Quem você está tentando impressionar com seus prazos?

Dica: obviamente, não seus usuários.

Levante a mão para aqueles cuja empresa proclamou "Orientação para o Cliente" como um de seus valores corporativos. Para quem lê este texto em Habré e não vê a platéia: quase toda a sala levantou a mão, exceto algumas pessoas por trás.

Eles trabalham na Oracle.

A satisfação do cliente é um dos valores corporativos da Oracle. Mas os valores corporativos - eles são como uma academia - não basta apenas tê-los.

A obsessão do cliente é uma coisa útil, mas há mais uma coisa que muitas empresas estão obcecadas com o timing. Os prazos são bons. “Ele estará pronto quando eu terminar” pode ser uma ótima estratégia (ou até recomendada) para duas pessoas que trabalham no mesmo aplicativo. Mas quando você trabalha em uma empresa com mais de duzentos funcionários, precisa entender um pouco o que está acontecendo; uma ideia aproximada de quando seus usuários poderão usar seus novos apitos e peidos.

Atrevo-me a dizer que prazos rígidos são prazos ruins e, se a sua empresa possui, você provavelmente deve ir ainda mais longe e remover o item "foco no cliente" da lista de valores corporativos. Porque, acredite ou não, os usuários não se importam com sprints desarrumados.

Os prazos são principalmente necessários, não pelos clientes, mas pela gerência.

O objetivo principal é o objetivo

Ou por que congelar os requisitos de sprint é uma prática terrível

O tempo é bom, eles criam um senso de urgência, garantem a previsibilidade de seus processos e, portanto, você deve tê-los.

Mas existem termos bons e ruins. E há empresas nas quais os prazos são fixados em pedra e aqueles que cumprem os prazos a um passo da demissão. E então os problemas começam.

Estou falando de uma cultura de desenvolvimento na qual é comum congelar metas durante o sprint: quando todos se reúnem no início, avaliam tarefas, certamente usando apenas números de Fibonacci, e o que for decidido nessas reuniões, tudo isso deve ser feito antes da conclusão sprint - nada muda e não é tolerado. Em teoria, isso parece incrível, mas acho que essa tática está perdendo em qualquer cenário:

Situação A. Suponha que um desenvolvedor supere a lei de Parkinson e feche as tarefas com antecedência. Nesse caso, o desenvolvedor não relata isso na manhã seguinte, porque, ei, bem, ele não pode dizer que não tem nada para fazer. Ou o gerente atribui-lhe mais tarefas congelando o sprint, porque bem, ele não pode ter um desenvolvedor que não faz nada .

Situação B. O desenvolvedor, sendo um desenvolvedor, está atrasado. Os problemas com a configuração do ambiente demoraram mais que o esperado e ele não tem mais certeza de que terá tempo para fazer tudo antes do final da semana.

O que ele relata na próxima reunião, ao qual o gerente de projeto responde: “Ok, eu ouvi você. Mas assumimos um compromisso, então você pode tentar concluir tudo dentro do prazo? ” Ao mesmo tempo, a cabeça do gerente examina uma imagem de como ele deve explicar o atraso na liberação na sincronização semanal com o vice-presidente da empresa de desenvolvimento, que, por sua vez, dá a ele o conselho instrutivo "Just do it" , então é melhor apenas esticar e tentar fazer.

Assim, o desenvolvedor, sendo desenvolvedor, sai por algumas noites, ou talvez um fim de semana, e conclui o trabalho a tempo. E seu gerente aprecia seus esforços no próximo comício. Negócios alguma coisa.

Ou não é tão suave? Os prazos foram cumpridos e o trabalho foi concluído com êxito, mas o precedente errado foi criado. Um estudante recém-contratado com os olhos arregalados recebeu um sinal de que o processamento nos finais de semana é correto .

E nem discutiremos o triste cenário quando o prazo não for cumprido, a tarefa vai para o próximo sprint e o gerente deve justificar o atraso em sua próxima sincronização semanal com o vice-presidente de desenvolvimento e ouvir conselhos morais.

Você vê algum problema? Em nenhum momento alguém fez a pergunta: "Escute, o que acontece se passarmos para o próximo sprint e não dermos desculpas a ninguém? Como isso afetará os usuários? ”

Muito mais frequentemente do que deveria, os prazos são auto-hipnose. E como lidar com eles - também.

A solução ideal seria simplesmente conversar com as partes interessadas - a equipe de produto ou a equipe de vendas, descobrindo com elas se o atraso poderia levar à perda do cliente. E se for esse o caso, aloque definitivamente horas extras e é possível trabalhar no fim de semana. Nesse caso, o jovem estudante receberia um sinal de que a empresa realmente se importa com seus clientes, e não com seus sprints.

Há outro problema com o congelamento de sprints. Suponha que você recebeu uma solicitação de um cliente - para corrigir um bug potencialmente trivial e de baixa prioridade. O desenvolvedor vai lidar com isso em um dia. Mas você está seguindo o processo de ^TM , o que significa que a tarefa é adicionada ao backlog de sua equipe e talvez seja lembrada após alguns meses. Mas você perdeu a oportunidade de agradar o usuário! Você pode lidar com isso em alguns dias e informar ao usuário por e-mail que o problema foi resolvido. As pessoas se lembram de tais momentos, e são essas coisas que as fazem recomendar o seu produto a seus amigos.

Não se empolgue demais com os processos - por causa deles, você pode perder seu objetivo. ¹

Também acredito que o congelamento rápido ou qualquer outra prática restritiva é um sinal da desconfiança mútua inerente à empresa, como resultado de problemas mais fundamentais no nível da cultura da comunicação, mas mais sobre isso na próxima vez.

Por que os prazos são terríveis

1. Eles criam expectativas falsas, ao contrário do que está escrito em seus valores corporativos. Como seus valores corporativos não são seus , seus valores reais são expectativas e preconceitos não escritos (bons e ruins).
2. As pessoas cortam cantos se você as colocar em condições adversas. Alguém marcará para o teste, alguém não atualizará a documentação. Você envia a liberação no prazo, mas a que custo?
3. Ninguém concorda em gastar tempo procurando novas soluções enquanto os gerentes oram por tarefas concluídas no prazo. Todos escreverão o front-end nas estruturas MVC até que alguém no Facebook cumpra algum prazo.

Então, trabalha sem prazos?

Claro que não. Estabeleça prazos, mas torne-os flexíveis. Quão flexível seus prazos podem ser é seu objetivo. Se o não cumprimento do prazo resultar na perda de um milhão de dólares, sua flexibilidade deve ser zero. Mas se esse é outro recurso, sempre há espaço para manobras. Você também pode experimentar métodos probabilísticos mais complexos para estimar datas, em vez de reproduzir números de Fibonacci com o dedo no céu. ²

Mas congelar sprints é uma decisão mais ou menos.

^1. Jeff Bezos falou bem sobre esse assunto em uma carta aos acionistas em 2016 . Ele aconselhou "resistir a proxies entre pessoas dentro da empresa".

^2. Joel Spolsky fala sobre métodos avançados para estimar prazos em seu artigo “Agendamento Baseado em Evidências” ( tradução em Habré ).