finito

Tag: Engenharia de Requisitos

  • FAN – Ano III

    Como foi antecipado, a estreia do novo formato do FAN acontecerá neste final de semana, em São Paulo. Além do conteúdo programático, mexi também na estrutura do treinamento e no visual do material de apoio. Destaco neste artigo as principais modificações e as justificativas para elas.

    O programa para Formação de Analistas de Negócios é um eterno trabalho em desenvolvimento. Aliás, eu acho que todo programa de treinamento é ou deveria ser assim. Sempre encontraremos algo que pode ou precisa ser melhorado. Durante os dois primeiros anos o conteúdo foi diferente em todas as turmas, para desespero do pessoal que confecciona as apostilas. A primeira grande alteração se deu após a quinta edição, quando dobramos a carga horária. A principal reclamação que recebíamos via fichas de avaliação era: “Puxa, a gente gostaria de exercitar suas sugestões”. Esticamos a duração do treinamento para poder incluir os módulos práticos.

    Alteramos também o material didático. Além das apostilas, os alunos também recebiam material de apoio para execução dos exercícios. Não bloquinhos de rascunho, como de costume, mas modelos que, apesar de extremamente simples, apoiavam o aprendizado ao reforçar os conceitos apresentados.

    Depois veio “The Back of the Napkin”, de Dan Roam (Portfolio, 2008), e com ele um novo método para o trabalho de modelagem de negócios. O núcleo das sugestões, baseado no uso da UML e sua extensão EPBE (Eriksson-Penker Business Extensions), foi mantido. Mas o método do pensamento visual facilitou tanto o aprendizado quanto a aplicação prática e imediata da modelagem de negócios.

    Só em agosto de 2009 eu resolvi “congelar” o conteúdo do FAN. Queria testar sua estabilidade em turmas abertas e fechadas. O “descanso” e relativo distanciamento do material foi proveitoso. Há pouco mais de um mês, quando o reencontrei, sabia exatamente o que alterar.

    A sequência do treinamento é madura, está bem resolvida. Mas slides envelhecem! Cerca de 70% dos slides têm a idade do FAN! De tanto apresentar o material, sempre com alguma variação, aprendi uma separação mais adequada entre o que vai na apresentação e o que é falado. É uma reengenharia gostosa de fazer, cheia de surpresas. Tem momentos em que 5 slides vão para o lixo. No momento seguinte, 7 novos slides berram para ver a luz. Ou seja, o tamanho da apresentação utilizada seguirá parecido: imenso.

    Aproveitei o esforço para “dar um tapa” no visual do material didático. Se os slides já eram minimalistas pra caramba, agora eles ficaram mini-minimalistas. Influência viciante de duas obras: “Presentation Zen”, de Garr Reynolds (New Rider Press, 2008) e “The Presentation Secrets of Steve Jobs”, de Carmine Gallo (McGraw-Hill, 2010). Treinamentos como o FAN são muito cansativos. Dois dias inteiros consecutivos fazem com que os alunos percam muita coisa, principalmente ao final dos dois dias. E a gente sabe que bullets, cores, efeitos e muita ladainha escrita e falada cansam. É claro que um treinamento assim tem muito pouco em comum com os imbatíveis keynotes do Steve Jobs, por exemplo. Mesmo assim, as duas obras citadas ajudaram a desenvolver um material de apoio que: i) Cansa menos; ii) Registra aquilo que é estritamente fundamental; iii) É de fato *Visual*; e iv) Foge das perigosas e feias armadilhas do Powerpoint e afins. Estou muito satisfeito com o produto final. Tanto que em breve, finalmente (!), vou liberar uma versão light na área de downloads deste site e também no Slideshare. Só peço que aguardem um pouquinho, até a conclusão do teste de verdade que farei neste final de semana.

    A distribuição dos exercícios também ajuda a tornar o evento mais produtivo e agradável. Distribuídos de maneira homogênea e com duração fixa, eles acabam ditando um ritmo. Sim, tô surrupiando aqui uma prática muito eficaz dos projetos guiados por métodos ágeis. O ritmo constante, estou apostando, deve tornar os exercícios ainda mais produtivos e eficazes. E, de quebra, os alunos mergulharão um pouco mais no modelo iterativo e incremental de desenvolvimento. As versões anteriores do FAN também tinham essa intenção. Mas existiam módulos muito extensos de teoria, seguidos de dois ou três exercícios consecutivos. Consegui encontrar um formato mais equilibrado. E sem nenhum prejuízo para a parte teórica. Ok, chega de blablablá. Que venham os testadores! Inté.

    .:.

    “Pô Paulo, que sacanagem! Se você tivesse avisado a gente teria aguardado essa nova versão…”

    Pessoal, a AUI! (angústia pelos upgrades infinitos) veio para ficar. Você acaba de gastar aquela bela grana num celular novinho e daqui a uma semana  aparecerá um melhor e mais feito pra ti. Será sempre assim. No caso fo FAN não se preocupem porque: i) Todo o material estará disponível para vocês, através de nosso grupo AN.br; e, ii) Estou programando dois eventos de atualização que serão disponibilizados para todos os 2.000+ participantes das turmas anteriores do FAN. Um deles será “na faixa”, “vasco”, “grátis”. Aguardem!

  • 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.

  • 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á?

  • O Assassinato de um Projeto pelo Covarde Seu Moreira

    O seu Moreira era feliz e não sabia. Seus bem cuidados produtos eram distribuídos em quase toda grande São Paulo. Para tanto contava com uma motivada equipe de 40 vendedores. E um processo de venda bem simples. Cada vendedor tinha sua caminhonete e um estoque calculado para durar o dia inteiro. Apenas 5% das vendas não aconteciam com pronta entrega. Seus clientes eram as padocas e pequenos mercados de bairros. O vendedor visitava o cliente, conferia seu estoque e fazia reposição do que era necessário. Emitia manualmente a nota fiscal, enquanto saboreava o cafezinho gratuito e quente. Os fregueses melhores & maiores recebiam visitas semanais. Os outros, quinzenais. O negócio do Moreira ia bem, sem grandes problemas, há mais de 20 anos. Até que aconteceu aquela festa de final de ano na ASSPRONG. Seu Moreira não era de festejos. E se arrepende até hoje de ter participado daquele.

    A festança, como sempre, era uma chatice só. Esquentando na mão a única taça de espumante que se permitiu, seu Moreira já ensaiava uma saída estratégica pela esquerda quando foi interrompido pelo VP de Marketing e Relacionamentos da ASSPRONG, o Zé Bragantino. “Moreira, meu querido, deixa eu te apresentar o Welldonedson, diretor de vendas da cervejaria ACME”. O sujeito sorria de orelha a orelha e tinha os ralos louros cabelos domesticados por gumex. Amenidades trocadas com a usual superficialidade e logo o papo foi para os negócios. Imediatamente perceberam a semelhança entre os seus. A base de clientes era diferente – a ACME vendia principalmente para bares e restaurantes. Mas o modelo de distribuição e atendimento era idêntico. Mas a prosa ruim pendia para o encerramento rápido. Até que Welldonedson revelou um número que deixou o Moreira embasbacado e embaraçado: seus vendedores atendiam uma média de 80 clientes por dia. “Como isso seria possível?”, pensava o assustado Moreira. Quando não chovia e o trânsito não estava tão infernal, seus vendedores conseguiam visitar, no máximo, uns 30 fregueses.

    Welldonedson seguia contando gogó para um Moreira que só fingia ouvir enquanto calculava e pesquisava o mistério da produtividade absurda dos vendedores da ACME. Criou coragem e quis saber sobre os recursos que municiavam os vendedores do Welldoneson. Tinha os carros modernos, mas eles não significam muita coisa numa cidade onde a velocidade média é de 20km/h. Tinha também o GPS, mas o Moreira sabia que o feeling de seus vendedores para o trânsito era mais eficiente que qualquer engenhoca moderna. Além disso, todos tinham tatuados no cérebro seus roteiros de visita, atalhos e pontos de fuga.

    Moreira já ia perder a esperança de descobrir o segredo até que Welldonedson citou o maravilhoso sistema de automação de força de vendas que eles implantaram havia um ano e meio. “Sales Force Automation, ess éff êi”, foi como ele falou. Uma maravilha, uma teteia, uma joia 100% customizada para as características muito específicas da ACME. “Atrasou um ano e custou uns 2 milhões, mas valeu a pena. E o senhor sabe, né seu Moreira, todo projeto de alta tecnologia é assim mesmo”. Moreira concordou com um leve movimento da cabeça. Ele não sabe o que é projeto de alta tecnologia e muito menos “que eles são assim mesmo”. Se despediu sem jeito e deixando a taça de vinho na mão de Welldonedson que disse “até mais” já procurando pelo próximo ouvinte-vítima.

    Foi um final de semana inteiro de noites mal dormidas. Seu Moreira não conseguia parar de pensar na possibilidade de duplicar a produtividade de seus vendedores. Sua linha de raciocínio era simples: dobro de visitas = dobro do faturamento. Poderia até mesmo expandir sua área de atuação. E sem contratar mais ninguém? Parecia bom demais para ser verdade. Mas, pôxa, se a ACME pode, por que o seu Moreira não poderia?

    Na segunda-feira, logo cedo, Moreira chamou o contador e o sobrinho para uma conversa. Eram os dois que mais entendiam desse negócio de computador. Ambos ficaram surpresos. Moreira nunca havia demonstrado entusiasmo algum com coisas assim. Aliás, parecia odiar qualquer “recurso tecnológico que promete acelerar toadas”. Mas agora parecia apaixonado pela ideia de ter um sistema que dobraria suas receitas. A produção não seria problema. Se fosse o caso, disse Moreira, eles fariam com que o 2º turno fosse permanente e não apenas em ocasiões especiais. Nada o distraia ou tirava seu foco: ele queria falar sobre o sistema. “Quem faz esse tipo de coisa?”.

    Dois dias depois eles já recebiam 3 empresas que se candidataram para desenvolver o sistema. Gente de terno e gravata e um linguajar que fazia o Moreira interrompê-los a cada duas frases: “Java? Java é um cliente nosso, lá no Bixiga”. O sobrinho assumiu as negociações. As propostas deveriam chegar até o final da tarde da próxima sexta. Uma das 3 empresas sugeriu a visita de um analista de negócios para entender melhor os requisitos. Sobrinho e contador o receberam na tarde de quarta-feira. “Entrevistar os vendedores? Hmm… não vai dar não. Estão todos na rua, vendendo né? Mas pode perguntar que a gente sabe tudo sobre o negócio.”

    Nove meses depois, cinco além do prazo combinado entre as partes…

    Os vendedores não estavam na rua como deveriam. Estavam todos em reunião com o Moreira, tentando explicar os motivos de não conseguirem mais visitar nem 20 clientes por dia. “O programa é complicado demais, seu Moreira”, insistia Jojoaquim*, o funcionário mais antigo. “A gente tem que conferir e digitar todo o estoque do freguês toda vez, porque dá diferença”, explicava Mustafá. “E a emissão da nota então, seu Moreira. É lerda demais. Quando a gente fazia na mão era mais rápido” disse Magrão, com sua tradicional voz de choro.

    O sobrinho do Moreira tentou culpar os vendedores mas engoliu um parágrafo inteiro quando viu a cara do tio e se lembrou do tanto que ele protegia sua equipe. O contador só fitava, ameaçador, o coitado do analista de suporte que representava a empresa que tinha desenvolvido a aplicação. O moleque, ainda com espinhas na cara, não escondia o constrangimento e o medo. Coitado, ele não tinha nada a ver com aquilo. E explicou que tinha corrido tudo bem no treinamento. E que a aplicação estava lenta, mas ele desconfiava que era culpa do Windows e que um pouco mais de RAM talvez resolvesse a questão. Moreira não entendia nada do que era falado. Entendia menos ainda o fato dos seus vendedores estarem visitando menos clientes depois dele ter gasto “os olhos da cara, ora pois” em um projeto que visava exatamente o contrário.

    .:.

    Observações:

    1. A imagem utilizada, “1918 Farm Auction“, foi colocada no Flickr por Dok1. Eu não sabia que ‘Acid Test’ era um termo tão antigo.
    2. O texto acima deve ajudar a mostrar o tipo de ‘causo’ que serve como base para os exercícios dos 2 Jogos dos 7 Erros, eventos que acontecerão no próximo mês.
    3. Aquele * deve mostrar que não se trata de um erro de digitação. O pai do Jojoaquim era gago. E o escrivão era um brincalhão.

  • Eventos: Os Novos e o Velho

    Direto ao ponto: estão liberadas as inscrições para 3 eventos em São Paulo, dois novos e o velho conhecido FAN.

    O Jogo dos 7 Erros para Líderes de Projetos é um dos novos. É uma oficina (workshop) com duração de um dia e formato um pouco diferente. Brincamos com o velho jogo dos 7 erros – aquele onde devemos descobrir diferenças entre duas imagens. Na oficina cada erro aparecerá em uma situação diferente. E cada situação tratará de um tema desafiador e recorrente na vida dos líderes e gerentes de projetos.

    É um jogo mas está longe de ser brincadeira de criança. Os exercícios, elaborados individualmente, são de médio ou alto graus de dificuldade. E são baseados em situações reais. Cada situação terá duração de uma hora e será encerrada com um bate-papo entre os participantes.

    A outra novidade tem o mesmo formato: O Jogo dos 7 Erros para Analistas de Negócios. Não é requerida participação no FAN. Mas é desejável que os participantes tenham experiência em Análise de Negócios.

    Os dois jogos estão sendo lançados em caráter “Beta”. Ou seja, trata-se de um teste realmente. Daí o precinho especial (R$ 199 para clientes da Tempo Real Eventos e R$ 249 para estreantes). Além disso, cada evento contará com a presença de 5 convidados especiais. Na linha de uma famosa revista de informática, talvez estejamos inventando uma nova profissão: Crítico de Oficinas! Será esta a função dos convidados. Se você se interessou pelo desafio, tente sua estréia aqui, deixando um comentário crítico / criativo sobre os novos eventos. Se for aprovado, a vaga é sua.

    .:.

    E o velho FAN dá as caras novamente, rumo ao seu 3º ano de vida. Será a 18ª turma em São Paulo – com certeza um dos recordes da Tempo Real Eventos. Legal que se trate de um velho (na nossa área 3 anos pode ser muito tempo) que ainda está sabendo envelhecer. Esta turma marcará a estréia da versão 1.1 do programa. Em  números absolutos, trata-se da 4ª versão diferente desta oficina de 14 horas.

    Aliás, vale lembrar que é o mesmo evento que será apresentado pela primeira vez em Brasília, nos dias 9 e 10 de abril.

    Críticas, dúvidas ou sugestões podem ser colocadas aqui mesmo, na forma de comentários. Ou através do email: [email protected]

    Desde já agradeço. Inté!

  • Prioridades 2: As Origens

    Sequência do papo sobre “Prioridades & Banalidades“.

    Se uma organização não sabe o que quer e não tem a mínima noção do caminho que pretende trilhar, então não podemos esperar que a equipe de projeto saiba dizer o que é prioritário em seu trabalho. Os ventos mudarão diariamente e o barco vagará a esmo. Até afundar, que é o que costuma acontecer com muitos projetos, particularmente de TI.

    Nas turmas do FAN eu costumo recomendar o seguinte: se a estratégia, se o valor do projeto não está claro para clientes, patrocinadores e usuários, então é melhor nem começar o trabalho. Se não atacar o quanto antes as dúvidas e ambiguidades, que provavelmente são fruto de sérios problemas de comunicação, a equipe estará assimilando riscos que dificilmente terá condições de administrar quando o projeto ganhar ritmo.

    Mas é curioso que até em empresas que apresentam um processo de planejamento aparentemente robusto as equipes tenham dificuldade de definir suas prioridades. Em dado momento as organizações elaboram e refinam seu portfólio de projetos. Em algumas o horizonte é de um ano ou mais. É a estratégia da empresa, sua Visão, que norteia o processo e ajuda a definir os projetos prioritários. Seria de se esperar que as mesmas informações que guiaram esta tomada de decisão sejam utilizadas pela equipe de projeto. Surpreendentemente, não é o que acontece em diversas organizações.

    Em algumas há a definição de que esse tipo de informação é sensível e merece sigilo. O que desemboca no engano de achar que uma equipe não precisa saber o que o negócio ganhará com o projeto. Pode parecer absurdo, mas já vi clientes e usuários urrando: “Você não precisa saber disso!”. Como não? Quem pensa assim ignora que os desenvolvedores tomam dezenas ou até centenas de decisões por dia. Decisões que afetam o negócio de uma forma ou de outra.

    Em outras organizações – que interpretam de maneira diferente o mantra “Informação é Poder” – os problemas com a definição de prioridades são outros. A equipe não é municiada com requisitos do negócio simplesmente porque não pergunta por eles. São diversos os fatores que ajudaram a criar essa alienação. Um dos principais, desconfio, é a mentira que diz que “tudo é para ontem”. E, se a pressa é grande, por que cargas d’água um analista perderia tempo tentando entender as motivações do projeto? Eles vão direto ao que interessa, aos requisitos que brotam e lotam listas. O problema é que esses requisitos, desprovidos de sentido, dizem muito pouco sobre o caminho que a empresa espera tomar. E fica simplesmente impossível que a equipe saiba dizer o que é prioritário.

    Sabe o que é estranho e paradoxal nessa lenga-lenga toda? É que normalmente o entendimento dos objetivos do negócio não rouba nem 30 minutos de um analista de negócios. O não entendimento costuma roubar muito mais.

    .:.

    Novamente surrupio uma foto da Tanakawho, “Indecision at the last moment“. O surrupio é legal!

  • Prioridades & Banalidades

    É curiosa e perigosa uma dificuldade que vejo por aí com uma certa frequência: Equipes de projetos não sabem ou não conseguem dizer o que é prioritário. O escopo de projetos de software é tratado como um monolito. E a iniciativa vira um jogo de 8 ou 80 – de tudo ou nada. Segundo analistas e desenvolvedores, seriam os usuários os principais responsáveis pela falta de flexibilidade. Algo como: “se eu estou pedindo, então é prioritário”. Todos os requisitos¹ são recebidos e tratados como iguais. É difícil que algum tipo de projeto possa evoluir bem com tamanha rigidez.

    A situação é curiosa porque não reflete nosso comportamento cotidiano. É natural que as pessoas considerem opções e definam prioridades quando vão fazer qualquer aquisição que comprometa uma fatia de seu orçamento. Pense na compra de um carro novo, por exemplo. Você define o que é fundamental, como marca, modelo, potência e cor. Elege itens importantes como o trio elétrico, tipo de combustível, airbag etc. Por fim, lista os opcionais que você só comprará caso o bolso permita, como o MP3 player com entrada USB, DVD para as crianças etc.

    Software é muito maleável. Qual o motivo, então, para tratá-lo de forma tão inflexível? Desconfio que a culpa não seja só dos usuários. Aliás, desconfio que eles não tenham culpa nenhuma nesta questão. Não na maioria das vezes.

    Quando utilizamos um processo que prevê a “coleta” (sic²) de todos os requisitos nos momentos iniciais do projeto, implicitamente estamos dizendo para os usuários: “fale agora ou cale-se para sempre”. Parece natural que os usuários tentem se lembrar de tudo. Que eles tentem entuchar de *tudo* naquilo que chamamos de escopo. Assim como é natural a reciprocidade. Ou seja, se eles só tiveram uma chance para falar, também darão apenas uma chance para a equipe entregar *tudo* o que eles pediram. Mas, apesar de ser irritantemente comum, o sintoma acima foi apresentado de maneira simplista porque explica apenas uma parte do problema.

    Muitos analistas e desenvolvedores se comportam como “tiradores de pedidos”. Vão conversar com os usuários e se limitam a registrar, vírgula por vírgula, *tudo* o que eles pedem. Se desconhecem o negócio, seus objetivos e o problema em questão, os analistas não apresentam condições de criticar o que está sendo pedido. Acontece que em algumas empresas os analistas não têm o direito de criticar. Será que um dia eles serão cobrados por terem o dever de criticar?

    A visão crítica e criativa aplicada ali, no nascedouro dos requisitos, é que permite uma priorização realmente eficaz. E esta visão só existe quando há um bom entendimento do negócio.

    .:.

    Como o papo é longo e anteontem eu prometi artigos mais curtos (e frequentes), o papo seguirá em posts futuros. Inté!

    Observações

    1. Caso seja de sua preferência, leia “histórias” (ou User Stories) onde escrevi “requisitos”.
    2. O termo “coleta” é muito ruim. Dá a impressão de que os requisitos estão lá, prontinhos e maduros, como tangerinas no pé. Na realidade nós *aprendemos e desenvolvemos* requisitos, sempre com os usuários.
    3. A imagem utilizada, Arch, é da Tanakawho – talento que libera suas obras no Flickr com licença Creative Commons.

  • O Mundo Ágil precisa de Analistas de Negócios?

    Na realidade, a dúvida mais frequente em nossos papos e debates é: Como o Analista de Negócios (AN) se ‘encaixa’ em um projeto guiado por um método ágil? Acontece que possíveis respostas para essa questão obrigatoriamente nos levam para a pergunta do título: Projetos ágeis precisam de AN’s? Temo que não são poucos os que responderiam com um rápido e sonoro: Não!

    E não é muito difícil entender suas razões. Primeiro, como Roman Pichler lembra em “Agile Product Management with Scrum”¹, nenhum livro “clássico” derivado do Manifesto Ágil cobre aquelas etapas iniciais de um projeto que podem se beneficiar da atuação de um AN. Ken Schwaber, em “Agile Project Management with Scrum” (2004), Kent Beck, “Extreme Programming Explained” (1999) e “Crystal Clear” (2005) de Alistair Cockburn – todos partem de uma visão ou pauta* (Product Backlog) previamente definidos. Pouco ou nada falam sobre aquele momento em que equipe e organização definem ou, melhor dizendo, começam a definir o que precisa ser feito.

    Pichler não cita, mas “Agile Project Management – Second Edition” (2010) de Jim Highsmith e até “Utilizando UML e Padrões” (2008) de Craig Larman apresentam a mesma restrição. Este último não o faz de maneira explícita, como é comum em obras baseadas no Processo Unificado (PU). Mas isso é assunto para outro artigo. O que nos interessa aqui é a confirmação de que não só o AN, mas a própria Análise de Negócios é em parte ignorada por pessoas e obras que ajudaram a fundar, definir e consolidar o Movimento Ágil.

    Por favor, não entenda que a análise de negócios é apenas uma fase no início de um projeto. Utilizada corretamente em um modelo de ciclo de vida iterativo e incremental, ela existirá durante todo o projeto. E até depois dele. O que tento destacar aqui é que, nas fases iniciais de um projeto, a análise de negócios é caríssima. E o é porque é ela que ajuda a definir uma clara visão dos objetivos do negócio ou do produto. E, como diz Jim Highsmith², “na ausência desta clara visão, a natureza exploratória de um projeto ágil resultará numa espiral infinita de experimentações”. No popular: “para quem não sabe para onde vai, qualquer caminho serve”.

    Não é minha intenção tentar explicar essa grave omissão. Já ouvi muitas pessoas dizendo que a Análise de Negócios seria, por si só, um projeto específico. Não concordo. Todo projeto de software depende, mesmo que em graus diferentes, de um conjunto de métodos e práticas que: 1) ajudam a definir o que precisa ser feito; e 2) ajudam a garantir que o que está sendo feito realmente atende aos objetivos fixados (e respeita as restrições colocadas). A esse conjunto foi dado o nome “Análise de Negócios”. E eu não entendo como um projeto para a construção ou implantação de um sistema de informação poderia prescindir dele.

    Um segundo motivo pelo qual os AN’s parecem “ignorados” pelo Mundo Ágil é a forma como este, em seus vários sabores e formas, conclama e exige uma participação mais efetiva dos usuários e demais partes interessadas que não fazem parte do “time de construção”.

    Na proposta conhecida como eXtreme Programming (XP ou XisPê), por exemplo, uma prática requer o usuário literalmente sentado ao lado dos desenvolvedores. Costumo brincar que, quando um bom AN se deparar com um usuário que tenha total disponibilidade para ficar alimentando um projeto com seus requisitos, deveria recomendar sua sumária demissão. É brincadeira. Mas procura iluminar um ponto crítico: quem, nos dias de hoje, pode abandonar seus afazeres cotidianos durante todo um projeto? É claro que se trata de uma prática de difícil aplicação. Assim como deve ser óbvio que, quando possível e em determinados tipos de (pequenos) projetos, ela deve ser adotada. Não questiono sua eficácia. Apenas desconfio de sua viabilidade.

    O Scrum é outra proposta derivada do Mundo Ágil, que se caracteriza ultimamente pelos altíssimos índices de popularidade. Ele concentra suas sugestões nos aspectos gerenciais de um projeto. E define a existência de 3 “entidades” principais na comunidade de um projeto: o ScrumMaster, o Time e o Dono do Produto (Product Onwer). Este seria o representante de todos os usuários e teria, segundo Ken Schwaber (um de seus “criadores”), duas grandes responsabilidades: 1) Maximizar o ROI (Retorno sobre o Investimento); e 2) Gerenciar a Pauta (Product Backlog). Roman Pichler, no mesmo título citado anteriormente, sugere uma revisão das duas principais preocupações que devem guiar o Dono do Produto. Elas seriam: 1) Definir a Visão; e 2) Entregá-la!

    Repare como a sugestão de Pichler se encaixa perfeitamente na definição da análise de negócios que apresentei acima: 1) Ajudar a definir o que precisa ser feito; 2) Ajudar a garantir que a entrega realmente satisfaz os objetivos colocados. A mudança está apenas no tom, no tamanho da responsabilidade: o Dono do Produto realmente define a visão e é o principal responsável por entregá-la**. A análise de negócios ajuda.

    Então podemos dizer que o Dono do Produto (DP) elimina a necessidade de um Analista de Negócios (AN)? Em minha opinião, quase nunca! Citarei Pichler novamente, listando aquelas que seriam as responsabilidades de um DP:

    • Pesquisa de mercado;
    • Planejamento do Produto;
    • Análise de Negócios (!);
    • Gerenciamento da Pauta (Product Backlog);
    • Descoberta, Descrição e Priorização de Requisitos;
    • Gerenciamento de Versões (Releases);
    • Acompanhamento da evolução do projeto;
    • Gerenciamento do orçamento;
    • Relacionamento com clientes, usuários e outras partes interessadas; e
    • Participação nas Reuniões Scrum.

    Gerentes de projetos devem ficar um tanto “encafifados” com a listinha acima. Mas outro dia eu falo com eles. A questão aqui é: até que ponto é possível que apenas uma pessoa realize (bem!) todas as atividades listadas acima? Repare ainda como questões operacionais, táticas e estratégicas são misturadas, causando a falsa impressão de que seriam equivalentes. E lembre-se que existem pessoas que ainda cogitam a utilização de um DP que não tem 100% de disponibilidade de tempo para o projeto!

    Não é por acaso que vários trabalhos recentes – dentre eles o já citado Pichler e também “Scrum Product Ownership”³, de Bob Galen (2009) – afirmam que o trampo do DP é “o mais pesado em um projeto Scrum” (Galen). Portanto, não deve causar espanto nem revolta o fato de alguns autores começarem a sugerir uma Equipe do Dono do Produto. Pichler chega a citar um exemplo mostrando uma equipe formada por “dois analistas de negócios, um arquiteto chefe e um assistente de projeto”, além do próprio DP, é claro.

    É importantíssimo salientar que o DP continua sendo uma única pessoa. O que muda com a sugestão acima é a aceitação de que o DP não dá conta sozinho de tudo o que ele precisa fazer. Mesmo em projetos considerados pequenos. Sendo assim, ele sempre poderá montar um time próprio. Sinceramente, eu não entendi o que um “arquiteto chefe” fez naquele exemplo do Pichler. Mas, tendo em vista a lista de responsabilidades acima, é muito fácil supor a ajuda que AN’s podem dar para os DP’s. Sendo mais direto: todo o trabalho operacional listado (descoberta e descrição de requisitos; análise de negócios de uma maneira geral; pesquisas e parte do relacionamento com outras partes interessadas) pode ser atribuído exclusivamente para AN’s. Além, claro, do apoio na execução de atividades de caráter tático (como o gerenciamento da pauta).

    Eu entendo e até tento compartilhar o temor que muitos demonstram quando veem uma sugestão como essa. Mais pessoas, mais intermediários, podem comprometer a qualidade da comunicação. Nunca vou dizer que esta não é uma preocupação relevante. Acontece que os problemas causados por um DP sobrecarregado podem ser consideravelmente piores. Imagine, por exemplo, o início de uma iteração sem uma pauta fechada; ou então com uma pauta repleta de requisitos (ou histórias) incompletos, ambíguos ou mal estruturados e porcamente priorizados.

    Se ambos os cenários, comunicação e sobrecarga, são ruins e indesejáveis, mas devemos escolher um, qual seria melhor administrado? Qual representa menores riscos?

    Conclusões (?)

    Reparou nas datas de publicação das obras citadas? Pensou na base histórica que temos desde o dia 13 de fevereiro de 2001, data de ‘nascimento’ do Manifesto Ágil? Desconfiou que a consolidação de nossos métodos de experimentação (desenvolvimento) é também uma experiência? Por isso tasquei um ‘?’ ali no subtítulo. Porque conclusões, nesta altura do campeonato, ainda são muito perigosas. E relativamente frágeis. Daí a quantidade de debates e embates que vemos por todo canto. De um lado, ainda vemos muita resistência em mudar (o que configura uma boa piada). De outro, muitas vezes, a falta de humildade para admitir que ainda estamos todos aprendendo.

    Por isso, caros AN’s (e GP’s), não é preciso ter medo do ‘monstrinho’ Ágil. Todo projeto seguirá apresentando necessidades e consequentes atividades, independentemente do processo, metodologia ou ‘modinha’ utilizada. Todo projeto seguirá tendo uma etapa onde definimos o que precisa ser feito. Assim como todo projeto seguirá precisando de líderes.

    O que não pode significar, de forma alguma, que você AN (ou GP) possa baixar a guarda e ignorar tendências fortes, verdadeiras, viáveis e inevitáveis como o Movimento Ágil. E o SEMAT (?). E o Flu? E 2012?? E o Flamengo e a Terezinha???

    Desconfianças (!)

    Foi um bom mineiro, Guimarães Rosa, quem disse: “Sei de nada não… Mas desconfio de muita coisa”. Quem dera eu tivesse as desconfianças do Rosa. As minhas, no assunto em questão, são:

    • Não vejo mais com bons olhos a alocação de um AN para desempenhar o papel de Dono do Produto. Cheguei a sugerir isso algumas vezes. Peço desculpas e retiro minha sugestão. O DP deve ser de fato uma pessoa do negócio (ou, em algumas situações, o Gerente do Projeto).
    • Em projetos guiados pelo Scrum, o AN deve fazer parte do Time do Dono do Produto. Em muitos projetos, bastará 1 (um) AN. Seu par, na maioria das atividades, será o próprio DP ou um integrante do Time.
    • Corpos de conhecimentos vão incorporar cada vez mais práticas ágeis. Não adiantará muita coisa se seus espíritos (Princípios) não forem seriamente questionados.
    • AN’s (e GP’s) que já se deparam com projetos ágeis ou desconfiam (ou desejam!) que eles estejam em seu horizonte próximo, deveriam priorizar o estudo de obras como aquelas listadas abaixo, em detrimento até mesmo do BABoK (por razões já explicadas aqui).
    • Opa, quase me esqueci. A resposta é: Sim, o Mundo Ágil precisa de Analista de Negócios.

    Bibliografia

    1. Agile Product Management with Scrum
      Roman Pichler. Addison-Wesley (2010).
      Obs.: Tomei por base uma versão preliminar do livro, um Rough Cut. Seu lançamento está previsto para 5/mar/10.
    2. Agile Project Management – Second Edition
      Jim Highsmith. Addison-Wesley (2010).
      Obs.: Já disponível.
    3. Scrum Product Ownership
      Bob Galen. Draft v1.3 (2009).
      Obs.: A versão final, independente, já está disponível via Lulu.

    Observações:

    A foto utilizada neste artigo, “Danger: Keep Clear“, é do PSD, surrupiada legalmente no Flickr porque liberada como Creative Commons (by).

    * A sugestão do termo “Pauta” como alternativa para “Product Backlog” deve ser creditada para o colega Leandro Mendonça. Muito obrigado, meu caro. Tenho testado o termo com um surpreendente índice de aceitação.

    ** Antes que me batam: O DP é o principal responsável pela entrega no sentido de que ele deve ser accountable (aah! palavrinha maldita). No popular: é o dele que estará na reta em caso de problemas com a entrega do projeto. Ok? Então guardem as facas, please!