Os 12 Princípios Frágeis (da Gestão Tradicional de Projetos)

Este post não tem tags.

Compartilhe:

Os doze Princípios Ágeis foram criados pelos autores do Manifesto Ágil, um pouco depois da reunião na estação de esqui de Utah que deu origem a todo esse movimento, em 2001. Eles podem ser lidos aqui.

Ao ler os Princípios Ágeis, eu sempre imagino cada um deles se contrapondo diretamente a um pensamento ou forma de trabalhar predominante na época em que foram escritos, e que, infelizmente, ainda estão muito presentes hoje.

Tendo isso em vista, eu me permiti uma brincadeira e criei os “12 Princípios Frágeis da gestão tradicional de projetos”, opostos ao Ágil. Leia e compare com os princípios originais. Mas, por favor, não tente isso em seus projetos!

  1. Nossa maior prioridade é cumprir o plano por meio da entrega, dentro do prazo previsto, de software com o escopo prometido.
  2. Mudanças de requisitos são indesejadas, e devem ser evitadas ou estritamente gerenciadas em qualquer fase do projeto. Os processos tradicionais tiram vantagem da mudança para cobrar mais caro do cliente.
  3. Entregar software funcionando, de muitas semanas a muitos meses, com preferência à maior escala de tempo.
  4. Pessoas de negócio e desenvolvedores devem trabalhar separados ao longo do projeto e se comunicar por meio de documentos e especificações.
  5. Construa projetos em torno dos melhores processos e ferramentas. Comande e controle os indivíduos e jamais confie neles para realizarem o trabalho.
  6. O método mais eficiente e eficaz de se transmitir informações para e entre uma equipe de desenvolvimento é a partir de documentos detalhados.
  7. Percentual de tarefas cumpridas é a medida primária de progresso.
  8. Os processos tradicionais promovem o desenvolvimento do jeito que for preciso. Os patrocinadores e usuários devem ser capazes de manter uma pressão constante nos desenvolvedores para acelerarem seu ritmo de trabalho e entregarem o que prometeram.
  9. Contínua atenção ao prazo e orçamento aumenta as chances da entrega acontecer, mesmo que a qualidade precise ser sacrificada.
  10. Complexidade – a arte de se maximizar a quantidade de trabalho feito – é essencial.
  11. As melhores arquiteturas, requisitos e projetos são definidos e detalhados antes do início do trabalho por gerentes e líderes.
  12. Ao final do projeto, a equipe reflete sobre o que deu errado e de quem foi a culpa e, então, espera poder refinar e ajustar seu comportamento de acordo em algum próximo projeto.

Gostou deste artigo? Compartilhe conosco seus insigths ou histórias pitorescas que envolvem alguns desses princípios do modelo tradicional de fazer as coisas. 🙂

Sobre o autor(a)

Co-fundador e Trainer na K21

Rafael Sabbagh é co-fundador da K21 e foi membro do Board de Diretores da Scrum Alliance entre 2015 e 2017. Ele é Certified Scrum Trainer (CST) pela Scrum Alliance e também Accredited Kanban Trainer (AKT) pela Kanban University. Atuando em nível executivo, possui uma vasta experiência em Transformação Digital e Gestão de Produtos. Ao longo da sua carreira, já treinou milhares de Scrum Masters, Product Owners e membros de equipes em mais de 15 países na Europa, América e Ásia.

No headers found for the table of contents.

Artigos relacionados

Um tema que aparece bastante vezes quando estamos apresentando nosso treinamento de Product AI é a questão ética sobre o uso de Inteligência Artificial (IA) em nossas vidas. Depois de pesquisarmos sobre o assunto, condensamos em cinco tópicos principais que…

– Bora falar de métricas? – Qual delas? – Como assim? – DORA, GEM, Métricas do Pirata, Fit for purpose, Métricas do Scrum / Kanban? – 😱 Você já se deparou com um mar de métricas e se perguntou quais…

Vira e mexe esbarramos com o problema de estar numa empresa e ouvir que é impossível não termos alguns KRs “tarefeiros”. Ou seja, algum tipo de medição que ao invés de falar do valor de fato a ser gerado, esteja…

Esta é uma ferramenta que auxilia no esclarecimento de expectativas, feedbacks e formação de acordos em qualquer relação de trabalho. Ela é diferente de, por exemplo, uma lista de requisitos do cargo porque ela foca menos nos comos e nas…