[GPMPE-MH] - Quais premissas você cria para seus projetos? #11 - Alexandre Vignado
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
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%)
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.
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!
#GPMPE-MHágilgestão de projetospremissasriscosscrum
Previous Post:[GPMPE-MH] – Você quer ser um Gerente Híbrido de Projetos? #10
Next Post:Afinal, como estimar usando o Planning Poker?
Mais uma bela explicação Vignado! Parabéns pelo excelente conteúdo dos artigos, sempre estou atento as novidades. Obrigado!