Desenvolver software é uma atividade artesanal e difícil. O desafio é transformar uma ideia em código. É preciso várias etapas para se ter clareza sobre o que se deve ser desenvolvido. Até mesmo uma nova função pode requerer muitas interações. Aumenta-se a chance de se obter o que realmente se precisa ao validar e aprender com cada passo.
Talvez o maior impacto na construção de um software seja o jeito como ele é construído. São inúmeras decisões que precisam ser tomadas em vários níveis, desde conceituais (ex., qual é o problema que precisa ser resolvido) até detalhes mínimos (ex., tipo da coluna de uma tabela no banco de dados). Há milhares de livros e muitas técnicas amplamente divulgadas sobre como criar um software. Precisa-se, assim, definir um método que se encaixe no perfil de uma empresa.
Na Knewin, usamos, no início, o método ágil chamado Scrum. Definíamos um ou mais objetivos a serem desenvolvidos a cada quinze dias. A equipe discutia cada objetivo e definia a lista de tarefas, seus responsáveis e o tempo estimado para desenvolver cada uma delas. Havia reuniões diárias, de 15 minutos, para discutir o que estava indo bem e o que não estava. Tudo ficava registrado em um software específico para Scrum.
Com o tempo, notamos que o método não estava funcionando para nós. As decisões em uma startup são tomadas com mais velocidade porque há muita coisa ainda sendo definida. Há demandas básicas dos clientes que ainda estão sendo entendidas, o mercado está sendo descoberto, clientes maiores geram demandas mais urgentes, questões operacionais impactam o planejado e assim por diante. Ademais, a nossa equipe era pequena e tinha que dar conta de várias coisas ao mesmo tempo.
Muita coisa que era urgente não podia esperar. O fato é que a demanda urgente, e outras nem tão urgente assim, muitas vezes ganhavam prioridade em vez das tarefas planejadas. A equipe ficava ansiosa com as reuniões finais de cada quinzena porque várias tarefas ainda estavam por fazer.
Tivemos que buscar um método diferente, que estivesse mais alinhado com a dinâmica da Knewin. Adotamos, então, algumas práticas do método Kanban. Esse método é mais flexível e nos permitiu organizar as demandas urgentes com as demandas planejadas. Ainda havia a reunião de planejamento e a revisão sobre as tarefas concluídas, mas a reunião diária foi trocada por interações pontuais entre as pessoas sempre que fosse preciso.
A grande diferença ocorreu quando passamos a planejar a semana. As tarefas precisavam ser resolvidas em cinco dias e isso nos forçou a ser mais críticos nas escolhas. Além disso, ficou mais fácil negociar demandas urgentes para serem atacadas na semana seguinte. As equipes, em especial comercial e relacionamento com o cliente, entenderam esse ritual e, com isso, foi possível dar mais foco nas tarefas planejadas.
Os objetivos da semana eram definidos a partir de OKRs (Objective and Key Results). OKR é um método que ajuda a definir e medir com mais precisão o quanto de um objetivo foi alcançado. Um exemplo de objetivo poderia ser: Ampliar a cobertura de coleta de jornais online. Já um exemplo de key result seria: Adicionar 5.000 novos jornais por semana (adicionar apenas 2.500 jornais por semana significa apenas 50% concluído).
Começamos com OKRs de três meses e depois de algum tempo mudamos para OKRs mensais — alterarmos porque não funcionou um intervalo muito grande para uma equipe pequena que também era responsável por tarefas do dia a dia. Cada OKR era definido com base no planejamento estratégico, que descrevia as diretivas do que precisávamos alcançar no ano. Com isso, as tarefas planejadas na semana estavam de acordo com as metas do ano e podiam ser medidas pelos key results dos OKRs.
As principais tarefas da semana vinham dos OKRs, mas ainda tínhamos que planejar as demandas urgentes e demandas pontuais de clientes. Na reunião de planejamento da semana todas essas tarefas eram discutidas e priorizadas em conjunto. Assim, cada desenvolvedor sabia o que precisava ser feito e podia melhor se organizar para dar vazão às suas tarefas — menos interrupção e, consequentemente, mais produtividade.
Todos da equipe sabiam o que cada um estava fazendo. As tarefas também eram mais bem delimitadas e, normalmente, seguia um ritmo de evolução contínua. Além disso, as tarefas dos OKRs seguia uma evolução de produto e isso nos permitia definir cada passo com mais facilidade — é uma vantagem de uma empresa de produto. A meta era chegar ao final da semana com as tarefas concluídas e já sendo usadas pelos clientes — passos menores mas constantes.
Também tínhamos mais rapidez para intervir caso algo não saísse do jeito que prevíamos. Mesmo se a tarefa levasse a semana toda, ainda assim, era apenas uma semana. Esse tipo de situação acabava ocorrendo cada vez menos à medida que mais conhecíamos as necessidades dos nossos clientes.
Tivemos vários benefícios em usar algumas práticas do Kanban para o nosso dia a dia no desenvolvimento das aplicações. O planejamento semanal gerou menos interrupção para a equipe ao passo que as atividades urgentes também puderam ser encaixadas, pelo menos a grande maioria delas, na semana.
Nossa equipe também conseguiu organizar as interações e validações com mais frequência, principalmente com os clientes. Com a definição de tarefas menores e o conceito de evolução contínua conseguimos acertar mais quanto às necessidades dos nossos clientes para novas funções assim como nas melhorias das funções existentes.
Enfim, o nosso método de desenvolvimento de software usa práticas do Scrun e Kanban — para nós não fez sentido usarmos esses métodos com todos os seus detalhes e minúcias. Nós escolhemos as práticas que vimos mais valor dado o nosso jeito de atuar. Fizemos vários ajustes durante esses anos da Knewin e ainda hoje sabemos que haverá outras tantas mudanças. Além disso, novas pessoas e papeis entram na equipe o outras ideias são discutidas e questionadas com frequência.
Temos hoje algumas equipes de diferentes produtos e cada uma delas têm suas regras e práticas próprias. Há equipes que fazem uma reunião diária de 15 minutos, por exemplo, e há equipes que planejam apenas a semana e se falam quando é preciso. O resultado é medido pelas entregas e a aderência ao que foi planejado.
Contudo, novas práticas no desenvolvimento de software estão sendo inseridas de modo transversal às nossas equipes. O mínimo é garantir que tenhamos qualidade no código, alarmes devidamente configurados, revisões contínuas, documentação clara e objetiva, automação para atividades rotineiras, interação entre as equipes e alinhamento com OKRs e as metas anuais.
Também temos muita preocupação com a visão de longo prazo. Planejar a semana mesmo com OKRs e metas anuais não elimina o risco de focar no urgente e operacional e esquecer o importante. Por isso, discutimos as tarefas a luz do que queremos para o futuro. Planejar a semana exige uma visão crítica que consiga compreender a urgência, as demandas específicas, os desejos, inovações e o futuro.
A experiência de anos atuando com o desenvolvimento de software e sempre estudando os métodos de como melhor desenvolver software têm nos ajudado a obter melhores resultados em nossas entregas. A evolução incremental e contínua com interação constante com os clientes, talvez, tenha sido o maior impacto nessa atividade que ainda é artesanal e bem complexa. O importante é aprender e melhorar sempre.
Novas postagens no endereço fbeppler.com.