Planejar o escopo: as regras antes do jogo
Peter Mello ·
Em uma obra de ampliação industrial, o pedido chega numa terça-feira, durante a visita do cliente: já que a tubulação vai passar por ali, dá para incluir mais um ramal? O encarregado concorda, porque o material está no canteiro. Três semanas depois, o ramal aparece no boletim de medição, sem aditivo, sem desenho revisado e sem que ninguém se lembre de quem autorizou.
Escopo que cresce sem regra não aparece como problema no dia do pedido. Aparece na medição.
O Guia PMBOK trata desse assunto no processo de planejar o gerenciamento do escopo, que define como o escopo será descrito, validado e controlado ao longo do projeto. O resultado desse processo ainda não é a lista do que será feito, e sim o combinado sobre como essa lista poderá mudar.
No lançamento do Pandora Solver v1.0, esse combinado coube em três perguntas, escritas antes da primeira conversa sobre requisitos: quem aprova uma mudança de escopo, onde ela fica registrada e quando o escopo é revisado. As respostas foram curtas. A aprovação ficou com o responsável pelo produto, depois de ouvir o patrocinador. O registro ficou em um único documento versionado, o Escopo v1.0. A revisão ficou marcada para o fim de cada ciclo de entregas, e não para o momento em que alguém tivesse uma ideia nova.
É importante frisar que a regra não existe para dizer não. Ela existe para que o sim e o não sigam o mesmo critério. Sem ela, o pedido de mais uma função é aceito por impulso quando a equipe está animada, ou recusado por teimosia quando a equipe está cansada.
Percebe-se, na prática, que o plano de escopo tem um parente próximo que costuma ficar esquecido: o plano de requisitos. Ele define como cada necessidade será levantada, priorizada e acompanhada até a entrega que a atende. É o assunto do próximo capítulo.
No Pandora Solver, a mudança de escopo segue a mesma rota de qualquer outra decisão dentro do Fio Digital: tem responsável, tem status e deixa um registro que continua lá depois que a reunião termina. O ramal pedido na visita deixa de depender da memória de quem estava presente.
Este texto não pretende esgotar o tema. Um produto de software feito por uma equipe pequena e uma obra com cinco contratadas pedem regras de tamanhos diferentes. O que se mantém é a ordem: primeiro as regras, depois o jogo.