Gerenciamento de Projetos: Recursos (Marcos, Tarefas e Ciclos de Feedback)
O gerenciamento de projetos é multifacetado, e a maneira como todos dividimos os vários aspectos de nossos projetos provavelmente depende de como nosso local de trabalho o faz, como o cliente deseja fazê-lo ou como optamos por fazê-lo nós mesmos.
Para este post, quando se trata de trabalhar especificamente em qualquer projeto, estou falando especificamente sobre como pegamos os requisitos de um projeto e os dividimos em partes e entregas mais gerenciáveis para as pessoas para quem estamos trabalhando. E ao fazer isso, acho importante que eles sejam mantidos no circuito e possam ver o progresso nos pontos de verificação adequados para obter feedback.
Apesar de mudar vários aspectos do meu negócio à medida que aprendi mais sobre o que funciona e o que não funciona, uma coisa que permaneceu consistente em como eu lido com os aspectos relacionados ao desenvolvimento de recursos de um projeto.
Recursos: Marcos, Tarefas e Ciclos de Feedback
Sempre que começamos a falar sobre esse tipo de coisa, é fácil cair no jargão da nossa indústria. E embora eu não ache que haja necessariamente algo muito técnico sobre “marcos" e “tarefas”, um “loop de feedback” é algo um pouco diferente.
Dado um conjunto de requisitos, não importa quão grande, eu imediatamente começo a examinar o documento – independentemente de como o recebemos – e a pensar em todas as peças que serão necessárias para alcançar um determinado recurso. Independentemente das linguagens, ferramentas, estruturas ou aplicativos com os quais você escolhe trabalhar, acredito que é aqui que ter uma profunda familiaridade com o que você trabalha é importante.
Quebra de recursos em marcos e marcos em tarefas.
A partir daí, vou dividir um determinado recurso em várias tarefas e repetir isso para cada um dos recursos. Normalmente, tento fazer de cada recurso um marco, mas alguns recursos são maiores que outros e precisam ser divididos em várias partes. Para esse fim, um projeto geralmente é dividido de tal forma que:
- Um recurso se torna um marco (ou marcos),
- Um marco é um grupo de tarefas,
- E uma tarefa corresponde a uma unidade funcional (não necessariamente uma função na base de código geral).
Então, você pode trabalhar para trás a partir disso para ver como isso corresponde a uma versão:
- Uma tarefa geralmente corresponde a um commit,
- Um conjunto de commits corresponde a uma tag,
- Uma tag corresponde à fusão de um recurso,
- Um recurso corresponde a um marco.
Nesse ponto, um marco deve estar pronto para ser implantado no ambiente de teste para que o cliente possa avaliá-lo em relação ao que ele tem em mente (e nos requisitos) para garantir que ele seja atendido.
Este é o lugar onde um loop de feedback entra em jogo. Mas primeiro, defino um ciclo de feedback simplesmente como:
Uma conversa em torno de um determinado recurso que determina se está concluído ou se merece mais trabalho.
Embora outros entrem em muito mais detalhes. Eu discordo, no entanto.
Portanto, enquanto aguardamos o retorno do cliente sobre o marco mais recente, eu – ou nós – normalmente avançamos com o próximo marco. É por isso que é importante ter uma maneira consistente de trabalhar com marcos, tarefas e comentários (junto com ramificações no controle de origem e ambientes de teste).
Comece a trabalhar em um novo recurso depois de confirmar o último no controle de origem e na preparação.
Se o feedback voltar do cliente, normalmente o pegamos, determinamos o que pode ser feito, o que não pode ser feito e, em seguida, o agrupamos em um novo marco. Às vezes, o marco é adicionado ao final; outras vezes, é adicionado como o próximo item de prioridade. Tudo depende da natureza do trabalho, do feedback e de como ele se encaixa no escopo do projeto.
Mais do que recursos
De um modo geral, esta é apenas uma visão de alto nível de como tento gerenciar os aspectos de desenvolvimento de recursos. Mas observar marcos, tarefas e ciclos de feedback é algo importante porque, uma vez que o sistema esteja em vigor, ele cria uma maneira previsível de que você e uma equipe possam implementar soluções.
Além disso, cria previsibilidade com entregas e comunicação com seu cliente, e isso funciona especialmente bem com clientes recorrentes, pois eles sabem o que esperar.
Como acontece com muitas das coisas sobre as quais escrevo, não tento apresentar isso como evangelho, mas acredito que ter algum sistema em vigor é importante. Eu não acho que alguém deveria criar um projeto, a menos que seja apenas um projeto pessoal e paralelo.
Portanto, independentemente da abordagem que você escolher, pelo menos tenha uma abordagem.