PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Iterativo e Incremental

  • Muita Areia no Caminhãozinho do AN

    De todas as sugestões que apresento no FAN, a que causa mais espanto e suspiros é: um analista de negócios (AN) não deveria cuidar de mais de dois projetos ao mesmo tempo. Dois projetos pequenos! Invariavelmente a casa cai neste momento. E o burburinho parte, principalmente, de profissionais que atuam em médias e grandes empresas. Alguns deles são responsáveis por 10 ou mais projetos. Maluquice pura.

    Não entendo como eles podem tocar tantos projetos simultaneamente. E, considerando que essas empresas contam com algumas dezenas de AN’s, não entendo como elas conseguem disparar e cuidar de tantas iniciativas.

    O burburinho vira debate quando emendo uma segunda recomendação: AN’s deveriam trabalhar sempre em duplas. Uma rápida conta de padaria, que tanto caracteriza a matemática dos novos tempos, deve deixar todos aturdidos: “Hoje tenho 100 projetos e 10 AN’s. Você está sugerindo que eu contrate 190 analistas?!?” Isso sim seria uma bela política para geração de (bons) empregos. Mas reconheço sua inviabilidade.

    É fato que a sobrecarga insana de trabalho não é um privilégio dos AN’s. Infelizmente, é outra característica do século XXI. Mas ninguém deveria aceitar isso como um fato consumado e pronto. No caso específico dos AN’s não é difícil descobrir e tentar corrigir as razões de tanto trabalho¹.

    Em primeiro lugar é preciso dizer que nenhuma empresa tem tantos projetos assim. Projetos, com ‘P’ maiúsculo, devem representar apenas algo entre 10% e 20% de toda a demanda. O restante trata de alterações ou evoluções em soluções existentes, nos famigerados sistemas legados. E por que as empresas estariam utilizando analistas de negócios para cuidar de solicitações de manutenção em aplicações?

    Uma desculpa razoável seria a competência desses profissionais para o desenvolvimento de requisitos. O que muitas organizações não entendem é que não existem, na grande maioria dessas solicitações, requisitos. Não no sentido de existirem necessidades verdes o suficiente para justificar todo o processo de maturação intrínseco à Análise de Negócios. Noventa e tantos por cento das novas necessidades dos usuários são simples e diretas, como por exemplo: “coloca um novo campo assim nesta tela”. Gastar AN’s com solicitações dessa natureza é um belo desperdício.

    Sabe-se lá por que cargas d’água inventaram um novo nome para atendentes de help-desk. Sim, porque solicitações de manutenção deveriam ficar no âmbito daquele grupo que um dia batizamos “help desk”.

    Ouço de algumas empresas que parte das solicitações tem real necessidade de Análise do Negócio. Ok, mas quantas? Duvido que sejam 10% delas. E insisto: é desperdício. Mas entendo: começaram a colocar AN’s para desempenhar essa função na vã esperança de melhorar um cadinho a qualidade do atendimento. Acontece que a solução virou um tiro de bazuca no pezão: AN’s estão aprendendo a desenvolver um monte de coisa. Leem o BABoK ou participam do FAN e absorvem dezenas de ferramentas que podem tornar seu dia a dia menos desagradável. Pena que sejam coisas que agregam muito pouco ou nada quando o trampo é só de manutenção de sistemas. Pior: são coisas que custam tempo e dinheiro.

    Uma grande, imensa empresa tupiniquim se prepara para experimentar um novo desenho. Deve instituir a figura dos Analistas de Demandas ou algo parecido. Seria o meio termo entre analistas de negócios e atendentes de help-desk. Não sei se a solução não deveria ser simplesmente uma melhor preparação do pessoal de suporte. Uma preparação que passasse obrigatoriamente pela especialização. Por exemplo: o cara que atende chamados sobre impressoras não pode ser o mesmo que recebe solicitações para o SAP/R3. Parece óbvio, mas não é tanto assim em alguns lugares que conheço.

    Não há processo ou ferramenta que substitua um simples “Não!”

    Um segundo fator que contribui muito para a sobrecarga de AN’s é a incapacidade que algumas organizações têm de falar “Não”. Em tempos de nervos à flor da pele, competição interna sanguinolenta, políticas demasiadamente corretas e grave miopia onde deveria existir só *Visão*,  a impressão que fica é que todas as demandas e projetos são prioritários, vitais e pra ontem. Uma peneirinha meio esburacada já ajudaria muito. Gastamos tanto com soluções para gestão de portfólios, PMO’s e afins, e seguimos sem a mínima capacidade de dizer qual projeto merece mais atenção e recursos. Enquanto uma organização não aprender a colocar suas iniciativas e demandas em uma fila indiana (uma atrás da outra, sem exceção) ela seguirá com a sensação de sempre ter mais trabalho do que recursos disponíveis para executá-lo².

    Justificando as Sugestões

    “Que tal sugerir que cada dupla de AN’s tenha um mordomo ao seu dispor?” Já ouvi algo parecido, de um colega que interpretou de maneira um tanto precipitada minhas sugestões. Não defendo sombra e água fresca para AN’s. Apenas insisto que eles não conseguirão provar seu valor se: i) Trabalharem em mais de um projeto (ou dois projetos pequenos); e ii) Não trabalharem em duplas. Por favor, me permita justificar.

    Defendo que todo projeto de software seja desenvolvido seguindo um modelo Iterativo e Incremental. Deve estar implícita nesta sugestão a necessidade dos AN’s permanecerem no projeto do primeiro até o último dia. E, a menos que o projeto seja pequenininho, é impossível que os AN’s cuidem (bem) de mais de um. Repito: impossível.

    Pense nas principais tarefas desempenhadas por um AN: entender um negócio e determinado problema ou oportunidade; e entender o usuário, suas necessidades e restrições. Ambos “entendimentos” ocorrem simultaneamente, em diversas situações. Vamos simplificar e usar o modo mais corriqueiro: o AN entrevistando um usuário. Ele deve prestar atenção em seu interlocutor e conduzir a entrevista. O “olho no olho” é importante, assim como a leitura de sinais, caretas e tiques. A explicitação da conversa, seu registro na forma de diagramas, especificações de casos de uso etc, é igualmente importante. E demanda a mesma fatia de atenção. Como um AN pode desempenhar bem, simultaneamente, duas funções tão distintas?³

    Já experimentei de tudo para substituir a explicitação anotada: gravação de áudio, vídeo etc. Nada substitui uma segunda cabeça. Ao término de uma entrevista, no momento da análise dos requisitos aprendidos, ela completa o entendimento, ajuda a destacar pontos obscuros e dúvidas. Enfim, duas cabeças sempre serão melhor que uma.

    Outra justificativa para o uso de duplas é o melhor aproveitamento das habilidades de cada um. Tem analista que parece ter nascido para a socialização: é bom de papo, transmite segurança e sabe lidar com usuários e clientes. Outros são talentosos na redação e desenho. É relativamente raro encontrar um AN que faça muito bem as duas coisas. Como é impossível que ele faça bem as duas coisas simultaneamente, por que não equipá-lo com seu par ideal?

    Eu sei, a implementação dessas sugestões tem que entrar na fila. As empresas que pretendem obter o máximo da Análise de Negócios devem ter outras prioridades: i) Aprender a dizer “Não!”; ii) Colocar os projetos em fila indiana; e iii) Separar o hoje (operação) do amanhã (projetos). E não é que a Análise de Negócios pode ajudá-las até nisso? Bom, acabei de arrumar mais areia para os abarrotados caminhõezinhos dos AN’s. Inté!

    .:.

    Observações:

    1. Eu quis dizer que a identificação dos problemas é fácil. Sua solução, nem tanto.
    2. Perguntinha retórica mas necessária: capacity planning só vale para máquinas?
    3. Vira e mexe me deparo com uma solução curiosa: o AN diz que anota tudo rapidinho, priorizando o contato “olho no olho” com o usuário ou cliente. Depois volta para casa e “passa tudo a limpo”, inclusive escrevendo os casos de uso. Esforço total: 4 horas, por exemplo. Se ele tivesse um par que o isentasse da anotação, ciente de que “passar a limpo” é desperdício e que especificações de casos de uso são construídas na frente do usuário, consumiria as mesmas 4 horas.
    4. A imagem utilizada, “Colorful toy trucks parked in a circle“ é de Horia Varlan e foi obtida no Flickr.

  • Agile Project Management

    Autor: Jim Highsmith é um consultor e escritor, especialista em engenharia de software e gerenciamento de projetos. Além do livro apresentado aqui, escreveu também “Adaptive Software Development” (Addison-Wesley, 2000), dentre outros. Foi co-autor do Manifesto Ágil.

    Editora: Addison-Wesley | The Agile Software Development Series. Primeira edição de 2004. Esta entrada é sobre a segunda edição, publicada em 2010.

    Do que se trata: Criação de produtos inovadores através do APM – Agile Project Management, ou Gerenciamento Ágil de Projetos. Apesar da intenção de atender um público mais amplo, é claro que Highsmith concentra-se no desenvolvimento de software.

    O autor sugere um Agile Enterprise Framework composto por 4 camadas:

    • Governança do Portfólio
    • Gerenciamento de Projetos
    • Gerenciamento de Iterações
    • Práticas Técnicas

    O livro só não cobre a última camada, que pode ser composta por práticas sugeridas em frameworks como XP (eXtreme Programming), OpenUP etc.  Highsmith defende que a estrutura proposta “facilita a construção de métodos ágeis híbridos que atenderiam necessidades específicas de uma organização”.

    O destaque para o Gerenciamento de Iterações não é novo, mas Highsmith coloca o tema em um novo patamar. O Planejamento Avançado de Releases é uma das principais atualizações desta segunda edição. As outras são: Valores Ágeis; Escalando Projetos Ágeis; Governança de Projetos; e Medição de Performance.

    A quem se destina: Líderes de projetos.

    Mas também pode ser muito útil para:

    • Gerentes de projetos insatisfeitos com sua situação atual;
    • Gerentes de produtos cobrados por inovação, qualidade, valor, agilidade…
    • Qualquer um que queira conhecer o Mundo Ágil de maneira ampla e sem dogmas ou extremismos. É particularmente indicado para executivos e gerentes.

    Prós:

    • Isenção. Highsmith não defende nada específico como Scrum, XP ou FDD, por exemplo. E justifica sua posição lembrando que um dos princípios  do desenvolvimento ágil é a adaptação para diferentes situações.
    • É esta isenção que possibilita que Highsmith critique alguns caminhos e descaminhos do Mundo Ágil.
    • O livro é muito bem estruturado e ilustrado. O que torna a leitura das 370+ páginas um estudo agradável.

    Contras:

    • As alterações em relação à primeira edição são muito grandes. Desconfio que o “segunda edição”, apresentado em letras garrafais na capa, faça com que muitos que conheceram a primeira edição ignorem este lançamento. Não deveriam.
    • Aliás, que capinha mais feia, hem?

    Destaques Aleatórios:

    • “Qualquer um que pratique o desenvolvimento ad hoc sob o disfarce ‘ágil’ é um impostor.” (pág. 9)
    • “Olhando de fora, um time gerenciado e um time liderado podem parecer a mesma coisa. Dentro eles são muito diferentes.” (pág. 48)
    • “Princípios guiam práticas. Práticas instanciam princípios. Não dá para separá-los”. (pág. 86)
    • “Todo projeto deve ter um time de desenvolvimento e um time de produto. O grupo de desenvolvimento deve ser liderado pelo líder do projeto e o grupo de produto pelo gerente do produto (que no Scrum é chamado Dono do Produto).” (pág. 119)
    • “O reconhecimento de que a iteração 0 (zero) não entrega valor para o cliente pressiona o time a mantê-la breve”. (pág. 147)
    • “… ‘Como você consegue estimar o desconhecido?’ A resposta é: ‘Você não consegue’. Quando há o desconhecido você está chutando, não estimando – e isso é o melhor que podemos fazer. É por isso que tempo e custo são vistos como restrições, e não estimativas, em projetos ágeis.” (pág. 153)
    • “A falta de um bom planejamento de releases é endêmico em partes da comunidade ágil”. (pág. 157)
    • “Existem duas estratégias fundamentais para o gerenciamento de mudanças – antecipação e adaptação – e o bom design leva ambas em consideração.” (pág. 218)
    • “Muita gente, inclusive algumas da comunidade ágil, pensa que o gerenciamento ágil de projetos significa menos gerenciamento. Em minha experiência, o gerenciamento ágil pode ser diferente, mas com certeza não demanda menos tempo.” (pág. 225)
    • “O intercâmbio de pessoas é muito mais eficaz que o intercâmbio de papelada.” (pág. 283)
    • “Os relatórios do Standish Group NÃO são bons indicadores da pobre performance do desenvolvimento de software, eles SÃO bons indicadores das sistêmicas falhas de nossos métodos de planejamento e medição.” (pág. 334)
    • “Quem nunca cancela projetos nunca corre riscos. Quem não corre riscos não sobrevive. não é fracasso, é bom gerenciamento.” (pág. 334)
    • “Previsibilidade ou agilidade: escolha uma.” (pág. 336)

    Trilha de Estudo:

    • Como prometido, uma trilha curta (em número de títulos). Esta entrada completa a anterior, “Agile Product Management with Scrum“, de Roman Pichler. Diz aí, você precisa de 2 dias, 2 semanas ou 2 meses para estudar ‘isso tudo’? Inté!

  • Times

    Existem Times, times, timinhos e igrejinhas, como a Copa recém-encerrada bem mostrou. A formação de equipes, para projetos de qualquer natureza, é uma complexa mistura de ciência, bom senso, tato e intuição.

    Ciência porque é preciso conhecer o projeto, as partes interessadas, as habilidades requeridas – tanto sociais quanto técnicas, e o desenho sócio-técnico mais adequado. O bom senso delineia fronteiras, particularmente em relação aos selecionáveis. O tato é exigido tanto na convocação quanto na exclusão de integrantes da equipe. Por fim, a intuição, subjetiva qualidade que permite perceber que aquele improvável jogador pode render bastante em determinado momento do projeto.

    Este artigo trata exclusivamente o primeiro componente, a ciência. E, claro, não falará sobre seleções de futebol. Apesar de sua possível utilidade em outros tipos de iniciativas, o alvo aqui são os projetos para desenvolvimento de sistemas.

    Até pouco tempo atrás eu me gabava de ter feito apenas uma pequena alteração em um metamodelo sócio-técnico que tinha uns 10 anos de idade. Vendia-o como um modelo para um Dream Team, ignorando alguns padrões emergentes que exigiam outro nível de abstração. A ficha só caiu depois de uns tabefes na cara, particularmente os proferidos por Jim Highsmith em “Agile Project Management – 2nd Edition” (Addison-Wesley, 2010). Roman Pichler, em seu “Agile Product Management with Scrum“ (Addison-Wesley, 2010), deu o bofetão de misericórdia.

    O Líder do Projeto

    O Movimento Ágil colocou o auto-gerenciamento no topo da agenda de todos que estavam formando times seguindo seus princípios. “Indivíduos e interações são mais importantes que processos e ferramentas”, é o que diz o primeiro verso do Manifesto Ágil. Dele derivaram os conceitos de auto-direção, auto-organização, auto-disciplina, respeito pelos indivíduos, igualitarismo e um bom ambiente de trabalho.

    Highsmith diz com todas as letras que “times auto-organizados não se caracterizam pela falta de liderança, mas por um estilo de liderança”. Reforça a mensagem citando Larson e LaFasto (“Teamwork: What Must Go Right, What Can Go Wrong”. Sage Publications, 1989): “bons líderes são o principal ingrediente de projetos e organizações de sucesso”.

    Highsmith ataca frontalmente,  resguardando os nomes dos santos, as propostas de auto-direção. Estas sim se caracterizariam pela ausência de um líder único. Os integrantes se revezariam nesta função dependendo de determinada situação em um projeto. Parece claro que ele dirige suas críticas para algumas práticas sugeridas em frameworks como o Scrum e a XP (Extreme Programming). Critica as práticas ou algumas interpretações delas, preciso dizer.

    Déjà vu? Pois é, já falei um tanto sobre o líder aqui no finito, na seguinte série:

    O Time de Produto

    Residem aqui todos os que ajudam a definir e priorizar o que precisa ser feito. Sim, é aqui que fica o Product Owner (PO – Dono do Produto) em um projeto guiado pelo Scrum. Uma coisa que precisa ser mais reconhecida e divulgada é que o PO, normalmente um usuário ou especialista no domínio, raramente terá disponibilidade para executar e entregar tudo o que está sob sua responsabilidade. Para muitos não fará sentido, por exemplo, a execução de várias tarefas operacionais para desenvolvimento e manutenção da Pauta (ou Product Backlog, como queiram).

    Além do PO ou gerente do produto, o time de produto pode ser formado por: analistas de negócios, especialistas no produto / domínio e parte do pessoal de controle de qualidade (QA). Highsmith reconhece que “a formação deste time, com as pessoas mais adequadas e com tempo suficiente, pode ser um complicado desafio para muitas organizações porque o comprometimento exigido é bem maior do que em projetos tocados de maneira tradicional”.

    É por isso que teimo tanto com a Formação de Analistas de Negócios. Por entender que os bons analistas podem compensar a indisponibilidade de usuários e clientes que mal têm tempo para cuidar de seus afazeres cotidianos. Que fique claro: eles compensam, mas não substituem nunca os usuários e especialistas.

    O curioso é que até hoje vemos equipes sendo formadas sem um único representante disso que chamo (depois do Highsmith) de Time de Produto¹. Gerentes de projetos e analistas-programadores normalmente se revezam na posse dessas atribuições. O (imenso) problema com este enfoque é um só: gerentes e analistas-programadores não percebem o “levantamento de requisitos” (sic) como sua responsabilidade principal: “a gente não foi contratado pra isso”. Eles querem é gerenciar e programar. “Requisitos”, vejam só, é um tipo de impedimento para que eles executem seu trabalho real. Uma amolação.

    O Time de Desenvolvimento

    Gerentes de projetos, analistas-programadores (é melhor Desenvolvedores, não?) e afins moram aqui. Se o Time de Produto define o que precisa ser feito, este é o grupo responsável pelo como será feito e pela construção propriamente dita. Apesar de vivermos em tempos de massificação simplista e beócia – formando e contratando “analistas-programadores” como se tudo fosse a mesma coisa – não custa insistir que este time também é multidisciplinar. Que, dependendo do projeto, vários especialistas podem ser requeridos. Um profissional que saiba desenvolver para o Android ou iPhone, por exemplo.

    Gosto de ver, de forma macro, uma estrutura com um mínimo de 4 células: interfaces, serviços, dados e infraestrutura. Isso não significa hierarquização nem divisão excessiva do trampo, mas sim a aceitação de que existem conhecimentos específicos. Não é “linha de montagem”, mas o reconhecimento do fator humano e da impossibilidade de contratar gente que saiba tudo sobre tudo. Estão distantes os tempos dos monoblocos cobolísticos.

    Juntando Tudo

    Se há um projeto então existe um objetivo ou conjunto de objetivos bem definido. Se o Líder, o Time de Produto e o Time de Desenvolvimento trabalham no sentido de alcançar o mesmo objetivo, então eles formam um único time. Este deveria ser o único critério para definir um time de verdade, não as eventuais divisões internas que só existem para organizar o conhecimento e as responsabilidades de cada um.

    É muito sadia a divisão entre a turma do “que” e do “como”:

    • Falando como um usuário: “Eu realmente participo do projeto, faço parte do time. E quando não posso participar de algum encontro, fico tranquilo porque tenho um representante que defende meu ponto de vista. Isso, mais as entregas regulares que um processo iterativo e incremental garante, torna o projeto um trabalho agradável e estimulante, ao contrário do calvário que caracterizava nossos projetos anteriores.”
    • Falando como um desenvolvedor: “Finalmente inventamos uma maneira de ter o usuário bem perto da gente sem aquela sensação de ‘nós contra eles’, de dormir com o inimigo. Somos um time só e o que nos une são os objetivos do projeto.”

    Divisão sadia, mas naturalmente conflituosa. Sempre foi, independente da arquitetura social ou processo de desenvolvimento utilizado. E sempre será. Os conflitos podem gerar uma tensão criativa, desejável ou até mesmo fundamental dependendo da natureza do projeto. Uma hora é um time que apresenta sua caixa – suas restrições e condições. Outra hora a outra divisão o faz. E todos trabalham, como diz Scott Berkun², “pensando dentro da caixa, debaixo dela, fora dela, quebrando-a e fazendo uma bela fogueira”. É nesta hora que a presença de um líder pode fazer diferença. Quando o “que” e o “como” demoram para atingir um consenso, transformando a caixa numa solução criativa, nada melhor que um olhar isento mas igualmente comprometido com os mesmos objetivos. E com 3 votos nunca teremos empates, certo?

    .:.

    Observações:

    1. Já usei o termo “Time do Dono do Produto”, traduzindo literalmente Roman Pichler no livro já citado. “Time de Produto”, conforme sugerido por Jim Highsmith, é bem melhor. Mas confesso que não sei como ficará de forma definitiva em português. Aliás, nem sei se vingará como conceito!!
    2. Em “A Arte do Gerenciamento de Projetos” (Bookman, 2008).
    3. A ilustração utilizada neste artigo, “Chain of People”, foi legalmente surrupiada de HikingArtist.

  • Iterativo & Incremental: O Segundo Fator

    Semana passada sugeri uma forma alternativa de apresentar e justificar a adoção de um ciclo de vida para projetos baseado no modelo Iterativo & Incremental. Deveríamos enfatizar a certeza de que todos cometerão erros em detrimento do destaque dado às inevitáveis mudanças.

    Faltou dizer que muito do que chamamos de mudanças são na realidade erros. Usuários e clientes não são obrigados a aprovar o primeiro produto que recebem, por precisas e assinadas que sejam atas, especificações de casos de uso ou afins. Há mais mistérios entre requisitos e o produto final do que imagina nossa vã filosofia. E essa distância sempre exigirá, em alguma medida, um processo de tentativa e erro. Esse tipo de mudança é sim um erro. Muitos não gostam da palavrinha ou de admitir que erram. Mas deveríamos classificar melhor aquilo que chamamos de erros e mudanças. Papo para outra hora.

    Porque hoje eu gostaria de destacar um segundo fator que justifica a adoção do modelo Iterativo & Incremental: as pequenas vitórias. Assim como é indiscutível que o ser humano erra, também é indissociável de nossa natureza a necessidade de motivação – de uma recarga quase diária de nossas baterias. Em projetos não bastam seus objetivos, por nobres e ambiciosos que sejam, nem eventuais compensações financeiras. Imagine um campeonato de futebol, curto como uma Copa do Mundo ou longo (e cansativo) como o Brasileirão. Os times e jogadores comemoram cada vitória e cada gol. No vôlei, um jogo definido após dezenas de pontos, cada um deles é comemorado. Cada gol ou ponto é uma pequena vitória. Elas são tão cruciais para uma equipe de projetos como são para os jogadores.

    Em projetos tocados segundo moldes convencionais, particularmente no popular “cascata”, há pouco espaço para comemorações intermediárias. Por mais que equipe e coordenadores soltem foguetes para um documento de visão bem escrito ou uma coleção de especificações e modelos “nota 10”, o fato é que não há torcida nem usuários ou clientes compartilhando aquele momento e muito menos incentivando-o. É como uma vitória em treino, fechada e sem valor.

    A vitória que conta, por menor que seja, tem participação direta do público externo – dos usuários e clientes. E eles sabem que documentos e modelos não valem como gols e pontos. Ou seja, não substituem o produto final.

    Um projeto guiado pelo modelo Iterativo & Incremental supõe a comemoração de várias pequenas vitórias. Admite sim alguns revezes, como vimos no artigo anterior. Mas, exatamente por conta deste fator, torna a vitória final mais factível. Cada entrega, iteração ou gol é motivo para celebração. E isso ajuda a renovar o ânimo do time. No contexto de projetos há outros efeitos colaterais bastante benéficos, sendo o principal deles o aprendizado. O time tem a chance de rever seus erros e acertos, o que possibilita uma melhor preparação do próximo ataque, jogo ou iteração.

    Imagine um zero a zero arrastado e chato. Pior ainda, decidido nos pênaltis. Compare com uma sonora goleada, um jogo aberto e bonito de se ver, com placar final de 5 a 3. Qual você prefere?

    .:.

    “Goal“, a foto utilizada neste artigo, é do Jonas B.

  • Iterativo & Incremental: Um Convite aos Erros

    Entre todos os mistérios que rondam nossa área há um difícil de explicar e justificar: qual a razão de tanta resistência na adoção de um ciclo de desenvolvimento que seja iterativo e incremental?

    Nos últimos três anos, só por conta do FAN, pude falar com mais de dois mil profissionais e estive pessoalmente em dezenas de empresas. Sei que não tem valor de pesquisa, mas foi fácil concluir que pelo menos 95% deles ainda trabalham baseados em um modelo “cascata” (ou Waterfall) de desenvolvimento¹. Se considerarmos que já tem quase duas décadas que vários autores, metodologistas, empresas e consultores recomendam a adoção de outro modelo, qual a razão da incontestável predominância da “cascata”?

    Não, este (pequeno) artigo não tem a menor intenção de reativar o debate ou destacar prós e contras de cada proposta. Aliás, se você quiser uma boa justificativa *econômica* para adoção do modelo iterativo & incremental, deveria ler este texto do José Paulo Papo. Minha preocupação aqui é outra.

    Comumente apresentamos o modelo iterativo e incremental, independentemente do sabor (RUP, XP, Scrum, OpenUP…), como um remédio para as inevitáveis mudanças. Esse discurso costuma encontrar dois tipos de reflexos:

    1. (Ainda) existem aqueles que acreditam que mudanças ocorrem exclusivamente porque o entendimento do problema não foi bem realizado. São os mesmos que, infelizmente, acreditam que a Análise de Negócios é a resposta definitiva para especificações (sic) mal feitas. O que vemos neste cenário é mais gente gastando mais tempo e dinheiro para escrever mais. Deveríamos escrever melhor, estruturar melhor as informações aprendidas e colaborar, conversar mais. E não escrever mais e de maneira mais detalhada².
    2. “Os requisitos são estáveis e temos uma ótima compreensão do problema que iremos sanar. Podemos trabalhar em ‘cascata’”. É um reflexo parecido com o anterior mas com uma diferença: há realmente a sensação de que o solo pisado é de fato conhecido. Esta é uma das justificativas que encontro com maior frequência para a não adoção de um modelo iterativo e incremental.

    Percebendo os dois reflexos alterei minha maneira de apresentar e “vender” o modelo iterativo e incremental. Transcrevo abaixo o que costumo falar nos treinamentos e consultorias:

    O que é bonito no modelo iterativo & incremental é que ele reconhece um fato que nunca mudaremos: somos humanos. Ou seja, nós vamos cometer erros. Vários! Ao adotar este modelo estamos dizendo para nossos usuários e clientes: “Nós vamos errar, caríssimos, todos nós. Às vezes será um problema de interpretação de seus requisitos e histórias. Outras tantas vocês errarão, na explicação ou apresentação das próprias necessidades. E, precisamos admitir, muitas vezes as funcionalidades entregues não os atenderão pelos mais diversos motivos. Não importa. Aliás, não importa desde que o modelo de desenvolvimento adotado reconheça essa verdade: somos humanos e vamos errar”.

    Esse discurso gera duas respostas muito positivas: i) desarma aqueles que ficam louquinhos por um debate; ii) facilita a compreensão por todos que nunca trabalharam de outra maneira que não seja a “cascata” ou o “caos absoluto”. São bastante perceptíveis também as carinhas de surpresa que surgem com a repetição de uma palavrinha: Erro.

    Criamos uma cultura que combate e pune erros. Mesmo em ambientes que se dizem “inovadores” o erro ainda é mal visto. As pessoas vivem com medo de errar. Imagine então o desafio de dizer, antes mesmo do início de um projeto, que erros acontecerão. Mas é fato: erramos. Pra caramba!

    Clientes e usuários costumam gostar muito dessa transparência, dessa sinceridade. Estranham porque ela não é muito comum em nosso mercado. Mas aceitam o modelo e o consequente desafio com mais facilidade³. Daqui para a adoção de outras práticas mais modernas é “um tirinho”.

    .:.

    Observações:

    1. Num belo dia um cliente pediu que eu pulasse essa parte do curso: “A gente já desenvolve assim”. Obedeci. Mas depois o treinamento caminhou na base de soluços. Descobri o problema e o susto que curou o soluço: “É que nossas iterações duram algo entre 3 e 4 meses”. Ou seja, eles não desenvolviam de forma iterativa e incremental. Era outra coisa.
      Um outro freguês, agora numa turma aberta, disse que usa Scrum mas que tem que levantar todos os requisitos no início do projeto. Ou seja, não era Scrum. Também era outra coisa qualquer que nem merece nome.
    2. Era uma vez uma empresa que terceirizava todo o trampo de codificação para “fábricas de software” (sic). Eu apresentava para eles os 5 ícones recomendados pelo Cockburn (“Escrevendo Casos de Uso Eficazes”, Bookman. 2006) para indicar o nível de detalhamento de uma especificação de caso de uso. Eles disseram que, para trabalhar com fábricas, os 5 não seriam suficientes. Pediram a criação de outro, abaixo da “ostra”. Sugeriram a colocação da logomarca da Petrobras. E explicaram: “É o nível ‘pré-sal’, sete mil metros abaixo do nível do mar! Só assim o pessoal da fábrica entende.” Repito: não é escrever mais. Não deveria ser…
    3. Era outra vez, lá pelos idos de 2001 ou 2002, eu tocava um projetão. ÃO mesmo, em porte e complexidade. Sabe-se lá porque ($$$) topamos que o cliente “espelhasse” toda nossa estrutura gerencial. Para cada líder de nosso lado, eles colocavam um líder do lado de lá. Um mês de lua-de-mel. Um mês de “briguinhas”. E no terceiro mês a pérola: “Para com esse negócio de iterativo e incremental – queremos que seja cascata”.
      Juro, não é cascata não. Contei a história aqui só para dizer que a palavra “facilidade”, escrita ali no último parágrafo, deve ser interpretada com a devida precaução.
    4. “Funny“, a foto utilizada acima, é da Tanakawho. Sempre ela!

  • Motivação, Parte 2

    Se você perdeu, a parte 1 está aqui.

    Hoje vou falar sobre motivação em projetos “custom”, aqueles desenvolvidos especificamente para uma organização. O entendimento da motivação para esse tipo de projeto é um pouquinho mais complicado. Em artigos anteriores (1 e 2) eu falei sobre alienação (da equipe de desenvolvimento) e problemas de comunicação. A *motivação* desta série é a dificuldade que equipes apresentam para decidir o que é prioritário em um projeto. A *tese* aqui defendida é que todas as decisões sobre priorização deveriam se basear nos requisitos do negócio – nos objetivos que *motivaram* o projeto. Parece papo de maluco, né? Afinal, não é natural ou óbvio que seja assim? Envergonhadamente devemos admitir que não, não é natural.

    Chegamos em um estágio em que o usuário pede, “faz uma tela assim e assado”, e a equipe vai lá e faz. Aquela “tela”, que aos olhos do usuário parece algo banal, logo vira uma dor de cabeça coletiva: não se comunica bem com outras aplicações ou módulos de um mesmo sistema; quebra a ordem conhecida de um processo de negócio; apresenta regras de negócio conflitantes com outras previamente implementadas; recebe frequentes pedidos de alterações etc. Mas o que nos interessa aqui, agora, é que demandas deste tipo carecem de sentido: O que o negócio ganha com isso? Ou o que ele perde se a solicitação não for atendida? E quando chegarem dúzias de demandas parecidas, quais merecerão o início da fila?

    O processo não pode ser mecânico assim. TI não é padaria, com todo respeito às padarias. E usuário, mesmo quando guiado pelas melhores das melhores intenções, não deveria invadir o domínio da solução como no exemplo acima. Ele não deveria pedir uma tela, um módulo ou um sistema. Ele deve explicar suas dores, os seus problemas. Se a solução para eles será uma tela ou um sistema, quem dirá é a organização de TI. E TI toma boas decisões quando as fundamenta através da Análise de Negócios.

    O bom analista de negócios não começa seu trabalho em um projeto anotando os requisitos de um usuário para determinada tela, módulo ou sistema. Ele começa tentando entender e diagnosticar as dores do usuário. O bom analista sabe que nem sempre a solução será um sistema. E é aqui que o trabalho em projetos “custom” se diferencia demais daqueles que na parte anterior chamamos de “pacotes”. Aqui há um problema específico a ser diagnosticado e sanado.

    A necessidade de um diagnóstico rápido e eficaz é o que justifica minha cara de pau de sugerir uma sensível alteração na sequência de perguntas proposta por Dan Roam em “The Back of the Napkin” (Portfolio, 2008). “Por quê” é a primeira pergunta que o analista faz: “Por que este projeto é necessário?”. A resposta e toda a conversa que se desenvolve a partir dela nos ajudam a criar uma das três visões que compõem um modelo de negócios básico, a Visão do Negócio. Esta perspectiva, que pode assumir diversos estilos e formatos, compila todos os objetivos do negócio. Colocando de outra maneira, ela documenta a motivação para o projeto.

    É importante que ela, a Visão do Negócio, não seja confundida com o Documento de Visão. Este apresenta a visão (oh!) da solução. Ao desenvolver a Visão do Negócio, o analista ainda está relativamente distante da solução e sua respectiva visão.

    A visão do negócio pode ser representada por uma única linha em um documento, como por exemplo: “Dobrar o número de visitas realizadas pelos vendedores“. Mas ela também pode ser mais elaborada, como tenta mostrar o diagrama abaixo. A complexidade de um negócio ou a amplitude e criticidade de suas dores determinarão o formato mais adequado para entendimento e documentação¹ dos requisitos do negócio.

    Pois é, apelei para o causo do seu Moreira para dar um pequeno exemplo de diagrama que pode formar a visão do negócio. As duas áreas destacadas mostram todos os requisitos de negócio. O que pode ser apenas uma frase, “Dobrar o número de visitas”, em um diagrama mais elaborado pode ganhar a forma de uma hierarquia de objetivos ou requisitos de negócio. Repare que o “Dobrar nº Visitas” é quebrado em vários objetivos menores. E ele próprio deriva de outro, ou, colocando de uma maneira diferente, é condição para a realização de outro requisito, “Dobrar Faturamento”.

    Muito se fala sobre rastreabilidade de requisitos: “Toli Toli Tolá…” – e a cobla ficou lá², vendendo matrizes de rastreabilidade. Perdão. Para o analista de negócios é fundamental que o aprendizado e desenvolvimento dos requisitos obedeçam uma lógica parecida com a ilustrada no diagrama abaixo:

    A visão do negócio é a representação direta de todos os objetivos e metas, o que chamamos de requisitos do negócio. Todos os demais requisitos, independente do tipo ou nível de granularidade, devem derivar deles. Ou seja, devem mostrar seu *valor* – como apoiarão, direta ou indiretamente, a realização dos objetivos do negócio. Cada caso de uso, por exemplo, deve exibir de forma clara quais são os objetivos atendidos por ele. E estes objetivos devem ter uma ligação nítida com os requisitos de negócio maiores.

    Quando este conceito é bem implementado, a equipe consegue perceber com relativa facilidade o que é e o que não é prioritário em um projeto. No próximo artigo desta série falarei especificamente sobre valor e a priorização de todos os requisitos. Inté!

    .:.

    Observações

    1. Documentação! Palavrinha que causa arrepios, não? Chuto e sugiro que 80% dos artefatos gerados por um analista de negócios vá para o lixo tão logo tenha cumprido sua missão: facilitar o entendimento. Sua manutenção não se justifica na maioria das vezes porque: 1) É cara; 2) É muito frequente. Negócios mudam todo dia. É difícil manter documentos assim 100% sincronizados com a realidade. Acredito que para a maioria das organizações, um diagrama representando cada perspectiva (do Negócio, da Estrutura e dos Processos) seja suficiente. Mas, eu sei: cada caso é um caso.
    2. Não entendeu? Então você não passou sua infância ou juventude no início dos anos 80. Paciência. O “toli toli tolá” era cantarolado pelo Honolável Besoulo Japonês toda vez que ele dava um drible a la Neymar em seu arqui-inimigo, a Cobrinha Azul. Hehe… Ok, sei lá porque me lembrei disso agora. Cobra, Azul, eternamente driblada, Matrizes de Rastreabilidade… há um conjunto aqui… eu sei que tem…
    3. Abstract é outra foto que surrupio da Tanakawho.

  • ‘Seu’ Moreira e o Gerente com Dor de Dente

    O Moreira, ciente de sua ignorância sobre sistemas, projetos e afins, decidiu desde o primeiro momento que não acompanharia o desenvolvimento de sua ferramenta para ‘aumotação da força de vendas’. Passou a responsabilidade para seu sobrinho – é da família e é de confiança, o herdeiro que ele não conseguiu fazer por conta própria; E para o contador – funcionário fiel desde o dia da fundação da empresa. Os dois já fizeram vários “cursos de informática” (dois de 40 horas, para falar a verdade) e eram os únicos com autorização para mexer no micro da empresa. O sobrinho atendia solicitações que chegavam por email e mantinha o site de duas páginas da empresa. O contador controlava o livro-caixa, fechava a contabilidade e fazia a declaração de imposto de renda de todo mundo. Até dos vizinhos.

    Os dois receberam os primeiros módulos do sistema – para manutenção de cadastros (CRUD para os letrados), um mês após o prazo combinado. Gerente do projeto e um dos desenvolvedores fizeram a entrega. O gerente marcava a página de sua agenda com a fatura do mês. A anterior foi paga, apesar do atraso. Convenceram sobrinho e contador e depois o ‘seu’ Moreira com um pacotinho de modelos e um gráfico GANTT, o cronograma. Agora não tinha jeito. Ou eles viam alguma coisa do sistema ou “nem um centavo” sairia dali, como disse o Moreira. Cinco módulos de cadastros foram instalados no único micro da empresa. “Passa da hora de vocês comprarem o servidor e uma estação de trabalho, hem?”, pediu o gerente. O sobrinho disse que as cotações já haviam sido feitas e que o seu tio apenas esperava a real necessidade antes de fazer o desembolso. “E os micros para os vendedores, vocês já decidiram qual será?”. O contador falou que avaliavam três alternativas, mas não deixou a conversa prosseguir. Queria ver a entrega.

    Foram quatro horas de entrega e treinamento, duas além do previsto pelo gerente. Quando ele viu que a coisa ia se prolongar, ligou para o dentista e desmarcou a consulta, apesar da urgência: “Tem duas semanas que esse ciso não me deixa comer nem dormir direito”. Mas ele nem cogitou deixar o desenvolvedor fazendo a entrega sozinho depois que reparou que ele não era muito paciente nem muito bom com as palavras faladas. Gerenciou bem o risco. Até porque o ‘seu’ Moreira invadia a sala a cada meia hora: “e aí, novidades?”

    .:.

    Enquanto isso, entre uma discussão ou outra envolvendo MySQL, noSQL, ShitQL e coisas assim, a equipe tentava trabalhar. Todo dia tinha uma briga com o DBA, que não conseguia fazer valer o seu modelo. “Mas ele já foi homologado pelo cliente!”, gritava, arrancando gargalhadas. “Cara, o cliente não sabe nem o que é um banco de dados”, tentava explicar um desenvolvedor. O “clima ruim” contaminava até as “happy hours” que aconteciam de terça a sexta. Numa delas, quando parecia inevitável que o arranca-rabo descambaria para as vias de fato, o analista de negócios pediu demissão. “Ninguém merece”, choramingou. Na época ele já trabalhava por meio período no projeto do ‘seu’ Moreira. No restante do tempo ajudava os vendedores em atividades de pré-vendas. Sua decisão realmente não era reflexo dos 11 chopps, como torceu o gerente do projeto. Só voltou na empresa 10 dias depois, para fazer o acerto. Relutante, aceitou uma conversa de hora e meia com o desenvolvedor mais novo e o gerente para passar aquilo que não estava documentado.

    O gerente ouviu cético a promessa de que um novo analista seria contratado “asap”. Já aceitava, experiente que era, que teria que levantar ele mesmo os requisitos dos módulos de Mapa de Carga, Estoques e Vendas. Não sabia o que lhe doía mais, se as novas responsabilidades ou o dente de ciso.

    {continua}

    .:.

    Minha intenção original era casar o fim do causo do ‘seu’ Moreira com a estreia dos dois “Jogos dos 7 Erros”. Infelizmente, como vocês podem ver na agenda ali em cima, os eventos foram adiados para 16 e 17 de abril. O lado bom da história: vou poder trabalhar o causo com mais calma (e mais artigos).

    Preciso dizer que esta história específica, por ser antecipada aqui, não aparecerá mais nos “jogos”. Como tenho um bom estoque de causos, isso não é problema. Outra coisa importante a ser dita é que o exercício aqui proposto é diferente daqueles (7) que fazem parte do novo evento porque é aberto demais. Lá existirão temas, erros específicos. A história do ‘seu’ Moreira está repleta de enganos. Abaixo dos óbvios, que tem fins meramente ilustrativos e provocativos, existem aqueles que realmente desafiam analistas de negócios, gerentes e demais integrantes de uma equipe de desenvolvimento. Você consegue apontá-los? Alguns colegas participam da “oficina virtual” nesta thread do grupo AN.br. Caso interesse, entre. A casa é sua.

  • O que o ‘seu’ Moreira não Viu

    ou “Em TI, o que os olhos não veem o bolso sente. E como sente!“.

    Vimos lá no início do causo que o ‘seu’ Moreira repassou para o sobrinho e o contador a responsabilidade pelo acompanhamento do projeto. Em ‘tempo de proposta’, eles tiveram um único encontro com o analista da empresa que venceu a concorrência (por W.O., como vocês devem se lembrar). Hoje voltaremos exatamente para aquele momento, quando o analista solicitou um contato com os vendedores e não foi atendido.

    Seguindo uma dica que ele aprendeu com um colega que participou de um tal de FAN, o analista decidiu que utilizaria aquelas quatro horas na empresa do ‘seu’ Moreira para elaborar uma grande ‘fotografia’ de 2km de extensão por 2cm de profundidade. A visão ‘do todo’ era crucial naquele momento. Ele não se preparou para a reunião – nem sabia o ramo de atividades da empresa. E, como vimos no último episódio, ele se atrasou pra caramba para a única visita.

    O questionário aplicado, na base do improviso, deu origem a um diagrama rabiscado em uma folha A3. “A Toyota também usa A3, vocês sabiam?”, perguntou o analista para sobrinho e contador que não sabiam nada sobre a Toyota. Também desconheciam UML, a linguagem que teria sido usada na elaboração daquele estranho diagrama. “Mas dá pra entender, não dá?”, perguntava o analista após cada elemento rabiscado. “Aqui estão os vendedores e os clientes. Entre eles esta seta, que mostra o processo de vendas. Aqui tá o depósito e neste mini-diagrama de classes eu mostro como os seus produtos estão estruturados. Ah, o leite é matéria-prima de todos? Por que vocês não falaram antes? Mas é fácil, é só mudar essa seta aqui para mostrar que todos herdam tudo o que a gente definir para o leite, ok? Hã, você não entendeu? Esquenta não, depois eu explico melhor.”

    Sobrinho e contador ficaram encantados com a desenvoltura do analista: “Ele aprende rápido, né?”. Mas interrompiam o papo toda vez que ele puxava um gadget de última geração de sua chique mochila: “Você vê os emails aí no celular é? Nossa!!!”. O analista bateu uma foto do A3 com seu ultra-super-mega celular e enviou por email. “Como o projeto é para ontem, uma equipe já vai analisando lá o que a gente tá conversando aqui”. O que o analista não contou é que ele mandou o email para ele mesmo. Não tinha nenhuma equipe “de retaguarda” esperando pelas suas informações.

    Aliás, a equipe do projeto, no dia seguinte, resumia-se ao analista, seu chefe e o vendedor. “A proposta é para amanhã”, disse o aflito analista que, pelo andar da carruagem, sabia que ficaria com todo o trampo de elaboração. “Escreve a proposta técnica”, disse seu chefe, “que depois eu sento com o vendedor pra gente calcular o preço final”. Assim foi feito. Um “documento de visão / proposta técnica” de 10 páginas foi elaborado. O analista demonstrou através de um grande e colorido diagrama que existiam 5 grandes funcionalidades requeridas:

    • Elaboração da Agenda de Visitas
    • Mapa de Carga
    • Controle do Estoque dos Clientes
    • Venda / Faturamento
    • Relatórios Gerenciais Diversos

    Além disso, ele destacou que seriam necessários módulos para: cadastramento de clientes, produtos, vendedores, rotas, veículos etc.

    Após rápida negociação que resultou em um desconto de 27,5%, ‘seu’ Moreira contratou o projeto: Cinco meses de duração; Seis parcelas, sendo que a última só seria liberada após o aceite final do projeto. Imediatamente a empresa escolhida publicou 3 anúncios de vagas: 1 coordenador de projetos, 3 desenvolvedores ‘web’ e 1 DBA. Dez dias depois estavam todos reunidos com o analista para entender o projeto. Depois de fechado o negócio o analista havia agendado duas visitas para ‘coleta’ de requisitos. Foi apenas em uma, para “refinar o A3”.

    A3 que foi mostrado para os 5 novos integrantes da equipe. “Tá bom”, disse o coordenador, “mas cadê os requisitos?”. O analista falou que estava esperando a montagem da equipe e, principalmente, a contratação do coordenador para organizar as tarefas de ‘levantamento’. O mais jovem dos 3 desenvolvedores foi escolhido para ajudar o analista. Os dois mais experientes ficariam na empresa fazendo o ‘setup’ do ambiente e desenvolvendo um ‘framework’. O cronograma prometia a entrega dos módulos de cadastro para 30 dias. “Afinal”, justificou o analista, “os caras lá não têm sistema nenhum. Alguém vai ter que cadastrar tudo. Assim a gente ocupa o cliente e pode trabalhar em paz”. Um dos desenvolvedores falou que, “com o framework, a gente faz os CRUD tudo numa tarde”. Não fizeram.

    {continua}

  • Motivação, Parte 1

    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:

    1. O público-alvo;
    2. Seu benefício-chave (o valor que estamos prometendo para o cliente/usuário); e
    3. 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

  • Irritando o ‘seu’ Moreira

    As conversas que se desenvolveram a partir do cruel “Assassinato de um projeto pelo Covarde seu Moreira” não aconteceram aqui e sim no grupo AN.br. Em um futuro artigo desta ‘saga’ eu destacarei os principais pontos. Mas você não precisa esperar. Veja o papo e participe dele nesta thread. Hoje, brincando com a não linearidade do ‘causo’, conheceremos outros fatos relevantes além daqueles nem tanto assim, muito pelo contrário, ora pois.

    Como ficou entendido no episódio anterior, uma empresa foi contratada para desenvolver um “sisteminha de éss éff êi”, ou automação de força de vendas. Eles tiveram três dias (úteis!) para entender o problema, elaborar a proposta e negociar condições e restrições. Este que aqui rabisca tem o hábito de exagerar alguns pontos, exatamente para destacar absurdos. Mas já vivi situações mais draconianas que aquelas de alguns casos. Numa grande seguradora, por exemplo, já recebi uma demanda na tarde de uma bela (e ensolarada) sexta que deveria ser respondida na forma de uma proposta (“preço fechado, cara pálida”) na tarde da segunda-feira seguinte. Nossa área é repleta de gente que curte emoções fortes, adrenalina pura. Gente que não tem a menor noção dos riscos de suas demandas (ou propostas). Enfim… sigamos com a saga do ‘seu’ Moreira.

    A empresa que venceu a concorrência foi aquela única que insistiu na alocação de um analista de negócios para o entendimento do problema. Analista e seu superior imediato creditavam a vitória ao diferencial da colocação de um especialista no entendimento de requisitos. Na realidade, eles ganharam a concorrência por W.O.: as outras duas empresas convidadas não enviaram suas propostas no prazo combinado. E o Moreira tinha pressa.

    O analista, ciente do curto prazo, pediu um dia inteiro na empresa do Moreira. Queria fazer uma “imersão”. Mas acordou tarde; pegou um trânsito daqueles; se perdeu (“miolo da zona norte não é mole não, mano!”); e só chegou ao compromisso após o almoço. Se desculpou com o sobrinho (do Moreira) e com o contador e disse, confiante: “Tudo bem. Tudo o que eu preciso é de uma fotografia de 2km por 2cm do negócio. É fácil ‘tirá-la’ em 4 horas”. Os dois interlocutores ficaram olhando a mochila chique do analista, buscando por uma possível máquina fotográfica de última geração. “Não”, explicou o sorridente analista, “é só jeito de falar. Essa fotografia é uma visão de todo, sabe? Hoje não quero detalhes, apenas uma ‘visão panorâmica’ do problema de vocês. Então, vamos começar? Qual é o problema?”

    Vou poupá-los daquela lenga-lenga que parece caracterizar 8 em cada 10 projetos de software. Para possibilitar o acompanhamento pelos leigos e céticos, uma rápida descrição do que aconteceu entre o parágrafo acima e o que vem a seguir:

    • O analista de negócios levantou um monte de informações de maneira totalmente desestruturada;
    • O time reclamou um pouco, fingiu que entendeu e começou a codificar;
    • O gerente de projetos passava toda manhã atualizando o Project;
    • As tardes de segunda a quinta em reuniões para entender porque o projeto estava atrasado;
    • E as tardes de sexta explicando para o ‘seu’ Moreira as razões dos atrasos.

    Moreira, sempre acompanhado dos fiéis escudeiros sobrinho e contador, escutava as explicações com atenção. Há muito desistira de interromper o gerente de projetos para pedir explicações sobre termos enigmáticos. Anotava tudo e depois submetia a lista ao çábio* sobrinho. Lá pela 4ª ou 5ª reunião de justificativas não conseguia mais esconder a irritação. O que preocupava seus colaboradores: Moreira tinha pressão alta. Esfregava as ásperas palmas da mão como se quisesse arrancá-las. Estralava os dedos a cada dez minutos, o que sempre chamava a atenção do gerente de projetos. Era uma deixa para que ele avançasse na pauta, sempre em tom otimista. A relação se deteriorava a cada reunião. Mas o ‘seu’ Moreira sempre as encerrava da mesma maneira: “Tudo o que eu queria era dobrar o número de clientes visitados”.

    {continua}

    .:.

    O que é arriscado mas ao mesmo tempo muito divertido neste tipo de exercício é o fato do autor não ter controle total sobre o desenrolar da trama. Várias questões registradas em nossa conversa me pegaram de surpresa. No evento ao vivo, no “Jogo dos 7 Erros“, minha margem de manobra será bastante limitada. Cada exercício deve durar exatos 60 minutos. Por isso haverá um tema fixo para cada um deles. No causo do ‘seu’ Moreira podemos destacar dúzias de erros – a maioria tão óbvia quanto naquele jogo para crianças. Redigi assim para permitir que os participantes não perdessem muito tempo na identificação daquilo que realmente importa. Os ‘causos’ que serão levados para os novos eventos serão um pouco mais enxutos. Mas tão divertidos quanto este aqui.

    Me esqueci de dizer no primeiro episódio que a história acima se baseia num caso real. Claro que maqueei ramos de atividades, nomes e endereços para evitar que gente inocente morresse. De vergonha.

    * Aprendi a escrever çábio assim, com “ç”, com o Elio Gaspari. Existem sábios e çábios, né sabiá?