Profissionais TI - Pra quem respira informação

Leia também outros artigos da série: Artigo 0, Artigo 1, Artigo 2, Artigo 3, Artigo 4, Artigo 5, Artigo 6, Artigo 7, Artigo 8, Artigo 9, Artigo 10

O número de premissas que criamos para um novo projeto está diretamente ligado ao quanto sabemos sobre ele. Quanto menos sabemos, mais premissas são criadas.

O fato é que no início de qualquer projeto consideramos sempre estas premissas como válidas. Porém, se você já tem uma experiência em gerenciamento de projetos sabe que nem sempre isso se mostrará verdadeiro ao longo e término do projeto.

Existe uma linha tênue entre o significado de premissa e achismo.

Achismo: substantivo masculino; Teorização fundada no subjetivismo do ‘eu acho que‘ (aplicável a qualquer campo teórico); achadismo.

Premissa: substantivo feminino; cada uma das proposições que compõem um silogismo e em que se baseia a conclusão. Origem:  ETIM lat.escl. praemissa ( sententia ) ‘(proposição) colocada antes‘, fem.substv. do part.pas. depraemittĕre‘colocar antes’

• silogismo: raciocínio dedutivo estruturado formalmente a partir de duas proposições (premissas), das quais se obtém por inferência uma terceira (conclusão) [p.ex.: “todos os homens são mortais; os gregos são homens; logo, os gregos são mortais”]

Muitos utilizam o ‘achismo‘ pensando (achando) que estão escrevendo ‘premissas’. Exemplo:

• Eu acho que no dia da festa de casamento não vai chover, então vou considerar a premissa “Não irá chover no dia da festa” para que eu não tenha que me preocupar com gastos de cobertura e ainda economize fazendo a festa ao ar livre.

Isso é achismo puro! Sem fundamento algum! E o pior: a premissa foi criada APENAS para justificar um orçamento menor para o projeto. Aposto que você já recebeu projetos para gerenciar com premissas assim, não é mesmo?

Premissas são usadas o tempo todo no mundo de negócios. Usamos para saber como determinada pessoa irá agir no escritório após contratação, para definir preço ou demanda por um produto, para imaginar como o público irá reagir a determinada campanha de marketing. Não importa o quanto sua equipe é boa: continuaremos a acertar algumas destas previsões ou premissas, porém, deixaremos escapar outras, criando riscos em potencial para nossos projetos.

Mas então como criar uma premissa? Veja o mesmo exemplo, porém, criado da forma correta:

• Premissa: “Não irá chover no dia da festa”
  • Justificativa: Considerando o histórico de chuvas dos últimos 10 anos na semana em que ocorrerá a festa de casamento, existe a possibilidade de 5% de chuva.
• Risco associado: Pode chover no dia da festa
  • Probabilidade: Baixa (5%)
  • Impacto: Alto
  • Ações:
    • Acionar Gatilho: Acompanhar nas 3 semanas que antecedem o evento as condições meteorológicas na região.
    • Reservar R$X,XX para o aluguel de uma cobertura e mudanças de decoração.
    • Considerar a inclusão de um requisito “O restaurante onde será o jantar DEVE possuir espaço para realização de cerimônias” (pois se chover, a cerimônia poderá ser transferida para dentro do restaurante)

Toda premissa deve ter um risco associado. E este risco deve ser monitorado e tratado! É por isso que o gerenciamento de riscos e a análise de requisitos em um projeto não deve ser subestimada. Você verá que neste processo muitas premissas deixarão de existir para tornar-se apenas riscos, restrições ou requisitos.

Durante um projeto você já assumiu que uma entrega do seu projeto estava pronta, sem validar adequadamente? Achou que algum requisito foi atendido sem consultar os envolvidos adequadamente? Espero que não, pois este achismo, erroneamente chamado de premissa pode condenar o seu projeto, uma vez que muitos projetos falham justamente por premissas consideradas verdadeiras antes mesmo do início do projeto.

Lidando com o desconhecido

A incerteza não deve ser justificativa para assumirmos uma verdade sobre algo. É o mesmo que dizer que ‘o céu é azul‘ porque ‘Deus quis“.

Quando utilizamos metodologias ágeis, como Scrum, podemos trabalhar com um certo grau de incerteza. E podemos aplicar isso em qualquer tipo de projeto.

“Mas e projetos de construção? Não podemos começar a construir um prédio sem saber o que vamos construir com antecedência!“. É verdade, mas o que é prioritário na construção de um prédio? Definir o número de andares e estrutura do mesmo ou a cor do azulejo do banheiro da suíte? Podemos apenas assumir a premissa que teremos azulejo no banheiro e detalhar isso depois.

Em um projeto tradicional (waterfall) você precisaria se preocupar com:

• A Definição de Pronto – Como o dono do projeto irá considerar o projeto entregue, no ponto de vista dele.
• Todas as fases do projeto
• Como fazer a transição entre as fases – entender quando você estará pronto pra avançar no projeto
• Quais serão os testes que serão feitos/realizados
• Partes interessadas e suas funções (incluindo gráficos de impacto ou influências)
• Plano de comunicação, como serão as reuniões e modelos de status report – incluindo a frequência e os responsáveis
• Ferramentas e processos – Levantamento de requisitos, acompanhamento de tarefas, automação de testes, comunicação, gestão de mudanças, etc…

Seria incrível se tudo isso estivesse pronto e fosse conhecido no começo do projeto, mas nem sempre (ou nunca) isso é possível. Você raramente consegue ter todos estes detalhes no início do projeto, mesmo se for um projeto de atualização de um produto que você já trabalhou anteriormente.

Quando começar o projeto deixe claro à sua equipe as informações que estão faltando e identifique quem são os responsáveis por completar estes dados. Você pode não conseguir todas as respostas na hora, mas você saber quem pode lhe fornecer a informação correta é a chave de sucesso do seu projeto. Você precisa se comunicar com sua equipe, mostrando estas informações (e a falta dela) ao invés de você, sozinho, criar premissas e achismos sobre como sua equipe irá trabalhar.

E você? Quais premissas você costuma criar nos seus projetos e como você gerencia?

Espero que tenha gostado do artigo e que deixe seu comentário sobre o assunto. Vamos compartilhar conhecimento e ajudar nossos colegas a reduzir as premissas incorretas nos projetos!

Leia também outros artigos da série: Artigo 0,Artigo 1, Artigo 2, Artigo 3, Artigo 4, Artigo 5, Artigo 6, Artigo 7, Artigo 8, Artigo 9, Artigo 10

Publicação Original: http://www.vignado.com.br/?p=574