Fazer certo da primeira vez

Outro dia fui ao dentista e me deparei com uma frase na parede:
 "Porque nunca dá tempo de fazer certo... Mas sempre dá tempo de refazer?"

Traduzindo: não se preocupe se o tratamento dentário não funcionar na primeira tentativa. Na segunda vez, você ficará bem. Talvez seu dente incomode por um pouco mais de tempo, mas quem se importa?

Nunca imaginei que isto fosse uma prática além das fronteiras da TI. Fiquei surpreso pensando no meu novo bloco. Finalmente entendi porque o dentista fica ajustando o bloco até chegar em algo que me traga conforto. Quanto será que este processo torna o custo do bloco mais oneroso para o meu bolso? Quantas pessoas trocaram de dentista por este motivo?

Nada mais representativo ao que ocorre nos projetos de TI. O curioso é que ajustar ou  refazer é aceito com naturalidade pela equipe. Há um certo entendimento de que o usuário não transmite tudo que precisa e o analista não entende tudo que é transmitido. Assim, ambos acordam que, num segundo momento, o projeto vai se ajustar.

O efeito colateral negativo é que esta cadeia de imperfeições se alastra por todas as etapas do projeto. Como consequência este fica mais caro e com a percepção de baixa qualidade, mesmo que depois o produto final fique adequado. Perde-se a confiança no trabalho e, para garantir a entrega, diversos pontos de checagem, avaliação e homologação são criados. Já vi casos que se cria a conferência da checagem.

Portanto, se corrige com retrabalho algo que poderia ser feito certo desde o começo. Na minha forma de ver isto se conserta com um planejamento adequado de onde se quer chegar, da capacitação da equipe para realizar cada  etapa de trabalho e com a implantação de indicadores que meçam a qualidade do artefato entregue.

Com retrabalho todos perdem, e muito. E isto deveria ser mensurado para que as lições sejam aprendidas e os caminhos de correção sejam perseguidos.

Ilan Goldman: ROI previsto, ROI realizado

Ilan Goldman: ROI previsto, ROI realizado: ROI previsto, ROI realizado   Desde o meu primeiro projeto em desenvolvimento de software no estágio na Esso, em 1978, aprendi que a p...

ROI previsto, ROI realizado

ROI previsto, ROI realizado
 

Desde o meu primeiro projeto em desenvolvimento de software no estágio na Esso, em 1978, aprendi que a primeira tarefa a fazer antes de especificar qualquer coisa era definir o que a empresa teria a ganhar caso o software tivesse as funcionalidades desejadas pelos usuários. Me lembro bem que fazíamos uma lista de características, classificando-as como necessárias (e obrigatórias) ou desejáveis.

Assim nasceu o ROI na minha vida - Return On Investiment - que aliás nem sabia que se chamava assim. O fato é que sentávamos com os usuários para discutir os benefícios que a solução poderia gerar, fossem eles ganhos mensuráveis ou qualitativos.

Uma coisa que sempre me intrigou é que depois do projeto pronto e implantado ninguém queria saber se a mudança estava, de fato, gerando os benefícios previstos. É verdade que depois de pronto o investimento já teria sido realizado com a confecção da solução, mas ao menos a organização poderia saber o que de real foi obtido, para mais ou para menos.

Minha recomendação é que sempre se faça uma avaliação se o que foi plantado é o que está sendo colhido. Penso que deveria ser feita pelo menos seis meses depois do projeto implantado. Todas as partes envolvidas deveriam ser chamadas, ou seja, tanto a TI quanto os usuários. Nenhum é mais responsável do que o outro. Quando fazemos um projeto somos cúmplices e solidários.

Um outro ponto fundamental é o destino do projeto. Sim, porque todo projeto depois de implantado terá um destino. É o momento mais sensível e difícil do projeto. Este sai do holofote da empresa, crente que aquela situação está equacionada. Nananinanão! Aqui é que mora o perigo. Sempre há alguém a pedir mudanças que, na sua visão, vão ajudar a "melhorar" o projeto. Muitas vezes estas solicitações desvirtuam o objetivo do software, e mudam significativamente o propósito da solução. Isto porque a visão de quem solicitou não é compatível com o interesse da empresa. 

Minha segunda recomendação é controlar a ferro e fogo as demandas em projetos implantados, tratando-as com o mesmo rigor gerencial do projeto. A maioria delas é desnecessária e o custo é superior ao benefício que trará. Algumas podem simplesmente mudar completamente os rumos que a empresa desejava e colocar o processo em risco. Infelizmente, é isto que acontece na maioria das empresas.

Conhecimento faz a diferença

Conhecimento faz a diferença

O conhecimento sempre fez a diferença. 

Havia várias formas de codificar o conhecimento, mesmo antes da introdução do papel e, consequentemente, dos livros. Quem dominava os códigos de comunicação tinha uma superioridade sobre os demais. A própria história se conta a partir destes códigos.

Com a chegada do livro e da possibilidade de explicitar o conhecimento através de palavras registradas em papel, a educação floreceu e ganhou uma velocidade inacreditável. Se pensarmos que um estudante hoje aprende em cinco anos o que foi formulado e descoberto em séculos, temos uma boa idéia da diferença que o conhecimento disponível faz pela sociedade.

De certa forma, os aplicativos de computador são uma expressão de conhecimento.  Eles representam os processos que as empresas querem que sejam executados, e são desenhados para cumprir a tarefa. Diferente dos livros, os processos expostos nos aplicativos mais se parecem com o conjunto de códigos de antigamente. Mesmo assim ninguém duvida da sua importância para uma organização.

Portanto, é preciso mais para capacitar o profissional para obter o resultado almejado. Sem falar que nem tudo pode ser traduzido em aplicativos. 

Entendo que as empresas precisam construir os seus "livros", onde possam explicitar seu conhecimento e transmití-los entre seus pares para que haja continuidade e evolução. Da mesma forma que na educação, o conjunto de livros de uma empresa será o grande acelerador de produtividade e crescimento sustentável.

Acredito no conhecimento empresarial como fator diferencial. Não um fator secundário, mas o mais significativo que uma empresa pode almejar. Pensando nisto criamos o Pharos, a visão da Pix para a retenção e a difusão do conhecimento.

Se tudo que a empresa faz, da forma que considera a mais adequada, estiver explicitada num único local, acessível a quem interessa, é possível imaginar que não haverá fronteiras para onde se pode chegar. As empresas poderão evoluir a partir de experiências vivenciadas, sem retrabalhos e repetição de erros conhecidos.

Síndrome do "Deixa Comigo"

Síndrome do “Deixa Comigo”

Sei que este tema não é um privilégio da TI, mas pode causar impactos negativos no negócio quando se trata desta área. Vou explicar melhor: você passa uma tarefa para alguém com uma certa expectativa de retorno. Aí o trabalho demora, demora, demora, e quando você vai ver, pouco ou nada foi feito.

“O que houve?”, você pergunta.

“Estava tentando encontrar a solução mas não consegui.”

“E porque não pediu ajuda?”

“Para não atrapalhar o seu trabalho.”

“Ou seja, você só está decidindo quando atrapalhar, certo?”

Para enfrentar esta situação recomendo algumas práticas, que vão desde o acompanhamento frequente das tarefas previstas, principalmente com iniciantes e reincidentes, até a adoção de uma SLA – que corresponde a um compromisso de atendimento a um determinado incidente, num prazo máximo combinado. Se não houver mecanismos para a cobrança do trabalho antes mesmo de sua conclusão, e de alertas para a intervenção do gestor, dificilmente os prazos serão alcançados, os projetos concluídos e os acordos respeitados.

Mais importante do que projetar o tempo para um trabalho é ter as ferramentas e a gestão para acompanhar a sua realização. Ninguém nasce sabendo, ainda mais numa área onde é preciso ter os mais diversos conhecimentos, dos processos de negócio, da modelagem da solução, das técnicas de desenvolvimento, e dos impactos com os demais processos da empresa.

O processo de aprendizado no caso da TI é através da capacitação, e não pelo método de tentativa e erro.

Uma boa dica para acompanhar o que acontece na sua TI é “no news is not good news”.

Entregar o que promete

Entregar o que promete

Quando resolvi escrever meu primeiro blog já tinha listado mais de 50 temas sobre a minha experiência em implantar projetos nas empresas. Aprendi que devemos começar pelo que é mais importante e elegi aquele que é o meu guia, a minha obsessão.

Quando um usuário precisa da TI para resolver uma situação, ele se senta com o analista e descreve o seu processo. Cuidadosamente, trocam informações que vão resultar numa proposta de projeto. Existem várias formas de formalizar o entendimento. Para mim, o que dá melhor resultado é quando o analista descreve o processo que se propõe a implementar. Este documento deve ser revisto por todos os envolvidos até chegar a uma versão final, devidamente aprovada.

A partir deste momento há uma cumplicidade entre as partes. O contrato, representado pelo documento, foi estabelecido e tem que ser cumprido. Entregar no prazo, no custo, com qualidade e com as funcionalidades prometidas é a meta a ser implacavelmente perseguida. Qualquer desvio, seja mudança ou barreira, deve ser comunicado imediatamente, para que a confiança seja mantida.

Descobri que entregar o que foi prometido é a principal razão do sucesso do projeto. Mesmo que, depois de implantado, apareçam situações não previstas – e sempre surgem. Porém, ninguém duvida que estão todos comprometidos com o resultado final.

Na Pix a orientação é para descrever qualquer mudança solicitada, por menor que seja, e enviar para revisão e aprovação pelo usuário. Chamamos este procedimento de Cenário. Depois é só entregar o que prometemos. Funciona.