Na Gerência de uma equipe de desenvolvimento, há aspectos tão ou mais importantes que a ferramenta de controle da produção. Em uma situação normal utilizo a seguinte técnica:simplicidade, objetividade e eficiência. Uso uma tabela (Excel,Word ou Project, dependendo do tamanho do projeto) com as colunas:
- Id da tarefa
- Nome do desenvolvedor
- Horas previstas
- Horas realizadas
- Observações
As horas são alocadas com base histórica. Não uso FPA. O desenvolvedor me diz quantas horas vai gastar com determinada funcionalidade já com os testes básicos. Para que isso funcione é preciso que você trabalhe com desenvolvedores experientes e responsáveis. Um estagiário não conseguirá te dizer essas horas. Na metade do tempo previsto eu reviso a tarefa e/ou vou lá ver como está. Se já houver atraso ajusto o cronograma e documento o que houve.
Normalmente um desenvolvedor experiente aloca as horas em uma tarefa já prevendo possíveis imprevistos. E consegue te entregar no prazo correto, com alto índice de corretude. Isso já o coloca no seu limite de capacidadede produção. Você pode e deve, naturalmente, fazer uma crítica nas horas alocadas pelo seu desenvolvedor. Mas repito, se ele for bom e confiável, não será possível que ele entregue a tarefa em menos tempo sem afetar a qualidade.
Lembre-se: "uma mulher gera um filho em nove meses, nove mulheres não gerarão um filho em um mês." Conheça a tarefa que você vai delegar e saiba da real possibilidade de tempo de execução e pronto. Um bom desenvolvedor irá te entregar a tarefa nesse tempo.
Existem alguns outros aspectos. Penso em tratar isso em um artigo posterior. Qualquer esclarecimento a mais, entre em contato.
2 comentários:
Vagner, aceitei recentemente o desafio de coordenar uma equipe desenvolvedores para a conclusão de um projeto que já se arrasta por algum tempo. O dilema está em como administrar o desenvolvimento das ferramentas essênciais do sistema e solicitações de ajustes para que o processo de trabalho do usuário não pare. Os programadores não conseguem concluir o desenvolvimento porque estão ajustando provisóriamente alguma outra coisa. Abs.
Caro colega,
seu caso é muito típico.
Há várias abordagens para esse problema.
Qual abordagem você deve usar, depende do perfil do seu cliente.
A mais comum seria:
1. Se o projeto "se arrasta por algum tempo", significa que riscos previstos ou não, aconteceram.
Lembrando que risco é tudo aquilo que impacta no cronogram (positivamente ou negativamente).
Identifique esses riscos. Coloque no papel e obtenha um aceite do cliente.
2. Uma vez identificado o que aconteceu, redefina o escopo. Provavelmente seu escopo está mudando a toda
hora. Saiba o que falta fazer. Coloque no papel e obtenha o aceite do cliente.
3. Separe as naturezas de manutenções. Tenha isso muito claro na sua cabeça,
e na cabeça de todo mundo (desenvolvedores e cliente principalmente). Neste cenário, os desenvolvedores
só devem fazer manutenções corretivas, aquelas que você falou "para que o processo de trabalho do usuário
não pare". Mas por outro lado o cliente só irá aceitar isso se você tiver uma data para passar para ele de
quando o restante ficará pronto. E você só terá essa data, realizando os itens 1 e 2. Principalmente cuidando
para que os riscos não aconteçam de novo. Se o restante for muita coisa, versione.
4. Outras observações:
- verifique esse "estão ajustando provisóriamente alguma outra coisa.". Se está todo mundo nesse processo
tem alguma coisa errada aí. Deveria ser possível você deixar no máximo um desenvolvedor por conta disso.
- me parece que seu projeto virou um processo. Não pode. Porque processo não termina mesmo. Já o projeto
tem escopo definido, data de início e data de fim. Convença o cliente disso.
- certifique-se de ter acesso às pessoas certas no cliente. Quem tem a regra e/ou quem tem poder.
como eu disse essa é uma das sugestões. Existem outras estratégias que podem ser adotadas nesse caso. Essa me
pareceu a mais fácil em função do que você me falou.
Parabéns por ter aceitado o desafio.
Obrigado por ter escrito e fique à vontade para escrever novamente.
Postar um comentário