Há muitas maneiras de estruturar a gestão de equipes de produto. Algumas dessas funções de gestão são vitais, enquanto outras podem ser muito problemáticas.

Abaixo está uma lista de funções que eu acho que sejam anti-patterns para as equipes de produto. Para ser claro, eu estou falando sobre essas funções estritamente no âmbito de equipes focadas na construção de software destinado a ser vendido aos clientes. Na verdade, tenho certeza de que algumas dessas funções não têm o seu lugar em companhias de tecnologia com foco em apoiar as necessidades da empresa.

Com esse aviso dado, divirta-se!

Diretor de QA

O que faz um diretor de QA (Quality Assurance)? Isso varia, mas a descrição de trabalho a seguir dá uma ideia:

O diretor de Quality Assurance (QA) de software é responsável por garantir que as soluções sejam desenvolvidas, testadas e implementadas de forma consistente, sem descuidar as metas de qualidade estabelecidas.

Parece razoável. Por que você não iria querer alguém responsável por garantir que as soluções estão cumprindo as metas de qualidade?

Bem, eu acho que essa função é problemática, pois implica uma separação entre os responsáveis por escrever o software e os responsáveis por verificar que ele funciona. Essa separação não é certamente predeterminada, mas é difícil de evitar. É muito fácil cair na armadilha do “nós contra eles” quando você tem a equipe de “dev” e a equipe de “QA”.

Considere a incompatibilidade de prioridade. O objetivo da equipe de desenvolvimento (e de seu gerente) é entregar o máximo possível o mais rápido possível , enquanto a equipe de QA (e de seu gerente) quer alcançar a mais alta qualidade possível. Na verdade, seu desempenho é frequentemente ligado a esses objetivos.

Bem, esses dois objetivos não são os mesmos. Na verdade, eles estão às vezes em desacordo. E, quando eles estão em desacordo, a única maneira de decidir corretamente o caminho a seguir é no contexto da equipe maior. O que significa que as prioridades de alguém poderiam ser comprometidas. O que também significa que alguém vai ser o “vencedor” e alguém, o “perdedor”.

Sempre que você tem “vencedores” e “perdedores” como consequência da tomada de decisões do dia-a-dia, as dinâmicas nada saudáveis acabam surgindo. As pessoas começam a focar em tentar ganhar, em vez de se concentrarem em fazer a coisa certa. Eu vi pessoalmente todos os tipos de comportamentos loucos que resultam disso (fingir contagens de bugs, disputar sobre detalhes insignificantes como quantos pixels estão fora de algum elemento, sabotar builds, e assim por diante).

Algumas ressalvas. Primeiro, eu não estou dizendo que se preocupar com a qualidade não é muito importante. Pelo contrário, é importante o suficiente para que todos na equipe tenham que desempenhar um papel direto para fazer um produto de qualidade.

Eu também não acho que é uma má ideia ter alguém especificamente responsável por garantir a qualidade. Isso não é para absolver os outros, mas para dar uma maior visualização sobre as coisas. Eu acho que as estratégias de teste eficazes, bem como arquiteturas eficazes, não bastam vir à existência, mas necessitam de premeditação e planejamento.

Gerente de desenvolvimento

Em primeiro lugar, só para ficar claro, eu estou falando especificamente sobre pessoas cuja única responsabilidade é gerenciar desenvolvedores, e não o código. Por que isso é ruim?

Primeiro, se você precisa de alguém para gerenciar os desenvolvedores, você provavelmente tem desenvolvedores que precisam ser gerenciados. Alguém que eu admiro muito disse uma vez: “Eu não contrato supervisores, porque eu também não contrato pessoas que precisam ser supervisionadas”.

Em segundo lugar, os gestores de dev muitas vezes têm opiniões fortes sobre o código. Eles têm pensamentos sobre como as coisas devem ser arquitetadas e implementadas, quais linguagens, bibliotecas ou frameworks devem ser usados, quais convenções de codificação devem ser seguidas, e assim por diante.

Opiniões são algo muito bom. É bom tê-las e é ainda melhor compartilhá-las. No entanto, quando se trata de opiniões sobre o código, elas só importam se você tem que viver com as suas consequências.

Eu fui culpado disso muitas vezes. Eu fazia pronunciamentos grandiosos como “vamos usar o framework X!”, sem entender como seria realmente viver com esse framework. Coisas do tipo, como é fácil implementar, ou debugar, ou compreender, ou
olhar. E, o que é pior, ao ouvir receio ou preocupação absoluta dos devs que têm que conviver com isso, eu diria “Ah, vamos lá, o quão difícil isso pode ser?”

Isso é ruim. Bons devs respondem muito mal a tal babaquice. Na verdade, é uma grande estratégia para perder o respeito deles. E, uma vez isso tenha sido perdido, você tem problemas reais.

Gerente de projeto não técnico

O principal objetivo de ser um gerente de projeto é ajudar a equipe a gerenciar riscos. Eu diria que é praticamente impossível fazer um bom trabalho de gerenciamento de risco do que você não entende.

Mas eu não estou dizendo que não é importante ser capaz de montar gráficos Gantt e relatórios de progresso ou realizar sessões de planejamento. Estou dizendo que isso é muito menos importante do que entender onde estão os bits mais arriscados e descobrir o que fazer sobre isso.

Assim, por mais agradável que seja ter certificações “PMI” ou “ScrumMaster , essas coisas não são suficiente para ser um gerente de projetos eficaz em um projeto de software.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://tatiyants.com/management-anti-patterns-on-product-teams/