Abbiamo Kanban! E agora, quem prioriza as demandas?

Aprendemos que a priorização das atividades deve ser feita, invariavelmente, pelo time do negócio. Na prática, entretanto, em nosso time, isso não acontece(u) de forma natural.

NOTA DO ELEMAR: Este post é do Fernando Neiva, editado por mim.

Resistindo a tentação

Nossos squads, na Guiando, são formados por pessoas que tem bastante experiência em nosso negócio –  são especialistas em gestão de custos faturados. Em decorrência disso, conhecemos o funcionamento e as demandas de nossa aplicação e conseguimos mensurar bem os impactos de cada alteração.

Essa condição, somada ao interesse das pessoas em contribuir, nos coloca em condição perigosa: frequentemente, o time de tecnologia entende que tem condições de priorizar demandas sem recorrer a área de negócio. Obviamente, isso nem sempre é verdade.

O que acontece quando priorizamos (no lugar do negócio)

Ao assumirmos a responsabilidade por decisões de negócio, nossos times passavam a ser cobrados não mais pelas questões técnicas, mas também pelo que foi entregue (e, principalmente, pelo que não foi entregue). Ou seja,  além de definir a arquitetura, o framework, a interface, etc, o time acabava tendo que justificar por que priorizou a feature A e não a feature B. Muitas vezes, perdíamos o foco técnico.

Não estou dizendo que o time de tecnologia deve ser estritamente técnico, pelo contrário, o conhecimento de negócio é essencial para realizar entregas de grande valor. Entendemos também que podemos e devemos contribuir com os esforços de priorização. Mas, precisamos entender de uma vez por todas que essa não é nossa responsabilidade – contribuímos, não executamos.

O que estamos fazendo?

No início da adoção do Kanban, propomos que os times de desenvolvimento puxariam os itens de uma fila priorizada pelo time de negócio. Na verdade eram duas filas, uma estratégica, que continha as necessidades para a evolução do produto, e uma de mercado, que contemplava demandas pontuais para atender algum cliente de forma mais específica. Os times puxavam demandas das duas filas em uma distribuição acordada com negócios.

Para amenizarmos dificuldades com itens em uma ordenação que tecnicamente poderia causar problemas, nas reuniões de negócio os squads influenciam na priorização para maximizar a eficiência.

Que resultados estamos obtendo

Ao tornar explícita a responsabilidade de priorização com o time de negócio a equipe técnica diminuiu consideravelmente a quantidade de reuniões para negociar prazos, escopo de funcionalidades e justificativas de decisões de priorização tomadas.

Também melhorou bastante a comunicação sobre o que de fato está em desenvolvimento. Antes desse processo, era comum situações onde a área de negócio pensava que algo estava sendo feito, mas não estava. Isso acarretava em bastante stress.

Na nossa experiência essa mudança fez muita diferença no dia a dia das equipes e tornou o trabalho melhor.

A área de Negócio deixou de ser “passiva queixosa” e assumiu a condição de “parceira colaborativa”.

Ainda temos problemas com correção de bugs. Por termos acordos de SLA, eles furam a fila priorizada explicitamente pelo negócio. Estamos experimentando um pouco o “custo da (não) qualidade”. Entretanto, este é tema para outro post.

Gostaríamos de saber como isso funciona na sua empresa. O time de tecnologia que prioriza? Isso acarreta algum tipo de problema ou funciona bem?