Gestão da Mudança

Como é que gere a mudança no seu projecto?

A mudança é uma das coisas mais difíceis de lidar durante um projecto. Existem várias razões para isso, não há recursos disponíveis, a calendarização do projecto não pode ser alterada, o orçamento é limitado, etc.

As pequenas mudanças são fáceis de implementar com pouco ou nenhum impacto na data de entrega do projecto. Mas quando o pedido de mudança se refere a um comportamento já desenvolvido, ou em desenvolvimento, o problema torna-se mais sério.

Os gestores de projecto têm três coisas que podem ajustar durante o ciclo de vida de um projecto. Quando recebem um pedido de mudança de abrangência do projecto, só têm duas alternativas: adicionam recursos ou adiam a data de entrega.

Como é que eles podem evitar ter que tomar estas decisões?

Como um exemplo, imagine que está a trabalhar num projecto para desenvolver uma aplicação Web para gerir um sistema de Qualidade. Terminado o planeamento, o gestor de projecto estará em condições de dar uma data de entrega ao cliente. O primeiro passo é planear! Sim, isso envolve muitos passos e não é o meu objectivo discuti-los agora. Mas a Gestão da Mudança começa aqui.

Suponha que o projecto tem seis iterações (ou Sprints), sendo os últimos dois para estabilização (entenda-se que não há linhas de código novo, apenas correcção de erros). Provavelmente, começará por definir a abrangência do projecto, definir requisitos, definir a arquitectura e desenho, antes de começar a programar e testar. Quanto mais avançado nas iterações estiver, mais complicado se torna a gestão da mudança.

Mas todos sabemos que as mudanças não se podem evitar, a não ser que queiramos entregar, ao cliente, um produto que já não é o que ele quer.

Agora suponha que a sua equipa já está a programar e que você descobre que, uma funcionalidade importante, não foi planeada. O motivo pode ter sido uma falha de visão na fase de desenho. Imagine que essa funcionalidade afectará o código já escrito. Entra em pânico? Não é necessário.

Neste cenário, uma de duas coisas podem acontecer. Se investiu bastante tempo na fase de desenho e definição de requisitos, então a probabilidade do cenário descrito ocorrer é muito baixa. Caso contrário, a probabilidade sobe. Para estar preparado para isto deve considerar algum tempo, no seu planeamento, que poderá usar, caso um cenário como esta aconteça.

Deve existir um equilíbrio entre o tempo que se investe no desenho e definição de requisitos, e o tempo reservado a falhas de desenho ou requisitos. Isso depende da complexidade da aplicação, a especialização dos analistas e programadores, da experiência em projectos similares, entre outras coisas.

Pela minha experiência, diria que muitos destes pedidos de mudança acontecerão durante os testes. Quando os testadores começam o seu trabalho, eles têm um produto, ou parte dele, para testar, e torna-se mais fácil ver algumas situações quando se tem um produto na mão. Os programadores não olharam da mesma forma. Outra razão para isto é a capacidade dos testadores de verem as coisas como programadores e utilizadores, simultaneamente. Por isso é tão importante envolver os testadores em todas as fases do processo de desenvolvimento. Eles são bons aliados dos analistas e programadores.

Considere, agora, outro cenário. Durante uma apresentação ao cliente, este decidiu incluir mais uma funcionalidade, ou alterar uma já existente, mas sem que isso altere a data de entrega. Vai trabalhar durante a noite? Como é que vai incluir mais esta funcionalidade se não tem mais recursos disponíveis?

É importante dar isto ao cliente, de outra forma ele irá receber um produto que já não é o que pretende.

Pode usar a mesma estratégia usada no primeiro cenário, ou melhora-la.

Antes de começar a planear, tente negociar com o cliente uma Caixa, que ele possa usar para adicionar ou alterar funcionalidade, durante o desenvolvimento do projecto. A Caixa pode ser uma quantidade de tempo, número de recursos, iterações extra, número de linhas de código, qualquer coisa que ambos possam medir. O cliente deverá estar disposto a pagar por isso, e você terá que incluir isso no seu planeamento.

O meu conselho é que deve contar com mudanças porque elas, de certeza, irão acontecer.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s