Sobre Accountability no Desenvolvimento de Software

19 de janeiro de 2020

Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.

Sobre Accountability no Desenvolvimento de Software

Todas as empresas querem accountability. Faz parte de fazer qualquer coisa funcionar. Se você precisa atingir resultados, precisa entregar algo, e seria ótimo saber quando isso vai acontecer.

Accountability ainda é uma palavra delicada para times de software. Quando usada de forma errada, se transforma em prazos rígidos (e às vezes artificiais). E esses podem ser prejudiciais para os times de diversas maneiras. Por que isso acontece e por que é tão difícil?

Para começar, se você quer accountability, é melhor ter previsibilidade primeiro. Se você não consegue prever o trabalho (e o tempo necessário), então será difícil se tornar accountable. A conversa positiva é sobre como tornar times mais previsíveis e, assim, capazes de ser accountable por resultados. Accountability precisa de previsibilidade. A principal questão é como chegar lá.

Sobre previsibilidade em software, há dois tópicos que valem a discussão:

1. Variação em processos de produção
2. Como lidar com a variação na entrega de software

Variação na Produção

Você pode esperar variação em qualquer sistema de produção, e não será diferente em tecnologia.

Em qualquer negócio, sempre há variações, entre pessoas, em output, em serviço e em produto. O output de um sistema resulta de dois tipos de variação: variação por causa comum e variação por causa especial.

No trecho acima, causas comuns são as consequências do sistema, ou como o trabalho funciona. Por exemplo, se um time não consegue focar no trabalho, então vemos mais variação, pois o esforço está espalhado em muitas coisas diferentes. Causas especiais são eventos fora do comum que aumentam a variação. Isso poderia acontecer se houvesse um incidente e o time tivesse que desviar sua atenção por um período significativo.

Geralmente superestimamos causas especiais em relação às causas comuns. Isso é prejudicial para a variação. E agir sobre isso da forma errada vai piorar os resultados ao invés de melhorá-los.

As pessoas acham que existe muito menos variação do que realmente existe. Portanto, sua inclinação natural (sem um conhecimento suficiente de variação) é suspeitar de um problema especial quando na verdade é apenas a variação natural do sistema. Interferir, reagir exageradamente à variação, é um método comum de aumentar a variação — e os custos!

E a Entrega de Software?

Variação é especialmente importante na entrega de software. É um campo onde a variação esperada (causa comum) é bastante alta. Software é naturalmente complexo.

O desafio específico é que cada feature adiciona mais código, mais lógica e aumenta a complexidade de todo o sistema. Com isso, o trabalho se torna mais complexo, mais arriscado e mais difícil de prever.

Complexidade aumentando com as features

Por que isso é um desafio?

O gráfico acima é fácil de entender. Mas na prática, quando há tensão sobre a entrega, é mais fácil encontrar causas mais simples. Causas que podem criar uma pressão por mais previsibilidade.

E é aí que se torna um problema. Prazos mais rígidos e a exigência de estimativas “melhores” significam tratar causas comuns como causas especiais. Em vez de lidar com a complexidade, lidamos com estimativas ruins. Criamos e perpetuamos então um ciclo vicioso. Um que só vai aumentar a variação e reduzir a previsibilidade.

Uma vez que você entra nele, os resultados mais prováveis serão burnout e/ou a constante redução da qualidade do produto.

Qual é a alternativa?

Isso não quer dizer que times não devam aspirar à previsibilidade. Devem e precisam, afinal trabalhamos dentro de restrições de negócio.

A melhor ação é reduzir a complexidade e aumentar a previsibilidade, agindo sobre o sistema (causas comuns). Há muitas formas de fazer isso, e algumas das maneiras como a indústria tem enfrentado esses problemas são:

• Estabelecer melhor qualidade: Testes automatizados de regressão, integração e deploy contínuos, alertas. Todas essas são formas de proteger o desenvolvimento e tornar mais fácil identificar problemas. Com isso, reduzindo a complexidade de entregar código novo.

• Reduzir o tamanho e a complexidade do código: Dedicar tempo para simplificar o sistema. Refatoração, dividir o sistema em partes menores, remover código e features não utilizados. Tudo isso torna o sistema menos complexo e mais previsível para trabalhar.

• Simplificar soluções. Times de produto produtivos focam no problema do cliente que estão tentando resolver, iterando na solução. Isso possibilita soluções técnicas mais eficazes que reduzem a taxa com que a complexidade aumenta.

Agir sobre o sistema pode levar mais tempo para resultar em mudança. Mas no final é o que vai gerar melhores resultados. Em qualidade, tempo e custo.