Dos diversos vícios que caracterizam nossa área, existe um particularmente perigoso: quando apresentados a um determinado problema, nos contentamos com a primeira solução que aparece. Excesso de confiança? Outra derivação da fatídica – e não inteiramente mentirosa – arrogância que carimba nosso perfil? Sim, mas não é só isso. Há também o fator prazo: “é para ontem!” O cliente, mal acostumado como nossa extrema agilidade, não entenderia caso pedíssemos um tempinho para pensar na melhor solução. Este problema é mais comum em empresas prestadoras de serviços, mas também é percebido em outras organizações de TI. Ou seja, nossas propostas, sejam elas para clientes externos ou internos, quase sempre estão vendendo a primeira solução que pintou em nossas cabeças. Mas quem acerta na primeira?
A mais importante ferramenta do físico é sua cesta de lixo.
- Albert EinsteinAs duas mais importantes ferramentas de um arquiteto são a borracha na sala de desenhos e a marreta na construção.
- Frank Lloyd Wright
Costumo dizer que, na iteração 0 (nos momentos iniciais do projeto, que antecedem o estudo de viabilidade e a elaboração de uma proposta), o principal trabalho do analista de negócios (AN) é ter uma visão do todo: “2 quilômetros de extensão e 2 centímetros de profundidade“. Para obter esse “instantâneo”, o AN lança mão de suas duas principais armas-disciplinas: A Análise e Modelagem do Negócio e a Engenharia de Requisitos [1].
Ao interpretar as dores e os objetivos do cliente, o AN começa a dar um certo “relevo” àquele “instantâneo”. Ele destaca os requisitos de usuários mais críticos – fundamentais para o negócio. Como mostrei na pequena série “Estruturando Requisitos” (link p/ parte 2), cada requisito devidamente *aprendido* pelo AN é – obrigatoriamente – acompanhado do atributo “Grau de Importância”: aquele requisito é Fundamental, Importante ou Opcional?
Com base nesta classificação o AN tem condições de selecionar os pontos que merecerão sua maior atenção. Sua atuação, agora, depende do tempo que ele tem para a elaboração da Proposta (ou Estudo de Viabilidade, ou Documento de Visão, ou Project Charter…). Seguindo a sugestão apresentada no artigo citado no parágrafo anterior, cada Requisito de Usuário selecionado é transformado em um Caso de Uso. O requisito “Emitir Nota Fiscal”, por exemplo, vira o caso de uso cujo título é “Emitir Nota Fiscal”.
Ao desenvolver o caso de uso em questão, o AN está “fazendo um zoom” naquele “instantâneo”. Por ser crítico para a solução do problema de negócio, aquele requisito (de usuário) será desdobrado em n requisitos funcionais. Mais que isso: no mesmo momento o AN também pode estar descobrindo ou aprendendo regras de negócio, definições de dados e também alguns requisitos não-funcionais. Informações que podem ser facilmente registradas em um bom modelo para especificações de casos de uso. Para cada requisito *aprendido* segue valendo a mesma questão: ele é Fundamental, Importante ou Opcional?
Vamos supor que estamos tratando de um projeto com 10 casos de uso. O AN teve tempo suficiente para detalhar um pouco mais 4 deles. Claro, para o detalhamento ele lançou mão de entrevistas, observações, sessões JAD (ou workshops) – as técnicas mais indicadas para aquele projeto e/ou cliente. Respeitando o prazo (que quase sempre é imposto), ele desenhou o melhor retrato possível do problema do cliente. Este retrato é composto por um grande diagrama conceitual (ou mapa de processos), diagramas de processos ou de linhas de montagem (caso os processos de negócio em questão sejam complexos o suficiente para justificar a elaboração destes), a classificação de 10 casos de uso e a especificação (um pouco mais detalhada) de 4 deles. Esta “radiografia” é tudo que a equipe possui para definir qual a melhor solução.
Equipe? Sim, o desenho da solução deve ser um trabalho em equipe. Em um futuro artigo apresentarei o que chamo de “parlamento” – o formato desta equipe. Vale ressaltar que cada ponto de vista relevante deve estar representado neste momento. Desenvolvedores, especialistas em usabilidade, os “inimigos” da infra, os “chatos” dos DBA’s e, claro, o coordenador do projeto. O AN, óbvio, representa o cliente. Mas não como um “advogado do diabo”. Não agora, em que sua principal responsabilidade é *ensinar* para a equipe o problema que deve ser solucionado. O AN apresenta um conjunto de “Fatos”, o problema definido.
Começamos aqui a expandir aquilo que Scott Berkun chama de “Espaço do Problema” [2]:
O início dos debates é marcado por um volume relativamente grande e heterogêneo de idéias. O “espaço do problema” aumenta, como ilustra a figura acima (surrupiada do Berkun). Em determinado momento (que variará bastante dependendo do tipo e complexidade do projeto), o time pára de gerar idéias e começa a agrupá-las. É sugerido que se chegue em 3 alternativas de solução: a mais cara, a mais barata e a coluna do meio, por exemplo. Sugestão: as idéias também são agrupadas em casos de uso.
Os debates, que a partir deste momento podem incluir o próprio cliente (formalmente, via proposta que contemple as 3 alternativas, ou informalmente, na mesa de discussões) visam a redução do número de opções. Gradativamente, por exclusão, ou com o cliente fazendo a escolha de uma das três alternativas apresentadas.
O problema com este enfoque é que, se por um lado está bem claro o que é fundamental ou importante para o negócio, por outro temos pouca visibilidade da complexidade e custo daquelas alternativas de solução. O “parlamento” foi reunido exatamente para suprir tal necessidade. Mas como isso é feito? O próximo artigo apresentará uma sugestão. Inté!
Notas:
- Mais do que os objetivos ou os atores (e seus objetivos), acredito que o melhor “guia” para o desenvolvimento de requisitos são os próprios processos de negócio. Um dia, num clássico trabalho (The Object Advantage – Addison Wesley (1995)), Ivar Jacobson disse que o “caso de uso é o nosso constructo para um processo de negócio”. Entendo que a análise e modelagem do negócio é indissociável da engenharia de requisitos. Para minha sorte, não estou só.
- “A Arte do Gerenciamento de Projetos“, de Scott Berkun – Artmed Editora (2008). Pois é, finalmente o grande livro do Berkun é lançado em pt-br. Para nosso azar o livro foi reeditado lá fora, com novo título (“Making Things Happen“) e conteúdo revisto. Quem mandou demorar?
The Quem Acerta na Primeira? by finito, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Brazil License.
Artigos relacionados:
- Casos de Uso, Requisitos Funcionais e Probleminhas [Atualizado]
- EPBE: Quem usa?
- Quem Paga a Dolorosa?
- O Parlamento
- Estruturando Requisitos – Parte 2
Related posts brought to you by Yet Another Related Posts Plugin.
{ 2 comments… read them below or add one }
Como sempre, cada caso é um caso. Vejo esse processo inicial como um pouco burocrático para empresas prestadoras de serviço de pequeno porte, que têm um capital de giro relativamente pequeno para bancar essas horas iniciais de planejamento da proposta.
Nestes casos, um pouco por opção e um pouco por restrição (ou até pressão para fechar a venda) a gente trabalha com estimativas menos realistas do que gostaria. Claro, o ideal é ter como financiar o desenvolvimento de uma proposta mais madura, mas em quantas realidades esse método se encaixa?
Comercialmente falando, acho interessante a cultura de fazer da análise de processos um serviço a parte. Independente do fechamento da proposta para a produção do software, um serviço preliminar de análise pode bancar uma proposta muito mais segura e com menos “gordura”, ou seja, tende-se a eliminar o excesso de contingência que muitos gerentes de projetos adoram colocar para segurar as pontas quando descobrimos os erros de estimativas do charter.
Vejam a bola de neve: como temos pouca garantia de retorno não investimos muito nas fases preliminares de análise (viajens, custo hora/homem, etc.) antes de fechada a venda. O resultado é um charter gordo de contingências de prazo e custo, para o caso das coisas darem errado (e vão dar errado se a venda for feita).
A pergunta que eu faço é a seguinte: quantas vendas perdemos por excesso de contingência? Posso estar falando uma grande bobagem, mas é a experiência que vi já em duas empresas (uma onde trabalhei e outra que acompanhei como expectador). Aqui estamos tentado fazer diferente, análise como um serviço cobrado separadamente, e está funcionando.
Olá Jefferson,
Não é a primeira vez que vejo argumentos como os seus. Tenho certeza, não será a última.
Burocracia? Sinceramente? Estou falando apenas de alguns poucos modelos (no modo ‘default’ apenas um – o mapa de processos ou visão conceitual do negócio) e dos casos de uso. Isso é burocracia?
Também concordo que, dependendo do projeto, um trabalho preliminar (de análise e modelagem do negócio + engenharia de requisitos) seja contratado em separado. Ou executado pela própria empresa contratante, municiando assim a elaboração de seu RFP (request for proposal) além, claro, do estudo de viabilidade (ou project charter, ou MRD – Marketing Requirements Documents etc). Mas preste atenção na minha sugestão.
Normalmente, qual o tempo médio que uma empresa tem para a elaboração de uma proposta? Mesmo falando das pequenas e médias. Qual o tempo médio? Vamos supor que seja de uma semana. Então.. o que a empresa faz neste período? Qual é o trabalho de preparação de uma proposta?
Em alguns casos, o AN trabalhará exclusivamente com a RFP(ou documento similar). Em outros, o AN terá espaço para tirar dúvidas (remotamente) ou até mesmo de realizar algumas entrevistas. Pois bem, minha sugestão apresentada no artigo trata exatamente disso: de executar de uma forma um pouco mais estruturada este trabalho.
Minha intenção principal é o alerta para o fato de que quase nunca acertamos na primeira. O desenho da solução merece melhor trato. Na carona sugiro que o escopo, desde o início, seja tratado como um conjunto de casos de uso que, desde seu “nascimento”, são devidamente classificados (assim como todos os requisitos que aparecerem).
Não importa se tenho 1 dia, 1 semana ou 1 mês para a elaboração da proposta. Sei que é perfeitamente possível utilizar o processo que apresentei.
Quanto ao custo: a parte mais “cara” é o parlamento. Seus melhores especialistas serão alocados por um certo tempo. Isso é investimento. Investimento no cliente, na proposta. Você aumentará muito suas chances na concorrência se investir mais – lógico. Reduzirá riscos se envolver os pontos de vista mais relevantes. Mas isso também é óbvio.
Agora, os custos para a elaboração da proposta, seja na minha sugestão, seja no método “bumba-meu-boi”, serão sempre os mesmos, não?
Abraços,
Paulo
{ 1 trackback }