Motivado pelo ótimo post do Rafael Buzón, compartilhando a experiência de vários agilistas sobre o início de um projeto ou produto, resolvi escrever um pouco sobre como conduzimos nossos projetos na Lambda3.
Nosso contexto de Trabalho
Nós somos um Ateliê de software . Isto significa que normalmente atuamos em projetos e produtos de outras empresas, em modelos de contratação que podem variar dependendo do tipo de cliente com quem atuamos: Time Material, Processos de Negócio, MVP, Escopo Fechado. Aproveitando os perfis de empresa que o Rodrigo Yoshima propôs há algumas semanas, nossas maiores preocupações no trabalho são “Qualidade”, “Prazo” e “Custo”, por ordem de prioridade.
Mas a Lambda3 faz projetos de escopo fechado?! Sim. Apesar de super incomum, algumas empresas precisam iniciar a relação de trabalho com premissas tradicionais, ainda que o histórico de seus projetos tradicionais sempre seja problemático. Esse é um assunto para um próximo post; hoje vamos falar sobre nossos projetos ágeis.
Nosso trabalho começa na atuação comercial, apresentando os diversos modelos de parceria e entendendo a realidade do cliente: seja desenvolvendo o MVP para uma nova startup, assumindo um projeto legado ou iniciando um projeto corporativo. Tradicionalmente esse é um trabalho difícil, e na nossa experiência mais lento que o comum, uma vez que há muito de alinhamento para ser feito, e meu trabalho normalmente é explicar todo o processo de trabalho, motivação, benefícios e trade-offs necessários.
Cada vez mais encontramos empresas que aceitam o discurso Ágil, ainda que não necessariamente saibam o impacto do modelo, principalmente após experiências ruins com fornecedores ou depois de falhar inúmeras vezes em projetos tradicionais. Isso facilita o início de nosso trabalho, mas nem por isso torna mais fácil o dia-a-dia de um projeto.
Nossos Projetos Ágeis
Quando me perguntam: “Vocês usam Scrum?” a resposta sempre é “também”. Não gosto de rótulos, já que a Lambda3 tem atuado em diferentes contextos, e cada um acaba tendo definições diferentes. Mas acontece que muitos desse clientes esperam algo “tipo scrum” quando trabalhamos… (reuniões diárias, retrospectivas and all that jazz)
Iniciamos um novo projeto fazendo um alinhamento interno a respeito do trabalho: O entendimento do modelo de trabalho, o tipo de contratação, a percepção que o comercial Lambda3 tem do cliente, principais premissas do negócio e possíveis desafios. Transparência é um ponto crucial na empresa, e todas as informações são compartilhadas para que o time possa ter todo o contexto sob o qual atuará. O time escolhido atuará de maneira auto-gerenciada, com total liberdade para decidir e atender ao projeto da maneira que achar melhor. É um modelo que falamos há anos neste blog, e segue a estratégia descrita em meu último Post: Seu Time Autogerenciável.
Feito isso é a hora de reunir todos numa mesma sala e discutir sobre o projeto. Nossos contratos inclusive requisitam a participação do cliente nas cerimônias. Cada caso pede uma abordagem diferente nesse momento, e as práticas ágeis são um ótimo arsenal para se ter à mão.
Contexto é tudo:
- Fazemos Inceptions? Sim, quando o cliente topa estar conosco por 40 horas apresentando seu novo produto e planejando seu MVP. Esse investimento no início do trabalho acaba sendo o mais produtivo e gera um alinhamento sem igual. Infelizmente não são todos os trabalhos que permitem… #chatiado
- Release Planning? Sim, a maior parte das vezes. Talvez essa seja a principal ação que tomamos no início dos projetos. Assim temos, por exemplo, a visão no primeiro dia de projeto do que representa uma primeira entrega (no ar na primeira semana de projeto) e o que significa o primeiro Release para o produto.
Temos times em diversos graus de maturidade e que trabalham de maneira independente, não há um processo único para conduzir projetos. Temos times que usam mais tradicionalmente Scrum, alguns times que estão experimentando com fluxo contínuo e outros sem uma metodologia definida (apesar de seguirem princípios ágeis). Cada cliente, uma abordagem diferente. Cada cliente, um contexto novo – e por isso não seguimos fórmulas mágicas.
Com um cliente novo costumamos ter contratos que duram somente 3 meses. Por que? Na nossa experiência:
- É uma ótima oportunidade de apresentar o modelo ágil de contratação
- Traz risco menor para o investimento do cliente, que acaba se comprometendo com pouco tempo – principalmente quando não está totalmente certo do modelo
- É tempo suficiente para um ciclo de ao menos 2 lançamentos em produção além de todo o boilerplate de contratação de um Ateliê de Software
- Cria o incentivo: “entregar o melhor que podemos, para continuarmos atendendo esse cliente”. Clientes satisfeitos permanecem conosco por muitos meses, e sempre retornam para novas iniciativas.
À medida que as entregas vão acontecendo, e a confiança de nossos clientes crescendo, sempre existe mais trabalho a ser feito. Os contratos tendem a ser mais longos após o primeiro estágio.
Ao término de um contrato, fazemos uma retrospectiva de projeto, celebrando a experiência e buscando o aprendizados para os próximos projetos que o time atuará. Olhar para o projeto numa escala maior, visando melhorar o trabalho futuro para todas as nossas interações com os clientes.
Se interessou? Gostaria de falar mais sobre projetos? Podemos ir até sua empresa e apresentar nosso modelo de trabalho! Me convide!
