Como regra, no campo do desenvolvimento personalizado da Web, todas as agências sonham apenas com clientes cujos projetos crescerão duas vezes no volume de negócios anual, entregam regularmente casos que podem se orgulhar e ganham prêmios de classificação de perfil pela agência. Esses clientes são líderes do setor. São empresas cujo negócio é construído na Web ou grandes redes offline que, graças a investimentos impressionantes, alcançam as posições de liderança no canal da Web.
Parece que, tendo alguns desses clientes, você pode descansar sobre os louros - pare de vender e apenas controle o fluxo sempre crescente de tarefas. Mas, na realidade, à medida que o projeto cresce, ele oferece novos e novos desafios para lidar e salvar o cliente. Ao trabalhar de maneira econômica, será uma tarefa muito difícil.
Crescimento do projeto e desafios relacionados
É importante tomar medidas proativas a tempo e suportar os custos adicionais associados ao dimensionamento. A princípio, isso pode afetar adversamente a lucratividade, mas, ao atingir determinados volumes, ficará claro que o investimento inicial foi justificado.
Aqui estão os principais desafios que a agência pode enfrentar em um projeto como esse:
- O problema do dimensionamento é a reestruturação da estrutura da equipe com o crescimento dos volumes.
- A necessidade de entender as tarefas do produto e de negócios - sem uma forte análise do produto, é impossível trabalhar efetivamente em um grande projeto.
- Arquitetura complexa de software e servidor - juntamente com o crescimento dos volumes de produção do projeto, também há um aumento no atendimento, levando a uma arquitetura mais complexa e à necessidade de usar soluções de alta carga.
- Requisitos de alta qualidade.
- A necessidade de garantir operação ininterrupta 24 × 7 e uma alta velocidade de resposta a incidentes, inclusive fora de horas.
- Alto grau de responsabilidade por interromper as vendas.
- Monitoramento e controle de indicadores de negócios.
Nem todas as agências no mercado têm as competências necessárias para lidar com todos esses desafios. Hoje falaremos sobre o problema de escalar a equipe - o aspecto mais difícil, na minha opinião, de trabalhar com um projeto em crescimento.
Tive a oportunidade de trabalhar em vários projetos com crescimento explosivo, incluindo a maior loja online de artigos para crianças e a principal companhia de seguros.
Participei desses projetos primeiro como gerente e depois como chefe de uma equipe de gerenciamento, e quero compartilhar a experiência adquirida.
Funções em um projeto pequeno e por que você precisa escalar
O esquema de função se parece com isso no caso geral:
Na AGIMA, usamos o gerenciamento em três etapas, quando todas as questões táticas são decididas dentro da estrutura de interação da equipe do projeto, e as questões estratégicas são levadas ao nível de diretor de contas e chefe do departamento de atendimento ao cliente. Uma hierarquia é construída dentro da equipe do projeto, dependendo da escala do projeto, falarei sobre isso abaixo.
É assim que um diagrama de funções típico se parece dentro de uma equipe de projeto em um projeto pequeno:
O projeto tem duas funções principais: gerente de projeto (RP) e líder da equipe.
A empresa se comunica com o cliente, formaliza as tarefas, elabora uma lista de pendências, determina prioridades, faz planos e exerce o controle das tarefas para conformidade com a lógica de negócios. Além disso, o RP se comunica em todas as etapas do trabalho com os departamentos de design, design, análise e administração do sistema.
O Timlid realiza formalização técnica de tarefas, define as tecnologias / ferramentas utilizadas, realiza uma revisão de código, realiza lançamentos, monitora a integridade arquitetônica do projeto e coordena as equipes de desenvolvimento.
Os recursos restantes podem ser conectados ao projeto conforme necessário e são altamente intercambiáveis.
Um marco importante no crescimento do projeto e uma mudança de paradigma peculiar ocorre em um momento em que é impossível manter todas as informações em uma única cabeça. Um líder de equipe fisicamente não pode controlar toda a arquitetura do projeto, pois cresce muito rápido. Um gerente não tem tempo para mergulhar em todas as tarefas e controlar todo o trabalho.
É necessário separar e duplicar as tarefas dos funcionários, e o esquema de funções padrão se expande e se torna mais complicado.
Estrutura da equipe de gerenciamento
Uma das unidades mais difíceis de dimensionar é a RP.
À medida que o projeto cresce, faz sentido implementar o esquema clássico de gerente de contas em pares - gerente de projetos, quando um RP cuida do atendimento ao cliente, incluindo questões de produtos, e o segundo organiza o processo de produção dentro da empresa.
No entanto, esse esquema se torna um impasse com o crescimento subsequente. Dentro da estrutura de um projeto, pode haver várias dezenas de produtos, cada um dos quais requer muita atenção do ponto de vista dos processos de negócios. Nesse caso, surgem situações periodicamente quando o desenvolvimento paralelo de diferentes produtos leva a conflitos lógicos na estrutura da arquitetura de aplicativos da web ou lógica de negócios, o que implica riscos extremamente altos.
Portanto, o esquema ideal do ponto de vista de maior escalabilidade é o seguinte:
O Chefe do Grupo (GH) gerencia a equipe gerencial do projeto e é responsável pelo controle de orçamentos, lucratividade, formação de equipes (executores gerenciais e diretos) e alocação de recursos, além de resolver questões estratégicas do gerenciamento de projetos. Ele também conduz o controle do produto e monitora a ausência de conflitos em processos paralelos. Ele não gasta tempo em atividades operacionais e monitorando a implementação de cada tarefa específica.
Graças à introdução dessa função, os casos são eliminados quando várias tarefas grandes são executadas em paralelo e as contradições e conflitos lógicos são revelados na fase final, o que, no caso menos bem-sucedido, resulta em refatoração completa.
Se necessário, uma função adicional de proprietário do produto está conectada, à qual o GH delega parte das responsabilidades do produto. Na maioria das vezes, esse funcionário é baseado no cliente e transmite todos os desejos da empresa na forma de tarefas formalizadas para execução.
Cada PR da equipe é responsável por sua "peça" do projeto, assumindo o controle de todas as tarefas atuais de vários produtos (idealmente, essas devem ser áreas relacionadas). Suas responsabilidades incluem o tempo e a qualidade de todas as tarefas no âmbito do desenvolvimento de produtos responsáveis.
O esquema é facilmente escalável e possui um limite de entrada relativamente baixo, pois ao conectar um novo RP, ele não precisa cobrir simultaneamente toda a base de conhecimento do projeto, basta entender o princípio de operação dos "seus" produtos.
É importante que cada RP seja responsável não apenas pelo processo de produção, mas também seja versado na lógica de negócios de seus produtos. Graças a isso, todas as decisões de gerenciamento não são apenas corretas do ponto de vista do gerenciamento de projetos, mas também são úteis para os negócios e a arquitetura é verificada.
Em alguns casos, o papel do administrador do projeto deve ser destacado separadamente - esse funcionário não mergulha no componente do produto ou no processo de produção, mas está envolvido na preparação de relatórios, é responsável pelo gerenciamento de documentos e também desempenha o papel de "primeira linha", garantindo a continuidade da comunicação e respostas rápidas a todas as solicitações de clientes e parceiros .
Ao mesmo tempo, toda a equipe de gerenciamento incluiu motivação coletiva, ligada ao gerenciamento das expectativas dos clientes, em primeiro lugar - entrar no cronograma do projeto.
- 10 dias úteis antes do início do mês, cada RP em si aloca de três a cinco de suas principais tarefas para o próximo mês.
- Cinco dias úteis antes do início do mês, o GH seleciona dois ou quatro para cada gerente e define os prazos: 1 - prazo do cliente (50%), 2 - prazo interno (100%) e o insere na tabela.
Condições de bônus (de acordo com os resultados do mês):
- O gerente recebe bônus de 100% se todas as suas tarefas forem concluídas dentro do prazo interno.
- O gerente recebe 50% dos bônus se pelo menos uma de suas tarefas sair do prazo interno, mas foi concluída no prazo do cliente.
- Nenhum dos gerentes recebe bônus se pelo menos uma tarefa da lista geral não tiver sido concluída no período do cliente.
Esse esquema permite que toda a equipe de gerenciamento trabalhe de maneira eficaz e correta, gerenciando as expectativas do cliente.
Testando não apenas o código final - comando QA
À medida que o projeto cresce, uma sólida base de conhecimento se acumula, o número de nuances e recursos aumenta, os relacionamentos lógicos se tornam mais complexos e diversificados. Em algum momento, esses fatores começam a exercer uma influência tão forte que a depuração de pré-lançamento leva tempo proporcional ao desenvolvimento e requer a mesma quantidade de recursos.
Para evitar essa situação, surgiu a idéia de criar uma equipe de controle de qualidade de pleno direito com base na equipe de teste. A principal diferença é que o teste é realizado não apenas no estágio de desenvolvimento-depuração-lançamento, mas em todas as etapas do projeto:
- O controle de qualidade é responsável pela qualidade do produto e sua conformidade estilística e lógica com outros produtos e geralmente aceito nas regras do projeto.
- O controle de qualidade examina todos os artefatos que aparecem no projeto: a formalização inicial da tarefa, protótipos, especificações, design e, é claro, testar o código e o layout, escrever casos de teste, cobrir a funcionalidade existente e nova com uma grade de autotestes.
- Sem a validação de materiais pela equipe de controle de qualidade, o RP não tem o direito de iniciar a próxima etapa ou enviar materiais para aceitação do cliente.
Essa abordagem pode reduzir bastante os riscos de depuração prolongada e atrasar as datas de lançamento.
Timlids - eficiência ou intercambiabilidade?
Assim que o segundo líder da equipe é apresentado ao projeto, a pergunta surge imediatamente - qual esquema de distribuição de responsabilidades deve ser aplicado?
Existem várias opções: dividir o projeto por tipo de atividade, ou seja, a equipe A se concentra na arquitetura, revisão de código e formalização técnica de tarefas, enquanto a equipe B gerencia equipes de desenvolvimento e libera builds, é responsável pela continuidade e segurança. A segunda opção é uma divisão do produto, na qual cada líder de equipe é totalmente responsável por seu conjunto de produtos no projeto.
Ambas as opções são boas em termos de utilização de recursos, mas apresentam grandes riscos em termos de permutabilidade.
Por exemplo, o que devo fazer se um dos líderes da equipe ficar doente, sair de férias ou sair? Será difícil incluir uma nova liderança de equipe no processo, pois o período de imersão nessa função é extremamente longo.
Portanto, vale a pena usar um esquema híbrido no projeto, no qual cada líder de equipe está envolvido em suas próprias tarefas, mas há várias atividades nas quais todos ou pelo menos dois líderes de equipe são dedicados.
Essas atividades incluem as de maior risco, por exemplo: arquitetura do projeto, continuidade, segurança, principais produtos que representam as vendas mais ativas e cujo desempenho é especificado no SLA.
Esse esquema, é claro, reduz a produtividade do trabalho, mas remove a maioria dos riscos. É necessário encontrar um equilíbrio entre eficiência e permutabilidade, descrevendo uma lista dos momentos mais cruciais.
Separadamente, faz sentido conectar os líderes de equipe a atividades alienadas: um produto que é arquitetonicamente divorciado da parte principal do projeto ou uma atividade que pode ser envolvida em paralelo. Por exemplo, é inteiramente possível destacar um layout de líder de equipe que assumirá completamente o controle de todas as operações da linha de frente; Distinguem-se separadamente os papéis de controle de qualidade, design e análise do líder da equipe.
Intercambiabilidade dos membros da equipe
Quanto mais pessoas envolvidas no projeto, mais ativamente você precisar usar as ferramentas para diminuir o limite de entrada para novos funcionários, além de simplificar a intercambiabilidade dos membros da equipe existentes e reduzir o fator de barramento.
Aqui estão algumas ferramentas com bom desempenho em quase todos os projetos.
Sistema de designO sistema de design é um kit de design abrangente e atualizado e uma biblioteca de componentes no repositório. Ele reflete o conjunto completo de elementos padrão no projeto e permite coletar novas páginas desses blocos. O sistema de design não apenas contém um conjunto de elementos, mas também descreve sua interação, além de exemplos de código.
O uso de um sistema de design pode simplificar bastante o entendimento de um novo funcionário, seja gerente, designer ou programador, das regras visuais do projeto, e aplicar soluções existentes em vez de inventar constantemente novas.
O uso de tais ferramentas requer uma grande despesa de recursos para desenvolvimento e suporte. Além disso, muitas vezes é preciso muito esforço moral para explicar ao cliente por que é necessário aderir a esse sistema e por que propostas como "Adicione um novo botão verde nesta página, como no site N, que parece tão bonito", serão rejeitadas.
A documentaçãoQuanto maior o projeto, mais cuidadosamente cada produto e cada recurso deve ser documentado; caso contrário, cada vez mais os especialistas gastarão mais tempo na depuração e na compreensão de como uma ou outra funcionalidade deve funcionar.
A documentação do projeto faz sentido dividir em 4 tipos:
- Especificações de interface - uma descrição do comportamento da funcionalidade implementada (lógica de trabalho, validação de campo, conjunto de telas).
- Os casos de teste (descrição dos cenários do usuário e os resultados de sua passagem), com base neles, se necessário, são desenvolvidos autotestes.
- Especificações de serviço (descrição da interação com serviços da web, dados de teste, exemplos de solicitação-resposta).
- Documentação do código (descrição dos componentes, classes e hierarquia, modelos).
Toda a documentação deve ser agregada em uma base de conhecimento on-line (Wiki) e mantida atualizada.
GitPara acelerar a conexão de novos desenvolvedores de outros projetos da empresa, está sendo introduzida uma abordagem padrão ao GitFlow. Na AGIMA, usamos a abordagem "trabalhar com dois ramos principais".
Em vez de usar a ramificação principal, duas ramificações principais do histórico do projeto são usadas: mestre para liberações e desenvolvimento para mesclar a funcionalidade desenvolvida das ramificações de recursos.
WorkflowOutra ferramenta que regula e padroniza o trabalho de todos os membros da equipe é o fluxo de trabalho por dia da semana.
Cada semana é um ciclo de produção padrão: os lançamentos são feitos estritamente às terças e quintas-feiras; Quarta-feira - dia das avaliações; A retrospectiva e o planejamento de novas remessas ocorrem no final da semana - na quinta e sexta-feira. Este é um exemplo de fluxo de trabalho de um dos projetos; para cada caso específico, uma abordagem deve ser desenvolvida.
O cliente também deve estar envolvido no fluxo de trabalho - esse sistema não pode funcionar unilateralmente.
Não menos importante é o fluxo de trabalho nos status das tarefas, o que simplifica a transição de funcionários entre projetos. Deve ser idêntico em todos os projetos da empresa. No AGIMA, fica assim:
Manter os membros da equipe informados
Mesmo que a documentação esteja perfeitamente organizada no projeto e todos os processos funcionem como um relógio, é impossível prever todos os riscos associados à falta de conhecimento de cada artista específico. Para isso, são organizados eventos regulares de vários formatos.
1. Reuniões de produtosNessas reuniões, funcionários mais experientes informam à equipe sobre produtos específicos. Os aspectos da lógica de negócios, implementação técnica e arquitetura são destacados. A conscientização de cada funcionário sobre as principais nuances dos produtos ajuda a apresentar idéias úteis e a tomar as decisões corretas em todas as etapas da implementação.
2. Seções de infraestruturaO projeto está crescendo dinamicamente, isso implica no constante desenvolvimento e expansão da infraestrutura. Nas seções regulares, são discutidos os problemas e tarefas atuais para o desenvolvimento da infraestrutura e discutidos os progressos na implementação de cada uma delas.
3. Retrospectivas e planejamento do trabalhoÉ necessário realizar reuniões semanais para discutir as tarefas implementadas na semana passada, destacar erros e planejar o trabalho para o próximo período contábil.
Conclusões
A aplicação cuidadosa de todas as ferramentas e abordagens acima ajudará a formar uma equipe coerente e resiliente que será facilmente dimensionada com o crescimento do projeto.
Sem dúvida, a organização de um sistema desse tipo carrega uma série de dificuldades e exige competências profundas dentro da agência e a disposição do cliente de investir em tais decisões, o que pode ser difícil em nosso mercado em desenvolvimento, mas esses esforços valem a pena e levam a uma cooperação frutífera e a longo prazo e permitem a emissão o mercado é realmente produtos de qualidade.