Aceleramos o processo de desenvolvimento de projetos complexos. Sem caos e nervos

Na prática, geralmente encontramos o fato de que o gerente de projeto deseja acelerar o processo de desenvolvimento - ele não está satisfeito com a velocidade de entrega de novas funcionalidades. Normalmente, esses clientes precisam de produtos complexos, como um sistema de gerenciamento hospitalar, um sistema de negociação de câmbio, sistemas bancários e serviços bancários.

Nesses casos, você pode conectar uma nova equipe de especialistas, estabelecer processos em uma já existente ou combinar os dois. Considere os prós e contras de cada abordagem. Faça imediatamente uma reserva indicando que o artigo discute o desenvolvimento de projetos grandes e complexos (mais de 10.000 horas).

Por que você não pode conectar imediatamente novos especialistas

Freqüentemente, a opção mais fácil e óbvia para aumentar a velocidade de desenvolvimento é conectar novos especialistas ou uma equipe. Parece ao gerente de projeto que isso pode acelerar a velocidade de fornecer valor comercial aos usuários finais. Na prática, esse nem sempre é o caso, especialmente quando os processos no projeto exigem processamento. Damos um exemplo de nossa prática.

Era necessário conectar duas equipes a um projeto em desenvolvimento existente. O projeto foi desenvolvido por mais de 4 anos e contém um grande número de subsistemas (mais de 20) com seus mecanismos e serviços comuns. Uma regressão completa exigiu a participação de 5-7 engenheiros de controle de qualidade e cerca de 4-6 dias úteis. Ao entrar no projeto e deixar as equipes no nível necessário de resolução de problemas, elas encontraram as seguintes dificuldades:

• Uma parte do código fonte do sistema estava sob o controle do sistema de controle de versão svn, a outra git. O SVN era anteriormente muito popular, no entanto, para grandes projetos de equipe e frequentes mudanças simultâneas, não é adequado. Portanto, antes de mudar para o git, parte do tempo era gasta em mesclagens, edição de conflitos e outras operações relacionadas à ramificação no svn.
• Havia uma instrução desatualizada para implantar o ambiente, para que as equipes coletassem todos os tipos de armadilhas desse sistema e só pudessem iniciar as primeiras tarefas após 3-4 dias.
• Analistas-chave, especialistas técnicos estavam ocupados preparando o lançamento, por isso era impossível obter rapidamente informações esclarecedoras sobre novas tarefas. A configuração da tarefa era de nível superior. Isso diminuiu significativamente a implementação de tarefas.
• O fluxo de trabalho das tarefas foi difícil, a princípio as equipes "tropeçaram" em como lidar com a tarefa ao longo de seu ciclo de vida.
• No início, o cliente queria se dar bem apenas com os esforços de seus engenheiros de controle de qualidade, mas não conseguiu verificar completa e prontamente a nova funcionalidade das equipes de desenvolvimento conectadas, devido à carga pesada. Portanto, eu tive que trabalhar com horas extras.
• A revisão do código foi realizada de acordo com os princípios e critérios estabelecidos pelo projeto. Os critérios não foram documentados. Portanto, foi gasto tempo extra corrigindo os comentários.

O resultado das nuances acima são:

• custos de tempo adicionais que poderiam ser gastos na solução de problemas de negócios
• desenvolvimento lento de todo o sistema
• ou horas extras.

Considere como evitar essa situação.

Análise de processo

Antes de conectar novos especialistas, vale a pena descobrir como o trabalho da equipe é organizado - é necessário encontrar e eliminar os gargalos. Normalmente, o PM lida com esse problema, pois ele é responsável pelo projeto e deseja gastar menos energia no rastreamento de processos.

Eliminar gargalos leva o projeto adiante. Por exemplo, o tempo necessário para entrar em um novo especialista ou equipe de especialistas é reduzido, o envolvimento da equipe no projeto é aumentado, o custo de uma hora é reduzido devido à implementação correta das tarefas na primeira vez. Se todos os gargalos forem removidos, o gerente de projeto receberá um aumento tão rápido na velocidade de desenvolvimento quanto a prática atual e o contexto do projeto permitirem. Em geral, é bom para todos.

A análise de gargalos é possível de dois lados: da alta gerência / especialista e da equipe. Analisaremos cada opção separadamente.



Especialistas externos. Nessa abordagem, o processo de trabalho é analisado por uma equipe externa de especialistas externos ou pelo gerente de projeto em conjunto com o líder da equipe. Com o último, não é o fato de que ele vai acabar - é importante que eles possam descartar todas as nuances do projeto, caso contrário, a análise não terá sentido.

Uma condição importante é o suporte ao gerenciamento de projetos e a disponibilidade para mudanças.

Consequentemente, o especialista mergulha no projeto e analisa detalhadamente a documentação, código fonte, estrutura do banco de dados, processo de produção (da análise à liberação). O trabalho em fases é assim:

1. Toda a cadeia de trabalho do projeto é considerada do começo ao fim. O tempo de cada processo é medido.
2. Um gráfico de Gantt é construído. O especialista analisa quais processos estão sendo executados em paralelo, qual após o outro.
3. Um especialista pensa em como tornar cada processo mais produtivo e menos dispendioso. Como regra, um especialista compreende intuitivamente em quais lugares as maiores dificuldades surgem e começa a acelerá-las para uma possível modernização.

As vantagens desta abordagem:

• O trabalho é analisado por uma pessoa que não está envolvida no projeto. Ele tem uma visão direta dos processos, portanto, ele pode encontrar os problemas que não são visíveis para os membros da equipe.
• Um especialista, como autoridade, é capaz de convencer uma equipe a aceitar mudanças nos processos. As equipes que trabalham em um projeto há muito tempo não buscam inovação. Para eles, isso é muito estressante, pois eles terão que reaprender novamente. Além disso, essa reação chega até às mudanças que ajudarão a trabalhar com mais eficiência.
• Rápida implementação de soluções - de 2 a 15 dias. Tudo depende da mudança global e da burocracia dentro da organização.
• A equipe do projeto leva a experiência de especialistas de terceiros. No futuro, isso ajudará a configurar processos de forma independente.

Contras:

• Os especialistas precisam gastar muito tempo para entender os meandros. A equipe pode estudar a história do projeto em um dia, enquanto o especialista precisa de pelo menos uma semana e meia.
  O que fazer sobre isso : defina os objetivos da análise juntamente com o gerente do projeto / líder da equipe. Dê ao especialista todos os projetos "introdutórios", não esconda os detalhes.
  
  Se o cliente é tão leal que está pronto para analisar iterativamente o projeto, você precisa aproveitar a oportunidade e concordar com essas condições. Posteriormente, será possível ajustar a direção da análise após cada iteração, concentrando-se apenas na desejada.
• Alguns membros da equipe podem não concordar com a decisão. Posteriormente, eles podem sabotar o projeto, implementar mal o contrato e isso afeta o clima geral da equipe.
  
  O que fazer sobre isso : discuta cada decisão com a equipe e não coloque-a imediatamente antes do fato.
  
  Opção ideal: o especialista analisa os processos de forma independente e depois os discute com as principais pessoas do projeto. Se houver contradições, eles as discutem. Isso acumulará muitas pessoas leais às mudanças que afetarão outros membros da equipe. Será possível convencer os céticos mais ardentes.

Da equipe . Essa abordagem pode ser chamada de retrospectiva, que é parte integrante do scrum. O processo é assim:

• Toda a equipe do projeto está indo
• Um dos participantes assume o papel de facilitador (scrum-master). Ele garante que a conversa prossiga de maneira construtiva.
• A equipe discute suas abordagens para o trabalho. Todos os aspectos são considerados: processos, codificação, estabelecimento de metas etc. Em seguida, os prós e contras são destacados.
• Em uma votação geral, eles concordam com as mudanças: as vantagens precisam ser corrigidas, os negativos removidos.
• Após 3-4 semanas, o processo se repete. A equipe analisa os resultados e, se todos estão satisfeitos com tudo, o trabalho continua.

Termos importantes:

1. Suporte de gerenciamento para quaisquer mudanças e inovações.
2. Coesão da equipe e foco na melhoria.

Se a cultura da empresa não incentiva a iniciativa, a inovação, a retrospectiva não é a melhor maneira de redesenhar os processos. Os membros da equipe não vão além do “pântano”.

Vantagens da abordagem:

• Participação de cada participante na discussão do projeto.
• A capacidade de identificar todos os aspectos positivos do projeto e, se necessário, transformá-los em um determinado modelo (melhores práticas).
• Os membros da equipe compartilham experiências entre si.
• Resolução gradual de problemas, a partir daqueles que diminuem a velocidade da equipe e do projeto, terminando com pequenas melhorias.

Contras:

• Existe o risco de que apenas pequenos problemas sejam resolvidos e todos os principais permaneçam intocados.
  O que fazer sobre isso : O PM, o líder da equipe e o facilitador devem influenciar sua opinião sobre a equipe através da autoridade. Sua tarefa é chamar a atenção para problemas importantes na fase de discussão.
• Para grandes mudanças que exigem muito trabalho, é necessário tempo adicional para coordenação com a gerência. No entanto, não é fato que a gerência concorde com as inovações.
  O que fazer sobre isso : defender seu ponto de vista antes da liderança é a única solução.
• Se a equipe não tiver treinamento contínuo (conferências, troca de experiências, treinamentos), é muito provável que as decisões tomadas sejam desatualizadas e não sejam tão eficazes.
  O que fazer com isso : constantemente troque experiências. Participe de conferências, reuniões e treinamentos internos relevantes. Se estamos falando de uma grande empresa, uma boa opção seria dias de demonstração. Nesses eventos, as equipes mostram quais resultados alcançaram em seu trabalho.

Na maioria dos casos, é possível adaptar e melhorar os processos descritos acima. Mesmo que seja inicialmente claro que é realmente possível concluir o projeto no prazo, atraindo novos especialistas / equipes, recomendamos enfaticamente que você tente as etapas acima.

Se, após eliminar os gargalos, o gerente de projetos acreditar que a capacidade não atingiu o nível desejado, você poderá conectar novas equipes.

Preparando a infraestrutura para novas equipes

Nesta fase, vale a pena realizar um trabalho preparatório que reduzirá a duração e o custo do desenvolvimento, ajudando a salvar as células nervosas dos desenvolvedores. Vamos considerar quais condições devem ser:

1. As tarefas para a nova equipe devem ser detalhadas em detalhes. Você pode iniciar cada um deles sem esperar - não há dependência de tarefas atuais ou futuras. As áreas de responsabilidade de cada equipe são descritas.
   Se esse não for o caso , a maioria da nova equipe permanecerá ociosa ou se envolverá em tarefas secundárias que tenham o menor impacto no valor do produto.
2. A arquitetura do projeto é "correta", ou seja, dividido em módulos, subsistemas, componentes comuns.
   
   Se isso não acontecer , a conexão de um novo comando falhará. Os desenvolvedores trabalharão sob o controle do atual líder da equipe, mas uma pessoa pode gerenciar efetivamente não mais que 7-9 pessoas. A timlid será dividida e alguns membros da equipe ficarão ociosos até receberem tarefas.
   
   Se não for possível isolar seções isoladas do código do projeto, mas você precisar avançar, tente ignorar essa limitação. É necessário dividir o projeto em várias partes através da refatoração.
   
   Outra opção - depois de imergir duas ou três pessoas no projeto, para dar à nova equipe mais e mais grandes funções de negócios. Portanto, as equipes desenvolverão o projeto isoladamente umas das outras e, devido ao novo líder da equipe (uma pessoa que está imersa nas sutilezas), reduzirá a carga no líder principal da equipe.
3. Os processos de trabalho no projeto são descritos em detalhes. Por exemplo, há uma tarefa de fluxo de trabalho, a tarefa é mostrada para ser executada no sistema de controle de versão (a prática mostra que nem todo mundo tem um GitFlow padrão), a interação entre os participantes do projeto é descrita.
   Se isso não acontecer , o caos será criado no projeto. Nesse caso, o gerente de projeto lidará apenas com o gerenciamento de emergência “manual”.
4. Componentes e módulos comuns possuem documentação relevante e compreensível. Existem testes de unidade e integração das partes principais. Há uma descrição clara da arquitetura de todo o projeto, mecanismos gerais e instruções sobre como aplicá-los. Se o acima ainda não existe, é necessário adicionar tarefas semelhantes ao conjunto de dívidas técnicas para corrigir a situação.
   
   Se não for esse o caso , aumentará o risco de realizar um trabalho duplo. Um código-fonte ruim ou duplicado será gravado. No futuro, isso levará a um suporte de projeto mais caro. Como regra, conectar uma nova equipe implica a possível conexão de várias outras equipes. Assim, os custos de tempo serão reduzidos por um múltiplo do número de equipes.
5. Existem regras fixas para escrever código - código de convenção, scripts para atualizar a estrutura do banco de dados - migração, princípios gerais de revisão obrigatória de código. Apesar da forte semelhança, com certeza cada projeto tem suas próprias características.
   Se não for esse o caso , a complexidade e o custo de apoiar ainda mais o projeto aumentarão muitas vezes.

As condições acima permitem conectar novas equipes com mais eficiência. O tempo que leva para a equipe entrar no projeto é bastante reduzido. O mesmo acontece com os custos de mão-de-obra para apoiar e desenvolver o projeto.

Como conectamos uma equipe adicional ao projeto

Tivemos um caso em que o projeto precisava urgentemente acelerar o processo de desenvolvimento. Restam 2 a 3 meses até a próxima versão principal ser colocada em operação comercial. O projeto em si era um sistema complexo que foi desenvolvido por uma equipe por 3-4 anos.
Antes de tudo, mergulhávamos no contexto do próprio projeto. O resultado é a seguinte imagem dos gargalos do projeto:

1. Não há informações precisas sobre como os recursos devem ser implementados. A lista de tarefas, bugs e melhorias está desatualizada.
2. Não há integração contínua e o desenvolvimento é realizado em dois ramos.
3. O processo de teste do produto não é depurado. Por exemplo, os engenheiros de controle de qualidade podem encontrar bugs que já foram corrigidos, o que gera custos adicionais de mão-de-obra.
4. A base dos casos de teste estava em sua infância. Os engenheiros de controle de qualidade individuais começaram a escrever casos para si mesmos. Por esse motivo, ninguém poderia dar uma certa avaliação da qualidade do produto e dos possíveis riscos ao lançar uma nova versão.
5. O processo de trabalho, da produção à aprovação do cliente, não está documentado. Era impossível prever a composição exata das funções de liberação, bem como outros pontos menos significativos.

Após a análise, criamos um plano para eliminar os pontos acima. Obviamente, a equipe não concordou imediatamente com as mudanças, mas com o apoio da liderança e o desenvolvimento de prazos claros, conseguimos convencer cada membro da equipe.

Coordenamos nossas ações com as principais pessoas do projeto: PM, líder de equipe, analista líder. Juntas, essas três pessoas constituem um único centro de equipe de gerenciamento de clientes. Além disso, promovem soluções e monitoram sua implementação na prática. Sem essa equipe de gerenciamento, é impossível coordenar as ações de mais de três equipes.

Como resultado, os seguintes processos foram implementados \ otimizados:

1. Construímos comunicações entre todos os membros da equipe do produto - desenvolvedores, analistas e especialistas em testes.
2. Eles documentaram funções críticas e complexas para testes mais transparentes, eliminando defeitos, resolvendo disputas e planejando o trabalho subsequente.
3. Processos de desenvolvimento otimizados. Adotado pelo projeto WorkFlow e GitFlow. Eles ajudaram a configurar a integração contínua e executar testes automáticos no modo automático.
4. Dobramos a velocidade de montagem das bancadas de teste.
5. Organizou o processo de testes adequados. Teste de regressão implementado no final de cada iteração.
6. Introduziu o processo de planejamento de iteração.
7. Realizou testes de carga.

Com base nos resultados da primeira iteração, preparamos a infraestrutura para conectar uma nova equipe. Paralelamente, dois de nossos desenvolvedores se juntaram à equipe atual para mergulhar na base de código. Então um deles se tornou o líder da nova equipe. Na segunda iteração, as duas equipes alcançaram os seguintes resultados:

• Comissionamento após 3 meses.
• Corrigido 70% dos bugs
• Quatro recursos sérios implementados
• Otimizado e aumentado em 8 vezes a velocidade de carregamento de algumas páginas
• Recebeu informações precisas sobre a qualidade de todo o produto
• Iterações do RoadMap incorporado

Acredito que uma das realizações mais importantes deste projeto é a alegria do cliente. Ele representou de forma transparente o status do projeto a qualquer momento, e as obrigações para com os negócios foram cumpridas na íntegra e no prazo.

Conclusão

Existem duas maneiras principais de aumentar a velocidade do desenvolvimento do projeto: eliminar gargalos e aumentar as capacidades de produção. No primeiro caso, você pode obter um aumento de 30 a 40% na velocidade de desenvolvimento, no segundo de 70 a 80%. Comandos adicionais não dão um aumento duplo na produtividade, pois é gasto mais tempo na interação entre várias equipes.

Os principais fatores de sucesso para expandir as equipes de desenvolvimento são:

• trabalho preparatório
• processos estabelecidos
• um líder ou membro de uma equipe de projeto que promova e supervisione as atividades das equipes,
• centro de controle de comando único.

Atualmente, três equipes estão trabalhando no projeto que descrevemos anteriormente (um antigo e dois novos). O número de tarefas executadas aumentou 1,9 vezes .