Vamos referir de forma breve algumas dicas de planeadores profissionais que o apoiam a manter o seu projeto na linha.
Há uma série de erros comuns que são praticados quando se criam os planos do projeto, particularmente por pessoas que chegam de novo a estas artes. Apontamos alguns dos mais frequentes enganos que encontramos e falamos acerca das boas práticas comuns de orientação e dos dilemas que estas fazem que os planeadores tenham de enfrentar no mundo real.
Vamos tratar de 3 questões:
1. Evitar a lógica com fins em aberto
2. Utilize o número mínimo possível de constrangimentos
3. Mantenha a duração das atividades abaixo de 45 dias a não ser que sejam do tipo Level of Effort
Estamos sempre a lutar contra a aparência de as boas práticas serem contraditórias, porque quando seguimos uma somos forçados a não usar a outra ou a ignorá-la. A orientação relativa a fins em aberto (open ends) é uma daquelas que nos coloca perante um dilema-
Lógica de fins em aberto
Várias orientações dizem que deve ser evitada a lógica de atividades com o fim em aberto que, portanto, não têm sucessores. Esta parece a questão que se vê de forma mais comum nos planos, em que uma atividade não tem sucessor e fica flutuando no fim de uma cadeia de predecessores. Quando se pergunta ao planeador a razão para isto a resposta é quase sempre a mesma: “Não há outras atividades dependentes desta atividade, assim não há sucessor”. Em termos do mundo real, isto até tem muito sentido, se não há nada dependente da sua conclusão então não há dependência para ilustrar.
Contudo, a boa prática é não ter estas atividades flutuantes na rede. Ao fazermos isto retiramos a atividade do caminho crítico e criamos um muito grande e desabitual Total Float. Pode retorquir que se cabe dentro do âmbito do projeto, em algum ponto irá causar impacto na conclusão do projeto, assim se não puder ser mais nada pode-se fazer da milestone final do projeto o seu sucessor.
Entretanto, em projetos mais longos, isto pode incrementar os limites do Total Float, em especial se esta atividade ocorre cedo no ciclo de vida do projeto. E então surgem os dilemas das linhas de orientação, pois a solução óbvia é adicionar um constrangimento ao fim da atividade flutuante, o que pode parecer um conflito com a orientação geral.
Limite a utilização de Constrangimentos da Atividade
O termo ‘constrangimento’ não se refere necessariamente aos atributos especiais de data de Início e Fim que podem ser adicionados às atividades na maioria das ferramentas de software. O termo ‘constrangimento’ pode significar uma relação entre duas atividades, sendo o constrangimento físico: isto é o telhado não pode ser construído até as paredes estarem concluídas. Pode ainda referir-se a uma condição num contrato onde foi especificada uma data de entrega crucial. Isto refere-se a um constrangimento externo. Contudo para o propósito em questão, referimo-nos a constrangimentos que podem ser adicionados como atributos especiais de data a atividades numa ferramenta de software. Estas datas irão influenciar o cálculo do caminho crítico.
Muitas das orientações publicadas recomendam um uso muito limitado destes constrangimentos num plano de projeto o que significa que as datas rígidas que são adicionadas às atividades irão prender as datas mais cedo ou mais tarde.
Se a atividade flutuantes (ou cadeia de atividades flutuantes realizam uma milestone importante do contrato, então, o uso de uma data de constrangimento é adequado. Isto irá reduzir o float global nas atividades flutuantes. Para uma maior clareza do agendamento, deve ser adicionada uma Milestone como sucessor da atividade flutuante e o constrangimento deve ser aplicado a esta. Dependendo da proximidade da data de constrangimento das datas agendadas correntes, esta opção irá remover o Total Float à cadeia de atividades flutuantes. E se a data agendada é já mais tarde do que a data constrangida, será calculado float negativo indicando que já não se consegue alcançar a data contratual e são exigidas mudanças ao plano.
No exemplo seguinte, adicionámos uma milestone de realização do contrato ao final da atividade G e depois aplicámos um constrangimento de Finish On. A data de constrangimento é de três dias após a data de fim agendada para a atividade, assim temos 3 dias de Total Float, em vez dos 21 dias que tínhamos antes de termos introduzido o constrangimento. Podemos sempre ligar a data da Milestone Contract Complete à Milestone de Fim, mas se deslizar de tal forma que empurre para a frente a data de fim do projeto ficamos em problemas de qualquer forma. Podemos adicionar um lag longo entre a nova milestone e a Milestone de Fim, mas algumas orientações desencorajam a utilização de lags longos ou leads. O que irá finalmente fazer será um acompanhamento próximo, com base nas particularidades do trabalho real modelado.
As orientações que desencorajam a utilização de constrangimentos são sólidas porque demasiados constrangimentos irão mascarar o caminho crítico. Torna-se mais difícil diferenciar entre atividades no caminho crítico e atividades constrangidas. Já vimos agendamentos literalmente juncados de constrangimentos e era quase impossível discriminar o caminho crítico. Também pode criar enormes quantidades de float negativo o que não é nunca uma coisa boa. Se o cliente sabe alguma coisa pensa que as datas não podem ser alcançadas e os constrangimentos foram utilizados artificialmente para parecer tudo bem.
Em breve, use unicamente constrangimentos quando tem uma boa razão para isso. E mesmo assim utilize constrangimentos do tipo Start on or After or Before (constrangimentos soft), o que continuará a permitir que o agendamento siga na direcção em que deve ir.
Mantenha a duração das atividades abaixo de n dias
Vemos esta linha de orientação em algumas publicações ou mesmo estabelecidas em regras de contratos, e têm diferentes limites de duração dependendo dos tipos de projeto alvo. Claro que atividades continuadas como gestão, segurança, saúde etc. podem correr durante todo o projeto, mas estas são criadas como Level of Effort. Ou seja, uma atividade cuja duração está dependente de atividades às quais está ligada.
Uma atividade que não cria um resultado pode ter virtualmente qualquer dimensão, contudo os work packages concretos que descrevem um particular trabalho devem ser mantidos com uma dimensão razoável. Um máximo de dimensão costuma ser manter a dimensão das atividades abaixo de 3 meses. Quando a atividade é mais longa que isto, sugere que está a atuar mais como uma atividade sumária e isso significa que representa muitas operações que deviam ser decompostas.
Há contratos em que a dimensão da duração das atividades tem um máximo de duração definido para obrigar o planeador a decompor o trabalho. Este limite está muitas vezes ligado ao ciclo de controlo do projeto, isto é, num ciclo mensal podem exigir que não tenha mais 20 a 30 dias, num ciclo semanal, não podem exceder os 10 dias, etc.
Determinar o nível certo de decomposição do trabalho e estimar as durações das atividades pode ser por si um novo dilema. Existem várias linhas de orientação que discutem os métodos formais de fazer isto, tais como Opinião de Peritos, Estimação Análoga e Paramétrica. De qualquer modo, porque o trabalho pode ser sempre realizado de mais do que uma forma, estabelecer as atividades ao nível certo é sempre um desafio.
Quando cria a sua lista de atividades tenha presente que é desta forma que o trabalho vai ser registado. Se a descrição da atividade cobre mais do que um tipo concreto de trabalho, será difícil acompanhar e aplicar o status. Pense sempre na necessidade de oferecer atualização exata do status quando considera o nível de detalhe a que cria a atividade porque isso também ajuda na sua estimação.
Sumário
Quando chegamos ao fim, lembre-se que todas as orientações são desenhadas para oferecer o modo ótimo para alcançar um plano viável. São linhas de orientação e não leis rígidas precisamente por que cada plano tem um desafio único a ultrapassar. Os planeadores, que enfrentam o dia-a-dia cheio de desafios para manter válido o agendamento, receber orientações pode ser um assunto difícil, particularmente quando sabemos que temos de ignorar algumas delas para que o plano reflita a realidade que tentamos modelar.
Tradução de Ten Six
