Blog

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

  • Sobre Legados e o Incêndio Nosso de cada Dia

    Eu pagaria para ver estudos mais recentes sobre o rateio do orçamento de TI em médias e grandes empresas. Lá no já distante século passado era mais ou menos padrão a destinação de 70% ~ 80% do total das verbas para a manutenção das operações. Desconfio muito que este número esbarre hoje nos 90% ou 100%. Projetos novos e upgrades, que um dia mereceram algo entre 20% e 30% do orçamento total, atualmente ou são bancados pelas áreas de negócios ou simplesmente postergados. Não por acaso o Windows XP, por exemplo, ainda predomina em várias organizações¹. Alguns podem dizer que a nova política é reflexo da falta de confiança na organização de TI como um todo. Não estão de todo errados. Mas não tocam nas raízes do problema.

    O tema começou a me chamar a atenção quando percebi que vários participantes do FAN não eram analistas de negócios (AN’s) de fato, mas luxuosos atendentes de help desk. Seu dia-a-dia não é o apoio a novos projetos mas sim o tratamento de demandas de manutenção em sistemas. Por favor, não estou dizendo que demandas de manutenção não mereçam a alocação de AN’s. Algumas poucas, que de fato representam mudanças no negócio, justificam isso. Acontece que a grande maioria delas, independente do tipo ou porte do negócio, refere-se exclusivamente aos sistemas. Pior, são fruto de sistemas de baixíssima qualidade técnica.

    O imenso e incomensurável backlog de manutenção é o inferno de um sem número de departamentos de TI. Ao que tudo indica, muitos acreditaram que os AN’s representariam uma boa resposta. Caro engano. Tão dispendioso quanto aquele de um famoso instituto que registra “recomendações” numa famosa publicação tupiniquim: em um de seus últimos artigos, “ele” falou que estruturas de projeto e de manutenção não precisam ser separadas. E que tal divisão poderia resultar em acidentes. Céus!

    Quando projetos e manutenção começam a concorrer pelos mesmos recursos, e dado nosso “tudo é para ontem”, é claro que a manutenção – a necessidade “indriblável” de apagar de incêndios – sempre prevalecerá. Resumindo: se a empresa nutre uma mínima preocupação com seu futuro, deveria ter uma unidade que cuide exclusivamente de novos projetos. E é aqui que os AN’s podem provar seu valor e justificar seus custos.

    .:.

    Mas, como antecipei lá nas categorias deste artigo, eu não quero falar apenas sobre a análise de negócios. Quero aproveitar a oportunidade para tocar n’outro tema caro e meio raro (por aqui): arquitetura. Já acreditei que SOA (Arquitetura Orientada a Serviços) era uma excelente resposta à crescente demanda por flexibilidade e agilidade. Bom, ela segue excelente. Mas está longe, muito longe de ser uma resposta universal. Muitos daqueles sistemas que conhecemos como “legados” são tão feios, frágeis e gambiarrados que impedem que o “botox” SOA surta algum efeito. Daí que de uns tempos pra cá resolvi ressuscitar um conselho daquele mesmo instituto que critiquei acima: “aposente 2 ou 3 sistemas legados por ano. Ponto.”

    O conselho é anterior às ondas EAI (Enterprise Application Integration) e SOA. Mas a cada dia se torna mais necessário e urgente. O fato é que há um imenso abismo entre a arquitetura tecnológica de vários sistemas legados e as demandas atuais. A ploriferação de modernos canais digitais e a crescente pressão que eles excercem sobre aplicações antigas justificam a incorporação desse discurso de urgência. E é importante notar que não estou falando apenas de coisas de museu como Cobol², Oracle Forms, Delphi, Visual Basic, Fox ou Clipper. Tudo o que nasceu na primeira geração da Internet deve ir para o lixo. Devemos aceitar o fato de que nossos primeiros sites e aplicações Web, mesmo aqueles com “apenas” 5 ou 6 anos de vida, serviram para aprendizado. Mas hoje são pesadíssimas âncoras que impedem nossa evolução. Cada centavo gasto em sistemas antigos (feios, frágeis e gambiarrados) é centavo jogado fora. Mesmo que o centavo seja contabilizado em rubricas chiques como SOA, BPM, BI e afins.

    A aposentadoria de aplicações de negócios está longe de ser uma coisa trivial. São raríssimas as empresas que utilizam um processo de gerenciamento do ciclo de vida de sistemas³. Nós desenvolvedores só falamos, através de nossas mágicas metodologias, do ciclo de vida de projetos. Pouquíssima ou nenhuma atenção é dada ao sistema entregue. Até o dia seguinte ao término do projeto, quando aquele sistema vira “legado” e um novo foco de incêndio a ser combatido diariamente.

    .:.

    Auren Hoffman escreveu um excelente artigo sobre “Ser Bom em Matar Coisas“. Um bom líder de TI deve saber hora e forma de matar (ou aposentar) seus sistemas. Como já falei demais, guardarei “hora e  forma” para futuros artigos. Inté!

    .:.

    Observações:

    1. O colega Saulo Arruda citou, num comentário lá no Graffiti, que uma grande empresa de Telco ainda demanda projetos em ASP (não .Net) com uso incondicional do Windows 2000 e IE6. Falou também de uma montadora com a mesma arquitetura. Qualquer coisa feita em ASP deveria ir para o lixo incondicionalmente. E escrever projetos novos em ASP é o mesmo que “tentar apagar incêndios com etanol”, para surrupiar e adaptar um antigo dito de Fred Brooks (utilizado em outra situação, é claro).
      Pedindo licença aos letrados, tentarei explicar aos leigos porque ASP (Active Server Pages) é uma das coisas mais medonhas e perigosas já inventadas em nossa área. Pensem num texto qualquer escrito de maneira desestruturada e acidental em três dialetos distintos, todos misturados. Três dialetos mais ou menos assim: a língua de participantes do BBB, a linguagem cifrada que a geração Y usa em sites de relacionamento mais um manuscrito original de um Jack Kerouac bêbado. ASP é assim. E na mão de programadores eXpertos vira poesia pura.
    2. Há quem diga que Cobol se modernizou. Tem também aqueles que defendem que ainda não inventamos nada para substituí-lo em grandes corporações (o que me faz pensar se Google, Amazon e afins são pequenas). De qualquer maneira, como não vejo a carinha dele (Cobol) há muito tempo, deixo a dúvida no ar.
    3. Para falar a verdade, só conheço uma proposta formal de processo que prevê o gerenciamento do ciclo de vida de sistemas. Ele atende pelo nome EUP (Enterprise Unified Process) e foi criado por Scott Ambler. Sim, podemos dizer que é um irmão bastardo (e ainda não reconhecido) do RUP.
    4. A imagem utilizada, Tändsticka, é do brandbild e foi liberada como CC-by, por isso está aqui.
  • 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á?

  • Obrigado pela Informação que Você NÃO me Deu!

    Subtítulo: Relevância, Concisão e Simplicidade na Comunicação Empresarial

    Autor: Normann Kestenbaum, pós-graduado em administração de empresas pela FGV. Sócio da Baumon, onde presta consultoria para grandes empresas.

    Editora: Elsevier / Campus (2008).

    Do que se trata: Comunicação empresarial. No popular, um pequeno (108 páginas) grande guia para todo tipo de conversa que rola em uma organização.

    A quem se destina: Todo mundo. Claro, todo mundo que conviva de alguma forma em empresas e outros tipos de organizações.

    Dê de presente para:

    • Líderes e gerentes de projetos
    • Analistas de Negócios
    • Analistas de Sistemas
    • Todos os chatos que não conseguem transmitir uma simples ideia em 5 minutos ou linhas
    • CIO’s, gerentes e afins

    Contra-indicações: Nenhuma.

    Prós:

    • Texto leve e agradável.
    • Coerente – Conciso e objetivo.
    • Bem fundamentado, apesar da curta bibliografia (apenas 9 títulos citados).

    Contras:

    • Como em praticamente todo título nacional, falta um índice remissivo.
    • E alguns gráficos são muito ruins. Mereciam melhor trato.

    Um trecho (escolhido aleatoriamente entre aqueles que destaquei com um marca-textos):

    Outro ponto sobre a concisão que merece comentários é a percepção errônea de que apresentação é a parte mais importante de um encontrou ou o único elemento importante a preenchê-lo. Muitas vezes uma pessoa tem 30 minutos para fazer uma exibição, ocupa integralmente esse tempo e é obrigada a ir embora porque seu tempo expirou. E o que pensa o lado de lá? Quais são suas sugestões e contribuições? Para mim, é na troca de idéias que o encontro acontece de fato. Portanto a regra é ser o mais breve e objetivo possível na apresentação, de forma a deixar o máximo de espaço de tempo possível para uma saudável troca de ideías e opiniões.

    Uma citação:

    É importante ter distanciamento para olhar o jogo inteiro, uma visão panorâmica que permita traçar estratégias. Poucos conseguem virar esta chave.
    Garry Kasparov, ex-campeão mundial de xadrez.

    Uma piada:

    Kestenbaum surrupiou o trecho a seguir de uma matéria da Exame (jul/2005), que por sua vez surrupiou o tema de “Por Que as Pessoas de Negócios Falam como Idiotas” (apresentado abaixo). Trata-se de um exemplo de como não falar nada usando muitas palavras:

    Precisamos adotar as melhores práticas. Mas com foco no cliente? É claro! Sem isso perderíamos nossa vantagem competitiva, afetando o bottom line no longo prazo. Mas, se não nos alinharmos às stakeholders, vamos deixar de estar agregando valor ao negócio.

    Trilha de estudo para quem quer mergulhar no tema:

    1. Por Que as Pessoas de Negócios falam como Idiotas
      Brian Fugere, Chelsea Hardaway & Jon Warshawsky
      Editora BestSeller (2007).
    2. The Back of the Napkin – Solving Problems and Selling Ideas with Pictures
      Dan Roam
      Portfolio (2008).
      Extensão: blog Digital Roam
    3. Presentation Zen: Simple Ideas on Presentation Design and Delivery
      Garr Reynolds
      New Rider Press (2008).
      Extensão: blog Presentation Zen

    Prováveis extensões da trilha (ainda não lidas / testadas):

    • Blink – A Decisão num Piscar de Olhos
      Malcolm Gladwell
      Rocco (2005).
    • Confessions of a Public Speaker
      Scott Berkun
      O’Reilly (2009).
      Extensão: blog do autor.

    .:.

    Observações:

    • Como prometido, inicio aqui uma série de artigos sobre Biblioteca Básica e Trilhas de Estudos. Prometo a publicação de pelo menos uma trilha por mês.
    • Os títulos citados na trilha ou como prováveis extensões merecerão artigos específicos. Só não seguirei uma ordem pré-fixada para não tornar a série muito chata ou repetitiva.
    • As trilhas não são estáticas nem se pretendem fechadas. Qualquer sugestão será muito bem vinda. A única coisa que garanto é que só vou recomendar títulos que eu tenha lido e, quando for o caso, testado.
  • 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.