Gestão de Escopo e Tempo com Scrum, evitando conflitos com o cliente

Mudança de escopo do projeto ou uma necessidade inesperada do cliente no decorrer de todo o processo é algo bem comum e sempre gera muito estresse. Todos já passamos por isso um dia.

Caso sejamos clientes e esqueçamos de algum detalhe, já esperamos que essa possível “Change Request” vá custar caro. Seja por conta do valor que será cobrado pelo fornecedor, por conta do tempo que vamos perder ou pelo esforço de convencer a gerência a investir nessa empreitada.

Se somos fornecedores, devemos considerar o trabalho para reorganizar as atividades, ajustar as agendas dos integrantes do time, negociar valores com o cliente, ajustar outros projetos que dependem desse, etc.

Exemplificando o problema
Vamos supor a seguinte situação: a consultoria X1 fechou um projeto com o cliente Y para entregar um sistema de controle de estoque. Foram levantadas dez funcionalidades a serem desenvolvidas.

Para estimar o valor que será cobrado do cliente, levou-se em consideração o esforço que costuma ter para realizar as seguintes atividades:

• Tempo de levantamento de requisitos
• Tempo para desenvolvimento
• Tempo para testes
• Treinamento
• Subida para produção
• Operação assistida

Além disso, outros custos devem ser levados em conta, como: infraestrutura; tempo para adquirir o conhecimento necessário; softwares; parceiros; tempo de gerenciamento; etc. Importante: o lucro também precisa ser incluído.

Se algum desses fatores sofrer alteração, pode impactar na entrega do projeto. Por isso, mudanças de escopo não são bem aceitas por parte da consultoria.

No decorrer do desenvolvimento do projeto, se o cliente necessitar alterar qualquer requisito ou se surgir uma nova funcionalidade importante não prevista, é inevitável que ocorra o estresse.

O gerente de projetos que coordenará o escopo do projeto, precisa informar o cliente que qualquer mudança irá gerar uma “Change Request”, ou seja, haverá um custo adicional para incluir determinada mudança.

O cliente pode não ter previsto esse gasto adicional no início, fazendo com que o projeto precise ser suspenso temporariamente até que novos recursos sejam captados para sua conclusão. É possível que a área que solicitou o projeto tenha que justificar o aporte de novos valores para várias áreas internas e, com isso, perder a credibilidade.

Por sua vez, a consultoria não pode simplesmente parar até que sejam definidos os próximos passos. Afinal, há profissionais destacados para o projeto e a interrupção pode atrapalhar todo o fluxo de trabalho interno. Por isso, é de suma importância que o prazo inicial seja cumprido.

Nesse momento não é difícil que ocorra uma quebra de braço entre cliente e consultoria. Um pode culpar o outro e ambos acabarem perdendo. Afinal, todo o trabalho desenvolvido até então corre o risco de ter sido em vão se o projeto for abandonado. A relação entre as duas partes pode ficar comprometida, caso não haja habilidade de negociação e empatia dos dois lados.

Como já falado em outro artigo, é muito comum que em projetos ágeis, sobretudo, os projetos Scrum, utilizem a técnica de Scrum Poker para estimar o esforço das atividades. Podemos traduzir esse esforço em tempo.

Em projetos tradicionais, o tempo é contado em horas ou dias. Já no Scrum Poker, as entregas são frequentes, a cada intervalo de dias, por exemplo.

À primeira vista, a abordagem do Scrum Poker não parece muito atrativa. Porém, quando tratamos de entregas, estamos falando de algo pronto, que imediatamente vai agregar valor ao cliente.

Ao aplicar a técnica do Scrum Poker (método que utiliza cartas numeradas para definir o esforço na realização das atividades através de pontos), teremos a ideia da quantidade de esforço necessária para entregar as atividades de um projeto.

Voltando ao nosso problema principal: como a consultoria X1 pode melhorar a satisfação do cliente Y sem perder tempo e dinheiro? O Scrum tem a resposta que envolve gestão de escopo e estimativa de esforço baseadas em pontos (Scrum Poker).

Vamos exemplificar: supondo que no início do projeto, com a ajuda da equipe de consultores e após um levantamento de requisitos iniciais, a consultoria estime que o projeto necessite do esforço de 200 pontos para desenvolver as dez funcionalidades iniciais.

O desenvolvimento tem início e alguns requisitos importantes foram entregues nas primeiras Sprints. Essas funcionalidades exigiram 50 pontos de esforço. Nesse momento, o cliente identificou que existem funções que não estavam no escopo original e precisam entrar no projeto com urgência.

Como sabemos, o Scrum prioriza o que é mais importante para o cliente. Além disso, o Product Backlog (lista ordenada de tarefas) é algo vivo e pode ser repriorizado a qualquer momento. Inclusive, por conta disso, um cronograma tradicional não se aplica ao Scrum.

Essa adaptabilidade é um dos pilares do Scrum (Clareza, Inspeção e Adaptação).

Em suma, basta o Product Owner do projeto colocar essas funcionalidades como novas prioridades e solicitar ao Time de Desenvolvimento (consultores) para estimar o esforço em pontos.

Vamos supor que o time acredita que as novas funcionalidades representem 40 pontos. Essa pontuação substituirá outras funcionalidades menos relevantes. É muito provável que algumas funções definidas inicialmente percam sua importância diante das que estão sendo entregues.

O cliente irá receber suas funcionalidades de tempos em tempos, não apenas no final do projeto. Isso traz um retorno de investimento muito rápido, impedindo que todo o esforço empregado até então seja um fracasso total.

Essa abordagem praticamente elimina a crise que poderia acontecer com uma possível mudança de escopo, sendo uma forma de gerenciar riscos, permitir o monitoramento, reduzir custos, controlar o tempo e, também, o escopo no geral.

Creio ter conseguido passar esse ponto de vista adiante. Espero que esse artigo seja útil ao menos para iniciar discussões sobre o uso de técnicas ágeis. Um abraço!
Por: Fernando Silva – Especialista GRA Actionsys