Esse não será um post técnico sobre uma nova gem ou alguma técnica de programação. Neste post vou compartilhar o processo/metodologia que utilizamos para guiar nossos projetos.
Depois de trabalhar em diversos projetos dentro da HE:labs, atualmente estou no meu projeto mais longo que completou 5 meses na última semana e ontem fechamos a iteração número #21. Esse projeto tinha uma previsão de durar apenas 8 semanas e por esse motivo resolvi compartilhar nesse post o que exergamos como pontos importantes para conseguirmos termos projetos com resultados positivos, com cliente feliz com o andamento do projeto e ganhando dinheiro
O nosso modelo de trabalho baseia-se em iterações semanais. As segundas-feiras temos uma reunião de planejamento, onde conversamos com o cliente sobre a última entrega e o que o cliente vislumbra para a iteração que se inicia. Feita a reunião, o time segue o trabalho de quebrar as histórias em tarefas e estimar o esforço, para que o cliente possa fazer a priorização das histórias que serão trabalhadas durante a iteração e ficar claro o que será entregue ao fim da iteração. Isso faz com que o cliente saiba exatamente o que irá receber.
Nesse processo alguns pontos são muito importantes. No nosso modelo, a cada nova semana fazemos uma nova "venda" para os nossos clientes, e a nossa missão é fazer com que eles "comprem" semana após semana, e dêem continuídade ao projeto. Essa "venda" acontece semanalmente, pois o nosso contrato permite que os clientes cancelem o contrato a "qualquer" momento, ou seja, se o cliente estiver insatifeito ele pode descontinuar o projeto.
Nós desenvolvedores temos o hábito de criar soluções mirabolantes para problemas simples e o cliente por sua vez acredita que toda solução é simples. Isso acontece principalmente pelo fato do software não ser um produto palpável. O Extreme Programming, tem como um de seus valores a simplicidade que é definida como: não produzir mais que o necessário. Seguindo esse conceito, mostramos aos nossos clientes as complexidades do desenvolvimento de um software, auxiliamo-os a tomar decisões mais simples que atendam aos requisitos do negócio, e ao mesmo tempo nos educamos para criarmos soluções simples também.
Uma das ferramentas que nos auxilía tanto na comunicação com o cliente quanto a dar soluções mais simples, é uma tecnologia muita avançada chamada de:
desenho a mão livre
Tanto o cliente quanto o time passam para o papel o entendimento da funcionalidade, para ser discutida, lapidada e chegar a uma solução final e que fique entendida por todos. Normalmente temos mais uma de solução para o problema. No início do projeto nem sempre é assim, o cliente normalmente leva algum tempo até começar a tomar as melhores decisões, mas depois de algumas iterações o cliente passa a optar pela mais simples, pois isso significa para ele menos esforço para o mesmo resultado. Além dessas vantagens, o desenho faz com que o cliente saiba exatamente o que vai receber e evita problemas como o famoso desenho a seguir.
O ruído é um dos maiores problemas na comunição e isso já é mais que sabído. O mercado tradicional, que chamam por aí de fábricas de software, com seus níveis hierárquicos é bem famoso pelas geração de ruído entre o "desejo" do cliente e o produto que é entregue. Esse modelo para piorar entrou em um ciclo vicioso auto-alimentado.
A pior parte é que esse processo "treina" desenvolvedores/profissinais que não saberão se portar e se comunicar com um cliente por serem isolados da comunicação. Entretanto esses mesmos profissionais depois de algum tempo são promovidos a Analistas/Gerentes sem qualquer experiência de comunicação/social/interação, pois isso nunca lhe foi cobrado/apoiado pela própria estrutura da empresa.
Uma das formas de retirarmos o ruído entre o time e o cliente na HE:labs, é que todos participantes de qualquer um de nossos time, isso mesmo os desenvolvedores, fazem a reunião diretamente com o cliente. Não existe um papel de gerente e/ou qualquer outro nome/função que isole o time da comunicação, nossos times são auto-geridos e capazes de levar uma reunião não só no âmbito técnico como também em relação ao negócio do cliente, isso exige uma habilidade "social" e interação de cada membro do time. Como resultado, o cliente conhece quem está trabalhando no projeto, remove o mito de que o programador só sabe escrever código, e gera um "contrato" em forma de responsabilidade do time com o cliente, pois este mesmo time, é que se encontra com o cliente todas as segundas-feiras e não vai querer ver o cliente decepcionado. Outro benefício desse modelo é que estreita-se o relacionamento entre o time/empresa e o cliente fazendo com que a confiança aumente.
A comunicação clara, compreende a redução de ruído e tem como resultado a confiança. Para exemplificar, cito a estimativa das tarefas de uma iteração, onde o time possui uma velocidade média dependendo de quantos membros a equipe é composta. Partindo desse ponto o cliente sabe exatemente o que irá receber ao final da semana no fim do dia de reunião, dado a relação velocidade do time e "pontos" estimados referentes as tarefas que irão entrar na iteração. Além disso, é preciso que a comunicação seja contínua durante a semana, ou seja, o cliente também deve estar disponível e em contato com o time durante o andamento da iteração, afinal de contas o projeto é como um filho, precisa de atenção sempre que necessário.
A relação da honestidade posso exemplicar, como o caso de haver um imprevisto durante a semana, o cliente do projeto é notificado o mais rápido possível que o time precisa de algo e/ou algo aconteceu. Assim como se o time acabar todas as tarefas da semana antes do prazo, o time pega tarefas do backlog para dar continuidade e o cliente tem clareza disso, pois no fim da semana ele recebe um roteiro de testes dizendo como testar o que foi feito.
Reprodução não interrompida de um mesmo fato ou fenômeno; frequência, habitualidade: (1)
Manter a frequência, o hábito, o ritmo é um dos desafios mais difíceis em um projeto em geral. Manter a produtividade, manter a qualidade, manter uma boa comunição são só algumas das variáveis de um projeto, porém alcançar e manter esse conjunto de variáveis funcionando é o que leva o projeto mais próximo da perfeição. Esse é o desafio de todo gestor e que toda empresa, seja desenvolvendo produtos internos ou prestando serviço, visa alcançar. Mas isso é fruto de um trabalho constante e contínuo para que o que está funcionando se mantenha e o que tiver de melhorar seja consertado rápidamente.
Esses pontos abordados, são alguns dos pontos que não só eu mas a empresa como um todo, enxergamos como importante para o sucesso de um projeto. Coragem para seguir em frente com o que você acredita é importante, porém mais importante é coragem para mudar e corrigir o rumo quando necessário, ou seja, estar adaptável as situações.
Cada projeto tem suas peculiaridades, assim como cada cliente tem o seu perfil. O importante é utilizar as ferramentas que funcionem para o seu time, mas manter a mente aberta para melhoria contínua. O que eu compartilho nesse post é o que acreditamos e vimos funcionar até o momento deste post. Entretanto estamos em aprendizado contínuo com cada novo cliente e projeto, então coragem para mudar é essencial!
Basedo nessas premissas que eu compartilhei, estamos entregando semana a semana cada projeto. E o nosso time/empresa recebeu do cliente do projeto que estou trabalhando um depoimento, resultado do trabalho que estamos fazendo. Veja a seguir.
Na nossa página existem outros depoimentos.
Abraço, Rodrigo Pinto.
(1) http://www.dicio.com.br/constancia/
Comentários
Included file post/disqus_thread.html not found in _includes directory