Certas vezes, a vida nos dá oportunidades, e quando a enfrentamos, caímos de paraquedas em algo totalmente inesperado.
Depois de trabalhar durante oito anos em uma empresa de tecnologia, com um cultura de desenvolvimento estruturada e um time de tamanho razoável (que nesses oito anos aumentou em sete vezes seu tamanho), me vi em uma situação em que, em três pessoas, tínhamos que criar algo totalmente do zero, em uma empresa que nunca trabalhou com desenvolvimento de software.
Era previsível que enfrentaríamos os clássicos problemas da nossa área. O que queremos? Quais são os requisitos? Qual metodologia iremos usar? Como iremos estimar nosso trabalho? Como serão as entregas? Qual o próximo passo?
Em cada passo, essas perguntas foram se respondendo, e nesse tempo, uma coisa se reforçou em minha cabeça: desenvolvimento de software não é apenas código.
O que vamos fazer
Tínhamos uma equipe, e aí? Vamos criar o quê?
Um dos grandes problemas gerais do mundo empreendedor é a ideia. Como ter uma ideia e como saber se é uma ideia boa. Ela trará lucro? Ela fará sucesso mundial?
No começo não tínhamos muita noção de qual caminho seguir. Escolhemos nosso rumo e fomos. Nos perguntamos muito, mas conseguimos responder pouco. No fim, acabamos por escolher algo que é a essência da Par Mais: educar e empoderar as pessoas.
Foi então que desenvolvemos um aplicativo para que as pessoas pudessem enfrentar o gerente de seu banco, de maneira que quando ele fizesse uma oferta de produto, o usuário pudesse abrir o App ($eu Dinheiro) e verificar se aquele era realmente o melhor produto naquele banco.
No mais, recentemente me deparei com a metodologia VLEF (Vai lá e faz), de Tiago Mattos, que ajuda muito a estruturar a ideia, e pensar se ela realmente é uma ideia que deve ser levada adiante.
Atualmente, me parece uma boa metodologia para executar as ideias que teremos.
Metodologia
Certo, agora tínhamos um software para fabricar, aí nos perguntamos: vamos usar uma metodologia ou vamos “só sair fazendo”?
Da nossa equipe, eu e outro colega tínhamos vindo da mesma empresa, então tentamos aplicar o que tínhamos adquirido de bom de lá, o velho amigo SCRUM. Não éramos extremistas do SCRUM, então funcionou bem.
Entretanto, a equipe cresceu e começamos a nos perguntar sobres outras coisas, se estávamos fazendo certo e por que tínhamos tantos problema em nosso processo, que deveria ser simples.
Então foi aí que viramos a chave, e começamos algo novo, que estava acima da metodologia. Afinal, a metodologia deveria vir para auxiliar e orientar nossas vidas, e não nos forçar a fazer algo que mais atrapalha do que ajuda.
A cultura do Spotify
Para quem nunca viu ou não sabe o que é, sugiro tirar um tempo de sua vida para assistir, segue o link.
Apesar de se tratar de uma solução para uma empresa de desenvolvimento de software, eu particularmente acredito que esse modelo possa ser aplicado a qualquer tipo de empresa que não possua um produto estilo linha de produção. Me refiro especificamente a empresas onde há vários setores, mas o resultado do trabalho é resultado do trabalho em equipe.
Basicamente, dividimos nossas equipes em squads e cada squad é responsável por resolver um problema específico. Cada squad é formado por um grupo de pessoas, que juntas têm o conhecimento completo para executar suas tarefas.
Há casos também, onde notamos em que algum conhecimento específico é necessário para melhorar o desempenho do time. Nesse caso, quando não conseguimos alocar um novo profissional para preencher essa lacuna, tentamos resolver entre nós mesmos.
O objetivo é do time, então juntos resolvemos os problemas.
E quando tem algo que não conseguimos resolver? É hora de chamar o chefe!
Voltando para a metodologia
Agora que temos nossos squads, e cada squad resolve seus problemas, então cada squad pode ter também sua metodologia. Apesar de que nossos squads seguem a mesma até o momento.
Mas há alguns pontos de aprendizados interessantes para se compartilhar. O que eu acho bem interessante, é uma boa prática que nos permite melhorar a cada interação.
Retrospectiva
O próprio Spotify diz que em sua empresa eles motivam a cultura do erro. Onde errar não é ruim, desde que se trabalhe e prepare para que ele não volte a acontecer.
Então, no fim de cada ciclo, temos uma reunião de retrospectiva. Nessa reunião, levantamos tudo que aconteceu de bom e de ruim no sprint. E com o que aconteceu de ruim, pensamos no que podemos fazer para melhorar.
Confesso que ainda não tenho clareza do que fazer com cada problema que encontramos. Muitos ficam guardados, esperando por uma solução. Mas a intenção é sempre essa, encontrar os erros, e tentar prevenir a sua reincidência.
E assim, vamos em frente, cada vez melhorando nosso dia a dia.
Sprints
Nossos ciclos são chamados de sprints, como no SCRUM.
Nós já trabalhamos com diversos tipos de sprints, por exemplo: sprints de uma semana. E foi justamente em uma reunião de retrospectiva que detectamos que passamos mais tempo planejando do que desenvolvendo. Logo o sprint passou de uma semana para duas.
Planejamento Macro
Cada squad possui um integrante que é responsável por executar as tarefas de PO (Dono do produto). Então essa pessoa é responsável por coordenar com os interessados qual o projeto que executaremos.
Com o projeto em mãos, o time realiza um trabalho de identificar as pequenas entregas no projeto e pontuá-las, usando Poker Planning.
Nesse momento, a pontuação é feita de maneira superficial. A pontuação total é cruzada com a média de pontos do time e assim conseguimos dar um prazo para a conclusão do projeto.
Planejamento Micro
No começo de cada sprint, o squad se reúne e planeja as tarefas das próximas duas semanas. Com o projeto já planejado e o backlog priorizado pelo PO, o time começa a pegar as tarefas e fazer o planejamento mais detalhado sobre cada item. Se nesse momento o time encontra algum problema que não percebeu antes, o prazo do projeto pode mudar.
Atualmente, este é um risco que estamos dispostos a correr. Preferimos o trabalho mais dinâmico do que longas reuniões para fazer um projeto inteiro, que no fim, pode cair na mesma armadilha e atrasar a entrega do projeto.
Para facilitar esse processo, recentemente adicionamos uma regra ao nosso planejamento: se a tarefa poderia levar mais de dois dias para ser entregue, ela deve ser quebrada em tarefas menores que possam ser entregues em menos de dois dias.
O objetivo principal dessa regra é conseguirmos observar melhor o andamento do sprint, e fazer um bom gráfico de Burn Down, que mostra a evolução do sprint, onde quanto mais tarefas são completadas, mais próxima de zero fica a linha, até não restar mais entregas naquele sprint.
Atualmente parece estar dando resultados positivos:
- Antes de um planejamento Micro.
- Depois de um planejamento Micro.
Entregas – Um pouco do que queremos fazer
Acreditamos que a entrega do software não é apenas um “merge no master”. Precisamos ir mais a fundo. Temos interesse em ver nosso cliente final utilizando aquilo que criamos, e queremos que nosso produto realmente resolva o seu problema.
Dessa maneira, a cada entrega relevante, colocamos a entrega na mão do usuário e pedimos para ele usar. Dessa maneira conseguimos observar a utilização e captar melhorias e problemas do software.
Essas entregas relevantes são que chamamos de MVP (Produto Viável Mínimo). No momento do planejamento, sempre olhamos para tudo que temos e nos perguntamos: o que de tudo isso é realmente necessário para resolver o problema do usuário? Podemos fazer entregas menores? Podemos resolver os problemas em partes?
Com essas respostas, criamos marcos no projeto em que o produto já pode ser implantado e já podemos vê-lo em operação. Isso ajuda a traçar os próximos passos, e talvez até identificar se o que estamos projetando realmente resolve um problema do usuário.
Encontrar esses MVPs é uma das tarefas mais desafiadoras que temos no momento.
Resumo
Resumi em poucas palavras como é o funcionamento do dia a dia do nosso trabalho aqui na Par Mais Tecnologia.
Ainda temos muito a melhorar e aprender. Assim como e o MVP, é o nosso trabalho: aplicar, observar e melhorar. A cada ciclo melhor que o anterior. Aprendendo com os erros. Mantendo o que temos de bom.
E assim vamos em frente.
