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

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. 🙂

Autor(es)

Rafael Sabbagh
Rafael Sabbagh
Rafael Sabbagh, co-fundador da Knowledge21 e membro do Board de Diretores da Scrum Alliance entre 2015 e 2017, é Certified Scrum Trainer (CST) pela Scrum Alliance e também Accredited Kanban Trainer (AKT) pela Kanban Univesity. Atuando como 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 Time em mais de 15 países na Europa, América e Ásia.

Comentários

4 Comentários

  1. Cristiano Lopes 25/08/2018 em 11:54- Responder

    Acho que posso comentar sobre o assunto, antes quero dizer que não sou a favor e nem contra os projetos tradicionais e adoro o Scrum por diversos motivos, mas principalmente pela descentralização da responsabilidade, tornando a equipe madura (auto gerenciável).
    1. Quem disse que num processo ágil não tem um “final”, lembre que a cada sprint é uma obrigação entregar alguma funcionalidade pronta (done) que pode ser liberada para uso (po decide).
    2. Lembra que mudanças durante o Sprint posso dizer que é indesejada, pois se houver toda hora mudança a equipe de desenvolvimento não consegue entregar. Cobrar a mais pelo que não foi feito ainda é improvável, porém se já foi feito e precisa ser refeito, com certeza pagará o refeito, isso em qualquer estrura, metodologia
    3. Aqui desmerece um pouco o bom gerente de projetos, o bom gerente de projetos faz um cronograma com entregas incrementais, onde gera mais valor, algumas técnicas usadas para gerar priorização da atividade são usadas, gráfico de importância x custo, importância x riscos
    4. Este é o ponto ruim de projetos tradicionais, mas ali no começo afirmei sobre a descentralização da responsabilidade, porém, não vejo equipes trabalhando separados, e até burlam o processo, normalmente iniciam a atividade antes de vir a formalização, onde o bom gerente usa o bom senso. Mas concordo contigo.
    5. O bom gerente delega, coloca as pessoas certas no lugar certo, existe sim uma centralização, mas concordo contigo.
    6. Apesar do documento detalhado existir na maioria dos casos no projeto tradicional, o que é visto na prática é uma reunião de entendimento e o documento é a formalização do que foi passado, os documentos são normalmente uma exigência e vai ter casos que faz parte do dod.
    7. Há um erro aí, na verdade é o ETC que o gerente dá muita importancia, igual é feito nas daily.
    8. Como assim? sobre qualidade não existe discussão, não existe é feito do jeito que for preciso, é feito conforme a necessidade e depois se abre um item de mudança para melhorar, idem num processo de arquitetura necessária que vai melhorando confirme os Sprints, questão de organizar as atividades corretamente, e o GP busca pessoas para ajudar neste road map de melhoria.
    9. Wtf 😀, qualidade não se discute, só se for acordada na entrega, por exemplo com um código fixo e depois algumas tarefas para deixar parametrizados.
    10. Alguns gráficos ou status são assim mesmo, mas posso lhe dizer que o burndown tem o mesmo problema. Transparência é fundamental em qualquer tipo de projeto. Faltando 2/3 dias para finalizar o Sprint veio a notícia que não seria entregue aa funcionalidades, quem nunca passou por isto, dá até dor de barriga pensar nisto KKK
    11. Normalmente é criado um cronograma paralelo de arquitetura casando com as outras atividades e entregas, mas muitos esquecem disto, no início é uma previsão depois vai se alterando, exemplo real um componente que era somente um gateway virou um sistema, ou seja, mudou muito ao longo do projeto e foi se adaptando, faz parte das mudanças.
    12. Lições aprendidas não tem culpado, buscar a culpa é meio instintivo, este é o maior problema do ser humano, 5 why, Ishikawa.

    Por fim, não desmereço o bom gerente de fazer projetos tradicionais, mas dá para melhorar kkk

    • Rafael Sabbagh 28/08/2018 em 18:22- Responder

      Olá, Cristiano Lopes!

      Obrigado por seus comentários. Claro, como eu disse no início do texto, ele é apenas uma brincadeira que me permiti fazer. O fato é que cada princípio ágil se opõe a um comportamento observado na época, e foi o que busquei trazer com cada um dos princípios frágeis.

      Para ser mais correto, eu até mexi um pouquinho, nos últimos dias, nos princípios que falavam sobre entregar no final (1 e 3). Mas, mesmo que haja mais de uma entrega durante o projeto, o problema que quero retratar aí é o longo tempo até fazer a entrega. E com o escopo predeterminado, o famoso BDUF (https://www.knowledge21.com.br/blog/bduf/),

      A questão mais importante quando colocamos tradicional e ágil frente a frente é a grande diferença cultural entre um e outro, e a grande dificuldade de quem está imerso no tradicional em perceber essa diferença.

      Enfim, podemos discutir o que se acha que uma coisa é, mas ela continua sendo o que as pessoas fazem dela por tempo suficiente para cristalizar. 🙂

      Um abraço,
      –Rafael Sabbagh

  2. CRISTIANO XAVIER LUCAS FERREIRA 27/08/2018 em 13:24- Responder

    Parabéns pelo artigo. Vou usá-lo para ajudar a explicaras diferenças entre o manifesto ágil e o método tradicional.

    • Rafael Sabbagh 28/08/2018 em 16:52- Responder

      Obrigado, Cristiano Xavier!

Deixar um comentário