Get best of the week

Como entender que um projeto é um projeto e executá-lo corretamente

Dois dias antes da demonstração. A equipe viu funcionalidades específicas - a integração de nosso produto com o Google Maps. A integração é vista "no joelho" - o principal é ter tempo para mostrar ao potencial cliente os recursos do sistema.

A demonstração passa e o cliente faz uma pausa para pensar.

Seis meses depois, os vendedores vendem outra solução com a integração do Google Maps para outro cliente. Bem, eles viram que, meio ano atrás, tudo funcionava na demo.

Qual é o problema aqui?

Eu trabalhei em diferentes empresas. Em algum lugar, ficou claro que faríamos esse projeto. Por que isso ficou claro? O cliente veio e disse: eu preciso criar esse sistema e o descreve. O gerente planeja quanto o projeto levará tempo e dinheiro, negociará com o cliente e trabalhará adiante. É - a carta patente, o plano do projeto, os riscos, o controle de qualidade e outros artefatos do projeto. Clara e compreensível.

Em outras organizações, o projeto foi lançado de cima - estamos fazendo isso e aquilo, levar as pessoas e partir. Menos extensões, mas também de forma clara e clara.

Terceiro, o mais difícil, com projetos não é fácil. Na minha opinião, há uma série de problemas sobre os quais é difícil julgar pelo meu nível. Tudo aconteceu como descrito no início - é mais provável que o projeto esteja morto do que vivo.

Que problemas surgem?

  • , — . , .
  • .
  • , .

A equipe do projeto começou a elaborar o plano de implementação e apareceram "de repente" nuances.

Um clássico do gênero, no entanto - nós e o cliente entendemos de forma diferente “integração”, por exemplo, ou o termo “auditoria”. Para eles, era uma palavra terrível associada a verificadores malignos e, para nós, um termo que significa funcionalidade.

Como resultado, o processo de implementação se traduz em um projeto de revisão. Formalmente, o projeto de carta não mudou; todas as metas de alto nível permaneceram as mesmas.

Como taxi? A principal tarefa é descobrir exatamente o que precisa ser feito, determinar prioridades, cronogramas, recursos, riscos, notificar todas as partes interessadas, preparar vários cenários de desenvolvimento. Como resultado - concordar com o cliente sobre a quantidade necessária que caberá no orçamento acessível.

As principais nuances - o projeto já foi vendido, já possui um orçamento e a quantidade de trabalho. Restrições bastante difíceis. Mas isso não significa que você precise engolir tudo e aceitar a verdade em primeira instância. Em 99% dos casos, você pode negociar, seja um cliente ou um patrocinador.

Começamos o projeto


Aconteceu que sou mais um defensor de planos claros. Waterfall e a abordagem PMI são similares em espírito, embora alguns aspectos do Agile não sejam estranhos.

Assim, o projeto começa e a prova de que o projeto é lançado é o termo de abertura do projeto. Para aqueles que são pouco familiares ou desconhecidos, explicarei que tipo de animal é esse.

De acordo com a ideologia do PMI, este é um documento que descreve as metas, prazos, orçamento, riscos e também dá autoridade formal ao gerente do projeto e, principalmente, determina o nome do projeto. Abaixo vou explicar o porquê.

Freqüentemente, a carta é preparada pelo gerente de projeto, acordado com o patrocinador, cliente e outras partes interessadas.

Em uma das empresas em que trabalhei, não havia uma definição clara do que era um projeto. Havia uma certa atividade, um certo fluxo, que era chamado de projeto, mas na verdade não era. Essa foi uma suposição. Ok, vamos chamá-lo de projeto e pelo menos decidir um nome para que todos entendam do que estamos falando. Houve confusão com os nomes, quando o patrocinador disse - “Qual é o progresso no projeto de integração de soluções?”, Então o chefe do departamento e o gerente pensaram em coisas diferentes. O chefe do departamento chamou esse projeto de "integração do cliente" e o gerente de projeto de "otimização do banco de dados". Todos pensavam em seu próprio nível.

O Agile não possui orçamento e prazos, mesmo os de nível superior, pois tudo é flexível e pode mudar a qualquer momento. Sim, o Agile pode estimar o tempo de conclusão, mas somente após várias iterações quando o desempenho da equipe é avaliado. Mas existem objetivos. Nós sabemos o que queremos fazer.

Vou dar um exemplo. Existem duas equipes de desenvolvimento. Ambos têm o mesmo projeto - desenvolver uma solução móvel para controle de qualidade de alimentos.

A equipe A trabalha no Waterfall. A equipe B trabalha no Agile. Diferentes abordagens para planejamento e desenvolvimento. Mas o objetivo é um. Então, por que não corrigi-lo no início? Qual é a probabilidade de a equipe B no meio do sprint entender que o cliente não precisa de um aplicativo para controle de qualidade, mas precisa de um aplicativo para gravar partidas de futebol? Muito pequenos, com maior probabilidade, eles alcançarão seu objetivo original.

NB: Estou fazendo uma suposição e falando sobre desenvolvimento personalizado, não sobre startups.

Com o nome, tempo, orçamento, mais ou menos claro. E os riscos?

O PMI se refere a isso formalmente. Na minha opinião, o processo de gerenciamento de riscos é uma coisa independente. Deixe-me explicar o que quero dizer.

O processo de gerenciamento de riscos consiste nos seguintes estágios:

  1. Identificação
  2. Análise
  3. Planejamento
  4. Monitoramento

Este é essencialmente um processo iterativo. É aplicável a operações e abordagens ágeis.

Ao iniciar um projeto, existe um risco global - ele pode falhar.
O livro de Edward Yordon, The Kamikaze Path, tem um pensamento interessante - vale a pena tratar qualquer projeto como um fracasso. Com essa atitude, você precisa construir uma estratégia de desenvolvimento, ou seja, pensar em um conjunto de ações que tornarão um projeto bem-sucedido uma falha.

Então, por que não se afastar desse pensamento e fazê-lo acontecer? Sim, existem poucos dados no início. Mas é por isso que são riscos de alto nível, para mostrar às partes interessadas o que pode dar errado.
Total - o rascunho da carta é um documento que permite que todas as partes principais cheguem a um acordo sobre uma terminologia, objetivos globais e riscos de alto nível. Todo mundo entende para onde estamos indo, o que queremos alcançar e o que pode acontecer de errado.

Estabelecimento de metas do projeto


Muitos gerentes de projeto iniciantes passaram por isso - é necessário elaborar uma carta e determinar o (s) objetivo (s) do projeto. E esses monstros nascem:

  • Desenvolvimento e implementação de um programa corporativo e sistema de gerenciamento de projetos para melhorar a interação entre departamentos;
  • Reciclagem do sistema de contabilidade tributária para otimizar o processo contábil;
  • Implementação de um sistema de controle de custos para aumentar o lucro dos departamentos.
  • Tais projetos não podem ser concluídos. Se você vir essa redação no regulamento, este projeto já está morto.

Por que um "sistema corporativo" aprimora a colaboração? Como o cliente entenderá que fez isso?

“Reciclando o sistema contábil” - vamos reformulá-lo, mas como? Mude os itens de menu na interface. Isso simplifica o processo contábil?

“Implementação do sistema de controle” - como entendemos que o sistema está implementado? Suponha que todos concordem que ela foi implementada, mas isso aumentará o lucro dos departamentos? E se não implementarmos nada, mas o lucro aumentar, por razões fora do nosso controle? Podemos assumir que o projeto atingiu seu objetivo?

Se formularmos os objetivos do projeto, esse deve ser um conjunto de objetivos: o que precisa ser feito especificamente e como entendemos que o fizemos? O que devemos ver, sentir? O que deveria mudar? Quais custos isso deve ser alcançado? Quando? Se existem vários objetivos, quais são suas prioridades. Pode acontecer que os objetivos dependam um do outro, ou pode acontecer que alguns objetivos sejam mutuamente exclusivos.

Definindo metas SMART


  • Específico - específico.
    O que nós queremos fazer? Algo para melhorar? E quanto?
  • Mensurável - mensurável.
    Podemos medir a meta em dinheiro, por cento, tempo economizado?
  • Realizável - realizável Temos recursos, conhecimentos, experiência e tempo suficientes para atingir a meta?
  • Relevante - relevante ou significativo.
    Aqui você precisa determinar o que é necessário para atingir a meta?
  • Tempo limitado - tempo limitado.
    Por quanto tempo o objetivo deve ser alcançado?

Exemplo: implemente um sistema de gerenciamento de projetos baseado no Project Server para 20 locais de trabalho do escritório do projeto usando um registro eletrônico de riscos e e-mails com a notificação automática de adiamento de prazos.

O sistema deve ajudar a reduzir o cronograma de cada projeto em 15% dentro de 2 meses após o lançamento.

O sistema deve ser implementado em 6 meses, o mais tardar em 15 de dezembro.

Já está mais perto, mas ainda é possível refinar.

Perguntas adicionais que você pode fazer:

  • O que deveria ser feito?
  • Por que você tem que fazer isso?
  • Quais benefícios o projeto deve trazer?
  • Todos estão familiarizados com este plano?
  • Todo mundo o entende da mesma maneira?
  • Todo mundo concorda com ele?
  • Quando você precisa terminar o trabalho?
  • Quem é o usuário final?
  • Que qualidade você espera receber?
  • Que funcionalidade é esperada?
  • Quais instalações estão disponíveis?
  • Quem controla o sucesso e por quais critérios?
  • O que não deveria acontecer em nenhum caso?
  • Que trabalho não pertence ao projeto?

As duas últimas perguntas são as chamadas "não metas".

Eles descrevem o que não é relevante para o projeto e o que não deve acontecer, pois isso interfere no andamento do projeto ou viola as restrições internas. Os resultados que não são relevantes para o projeto não devem ser caracterizados como prejudiciais, mas você deve estar ciente de que o cliente não paga por eles.

Sumário


Veja bem, existe uma certa quantidade de trabalho com certos contornos e há até uma linha do tempo e orçamento para isso? Com um alto grau de probabilidade, este é um projeto. Estamos negociando com o pessoal de vendas para que os gerentes e engenheiros estejam envolvidos no processo de vendas. Pelo menos como consultores - e eles trabalharão com isso.

Antes de começar, determinamos o nome do projeto e a terminologia. Escrevemos a carta e formamos metas claras e compreensíveis. SMART é o nosso tudo.

More articles:


All Articles