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.