finito

Tag: Escopo

  • 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

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

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