Costumo conversar com alguma frequência sobre departamentos de Tecnologia da Informação (TI) de empresas e como eles parecem estar desconectados dessas empresas, muitas vezes assumindo um papel reativo frente às demandas do negócio. É comum ouvir reclamações da área de negócios sobre a TI dizendo que eles quase nunca entregam o que é pedido e que é difícil de entender o que eles falam. Por outro, não menos comum é ouvir o pessoal da TI falando que a área de negócios não sabe o que quer e que não dá para atender “trocentas” demandas de alta prioridade da área de negócios. Esse falta de entendimento entre TI e a área de negócios da empresa é tão comum que virou até motivo de charges dos mais variados tipos:

Desenvolvimento de software

Para quem vive na parte de TI que tem a ver com desenvolvimento de software, esse problema tem sido endereçado há algum tempo. O Manifesto Ágil, de 2001, deixa isso bem claro:

• Passamos a valorizar colaboração com o cliente mais que negociação de contratos.
• Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.
• Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
• Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.

Como o pessoal que desenvolve software precisa colocar seu software em algum lugar, eles decidiram envolver o pessoal que cuida do ambiente de produção nessa forma de pensar que aproxima TI e negócios. Com isso nasceu em 2009 o movimento DevOps:

DevOps (amálgama de Desenvolvedor e Operador) é uma metodologia de desenvolvimento de software que explora a comunicação, colaboração e integração entre desenvolvedores de software e profissionais de TI (Tecnologia da Informação). DevOps é a reação à interdependência entre desenvolvimento de software e operações de TI. Pretende ajudar organizações a produzir software e serviços rapidamente.

Fonte: Wikipedia

Nesses times que desenvolvem software, é comum a figura do Product Owner ou do gestor de produtos que, como já mencionei antes:

é a função responsável por todos os aspectos de um produto de software, desde os objetivos estratégicos até os detalhes de experiência do usuário. É a função responsável por fazer a conexão entre a estratégia da empresa e os problemas e necessidades dos clientes por meio do software que deve ao mesmo tempo ajudar a empresa a atingir seus objetivos estratégicos enquanto soluciona os problemas e as necessidades dos clientes.

O problema da TI

Imagine agora a área de TI de uma Magazine Luiza, de um Posto Ipiranga, de um Laboratório Fleury, de um Colégio Santo Américo, e assim por diante. Essas áreas de TI terão dentre seu escopo as seguintes funções:

• Inventário de hardware
• Inventário e instalação de software
• Monitoração e métricas de disponibilidade de servidores
• Gestão de anti-virus e anti-malware
• Monitoração de atividades dos usuários
• Monitoração e gestão de capacidade
• Gestão de segurança
• Gestão de storage
• Gestão e monitoração de redes

Como dá para ver, essas áreas de TI já têm bastante coisa com que se preocupar e dificilmente irão desenvolver software. Se optarem por desenvolver software, muito provavelmente irão usar empresas terceiras para fazer esse desenvolvimento. Mesmo que decidam desenvolver internamente, desenvolvimento de software ainda será um pedaço pequeno da área de TI. A preocupação dessas áreas de TI é com como integrar softwares de mercado e fazê-los funcionar para atender as necessidades do negócio.

O problema é que, diferentemente da função de desenvolvimento de software, que já descobriu a importância de ter um gestor de produto para ajudar a entregar resultado mais alinhado com a área de negócios, todas as outras funções de uma área de TI não contam com essa ponte entre TI e a área de negócios.

Uma possível solução para TI

Eu gostaria de propor uma solução para o problema da TI: termos mais pessoas com a função de “gestor de produto”. Acho que esse nome não encaixa muito bem quando o que a área de TI está entregando não é um software, mas o que importa é o papel que essa pessoa terá de criar a ponte entre as áreas de TI e negócios. Talvez um nome mais apropriado seja “gestor de negócios”.

Essa pessoa teria por responsabilidades:

• Levantar necessidades das diferentes áreas da empresa em relação a área de TI, inclusive identificando e propondo soluções para eventuais conflitos entre essas necessidades.
• Quando essas necessidades tiverem impacto no cliente final da empresa, entender esse impacto junto a esses clientes.
• Negociar prioridades de implementação das necessidades das áreas da empresa.
• Trabalhar em conjunto com as equipes de TI para que as entregas feitas estejam de acordo com os requisitos levantados com as áreas da empresa.
• Atuar em conjunto com as áreas solicitantes e equipe de TI no relacionamento com eventuais fornecedores / parceiros. (ex: bancos, consultorias, etc)
• Comunicar todas as áreas da empresa sobre novas implementações da área de TI, bem como próximas implementações previstas. Preparar treinamentos quando necessário.
• Trabalhar em conjunto com marketing para comunicar os clientes quando as novas implementações forem customer facing.
• Definir, acompanhar e analisar métricas de uso da TI, para utilizá-las como mais uma informação relevante para tomada de decisão.

E para poder assumir essas responsabilidades, essa pessoa precisa:

• Experiência em trabalhar com equipes de TI para entrega de projetos de qualidade, dentro dos prazos esperados.
• Entendimento de TI e conhecimento técnico para poder negociar opções de implementação. Ter sido da área de TI não é requerido, mas pode ajudar na função.
• Conhecimento geral sobre os produtos e serviços da empresa, bem como do funcionamento das diferentes áreas da empresa.
• Boa comunicação oral e escrita.
• Habilidade de negociação entre diferentes stakeholders com diferentes prioridades.
• Capacidade de documentação de requisitos e cenários de uso.
• Liderança.

Como dá para ver da descrição acima, essa pessoa tem um perfil mais sênior. Ela será um par do gerente de TI.

Uma dúvida que pode surgir ao ler essa proposta de adicionar um “gestor de negócios” ao time de TI é por que os gerentes de TI não podem assumir essa função? Até podem, mas o gerente de TI tem outras preocupações. O gerente de TI tem dois focos principais, tecnologia e pessoas. Ele precisa estar antenado sobre as tecnologias de sua área para saber como melhor atender as necessidades que surgirem e precisa gerenciar o time, encontrar e coordenar bons profissionais de TI não é tarefa fácil. Colocar no gestor de TI mais essa carga de negócios pode causar uma queda de qualidade nos focos atuais.

No desenvolvimento de software nós já percebemos que é melhor ter uma função separada para cuidar da parte de negócios. Por que não aplicar essa mesma separação de papéis para as outras áreas de TI?

Usando gestor de negócios na prática

Na Locaweb, tínhamos já há muitos anos um time que faz o desenvolvimento e manutenção do que nós chamamos de sistemas centrais da empresa. Esses sistemas têm os dados dos clientes, dos produtos e a relação entre cada cliente e os produtos contratados. Além disso, eles são responsáveis por fazer a cobrança dos serviços prestados e, quando não houver o pagamento, desativar o serviço do cliente. São os sistemas de cobrança da Locaweb.

Durante muitos anos, foram tratados como sistemas na maneira tradicional, ou seja, o próprio gerente da área, além de cuidar do time de desenvolvimento e das questões técnicas, era também responsável por interagir com todas as áreas da empresa para coletar e priorizar as demandas.

Em 2014, decidimos mudar a estrutura da área criando a figura de PO (Product Owner) de sistemas centrais, como par do gerente da área. Pouco tempo depois, percebemos que essa mudança foi essencial, não só para melhorar a qualidade das entregas desse time, como também para desafogar o gerente da área para que ele pudesse se focar nas questões técnicas de desenvolvimento de sistemas. O time ficou mais feliz com a nova forma de trabalhar, assim como todos os clientes internos e externos da área passaram a enxergá-lo como um facilitador.

Quando entrei para a Conta Azul em agosto de 2016, havia também uma equipe com os mesmos objetivos e a equipe estava criando essa função de gestão de produtos para ajudar na interface com as outras áreas. No Gympass criamos um time similar, que chamamos de Cross Features, e na Lopes tb criamos o time de Sistemas Centrais.

ThoughtWorks sugere “aplicar a gestão de produtos a plataformas internas”

Fiquei mais uma vez satisfeito ao ver que mais uma vez uma técnica que utilizo há algum tempo para ajudar a criar um software melhor foi mapeada pela equipe da ThoughtWorks! Na edição de novembro de 2017 do Radar Tecnológico, eles sugerem “aplicar a gestão de produtos a plataformas internas”:

Vimos um aumento acentuado no interesse no tópico de plataformas digitais nos últimos 12 meses. As empresas que procuram implantar novas soluções digitais de maneira rápida e eficiente estão construindo plataformas internas, que oferecem às equipes acesso de autoatendimento às APIs da empresa, ferramentas, conhecimento e suporte necessários para criar e operar suas próprias soluções. Concluímos que essas plataformas são mais eficazes quando recebem a mesma consideração que uma oferta de produto externo. Aplicar a gestão de produtos a plataformas internas significa estabelecer empatia com os consumidores internos (leia-se: desenvolvedores) e colaborar com eles no projeto.

Os gestores de produto da plataforma estabelecem roadmaps e garantem que a plataforma agregue valor aos negócios e aprimore a experiência do desenvolvedor. Alguns proprietários até criam uma identidade de marca para a plataforma interna e a usam para comercializar os benefícios para seus colegas. Os gestores de produto da plataforma cuidam da qualidade da plataforma, reúnem métricas de uso e aperfeiçoam a mesma continuamente ao longo do tempo. Tratar a plataforma como um produto ajuda a criar um ecossistema próspero e evita a armadilha da construção de outra arquitetura, estagnada e subutilizada, orientada a serviços.

Isso certamente nos ajudará a desenvolver um software melhor, incluindo sistemas internos, que atenda às necessidades de seus usuários enquanto auxilia o proprietário do software a atingir seus objetivos.

A falácia do “cliente interno”

Vi muitas vezes pessoas usando o conceito de cliente interno ou usuário interno ao discutir o trabalho realizado entre as áreas. Algo parecido com “tenho aqui uma demanda por você e, como sou seu cliente interno, preciso que a demanda seja resolvida o mais rápido possível, de preferência até o dia X”. Eu já vi algumas pessoas sugerindo que nos avaliássemos como clientes e fornecedores internos. O problema de usar o conceito interno do cliente para o relacionamento entre áreas é que ele tende a colocar as pessoas nessas áreas em lados opostos. Alguém de uma área tem uma demanda por outra área.

Uma área pede e a outra área executa. Se a outra área não executar bem, a área exigente se queixa. Se a outra área não cumprir o prazo acordado, a área exigente reclamará. A área que deve executar a demanda justifica que a solicitação não estava clara e que a demanda deve ser feita no formato Z, especificando A, B e C, porque, sem estes, eles não podem executá-la corretamente ou no prazo. E assim a história continua…

Além disso, as empresas normalmente têm mais de duas áreas. Assim, uma área pode ter mais de um cliente interno e, portanto, pode receber várias demandas que, na maioria das vezes, são todas “necessárias para ontem” e todas são “as mais importantes para a empresa”. Em seguida, começa a disputa de priorização.

Cliente interno vs trabalho em equipe

Em 2001, um grupo de pessoas que trabalhou com o desenvolvimento de software sob demanda se reuniu para discutir as melhores maneiras de criar software. Essas conversas deram origem ao Manifesto Ágil, contendo a base dos conceitos ágeis que melhoraram consideravelmente a taxa de sucesso dos projetos de desenvolvimento de software em nosso setor. Durante essas conversas, eles chegaram à conclusão de que, entre outras coisas, era necessária uma maior colaboração do cliente. Para aumentar o sucesso em projetos de desenvolvimento de software, é essencial que o cliente se torne parte da equipe que está desenvolvendo software, e não um mero requerente espectador. Devemos parar com esse conceito de cliente interno e voltar a usar o bom e velho conceito de trabalho em equipe, mesmo entre diferentes áreas. O trabalho em equipe não é apenas para pessoas da mesma área, mas também para pessoas de diferentes áreas. Qualquer empresa pode e deve ser vista, em última análise, como uma equipe de equipes.

Para trabalhar bem em equipe, você deve ter empatia, isto é, saber entender e respeitar os pontos de vista dos outros, colocar-se no lugar deles, tentar entender como os outros pensam e por que pensam dessa maneira. Áreas diferentes têm culturas diferentes e modos de pensar diferentes. E isso é bom! As equipes trabalham principalmente porque pessoas diferentes, trabalhando juntas, são capazes de produzir um resultado com maior impacto do que usando apenas suas habilidades individuais. Se todos pensassem da mesma forma, isso não seria possível. Portanto, para se ter um trabalho de equipe de verdade, é importante não apenas tolerar e conviver com as diferenças: precisamos tirar proveito delas. Nós devemos cooperar. Nós devemos trocar conhecimentos. Valorizar conflitos saudáveis, não ter medo de debates e desacordos. Quando duas pessoas trocam ideias, cada uma sai da troca com mais ideias. Todo mundo ganha. Pontos de vista diferentes ajudam a obter melhores resultados, desde que as pessoas não sejam motivadas pelo ego ou pela desconfiança.

Exemplo prático de trabalho em equipe ao invés de cliente interno

Passando da teoria para a prática, deixe-me dar um exemplo. Usarei a necessidade de contratar novos funcionários em uma determinada área que precisará de RH para este exemplo. Quando precisamos fazer uma nova contratação, devemos evitar simplesmente enviar a descrição do cargo ao RH e aguardar passivamente o RH para fazer essa tarefa e só então voltar ao RH e perguntar se eles conseguiram preencher a vaga. O problema a ser resolvido é preencher a vaga com a melhor pessoa possível dentro da faixa salarial orçada para o cargo e dentro do prazo. Este não é um problema exclusivo do RH. É um problema a ser resolvido pela equipe de RH junto com a área que demandou. Por esse motivo, a pessoa que solicitou uma nova contratação precisa trabalhar com o departamento de RH para preencher essa vaga, não apenas fazendo as entrevistas, mas também ajudando na procura, discutindo cada currículo recebido, cada candidato entrevistado e assim por diante. Uma nova contratação deve ser um trabalho em equipe entre a equipe de RH e a área que precisa fazer essa nova contratação. As chances de se fazer uma boa contratação em tempo hábil são muito maiores quando a área demandante e o RH se reúnem e trabalham em equipe para fazer essa contratação.

Assim, sugiro que paremos de usar o conceito de cliente interno e voltemos ao bom e velho trabalho em equipe, mesmo entre áreas. Isso aumentará bastante a taxa de sucesso de novos empreendimentos, bem como a motivação das pessoas das áreas envolvidas.

Atualização de 2023

Esse artigo foi escrito originalmente em 2014 e é um dos capítulos finais do meu livro “Gestão de produtos: Como aumentar as chances de sucesso do seu software”. Apesar de ter quase 10 anos e de termos evoluído, ainda tem muita empresa usando o modelo negócios demanda => tecnologia implementa.

Por isso nos últimos meses venho me aplicando cada vez mais em minha missão de ajudar pessoas e empresas a conectarem negócios e tecnologia por meio de treinamento e consultoria em gestão de produtos e transformação digital.

Treinamento e consultoria em gestão de produtos digitais

Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a enfrentarem seus desafios e oportunidades de produtos digitais por meio de treinamentos e consultoria em gestão de produtos e transformação digital.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.