Afigura-se que o PO está “no meio”: um “subordinado” queixou-se aos responsáveis da empresa de que um chefe de equipa/director de projecto o está a secundar. Por várias razões, esta parece ser uma equipa de software. Embora não seja estritamente relevante, o que pode constituir um problema é o facto de se esperar que a pessoa que desempenha uma função de “engenharia” administre o seu tempo, tal como um funcionário de vendas a retalho - dentro e fora, às 8 horas da manhã e às 17 horas. Parece que também há aqui outras questões, mas não estão discriminadas.
A questão, tal como colocada, é “O que devo dizer à gestão sénior? Isto sugere que a primeira preocupação do PO é como é que ele está a ser visto pelos seus próprios gestores. Do ponto de vista do gestor sénior, dois egos estão numa luta de gatos - um escrevendo código e o outro gerindo um projecto. Isto implica uma certa distância social entre o "promotor” e o “supervisor”. O supervisor parece estar a tentar dizer ao subordinado: “você foi contratado para fazer o que lhe é dito - não questione a autoridade”. Embora a localização real não seja evidente pelo conteúdo, isto soa como uma loja algures na Ásia.
O que a direcção quer ouvir é que os dois beligerantes descobriram como fazer o seu trabalho com um mínimo de fricção. Será que ele deve trazer todos os pontos negativos do seu superior ou o quê?“ seria uma má jogada - muito má. Tudo o que os seniores estão a ver neste momento é que dois empregados estão a discutir em vez de fazer o seu trabalho.
Portanto, correndo o risco de "não responder à pergunta”, eu proporia o seguinte:
O PO determina quais as métricas aplicáveis para medir o desempenho do promotor. Não é provável que seja a hora de entrada e de saída. É provável que seja a produção de produtos - código, documentação, fixações e apoio ao utilizador em quantidades razoáveis de tempo. Isto poderia aplicar-se tão facilmente a outras formas de engenharia - desenho de chips, projecto arquitectónico ou ponte. Todas elas têm misturas complexas de “concepção de núcleo”, documentação, revisões e resposta às reacções dos consumidores.
- Depois de ter descoberto as métricas, aplique-as ao revelador/engenheiro. Ele está a escrever código, a corrigir problemas e a apoiar os utilizadores de forma satisfatória? Em caso afirmativo, pare de o provocar com coisas que obviamente o incomodam. Veja se é possível identificar problemas de tempo que não são visíveis durante o horário de trabalho, tais como chamadas telefónicas nocturnas, trabalho aos fins-de-semana, ou outra actividade que perturbe a semana normal de 40 horas.
Há algum valor na introspecção. A OP está a participar num jogo de poder apenas para estabelecer ou manter a “classificação”? Pessoas em funções de engenharia entram em lutas com “gestores de linha” a toda a hora por causa de roupas, pausas, linguagem, horário de trabalho e protocolos de contacto com o utilizador ou cliente. Os engenheiros vêem o comportamento dos gestores como obstrucionista - mais preocupado com as aparências e os pré-requisitos do que em fazer as coisas. O PO poderia usar esta oportunidade para descobrir se os hábitos adquiridos num tipo diferente de organização (ou estrutura familiar) são contraproducentes aqui.
Tendo feito essas coisas, é hora de sentar-se com o desenvolvedor - idealmente fora do escritório - dizer ao almoço. Incentivar e permitir que o programador fale sobre a forma como o tempo é passado dia após dia - os pedaços disponíveis para codificação/design, as interrupções dos supervisores, interrupções dos utilizadores, problemas que o mantêm ocupado durante as horas em que não está a trabalhar, mudanças de especificações “do nada”, etc. Não se surpreenda se a conversa divagar - se assim o fizer - suavemente.
A partir daí, tente descobrir que eventos em particular desencadeariam a aparição tardia ou uma longa pausa - entre as coisas que desencadeiam a primeira (a partir da minha experiência pessoal) está apenas a ter um entendimento vago do que fazer a seguir. Muitas vezes sentava-me na minha reclinável em casa durante duas ou três horas só a pensar em como estruturar algo, depois, quando a resposta chegava, eu ia para o trabalho e fazia-o. Já tive muitos supervisores a queixarem-se da minha hora de chegada - nenhum sobre a qualidade do que fiz.
Se o engenheiro está a ser muito interrompido, o trabalho dos POs é descobrir como interceptar aqueles para que haja menos deles. Isto significa, em particular, não criar mais arbitrariamente. De onde vêm as interrupções, e podem ser diminuídas? Isto é muitas vezes o que os supervisores devem fazer - manter os decks limpos para que os programadores/designers/engenheiros possam concentrar-se em tirar as suas coisas.
Se o programador não for realmente capaz de explicar para onde vai o seu tempo, então pode haver um problema de competência. Mais uma vez, isto está focado na saída, não no relógio de ponto. Os prazos não são cumpridos porque nada é feito ou porque outra pessoa está sempre a mudar de ideias? Se o programador tiver de continuar a começar de novo, então nada será feito. Se assim for, porque é que isto está a acontecer? Espera-se que os supervisores bloqueiem os requisitos para que a equipa possa trabalhar para um alvo fixo.
Se todas essas coisas acontecessem, o O supervisor poderia comunicar à direcção que a produtividade está a melhorar e que os utilizadores estão a obter a infra-estrutura informática de que necessitam.