Tag: Fun

  • ‘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}

  • 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.
  • O Problema com Harry*

    Harry era um coordenador de projetos. Vivia para resolver problemas. O último foi insolúvel: Harry bateu as botas; foi dessa para uma melhor; tá mortinho da silva. Ninguém percebeu ainda. Ele está em seu cubículo, silencioso como quase sempre. Debruçado sobre o teclado, parece dormir. A tela do micro exibe o gráfico Gantt que ele atualizava quando morreu.

    Jenifer apareceu para confirmar a reunião das 10. Notou que algo estava errado só na quarta vez que chamou Harry, tocando seu ombro. Pela temperatura do pescoço sacou que o cara estava realmente morto. Lembrou-se imediatamente da rodinha que se formou em torno da máquina de café logo após a reunião do dia anterior. Sentiu um frio na espinha quando recordou a jura que fez para meia dúzia de testemunhas: “Ainda mato esse $%&”. Deixou o cubículo se certificando de que ninguém havia reparado sua presença ali.

    Jenifer é analista de negócios. Os 5 meses e 18 dias de convívio com Harry foram, segundo suas próprias palavras, “um inferno”. Se arrependeu de ter sugerido a adoção de um modelo iterativo e incremental para o desenvolvimento do projeto. “Melhor seria ter ficado aqui apenas um mês, escrito do jeito que desse todos os casos de uso e me mandado para outro projeto”. Harry lhe roubou a ideia e fez um curso de 8 horas de ScrumMaster. Voltou com o certificado e algumas conclusões: “A ideia do Scrum é muito boa. Só não curti muito esse papo de ScrumMaster, Product Owner e coisa e tal. Vamos adotá-lo, mas eu seguirei sendo GP. E tenho dito!”

    Harry fazia questão de participar de todas as reuniões com o cliente. Jenifer funcionava mais como sua secretária do que como analista de negócios.

    TheTroubleWithHarry

    Arnie é um dos três programadores plenos (pero no mucho) alocados no projeto. Com espinhas no rosto e bonequinhos japoneses em sua mesa, vivia irritado com Harry. Reclamava do “clima opressivo” do projeto. Não suportava mais as 4 horas extras diárias e as manhãs de sábado trabalhando, coisa que Harry chamava de “esforcinho extra”. Algo que ele compensaria, dependendo do sucesso do projeto, “com uma bela feijoada no Bar Brahma. Por minha conta!”, prometia o falecido.

    Arnie nunca manifestava suas opiniões para o coordenador – tremia de medo dele. Aos pares sempre acusava as sugestões “malucas” e o risível domínio técnico de Harry: “O cara sabe de Java tanto quanto eu manjo de culinária peruana”. As piadinhas de Arnie nunca mereciam uma risada espontânea, mas todos os programadores concordavam com suas críticas.

    Passou pelo cubículo do Harry para perguntar, pela terceira vez, se a data de encerramento da iteração realmente mudaria. Todo mundo achava aquilo uma loucura e Harry nunca era conclusivo. A verdade é que nenhuma iteração até aquele momento havia respeitado o plano original (que previa ciclos de 30 dias). Arnie tremeu muito quando percebeu que seu silencioso interlocutor estava mortinho. Agachou e elaborou 100 planos para escafeder-se sem ser notado. Saiu engatinhando e entrou no cubículo ao lado, da gata Jenifer, simulando a busca pela lente de contato que ele nunca usou. Nem notou as cruzadas pernas torneadas de tão nervoso que estava.

    Eis que chega o Capitão, bufando. É o gerente da área comercial e já avisou que não toleraria mais reclamações do cliente. Esperava desde a noite anterior por uma versão atualizada do arquivo do ‘project’. O cliente falou que não pagaria mais nenhuma parcela se não visse uma “evolução” do projeto. Harry e Capitão acordaram que o envio do ‘project’ talvez funcionasse como calmante. Não sem antes discutirem, por 3 horas e 17 minutos, sobre os problemas do projeto. Harry dizia que o cliente não sabia o que queria. E reclamava que sua equipe era muito “júnior”. Capitão, entre um tapa e um murro na mesa, lembrava que nunca vira, em 30 anos de carreira, um projeto de software sem problemas. No ápice do papo, lá pelas 8 da noite, gritou para quem quisesse ouvir: “Se esse projeto não der lucro eu te mato, safado!”

    Boa parte da remuneração do Capitão vinha de um naco do lucro de cada projeto comercializado. Ou seja, há tempos ele vivia com a corda no pescoço, contas penduradas e um salário mínimo. A empresa resolveu que comissões ‘normais’ estavam apenas contribuindo para o aumento do prejuízo dos projetos. E concluiu que a participação nos lucros incentivaria maior colaboração da área comercial nos projetos, “gerenciando relacionamentos. Afinal, esses técnicos são muito ruins de papo”. Capitão bufou, acatou e enviou o currículo atualizado para 47 empresas.

    Capitão gritou uma, duas, três vezes. “Não é possível que agora esse @#$ resolveu dormir aqui!”. Com um safanão fez a cadeira girar, o que mostrou meia face do pobre coitado e morto Harry. O olho esbugalhado dizia tudo.

    Jenifer e Arnie aproveitaram o escândalo para dar e livrar suas caras: “Capitão, você matou o Harry?” A pergunta saiu em uníssono e em volume suficiente para ser ouvida em todo o andar. Logo estavam todos ali, pescoços sobre as divisórias do cubículo, rostos de espanto e comentários inteligentes sem champanhe nem cicuta. “Jura? O Capitão matou o Harry?”

    Ninguém gostava do Harry. “Mas matar o cara! Meldels… onde vamos parar?” As meninas choravam um choro nervoso. Os rapazes, com seus modernos celulares, espalhavam a nova para toda a agenda de contatos. Ninguém sabia o que fazer. Capitão estava estático, catatônico, com cara de bobo. Jenifer e Arnie ainda o fitavam, acusadores e aliviados.

    O ramal do Harry tocou. Identificador de chamadas: “Amorzinho”. Todos que estavam próximos trocaram olhares, esperando que um herói tomasse a iniciativa de atender ao chamado. Ninguém teve coragem e depois do 13º toque o telefone silenciou. Para tocar de novo 30 segundos depois. Identificador de chamadas: “Esse cara não tem mãe”.

    “Xi… agora é o freguês”, disse alguém.

    Capitão atendeu, mandando bala: “Ô Xerife, você sabe que mora eu meu coração, não?”. Silêncio constrangedor de dois minutos e meio. Todos sacaram que o Xerife, o cliente, desfilava seu repertório de impropérios nos acostumados ouvidos do Capitão. Do nada, o gerente comercial resolveu mudar o rumo da conversa: “Querido, por favor, me diz uma coisa: você mandou matar o Harry? Porque, veja bem, se foi você, eu gostaria que você soubesse que todos aqui consideraram a decisão mais acertada para que finalmente a gente possa estar providenciando a otimização de nosso processo orientado ao…” tum, tum, tum…

    Epílogo

    Foi no velório que todos ficaram sabendo que Harry não foi assassinado. Sofreu uma parada cardíaca fulminante. “Também”, disse Jenifer, “o cara se alimentava mal e não fazia exercício nenhum! Não aguentava um lance de escadas”. Arnie lembrou que havia dois meses que Harry parou de fumar: “Não adiantou nada.” “Pudera, o cara tava mascando 60 chicletes de nicotina por dia!”, assuntou outro. Capitão consolava o Amorzinho dizendo que Harry era o melhor coordenador de projetos que ele conheceu em 30 anos de carreira. “Pena que não suportou a pressão”.

    E Harry não conseguiu o que queria quando veio para a “Top Down**”, com o diabo ter. Ele queria era falar pro Presidente pra montar um PMO e ajudar toda essa gente que só faz sofrer…

    .:.

    * O drama acima foi levemente inspirado num dos melhores filmes pouco conhecidos do Mestre Hitchcock, “The Trouble with Harry” (1955), que aqui em Pindorama é tratado como “O Terceiro Tiro”. As imagens utilizadas neste artigo foram indevidamente surrupiadas da Internet.

    ** A “Top Down” é uma software house de última geração fincada no meio do potencial vale do silício tupiniquim, leia-se Vale do Anhangabaú. Sediará outros dramas, com certeza. Infelizmente, sem nosso querido Harry.

    Atualização em 3/Fev/10: As três batidas na madeira, dadas abaixo, não adiantaram muito. Eu deveria ter verificado anteriormente a coincidência com nomes, principalmente com a empresa. É preciso dizer que a Top Down do artigo acima, agora definitivamente fechada, não tem nada a ver com a empresa homônima sediada no Rio de Janeiro. Foi uma infeliz coincidência mesmo. E pelo meu descuido peço desculpas. Agora vou ter que inventar um novo nome para as futuras aventuras da trupe desenvolvedora.

    Lembrete: salvo engano, ontem foi o Dia dos Gerentes de Projetos. Eu não ia homenagear-nos (ainda me considero um) com um artigo sobre as “maravilhas” da última versão do PMBoK, né? Fica para uma data mais propícia (ou menos perigosa).

    Aviso: a história acima é pura ficção e bobagem. Qualquer semelhança com fatos, empresas ou pessoas de verdade deve ser mera coincidência. (3 batidas na madeira)

  • Estereotipinhos

    Existem usuários e usuários. Quem convive com eles sabe que cada um tem suas peculiaridades – suas necessidades e desejos, suas reclamações e chororôs, seus jeitos e manias, seus tiques e chiliques. Mas isso não nos impede de identificar e traçar alguns padrões, perfis, estereótipos e… Estereotipinhos!

    O analista de negócios mais esperto sabe que não pode colocar a mão no fogo por todos os requisitos que aprende. E as melhores pistas que ele tem para não se queimar são o jeitão e a postura dos usuários. Não, o analista não precisa virar o Doutor Cal Lightman (personagem de Tim Roth na série “Lie to Me”) – um cara que percebe mentiras e outras coisas simplesmente observando seus interlocutores.  Mas atenção e canja de galinha não matam projeto nenhum, certo?

    Este artigo não é (muito) sério. Ele pretende apenas apresentar alguns perfis de usuários que costumam criar probleminhas em projetos. E dar algumas sugestões para que os analistas evitem maiores acidentes.

    .:.

    Caetano

    CaetanoO usuário Caetano é carente. Passa eras esquecido em seu departamento Trancoso. A cada bimestre ele tenta receber um pouco de atenção, naquelas enfadonhas e inúteis reuniões com todo o escalão intermediário. Caetano só lida com processos de apoio (leia-se Despesas). Então só merece atenção quando a realização de seu backlog é uma obrigação. De vez em quando acontece. E lá vai o analista ouvir tudo o que o Caetano precisa.

    Caetano fala devagar, mas não para de falar. Parece que não precisa da pausa para respirar. E fala, fala e fala. Pede uma coisa, reclama de outras duas. Pede duas coisas, reclama de alguém genérico. Caetano adora abstrações e picuínhas. E mistura tudo em 45 minutos de um monólogo muito chato. Quando se aproxima dos ‘finalmentes’, Caetano desacelera: “Como vou saber o que estou pensando se não ouvir o que estou falando?” Suas frases ficam mais curtas e cada vez mais lentas. Até que há um intervalo que dura entre 5 e 10 segundos. Aí, num moroso (de) repente, Caetano condena toda a sessão de desenvolvimento de requisitos com apenas duas palavrinhas: “Ou não”.

    Ao analista resta: respirar fundo e ter muita paciência. Caetano é carente e acha que TI nunca lhe dá atenção (o que é a pura verdade). Suas demandas nunca são prioritárias. O analista deve evitar interromper o monólogo, para não correr o risco de ter um Caetano nervoso e irritado. E deve tentar entender o “ou não”, por impossível que isso pareça.

    Glória

    GloriaAh, a usuária Glória – uma novelista nata. Adora contar histórias (no meio de uma sessão de desenvolvimento de requisitos). Não, não o tipo de história que agradaria agilistas. Suas histórias são muito longas, verdadeiros épicos. E intrincadas demais. Glória normalmente comanda um departamento “global” – atinge todo mundo. RH, financeiro ou algo do tipo. Parece que todos na empresa gostam da Glória. Alguns por obrigação. Mas seu Ibope é alto: ela é realmente muito simpática. Calorosa até na hora de expressar seus requisitos.

    Glória complica demais e é voluntariosa. Aprendeu e ensina que tem mais valor aquele profissional que não se limita a reportar problemas. Ela adora apresentar soluções. Praticamente cada requisito que ela pede já vem acompanhado da solução ideal. Mas suas soluções, quando não são ingênuas demais (“Nossa, mas colocar esse campinho na tela é tão fácil!”), são nonsense de tão complexas  (“Então vamos colocar a Deborah numa caixa de papelão e entregá-la, como que por acidente, na casa do galã da novela”).

    Pobre analista: você deve ser muito sutil ao pedir para a Glória que ela se limite a dizer “o que ela precisa”. Explique, gentilmente, que o “como” é responsabilidade de outra patota, outra plateia. Diga que, se for o caso, ela pode até participar das sessões de brainstorming que definirão a melhor solução. A equipe técnica o odiará por isso. Ninguém se esquece que Glória já derrubou coordenadores, arquitetos e até diretores no passado.

    Azevedo

    AzevedoAzevedo é um usuário azedo. Para ele, tudo e todos estão sempre errados. E ai de quem discordar. Azevedo vive colado no alto escalão – tem “moral”.  Apesar de seu job description não formalizar e ninguém pedir, Azevedo sempre se mete nos temas estratégicos da empresa. E parece ter resposta para tudo. Ele é muito culto, um intelectual de chapéu panamá. E gosta de exibir a riqueza de seu vocabulário quando expressa seus requisitos.

    Azevedo detesta ser entrevistado – particularmente para o desenvolvimento de requisitos. Ele não fala, mas indica que os entrevistadores nunca estão a sua altura. Ele gostaria mesmo é de ser entrevistado pelo diretor de TI, CIO ou equivalentes. Como isso nunca é possível, ele prefere mandar os requisitos por escrito. O analista também ficaria satisfeito com isso, se ele não soubesse que nada substitui o contato cara a cara. Enfrentar o chato do Azevedo é inevitável.

    Ilustríssimo analista: acalente-se. Todo ofício tem seus ossos. E toda empresa tem seus azevedos. Evite o confronto porque ele só será resolvido em outra instância. Ou seja, *nunca* discorde do Azevedo. Mas também não precisa baixar a cabeça para ele. Registre com capricho os requisitos. Não pule nenhuma etapa da cerimônia que o Azevedo eventualmente exigir. E torça para que esses encontros sejam breves.

    Dunga

    DungaMuitos analistas gostariam que o usuário Dunga fosse aquele amiguinho da Branca de Neve – quietinho e muito bonzinho. Não é. Dunga é um ranheta – vive zangado e enfesado. Mas é diferente do Azevedo. Dunga é paranóico, tem mania de perseguição. Acha que todo mundo quer derrubá-lo (o que nem sempre é mentira). Mas Dunga é muito importante para a empresa. Como mostra resultados, não será fácil tirá-lo de lá. E Dunga sempre tem muitos requisitos para apresentar.

    Requisitos do tipo “desconfiado”. Dunga costuma pedir um monte de coisa que só sua paranóia justifica: dezenas de senhas, centenas de relatórios. E lê nas entrelinhas de cada pergunta do analista alguma crítica ou complô. Dunga não tem paciência nenhuma. Nem os modos educados do Azevedo. Dunga esbraveja e, em situações extremas, usa até palavras que não podem ser publicadas neste espaço. Dunga mete medo. Em seus adversários e, infelizmente…

    … nos tristes analistas: que ouvem desaforos que não merecem. É muito importante manter a calma e a compostura. Faça o Dunga entender que você, prezado analista, é apenas o mensageiro. E está ali só para entender as necessidades dele. Mas não tente ganhar o raivoso com elogios ou mimos. O paranóico verá indícios de conspiração até nisso. Demonstre isenção, imparcialidade. Mas sinta-se a vontade para interromper uma entrevista toda vez que o Dunga passar dos limites. Afinal, ninguém merece chilique de gente mal educada, né?

    Outras Figurinhas

    O espaço é curto e o elenco de estereotipinhos é quase infinito. Listo abaixo outras figurinhas relativamente comuns que, dependendo do projeto, podem ser tão ou mais perigosas que os colegas apresentados acima:

    • Mikaela: usuária um tanto lenta e sem um pingo de autonomia. Seu chefe, sem tempo para nada, sempre a joga nessa enrascada: passar os requisitos para o chato do analista. O problema é que ela não sabe nada e decide menos ainda. Analistas: peguem o chefe no corredor ou elevador. Rende mais.
    • Maikol: usuário que não acerta uma! 90% de seus requisitos são falsos. Os outros 10% não têm valor nenhum. Não é má vontade, pelo contrário: é excesso de vontade. E muita falta de conhecimento. Analistas: confirmem de alguma forma os pedidos do Maikol antes de passá-los adiante. Mas tentem não queimar o cara, ok? Ele é gente fina.
    • Maike: é um super-usuário, curioso e fuçador que nem te conto. É pior que a Glória na hora de propor soluções, porque ele realmente acha que sabe tudo sobre .Net, Java, SQL e o ângulo correto para colocação da rebimboca da parafuseta. Maike é um destruidor de soluções e um martírio para analistas de negócios. Analista: coloque seu melhor técnico para baixar a bola desse cara. Senão você está perdido.
    • Mikey: é o engraçadinho da turma, faz piada com tudo e todos. Requisito-piada? Pois é, existe. E é sempre de mau gosto. Mas esses caras têm sua utilidade quando um workshop de requisitos está carrancudo demais. Mas é bom não dar muita trela. Senão eles roubam a festa (e o seu precioso tempo).
    • Mixel: é uma figura, um fenômeno. Excelente funcionário e amigo de todo mundo. O problema é que ele vive se metendo em confusões. Em projetos, suas trapalhadas aparecem mais aos 45 do segundo tempo, quando apresentado para uma solução: “Nossa, eu pensei que não tivesse nada disso. Eu queria outra coisa!”

    .:.

    Observação: Os usuários serão vingados! Qualquer dia publico “Estereotipinhos (do outro lado)”. Garanto que eles são piores que o pior usuário que conhecemos.