Gerenciamento de projetos por tempo fixo, orçamento fixo, escopo flexível (FFF)

Não é um sonho de qualquer proprietário de empresa gerenciar um produto de TI de forma a entregar o produto no prazo, ultrapassando os concorrentes e fazê-lo com alta qualidade, encantando os usuários? Eu gostaria de encontrar uma bala de prata para controlar e parece estar lá. Não tão prateado e nem tanto uma bala, mas uma abordagem bastante confiável e comprovada de gerenciamento, que pode ser chamada de FFF: Fix Time and Budget, Flex Scope.



Por que e quando você deve escolher FFF? Vamos dar uma olhada.



1. Três combinações



Cada uma das abordagens de gerenciamento de projetos é essencialmente diferente, na medida em que fixa ou não os seguintes valores: orçamento, escopo de trabalho, prazo e qualidade interna do sistema.





Uma combinação específica cria certas condições de trabalho, tem prós e contras:



  1. Preço fixo



    • Três pontos do triângulo do projeto são fixos: tempo, dinheiro e quantidade de trabalho.
    • Os principais riscos são assumidos pelo contratante e, por isso, esses riscos estão refletidos na avaliação. Além disso, os riscos são criados para o cliente, escrevi sobre isso no artigo 12, problemas ao trabalhar em uma atribuição técnica em um produto de TI .
    • Uma grande vantagem dessa abordagem são os parâmetros do projeto predefinidos antes do início do trabalho. Muitas vezes, a empresa / governo precisa especificar o prazo, o dinheiro e a quantidade de trabalho no contrato.
    • . , . , .
    • .
  2. Time and Materials (T&M)



    • , - .
    • .
    • , .
    • , . , , .
    • .
    • ( , Product Owner'), , , , .
  3. Fix Time and Budget, Flex Scope (FFF)



    • : , .
    • .
    • , , .
    • , .
    • , , . .
    • : , / , .
    • , .. . , , , , , , .


– , . , «», , , . . , , SonarQube. Podlodka.



2.



Por que essas três combinações são formadas? Por que não podemos consertar tudo? Afinal, o mais simples é fixar o orçamento, escopo de trabalho, data de lançamento e qualidade interna do sistema, assinar um acordo (se o cliente for interno, então passar pelo procedimento de aprovação com as partes interessadas) e fazer o trabalho com acerto preciso nos quatro valores. Mas, como mostra a prática, há um problema fundamental que não torna fácil percorrer esse caminho sem distorções.



Ninguém tem problemas para calcular o orçamento, é muito fácil calcular a data de lançamento e existem muitas métricas e listas de verificação para definir um nível específico de qualidade para um produto de TI. É tudo simples se você puder estimar com precisão o escopo do trabalho. Em outras palavras, se houver uma lista detalhada de tarefas e uma estimativa precisa dessa quantidade de trabalho, as outras três quantidades são facilmente calculadas. Por outro lado, se não houver uma estimativa exata, o restante dos valores também serão imprecisos, porque se baseiam em uma estimativa da quantidade de trabalho.



Sempre há problemas com a estimativa do escopo do trabalho, porque não existe uma metodologia de estimativa única que funcione com precisão aceitável. Todos os métodos se baseiam na experiência anterior de uma equipe que fez coisas semelhantes, o que em última análise significa imprecisões, porque as pessoas são imprecisas: emocionais, otimistas, esquecidas. A falta de uma metodologia de avaliação precisa é o primeiro fator que nos impede de entrar na avaliação da quantidade de trabalho.



Escrevi mais sobre esse problema no artigo Satisfação do cliente para programadores: Todos os programadores são otimistas . Há um link para o relatório 36 de Vadim Makishvili, onde ele propõe simplesmente multiplicar a pontuação por 3. Usando a metáfora de estabelecer e ultrapassar a rota, está escrito no artigo Por que os projetos de TI demoram 2-3 vezes mais do que o planejado? ...


No decorrer do trabalho em um produto de TI, eles mudam: a lista de tarefas que precisam ser realizadas, a profundidade de sua elaboração, a abordagem do design do sistema. Isso acontece sob a influência do ambiente externo: mudanças no mercado, mudanças na estratégia da empresa, mudanças na política dentro da empresa, feedback dos usuários, novas introduções daqueles que ficaram em silêncio na fase de análise, e posteriormente decidiram falar, etc. Nossa incapacidade de influenciar as influências externas é o segundo fator que nos impede de entrar inicialmente na avaliação.



O terceiro fator é que não há critérios para determinar o alcance da completude ao descrever o escopo do trabalho. A escrita do TK não pode ser finalizada, apenas interrompida. Escrevi sobre isso em detalhes no artigo Quando é hora de parar de escrever os Termos de Referência .



Devo fazer uma reserva de que tudo isso é verdade se você trabalha em uma área bastante complexa: de acordo com a estrutura do Cynefin, essas são as áreas Complexa e Complicada. Se o seu projeto entrar no Óbvio e, ao mesmo tempo, for bastante curto, você provavelmente estimará a quantidade de trabalho com muita precisão.


No total, temos que a raiz do problema está em uma estimativa imprecisa do escopo do trabalho e na impossibilidade prática de tornar essa estimativa precisa, portanto:



  • Projetos de preço fixo sacrificam a qualidade interna do sistema, pois é quase impossível fazer uma estimativa com três picos fixos. Ou, nos mesmos projetos de preço fixo, eles re-orçam tantos riscos para cobrir quaisquer imprecisões na avaliação, o que é ineficaz.
  • T&M , . Product Owner'.
  • FFF , , « » , T&M.


3. ?



Se for impossível estimar o escopo do trabalho com precisão suficiente, talvez nem um pouco? Existe esse movimento #NoEstimates. Em suma, organizamos o processo de desenvolvimento de forma a realizar as tarefas da forma mais eficiente possível, desde a fase de ideia até a implantação na produção e, ao mesmo tempo, manter uma alta qualidade interna. Eles oferecem organizar o processo usando Kanban com controle de métricas de processamento de fluxo e atenção especial para melhorar o processo de entrega de novos recursos. Avaliações prematuras são consideradas prejudiciais, avaliar e limpar o backlog é uma perda de tempo.



Onde aprender mais sobre #NoEstimates:



  1. David Anderson fala muito sobre isso, por exemplo, em sua palestra The Alternative Path to Enterprise Agility .
  2. Askhat Urazbayev falou na AgileDays em sua palestra #NoEstimates: Desenvolvimento não avaliativo .
  3. Ron Jeffries escreveu sobre isso no artigo Some Thoughts on Estimation .
  4. Denis Stebunov escreveu sobre isso em Habré no artigo On Estimates of Terms in Software Development .


Eu sou tanto a favor dessa abordagem. Gosto dele como engenheiro e como líder. Mas a vida é organizada de forma que os donos do orçamento precisam de uma estimativa, pelo menos nas primeiras etapas do trabalho, pelo menos aproximada. Na Byndyusoft, às vezes passamos para #NoEstimates, mas só depois de um relacionamento bastante longo com o cliente e isso nem sempre acontece.



4. FFF - equilíbrio entre flexibilidade e previsibilidade



Embora as notas estraguem a vida e sejam uma perda de tempo, é difícil começar sem elas. É claro, entretanto, que nenhuma estimativa será precisa. Acontece que a melhor opção é fixar o prazo e o orçamento para que a empresa possa conviver com isso e deixar o volume de trabalho flutuando. Além disso, o cliente e o contratante devem concordar que a cada momento a equipe está engajada apenas nas tarefas mais importantes e necessárias, e o cliente dedica tempo para monitorar a dinâmica da escolha das prioridades.



A primeira vez que vi a descrição de FFF foi em Getting Real by 37signals no capítulo Fix Time and Budget, Flex Scope . No momento, na minha empresa, esta é a abordagem de trabalho mais popular, tanto os clientes quanto nós estamos satisfeitos com isso.



5. Qualidade interna do sistema



Como escrevi acima, trabalhar no FFF é possível se a empresa tiver desenvolvedores competentes e capazes de garantir a alta qualidade interna do sistema. Isso geralmente é feito automatizando tudo e todos, criando listas de verificação de práticas recomendadas, revisando constantemente o código e a arquitetura, todos os tipos de teste e, o mais importante, recrutando as pessoas certas para a equipe.



Por que não esquecer a qualidade interna, escreve o blog de Martin Fowler, Software de alta qualidade vale o custo? ... Escrevi sobre isso no artigo Determinando o fracasso de um projeto de TI... Em suma, com o FFF, mudanças na direção do desenvolvimento do produto são assumidas, e isso implica flexibilidade suficiente do sistema. Se a qualidade do sistema for baixa, então cada "virada" retardará o desenvolvimento e aumentará seu custo, até a parada total do projeto.



Se você quiser trabalhar de acordo com a FFF, coloque os critérios de qualidade no contrato para corrigi-los com certeza.



6. Motivação do cliente e do contratante



O trabalho da FFF proporciona a motivação certa por parte do cliente e do empreiteiro. Diferentemente do Preço Fixo, onde o cliente e o contratado se comunicam por meio da interface do contrato, e ao contrário do T&M, onde o cliente pode perder limites e gastar mais do que o necessário; na FFF todos têm que investir em comunicação e “viver” no projeto para fazer o mais importante e ao mesmo tempo cumprir os termos do contrato.



7. Escolha FFF



Preço fixo e T&M têm suas vantagens em certos contextos:



  1. Se você está participando de uma licitação e se compromete a concluir um trabalho específico dentro do prazo e dinheiro acordados, enquanto a comunicação é principalmente construída por meio de um contrato, o preço fixo é provavelmente a melhor opção.
  2. Se o cliente sabe exatamente o que precisa e sabe como construir efetivamente o processo de trabalho, então ele só precisa comprar recursos da T&M e dispor deles a seu próprio critério.


No entanto, em igualdade de circunstâncias, tentamos escolher FFF. Esta abordagem parece ser a mais equilibrada: reduz os riscos do cliente e do contratante, cria a motivação necessária de ambas as partes e zela pela qualidade interna do sistema.



Links:



  1. Como e quais termos de referência devem ser escritos ao trabalhar no Agile .
  2. O princípio da gestão de projetos no gabinete de design de Artyom Gorbunov.



All Articles