Este artigo é para você, um corajoso empresário com uma ideia para um aplicativo no coração e um pouco de dinheiro no banco. Os diagramas que você rabiscou em guardanapos vão perturbar o mundo inteiro, e caminhões cheios de dinheiro já foram enviados para sua casa. Para garantir que eles cheguem no prazo, aqui estão algumas dicas simples para fazer sua produção funcionar sem problemas.
O motivo pelo qual você precisa de um gerente de projeto
'Os programas de computador são as coisas mais complexas que os seres humanos criam', diz Douglas Crockford. Você pode não ter ouvido esse nome antes, mas para um programador, ele é bastante famoso. Atualmente, ele é arquiteto de software sênior no PayPal e foi o pioneiro em todos os tipos de tecnologia de ponta que estão além do escopo deste artigo. Ele é alguém que tem muito conhecimento sobre como trabalhar em grandes projetos.
Quanto a mim, estou programando há 13 anos e ainda há momentos em que cada projeto me leva para um território desconhecido. Existem tantas tecnologias diferentes, bem como novas técnicas sendo desenvolvidas em um ritmo tão alarmante, que nunca sinto que estou totalmente ciente do que está acontecendo. Embora cada projeto tenha seus desafios únicos, existem algumas constantes:
- O projeto sofre a pressão do tempo.
- O orçamento é menor do que eu gostaria.
- Minhas taxas são mais caras do que o cliente deseja.
- Não estou ouvindo tão perfeitamente quanto o cliente deseja.
- O cliente não explica as coisas tão perfeitamente como eu gostaria.
Obviamente, precisamos de uma babá. Alguém precisa intervir para definir as regras do jogo, manter todos honestos e garantir que não vamos esquecer algo importante. Alguém deve facilitar a comunicação entre todas as partes.
Essa pessoa, esse herói, é o gerente de projeto.
Por que o gerente de produto está em uma caixa? Ele é um gato. Os gatos adoram caixas.
O ApeeScape não ofereceu contratos com gerentes de projeto quando comecei a escrever este artigo, mas agora eles oferecem ( Projetos ApeeScape ) Sinergia! Só posso imaginar o poder que a leitura das dicas a seguir trouxe e perceber que estava perdendo uma grande oportunidade.
A razão pela qual um programador não é um bom gerente de projeto
Deixando de lado a Certificação por Instituto de Gerenciamento de Projetos 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 do que qualquer pessoa em projetos técnicos e nossas mentes analíticas são adeptas da catalogação de informações e do estabelecimento de metas concretas.
vazou números de cartão de crédito com dinheiro
Você está claramente nos pagando o suficiente, então é razoável esperar que possamos gerenciar diferentes tarefas nós mesmos, 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 estupor de programação para tomar decisões sobre o que priorizar ou para discutir quanto trabalho realmente será feito nesta semana, o código para de escrever. Depois disso, leva pelo menos 10 minutos para voltar 'à zona', especialmente se estamos estressados com a conversa que acabamos de ter, o que é provável, especialmente se estivermos discutindo sobre a prioridade das funções. Não é grande coisa, eu sei, mas tudo isso é feito para fazer um uso mais eficiente de recursos caros.
Mais importante ainda, focar nos detalhes não permite que você aprecie o ambiente geral. Se este artigo não deixar nada para você, tente entender o seguinte: quando passo o dia todo olhando para alguns insetos específicos, meu cérebro perde de vista a imagem maior.
Meu cérebro me recompensa quando eu conserto esses bugs, e acho que fiz grandes coisas e agora posso ir jogar videogame. Quando alguém me lembra que a página inicial ainda não funciona, é uma surpresa completa porque passei o dia inteiro enchendo meu cérebro com um conhecimento muito detalhado de uma pequena parte de todo o projeto, e me esqueço do descansar. É assim que meu cérebro funciona, e muitos outros programadores têm uma constituição psicológica semelhante.
Quando saímos de nosso estupor de programação para tomar decisões, o código para de ser escrito.
A razão pela qual o cliente não é um bom gerente de projeto
Bem, se nós, programadores, não queremos assumir a responsabilidade por fazer coisas de gerenciamento de projetos, então a responsabilidade permanece com você, o cliente. É o seu dinheiro. É a sua visão. Enfim, você é o responsável por tudo isso.
No entanto, você também tem muito o que fazer.
Muitos clientes são meros mortais com empregos diurnos, como todos nós, e alguns até sofrem de procrastinação ou esquecimento. Embora isso certamente não descreva você, considere a ideia de ter um Lembrete Profissional (Lembrete profissional) por perto, para que você possa voltar ao importante trabalho de manter o projeto vivo.
Se você trabalhou ou supervisionou um projeto técnico de escopo semelhante, pode ser um bom gerente para seu projeto. Do contrário, 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 apenas em meio período), alguém que sabe quais partes do processo precisam, ou podem precisar, de mais atenção.
Faça controle de qualidade, por exemplo. O controle de qualidade adequado é essencial para obter o que deseja de qualquer projeto, e isso nunca recebe a atenção que merece. Um bom Gerente de Projetos aproveitará ao máximo os recursos limitados de um controle de qualidade e também garantirá a qualidade de seus programadores para sua segurança. Às vezes, saímos do nosso fundo e às vezes cometemos erros. É necessária uma pessoa tecnicamente competente em uma função de supervisão para determinar se o seu programador está tendo um dia ruim ou se ele ou ela é, de fato, uma adição ruim ao projeto. Resolver problemas de pessoal desde o início pode fazer a diferença entre a vida ou a morte do seu projeto.
Por último, até você, ó cliente glorioso, às vezes precisa de um pouco de verificação e / ou equilíbrio. Isso é difícil para mim escrever, pois nós, programadores, não somos muito conhecidos por nossa franqueza ao falar. Basta dizer que já trabalhei em muitos projetos onde o cliente estava convencido de que tudo era prioridade e absolutamente tudo precisava ser alcançado. Embora eu não tenha dúvidas de que isso seja 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 dado a um Gerente de Projeto autoridade para avaliar a carga de trabalho e manter as coisas sob controle com tato, mas com firmeza. É difícil tomar as decisões infelizes de autojulgamento 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 chorarmos e gritarmos com ele. (Eu sei que isso é verdade porque tentei muitas vezes.)
Uma lista incompleta de técnicas para gerenciar um projeto técnico
Se você decidiu ignorar as mais de 1.000 palavras acima e deseja gerenciar seu projeto sozinho, ou se está contratando alguém, mas deseja obter mais informações 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:
uma das maneiras mais eficazes e fáceis de uma empresa mudar sua imagem é:
Milestones
Ao iniciar um novo projeto, a maioria das pessoas sabe intuitivamente que é importante dividir o projeto em partes um pouco mais gerenciáveis, cada parte pode variar de algumas semanas a alguns meses em termos de trabalho. No início do projeto, é bom fazer uma reunião inicial para estabelecer esses marcos ou pontos específicos. Tudo bem ser um pouco vago sobre como você vai chegar lá, o mais importante é monitorar após cada etapa, para se beneficiar da melhor compreensão de todos sobre o projeto e para ter certeza de que as etapas do projeto do projeto ainda estão (mais ou menos) do mesmo tamanho que inicialmente se acreditava.
Estimativas de tempo
Nós, programadores, odiamos estimativas, porque sabemos que elas darão errado e serão usadas contra nós. Tudo bem que eles estejam errados, pois, por definição, são baseados em um punhado de enigmas. Também é bom que sejam usados contra nós, porque o nosso trabalho é bastante confortável e não faz mal sentir um pouco de pressão de vez em quando.
Portanto, não hesite em pedir orçamentos cada vez que se inicie o trabalho de uma nova etapa. Você deve esperar uma explicação de uma ou duas linhas para cada recurso importante, junto com uma estimativa aproximada de quanto tempo esse recurso levará. Normalmente faço uma estimativa otimista e depois o dobro. Muitas vezes, esse tempo extra é gasto em obstáculos invisíveis.
Histórias de usuários
As histórias do usuário são descrições curtas de uma única funcionalidade do aplicativo. Eles são úteis como um registro de características importantes e devem ser reduzidos, capazes de caber em um cartão e frequentemente acompanhados por um pequeno desenho. Mais importante ainda, eles servem como uma ponte entre o que o cliente deseja e o que o programador tem a dizer ao computador. As histórias são simples o suficiente para que você, o cliente, possa entender em alguns minutos, mas detalhadas o suficiente para que nós, os programadores, possamos obter o máximo delas.
Para obter algumas informações rápidas sobre histórias de usuário, encontrei estes tutoriais de Software Mountain Goat Y Roman Pichler , são de alta qualidade e concisos. Para obter mais informações sobre toda a filosofia de “Gerenciamento Ágil de Projetos”, tente esta postagem do blog do ApeeScape A introdução definitiva ao gerenciamento ágil de projetos 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 vale a pena repetir porque você verá enormes ganhos de produtividade se mostrar aos seus programadores um design bem planejado e concreto. 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 algo, porque o rascunho final não foi fornecido para nós, bem, leve em conta ... Não estou reclamando, porque design é divertido, mas, na minha experiência, essa é a fonte número 1 de horas extras faturáveis evitá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 . O comp não precisa ter as mesmas cores e estilos do produto acabado (pois eles podem ser facilmente alterados posteriormente), mas reserve um tempo extra para garantir que todos os elementos da IU estejam presentes e verificados.
Reuniões Stand-Up
Reuniões longas às vezes são inevitáveis, mas não sobrecarregue seus programadores ou demore mais 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 stand-up é geralmente limitada a 15 minutos e é comum ficar de pé durante ela. Ficar em pé deve garantir a participação de todos, bem como manter a reunião curta.
Durante os stand-ups, todos se movem em um círculo para fornecer um breve relatório de status, mantendo todos os membros da equipe atualizados sobre o progresso uns dos outros. Você pode encontrar mais informações sobre o suporte UPS em ExtremeProgramming.Org . Se todos trabalham remotamente e você não quer se encontrar no Skype todos os dias, você pode usar uma ferramenta divertida como 15Five , como uma alternativa aos stand-ups. O 15Five permite que os membros da equipe forneçam feedback sempre que for conveniente para eles e fará perguntas da pesquisa para gerar respostas mais detalhadas.
Sistema de bilhetagem
Embora qualquer pessoa possa manter um sistema de notas adesivas e Google Docs (com tarefas para cada um destacadas em cores diferentes), não é realmente necessário. Muitas pessoas tentaram resolver esse problema para você. Basecamp e Trello são famosos por sua facilidade de uso, enquanto o Pivotal tenta encapsular toda a filosofia “ágil” em um pacote muito sofisticado. Seja qual for a sua escolha, um bom sistema de bilhetes permitirá a você, no mínimo:
- Crie tarefas
- Atribuir prioridade e data de entrega
- Vincular tarefas e subtarefas
- Atribuir resoluções diferentes, como 'concluído' ou 'falha no teste'
- Mostrar todas as tarefas atribuídas a um determinado usuário
Quando um gerente de projeto mostra 40 tickets vermelhos brilhantes de maior prioridade com vencimento no mesmo dia, você realmente entende o valor dessa visão do projeto.
Controle de versão
Você pode nem mesmo conseguir olhar o código no sistema de controle de versão do seu projeto, mas o controle de versão (ou controle de versão) é uma das ferramentas mais importantes que temos, o maior sistema de backup imaginável.
princípios de definições e exemplos de design
A maioria dos projetos modernos usa Git, embora você às vezes encontre o Subversion (SVN) ao trabalhar em projetos que já estão disponíveis ao público há algum tempo. Github permite hospedar um número ilimitado de repositórios públicos gratuitamente (além disso, contém a maioria dos projetos de código aberto do mundo), enquanto 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, bem como um acompanhamento toda vez que 'comprometemos' o código, ao mesmo tempo que nos obriga a escrever uma pequena mensagem que descreve o que nós estavam trabalhando. Isso evita que diferentes desenvolvedores sobrescrevam o código uns dos outros, nos permite ver todas as mudanças que foram feitas durante um determinado período de tempo e nos permite criar novos ramos de código para armazenar recursos que não entrarão em operação imediatamente. Ele ainda tem um comando chamado 'falha' que mostra quem foi o responsável por uma determinada linha de código e quando ela foi confirmada.
O controle de versão é o melhor.
Desenvolvimento baseado em teste
Esta é uma prática relativamente cara, o que significa que não é usada com freqüência em projetos onde o orçamento é limitado a alguns freelancers. Portanto, para começar, você não deve se sentir mal por não fazer isso, mas tenho que apresentar a ideia, pois ela oferece a melhor defesa contra bugs. Basicamente, seus programadores gastam preciosas horas adicionais escrevendo testes (pequenos blocos de código) para garantir que certas partes do aplicativo se comportem de uma maneira específica, previsível e repetível. Por exemplo, você pode escrever um teste garantindo que, quando o botão 'login' for clicado, uma janela pop-up seja aberta com um campo de nome de usuário.
A beleza dos testes é que, depois de escrevê-los, 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 ter certeza de que nenhum bug foi introduzido em qualquer um dos 200 recursos. Não é perfeito, mas é o mais próximo que podemos chegar de garantir aplicativos livres de bugs (bug-lite, pelo menos).
Para fechar
Isso é tudo que sei sobre gerenciamento de projetos. Não tenho certeza de quanto disso o exame do Project Management Institute passaria, mas é todo o material que coletei 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 esta informação seja útil, mesmo que não seja algo que você tenha a oportunidade de fazer. Você será a autoridade máxima neste projeto; portanto, quanto mais souber sobre seu funcionamento interno, maior será a probabilidade de levá-lo à vitória.
