A série #onovogestor está lidando com definições, desmistificações e eventuais recomendações.

A ideia é começar a influenciar a preparação de profissionais aos desafios reais das organizações e que não se limitem ao escopo de um ou outro tipo de mindset de gestão.

Hoje vamos continuar a olhar para o Tradicional e revisitar um dos principais conceitos estigmatizados na modernidade: o projeto.

Então, recordemos o que é um projeto:

“Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.[…]” (PMBOK)

Agora pare e pense: MUITO do que você faz é projeto.

O que as pessoas moderninhas revolucionárias criticam sobre o conceito “projeto” é, entretanto, uma visão que traz a reboque os fatores de microgestão, comando e controle, cronogramas cascateados, etc…

Aliás, muito do que vemos são termos ou conceitos do universo dito “Tradicional” que foram re-significados como ruins a posteriori, servindo de inimigo comum à nova forma de pensar. E, como toda boa mentira, ela se apoia em uma verdade e a potencializa para criar o “lado certo” e o “lado errado” universal.

Se você vem me acompanhando nesta série já percebeu o quanto tenho criticado a não-evolução do pensamento gerencial que pulou drasticamente para um conjunto de valores e práticas do outro lado da balança. Pode ser um fenômeno social, mas o que estou interessado é começar um processo novo: resgatar o que o gestor sempre deveria ter sido — um profissional fora das “caixinhas”.

Voltando à questão do “projeto”.

Os discursos mais simpáticos hoje falam de “produto” em contraposição ao “projeto“. Porém eu acredito que as pessoas que assim preferem não desenvolveram uma ideia concreta do que seja um ou outro, mas possuem apenas alguns pré-conceitos, sendo levadas pelo efeito manada ou tribal.

Para encurtar a explicação do meu ponto de vista, deixe-me fazer um exercício:

Imagine que você está desenvolvendo um produto e está chegando próximo ao início de uma nova release. Esta release afeta 2 áreas internas na organização que precisarão de treinamentos após o lançamento e um plano gradual de migração do antigo sistema para o novo. O lançamento desta release, por questões estratégicas, deve ocorrer antes da black friday, para a empresa poder ter maior margem nas vendas online. Esta release tem escopo com 2 grandes marcos que representam as 2 novas características que evoluirão na plataforma. Além da restrição da data, a equipe trabalha com um nível de qualidade mínimo acordado com a área de Qualidade e as premissas de que o novo componente trará mais segurança à operação e que a nova proposta visual será mais intuitiva aos usuários.

Esse cenário, que poderia acontecer em um contexto Ágil ou Tradicional, configura “um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”, ou seja, um projeto!

Por que eu acho que as pessoas não gostam de falar de “projeto”:

* Porque remetem a um passado inicial da carreira quando não sabiam gerenciar;
* Porque acham que projeto não considera o usuário final;
* Porque acreditam que projeto é sobre datas impossíveis e cronogramas chatos;
* Porque projeto lembra o gerente do projeto, alguém geralmente mais carrancudo; 🙂
* Porque pensam que projeto e produto são mutuamente excludentes;
* Porque tudo parece tão mais fácil quando se é Ágil. S2

Entretanto, no cenário que desenhei acima, sendo Ágil ou não você precisará de conceitos mais Tradicionais para conduzi-lo bem. Vamos lá:

Você até pode conduzir o desenvolvimento do produto com ciclos iterativos incrementais à lá Scrum, mas atente-se para:

* Iniciativas paralelas

Paralelo ao desenvolvimento da release, um projeto de migração da plataforma legada para atual precisará acontecer. Geralmente projetos de migração não são de característica predominantemente Complexa (veja Cynefin), sendo mais para o Complicado. Logo, especialistas poderiam dizer com alto grau de confiança como fazê-la. O desafio será orquestrar este projeto com a nova construção em andamento. Gestão digna de projetos.

Planejar treinamentos também não é uma tarefa de natureza incerta. Geralmente predominam os domínios Complicado e Simples. Você precisará de alguém que conheça o novo sistema; alguém que tenha alguma habilidade em treinamentos; criar o material necessário; fazer algum teste sobre o conteúdo e finalizar a construção para aplicá-lo. Nada super Ágil.

* Redução dos principais riscos

Algo que não está tão explícito nos modelos Ágeis é o foco necessário à tratativa dos principais riscos. Perceba que este release tem datas fixas e premissas importantes. Cenário em que investir, assim que possível, na mitigação ou eliminação destas premissas/riscos é importante. Uma priorização do backlog olhando para a importância das features ao produto, sem considerar esses riscos do projeto, pode ser catastrófico.

* A utopia Ágil

Ao envolver outras áreas, geralmente de cultura não-Ágil, pode ser uma utopia ter “todos dentro do mesmo barco”. Aquela intenção de ter todos engajados na execução, consumindo e aprendendo com as entregas parciais, pode não acontecer. Ainda mais quando houver muitas pessoas envolvidas. Por certo você precisará de uma boa gestão de comunicação com os stakeholder que não estão dentro da sua Sprint.

Logo, este cenário já tem 3 grandes projetos em andamento que, inclusive, se integram em 1 projeto maior. Integração e Cronograma do PMBOK também poderiam ajudar nesta visão 😉

Autores do mundo Ágil também referem-se comumente a projetos, gestão de projetos, equipes de projetos. Há livros que trazem a palavra Projeto na capa e apresentam conteúdo Ágil para este contexto. Logo, creio que preferir produtos a projetos seja uma característica da comunidade e do Movimento Ágil, com seu vocabulário e inimigo próprio.

O mundo sim passou a enxergar os benefícios de olhar para produtos e especialmente para serviços, mas não podemos esquecer que a entrega destes acontecem através de projetos.