Embora eu adore ler livros de programação, acho que os livros de gerenciamento de projetos de software são uma das leituras mais entediantes que já tentei fazer. Suponho que isso signifique que eu provavelmente não deveria ser um gerente de projetos. A má notícia para o equipe do Stack Overflow é que eu sou efetivamente uma.
Isso não quer dizer que todos os livros de gerenciamento de projetos de software sejam ruins. Apenas a maioria deles. Um dos poucos que achei interessante o suficiente para terminar é o livro de Johanna Rothman Behind Closed Doors: Secrets of Great Management. Ela o escreveu em conjunto com Esther Derby.
Depois de lê-lo, o senhor perceberá que esse é o livro que eles deveriam ser distribuído a todos os gerentes de projetos de software recém-formados. E o senhor ficará profundamente deprimido porque não trabalha com nenhum gerente de projeto de software que aparentemente têm lido.
Descobri Johanna quando um de seus artigos foi citado no livro original de Spolsky Melhor redação de software livro. Seu artigo sobre remuneração da equipe (pdf) basicamente explodiu minha mente; isso me forçou a repensar toda a minha perspectiva sobre o ser pago para trabalhar em um emprego. O senhor deve lê-lo. Se o senhor tiver um gerente, peça a ele que o leia também. (Atualização: este ensaio é, na verdade, do Mary Poppendieck, que também é excelente. Vou deixá-lo no post porque é uma leitura fantástica, mesmo que esteja um pouco fora do tópico).
Desde então, falei brevemente sobre seu trabalho em Jogos de Programação e O senhor não é o seu trabalho. Mas gostaria de me concentrar em um aspecto específico do gerenciamento de projetos no qual aparentemente não sou muito bom. Uma pessoa que ligou para o Podcast #16 me chamou a atenção para o fato de o minhas alegações originais sobre o cronograma do Stack Overflow no final de abril. O que era para ser “6 a 8 semanas” se tornou… bem, algo mais parecido com três meses.
Meu problema é que sou quase patologicamente ruim em anotar as coisas. A menos que eu esteja escrevendo uma entrada de blog, suponho. Prefiro acompanhar o que estou fazendo em minha cabeça, antecipando apenas o próximo item em que pretendo trabalhar, enquanto prossigo o mais rápido possível. Acho que fui vítima, pelo menos um pouco, do deste cenário:
“Veja, Mike”, disse Tomas. “Posso entregar meu código hoje e chamá-lo de ‘recurso completo’, mas provavelmente terei três semanas de trabalho de limpeza para fazer depois de entregá-lo.” Mike perguntou o que Tomas queria dizer com “limpeza”. “Ainda não consegui que o logotipo da empresa apareça em todas as páginas e não consegui que o nome e o número de telefone do agente fossem impressos na parte inferior de cada página. São pequenas coisas como essas. Todas as coisas importantes funcionam bem. Estou 99% pronto”.
O senhor está vendo o problema aqui? Eu sei, são tantos que o senhor difícil saber por onde começar a listar todos elesmas qual é o problema mais profundo e fundamental que está ocorrendo aqui?
Este desenvolvedor de software não tem uma lista detalhada de todas as coisas que precisa fazer. Isso significa que, apesar de afirmar categoricamente que está 99% concluído, ele tem nenhuma ideia quanto tempo levará o desenvolvimento! Simplesmente não há base factual para nenhuma de suas reivindicações de cronograma.
O trabalho de um bom gerente de projetos de software é reconhecer os sintomas reveladores desse erro clássico e abordá-los de frente, antes que descarrilem o projeto. Como? Por meio de forçandoincentivando os desenvolvedores a criar uma lista detalhada de tudo o que precisam fazer. E, em seguida, dividir essa lista em subitens. E, em seguida, adicionar todos os subitens que o senhor inevitavelmente esqueceu porque não pensou com tanta antecedência. Quando o senhor tiver todos esses itens em uma lista, então, e somente então, poderá começar a estimar quanto tempo o trabalho levará.
Até que o senhor tenha pelo menos o início de uma lista de tarefas, qualquer conceito de agendamento é pura fantasia. Uma fantasia muito agradável, com certeza, mas o mundo real pode ser extremamente implacável com esses sonhos.
Johanna Rothman faz a mesma observação em um recente boletim informativo por e-mail e oferece ações específicas que o senhor pode tomar para evitar ficar preso em 90% do trabalho:
- Liste tudo o que o senhor precisa fazer para concluir a grande parte do trabalho. Incluo qualquer trabalho de infraestrutura, como a configuração de ramificações no sistema de controle de origem.
- Faça uma estimativa de cada item dessa lista. Essa estimativa inicial o ajudará a ver quanto tempo pode levar para concluir a tarefa inteira.
- Agora, veja quanto tempo cada item da lista levará para ser concluído. Se a tarefa for maior que um dia, divida-a em partes menores. Dividir tarefas maiores em partes menores é fundamental para escapar da síndrome dos 90% concluídos.
- Determine uma maneira de mostrar o status visível a qualquer pessoa interessada. Se o senhor é a pessoa que está fazendo o trabalho, o que teria de fazer para mostrar seu status ao seu gerente? Se o senhor for o gerente, o que precisa ver? Talvez o senhor precise ver listas de casos de teste, uma demonstração ou qualquer outra coisa que mostre um progresso visível.
- Como o senhor tem tarefas de um dia ou menores, pode acompanhar seu progresso diariamente. Gosto de manter um gráfico ou uma lista das tarefas, meu tempo estimado inicial de término e o tempo real de término de cada tarefa. Isso é especialmente importante para os gerentes, para que o senhor possa ver se a pessoa está sendo interrompida e, portanto, está fazendo várias tarefas ao mesmo tempo. (Veja o artigo sobre a Jogo de programação Split Focus.)
Não gosto muito de agendas, nem de listas, mas sem elas, eu não pode ter o primeiro. É como tentar desafiar a lei da gravidade. Portanto, em nosso projeto, estamos sempre 90% concluídos. Se o senhor quiser escapar do gueto dos 90% prontos em o senhor projeto de software, não aprenda isso da maneira mais difícil, como eu fiz. Sempre que alguém lhe perguntar qual é o seu cronograma, o senhor deve ser capaz de apontar para uma lista de tudo o que precisa fazer. E se não puder, o primeiro item de sua lista de tarefas deve ser criar essa lista.