Estimativa não é aferição: Cuidado com as Mães Dináh do Software.

Para começar nossa conversa de hoje, vamos primeiramente discutir algo simples: o significado da palavra ESTIMATIVA.

Régua

Estimativa: s.f. Cálculo aproximado, avaliação; conjectura (Dicionário Aurélio).

Pois bem, estamos falando em cálculo aproximado, avaliação, conjectura, isso mesmo conjectura. Logo não é o mesmo que aferição, como é possível medir algo que não conhecemos por completo. A pergunta então é: Por que tantas pessoas se apegam nas estimativas quando estão em fase de projeto?

Eu diria que há vários porquês para esta pergunta, um deles é que o ser humano precisa de algo concreto, pelo menos em teoria para avalizar a construção de qualquer coisa, desde casa, por que não, até coisas mais complexas. Outro motivo plausível é que precisamos formalizar contratos, e por que não seguros. Isso mesmo, seguro, muitas pessoas vendem seguro, principalmente quando o assunto é prazo de desenvolvimento de software. É simples, eu te contrato para desenvolver uma solução que eu não quero desenvolver, pois tenho consciência que não é possível no prazo que eu estou te contratando mas se você não me entregar quem falhou foi você e não eu.

Outro motivo é porque estamos acostumados com as convenções formais de qualquer relação de trabalho onde de antemão tenho a necessidade de saber quanto tempo irá levar para fazer determinada tarefa senão sou incapaz de julgar se o resultado foi considerado aceitável, já que a única coisa que me interessa é o prazo. Escopo é fixo e qualidade não é mensurável neste cenário, ou seja, a borracha do processo chama-se Prazo!

Ken Schwaber, fundador da Scrum.org, fala em seu livro “Agile Project Management with Scrum” sobre as diferenças entre viajar entre duas cidades de duas formas distintas: Avião e Automóvel. Neste momento você deve estar se perguntando o que isso tem a ver com estimativa, logo aviso: Tudo!

spyker_f16

Na visão do Ken viajar de avião entre outras coisas é mais rápido, porém a grande “vantagem” é que se conhece “tudo” sobre a viagem, desde o clima, o trajeto, a velocidade de cruzeiro. Estima-se que um voo inicia exatamente no horário e termina aterrissando em seu destino no horário planejado.

Viajar de carro já não é tão minuciosamente planejado assim. Imagine quantas variáveis não são conhecidas de antemão, de repente você, dependendo do obstáculo que encontrar pode decidir-se por ir pela estrada A ou B. Se estiver chovendo tem a opção de parar em um posto para aguardar a chuva parar. Caso você encontre uma bela paisagem teria a oportunidade de vislumbrar a vista e aproveitar o trecho também para relaxar. Apenas uma coisa é certa neste tipo de viagem: a previsão de chegada irá mudar, seja em minutos, horas ou dias, tudo dependerá das condições encontradas e quanto mais longo for o trecho da viagem, maior será a chance dela mudar, e o motivo da mudança só será conhecido muito próximo dela acontecer, ou quando ela acontecer.

Neste momento é que alerto para a necessidade de sempre estarmos aferindo o que passou durante o projeto, claro que com o passar do tempo o time irá “azeitar”, conhecerá mais do Negócio, da linguagem, frameworks entre outras coisas. Porém existem sempre alguma variáveis que não podemos antever ou mesmo prever.

Conhecendo tudo isso que foi dito acima, como pode alguém julgar-se capaz de medir o trabalho a fazer antes de conhecer suas variáveis, seu caminho e tudo o que cerca o Negócio e reflete diretamente no projeto. Ora, não é porque já viajei de carro de Campo Grande/MS até São Luís/MA que posso afirmar com toda a certeza que numa nova viagem neste trecho, irei fazer exatamente igual a viagem anterior. Lembro que minha estimativa era chegar em 3 dias em São Luís, porém fiz em 3 dia e meio, pois tivemos um contratempo no primeiro dia e tivemos que adaptar tudo dali em diante.

Se até mesmo a Nasa, como já falei em outro Post no passado sabe que um projeto pode variar, por que eu, um simples desenvolvedor não vou usar do conhecimento que tudo muda o tempo todo no mundo para melhorar as minhas estimativas.

Responder a mudança (Manifesto Ágil) é sem dúvida melhor que planejar e seguir um plano, não que planejar seja desprazível não é nunca! Mas é necessário sempre saber quando algo mudou e o que é necessário fazer para adaptar-se de acordo com a mudança. Se alguma dessas mães Dináh do software quiser contestar fique a vontade, o debate é livre.

Outro ponto que deixo claro, é que, avaliar o sucesso de um projeto pelo prazo de entrega é simplesmente falta de habilidade e conhecimento e soa para mim como leviano. Lembre-se que pessoas não são enxadas, nem mesmo máquinas ou robôs.

Planejamento estratégico e disseminação da informação: O Sucesso depende do alinhamento entre os dois.

visao_estrategia_gestao_pessoasCom certeza você já ouviu falar em Planejamento Estratégico, pois muitas e muitas empresas falam sobre isso. Gestores adoram falar sobre este assunto e diretores amam dizer que tem tudo planejado e pode ser verdade, mas a base da pirâmide tem a visão do todo e qual é o seu papel dentro do plano estratégico?

A resposta é: Nem sempre!

Quando temos nossa visão clarificada e entendemos o que é esperado de nós enquanto parte da estrutura organizacional da empresa, fica mais fácil “vender” e colaborar para os projetos da empresa, pois fica claro a importância que temos dentro do processo de desenvolvimento, não apenas a nível operacional, mas também a nível estratégico.

Continuar lendo

O projeto mudou, e agora?

Perdido e sem direçãoParece até besteira, mas o que vou relatar aqui é uma narrativa de um fato que se assemelha a muitos outros, e que pode determinar o fim de um projeto e o fracasso de uma organização.

Uma empresa do ramo da construção civil contratou uma software house para desenvolver o ERP para atender suas necessidades, eram elas básicas: Controlar entrada e saída de mercadorias, realizar vendas, controlar patrimônio, emitir notas fiscais, controlar gastos com centro de custos, folha de pagamento, impostos, ou seja, quase todos os processos da empresa estariam neste ERP.

A equipe de vendas da software house ficou encantada com a oportunidade que se apresentava diante deles. Promessas e mais promessas foram feitas. Tudo o que os clientes queriam estava no “pacote“, nada iria faltar, os clientes teriam acesso total a tudo o que era necessário, milhares de gráficos e relatórios, indicadores até para a ração que os cães de guarda da empresa consumiam. Continue

Trazendo ordem a partir do caos

CaosO cenário é simples, uma empresa com projetos atrasados, qualidade baixa e entregas demoradas. Parece o panorama de uma empresa qualquer de software não só no Brasil, mas em qualquer lugar do mundo. Acredito que pode ser a minha empresa, a sua ou de algum amigo seu.

No primeiro momento é simples, há uma necessidade clara de maior controle sobre os prazos, sobre o andamento dos projetos, e principalmente sobre a qualidade e as entregas. Dentro desta configuração não se pode imaginar algo diferente, que não seja agir com mão firme, trazer as rédeas para junto do corpo e traçar metas para melhoras os indicadores da nossa empresa.

O grande desafio agora é com fazer isso, sem pressionar desnecessariamente os desenvolvedores envolvidos com cada um dos projetos. Com fazê-los pensar como empresa, sendo parte não apenas do problema, mas principalmente da solução.
Continue

Gerando alto valor agregado ao software

Muito tem se falado sobre gerar valor agregado, que o Backlog do produto tem que ser ordenado de forma a enfatizar os itens que tenham mais valor. Costumo ser muito questionado sobre o que de fato significa gerar valor agregado. Bem como não poderia ser diferente, tudo o que é executado dentro de uma Sprint deveria por definição ter seu valor, já que tudo tem um custo para ser realizado. Quando falamos em valor agregado, temos que pensar em três fatores: Primeiro qual o custo efetivo daquela porção de software, ou seja, quanto custará para construir aquele pedaço do sistema. Segundo, qual será o retorno que este incremento de software trará para o meu Negócio. Terceiro qual o tempo que levará até que eu tenha retorno sobre investimento que foi desprendido para criar o incremento.

Gráfico de valor agregado

Bom, você agora deve estar imaginando que tudo gera em torno do retorno financeiro que o software trará, correto?
Bem, valor agregado não é apenas dinheiro em caixa, e talvez seja ai que esteja a grande confusão, valor agregado pode ser algo que para você talvez não tenha tanto valor ou importância dentro do contexto do software, mas para o cliente, será algo que poderá talvez, mudar a vida dele. Continue