Você precisa de um herói: o gerente de projeto

Este artigo é para você, o empreendedor corajoso com uma ideia de aplicativo em seu coração e um pouco de dinheiro no banco. Os diagramas que você rabiscou em guardanapos de coquetel vão atrapalhar o mundo inteiro, e caminhões basculantes cheios de dinheiro já foram despachados para sua casa. Para garantir que eles cheguem a tempo, aqui estão alguns conselhos simples para fazer seu ciclo de produção funcionar sem problemas.

Por que você precisa de um gerente de projeto em primeiro lugar

“Os programas de computador são as coisas mais complexas que os humanos fazem”, diz Douglas Crockford. Você pode não ter ouvido esse nome antes, mas ele é bastante famoso por ser um programador. Ele é atualmente um arquiteto de software sênior no PayPal e foi pioneiro em 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, programo há 13 anos, e mesmo agora, em algum momento, todo projeto me leva a um território desconhecido. Existem tantas tecnologias diferentes por aí, e novas técnicas estão sendo desenvolvidas em um ritmo tão alarmante que eu nunca sinto que estou completamente por dentro do que está acontecendo. Embora cada projeto tenha seus desafios únicos, existem algumas constantes:

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

Claramente, precisamos de uma babá. Alguém tem que intervir para estabelecer as regras básicas, manter todos honestos e garantir 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 de projeto.

A Toptal não oferecia contratos com gerentes de projeto quando comecei a escrever este artigo, mas eles oferecem agora. Sinergia! Eu só posso imaginar que os poderes que leram os conselhos a seguir e perceberam que estavam perdendo uma grande oportunidade.

Por que um programador não é um bom gerente de projeto

Além da 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 seriam gerentes de projeto bastante decentes; temos mais experiência com projetos técnicos do que qualquer outra pessoa e nossas mentes analíticas são hábeis em catalogar informações e estabelecer metas concretas.

Deus sabe, você está nos pagando o suficiente, então parece razoável esperar que possamos 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 nosso torpor de programação para tomar decisões sobre o que priorizar, ou para discutir sobre o quanto realmente será feito esta semana, o código não está sendo escrito. Em seguida, leva pelo menos 10 minutos para voltar à “zona”, especialmente se estivermos estressados ​​com a conversa que acabamos de ter, o que é provável se estivermos discutindo a prioridade dos recursos. Boo hoo, eu sei, mas trata-se de fazer o uso mais eficiente de recursos caros.

Mais importante, nós realmente não podemos ver a floresta para as árvores. Se você não tirar mais nada deste artigo, por favor, entenda o seguinte: quando passo o dia todo olhando para alguns bugs específicos, meu cérebro perde a noção do quadro geral.

Meu cérebro me recompensa quando corrijo esses bugs, e presumo que fiz grandes coisas e posso jogar videogame agora. Quando alguém me lembra que a página inicial ainda está quebrada, é uma surpresa completa porque passei o dia enchendo meu cérebro com um conhecimento muito detalhado de uma parte muito pequena do projeto geral e meio que esqueci o resto. É assim que meu cérebro funciona, e muitos outros programadores têm uma estrutura psicológica semelhante.

Por que um cliente não é um bom gerente de projeto

Bem, então, se nós programadores não quisermos assumir a responsabilidade de fazer as coisas do gerenciamento de projetos, então isso deve recair sobre você, o cliente. É o seu dinheiro. É a sua visão. Você é responsável por tudo, de qualquer maneira.

Você, no entanto, também tem muito no seu prato.

Muitos clientes são meros mortais com empregos diários como o resto de nós, e alguns são conhecidos por sofrer de procrastinação ou esquecimento. Embora isso não necessariamente descreva você, especificamente, por favor, considere a ideia de ter um Profissional de Recordação por perto para que você possa voltar ao importante trabalho de manter todo o projeto vivo.

Se você trabalhou ou supervisionou um projeto técnico de escopo semelhante, pode realmente ser um bom gerente para o seu projeto. Se você não tiver, por favor, não subestime o valor de alguém que pode prever os problemas que podem surgir. As estimativas de tempo são sempre apenas estimativas, e os bugs tendem a aparecer nos momentos menos oportunos. Vale a pena o custo de outro funcionário (mesmo que seja apenas meio período) ter alguém por perto que saiba quais partes do processo precisam, ou provavelmente precisarão, de mais atenção.

Veja a garantia de qualidade (QA), por exemplo. O controle de qualidade adequado é essencial para obter o que você deseja de qualquer projeto e nunca recebe a atenção que merece. Um bom gerente de projeto aproveitará ao máximo os recursos limitados de controle de qualidade e também garantirá a qualidade de seus programadores para você. Às vezes, saímos de nossa profundidade e às vezes cometemos erros. Você precisa de uma pessoa tecnicamente proficiente em uma função de supervisão para determinar se seu programador está apenas tendo um dia de folga ou se ele ou ela é, de fato, um ajuste ruim para o projeto. Acabar com os problemas de pessoal cedo pode significar a diferença entre a vida e a morte do seu projeto.

Por fim, até você, cliente, às vezes precisa de um pouco de verificação e/ou equilíbrio. Isso é difícil para mim escrever, já que nós, programadores de computador, não somos bem conhecidos por nossas naturezas francas. Basta dizer que trabalhei em muitos projetos em que o cliente estava convencido de que tudo era prioridade máxima e absolutamente tudo precisava ser feito. Embora eu não tenha dúvidas de que isso era absolutamente verdade, esses clientes, infelizmente, não tinham controle sobre o número de horas em um dia. Eles não obtiveram o resultado positivo que desejavam e/ou mereciam, e acho que esse resultado poderia ter sido evitado se o cliente tivesse confiado a um gerente de projeto a autoridade para avaliar a carga de trabalho e, com tato, mas com firmeza, manter as coisas sob controle . É difícil fazer os julgamentos desapaixonados que a maioria dos projetos técnicos exige quando é sua ideia e seu dinheiro em jogo e o computador não se importa se você ou eu choramos e gritamos com ele. (Eu sei que isso é verdade porque eu tentei muitas vezes.)

Uma lista incompleta de técnicas para gerenciar um projeto técnico

Se você decidiu ignorar as 1.000 palavras anteriores e gerenciar seu projeto sozinho, ou se vai contratar alguém, mas quer ter mais conhecimento sobre o processo, esta lista o ajudará. Eu nunca fui (oficialmente) um gerente de projeto, então não posso dizer quais ferramentas qualquer gerente de projeto usaria, mas tive um bom sucesso com todas essas técnicas:

Milestones

Ao iniciar um novo projeto, a maioria das pessoas sabe intuitivamente que é importante dividir o projeto em partes um pouco mais gerenciáveis, com cada parte variando de algumas semanas a alguns meses de trabalho. No início do projeto, é bom ter uma reunião inicial para estabelecer esses marcos. Não há problema em ser um pouco vago sobre como você os alcançará, o mais importante é continuar verificando após cada marco para se beneficiar da compreensão aprimorada de todos sobre o projeto e para garantir que os marcos do projeto ainda sejam ( aproximadamente) do mesmo tamanho que inicialmente se acreditava.

Estimativas de tempo

Nós programadores detestamos absolutamente as estimativas porque sabemos que estarão erradas e sabemos que serão usadas contra nós. Tudo bem que eles estejam errados porque, por definição, eles são baseados em um punhado de incógnitas. Também está tudo bem que eles sejam usados ​​contra nós porque nossos trabalhos são bem confortáveis ​​e não faz mal ter o chicote estalado de vez em quando.

Portanto, sinta-se à vontade para solicitar estimativas toda vez que o trabalho começar em um novo marco. Você deve esperar uma ou duas linhas para cada recurso principal, juntamente com uma estimativa aproximada de quanto tempo esse recurso levará. Costumo fazer uma estimativa otimista e depois duplicá-la. Na maioria das vezes, esse tempo extra é responsável por armadilhas invisíveis.

Histórias de usuário

As histórias de usuários são breves descrições de uma única funcionalidade dentro do aplicativo. Eles são úteis como um registro de características importantes e devem ser pequenos, capazes de caber em um cartão de índice e muitas vezes acompanhados de um pequeno desenho. Mais importante, eles servem como uma ponte entre o que o cliente deseja e o que o programador tem a dizer ao computador. Eles são simples o suficiente para você, o cliente, nocautear em alguns minutos, mas detalhados o suficiente para nós, os programadores, afundarmos nossos dentes.

Para algumas informações rápidas sobre histórias de usuários, achei esses tutoriais da Mountain Goat Software e Roman Pichler de alta qualidade e sucintos. Para obter mais informações sobre toda a filosofia do gerenciamento ágil de projetos, experimente esta postagem do blog Toptal The Ultimate Introduction to Agile Project Management, de Paul Barnes.

Composições (Mockups)

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 vale a pena repetir porque você verá enormes ganhos de produtividade se colocar um design concreto e bem pensado na frente de seus programadores. Toda vez que temos que tomar uma decisão de design, temos que sair da “zona”, e toda vez que temos que voltar e mudar alguma coisa porque não recebemos o rascunho final, bem, você faz as contas... eu' Não estou reclamando, porque o design é divertido, mas, na minha experiência, essa é a fonte número 1 de horas extras evitáveis ​​e faturáveis.

A maioria dos designers fornece composições, também conhecidas como composições, no Adobe Photoshop, Adobe Illustrator ou Sketch. Se você está fazendo isso sozinho, pode usar uma das inúmeras ferramentas online, como Balsamiq ou InVision. A composição não precisa ter as mesmas cores e estilos do produto final (já que eles podem ser facilmente alterados posteriormente), mas reserve um tempo extra para garantir que todos os elementos da interface do usuário estejam presentes e contabilizados.

Reuniões em pé

Às vezes, reuniões longas são inevitáveis, mas você realmente não quer sobrecarregar seus programadores ou ocupar mais tempo do que o necessário. 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 em pé geralmente é limitada a 15 minutos, e é costume ficar em pé durante a duração. O aspecto permanente deve garantir que todos participem, bem como manter a reunião curta.

Durante as reuniões, todos circulam em círculo 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 todos vocês trabalham remotamente e não querem que todos usem o Skype todos os dias, você pode experimentar uma ferramenta divertida como o 15Five como alternativa aos stand-ups. O 15Five permite que os membros da equipe forneçam sua opinião sempre que for conveniente para eles, e os solicitará com perguntas de pesquisa para obter respostas mais detalhadas.

Sistema de Bilheteira

Embora qualquer pessoa possa manter um sistema de notas adesivas e Google Docs (com as tarefas de todos destacadas em cores diferentes), isso não é realmente necessário; muitas pessoas tentaram resolver esse problema para você. O Basecamp e o Trello são famosos por sua facilidade de uso, enquanto o Pivotal tenta encapsular toda a filosofia “ágil” em um pacote muito elegante. Seja qual for a sua escolha, um bom sistema de bilhética permitirá, no mínimo:

• Criar tarefas
• Atribuir prioridade e data de vencimento
• Vincular tarefas e subtarefas
• Atribua resoluções diferentes, como "concluído" ou "teste com falha"
• Mostrar todas as tarefas atribuídas a um determinado usuário

Quando um gerente de projeto lhe mostra 40 tíquetes de alta prioridade em vermelho brilhante, todos com vencimento no mesmo dia, você realmente entenderá o valor dessa visão panorâmica do projeto.

Fonte de controle

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

A maioria dos projetos modernos usa o Git, embora às vezes você encontre o Subversion (SVN) ao trabalhar em projetos que já existem há algum tempo. O Github permite hospedar repositórios públicos ilimitados gratuitamente (além disso, contém a maioria dos projetos de código aberto do mundo), enquanto o Bitbucket permite hospedar repositórios privados ilimitados e, portanto, é a escolha preferida para projetos comerciais.

Qualquer que seja o sistema de controle de versão que você escolher, ele armazena nosso código remotamente caso algo aconteça, além de rastrear cada vez que “comitamos” código para ele enquanto nos força a escrever uma pequena mensagem descrevendo no que estávamos trabalhando. Isso impede que desenvolvedores diferentes sobrescrevam o código uns dos outros, nos permite ver todas as alterações que foram feitas em um determinado período de tempo e nos permite criar novas ramificações de código para armazenar recursos que não serão lançados imediatamente. Ele ainda tem um comando chamado “culpa” que mostra quem foi responsável por uma determinada linha de código e quando ela foi confirmada.

O controle de origem é o maior.

Desenvolvimento orientado a testes

Esta é uma prática relativamente cara, o que significa que não é frequentemente empregada em projetos onde o orçamento é limitado a alguns freelancers. Então você, como um empreendedor de startups, não deveria se sentir mal por não fazer isso, mas eu devo colocar a ideia na sua frente porque ela fornece a melhor defesa contra bugs. Basicamente, seus programadores gastam horas preciosas adicionais escrevendo testes (pequenos blocos de código) que garantem que certas partes do aplicativo se comportem de maneira específica, previsível e repetível. Por exemplo, eu poderia escrever um teste afirmando que quando o botão “login” é clicado, um pop-up abre com um campo de nome de usuário nele.

A beleza dos testes é que, depois de escrevê-los, posso executá-los com um único comando. Se eu tiver 200 testes escritos, posso executá-los depois de lançar uma nova versão do aplicativo para garantir que nenhum bug tenha sido introduzido em nenhum desses 200 recursos. Não é perfeito, mas é o mais próximo que podemos chegar de garantir aplicativos livres de bugs (pelo menos bug-lite).

Embrulhar

Isso é tudo o que sei sobre gerenciamento de projetos. Não tenho certeza de quanto disso passaria pelo Project Management Institute, mas são coisas que aprendi 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ê ache essas informações úteis, mesmo que isso não seja algo que você possa fazer. Você será a autoridade máxima neste projeto, então quanto mais você entender sobre seu funcionamento interno, maior a probabilidade de conduzi-lo à vitória.