Na minha última palestra, no Ceará On Rails, eu tive que preparar tudo de um dia para o outro e não pude organizar melhor as idéias colocadas nos slides. Em um deles eu escrevi “A procura da batida perfeita”, no momento que eu ia falar sobre as características de uma aplicação web ideal, da maneira que eu busco.

De lá pra cá eu venho pensando sobre o termo “batida perfeita” e relacionando com os acontecimentos do dia-a-dia na minha vida.

Então me veio a pergunta: Qual seria a batida perfeita para a gestão de uma empresa de desenvolvimento de software?

Antes de responder, é bom lembrar que a batida perfeita é aquela que dá gosto de ouvir.

Respondendo a pergunta acima, na minha opinião, a batida perfeita para gestão em software, envolve em parte o seguinte:

Utilização de metodologias ágeis

Se eu pudesse dar uma só dica sobre o futuro, seria esta: use metodologia ágeis
Os benefícios a longo prazo do uso de metodologias ágeis estão provados e comprovados pela ciência; já o resto de meus conselhos não tem outra base confiável além de minha própria experiência errante.

As metodologias ágeis começaram a ter força no Brasil, neste ano de 2009. O Scrum, Lean, Kanban, XP foram as filosofias e metodologias mais faladas entre os Brasileiros. Eu estou convicto de que o agile, como é chamado pelos íntimos, é mais eficiente que as metodologias adotadas atualmente, assim como sou convicto que haverá metodologias melhores no futuro próximo. O legal é que o agile já é o primeiro passo para se aceitar mudanças com velocidade.

Fixar qualidade, negociar escopo. Preço e prazo são consequência
É muito importante que você fixe a qualidade do serviço, seja para clientes externos ou clientes internos. Negociar o escopo é chave para o sucesso de projetos de desenvolvimento de software, pois assim fica garantido que o que foi feito vai funcionar, que é um dos maiores problemas neste setor.

Entendimento do perfil do desenvolvedor
Em geral, o desenvolvedor é um funcionário um pouco diferente dos demais. Um amigo meu já disse uma vez “É mais fácil tocar uma indústria com 600 funcionários do que uma empresa de software com 10”. É claro que não passa de uma opinião, mas o que ele queria dizer é que desenvolvedores são problemáticos.

O primeiro problema que deixa qualquer gestor neurótico é o horário. Difícil fazer o Daily Meeting no horário todos os dias, não é mesmo!?

Confiar no desenvolvedor é importante, principalmente nos prazos dados. É sério, eles sabem dar prazos. Os gestores que não sabemos aceitar.

Escolha de uma tecnologia para trabalhar
Escolher um ambiente e as tecnologias para as soluções que serão desenvolvidas é indispensável. Pequenas empresas principalmente precisam fazer uma escolha e segui-la.

As opções são inúmeras, dentre elas temos: software desktop, software para Windows, aplicações para mainframe, sistemas web na plataforma Windows, sistemas Ruby on Rails, etc. Perceba que não existe um critério, você pode deixar mais abrangente dizendo desktop x web ou especificar que será só pra Windows ou usando o framework X.

Embora não seja aconselhável você se prender a uma tecnlogia, quanto mais você especificar com o que deseja trabalhar, é melhor para evitar ficar perdido e gastar energia com falsas oportunidades.

Estes foram apenas quatro pontos que estavam na minha cabeça e resolvi colocar em um post. A batida perfeita não pára por aí evidentemente. Muitos outros fatores são relevantes, inclusive aqueles que dizem respeito à programação em si.

Havendo oportunidades escreverei sobre abatida perfeita para desenvolvimento de código de programação e fatalmente falarei sobre os tópicos abaixo:

Framework, Programação orientada a testes (TDD), Deployment automatizado, Integração contínua, Controle de versão distribuído, Definição de um Commit Pattern, Ambiente de Staging, etc.

Conforme eu for descobrindo características importantes, vou escrevendo aqui. Por enquanto é só.

Abraço e até a próxima

Atualização em 18/08/09 – Depois de esvaziar o buffer neste post, continuei lendo e pesquisando sorbe o assunto. Pretendo formatar um modelo que funcione bem para as características específicas aqui da Myfreecomm. Nas leituras achei este post que responde exatamente as minhas perguntas.

Atualização em 06/08/09 – A questão não é a literatura sobre P.O. e Scrum Master em si, mas o que é vivenciado na prática. Algumas literaturas dizem que o P.O. deve ser o cliente, outras dizem que pode ser um representante dele e por aí vai. Minha idéia é tentar entender como isso funciona em alguns casos práticos. Realmente a pergunta no título ficou muito ruim, deveria ser: Como funciona pra você?

***

Este post é fruto de uma conversa que tive ontem sobre a necessidade de delimitar as responsabilidades de cada papel no SCRUM. Essa conversa vai de encontro com um ponto que queremos melhorar no processo desenvolvimento na Myfreecomm.

Geramos algumas dúvidas que eu não sei a resposta exata, mas pretendo respondê-las após alguns estudos e experimentos na prática. Se você tiver alguma resposta, deixe um comentário.

O P.O. é o cliente? Cliente e P.O. são as mesmas coisas? O P.O. tem que ser necessariamente o representante do cliente?

O P.O. precisa entender de software?

É papel do P.O.trazer o que ele quer já detalhado em forma de itens do software a ser desenvolvido ou é papel do Scrum Master entender a necessidade de negócio e traduzir em software?

Dado um cliente externo (ou interno off-site) não se faz necessário designar um “P.O. Interno” que seja um analista e que faça a ponte com o cliente?

O “P.O. Interno” pode ser o Scrum Master, dado o fato de que o Scrum Master entende de tecnologia e é um analista de sistema em geral?

É responsabilidade do Scrum Master definir o prazo real para o desenvolvimento e demonstrar ao P.O. no Sprint Planning ou é responsabilidade do P.O. ter o entendimento de desenvolvimento para criticar o prazo estipulado?

Qual a sua opinião?

Eu vivo falando isso, mas me dei conta que nunca escrevi aqui.

Em uma empresa de desenvolvimento de software o que há de mais importante e valiosos são as pessoas.

Eu penso muito sobre isso desde que fundei a BielSystems. Por conta de atualmente participar de duas equipes de trabalho diferentes, na BielSystems dirigindo e na Myfreecomm gerenciando, faço muita comparação e tenho aprimorado algumas opiniões sobre o assunto.

Cheguei a um conjunto de definições que estou buscando aplicar na íntegra seja onde for que eu esteja trabalhando. A primeira delas é:

Contratar de preferência bons profissionais e se possível os melhores do mercado.

Às vezes é difícil para uma start-up contratar bons profissionais e ainda mais os melhores do mercado, por conta do alto investimento inicial. O que eu tenho feito é só iniciar um projeto caso ele seja viável mesmo contemplando profissionais caros. Se o projeto não comporta, eu saio fora.

Esta primeira definição eu aprendi também com o Steve Jobs, mesmo antes de ler o livro A Cabeça de Steve Jobs. Eu já sabia que Steve só contratava gente muito boa, mas a leitura me chamou a atenção de como isso é tratado como fundamental dentro da Apple e Pixar.

Só não ficou muito claro pra mim, como ele dá oportunidade para os novatos que ainda estão em fase de aprendizado. É claro que eles contratam iniciantes, mas pelo que percebi isso não é muito relevante dentro das duas empresas dele. Isso tem haver com minha segunda definição sobre o assunto:

Não basta ter apenas profissionais com experiência. Dar oportunidade para novatos que estão com vontade de aprender é fundamental para montar uma boa equipe.

Ter novatos na equipe é muito bom. Quando a pessoa é iniciante e não tem muita experiência ela deve estar sempre disposta a aprender e a fazer o que tem que ser feito.

Vontade de aprender é fundamental, principalmente no mercado de tecnologia, que o conhecimento evolui com muita rapidez e o state-of-art muda a cada 6 meses. Uma pessoa que se contenta com o que sabe será expelida do mercado muito rapidamente.

Os iniciantes em geral têm uma disposição maior, uma vontade de crescer e um gás que é fundamental para contagiar a equipe e manter um ritmo acelerado. Além disso, é legal montar um clima de troca de conhecimento. Ter que ensinar os mais novos, inclusive, desenvolve a capacidade de comunicação dos mais experientes. Esta troca é saudável e todos ganham.

Outro ponto importante, diz respeito à como tratar o contratado.

É fundamental dar atenção e respeitar cada profissional individulamente, lembrando sempre que o resultado da organização depende somente deles e a empresa é responsável por fornecer o melhor ambiente para que o trabalho flua bem.

Os computadores podem ser substituídos de um dia para o outro sem causar absolutamente nenhum problema, basta pagar o preço que você duplica a estrutura com a garantia da conformidade. As pessoas não. Estas são altamente complexas e variadas, não é possível duplicar a equipe e garantir uma conformidade.

Além disso a substituição de um profissional é complicada. Eventualmente o problema maior não é quem sai, mas quem entra no lugar. Às vezes a pessoa que sai é responsável pela manutenção da hegemonia de uma equipe inteira e raramente isso é contabilizado. Às vezes o profissional que entra não se adapta ao clima que já existe e eventualmente contamina a equipe com práticas e valores ruins, o que é extremamente prejudicial a todos.

Esta última definição diz respeito diretamente às “fábricas de sotware” (argh!). Nestes locais de trabalho não existe ambiente propício para o desenvolvimento de bons códigos, as pessoas são tratadas como números e são substituídas como os computadores.

Desenvolvimento de software não funciona assim.

Não é por que este é o meu negócio que eu acho que ele seja diferente, ele é diferente mesmo e ponto. Existem muitos ótimos profissionais muito novos, os experientes acima de 35 anos não têm mais vez, a maioria dos bons profissionais são nerds, tudo muda muito rápido e os modelos tradicionais de gestão não funcionam.

Estes são alguns fatos que tornam este mercado um pouco diferente e talvez expliquem por que existem tantos problemas.

O que eu queria deixar registrado aqui é que no meio de tudo isso, as pessoas é que fazem a diferença, elas são o ativo mais importante de uma empresa de desenvolvimento. Na minha opinião, em um nível mais alto, a valorização das pessoas é o suficiente para obter sucesso com desenvolvimento de software.

Se você dirige uma empresa de desenvolvimento, reflita o quanto você valoriza cada profissional. Busque dar as melhores condições de trabalho para todos. Não trate todos de maneira igual, respeite as diferenças de cada um. Invista em pessoas pois o seu retorno vai ser muito maior.

Se você trabalha em uma empresa que não valoriza o profissional, repense. Mostre aos gestores as diferenças de mercado, eu te digo, eles podem mudar o ponto de vista! Faça o que tem que ser feito e busque sempre trabalhar com pessoas boas. Trabalhar no meio de incompetentes é a pior coisa que você pode fazer por você.

Deixei aqui o que penso e os valores que eu de fato estou aplicando na minha vida. Espero que seja insumo para reflexão e discussão.

Abraços e até a próxima.