Continuação de “Prioridades & Banalidades” e, de certa forma, um complemento para o ‘causo’ do seu Moreira.
Encerrei a última parte da série afirmando que um analista normalmente precisa de apenas 30 minutos para entender os objetivos do negócio. Provocação fracassada: ninguém questionou?!? Acreditam demais neste escriba, duvidam de tudo aqui escrito ou não sabem do que estou falando?
Quando falamos de projetos, qualquer dica que se pretenda universal deve ser recebida com desconfiança. E qualquer estimativa com números absolutos (30 minutos!) deve ser vista como trabalho de um ingênuo ou otimista ou inexperiente ou safado ou tudo isso misturado. Existem projetos complexos e muito grandes. Invariavelmente eles apresentam um conjunto de objetivos de negócio igualmente complexo e extenso. Por isso, acreditar que meia horinha seria suficiente para seu entendimento é acreditar em mágica. Por outro lado, seguirei afirmando que o entendimento dos objetivos do negócio, particularmente daqueles que motivam um projeto, deve ser algo simples e rápido. Ou deveria.
Mas, antes de seguir, um breve esclarecimento sobre os termos aqui utilizados:
- Motivação = Conjunto de Objetivos do Negócio
- Objetivo do Negócio = Requisito do Negócio
- Valor = Requisitos do Negócio devidamente atendidos
- Fracasso 2.0 = Valor não entregue
Vamos dividir os projetos de software em duas categorias, também para facilitar o entendimento do que vem abaixo. Vou chamar de “Pacote” aqueles projetos que visam a criação de um produto ou serviço que pretende ter vários clientes. E de “Custom” (perdão, bem que tentei achar um nome melhor) o projeto que atenderá demandas específicas de uma organização. A distinção é necessária porque as motivações para esses dois tipos de projetos podem ser consideravelmente diferentes. Assim como o processo para o seu entendimento.
Pacotes nascem de uma ideia brilhante e/ou de uma necessidade percebida. Ok, vários pacotes também nascem como cópias de cópias, tristes demonstrações de muita falta de imaginação. Mas aceitemos que a cópia também possa ser uma ideia razoavelmente brilhante. Não custa. E, às vezes, realmente são. A identificação e entendimento da motivação, em teoria, deveria ser muito mais simples nestes casos. Qual é a ideia? Qual é a oportunidade ou necessidade percebida? Se o autor ou vendedor da ideia não conseguir explicá-la de forma breve, desconfie. Ou produto ou seu “vendedor” não são tão bons assim.
Jim Highsmith – depois de Bill Shackelford – recomenda em “Agile Project Management” (2ª Edição. Addison-Wesley, 2010) que seja desenvolvida uma caixa para o produto ou serviço. Sim, uma caixa – uma embalagem para o pacote. Desconheço documento de visão mais direto e, preciso dizer, *Visual*. A caixa obriga a criação de uma mensagem ‘marqueteira’ (no melhor sentido da palavra). Nela destacamos as principais funcionalidades do produto ou serviço, de maneira suscinta na frente e de forma um pouco mais detalhada no verso. Restrições de uso, como plataformas ou sistemas operacionais por exemplo, seriam apresentadas no verso ou nas laterais. Enfim, a equipe deveria criar uma embalagem de verdade, com todas as informações fundamentais sobre o pacote. Um documento de 2 páginas seria uma alternativa para a caixa. A limitação de espaço é arbitrária sim. Exatamente para que os autores se limitem a informar aquilo que é fundamental. O poder de concisão, habilidade tão desejável em analistas e líderes de projetos, é crucial na apresentação da visão de um produto.
Um pacote é bem apresentado quando ele descreve:
- O público-alvo;
- Seu benefício-chave (o valor que estamos prometendo para o cliente/usuário); e
- Os diferenciais competitivos.
“Banhistas de Ipanema , refresquem-se com nosso côco geladinho . E não se preocupem com o lixo , porque o Zezinho aqui vai passar recolhendo tudo. É que a gente também faz uma graninha reciclando .”
Os três pontos explicam a motivação para o pacote. O seu desenvolvimento pode tomar um certo tempo. O que afirmei acima e reitero é: o entendimento dessa motivação deve ser rápido. Seja por uma analista de negócios ou por qualquer outra pessoa.
Requisitos ou histórias serão extraídos dessa definição. E devem ser priorizados. Pois é, o tema central desta série é priorização. Mas ainda vou demorar um pouquinho até chegar lá. Na próxima parte tratarei do entendimento da motivação em projetos “custom”. Inté!
.:.
Créditos
- Playground é uma foto da artista Tanakawho, e
- Software Box é do Vectorportal.
