Princípios ágeis revisitados: comunicação

Em um post passado, começamos a rever e exemplificar situações em que os princípios ágeis são facilmente demonstráveis. Os quatro primeiros princípios que destrinchamos eram mais relacionados à entrega de valor, mas ainda há mais oito a vermos!

Dessa vez, agrupamos mais quatro princípios que focam nas pessoas e na interação entre elas e passaremos por cada um deles apresentando exemplos de situações cotidianas em que vemos sua utilização. Vamos lá?

Pessoas de negócios e desenvolvedores devem trabalhar juntos diariamente durante o projeto.

Ainda é comum demais encontrarmos times de desenvolvimento de software e pessoas que entendem do negócio que não se falam. A ausência dessa conversa acontece por uma infinidade de razões e o custo para o projeto é bem alto. A falta de comunicação frequentemente aparece na forma de pedidos do usuário que chegam por escrito sem todas as informações necessárias. Então, o time chuta a forma de traduzir aquilo no projeto. Essa prática traz consequências graves: aumenta o retrabalho e promove a desconfiança dos usuários no time de desenvolvimento e no projeto.

Outro formato que tenta substituir a comunicação entre usuários e o time é a produção de extensos documentos com todos os detalhes necessários para que o desenvolvedor não tenha dúvidas do que precisa ser entregue. Embora essa teoria pareça bonita, na prática sabemos que o custo de produzir tal documentação é alto, causa gargalos e, não raro, ainda não resolve o problema, já que interpretação de texto é um problema sério. Além disso, quanto mais documentação existe, mais rapidamente ela se torna desatualizada e não confiável.

Aproximar as pessoas que entendem do negócio e o time de desenvolvimento é a melhor opção. Ela evita trabalho desnecessário e a perda de motivação que isso causa, corta custos e, ao envolver usuários por todo o processo, aumenta as chances de sucesso do software. Ter uma linha de comunicação sempre aberta certamente vai ajudar o projeto — e é melhor ainda se essa comunicação for o mais direta possível. Finalmente, a convivência diária também tende a aumentar bastante a qualidade da informação entre os envolvidos no projeto.

O método mais eficiente e efetivo de agregar informações para e de um time de desenvolvimento é conversa cara-a-cara.

Uma das ferramentas mais arraigadas no dia-a-dia de empresas é o e-mail. E, incrivelmente, mesmo que estejam no mesmo prédio, ou na mesma sala, vemos com frequência pessoas escrevendo e-mails umas para as outras, em vez de simplesmente levantar e conversar.

Essa substituição da conversa cara-a-cara por e-mails é custosa de diversas formas: há o tempo para estruturar a mensagem e escrevê-la, mais tempo para a outra pessoa perceber que recebeu um e-mail, lê-lo e redigir uma resposta. Por ser uma mídia bem menos rica que uma conversa, provavelmente haverá dúvidas e mal-entendimentos que precisarão ser resolvidos… em novos e-mails!

Em uma situação cara-a-cara, não apenas as interações são mais rápidas, mas todo o suporte de comunicação das caras, bocas, gestos, entonações e, se possível, de um quadro branco de apoio para ajudar na conversa. Todas essas formas de comunicação secundárias são excelentes tanto para reduzir mal-entendidos, quanto para encurtar o tempo necessário para chegar a um bom entendimento.

Reduzir problemas causados pela falta de comunicação é uma boa forma de evitar desmotivar sua equipe. Isso nos leva ao próximo princípio:

Construa projetos com pessoas motivadas. Dê a eles o ambiente e o suporte que precisarem e confie que eles farão o trabalho.

Motivação é um assunto interessante. Comecemos citando o criador do Dilbert, Scott Adams, que disse: “Estou tendendo a acreditar no princípio de que não se pode motivar pessoas, apenas desmotivá-las.” Concordamos muito com isso. E expor os problemas que a desmotivação em um ambiente de trabalho causa poderia ser assunto de um post inteiro, mas creio que estamos todos mais do que familiarizados com esse problema.

Em um bom trabalho em time, as pessoas prestam atenção nas outras e tentam manter todas felizes. Contudo, não é raro que fatores externos também interfiram na motivação do time. De itens básicos como cadeiras desconfortáveis e café ruim até os mais graves como a falta de autonomia, opiniões ignoradas e prazos impossíveis. Tirar problemas do caminho ajuda as pessoas a focarem no que realmente importa.

Outra parte polêmica dessa frase é a palavra “confie”. E aqui vale um pequeno problema circular para refletir: trabalhar com quem confia em você é muito mais motivante do que trabalhar com quem sempre está atrás da sua cadeira, verificando que você está trabalhando e fazendo suas tarefas direito. E, convenhamos, se “não dá pra confiar no Fulano de jeito nenhum” passou da hora de repensar se essa pessoa deveria mesmo estar no seu time.

Processos ágeis promovem desenvolvimento sustentável. Patrocinadores, desenvolvedores e usuários deveriam ser capazes de manter um ritmo constante indefinidamente.

Esse princípio fala de sustentabilidade, assunto bastante importante e frequentemente deixado de lado em busca da tal da produtividade. E vale relembrar um conceito importante: produzir muito não é ser ágil! Mesmo porque há mais do que só desenvolvedores na construção de um projeto, especialmente se praticarmos o desenvolvimento incremental. Produzir demais também causa desperdícios.

Não vale a pena focar em produzir mais software se o levantamento do que é mais necessário não acompanhar o ritmo. Na outra ponta, é arriscado produzir muito código sem que as mudanças sejam entregues aos usuários ou sequer aprovadas. Hora-extra não é sinal de comprometimento do time, mas uma indicação de planejamento falho. Largar mão de qualidade técnica pode fazer um time produzir mais em curto prazo, mas o impacto a longo prazo é potencialmente terrível.

E, claro, ainda há aqueles problemas de fluxo fáceis de enxergar em times que usam um quadro branco (kanban) de acompanhamento do projeto. Até mesmo times que não são de desenvolvimento de software conseguem tirar proveito dessa ferramenta.

Quanto mais sub-times, quanto mais especialistas não-generalistas um time tem, mais frequente é o problema de fluxo e ele também está relacionado a esse princípio.

Práticas relacionadas

Agora que já conhecemos esses princípios e vimos exemplos de suas aplicações, vejamos uma sopa de letrinhas de artefatos, práticas e papéis para você saber o que procurar para se aprofundar nesses assuntos:

Retrospectiva
principal ferramenta de construção e manutenção de times, retrospectivas ajudam a evidenciar as dores de cada membro do time e a promover melhorias — e melhorias motivam! Além disso, retrospectivas frequentemente ajudam a remover problemas de comunicação;
Daily Meeting ou Stand Up Meeting
o poder de um encontro diário de 15 minutos onde todos se comunicam é impressionante. Muito além de reportar o status do projeto, o daily é uma oportunidade diária de aprender e ouvir os outros membros do time;
Metáfora do sistema
uma das grandes dificuldades de colocar usuários, clientes e desenvolvedores para conversar é que seus vocabulários e formas de expressão podem ser extremamente diferentes. Quando esse é o caso, construir uma metáfora que ambos os lados saibam traduzir para sua visão do sistema é algo tão poderoso quanto simples;
Sem hora-extra
trabalhar mais do que aguentamos é uma má ideia sob diversos prismas: aumenta custos do projeto para quem paga, provoca queda na qualidade de vida dos que fazem, o que usualmente provoca queda na qualidade do código e inserção de bugs. A menos que por um breve período e por decisão do time, horas extra são monstrinhos para seu projeto;
Product Owner / Cliente próximo
novamente, reiteramos a importância da participação próxima do cliente, que aumenta as chances de o projeto caminhar na melhor direção possível;
Workspace informativa
comunicação passiva é uma excelente forma de nos assegurarmos que todos estão na mesma página, com relação ao projeto. Trazer o acompanhamento do projeto para o local onde ele é desenvolvido não só melhora a comunicação do time, mas também incentiva clientes a conhecer o ambiente e os desenvolvedores;
Gráficos
Parte da sua workspace informativa, gráfico de Burn Up ou Burn Down, velocidade média, fluxo acumulado, ou qualquer outro que mostre informações de acompanhamento sobre seu projeto ajudam muito na comunicação e, assim, são ferramentas poderosas. Cuidado, apenas, para não deixar informações se desatualizarem. Se gráficos forem tão pouco importantes a ponto de ficarem desatualizados, remova-os!

Trabalhar com pessoas é sempre complexo e é exatamente por isso que agilistas dão tanta atenção para essa faceta dos projetos. Uma boa comunicação pode não ser perceptível, mas uma má interação entre as pessoas pode ser incrivelmente destrutiva. Exatamente por isso, gostamos de falar muito sobre isso em eventos, conversas de corredor e também no PM-83.

Nos seus projetos, como você trabalhou comunicação e feedback? Além disso, o que fez para aproximar clientes e usuários do time do projeto?

4 Comentários

  1. Gustavo 15/07/2014 at 10:03 #

    Ótimo post Cecilia.

    Realmente a conversa cara-a-cara é bem mais rápida e diminui bastante o ruído na comunicação. Mas por outro lado, o email incomoda menos.

    Já percebi que aqui no meu trabalho as pessoas não gostam de ser interrompidas. Se estão desenvolvendo e eu chego para conversar sobre alguma coisa, isso tira a concentração da pessoa, quebra o raciocínio, e dependendo da situação deixa a pessoa irritada.

    O email, apesar de ser mais custosa é uma ótima forma de deixar claro o que você quer falar sem atrapalhar.

    Outra coisa que eu aprendi a usar são os comunicadores instantâneos como Hangouts ou Skype. Aqui todos ficamos o dia todo online no Hangouts, e basta apresentar o problema e dizer “Encontrei um bug no Caso de Uso X. Me chama quando desocupar” ou “O Caso de Uso Y foi alterado. Vem aqui na minha mesa assim que possível” que quando a pessoa puder, ela vê.

  2. Claudinei 15/07/2014 at 17:38 #

    Muito interessante.
    Só uma ressalva na minha opinião, documentação é importante pois muitas vezes conversamos cara-a-cara e depois de implementado o cliente diz que não era aquilo que queria, se está documentado e tem aceite do cliente pelo menos não da pra dizer que não foi isso que ele pediu. Então uma coisa não substitui a outra, apenas complementa.

  3. Alex 12/08/2014 at 13:18 #

    @Claudinei,

    Acho que um dos benefícios de uma boa comunicação seja também acabar com esse problema que relatou. Será mesmo preciso documentar tudo isso só para depois provar que o cliente falou isso e não aquilo? O que isso importa, mesmo que ele tenha mudado de opinião depois?

    É importante que ele seja claro também, mas se ele mudou de opinião depois ou acha que de outro jeito é melhor, qual o problema? Lembrando interações curtas promovem feedbacks rápidos e isso é muito bom.

    O próprio texto cita: “Product Owner / Cliente próximo”, eles estando próximos esse feedback será melhor e mais rápido, tornando o processo melhor. Melhor o cliente achando que poderia ser feito de outro jeito no fim de uma sprint do que no fim do projeto.

    Abraços!

  4. Ceci Fernandes 12/08/2014 at 15:09 #

    @Gustavo
    Concordo que interromper as pessoas no meio do trabalho delas seja, às vezes, bem chato e que messengers podem sim, fazer o trabalho. Acho que o ponto principal é simplesmente que, se precisa de resposta, deveríamos dar preferência a meios de comunicação mais síncronos e ricos. 🙂

    @Claudinei
    Como o Alex comentou, o quão relevante é saber de quem é a responsabilidade pela funcionalidade não ter atendido às necessidades? Entendo completamente com o fato de pessoas estarem acostumadas a se defender umas das outras através de e-mails de confirmação, por exemplo. É importante notar, no entanto, que é exatamente isso: uma pessoa se defendendo da outra — não colaborando.

    O que queremos é chegar em um ponto em que a colaboração se sobreponha ao medo de ser culpado por algo. Mas, sim, isso é um processo longo muito facilitado por entregas frequentes e desde cedo e muita comunicação entre time e cliente (usuário, de preferência).

    @Alex
    Obrigada pelo complemento. 😉

Deixe uma resposta