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.

Pessoas não são ferramentas! Não compare pessoas a enxadas.

Parece absurdo o título do post, mas infelizmente na Gestão dos dias de hoje existem gestores que acreditam sim que pessoas são recursos, ferramentas e que podem ser comparadas a, por exemplo, uma enxada.

ENXADAVamos aqui fazer uma analogia barata: Uma enxada quando nova necessita de pouca coisa para executar o seu trabalho, se formos puristas veremos que ela necessita apenas de um bom fio de corte que se consegue usando uma lima de preferência nova. Enxadas tem funções específicas, como carpir quintais, como dizíamos em Pirajuí, minha cidade natal. Sempre que o corte de uma enxada estava ruim,  era necessário pegar uma lima e voltar ao início, refazer o fio até que ele ficasse pronto para continuar o trabalho exatamente de onde parou e com a mesma eficiência (levando em conta que o trabalhador não se cansasse né).

Uma enxada nem sempre funciona como deveria, às vezes é necessário trocar o cabo, pois este não aguenta e o que é feito senão trocar o cabo, ora, se uma equipe não está bem, troca-se o líder e pronto, tudo está resolvido, concordam? Eu não, mas tem gente que irá concordar.

Outro ponto interessante desta analogia é o fato que todas as enxadas são iguais e fazem o que deveriam fazer. Para alguns gestores pessoas são assim, contratadas para fazer o que recebem para fazer e só isso, pois quem nasceu para ser enxada nunca chegará a machado e por ai vai. Mal gestores esquecem que a empresa e não eles investem tempo em treinamento entre outras coisas para tronar o profissional apto para trabalhar.

E quando uma enxada fica velha, basta trocá-la por uma nova, amolar até que o fio de corte fique a contento e pronto! Temos uma enxada novinha pronta para ser usada e continuar exatamente de onde a outra parou, sem maiores prejuízos.

Infelizmente existem gestores que veem pessoas como esse tipo de ferramenta, que não é capaz de crescer, evoluir e melhorar como pessoa e profissional, e por pensarem assim não investem nas pessoas, pois quem investe algo em uma enxada velha não é mesmo? Gestores deste tipo pensam ser autossuficientes e extremamente necessários nos processos da empresa e perdem a oportunidade de fazer com que seus liderados cresçam e desenvolvam-se, levando ao crescimento como consequência a própria empresa.

Uma vez postei no Facebook que Gestão de TI é balela, o que existe, ou deveria existir é uma boa Gestão das Pessoas que fazem a TI e recebi algumas críticas por ter postado isso. Agora pensemos bem, existe esse Recurso chamado Humano? Ou Gestão de pessoas é mais que trocar pessoas/enxadas velhas por novas. É entender os estágios de formações de times que performam, ou é simplesmente culpar A ou B pelo fracasso de determinado projeto, e dispensá-lo como se fosse uma enxada gasta e sem utilidade.

Perceba que quando formamos times ganhamos a oportunidade de crescer com eles e conhecer os seres humanos que vem de brinde quando incorporamos o profissional a nossa empresa. gestão de pessoas

Não gosto mesmo do termo Recursos Humanos, acho arcaico, assim como o termo gerente para mim perdeu todo o sentido quando me vi em projetos ágeis onde pessoas comprometidas faziam que era necessário para entregar o projeto ao cliente e vê-lo satisfeito. Não acredito em super-herói, portanto não acredito na figura de um ser que sabe tudo, que tem todas as respostas que manda e os outros obedecem  não porque sou insubordinado, mas sim porque sei o valor da opinião alheia, dos diferentes pontos de vista e que discussões sadias levam ao sucesso, sei o valor com companheirismo e entendo como um time pode performar, não porque alguém está com um chicote açoitando, mas sim pelo senso comum e comprometimento com o resultado.

Pessoas não são de forma alguma recursos, são patrimônio e tenho pena de quem pensa diferente disso.

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

xadrez_estrategico

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

Qual o papel da TI na sua empresa?

Depois de um longo e não tão tenebroso inverno, ou verão whatever!!! Cá volto eu a escrever algumas linhas sobre esse assunto que é demasiado extenso, mas vale muito a pena discutir. Este post não tem a pretensão de se simples, longe disto, mas sim causar uma reflexão para o verdadeiro papel da TI nas empresas atuais.

A TI operacional

A TI operacional

Continue

A mensagem do Coringa

Um dia destes assistindo talvez pela décima vez o filme “O cavaleiro das trevas”, me deparei com o momento em que o Coringa se confronta Harvey Dent no hospital de Gothan e um diálogo quase monólogo ocorre. As palavras do Coringa me levaram a uma reflexão muito interessante, que decidi compartilhar com os amigos. Eis abaixo o trecho que levou-me a reflexão:

“Eu só fiz o que faço de melhor.
Eu peguei seu planozinho e o virei contra você.
Olha o que eu fiz com essa cidade, apenas com alguns galões de gasolina e umas balas.
Hum….?
Sabe… Ninguém se apavora se tudo acontece como o planejado.
Mesmo se o plano for aterrorizante! Se amanhã eu for até à imprensa e dizer que um caminhão cheio de soldados explodirá, ninguém se aterroriza, porque é tudo parte do plano.
Agora, se eu disser, porém, que um prefeitinho velho vai morrer… todo mundo perde a razão!
Introduza um pouco de anarquia, mude a ordem pré-estabelecida, e tudo se torna caos.
Eu sou um agente do caos. E sabe o que é bom no caos? O MEDO. “

O que isso tem a ver com agilidade você deve agora estar se perguntando. Eu respondo da seguinte forma:

O Manifesto Ágil deixa claro que é mais importante Responder a mudanças que seguir um plano, e o que os planos tem em comum, simples, todos têm a falsa ideia de caminho perfeito para alcançar um objetivo. O que temos visto por ai são cenários onde o plano deve ser seguido a risca para que o objetivo seja alcançado e o projeto obtenha o tão sonhado Sucesso.

Agora deixe que algo interfira no plano perfeito que foi traçado e veja o caos se instaurar. É isso o que ocorre em muitos projetos e que por falta de flexibilidade quando se deparam com o cenário não antes previsto e por fim acabam falhando. Não estou falando de gestão de riscos, mas bem que poderia ser. Óbvio que não iremos prever tudo o que pode ocorrer em um projeto, isso é ilusão, como já falei em um post anterior.

Ser ágil é responder a mudança, não quer dizer que o plano inicial seja alterado o tempo todo, mas sim que, se caso algo necessite de ajuste e acredite, vai precisar, é estar preparado para tal mudança, mesmo que o tempo para tal parece ser tardio. E se o negócio exigir uma mudança? E se o cliente simplesmente mudar de ideia? Claro que não precisamos traçar planos para cada uma destas hipóteses, até mesmo porque seria insanidade, mas é bom ao menos estar preparado caso necessário for.

Não defendo aqui que os planos são ruins, apenas que devemos ter cuidado para não seguir demais um plano, agarrando-se a ele de forma a perder de vista os reais propósitos que levaram a existência o próprio plano! Da mesma forma vejo muitas pessoas mais preocupadas em fazer Scrum, XP ou Kanban do que fazer software, isso é um erro absurdo, basta lembrar que existe antes de tudo isso o Manifesto Ágil, que “rege” a agilidade antes que qualquer método. Qualquer método pode ser substituído por outro mais eficiente em um determinado contexto. Os métodos ágeis são sim derivados das experiências e dos princípios que são na minha visão mais importantes que qualquer método.

A pergunta que devemos responder é, se algo mudar, como eu agirei? Sabendo a resposta e lembrando que devemos estar sempre atentos à mudança e aceitando mesmo que tardia, não nos tornamos reféns dos nossos planos e se por acaso alguma coisa der errado, não iremos nos desesperar por conta disso.

Aceitar a mudança acredite, faz parte do plano!

Até a próxima.

A importância da meta.

Em vários projetos, não apenas ágeis, metas identificam pontos de verificação e validação do que está sendo realizado dentro de um projeto. Para projetos ágeis, especificamente utilizando Scrum, a meta é a razão de existir de uma iteração, também conhecida como Sprint. Se olharmos para o Scrum como um jogo onde o ideal é vencer e para vencer a meta dever ser alcançada, fica claro a importância de uma meta clara e atingível. Mais ainda, sem uma meta, não faz o menor sentido por exemplo, ter uma reunião diária, que serve para o time sincronizar os esforços e verificar o quanto longe está justamente da meta.
Meta para times Scrum
Assim como no futebol a meta é fazer o gol, no Scrum a meta deve ser entendida por todo o time Scrum e todos sem exceção devem jogar o jogo para vencer e tendo sempre em mente aonde querem chegar e porque a meta é importante para a Sprint e por consequência para o Produto. A analogia pode ser feita da seguinte forma também: Um produto pode ser considerado como um campeonato e as Sprints comparadas às partidas que são jogadas para que o time vença o campeonato. Pode ser que às vezes percamos alguns jogos, mas o campeonato é sempre mais importante que os jogos. Desta forma podemos ver que a Visão do Produto nada mais é que a meta maior que permeia o desenvolvimento, guiando o time à vitória final. Continue