Quando se trabalha muito tempo com tecnologia (quando falo em tecnologia, quero que você pense sobre um contexto mais amplo do que só desenvolvimento e programação), você se acostuma a ver novas profissões e especialidades nascerem o tempo inteiro. Quando uma dessas profissões nasce, geralmente há uma migração natural de pessoas que compõem outras áreas para essa profissão nova. Foi assim com o Design, quando designers, principalmente de offline, migraram para fazer web. Foi assim com programadores, quando devs de software offline migraram para desenvolvimento de software para web. Foi assim com Data Science, SEO, Acessibilidade. E foi assim também com a gestão, quando PMOs e outros tipos de gestores migraram da gestão de projetos de software tradicional para a gestão de projetos para internet.
É normal que profissionais que migraram de outras áreas tragam suas práticas, costumes, técnicas, métodos e frameworks da vida antiga para o novo ambiente. Como se trata de uma responsabilidade nova, o certo e o errado ainda precisam ser descobertos.
A construção de qualquer tipo de software é algo complexo, principalmente quando incluímos os usuários reais no processo de idealização e construção, pois mudamos os planos de acordo com o comportamento e interação do usuário com o produto. Nós não esperamos o software ficar pronto para que o usuário o use, pelo contrário, cada vez que temos um pedaço funcional, nós o disponibilizamos o mais rápido possível para que possamos recolher dados e feedback do público. Isso deixa tudo muito mais complexo e imprevisível.
Além disso, há uma variável que impacta bastante: a maturidade e a senioridade do time técnico. Em uma fábrica de carros, o nível técnico dos operários pode ser bem diferente, mas a qualidade dos carros não sofrerá porque há uma especificação muito clara e um controle da manutenção do nível de qualidade do processo. Alguém que acabou de chegar à fábrica, depois de dominar o processo e as máquinas, conseguirá ter o nível de performance mais ou menos igual ao de alguém que está lá há anos.
Quando falamos de desenvolvimento de software, um dev junior vai resolver um problema com vinte linhas de código. Uma desenvolvedora sênior resolverá o mesmo problema com duas linhas. A qualidade final do software é altamente afetada se há uma variação muito grande entre o nível técnico do time ou se o time é formado por desenvolvedores com pouca experiência. Quando trabalhamos no mercado de execução de tecnologia, isso acontece em quase todas as áreas.
Nesse cenário, a pessoa Product Manager precisa ter um perfil muito diferente da figura tradicional de Gestor de Projetos. São diferenças profundas em soft e hard skills. A maneira com que PM e PMO interagem com o time, com stakeholders, com usuários, com o negócio e com os problemas dos processos são diferentes, pois os ambientes e os contextos são diferentes.
Atualmente o mercado costuma comparar os papéis do PMO (Project Manager Office), do PO (Product Owner) e do PM (Product Manager), mas são perfis totalmente diferentes – para o ambiente de construção de produtos e serviços digitais, as responsabilidades do PMO ou do PO não são suficientes.
Antes de avançar para os próximos capítulos do livro, precisamos entender um pouco mais sobre o papel de cada um deles.
Gestor(a) de Projetos
