O mais importante é que os programadores não entendam como se comunicar com o cliente e entre si. Como construir um processo contínuo de desenvolvimento de produtos de qualidade. Como planejar seu dia de trabalho e sprints.
E tudo isso acaba se traduzindo em prazos interrompidos, horas extras, confrontos constantes sobre quem é o culpado e insatisfação do cliente - onde e como tudo está se movendo. Muitas vezes, tudo isso leva a uma mudança nos programadores, ou mesmo em equipes inteiras. Perda de um cliente, deterioração da reputação e assim por diante.
Ao mesmo tempo, acabei de entrar em um projeto desses, onde todos esses encantos estavam.
Ninguém queria assumir a responsabilidade pelo projeto (um grande mercado de serviços), a rotatividade era terrível, o cliente simplesmente se aborrecia e se debatia. O CEO uma vez veio até mim e disse que você tem a experiência necessária, então aqui está o cartão em suas mãos. Pegue o projeto para você. Se você errar, vamos fechar o projeto e expulsar todo mundo. Vai acabar, vai ser legal, então conduza e desenvolva como achar melhor. Como resultado, me tornei um líder de equipe no projeto e tudo caiu sobre meus ombros.
A primeira coisa que fiz foi criar um fluxo de trabalho do zero que correspondeu à minha visão na época e escreveu uma descrição de trabalho para a equipe. Não foi fácil de implementar. Mas em um mês tudo se acalmou, os desenvolvedores e o cliente se acostumaram, e tudo correu de forma silenciosa e confortável. Para mostrar à equipa que não se trata apenas de uma "tempestade no vidro", mas sim de uma verdadeira saída da situação, assumi o máximo de responsabilidades, retirando da equipa a rotina desagradável.
Já se passou um ano e meio e o projeto está se desenvolvendo sem hora extra, sem "corridas de ratos" e todo tipo de estresse. Alguém da antiga equipa não queria trabalhar assim e saiu, alguém, pelo contrário, fez questão de que aparecessem regras transparentes. Mas como resultado, todos que estão na equipe estão muito motivados e conhecem o grande projeto por completo, tanto no front-end quanto no back-end. Incluindo a base de código e toda a lógica de negócios. Chegou até ao ponto em que não somos apenas "remadores", mas também criamos muitos processos de negócios e novas funcionalidades que a empresa achou do seu agrado.
Graças a esta abordagem da nossa parte, o cliente decidiu encomendar outro marketplace à nossa empresa, o que é uma boa notícia.
Já que funciona no meu projeto, talvez também possa ajudar alguém. Então, o próprio processo que nos ajudou a salvar o projeto:
Processo de trabalho em equipe no projeto "Meu projeto favorito"
a) Processo de equipe interna (entre desenvolvedores)
- Todas as tarefas são criadas no sistema Jira
- Cada tarefa deve ser descrita tanto quanto possível e executar estritamente uma ação
- Qualquer recurso, se for complexo o suficiente, é dividido em muitas pequenas trocas
- A equipe trabalha em recursos como uma única tarefa. Primeiro, fazemos todos juntos um recurso, enviamos para teste e, em seguida, pegamos o próximo.
- Cada tarefa é marcada, para o backend ou frontend
- Existem tipos de presas e insetos. Você precisa indicá-los corretamente.
- Depois de concluir a tarefa, ela é transferida para o status de revisão de código (isso cria uma solicitação pull para seu colega)
- Quem concluiu a tarefa controla imediatamente seu tempo para essa tarefa.
- , , , , , .
- , , ( ), , - . —
- ,
- ,
- , , . ,
- : To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- , . , , .
- . , .
- .
- , .
- , , , , .
- , , , , . ( ) . , /.
- ( 12.00)
- , , , . . , . , , .
- , . .
- , , , , .
- . .
- . , , . . , , , .
- , . . .
- , , . .
- Todos os dias, o desenvolvedor tem que escrever no chat do cliente sobre quais tarefas ele trabalhou ontem e em quais tarefas ele trabalhará hoje
- O fluxo de trabalho é baseado em Scrum. Tudo é dividido em sprints. Cada sprint dura duas semanas.
- Sprints criam, preenchem e fecham um líder de equipe.
- Se o projeto tem prazos rígidos, tentamos estimar aproximadamente todas as tarefas. E coletamos um sprint deles. Se o cliente tentar adicionar mais tarefas ao sprint, definimos prioridades e transferimos algumas outras tarefas para o próximo sprint.
b) O processo de trabalho com o cliente
- Cada desenvolvedor pode e deve se comunicar com o cliente
- O cliente não deve impor suas próprias regras de jogo. É necessário de forma educada e amigável deixar claro ao cliente que somos especialistas em nossa área, e somente devemos construir processos de trabalho e envolver o cliente neles
- , , - , - (). . , , , .. , , , , , , .
- /-/ .. /, .
- . , , -, /.
- , . , , . .
- , . . , .
- , , . , . , . , . .
- , , . , . , .
- Se o cliente começa a inventar tarefas diferentes de sua cabeça, começa a fantasiar e explicar nos dedos, então pedimos que ele nos forneça um layout de página e fluxo com lógica que deve descrever completamente o comportamento de todo o layout e seus elementos.
- Antes de iniciarmos qualquer tarefa, devemos nos certificar de que esse recurso foi incluído nos termos de nosso acordo / contrato. Se este é um novo recurso que vai além de nossos acordos iniciais, então devemos definitivamente avaliar esse recurso ((prazo de entrega estimado + 30%) x 2) e indicar ao cliente que isso nos levará muito tempo, mais o prazo é alterado por duas vezes a estimativa. Vamos tornar a tarefa mais rápida - ótimo, todos se beneficiarão com isso. Caso contrário, estamos segurados.
c) O que não aceitamos na equipe:
- Opcionalidade, falta de montagem, esquecimento
- „ “. , , , .
- , . , , :)
- . , , . , , — . -, .
- .
- ! - - , .
E uma série de outras perguntas / teses que às vezes pergunto ao meu cliente para remover todos os mal-entendidos:
- Quais são seus critérios de qualidade?
- Como você determina se um projeto tem um problema ou não?
- Violando todas as nossas recomendações e conselhos sobre como alterar / melhorar o sistema, todos os riscos são suportados apenas por você
- Quaisquer mudanças importantes no projeto (por exemplo, todos os tipos de fluxos extras) levarão ao possível aparecimento de bugs (que iremos, é claro, corrigir)
- É impossível por alguns minutos entender que tipo de problema ocorreu no projeto e, mais ainda, corrigi-lo imediatamente
- Trabalhamos em um produto de fluxo específico (Tarefas em Fat - Desenvolvimento - Teste - Implantar). Isso significa que não podemos responder a todo o fluxo de solicitações e reclamações no chat
- Os programadores são apenas programadores, não testadores profissionais, e não podem garantir a qualidade adequada dos testes do projeto
- , , ( )
- ( ), ,
- — ,
- , , , ,
- , , , ,
- .
- , ( ),
Como regra, o cliente percebe imediatamente que nem tudo é tão simples no desenvolvimento de software e que o desejo sozinho claramente não é suficiente.
Em geral, isso é tudo. Deixo nos bastidores muitas negociações e a depuração inicial de todos os processos, mas como resultado tudo deu certo. Posso dizer que esse processo se tornou uma espécie de “bala de prata” para nós. As novas pessoas que vieram ao projeto puderam se acostumar imediatamente com o trabalho desde o primeiro dia, já que todos os processos são descritos, e a documentação e arquitetura em forma de diagramas imediatamente deram uma ideia do que todos estávamos fazendo aqui.
PS Gostaria de esclarecer que não há nenhum gerente de projeto do nosso lado. Está do lado do cliente. Nem um pouco técnico. O projeto é europeu. Todas as comunicações são feitas apenas em inglês.
Boa sorte a todos nos projetos. Não se queime e tente melhorar seus processos.
A fonte está no meu blog .