Olá amigos leitores do PTI!
Na matéria de hoje, coloco um dilema que já é clássico no mundo do gerenciamento dos projetos:
É mais importante atingir 100% do escopo ou cumprir um prazo? Ou os dois?
Vamos fazer uma analogia com situações do nosso cotidiano. Imagine que você foi a uma festa e conheceu a mulher da sua vida, passada uma semana vocês começam a namorar e estabelecem que em 2 meses vocês irão se casar e marcam a data do casamento na igreja. Pronto, a restrição de tempo foi criada. Agora será que dá para fazer um mega-evento, contratar decoração, músicos para a igreja, alugar o melhor buffet da cidade, DJ, elaborar e enviar convites para 345 pessoas, encomendar docinhos e lembranças, comprar viagem de lua-de-mel, tudo com qualidade em apenas 2 meses? Como o tempo era a restrição do casal, eles resolveram se casar apenas no civil e organizar um bela churrascada para os parentes, padrinhos e amigos mais próximos. Moral da história: o casal adequou o escopo do projeto (casamento) dentro da restrição do projeto (cronograma), sem sacrificar a qualidade.
Uma outra analogia, você resolveu se tornar um empreendedor e resolveu lançar um website de compras para bater de frente com grandes empresas como Submarino e Americanas.com. Você estabeleceu uma estimativa de prazo para concluir o website, porém, ele deve possuir o mínimo de funcionalidades que o torne competitivo e atrativo frente às grandes concorrentes. Acontece que aquele prazo estimado está chegando ao fim, e agora? Você lança o seu website, mesmo sabendo que ele não está pronto para fazer frente às grandes concorrentes? Ou prefere rever sua estimativa até ter um produto realmente competitivo? Moral da história: ter o escopo do projeto entregando valor era mais importante que cumprir um prazo.
Dados os exemplos acima, e voltando ao mundo dos projetos, podemos classificar as nossas entregas de projetos de duas formas:
1) Date-driven: É onde o tempo/cronograma é a grande restrição. Este tipo de entrega é bastante desafiador, pois talvez o escopo tenha que ser adaptado para entrega de valor e isso não é fácil, pois exige alguém com uma visão estratégica de negócio muito boa ! Nosso analista de negócio ou Product Owner deve ser dos bons.
2) Feature-Driven: Neste caso a entrega do escopo do projeto prevalece sobre o prazo. Claro, que não pretendo ser anárquico como muitos colegas agilistas que dizem que o prazo não importa. Mesmo em projetos conduzidos desta forma deve existir uma estimativa realista com sua variação (para maior ou para menor) aceita e compreendida por todos os stakeholders. Afinal de contas projetos são bancados com $$$ e $$$ não dura para sempre ! 🙂
Agora você me pergunta: “Mas Vitor, eu quero todo o escopo entregue dentro de um prazo. E aí?”
E aí que você pode ter 2 situações:
1) O escopo total cabe dentro do prazo estabelecido – Continua sendo uma entrega date-driven, sem haver necessidade de adequação do escopo.
2) O escopo total não cabe dentro do prazo estabelecido, mas tem que caber de qualquer jeito – Este caso ocorre de forma muito frequente e os gestores simplesmente não aprendem! É o famoso “me engana que eu gosto”. Você possivelmente elevará muito os custos do seu projeto, seja:
- Contratando um batalhão de pessoas para trabalhar, mesmo sendo comprovado que “nove grávidas não dão luz em 1 mês“, isso não significa de forma alguma que o projeto será entregue com QUALIDADE.
- Ou não se contrata ninguém e paga-se horas extras para a equipe, todo mundo trabalhando de 12 a 16 horas/dia. Fisiologicamente e psicologicamente, cada dia que passa o rendimento cai e a QUALIDADE do trabalho idem.
Aí sabe o que acontece quando o produto do projeto é entregue sem QUALIDADE? Surge a famosa “Fase 2” do projeto que os “fazejadores” de plantão tanto gostam.
Então amigos, entendam qual é a restrição do seu projeto e estabeleçam sua estratégia de entrega sem jamais deixar de entregar valor e qualidade.
Novo “triângulo de ferro” onde valor e qualidade são condições fixas do projeto e as restrições (escopo,tempo,custo) são varáveis.
Abraços e até o próximo artigo
3 Comentários
Caro Vitor.
Ótimo artigo!
O problema é que os gestores não brincaram quando eram crianças daquele joguinho em que voce tem de enfiar os blocos de figuras geométricas nos seus lugares respectivos nos espaços do tabuleiro.
Querem enfiar um triângulo em um circulo e não dá ! Daí , ou aparam as arestas para ele caber, deixando várias lacunas, ou aumenta o espaço para caber a figura, desfigurando o desenho original.
Com projetos é a mesma coisa : não ha nada que substitua o planejamento, o engajamento e se saber exatamente o que se quer, no prazo que se quer e no custo aceitável.
Parabéns.
Primeiramente parabéns pelo Post Vitor, na empresa onde estou estamos sofrendo com um legado terrível, ao meu ver sofreremos com isso por muito tempo, ou seja, o sistema da empresa foi desenvolvido pela equipe da própria empresa, possuímos um time de projetos e processos, onde cumprimos com os requisitos de documentação para iniciar um projeto, da maneira que rege às boas práticas, o grande problema é justamente o destino com dois caminhos, o primeiro sendo cumprido no melhor dos mundos já o outro totalmente quick wins, onde sofremos com a gestão de mudanças, devido o grande numero de incidentes abertos após o go live. Conclusão; se a TI realmente for muito bem gerenciada acredito que o entregável será de acordo com o esperado em tempo e qualidade, o oposto deste senário será uma grande calamidade, o backlog de projetos nunca será enxuta.
Forte abraço e sucesso.
Thiago Menezes
Parabéns,Vitor Massari,pela lucidez explicativa do seu texto,numa linguagem simples e objetiva.
Quem nunca estudou sobre isso,certamente sai do nível zero,com sua leitura,e sente vontade de saber mais.
Isto é educação correta.
Parabens,portanto.