Hierarquia de Cargos e Papéis

Papéis e Funções

Publicação da série sobre as diversas funções e posições em uma equipe de ProdOps, juntamente com as adaptações que o ProdOps faz no fluxo e na estrutura organizacional:

Literatura preliminar

Hierarquia de Cargos e Papéis
Expansão do Squad com Times Fixos e Times Virtuais

Especialidades ProdOps

ProdOps Tracker
ProdOps Specialist
ProdOps Quality Engineer
ProdDevOps Engineer
ProdOps Reliability Engineer
ProdOps Manager
Tech Product Manager

[DISCLAIMER: Desconto na turma de Continuous Delivery (ProdOps Delivery) vai acabar em 24h, se inscreva em https://produtoreativo.com.br/product-delivery

Introdução

O Framework ProdOps destaca-se pela sua notável flexibilidade, possibilitando a implementação em consonância com diversos modelos e métodos de gestão, independentemente do estágio de maturidade do produto ou do negócio, assim como em qualquer fase da trajetória da empresa. Respeita integralmente a cultura, tradição e estrutura específicas de cada organização.

A missão fundamental do ProdOps reside em fomentar uma cultura sólida de produtos digitais. Para alcançar esse objetivo, compreendemos a necessidade de realizar ajustes seletivos e a implementação de uma estrutura recomendada, levando em consideração a história e as características individuais das empresas envolvidas.

Este primeiro artigo explora como as estruturas corporativas se desenvolveram ao longo do tempo, fornecendo insights valiosos para, em seguida, sugerir uma definição clara de cargos, papéis e funções, destacando o que cada um deve fazer e os resultados esperados.

Origem da Estrutura

Este artigo aborda o cenário histórico do desenvolvimento da área de TI no Brasil, desde suas origens até os dias atuais, destacando as influências externas, principalmente dos Estados Unidos. Exploraremos também como a gestão de produtos digitais evoluiu ao longo do tempo.

O ingresso do software no ambiente corporativo inicialmente se deu como suporte ao processamento de dados empresariais. Até hoje, os sindicatos da área mantêm a nomenclatura SINDPD, remanescente da época em que a TI era conhecida como CPD (Centro de Processamento de Dados).

Por ser um segmento relativamente novo, comparado a áreas como finanças, contabilidade e engenharias tradicionais, as estruturas iniciais seguiram modelos hierárquicos padronizados, alinhados à administração clássica dessas empresas.

O percurso profissional seguia uma trilha técnica no âmbito operacional, seguida por uma trilha de gestão à medida que os profissionais adquiriam maior senioridade. O processo de carreira geralmente consistia em ascender a cargos como coordenador, gerente e diretor, com suas subcategorias gerenciais como únicas opções de promoção.

À medida que as empresas se digitalizavam e os softwares se tornavam protagonistas na automação de tarefas manuais, a gestão, anteriormente responsável por abranger negócios, desenvolvimento de pessoas e tecnologia, passou por uma divisão necessária devido à complexidade crescente.

É crucial ressaltar que, nesse período, ao contrário de outras áreas de engenharia onde profissionais técnicos podiam crescer até a aposentadoria, na tecnologia isso não era viável, dada a imaturidade da área em termos de modelos específicos de carreira.

Gestão de Projetos

A primeira distribuição de responsabilidades entre os gestores, que agora passava a ser compartilhada por um parceiro, consistiu em definir o escopo da digitalização. Em outras palavras, eles precisavam determinar quais projetos seriam encarregados de criar serviços digitais e como atenderiam às necessidades das diversas áreas de negócio.

Nesse contexto, destacou-se o papel do Gerente de Projetos na área de Tecnologia da Informação, influenciado pela literatura clássica de gestão de projetos que estava se consolidando naquela época, especialmente por meio de instituições como o PMI (Project Management Institute), fundado em 1969.

Inicialmente, muitas empresas implementaram a gestão de projetos dentro da estrutura organizacional existente, sendo bastante comum o próprio coordenador ou gerente assumir também o papel de gerente de projetos.

Em alguns casos, especialmente em empresas de maior porte, o gerente de projetos atuava em parceria com os líderes das equipes, focando exclusivamente no escopo do projeto e compartilhando responsabilidades em disciplinas como orçamento, riscos, entre outras.

A introdução desse novo papel de gestão gerou incertezas e preocupações sobre as responsabilidades individuais, limites de atuação e como os resultados dos projetos seriam avaliados e cobrados. Isso levou à necessidade de adaptações nos modelos de metas e remunerações para minimizar conflitos.

No entanto, a complexidade dos projetos que envolviam múltiplas equipes dentro das empresas também intensificou os conflitos existentes.

Área de Projetos

As diretrizes provenientes do próprio PMI trouxeram ao gerente de projetos, com sua estrutura de suporte dedicada, definições mais sólidas. A hierarquia, estabelecida por meio de escritórios de projetos (PMO, Project Management Office) bem organizados e com metodologia própria, proporcionou um ambiente mais estruturado.

Os resultados e acompanhamentos tornaram-se mais compreensíveis para a alta administração, enquanto a separação no organograma e a distribuição de responsabilidades ficaram mais transparentes.

Os times passaram a ter uma compreensão mais clara de a quem deveriam reportar e como seriam avaliados, com as expectativas claramente definidas pelos responsáveis diretos.

Apesar de os projetos terem seus escopos melhor desdobrados para as equipes por meio de um escritório de projetos gerenciando individualmente, a responsabilidade cotidiana pela priorização e pelo impacto no roadmap do projeto ainda apresentava desafios e conflitos.

Era do Nativo Digital

Com o surgimento de empresas que se estabeleceram inicialmente oferecendo serviços exclusivamente digitais pela internet, dois fenômenos aconteceram simultaneamente, principalmente com o advento do que ficou conhecido como o movimento Ágil. Para uma explicação mais clara, vamos dividir esses acontecimentos em dois blocos distintos: Carreira em Y e Gestão de Produtos Digitais.

Carreira em Y

O avanço da complexidade tecnológica gerou uma demanda por especialização muito mais acentuada do que anteriormente.

Na era do CPD, os profissionais conseguiam atuar em praticamente todos os ciclos de vida de um software, com distinções mais amplas, como infraestrutura e desenvolvimento. Contudo, na atual fase de desenvolvimento, é necessário desempenhar uma variedade maior de papéis.

O volume de trabalho para entregar um serviço digital aumentou consideravelmente, especialmente ao considerar que até 2010 o “Mobile” era praticamente inexistente. Hoje, temos a presença de IoT (Internet of Things), a ascensão da computação em nuvem com suas próprias camadas de abstração, e constantes novas tecnologias surgindo anualmente.

Mesmo que um profissional seja capaz de realizar tarefas em diversas fases e disciplinas, conhecido hoje como Fullstack ou T-Shaped, tornou-se humanamente impossível abraçar todas essas responsabilidades dada a quantidade exponencial de trabalho envolvida. A especialização tornou-se crucial para lidar eficazmente com a complexidade crescente do cenário tecnológico.

FAANG Dita o Formato da Carreira em Y

O mesmo fenômeno que ocorria aqui no Brasil parecia se desenrolar em escala global, onde profissionais de tecnologia enfrentavam desafios em termos de suporte para uma carreira centrada na evolução técnica exclusiva e focada apenas nos aspectos tecnológicos dos projetos. Empresas consolidadas na internet, reconhecendo a necessidade de especialistas mais aprofundados devido ao aumento da complexidade, iniciaram um movimento para criar trilhas de carreira mais claras e semelhantes às que já existiam para cargos de gestão.

A compreensão de que a expertise técnica desempenha um papel crucial na era digital levou essas empresas a investir na formação e retenção de profissionais altamente especializados. Isso resultou na construção de trilhas de carreira que permitiam aos especialistas técnicos avançar e aprimorar suas habilidades, sem a necessidade de fazer uma transição forçada para funções de gestão.

Essa abordagem não apenas atendia às demandas crescentes de complexidade tecnológica, mas também reconhecia e valorizava a expertise técnica como uma peça fundamental para o sucesso contínuo das empresas no cenário digital em constante evolução.

Atualmente, o grupo que representa e dita as tendências nos modelos organizacionais é frequentemente referido como FAANG (Facebook, Amazon, Apple, Netflix, Google) ou MANGA (Microsoft, Amazon, Netflix, Google, Apple). Essas gigantes tecnológicas exercem uma influência significativa no cenário empresarial global, não apenas pelo seu tamanho e sucesso, mas também por adotarem práticas inovadoras de gestão e estrutura organizacional. Seus modelos ágeis e adaptativos tornaram-se benchmarks para muitas outras empresas, à medida que buscam evoluir e se destacar no ambiente dinâmico e competitivo dos negócios digitais.

Ajustes no Modelo Operacional

O ProdOps desempenha um papel crucial ao orientar as empresas sobre como ajustar suas estruturas para acomodar a evolução de carreira dos profissionais especializados.

Compreendemos que, na atualidade, todas as empresas devem se considerar empresas de tecnologia. Não existem mais apenas empresas de varejo, financeiras ou turismo; todas são agora provedoras de serviços digitais que oferecem oportunidades nos setores de varejo, financeiro ou turismo.

Mesmo indústrias tradicionais reconhecem a necessidade de avançar no ambiente digital, incorporando uma jornada omnicanal que envolve todos os participantes na cadeia do produto. Isso inclui a adição de modalidades como o modelo Direto ao Consumidor (D2C).

No vídeo a seguir, exploramos como o ProdOps está estruturado para apoiar essa transformação digital, oferecendo insights e orientações valiosas para as empresas que buscam prosperar nesse ambiente dinâmico.

Confusão entre Cargos, Papéis e Especialidades

Com a proliferação de funções e responsabilidades e a fragmentação do escopo de trabalho, há ainda muitas considerações a serem feitas para estabelecer mecanismos mais eficazes de promoção e compreensão de como medir os resultados.

Os nativos digitais compreenderam que, além de criar uma trilha técnica, existem subníveis de carreira para cada estágio. Utilizando a nomenclatura do Google como exemplo, um profissional promovido a Staff Engineer possui vários níveis de senioridade para progredir em suas competências.

Profissionais em diversas especialidades, como Designers, QA, Data Engineers, entre outros, têm suas próprias trilhas, mas seguem um modelo de cargos técnicos unificado para acomodar todas as especialidades.

O ProdOps é concebido com a compreensão de que alguns profissionais podem desempenhar tanto funções gerenciais quanto técnicas. No entanto, a definição clara do caminho profissional a ser seguido precisa estar explicitada no plano de carreira, sendo que a mudança de um para outro deve ser considerada uma alteração organizacional significativa.

Uma definição clara de cargo e papel é crucial no plano de carreira. Profissionais que desempenham funções como SRE ou DevOps, por exemplo, seguem a mesma consideração de carreira, como Staff.

O que difere é a maneira como os resultados do seu trabalho são mensurados e como as repercussões das suas entregas são refletidas no modelo do produto como um todo. Isso é feito respeitando as fronteiras de especialização e evitando a armadilha de avaliações baseadas em comparações injustificadas.

Em termos mais diretos, profissionais de DevOps e SRE serão promovidos de Staff a Principal por meio de avaliações específicas, alinhadas às expectativas delineadas pela clara definição de cada papel no modelo operacional. Enquanto, na literatura, o SRE atua no ciclo da peça, o DevOps cuida do ciclo do time. Dessa forma, um profissional de DevOps será avaliado, por exemplo, pela implementação disciplinada de CI/CD, em vez da simples capacidade de implantar rapidamente (usando métricas DORA), considerando o trabalho colaborativo entre os membros de um produto.

Gestão de Produtos Digitais

A predominância do Scrum como modelo ágil no mercado, especialmente no Brasil, gerou uma considerável confusão no modelo organizacional. Algumas empresas optaram por transformar a liderança no cargo de ScrumMaster, originalmente concebido como um papel no Scrum. Em alguns casos, isso resultou em uma situação onde o ScrumMaster tornou-se mais uma liderança no time, levando a um desequilíbrio de liderança.

Anteriormente, as responsabilidades estavam mais ou menos estabelecidas. No entanto, essa fragmentação causou perturbação com a introdução de mais uma liderança para guiar a cadência de execução da equipe. O mercado brasileiro percebeu que essa mudança foi desnecessária, especialmente após a pandemia da Covid-19, e ajustes estão sendo realizados para contornar a fragmentação de liderança.

Outro aspecto desconfortável decorrente da confusão na incorporação do Scrum ao modelo operacional foi a introdução de mais uma função de liderança, o Gerente de Produto, conhecido no modelo como PO (Product Owner). Em materiais mais antigos de Scrum, o PO era referido como gerente de produtos. A transição para o termo PO foi uma tentativa de repaginação para criar um impacto de marketing.

No Brasil, analistas de negócios passaram imediatamente a ser designados como PO, resultando em uma bagunça nos entendimentos de funções e responsabilidades. Para acomodar essa gestão, foi criada uma progressão de carreira chamada PM (Product Manager) como líder do PO, o que, na essência dos termos, não faz sentido, uma vez que PO é Product Manager. Na sequência desse erro, foram criados cargos como GPM (Group Product Manager) e outros para tentar equalizar com o modelo clássico.

Antes de avançar, é crucial compreender os efeitos que prejudicaram a introdução e consolidação da gestão de produtos digitais, principalmente em empresas que precisam desenvolver uma cultura eficiente para operar, algo que os nativos digitais já possuem por natureza.

A Cultura de Projetos Continua Guiando a Empresa

Durante muito tempo, a estrutura de TI foi organizada organicamente em torno do modelo de projetos, com a sustentação dividida entre desenvolvimento, responsável pela evolução das aplicações, e operação, encarregada do cuidado em produção.

A introdução do gestor de produto nessa área seguiu um padrão semelhante ao do gestor de projetos antes da consolidação dos escritórios de projetos. A diferença reside no fato de que o escritório de produtos nunca foi conceituado por instituições como o PMI. Mesmo modelos ágeis em escala, como o SAFe, mantiveram o foco em oferecer orientações baseadas em serviços, como a gestão por Value Streams, que pode ser uma camada de desdobramento para projetos corporativos.

Toda a literatura desenvolvida com base nas práticas dos nativos digitais precisa ser traduzida para empresas que buscam transformar seus negócios para o digital. Isso ocorre porque a organização nativa digital já foi construída em torno de produtos, o que fornece um guia claro de como o gestor de produtos deve operar.

No modelo misto que fragmentou o escopo em projetos, negócios e agora um gestor de produtos, em vários cenários, o ruído na comunicação piorou significativamente, e o desalinhamento entre TI e negócios aumentou.

Nesse ínterim, o modelo Spotify, que ganhou notoriedade como um modelo operacional, agravou a situação já complicada. Introduziu várias camadas de abstração, tanto verticais quanto horizontais, no ecossistema, resultando em mais confusão nos papéis e responsabilidades.

Centro de Habilitação ProdOps

A área de ProdOps, sugerida pelo framework como um Centro de Habilitação, está alinhada com o objetivo de promover a cultura de gestão de produtos digitais. Seu propósito é oferecer os mecanismos necessários para organizar de forma orgânica os cargos, papéis e lideranças, permitindo que as equipes adotem o formato desejado de times multidisciplinares. Isso é feito com o suporte adequado, fornecendo a liberdade esperada dentro de uma padronização correta.

Centro de Habilitação ProdOps (C4E, Center for Enablement)

Esta série irá conceituar os papéis necessários, respeitando os cargos do modelo de carreira em Y já consolidados. A evolução do SRE no modelo ProdOps, agora renomeado para PRE (Product Reliability Engineering), inclui responsabilidades nos cargos de Staff ou Principal, por exemplo, desempenhando papéis como Tracker, Troubleshooting Engineer ou Platform Engineer.

O ProdOps não visa entregar um modelo universal; ao contrário, orientará o desenho mais adequado, onde os papéis e responsabilidades sejam claros e possíveis de serem medidos e acompanhados.