A relação entre programadores e “chefes” é historicamente tensa, apesar de ser fundamental para que se construa um grande produto. Já é hora de abolir de vez qualquer comportamento que nos faça esquecer que ambos estão do mesmo lado. Sempre.
E esta primeira discussão é sobre quando um programador precisa dizer não.
Parte 1 – Os problemas de um “não” seco
Em geral , quem está na linha de frente de um produto (chefe, vendedor, PO, etc), costuma trazer demandas para o time de software de modo desordenado. Vamos ilustrar:
Repare que Jhony está plenamente preocupado com o produto e com suas entregas. Repare que a fala do “chefe” também é preocupada com o produto. Qual o problema então?
O problema é que muita informação ficou subentendida, submersa, perdida:
- Jhony não deu abertura e nem ao menos soube a gravidade do problema;
- O “chefe” não recebeu explicação. apenas recebeu um adiamento da sua necessidade. E se for importante?
- Jhony adia para a próxima Sprint. Quando alguém tem um problema para resolver, esperar uma semana para discutí-lo é inviável;
- O último quadrinho é uma provocação para que tentemos imaginar o que cada um está pensando nessa hora. A informação no pensamento de cada um também fica perdia.
Ao meu ver, essa é a pior atitude. E apesar de estereotipada aqui, é equivalente a quando um freelancer demora para responder um e-mail e em menor grau, pode estar presente em pequenas conversas, quando não prestamos atenção de verdade ao que está sendo dito. O problema nesta forma de agir é que nada é encaminhado.
Parte 2 – Adiando para o o momento mais breve possível
Vamos agora iniciar com a mesma situação, mas com um pequeno detalhe, repare como tudo fica mais leve.
Jhony tem três atitudes excelentes aqui:
- Dedica atenção;
- Informa o motivo de não querer discutir isso neste momento, dando um elemento de valor para o “chefe”;
- Propõe uma estratégia de conversar em breve com o “chefe” sobre o problema dele. Detalhe, ele poderia não ter dado nenhuma estratégia, poderia ter parado em explicar o que estava fazendo. Este terceiro ponto é o segredo. A postura é de resolução do problema e não de informação sobre o problema.
Neste caso, o chefe entendeu que adiar em algumas horas era viável e Jhony pode voltar ao seu trabalho.
É claro que Jhony perde seu estado de “flow”. Faz parte, se o processo da empresa ainda não estiver bem estruturado, esta pequena perda de produtividade por interrupção ainda é melhor do que o “não” seco da primeira tirinha.
Parte 3 – E quando o problema é urgente.
Em alguns casos, do ponto de vista de quem tem um problema, ele é realmente urgente e precisa ser encaminhado imediatamente. Vamos para o exemplo:
Quando a demanda é urgente para alguém. Deve-se parar e ver, mesmo que todo o time precise parar.
Neste exemplo, fiz questão de colocar ambos lado a lado na frente do monitor. É importante que eles vejam e tentem encaminhar o problema o quanto antes. Agora o “chefe” consegue dar uma resposta ao cliente.
Mas isso não é o ponto final. A “tela em branco” continua sendo um problema e precisa ser resolvida.
Parte 4 – Negociação de Escopo
Aqui decidi não criar nenhum quadrinho. Negociação de escopo sempre depende muito da metodologia, do problema em si, da urgência. Mas vou elencar algumas possibilidades:
- Jhony (ou a equipe inteira) devem tentar estimar o tempo para resolver o problema e assim, ter mais elementos para a decisão;
- Se o tempo for curto, eles podem decidir fazer na mesma hora, destacando que algo pode atrasar;
- Se o tempo for longo, eles podem decidir fazer na mesma sprint, logo no dia seguinte, deixando claro para “o chefe” que o atraso pode fazer com que os recursos X, Y e Z não fiquem prontos na data estipulada;
- Se o tempo não puder ser estimado no momento, mas o “chefe” dizer que precisa que ele seja resolvido, a equipe deve dedicar o tempo necessário para poder passar uma estimativa completa e a especificação de com quais recursos eles não se comprometem mais;
- É sempre bom quando uma alternativa é encontrada e que permite ao time realizar o planejamento e entrega deste ajuste na Sprint seguinte. Neste caso, um exemplo seria enviar uma newsletter para a base de clientes informando o problema, e que logo o sistema de pagamento voltará ao normal;
Resumindo, ao final da conversa deve sempre ficar claro:
- Quando o trabalho será feito;
- Quais recursos foram comprometidos;
Conclusão
Para uma boa comunicação é necessário respeito pelo outro e abertura para ouvir e negociar. Acredito que programadores devem confiar, mas investigar as necessidades dos donos do produto, e os donos do produto precisam estar abertos para os questionamentos dos programadores.
E vamos lembrar que é sempre por um produto melhor. Quando, em alguma discussão desse gênero, surgir algum tipo de confronto negativo,lembre-se que quem perde são os usuários do produto.
Este artigo é uma inspiração direta do livro Clean Coder de Robert Martin e das questões que o papel de Scrum Master me faz vivenciar. Agradeço também ao Fernando Jorge Mota, que revisou as primeiras tirinhas (criadas com muita facilidade pelo serviço http://www.pixton.com).