Olá amigos. Frequentemente, especialmente em terceirização, vejo a mesma imagem. A falta de um processo de trabalho claro nas equipes em vários projetos.
O mais importante é que os programadores não entendem como se comunicar com o cliente e uns com os outros. Como construir um processo contínuo de desenvolvimento de um produto de qualidade. Como planejar seu dia de trabalho e os sprints.
E tudo isso acaba resultando em prazos perdidos, horas extras, constantes discussões sobre quem é o culpado e descontentamento dos clientes — por onde e como tudo está se movendo. Isso muitas vezes leva à troca de programadores, e até mesmo de equipes inteiras. À perda de clientes, deterioração da reputação e assim por diante.
Na minha época, eu acabei caindo em um projeto assim, onde havia todas essas belezas.
Ninguém queria assumir a responsabilidade pelo projeto (um grande marketplace de serviços), a rotatividade era terrível, o cliente simplesmente estava descontrolado. O CEO se aproximou de mim e disse que eu tinha a experiência necessária, então aqui estão as cartas na mão. Pegue o projeto. Se você falhar, vamos fechar o projeto e demitir todos. Se der certo, será ótimo, então administre-o e desenvolva-o como achar melhor. No final, me tornei o líder da equipe no projeto e tudo ficou sobre meus ombros.
A primeira coisa que fiz foi desenvolver um processo de trabalho do zero, que correspondesse à minha visão na época, e escrevi uma descrição de cargos para a equipe. Implementá-lo não foi fácil. Mas, em cerca de um mês, tudo se estabilizou, os desenvolvedores e o cliente se acostumaram, e tudo começou a fluir de maneira tranquila e confortável. Para mostrar à equipe que isso não era apenas uma "tempestade em um copo d'água", mas uma saída real da situação, assumi o máximo de responsabilidades, aliviando a rotina desagradável da equipe.
Já se passaram um ano e meio, e o projeto está se desenvolvendo sem horas extras, sem "corridas de ratos" e sem todo tipo de estresse. Alguns na equipe antiga não quiseram trabalhar assim e saíram, enquanto outros, ao contrário, realmente gostaram das regras transparentes que surgiram. Mas, no final, todos os que estão na equipe estão bastante motivados e conhecem o projeto enorme completamente, incluindo tanto o front-end quanto o back-end. Incluindo a base de código e toda a lógica de negócios. Chegamos ao ponto de que não somos apenas "remadores", mas nós mesmos criamos muitos processos de negócios e novas funcionalidades que agradaram ao negócio.
Graças a essa abordagem da nossa parte, o cliente decidiu encomendar mais um marketplace da nossa empresa, o que é muito gratificante.
Como isso está funcionando no meu projeto, pode ser que ajude alguém também. Então, o próprio processo que nos ajudou a salvar o projeto:
O processo de trabalho da equipe no projeto "Meu projeto favorito"
a) Processo interno da equipe (entre os desenvolvedores)
- Todas as tarefas são criadas no sistema Jira
- Cada tarefa deve ser descrita da forma mais detalhada possível e executar estritamente uma única ação
- Qualquer feature, se for suficientemente complexa, é dividida em várias tarefas menores
- A equipe trabalha nas features como uma única tarefa. Primeiramente, fazemos tudo juntos como uma feature, entregamos para teste e depois pegamos a próxima.
- Cada tarefa é marcada, se é para o backend ou frontend
- Há tipos de tarefas e bugs. É necessário indicá-los corretamente.
- Após a conclusão da tarefa, ela é transferida para o status de revisão de código (nesse momento, um pull request é criado para um colega)
- A pessoa que executou a tarefa imediatamente rastreia seu tempo para essa tarefa
- Após a verificação do código, o PR é aprovado e, depois disso, quem executou essa tarefa merge-a na branch master, em seguida, altera seu status para pronta para deploy no dev servidor.
- Todas as tarefas prontas para deploy no servidor de dev são implantadas pelo team lead (sua zona de responsabilidade), às vezes por um membro da equipe, se algo for urgente. Após o deploy, todas as tarefas com status de prontas para deploy no dev são transferidas para o status - pronta para teste no dev
- Todas as tarefas são testadas pelo cliente
- Quando o cliente testou a tarefa no dev, ele a transfere para o status pronta para deploy no prod
- Para o deploy no prod, temos uma branch separada, na qual fazemos o merge da master apenas antes do deploy
- Se durante os testes o cliente encontrar bugs, ele retorna a tarefa para ajustes, definindo seu status como retornada para ajustes. Assim, separamos novas tarefas daquelas que não passaram pelos testes
- No final, todas as tarefas passam pelo caminho desde a criação até a conclusão: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- Cada desenvolvedor testa seu próprio código de forma independente, incluindo como usuário do site. Não é permitido o merge da branch com a principal se não estiver absolutamente certo de que o código funciona.
- Cada tarefa tem suas prioridades. As prioridades são definidas pelo cliente ou pelo líder da equipe.
- Os desenvolvedores priorizam as tarefas mais importantes antes de tudo.
- Os desenvolvedores podem atribuir tarefas uns aos outros se forem encontrados diferentes bugs no sistema ou se uma tarefa envolver o trabalho de vários especialistas.
- Todas as tarefas criadas pelo cliente vão para o líder da equipe, que as avalia e pede ao cliente para fazer ajustes ou atribui uma delas a um dos membros da equipe.
- Todas as tarefas que estão prontas para serem implantadas na dev ou produção também vão para o líder da equipe, que decide quando e como realizar a implantação. Após cada implantação, o líder (ou um membro da equipe) deve informar ao cliente sobre isso, além de mudar os status das tarefas para 'prontas para teste' na dev/prod.
- Todos os dias, no mesmo horário (para nós, às 12h00), realizamos uma reunião entre todos os membros da equipe.
- Durante a reunião, cada um relata, incluindo o líder, o que fez ontem, o que planeja fazer hoje e o que não está funcionando e por quê. Assim, toda a equipe fica ciente do que cada um está fazendo e em que estágio está o projeto. Isso nos dá a oportunidade de prever e corrigir, se necessário, nossas estimativas e prazos.
- Na reunião, o líder também informa sobre todas as mudanças no projeto e sobre o nível atual de bugs que foram encontrados não pelo cliente. Todos os bugs são discutidos e atribuídos a cada membro da equipe para resolução.
- Na reunião, o líder atribui tarefas a cada um, levando em consideração a carga atual dos desenvolvedores, seu nível de preparo profissional e a associação das tarefas com o trabalho atual de cada desenvolvedor.
- Na reunião, o líder desenvolve uma estratégia geral sobre arquitetura e lógica de negócios. Em seguida, toda a equipe discute e decide se aceita ou faz correções nessa estratégia.
- Cada desenvolvedor escreve código e constrói algoritmos de forma independente dentro de uma arquitetura unificada e lógica de negócios. Cada um pode expressar sua visão de implementação, mas ninguém é forçado a fazer apenas de uma maneira específica. Cada decisão é argumentada. Se há uma solução melhor, mas atualmente não há tempo para implementá-la, uma tarefa é criada no JIRA para um futuro refatoramento de uma parte específica do código.
- Quando o desenvolvedor assume uma tarefa, ele a altera para o status de desenvolvimento. Toda a comunicação sobre o esclarecimento da tarefa com o cliente recai sobre o desenvolvedor. Questões de natureza técnica podem ser direcionadas ao líder da equipe ou a colegas.
- Se o desenvolvedor não entender a essência da tarefa e o cliente não conseguir explicá-la de forma clara, então ele passa para a próxima tarefa. A atual é assumida pelo líder da equipe que a discute com o cliente.
- Todos os dias, o desenvolvedor deve escrever no chat do cliente sobre as tarefas em que trabalhou ontem e aquelas em que trabalhará hoje.
- O processo de trabalho acontece em sprints. Tudo é dividido em sprints. Cada sprint dura duas semanas.
- Os sprints são criados, preenchidos e encerrados pelo líder da equipe.
- Se o projeto tem prazos rígidos, tentamos estimar aproximadamente todas as tarefas. E reunimos essas tarefas em um sprint. Se o cliente tenta adicionar mais tarefas ao sprint, então definimos prioridades e adiamos algumas outras tarefas para o próximo sprint.
b) Processo de trabalho com o cliente
- Cada desenvolvedor pode e deve se comunicar com o cliente.
- Não se deve permitir que o cliente imponha suas regras de jogo. É necessário, de maneira educada e amigável, deixar claro para o cliente que somos especialistas em nossa área, e somente nós devemos estruturar os processos de trabalho e envolver o cliente neles.
- É essencial, idealmente, antes de começar a implementação de qualquer funcionalidade, criar um fluxograma de todo o processo lógico para a funcionalidade (workflow). E enviá-lo para aprovação do cliente. Isso se aplica apenas a funcionalidades complexas e não óbvias, como sistemas de pagamento, sistemas de notificações, etc. Isso permitirá entender mais precisamente o que o cliente realmente precisa, manter a documentação da funcionalidade, além de se proteger contra o que o cliente pode afirmar no futuro, que não fizemos o que ele pediu.
- Todas as diagramas/esquemas/lógica etc. são armazenados no Confluence/Jira, onde pedimos ao cliente para confirmar a correção da implementação futura nos comentários.
- Nos esforçamos para não sobrecarregar o cliente com detalhes técnicos. Se precisamos entender como o cliente deseja, desenhamos algoritmos primitivos na forma de diagramas, que o cliente pode entender e ajustar.
- Se o cliente encontra um bug no projeto, pedimos que descreva muito detalhadamente no Jira. Sob quais circunstâncias ocorreu, quando, qual sequência de ações o cliente realizou durante os testes. Pedimos para anexar capturas de tela.
- Fazemos o deploy no servidor de desenvolvimento todos os dias ou, no máximo, a cada dois dias. Assim, o cliente começa a testar a funcionalidade e o projeto não fica parado. Isso também serve como um sinal para o cliente de que o projeto está em pleno desenvolvimento e ninguém está contando histórias para ele.
- Muito frequentemente acontece que o cliente não entende completamente o que realmente precisa. Como está criando um novo negócio para si, com processos ainda não ajustados. Portanto, é comum que joguemos fora grandes trechos de código e reformulemos a lógica do aplicativo. Isso implica que não vale a pena cobrir tudo com testes. Faz sentido realizar testes apenas nas funcionalidades criticamente importantes e mesmo assim com ressalvas.
- Existem situações em que a equipe percebe que não conseguimos cumprir os prazos. Nesse caso, fazemos uma auditoria rápida das tarefas e informamos imediatamente ao cliente. Como saída, sugerimos lançar em prazo a funcionalidade importante e crítica, e deixar o resto para depois do lançamento.
- Se o cliente começa a inventar várias tarefas aleatórias, começa a fantasiar e a explicar com gestos, pedimos que nos forneça um modelo da página e um fluxo com a lógica que deve descrever completamente o comportamento de todo o modelo e seus elementos.
- Antes de assumir qualquer tarefa, devemos garantir que essa funcionalidade estava nas condições do nosso contrato. Se for uma nova funcionalidade que foge dos acordos iniciais, devemos estimar essa funcionalidade ((tempo aproximado de execução + 30%) x 2) e informá-lo que levará esse tempo, além da prazos serem adiados conforme o tempo estimado multiplicado por dois. Se conseguirmos completar a tarefa mais rapidamente, ótimo, todos sairão ganhando. Se não, nos protegemos.
b) O que não aceitamos na equipe:
- Falta de compromisso, desorganização, esquecimentos
- “Deixar para depois”. Se você não pode cumprir uma tarefa, não sabe como, deve imediatamente notificar o líder da equipe, e não esperar até o último momento.
- Arrogância e vaidades de alguém que ainda não demonstrou suas capacidades e profissionalismo em ações. Se demonstrou, tudo bem, dentro dos limites do decoro 🙂
- Engano em qualquer forma. Se a tarefa não foi concluída, não deve mudar seu status para concluída e informar ao cliente que está pronta. O computador quebrou, o sistema deu erro, o cachorro comeu o laptop — tudo isso é inaceitável. Se ocorrer uma força maior real, o líder da equipe deve ser imediatamente notificado.
- Quando o especialista está constantemente offline e é difícil contatá-lo durante o horário de trabalho.
- Toxicidade na equipe não é permitida! Se alguém discorda, todos se reúnem em uma reunião para discutir e resolver isso.
E uma série de questões/teses que às vezes faço ao meu cliente para esclarecer mal-entendidos:
- Quais são os seus critérios de qualidade?
- Como você determina se há problemas no projeto ou não?
- Ao violar todas as nossas recomendações e conselhos sobre alteração/melhoria do sistema, todos os riscos são de sua responsabilidade.
- Qualquer alteração significativa no projeto (como todos os possíveis fluxos extratos) pode levar ao surgimento de bugs (que, naturalmente, vamos corrigir).
- É impossível entender em alguns minutos qual é o problema que ocorreu no projeto, e ainda mais corrigi-lo imediatamente.
- Trabalhamos em um fluxo de produto específico (Tarefas em Jira — Desenvolvimento — Teste — Implantação). Portanto, não podemos reagir a todo o fluxo de pedidos e reclamações no chat.
- Os programadores são exatamente programadores, e não testadores profissionais, e não conseguem garantir a devida qualidade dos testes do projeto.
- A responsabilidade pela teste final e aceitação das tarefas em produção recai inteiramente sobre você.
- Se já iniciamos uma tarefa, não podemos imediatamente mudar para outras, até terminarmos a atual (caso contrário, isso leva a ainda mais bugs e prolonga o tempo de desenvolvimento).
- A equipe diminuiu (devido a férias ou doenças), mas o trabalho aumentou e não conseguiremos fisicamente responder a tudo o que você deseja.
- Um pedido de sua parte para implantar em produção sem tarefas testadas em desenvolvimento — isso é apenas seu risco, não o dos desenvolvedores.
- Quando você define tarefas vagas, sem um fluxo correto e sem maquetes de design, isso exige de nós muito mais esforço e tempo de implementação, pois precisamos fazer um trabalho adicional em seu lugar.
- Qualquer tarefa relacionada a bugs, sem uma descrição detalhada de sua ocorrência e capturas de tela, não nos permite entender o que deu errado e como simular esse bug.
- O projeto requer constantes melhorias e upgrades para aumentar a performance e a segurança. Portanto, a equipe dedica parte de seu tempo a essas melhorias.
- Devido a horas extras (correções urgentes), nós devemos compensá-las em outros dias.
Geralmente, o cliente logo percebe que o desenvolvimento de software não é tão simples, e apenas o desejo claramente não é suficiente.
Em suma, isso é tudo. Deixo de lado muitas negociações e a depuração inicial de todos os processos, mas tudo se acertou no final. Posso dizer que esse processo se tornou para nós uma 'Bala de Prata'. Novas pessoas que entraram no projeto podiam já começar a trabalhar desde o primeiro dia, pois todos os processos estavam documentados, e a documentação e a arquitetura em forma de diagramas proporcionavam uma visão clara do que estávamos fazendo.
P. S. Quero esclarecer que não temos um gerente de projetos do nosso lado. Ele está do lado do cliente. Totalmente não técnico. O projeto é europeu. Toda a comunicação é apenas em inglês.
Boa sorte a todos nos projetos. Não se exaustem e tentem aprimorar seus processos.
O código está no meu .
Fonte: habr.com
