Na formação comparar o que é comparável, mas que tenho visto pouca gente a fazê-lo de forma clara e ausenta de opinião: metodologias ágeis e as abordagem clássicas de gestão de projectos. O prof. Alexandre Rodrigues fez uma analogia não posso deixar de partilhar.
O modelos actuais da gestão de projecto, sejam clássicos (como o normativo do PMI) ou ágeis (como XP ou Scrum) assentam em quatro variáveis: âmbito, custo, tempo e qualidade. O âmbito diz o que é para fazer, o custo afirma quanto vai custar, o tempo serve para definir quando vai estar concluído e a qualidade garante o bom resultado do projecto (i.e. sem defeitos). A alteração de uma variável pode afectar as outras de formanão linear.
Numa abordagem clássica tenta-se controlar o âmbito, ajustando as outras variáveis de acordo como se pretende implementar esse mesmo âmbito. Em fase de proposta acorda-se (i.e. contractualiza-se) o valor das outras três variáveis, de acordo com uma estimativa de quanto vai custar, quando estará pronto e em com que nível de controlo de qualidade. Qualquer alteração ao âmbito requer uma alteração ao contracto. Ou seja, eu peço o orçamento a um pedreiro para me construir um muro de 1m de altura no quintal. O pedreiro diz quanto isso me vai custar, quando estará pronto e sobre que condições de supervisão. Posto isto firma-se o contracto. Se a meio de obra eu decidir que pretendo o muro com altura de 80cm, o pedreiro tem que verificar o impacto que isso tem na obra em curso e apresentar um novo orçamento. Por outro lado, se a obra se atrazar, custar mais que o previsto ou forem feitas menos ispecções (i.e. pode ter mais defeitos), o custo adicional fica a cargo do pedreiro. Pode também acabar a obra mais cedo e assim fica com mais tempo para dedicar a outras obras. Pela perspectiva das metodologias clássicas, o âmbito é fixo e o tempo vai encolhendo ou esticando conforme a execução da obra vai correndo mais depressa ou mais devagar que o esperado. Ou seja, o âmbito pode ser visto como uma caixa onde se coloca ou tira tempo.
As metodologias ágeis assentam na ideia de que o âmbito global do projecto não está fixo. Ou seja, há uma ideia inicial do que é para fazer mas assume-se que a tarefa vá sendo alterada com o decorrer do projecto. Para lidar com este problema o projecto é executado com base em iterações (i.e. sprints em eXtreme Programming). No inicio da iteração define-se um conjunto de tarefas a executar, mas estas vão alterando conforme a iteração vai correndo. Se corre melhor colocam-se mais tarefas, se pior tiram-se as de menor impacto nas regras de negócio. Pode-se até substituir tarefas se o representante do negócio assim o entender. Por exemplo, imagine-se que eu queria à mesma fazer um muro de 1m no perímetro do quintal. Eu acordava com o pedreiro uma primeira iteração em que este iria tentar completar o muro. Se a meio da iteração eu desejasse colocar uma porta de ferro em vez de uma de madeira, o pedreiro não se iria importar, mesmo que isso implicasse tirar a porta que acabou de colocar. Por outro lado, se durante a iteração o pedreiro concluísse que estava a meter menos tijolos por dia do que os inicialmente estimados (i.e. à partes do muro que passam para a próxima iterarão), eu não me importaria e aceitaria o erro na estimativa sem exigir uma alteração contractual. Seguindo a analogia da caixa, na perspectiva das metodologias ágeis o tempo é fixo e o âmbito vai encolhendo ou esticando, conforme a execução da obra vai correndo mais depressa ou mais devagar que o esperado. Ou seja, o tempo pode ser visto como uma caixa onde se coloca ou âmbito.
Há uma diferença entre as abordagens clássicas e ágeis que eu já tinha percebido. Enquanto nas abordagens clássica assume-se que o contracto assenta num projecto a custo fixo, nas abordagens ágeis assume-se um contracto a Time and Materials (não sei traduzir isto). Mas esta analogia da caixa parece-me genial. Apresenta uma nova perspectiva sobre as duas abordagens. Só por isto já valeu a formação... mas valeu também pelo resto do programa.
Abraços,
Tiago Franco
2 comentários:
Apesar de já ter reparado nas duas abordagens, ainda não tinha pensado pensado nelas de forma tão estruturada. De qualquer maneira, quando pensei no assunto, uma ideia que me surgiu e que me parece boa (não tendo (in)formação no assunto, entenda-se) é que se possam usar ambas as abordagens em simultâneo. Ou seja: em algumas partes do projecto priveligiar o âmbito, noutras priveligiar o tempo. Será que esta definição deveria fazer parte do planeamento do projecto, definindo à partida quais as tarefas "âmbito" e quais as tarefas "tempo"?
Geralmente a opção de seguir uma abordagem clássica ou ágil é aplicável ao projecto como um todo. Principalmente porque é um questão contractual, e é raro ter um contracto por tarefa.
Mas é comum que, durante a execução do projecto, se tenha que decidir em ceder no âmbito ou no tempo. Ou seja, quando as coisas não correm como esperado, tem que haver uma decisão de fazer cortes. Caberá ao responsável comercial do projecto decidir qual a vertente em que o cliente é menos sensível, de forma a evitar uma penalização contractual. Ou seja, à projectos em que o cliente não se importa de receber os deliverables mais tarde do que o acordado.
Enviar um comentário