Mapeando os caminhos que product managers fazem em sua carreira. Cargos e responsabilidades. Photo by Clayton Robbins / Unsplash
Minha percepção é que as profissões dentro do mercado de tecnologia evoluem muito mais rápido do que outras. Existem várias hipóteses para justificar isso, como evolução rápida da stack tecnológica e dos métodos e processos utilizados no mercado. Só isso já faz com que os profissionais precisem se atualizar numa velocidade maior que em outros mercados.
A quebra em especializações é outro fator bem interessante que acontece com essas profissões. Se você percebe, todas as especialidades começaram aglutinando responsabilidades, depois tiveram alguns níveis de amadurecimento que criaram divisões e quebras de responsabilidades. Em alguns casos essa quebra faz sentido e foi bem benéfica, em outros casos, na minha opinião, prejudicou mais do que ajudou.
Um dos exemplos benéficos é da área de programação. No início só existiam programadores e pronto. Não quero pegar a timeline histórica muito longa, mas antes só existiam programadores. Geralmente desenvolvedores de software offline ou de hardware. Com a vinda de novas tecnologias como a internet e depois a web, a gente viu os programadores web surgirem.
Ainda no início eram só programadores, mas logo depois uma quebra surgiu, criando programadores back-end, depois front-end. E nessa também alguns já foram para área de arquitetura e infraestrutura. Hoje, programação está em toda parte que faz sentido. Mas não surgiu nenhum tipo de programador que só aperta um tipo de parafuso ou que faz só uma parte muito específica do processo que não pudesse ser feita dentro de um contexto completo. O que não é o caso de design.
Design, para mim, é o exemplo que não houve tantos benefícios. Houve uma linha muito parecida com os programadores. No início eram designers "offline" por assim dizer. Arquitetos entram nessa também. Tudo muito atrelado ao mundo físico. Mesmo aqueles que trabalham com design gráfico. Se você separar por contextos, essas quebras fazem muito sentido.
Quando a web veio, ainda continuou fazendo sentido com os designers dominando e controlando todo processo de design, desde sua descoberta, planejamento, aplicação, manutenção e evolução. Num passado recente isso se quebra em diversas micro-partes, onde seus contextos muito pequenos. Eu entendo que em alguns momentos existem necessidades de execuções muito específicas... mas o problema é que o mercado transformou disciplinas em contextos de execução. Isso vale para research, vale para writing e outros. Hoje, há um movimento de aglutinação dessas especialidades de novo, criando novamente um designer que entende do processo como um todo e sabe se adaptar à necessidade de cada projeto. Mas, esse é um assunto espinhoso, que nem todo mundo gosta de discutir com maturidade. Deixo para próxima.
Essa evolução de maturidade também aconteceu com Gestão. E nem quero me alongar muito, puxando o histórico lá de trás com nomes como Taylor. Quero começar a discussão a partir de agora, da nossa vida mais conhecida e recente. A Gestão de Projetos evoluiu e sofreu disrupções interessantes até chegarmos onde estamos agora.
Quando falamos sobre gestão de projetos, nós imaginamos ao famoso PMO, Project Management Office, que tinha como principal função garantir que o projeto fosse entregue dentro do tempo, com o escopo pedido e sem furar o budget. Para garantir isso, métodos e frameworks de processos são aplicados e uma série de rotinas de report são feitos para garantir que todos estão alinhados quanto aos principais pontos do projeto.
Logo, quem gere projetos precisa ter uma visão clara sobre processos. Isso não quer dizer que se aplica apenas a software, pelo contrário. Se você pega a história do PMI (Project Management Institute), você vai ver que eles fizeram um aeroporto. Eles participaram do programa Apollo. Eles participaram da criação do primeiro celular feito pela Nokia. Hoje a galera de produtos torce a boca quando fala sobre gestão de projetos, desdenhando de uma especialidade que eles não sabem fazer.
Gestão de produtos é uma derivação (não encaro como evolução) da gestão de projeto. Muitos PMs e líderes de produto não sabem gerir projetos, ou por falta de oportunidade, ou por que migraram de outras áreas, onde essa habilidade não era necessária. Talvez essa seja uma grande causa da síndrome da não entrega. Falta organização e processo. Mas essa é outra história.
Com a vinda da internet e da web, a popularização do smartphone, a evolução da Web 2 e todas as alavancas que fizeram as pessoas ficarem cada vez mais conectadas e viciadas em software, fez com que essa profissão também amadurecesse. A gestão de software é complexa, porque faz parte de um ambiente complexo. Embora construir prédios seja perigoso e pode acontecer uma série de problemas durante o caminho, há um processo bem estabelecido que traz alta previsibilidade da entrega atrelada a alta qualidade. Isso por que embora sejam projetos grandiosos, são projetos que rodam na sua maioria das vezes na camada complicada. Diferente da camada de software, que geralmente está na camada complexa.
A construção e desenvolvimento de software roda na camada complexa e caótica. Nosso esforço em gestão de produtos e gestão técnica é uma vigília constante para diminuir incertezas para tentar posicionar e manter o nosso produto na camada complicada. E muita gente se perde nesse ponto.
Diferente de uma construção de prédio que o trabalho vai ficando progressivamente mais "simples" conforme as partes são construídas, o software vai ficando cada vez mais complexo. E isso se potencializa quando há pessoas usando.