O dia em que me tornei desnecessário

Vamos começar com uma história, mas dessa vez real:

Era uma quente terça-feira de verão em 2011. Estou em uma sala de reuniões em um edifício da av. Paulista. O evento, ou melhor, a cerimônia é a review da sprint sete de um projeto para uma instituição financeira. Na review o time de desenvolvimento apresenta o resultado do trabalho da última sprint (período de tempo dedicado ao desenvolvimento de uma parcela definida do sistema) para os clientes. Éramos onze pessoas à mesa, divididos da seguinte forma:

  • Cliente: 
    • Uma gerente de projetos
    • Dois especialistas em sistemas do cliente
    • Três clientes finais (quem vai usar o produto)
  • Fornecedor: 
    • O Scrum Master
    • Eu (agile BA/PO/whatever)
    • Três desenvolvedores (o time tem seis, mas como a review foi no cliente e não temos uma perua, não trouxemos o time todo). 

A mesa estava assim:

Copy-of-handoffs2

O primeiro fato interessante foi que os clientes (verdes) e os desenvolvedores (vermelhos) se sentaram frente a frente sem estímulo algum da nossa parte. 

Os desenvolvedores começaram a sua apresentação, iam passeando entre telas que atendiam aos padrões de layout do cliente, realizando operações que haviam sido selecionadas na última planning quando de repente uma faísca se acendeu e os clientes finais começaram a fazer perguntas e comentários e a conversa começou a rolar solta. Fiquei assistindo.

Notei que nós, “os cinzas”, que costumávamos dominar essas reuniões, ditar ritmo e assunto, estávamos quietos e só abríamos a boca quando era realmente útil para a discussão.

Notei também que o vocabulário usado pelos desenvolvedores era totalmente orientado ao negócio, não havia necessidade de tradução.

A coisa ficou realmente interessante quando o cliente final lembrou-se de necessidades importantes que estavam foram da sprint e, conseqüentemente fora a release que se aproximava.

Sabemos que isso acontece, nem todo o planejamento do mundo consegue evitar mudanças. As metodologias de gerenciamento de projetos lidam com a mudança de diferentes formas. No caso do Scrum, quando algo importante para a release é descoberto, simplesmente atrasamos a release, mas claro que ninguém gosta de atrasar uma release, se for feito, que seja o mínimo possível (uma sprint). 

A base do meu trabalho de Agile BA/PO/whatever é entender tanto do negócio quanto de como o sistema está sendo construído e em condições normais me debruço junto ao cliente final para descobrir uma forma de atender à necessidade da forma mais barata, ou seja, aproveitar ao máximo os serviços já existentes no sistema.  O que fiz nesse caso? Muito pouco.

O time de desenvolvimento fez uso do conhecimento do negócio e os clientes finais fizeram uso do seu conhecimento do sistema e chegaram às soluções em tempo recorde e com muita eficácia.

Nós “os cinzas” ficamos, novamente, só dando úteis pitacos aqui e ali e é claro, sobrou para o analista de negócios atualizar a documentação (que parece cada vez menos necessária em um ambiente assim, sendo útil apenas para a construção do manual do usuário e para apoiar o QA externo). 

 

Claudiobr_scrum_2

 

O mais interessante foi que se estamos falando da sprint sete e nossas sprints têm dez dias úteis. Falamos em aproximadamente 105 dias corridos, três meses e pouco.

Deixando de lado o fato extraordinário de se entregar uma quantidade considerável de funcionalidade em um período inferior a cinco meses dentro de critérios rigorosos de arquitetura e layout do cliente, e pasmem – em outsourcing – nosso uso do Scrum teve outro mérito impressionante: Em muito pouco tempo temos um time de seis desenvolvedores capazes tanto de entregar a solução técnica quanto de compreender e atuar sobre o domínio do problema.

Eu gostaria de poder mensurar financeiramente o valor disso, pois além dos ovos de ouro (código rodando), desenvolvemos a galinha dos ovos de ouro (o time).

Chegamos nesse ponto com base em três pilares. O primeiro pilar é o fato do Scrum tratar o que eu chamo de “a entidade time” como centro, como os “porcos”, responsabilizando o time pela entrega e fazendo com que os desenvolvedores fiquem frente a frente com os clientes finais a cada sprint. 

Isso reduz as distâncias, os preconceitos e as dúvidas e cria empatia. Desenvolvedores e clientes finais se conhecem pelo primeiro nome e um dia, acabam conversando no corredor e se sentando próximos à mesa de reuniões por pura afinidade.

O segundo pilar foi o fato de refinarmos o time. Como dizem “o Scrum não resolve os problemas para você, mas ele deixa eles bem visíveis”. Com reuniões diárias, divisão das tarefas e uso do Kanban fica muito claro e tangível quem está fazendo um bom trabalho e quem está fazendo corpo mole.

Como administrador de empresas estudei meios de avaliar o desempenho de profissionais e até hoje não encontrei nada mais justo do que o Scrum. Não vou me alongar aqui sobre esse assunto, mas em suma, não são necessárias mais do que duas sprints para saber se o profissional é “porco” ou não.

Não houve tirania nem decisões unilaterais. Os desligamentos eram justificados e demandavam poucas explicações. Notei que os times preferem ser menores e melhores no lugar de serem maiores e piores. Nosso cliente entendeu a importância desse filtro, aceitando ficar com menos pessoas do que o contratado durante algumas sprints.

O terceiro pilar, que tem mais a ver diretamente com o papel do Agile BA/PO/Whatever é a aplicação da tabela de entrega de valor:

Claudiobr_scrum_3

Apresento essa tabela em minhas palestras e cursos. Ela serve para deixar claro que, apesar de nos projetos onde existe um intermediário entre o time de desenvolvimento e o negócio (como um analista de negócios), um lado NUNCA deve ser alienado em relação ao outro.

O analista de negócios é o responsável pelo domínio do problema, contudo, o time deve estar sempre a par e deve ser sempre consultado. O time é responsável pelo domínio da solução, contudo, o analista de negócios deve estar sempre a par e sempre ser consultado.

A magia do desenvolvimento iterativo é que essa interação ocorre o tempo todo, tanto nas cerimônias, como uma planning, quando no meio da sprint. 

Lembro que neste mesmo projeto eu estava no cliente quando recebi uma ligação de um desenvolvedor me consultando sobre uma mudança na forma de atender a um requisito. A conversa durou dois minutos, mas estreitou os nossos laços, permitiu que eu conhecesse melhor a solução e gerou um consenso que dura até hoje.

Em suma, devemos reduzir a barreira entre quem pensa em valor e quem pensa em entrega, mesmo quando as responsabilidades estão bem definidas.

Vou chutar, mas se você trabalha (ou quer trabalhar) com desenvolvimento ágil aposto que quando você teve o primeiro contato com a teoria algo tocou o seu coração, algo pareceu muito lógico e você ficou louca(o) de vontade de ver acontecendo na prática.

Bom, comigo foi assim. Quando a ficha caiu, fiz de tudo para fazer acontecer. Interessante como há coisas que conhecemos apenas na teoria, mas que caem muito bem nos nossos ouvidos. Intuímos que elas sejam boas, possíveis e desejáveis, quase como fé.

A maior parte das coisas que se encaixam nesse grupo atualmente na minha vida profissional tem a ver com desenvolvimento enxuto de software (Lean Software Development). 

Ando namorando com os conceitos “lean” desde o tempo de SENAI (afinal, isso começou na indústria), mas tenho que confessar: eu não havia me ligado no fato de que eles tinham tudo a ver com desenvolvimento de software e acabei trazendo os vícios dos processos industriais arcaicos para o desenvolvimento. 

A ficha caiu quando recentemente passei a ler os Poppendiecks, que trouxeram os conceitos para o desenvolvimento de software e acompanho as experiências do mundo real do Luiz Claudio Parzianello/@lcparzianello (Agile Business Analysis) e do Rodrigo Yoshima/@rodrigoy  (gerenciamento de produtos com Kanban), fico muito inclinado a colocar em prática, afinal de contas, a sensação de que existe muito, mas muito desperdício no nosso trabalho é grande.

Um dos pontos centrais da produção enxuta é eliminar o desperdício. O desperdício ocorre nos processos corporativos de muitas formas. As que eu vejo mais facilmente ao meu redor são “estoque” e “passagem de bastão”.

Um estoque é algo que você guarda para usar no futuro (que pode ser próximo ou não). Algumas pessoas podem argumentar que estoque é algo bom, afinal, você está preparado para variações na demanda (pense em uma loja com um bom estoque de serpentina antes do carnaval).

Contudo, é preciso lembrar que cada real que você investe no estoque de qualquer coisa é um real que você não investiu em outra coisa. Enquanto não é “vendido” ou “usado”, o estoque é literalmente dinheiro parado. Dinheiro que poderia ser usado em outra coisa. A engenharia de produção está sempre de olho na gestão dos estoques porque o financeiro está sempre em cima.

Sobre estoques, deixo apenas a reflexão: “será que investir em escrever detalhadamente o máximo possível de casos de uso o projeto/produto mesmo muito tempo antes de serem de fato usados pelo desenvolvimento vale a pena?”. Bom, isso é assunto para outro artigo, hoje gostaria de falar sobre a passagem de bastão.

A passagem de bastão (ou handoffs) ocorre quando existem intermediários dentro do processo. Sempre que um intermediário intervém, existe um gasto e um risco. O gasto é o tempo destinado à comunicação e o trabalho do intermediário em si. O risco está justamente na comunicação que se for incorreta, gera o efeito “telefone sem fio” que gera efeitos devastadores.

Claudiobr_scrum_4

 

- Na imagem acima, cada passagem de bastão tem um custo de tempo (e horas do profissional) e um risco de comunicação. Eles só podem ser compensados pelo valor que o intermediário agrega. 

Pensando em custos, tudo fica pior quando a comunicação precisa ser de mão dupla, como no processo de desenvolvimento abaixo:

 

Claudiobr_scrum_5

 

A cada pequena dúvida surgida no desenvolvimento, um pedágio caro precisa ser pago, tanto em tempo quanto no risco de problemas na comunicação.

Telefone-sem-fio

E então, acabamos com todos os intermediários? Claro que não, eles (nós) existem por uma razão, existem quando o valor que agregam é superior ao tempo gasto e o seu custo. É um cálculo de ROI.

Para ilustrar, lembro que uma vez montamos um diagrama de atividades particionado que ilustrava o processo cobrindo do surgimento de interesse por parte de um cliente até a instalação do produto. O processo passava por nada menos do que quinze partições e após análise, apesar de várias melhorias necessárias, todas as quinze traziam mais valor do que custo.

Um equívoco freqüente nas discussões sobre metodologias de projetos é o fato de vermos o mundo como algo estático, então alguém pergunta “quais são os papéis ideais em um projeto assim ou assado?” e alguém (até pouco tempo eu também) responde: “esse, esse e aquele”.
Ocorre que a importância dos papéis muda conforme a carruagem anda e precisamos levar isso em conta. 

A vida é movimento. O mundo não é estático.

Os analistas de negócios, que são intermediários, são importantes nos projetos de TI? A resposta é sim, claro, e vem condicionada por um “quando”.
Na minha experiência, o grande momento do analista de negócios em um projeto iterativo e incremental é no começo e vai decrescendo conforme um grande time é desenvolvido.

 

Claudiobr_scrum_6

 

Como visto acima, segundo o Lean, o trabalho no momento “B” acontece de forma muito mais eficiente do que no momento “A”, contudo, sem o analista de negócios dificilmente se chega ao momento “B”.

Importância do analista de negócios no momento “A”:

 

Claudiobr_scrum_7

A imagem acima representa o resultado de uma pesquisa informal que fiz junto a desenvolvedores com os quais trabalhei. A pergunta era simples “Você acha que eu contribuo para o projeto? De que forma?”.

Sim amigo analista de negócios (Agile BA/PO/whatever), você precisa trabalhar para poder desaparecer ao longo do tempo. Se você conseguir isso, estará fazendo um ótimo trabalho e você sabe que sempre existe um projeto no momento “A” te esperando ansioso.

 

28 ideias sobre “O dia em que me tornei desnecessário

  1. Parabéns Claudio!Foi excelente ler essa tua experiência de vida e ver que eu me encaixei em vários relatos seus.Abraço e continue assim.

  2. Mas é claro que eu acredito nisso! A maturidade do time x necessidade do analista de negócios, isso é fantástico.Mas minha posição continua sendo, que o pensamento "Lean" tem de ser comprado por todos, senão o time sofre, o cliente sofre, todos sofrem. (A velha história do meio-scrum, meio-waterfall)Parabéns pela conquista :)

  3. Muito bom Kerber. É exatamente assim que acontece…algumas vezes rola até um ciuminho do cliente qd este já está intimo da equipe e a comunicação entre ambos flui, mas sabemos que isso é um fator bastante positivo, e é nessa hora que já mergulhamos nos próximos projetos.

  4. Parabéns a toda equipe e por mais que tenha se tornado desnecessário (rsrsrs) fico feliz por isso assim como você também ficou pois tiveram excelentes motivos para tal feito, e mais contente por você ter compartilhado esta experiência fazendo com que todos do SDC colha bons frutos daqui pra frente :). É nóis!!

  5. Excelente post! Ou melhor, excelente capítulo de livro! rsrsrsConheço muitos analistas que vão justamente na contramão, querendo "monopolizar" a informação e acabam tornando-se um câncer no projeto. Praticamente um "momento A" crescente. Mentes pequenas, resultados pequenos.Abraço.@helbertm

  6. Já que compartilho na prática essa experiência, gostaria de parafrasear alguns pontos, também para reflexão (com contexto de mudança de AN no projeto – vale outro post):1- Acredito que o AN se torne "quase desnecessário" em entrega final de release e não "desnecessário" como está no título, se questões finais de negócio passaram desapercebidas (o que ocorreu neste projeto), a entrega final da release é responsabilidade de todos, ou seja também do AN. Concordo plenamente e é excelente essa compreensão do time, agora para tomar certas decisões relacionados a consolidação de uma nova regra "que apareceu de última hora" o time sente mais segurança com o apoio do AN.Outra questão…2 – Peguei esse trecho "Sobre estoques, deixo apenas a reflexão: “será que investir em escrever detalhadamente o máximo possível de casos de uso o projeto/produto mesmo muito tempo antes de serem de fato usados pelo desenvolvimento?”. Bom, isso é assunto para outro artigo, hoje gostaria de falar sobre a passagem de bastão."-> Realmente vale outro post, concordo que especificar demais algo que seja incremental pode gerar muito mais retrabalho e certamente desperdício. Todavia vou apresentar um cenário um pouco diferente. O AN sai do projeto 3 dias antes da entrega da Release 1. Depois é ele quem fará o Planning da Release 2 (Release 2 com somente 2 Sprints). Em um caso como esse é mais custoso para a empresa e desgastante para o cliente rever o assunto de novo. Dessa forma e especificamente em casos similares, acredito que uma especificação completa desses 2 Sprints seja mais econômico, ou seja escrevê-los detalhadamente. Abs,

  7. @todos, pessoal, fico muito feliz que o artigo tenha agradado. Espero também que ele tenha inspirado algumas pessoas lembrando que é sim possível desenvolver software em um ambiente agradável onde os envolvidos estão dedicados a fazer um bom trabalho, a aprender e também, claro, a se divertir.

  8. @anarubiazr, adorei o seu comentário. Quanto ao item 1, exagerei no título para chamar atenção. Dificilmente o AN se tornará totalmente desnecessário, contudo, ele sai de uma posição central e migra para o papel de facilitador.Quanto aos estoques, existe sempre algum caso no qual alguém vai dizer "ahh, aqui seria melhor ter estoque". Tentar manter estoques mínimos sempre dá margem para que isso aconteça, contudo, a soma das economias feitas compensa essas eventuais perdas.A saída de um AN do projeto não deve ser mitigada por documentação, ela deveria ser mitigada pelo desenvolvimento do time (e do eventual AN que assumiria a posição). Se existe algo no que o AN que saiu deveria ter investido mais, seria nisso, por exemplo, levando o novo AN para as reuniões e compartilhando conceitos do negócio.

  9. Cara, fantástico relato! Gostaria que todas as pessoas em posição de BA/GP/Arquiteto/Wharever tivesse esta consciência de que a melhor coisa que eles podem fazer para o projeto é sumir, deixando suas skills disseminadas no time, ao invés da tradicional separação arrogante: peões e "classe pensante".Isso me lembra meu post de pouco tempo atrás: http://destilando.com.br/posts/i-dont-believe-in-software-architects …Parabéns continue assim! Precisamos de mais mensagens como esta![]s

  10. Cláudio,Fantástico o seu post, estou iniciado minha carreira como AN e essas experiências me motiva a cada dia a dizer que meu trabalho vale a pena.

  11. Ótimo post!!! Acredito que não somente o papel do AN,mas qualquer papel de liderança tenha como objetivo final se tornar desnecessário. Se vc é um bom SM tb se tornará desnecessário em pouco tempo. Apenas pessoas medíocres tem medo de se tornar desnecessárias, pessoas boas sabem que sempre haverá um novo projeto no qual será necessário formar uma nova equipe e somente assim a empresa conseguirá crescer em rítimo sustentável.

  12. Excelente, Cláudio… ótimo post, e perfeito a forma como vocês conseguiram se adaptar a realidade do projeto…Destaquei o trecho abaixo, apenas ilustrando essa capacidade do seu time, que estabelecia boa comunicação interna, com o cliente e com terceiros como um time de QA externo.Nós “os cinzas” ficamos, novamente, só dando úteis pitacos aqui e ali e é claro, sobrou para o analista de negócios atualizar a documentação (que parece cada vez menos necessária em um ambiente assim, sendo útil apenas para a construção do manual do usuário e para apoiar o QA externo).O principal de toda discussão em torno do gerenciamento de requisitos, é conseguirmos criar meios de se adaptar as diversas formas de projeto, o PO e os clientes tem também um papel fundamental e o entendimento da forma de trabalho da equipe é fundamental…Espero, que continuemos trocando idéias através dos blogs…Abraço

  13. Olá Cláudio,Muito bom o seu depoimento. A situação atual desse projeto mostra um nível de maturidade alto por parte do time. Como desenvolvedor, achei muito bom ver os benefícios que você citou, pois são os mesmos benefícios que tenho tido nos projetos que tenho atuado.Sobre detalhar documentação antes do desenvolvimento, escrevi um post sobre isso. Segue o link:http://www.heroisdati.com/fale-menos-codifique-mais/No mais, parabéns pelo texto.Abraços!

  14. Fantastico post! Quase chorei! Sentir os metodos nao so traz resultados e nos tornam melhores profissionais, como tambem nos tornam pessoas mais felizes. Parabens.

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current day month ye@r *