Você precisa de um herói - o gestor de projeto

Este artigo é para você, o empresário valente com uma idéia de aplicativo em seu coração e um pouco de dinheiro no banco. Os diagramas que você rabiscou em guardanapos do coquetel será notado em todo mundo, e os caminhões de descarga cheios do dinheiro foram despachados na sua casa. Para garantir que eles cheguem a tempo, aqui estão alguns conselhos simples para fazer o seu ciclo de produção funcionar sem problemas.

Em primeiro lugar, por que você precisa de um gerente de projeto

"Os programas de computador são as coisas mais complexas que os seres humanos fazem", diz Douglas Crockford. Você pode não ter ouvido esse nome antes, mas para um programador ele é muito famoso. Ele é atualmente um arquiteto de software sênior no Paypal, e ele foi pioneiro de todos os tipos de tecnologia legal que está além do alcance deste artigo. Ele é alguém que sabe muito sobre como trabalhar em grandes projetos.

Quanto a mim, eu tenho programado por 13 anos, e até agora, em algum momento, cada projeto me leva para um território inexplorado. Há tantas tecnologias diferentes lá fora, e novas técnicas estão sendo planejadas em uma taxa tão alarmante que eu nunca sinto que estou completamente no topo do que está acontecendo. Embora cada projeto tenha seus desafios únicos, existem algumas constantes:

• O projeto tem seu tempo de pressão.
• O orçamento é menor do que eu gostaria.
• Eu sou mais caro do que o cliente gostaria.
• Eu não escuto tão bem como o cliente gostaria.
• O cliente não explica as coisas tão perfeitamente quanto eu gostaria.

Claramente, precisamos de uma babá. Alguém tem de intervir para estabelecer as regras básicas, manter todos honestos e certificar-se de que não estamos esquecendo nada importante. Alguém tem que facilitar a comunicação entre todas as partes.

Esse alguém, esse herói, é o gerente do projeto.



Por que o gerente de produto está em uma caixa? Ele é um gato. Os gatos amam caixas.

A Toptal não ofereceu contratos com gerentes de projeto quando eu comecei a escrever este artigo, mas eles fazem agora. Sinergia! Já posso imaginar o poder que traz ler as dicas a seguir, e a percepção de que perdíamos uma grande oportunidade.

Por que um programador não se torna um bom gerente de projeto

Deixando de lado a Certificação pelo Project Management Institute, a coisa mais importante que um gerente de projeto pode trazer para a mesa é a experiência. Como resultado, muitos programadores se tornariam gerentes de projeto decentes; temos mais experiência do que ninguém em projetos técnicos e nossas mentes analíticas são adaptáveis na catalogação de informações e estabelecimento de metas concretas.

Deus sabe, você está nos pagando o suficiente, então parece razoável esperar que nós pudéssemos nos controlar, em vez de forçá-lo a pagar pelo tempo de outra pessoa também, certo?

Bem, para começar, você está nos pagando para codificar.

Quando saímos de nossa programação atordoada para tomar decisões sobre o que priorizar, ou para discutir sobre o que realmente vai ser feito esta semana, o código não está sendo escrito. Em seguida, leva pelo menos 10 minutos para voltar para a "zona", especialmente se estamos estressados pela conversa que acabamos de ter, o que é provável, se estávamos discutindo recursos prioritários. Não é grande coisa, eu sei, mas isso é tudo sobre como fazer o uso mais eficiente de recursos caros.

Mais importante ainda, nós realmente não podemos ver a floresta pelas árvores. Se você não tirar nada deste artigo, por favor, entenda isso: Se eu passar o dia todo olhando para alguns bugs específicos, meu cérebro perde o controle do quadro maior.

Meu cérebro recompensa-me quando eu corrijo os bugs, e eu suponho que fiz grandes coisas e que posso jogar video game agora. Quando alguém me lembra que a home page ainda está quebrada, vem como uma surpresa completa porque eu passei o dia enchendo meu cérebro com o conhecimento muito detalhado de um pedaço muito pequeno do projeto geral, esquecendo o resto dele. Isso é apenas como funciona o meu cérebro, e um monte de outros programadores têm um psicológico semelhante.



Quando saímos de nossa programação atordoada para tomar decisões de projeto, o código não está sendo escrito.

Por que o cliente não se torna um bom gerente de projeto

Bem, então, se nós programadores não queremos assumir a responsabilidade de fazer as coisas gerenciais do projeto, então ele deve cair para você, cliente. É o seu dinheiro. É a sua visão. Você é o responsável por tudo, de qualquer maneira.

No entanto, você também tem muito a fazer.

Muitos clientes são meros mortais com trabalhos do dia a dia, como nós, e alguns foram até mesmo conhecidos por sofrer de procrastinação ou esquecimento. Embora isso certamente não descreva você, por favor, considere a idéia de ter um 'Recordador Profissional' ao redor, de modo que possa regressar a um importante trabalho de manter o projeto com vida.

Se você trabalhou em, ou supervisionou, um projeto técnico de um âmbito semelhante, você talvez tenha se tornado, de fato, um bom gerente para o projeto. Se não, por favor, não subestime o valor de alguém que pode prever os problemas que possam surgir. Estimativas de tempo são sempre apenas estimativas, e os erros tendem a aparecer nos últimos momentos. Vale a pena o custo de outro empregado (que seja parcial) para ter alguém ao redor quem saiba que partes o processo precisa, ou são susceptíveis de necessidade, de maior atenção.

Faça, por exemplo, o controle de qualidade (QA). QA adequada é essencial para conseguir o que quer fora de qualquer projeto, e ele nunca recebe a atenção que isso merece. Um bom gerente de projeto vai aproveitar ao máximo os recursos limitados da QA, e também vai assegurar a qualidade dos programadores para você. Às vezes, nós saimos da nossa profundidade, e as vezes nós cometemos erros. Você precisa de uma pessoa tecnicamente proficiente em um papel de supervisão para determinar se o seu programador está tendo um mau dia, ou se, de fato, ele é uma boa alternativa para o projeto. Corrigir problemas pessoais desde o início pode significar a diferença entre a vida e a morte para o seu projeto.

Por último, mesmo você, ó glorioso cliente, às vezes precisa de um pouco de verificação e/ou equilíbrio. Isso é difícil de escrever uma vez que os programadores de computador não são conhecidos por sua natureza franca. É suficiente dizer que, eu tenho trabalhado em muitos projetos onde o cliente foi inflexível e que tudo era prioridade e absolutamente tudo era necessário para ficar pronto. Apesar de não ter dúvida alguma de que era verdade, infelizmente, esses clientes, não tinham o controle sobre o número de horas gastas em um dia. Eles não terminam com um resultado positivo ou desejado, e eu sinto que este resultado poderia ter sido evitado se o cliente confiasse a um Gerente de Projeto a autoridade para avaliar a carga de trabalho e com muito tato, mas firmemente, manter as coisas sob controle. É difícil não levar pro lado pessoal tomada de decisões erradas em um projeto técnico, onde é a sua idéia e seu dinheiro em jogo, sendo que o programador não se importa com tudo isto.

Uma lista incompleta de técnicas para a gestão de um projeto técnico

Se você decidiu ignorar as 1000 palavras anteriores e gerencia por si o projeto, ou se você vai contratar alguém, mas quer ser bem mais informado sobre o processo, a lista a seguir irá ajudá-lo. Eu nunca fui (oficialmente) um gerente de projeto, então eu não posso dizer que ferramentas qualquer gerente de projeto usaria, mas eu tive um bom sucesso com todas essas técnicas:

Milestones

Ao iniciar um novo projeto, a maioria das pessoas intuitivamente sabe que é importante dividir o projeto em pedaços ligeiramente mais gerenciáveis, com cada pedaço variando de algumas semanas a alguns meses de trabalho. No início do projeto, é bom ter uma reunião inicial para estabelecer esses marcos. É normal ser um pouco vago sobre como você vai alcançá-los, o mais importante é manter a verificação após cada marco, de modo a se beneficiar da compreensão melhorada de todos do projeto, e para se certificar de que os marcos do projeto ainda são (aproximadamente) do mesmo tamanho inicialmente considerado.

Tempo Estimado

Nós programadores absolutamente detestamos estimativas porque sabemos que elas estarão 'erradas' e sabemos que elas serão usadas 'contra' nós. É normal que elas sejam assim, pois por definição, elas são baseadas em um punhado de incógnitas. Também é normal que elas sejam usadas 'contra' nós porque nossos trabalhos, de certa forma, são muito confortáveis e não faz mal, de vez em quando, este tipo de pressão.

Então sinta-se livre para pedir estimativas cada vez que o trabalho começa em um novo marco. Você deve esperar uma linha ou duas para cada característica principal junto com uma estimativa aproximada de quanto tempo essa característica tomará. Eu costumo fazer uma estimativa otimista, em seguida, a dobro. Isso garante o tempo extra para as imprevisíveis armadilhas que podem surgir.

Histórias de usuário

As histórias de usuários são breves descrições de uma única peça de funcionalidade dentro do aplicativo. Elas são úteis como um registro de características importantes e deve ser bem medida, capaz de caber em uma ficha e muitas vezes acompanhada por um pouco de desenho. Mais importante ainda, elas servem como uma ponte entre o que o cliente quer e o que o programador tem que fazer. Elas devem ser simples o suficiente para o cliente entender rapidamente, mas detalhadas o suficiente para nós, programadores.

Para algumas informações rápidas sobre as histórias de usuários, eu encontrei estes tutoriais de Mountain Goat Software e Roman Pichler para ser de alta qualidade e sucinta. Para obter mais informações sobre toda a filosofia de "Agile Project Management", experimente esta postagem no blog Toptal The Ultimate Introdução à Agile Project Management por Paul Barnes.

Composiçôes (mock-ups)

Este não é um artigo sobre por que você precisa de um designer, porque eu sinto que a maioria dos clientes já entende isso, mas é preciso repetir porque você verá enormes ganhos de produtividade se você desenhar um projeto concreto, bem claro para seus programadores. Cada vez que temos que tomar uma decisão de design temos que deixar "a zona", e cada vez que temos que voltar e mudar algo, porque não foram fornecidos com o esboço final, bem, você faz a matemática ... Eu não estou reclamando, porque o design é divertido, mas na minha experiência, esta é a fonte No 1 de evitáveis horas extras faturáveis.

A maioria dos designers fornece composições, também conhecidas como comps, no Adobe Photoshop, no Adobe Illustrator ou no Sketch. Se você está fazendo isso sozinho, você pode usar uma das inúmeras ferramentas on-line como Balsamiq ou InVision. O comp não tem que ter as mesmas cores e estilos como o produto acabado (uma vez que estes podem ser facilmente alterados mais tarde), mas por favor, adicione um tempo extra para garantir que todos os elementos da interface do usuário estão presentes e contabilizados.

Reuniões de Stand-Up

Longas reuniões às vezes são inevitáveis, mas você realmente não quer sobrecarregar seus programadores ou ocupar mais do seu tempo do que é necessário. Eu tive clientes que pareciam esperar que eu me lembrasse de tudo o que foi dito durante uma reunião de duas horas e meia; Eles ficaram muito desapontados. Uma reunião stand-up é geralmente limitada a 15 minutos, e é habitual ficar durante toda ela. O aspecto permanente é importante para garantir que todos participem, bem como para manter a reunião curta.

Durante os stand-ups, todos circulam para fornecer um breve relatório de status, mantendo todos os membros da equipe atualizados sobre o progresso de cada um. Você pode encontrar mais sobre stand-ups em ExtremeProgramming.Org. Se você trabalha remotamente e não quer receber todos no Skype todos os dias, você pode tentar uma ferramenta divertida, como 15Five como uma alternativa para stand-ups. 15Five permite que os membros da equipe forneçam sua entrada sempre que for conveniente para eles, e os levará com perguntas do questionário para obter mais respostas em profundidade.

Ticketing System

Enquanto qualquer pessoa pode manter um sistema de notas e/ou Google Docs (com tarefas de todos destacados em cores diferentes), não é realmente necessário; Muitas pessoas têm tentado resolver este problema para você. Basecamp e Trello são famosos por sua facilidade de uso, enquanto Pivotal tenta encapsular toda a filosofia "ágil" em um pacote prático. Seja qual for a sua escolha, um bom sistema de anotações permitirá, no mínimo:

• Criar tarefas
• Atribuir prioridade e data de vencimento
• Link de Tarefas e sub-tarefas
• Atribuir resoluções diferentes, como "concluído" ou "Falha"
• Mostrar todas as tarefas atribuídas a um determinado usuário

Quando um gerente de projeto mostrar-lhe 40 anotações vermelhas e brilhantes como prioridade para o mesmo dia, você vai realmente entender o valor desta visão para o projeto.



Você não tem que usar notas para controlar bugs abertos.

Controle de Versões

Você pode nem mesmo olhar para o código no sistema de controle de versão do seu projeto, mas o controle de origem (ou versão) é uma das ferramentas mais importantes à nossa disposição, o maior sistema de backup imaginável.

A maioria dos projetos modernos usam o Git, embora às vezes você funcione em Subversion (SVN) ao trabalhar em projetos que estiveram ao redor por um período. O Github permite que você hospede repositórios públicos ilimitados gratuitamente (além disso, contém a maioria dos projetos open source do mundo), enquanto o Bitbucket permite hospedar repositórios privados ilimitados e é, portanto, a escolha preferida para projetos comerciais.

Seja qual for o sistema de controle de versão que você escolher, ele armazena nosso código remotamente, caso de alguma aconteça, além de registrar cada vez que "atualizamos" o código, forçando a todos nós a escrever uma pequena mensagem descrevendo o que estávamos fazendo. Isso evita que os desenvolvedores diferentes sobrescrevam o código do outro, ele nos permite ver todas as alterações que foram feitas ao longo de um determinado período de tempo e nos permite criar novas versões de código para armazenar recursos que não serão atualizadas para produção, de imediato. Ele ainda tem um comando chamado "culpa" que mostra quem foi responsável por uma determinada linha de código, e quando ele foi atualizado.

Controle de versão é demais.

Desenvolvimento orientado a testes

Esta é uma prática relativamente cara, o que significa que não é freqüentemente empregado em projetos onde o orçamento é limitado a um par de freelancers. Então você, como um start-up, não deve se sentir muito mal por não fazer isso, mas eu tenho que pendurar a idéia na frente de você, porque ela fornece a defesa final contra bugs. Basicamente, os programadores passam horas preciosas adicionais escrevendo testes (pequenos blocos de código) que garantem que certas partes do aplicativo se comportem de maneiras específicas, previsíveis e repetitivas. Por exemplo, eu poderia escrever um teste afirmando que quando o botão "login" é clicado, um popup abre com um campo de nome de usuário nele.

A beleza dos testes é que uma vez que eu os escrevi, posso executá-los todos com um único comando. Se eu tiver 200 testes escritos, posso executá-los depois de lançar uma nova versão do aplicativo para me certificar de que nenhum bug foi introduzido em qualquer um desses 200 recursos. Não é perfeito, mas é o mais próximo possível de garantia de aplicativos livres de erros (bug-lite, pelo menos).

Em resumo

Isso é tudo que eu sei sobre gerenciamento de projetos. Eu não tenho certeza de quanto isso tudo passaria no Instituto de Gerenciamento de Projetos, mas é tudo o que eu obtive trabalhando em projetos da web ao longo da última década. Claro, eu recomendo que você contrate alguém para obter o benefício de sua experiência, mas espero que você encontre esta informação útil, mesmo se isso não é algo que você é capaz de fazer. Você será a autoridade final neste projeto, assim quanto mais você entender sobre seu funcionamento interno, mais provável será a vitória.

BY ETHAN JAMES - FREELANCE SOFTWARE ENGINEER @ TOPTAL