Papéis e autoridades

Quem faz não responde sozinho por tudo

Em uma equipe pequena, a mesma pessoa pode conversar com o usuário, escrever código e preparar a publicação. Acumular funções é frequente. O problema aparece quando essa concentração apaga perguntas diferentes: a solução tem valor? Está tecnicamente correta? As verificações são suficientes? Quem pode aceitar o risco que resta?

Papel é uma responsabilidade assumida em determinada decisão. Autoridade é o direito reconhecido de decidir dentro de limites. A pessoa que implementa pode escolher o nome de uma variável sem poder decidir coletar dados pessoais. A mudança de finalidade pertence a outra esfera de responsabilidade. Precisamos explicitar esses limites antes que a dúvida chegue ao desenvolvedor iniciante.

Usaremos três personagens didáticos: Lia representa o produto; Rui implementa; Bia verifica. Eles não são pessoas que tenham revisado esta edição. A inteligência artificial aparece como ferramenta de apoio à preparação e análise, sem assumir a aceitação humana do produto.

Uma matriz RACI preenchida

RACI é uma tabela de distribuição de responsabilidades. R executa a atividade; A responde pela decisão final; C é consultado antes dela; I recebe informação. Neste exemplo, cada linha tem exatamente um A para evitar duas autoridades finais contraditórias. A mesma pessoa pode acumular R e A, mas isso torna visível a concentração, não cria revisão independente.

A última linha identifica uma decisão reservada, mas o escopo atual já exclui dados pessoais. Nenhum participante pode iniciar essa coleta como detalhe de implementação. Seria necessário propor mudança de escopo, analisar consequências e obter uma decisão explícita; até lá, a resposta operacional é não implementar essa coleta.

O caminho de uma decisão

Rui encontra um formulário que pede nome para simular uma reserva. Ele não substitui o nome por um identificador inventado e declara o problema resolvido sem examinar o fluxo. Primeiro identifica o requisito: a simulação não exige identificar pessoas. Em seguida propõe remover a solicitação. Bia verifica se a operação ainda demonstra repetição com efeito único. Lia decide sobre a adequação ao objetivo didático.

• Liste as decisões que podem bloquear o trabalho.
• Atribua a cada decisão uma autoridade e um substituto, quando houver equipe para isso.
• Declare o que o executor pode resolver e o que precisa escalar.
• Defina quem verifica os requisitos e como registra divergências.
• Vincule a aceitação da versão às evidências disponíveis e aos riscos residuais classificados.

Quando existe apenas uma pessoa

No estudo individual, você pode ocupar os três papéis em momentos distintos. Escreva o resultado esperado antes de executar; faça a implementação; depois compare o observado com a expectativa registrada. Use testes com entradas adversas e procure revisão externa quando o risco justificar. Essas medidas reduzem alguns vieses, mas não equivalem a uma segunda pessoa independente.

Condição de avanço e exercício resolvido

O trabalho pode começar quando as decisões necessárias têm responsáveis identificados e o executor sabe quais dúvidas escalar. A publicação só pode avançar quando a autoridade correspondente considera as evidências e aceita os limites da versão. Preencher a RACI ajuda a organizar essa decisão; não a substitui.

Exercício: no cenário, Lia pede a versão completa; Rui concluiu testes automáticos; a navegação por teclado de REQ-004 ainda não foi examinada. Atribua executar, verificar e aceitar. A versão pode ser liberada com base apenas no relato de Rui?

Referências para aprofundamento

A referência S03, SSDF, prática PO.2 sobre papéis e responsabilidades, apoia a atribuição explícita de responsabilidades. S01, área Software Engineering Management, oferece o contexto de organização do trabalho; a matriz deste capítulo é uma aplicação didática.