Muito bem lembrado! Por descuido, ignorei priorização nesse parágrafo que escrevi. Aí entra em jogo justamente essa interação entre o AN e o GP, a estratégia da empresa, enfim… O assunto “escopo” é tão extenso que discutir isso num thread é, na minha opinião, totalmente impraticável. Por isso prefiro as discussões ao vivo 🙂

-Suzandeise

Fiquei mesmo com medo de confundir quando publiquei meu comentário. Tentei simplificar a coisa – e por isso não deveria ter falado em “Escopo da Solução”. Afinal, um pouco antes eu estava falando em “Escopo” – que a gente deveria ver um único “Escopo”.

Mas talvez a palavra não seja adequada. “Escopo”, “Requisitos”… estamos repletos de palavras que carregam mais responsabilidades do que deveriam. Eu sei que você não concorda, mas seguirei defendendo uma simplificação – um uso mais racional e direto dessas palavrinhas.

Segundo o PMBoK o gerente de projetos tem 9 “áreas” para cuidar. Não acho correto chamar esse conjunto de “escopo”. Até porque “Escopo” é uma delas. Exatamente aquela que, insisto, não deveria pertencer ao gerente de projetos.

Um projeto é iniciado para dar origem a um produto, uma solução, certo? A coisa mais importante de um projeto, independente do tipo ou natureza, é o seu produto. Concorda?

O que defendo, seguindo ensinamentos de Brooks e vários outros, além de minhas próprias cicatrizes, é que o gerente de projeto cuide da parte administrativa (Gerencial!) do projeto: custos, prazos, riscos, contratos… A parte criativa do projeto (o desenho da solução – algo que equivocadamente chamarei novamente de “Escopo”) deve ser de outra pessoa. Deve ser de um profissional que domine técnicas e tecnologias que serão utilizadas no desenvolvimento daquele produto. Gosto de chamar esse cara de “Arquiteto”. Por razões óbvias.

Será que deixei a coisa mais clara agora? Você diz.

Obrigado. Abraços,

Paulo

Primeiramente gostaria de parabenizá-lo pelo post “A Resposta do IIBA”. É bom saber que o Instituto está realmente disposto ao diálogo aberto com a comunidade.

Sobre o seu comentário nesse artigo, mais precisamente na parte do Escopo, discordo do final:

“… Ao analista de negócios cabe elicitar requisitos respeitando a delimitação de escopo definida no início do projeto (aqui assumo que isso foi feito direito no início do projeto, é claro.) Durante as atividades de elicitação de requisitos, é muito comum surgirem assuntos fora de escopo. Cabe ao analista de negócios não permitir que os “stakeholders” saiam pela tangente e incluam pedidos fora do escopo.”

Na verdade, cabe ao AN gerenciar o escopo de modo que requisitos prioritários sejam tratados como tal, independente do momento em que surgem. É claro que existem “n” restrições que interferem nessa priorização, mas é justamente aí que entram o AN e o GP, na negociação dos requisitos x restrições.

Abraços,

Leandro Mendonça

Não sei se entendi essa parte: “o Escopo da Solução deveria ter um único dono: o Arquiteto. ”

Esse “Escopo da Solução” seria o produto final do projeto, composto, por exemplo, pelo software funcional, suas especificações e demais artefatos que se façam necessários. É esse “Escopo da Solução” que pertence ao Arquiteto, certo? Nesse caso o conceito parece com o de “Escopo do Produto” do PMBOK.

Quanto ao “Escopo do Projeto”, esse é de responsabilidade do Gerente de Projetos e englobaria as demais disciplinas de gestão (riscos, aquisições, prazo, qualidade, integração, comunicação, etc.).

Penso que também exista um “Escopo do Problema” composto pelo conjunto de requisitos (necessidades). Esse conceito se aproximaria mais do “Product Backlog” do SCRUM do que da abordagem PMI para o gerenciamento de projetos. E o “dono” desse “Escopo do Problema” seria o Analista de Negócio (ou o Product Owner) e não o Gerente de Projetos ou o Arquiteto.

Na verdade tratam-se de 3 perspectivas cheias de intersecções sobre o mesmo objeto, no caso o projeto (problema + solução), mas a distinção me parece pertinente e necessária.

Pensei que você concordava com essas definições, mas fiquei confuso com seus últimos comentários.

Abraços,

Leandro.

Ok: ao vivo, com cerveja e num local com uma bela chaminé que disperse meu fumacê! 😉

Paulo

A distinção que vc fez entre a regra vs. a mudança da regra ou o processo vs. a mudança do processo faz total sentido.

Estou tentando conseguir liberação da pesquisa do ano passado… eu sabia que vc iria pedir. Não é só vc que está espantado com o critério de seleção das técnicas…

Quanto à discussão sobre escopo, vai ter que ser ao vivo mesmo 🙂

-Suzandeise

Tardou um pouquinho, mas eu sabia que não falharia, né? Antes de mais nada, muito obrigado pela consideração e pela participação neste debate.

Eu seria redundante demais se reafirmasse minhas opiniões. Acho que elas ficaram claras no artigo e nos comentários que publiquei. Então, me limitarei aos fatos novos:

Requisitos
A mudança de uma regra de negócio é um requisito. A regra não. A mudança de um processo também é um requisito. O processo não.

Essa distin̤̣o, que parece bobinha, faz toda a diferen̤a. Onde? Na qualidade das informa̵̤es do projeto Рna qualidade da documenta̤̣o!

Suzanne Robertson, co-autora do “Volere” (http://www.volere.co.uk/), é uma das experts consultadas pelo IIBA durante a elaboração do BABoK. Se tivessem “surrupiado” um pouquinho deste modelo, a definição de requisitos não estaria tão vaga. O “Volere” está bem documentado no apêndice A de “Requirements-Led Project Management”, livro que ela escreveu com James Robertson (Addison-Wesley, 2005). Não concordo 100% com ele, mas é bem melhor que o BABoK no assunto em questão.

Compatibilidade Retroativa

Eu entendo as origens, prezada Suzandeise. Basta ver a lista de experts consultados para se ter uma ideia: Scott Ambler, Meilir Page-Jones… O que não entendo e o critério de seleção de algumas práticas sugeridas.

Me causa espanto (e agora me baseio também na resposta oficial publicada em http://www.pfvasconcellos.eti.br/blog/2009/08/31/a-resposta-do-iiba/) saber que muita gente, mundo afora, ainda utiliza DFD’s e diagramas de contexto… Aliás, se a gente pudesse ver os resultados da pesquisa… Será que o IIBA pode fornecê-la?

Escopo

Sim, o Escopo da Solṳ̣o deveria ter um ̼nico dono: o Arquiteto. O profissional que guia o desenho e a constrṳ̣o da solṳ̣o Рque orienta o trabalho de toda a equipe t̩cnica. E que cuida da manuten̤̣o da Integridade Arquitet̫nica da solṳ̣o.

Fred Brooks, no longínquo 1975 (em “O Mítico Homem-Mês”, Elsevier-Campus, 2009), já dizia:

“Pensadores são raros. Executores são raros. Pensadores-executores são raríssimos!”

O arquiteto não se envolve com questões administrativas do projeto. O gerente do projeto não se envolve com o desenho técnico e a implementação da solução. Simples assim: um pensador e um executor.

Facilitamos a delimitação de fronteiras se eliminarmos algumas definições ambíguas, como “escopo do projeto” e “escopo da solução”.

Escopo, segundo o Houaiss, é “1. ponto em que se mira; alvo 2. intenção; objetivo.” Para nós, esse objetivo é o conjunto de requisitos que um projeto deve atender, certo? Então, IMHO, ele pertence ao cara que desenhou a forma pela qual os requisitos serão atendidos.

Próximo debate sem cerveja? Ah… 🙂

Obrigado. Abraços,

Paulo

Concordo com a sua avaliação da estrutura do BABOK 2.0 quando diz que a “forma como as disciplinas são apresentadas é boa,” mas que o diagrama da interação entre as áreas de conhecimento deixa a desejar. O diagrama atual é útil para entender como estão relacionadas as entradas e saídas de cada conjunto de atividades. Mas ele não deveria ser o único diagrama, pois a primeira impressão de quem o vê é de que ele é complicado demais. Seria mais didático introduzir primeiramente um diagrama simplificado (mais parecido com o do DRAFT) para depois complicá-lo com as setas que indicam todas as entradas e as saídas. O tanto de setas no diagrama atual causou até essa nova ordenação dos capítulos que, como você colocou, não é intuitiva pra quem lê o documento pela primeira vez. Vale a pena ressaltar que esse diagrama com todas as setas traz à tona a natureza iterativa das atividades de análise de negócios, ponto com o qual concordo plenamente.

AMBIGUIDADE NA DEFINIÇÃO DO TERMO “REQUISITOS”

O número de comentários neste thread discutindo a definição de “requisitos” é preocupante. Um documento como o BABOK 2.0 não deveria dar margem a interpretações. (Aliás, comunicação clara e livre de ambiguidade é uma habilidade crucial para analistas de negócios).

Admiro a sua maneira apurada e academicamente embasada de definir termos. Entendo a sua crítica de inconsistência na definição do termo “requisitos”. Mas teremos que conversar sobre isso por mais algumas horas (sem a cerveja e talvez com um flip-chart) para que eu possa chegar a uma conclusão sobre esse assunto. Os pensamentos que me vêm à mente agora resumo aqui…

Análise de Negócios acontece quando temos um problema ou uma oportunidade e precisamos encontrar uma solução. Esta solução tem que resolver o gap entre a capacidade atual da organização (processos, sistemas ou produto/serviços atuais) e onde ela quer chegar. Uma coisa é modelar o estado atual da organização (para entendê-la), outra coisa é descrever o ponto onde ela quer chegar (os requisitos da solução). Este “ponto onde a organização quer chegar” inclui tudo o que queremos manter da capacidade atual (inclusive processos e regras de negócios) + novos processos/regras/funcionalidades/etc. Então os requisitos das novas capacidades se confundem com os requisitos para se manter a capacidade atual… de qualquer forma são os “requisitos da solução” e a meu ver incluem, sim, processos e regras de negócio.

Toda essa discussão tem que ser resolvida e documentada a ponto de não dar margem para interpretações. Taí um desafio pro BABOK v3.

COMPATIBILIDADE RETROATIVA

O que você chama de “compatibilidade retroativa” é, na minha opinião, consequência da experiência daqueles que se juntaram para escrever o BABOK 2.0. A maioria dos envolvidos provavelmente veio de TI, portanto o texto que por um lado defende que Análise de Negócios abrange atividades muito além dos projetos de sistemas de software, cita muitos exemplos de TI e não deixa clara a aplicabilidade a outras áreas. Na minha opinião este é um dos maiores problemas desta versão do BABOK. É genérico demais em alguns aspectos (vide a confusão que gerou na definição de “requisitos”) e específico demais em outros (nos exemplos de TI).

Mas tudo depende da perspectiva de quem lê. Alias, quase todo o texto do BABOK tem que ser interpretado baseado na experiência de quem lê. Este não é um texto para iniciantes. (E acredito ser impossível passar na prova de certificação CBAP decorando o BABOK 2.0 sem ter a experiência requerida…)

Concordo com a diferenciação que o BABOK 2.0 faz entre “change-driven” e “plan-driven”. A deferenciação entre essas duas abordagens realmente é clara e consistente no capítulo 2 (“Planejamento e Monitoramento de Análise de Negócios”), como você indicou. Sua crítica ao capítulo 4 (“Gerenciamento e Comunicação de Requisitos”) faz sentido. Dada a natureza da abordagem “plan-driven”, é bem mais fácil entender os exemplos citados no capítulo 4 tendo em mente vivências dos projetos “cascata.” Mas ele também se aplica aos projetos que utilizam um processo ágil, ou a abordagem “change-driven”. Mesmo quando se utiliza um processo ágil, é necessário gerenciar requisitos, comunicá-los e aprová-los. A maneira como se faz isso é que deve ser diferente, menos demorada ou burocrática. Será que incluir exemplos disso no capítulo 4 é o melhor caminho? Se formos nessa direção deveríamos incluir exemplos de projetos que envolvem melhorias de processo, definição de novos produtos, e outros mais…

BABOK 2.0 vs. PMBOK

Eu te provoquei a ler o BABOK 2.0 e o seu artigo me fez estudar a quarta versão do PMBOK. Nos últimos dez dias despendi muito tempo analisando os textos, trocando emails, enfim… Não vou nem começar a destrinchar esta aparente falta de alinhamento entre o IIBA e o PMI. Daria um livro. Se eu conseguir respostas aos meus questionamentos, voltarei a esse tópico.

MODELAGEM DE NEGÓCIOS

Esta disciplina realmente foi dividida em vários capítulos. Não tenho opinião formada sobre como seria melhor abordar isso dentro do BABOK. Isso e a maneira como foi tratada a Arquitetura Corporativa estão entre os meus questionamentos também…

ESCOPO

A pergunta não deveria ser “quem é dono do escopo”, e sim quais são as responsabilidades de cada profissional em relação ao escopo. Ao gerente do projeto cabe gerenciar o escopo, isto é, não deixar que as atividades do projeto envolvam um escopo maior do que o combinado inicialmente para que não aconteçam impactos negativos no prazo nem no orçamento (o gerente de projetos só consegue fazer isso direito se ele também executar as atividades de análise de negócios ou se tiver no seu time um analista de negócios.) Ao analista de negócios cabe elicitar requisitos respeitando a delimitação de escopo definida no início do projeto (aqui assumo que isso foi feito direito no início do projeto, é claro.) Durante as atividades de elicitação de requisitos, é muito comum surgirem assuntos fora de escopo. Cabe ao analista de negócios não permitir que os “stakeholders” saiam pela tangente e incluam pedidos fora do escopo.

Escopo deveria ser do arquiteto? Você quis dizer o escopo da solução? Fiquei curiosa…