Prioridades 2: As Origens

Sequência do papo sobre “Prioridades & Banalidades“.

Se uma organização não sabe o que quer e não tem a mínima noção do caminho que pretende trilhar, então não podemos esperar que a equipe de projeto saiba dizer o que é prioritário em seu trabalho. Os ventos mudarão diariamente e o barco vagará a esmo. Até afundar, que é o que costuma acontecer com muitos projetos, particularmente de TI.

Nas turmas do FAN eu costumo recomendar o seguinte: se a estratégia, se o valor do projeto não está claro para clientes, patrocinadores e usuários, então é melhor nem começar o trabalho. Se não atacar o quanto antes as dúvidas e ambiguidades, que provavelmente são fruto de sérios problemas de comunicação, a equipe estará assimilando riscos que dificilmente terá condições de administrar quando o projeto ganhar ritmo.

Mas é curioso que até em empresas que apresentam um processo de planejamento aparentemente robusto as equipes tenham dificuldade de definir suas prioridades. Em dado momento as organizações elaboram e refinam seu portfólio de projetos. Em algumas o horizonte é de um ano ou mais. É a estratégia da empresa, sua Visão, que norteia o processo e ajuda a definir os projetos prioritários. Seria de se esperar que as mesmas informações que guiaram esta tomada de decisão sejam utilizadas pela equipe de projeto. Surpreendentemente, não é o que acontece em diversas organizações.

Em algumas há a definição de que esse tipo de informação é sensível e merece sigilo. O que desemboca no engano de achar que uma equipe não precisa saber o que o negócio ganhará com o projeto. Pode parecer absurdo, mas já vi clientes e usuários urrando: “Você não precisa saber disso!”. Como não? Quem pensa assim ignora que os desenvolvedores tomam dezenas ou até centenas de decisões por dia. Decisões que afetam o negócio de uma forma ou de outra.

Em outras organizações – que interpretam de maneira diferente o mantra “Informação é Poder” – os problemas com a definição de prioridades são outros. A equipe não é municiada com requisitos do negócio simplesmente porque não pergunta por eles. São diversos os fatores que ajudaram a criar essa alienação. Um dos principais, desconfio, é a mentira que diz que “tudo é para ontem”. E, se a pressa é grande, por que cargas d’água um analista perderia tempo tentando entender as motivações do projeto? Eles vão direto ao que interessa, aos requisitos que brotam e lotam listas. O problema é que esses requisitos, desprovidos de sentido, dizem muito pouco sobre o caminho que a empresa espera tomar. E fica simplesmente impossível que a equipe saiba dizer o que é prioritário.

Sabe o que é estranho e paradoxal nessa lenga-lenga toda? É que normalmente o entendimento dos objetivos do negócio não rouba nem 30 minutos de um analista de negócios. O não entendimento costuma roubar muito mais.

.:.

Novamente surrupio uma foto da Tanakawho, “Indecision at the last moment“. O surrupio é legal!