Olá pessoal! Meu nome é romano e hoje vou compartilhar minha experiência em uma equipe de layout distribuído. Vou falar sobre os processos que criamos e como uma equipe de quatro pessoas cobre as necessidades de layout de uma unidade inteira composta por mais de 30 produtos e mais de 20 equipes de produtos.
Também vou falar sobre como:
- Monitorar o trabalho de uma equipe distribuída;
- Obter consistência de código em diferentes projetos;
- Distribua tarefas de maneira justa;
- Manter um trabalho de alta qualidade;
- Não acumule tarefas inacabadas;
- Para evitar desgaste e desenvolver funcionários.
Em vez de se juntar
Acho que vale a pena dizer imediatamente por que temos designers de layout dedicados no Tinkoff Business. Afinal, existe uma opinião de que qualquer desenvolvedor da web deve ser capaz de fazer as pazes.
Em muitas empresas, os desenvolvedores estão todos digitando. Mas, primeiro, nem todos os desenvolvedores gostam de escrever e fazer isso muito bem. Em segundo lugar, para o desenvolvedor, o layout está longe de ser sempre de alta prioridade, o foco é mudado para o código. E quando não há foco, a qualidade e a atitude em relação aos detalhes sofrem.
Portanto, temos designers de layout dedicados, mas eles não estão anexados a um projeto específico, porque nem todos os projetos podem fornecer tarefas de layout o tempo todo.
Como foi antes?
Anteriormente, o processo era bastante simples.
Na minha unidade, havia quatro tipógrafos e uma sala de bate-papo especial, onde todas as pessoas interessadas jogavam quebra-cabeças para o layout, e nós os classificamos lentamente. Em geral, o sistema funcionou, mas havia, é claro, suas desvantagens.
Por exemplo, uma tarefa pode ser executada, mas nenhum dos tipógrafos respondeu à mensagem. O autor da tarefa começou a escrever na sala de bate-papo novamente - eles dizem: quem fará a tarefa? Além disso, não havia planejamento e entendimento de quem estava fazendo o quê, quando ele foi libertado e em quais projetos ele estava imerso.
Para que as mensagens dos autores não fiquem sem resposta, mesmo quando todos estão ocupados, comecei a responder todas as mensagens e me pergunto quem será capaz de realizar essa ou aquela tarefa quando. Ao mesmo tempo, ele determinou quem participava de quais projetos, quem sabe quais tarefas melhor. Durou cerca de um mês, o sistema começou a funcionar melhor - uma reação instantânea às tarefas de clientes completamente satisfeitos.
É verdade que essa abordagem ainda não forneceu respostas para muitas perguntas. Por exemplo, era difícil prever a carga, não havia unidade nas abordagens, não havia nenhum tipo de planejamento, cada um era por si só e resolvia seu problema de forma independente. Além do bate-papo, não havia um único ponto de entrada no layout, não havia ninguém para discutir com o novo projeto, para avaliar o design, porque não está claro quem irá trabalhar e quando.
E em uma das reuniões com o líder, decidimos organizar uma nova equipe de layout de todos os designers de layout, com quem compartilhamos tarefas para criar processos e fornecer layout para todos os projetos.
Aqui está o que veio disso.
Construindo uma equipe
Dado: quatro tipógrafos de diferentes cidades e até países. Mais de 30 projetos na mesma pilha, mas devido à natureza dos projetos, geralmente com arquiteturas diferentes, versões diferentes do design e componentes, equipes de desenvolvimento diferentes que às vezes praticam suas abordagens.
Primeiro, criamos um bate-papo privado apenas com designers de layout. Isso permite que você resolva rapidamente os problemas da equipe quando não precisa de muita urgência e sempre pode fazer uma pergunta, pedir ajuda a seus colegas ou revisar seu trabalho.
Controlar
Como controlar o trabalho dos funcionários, se eles não se sentam ao lado?
Em geral, existem diferentes tipos de controle, dependendo do nível de habilidades e do nível de confiança no funcionário. Não vou me debruçar sobre eles em detalhes, você mesmo aprenderá tudo.
Eu tive sorte - todos os caras eram igualmente bons e, por padrão, tinham 100% de confiança. Portanto, o sistema não era necessário tanto para controle, como para ações de sincronização e para entender o cenário geral. Para isso, introduzimos chamadas diárias matutinas de até 10 minutos, durante as quais todos disseram o que fizeram ontem e o que fariam hoje.
Essas frases servem apenas para sincronização por tarefas e projetos, não implicam análise de problemas, dificuldades, holivares ou outros problemas - tudo isso, se necessário, é enviado em frases ou discussões separadas no chat. É muito importante monitorar isso e interromper todas as tentativas de transferir a chamada para uma conversa de uma hora sobre o clima.
Consistência do código
Estamos recebendo tarefas de projetos completamente diferentes, com código e qualidade diferentes, por isso foi necessário obter um layout de alto nível para todos os projetos, independentemente dos dados de origem. Para fazer isso, por meio de discussões gerais e votação, desenvolvemos regras e diretrizes para o layout, as quais aderimos estritamente à nossa equipe e também recomendamos o uso por todas as outras. Até a ordem das propriedades é registrada.
Sim, se você escrever uma propriedade CSS de cor acima da largura, receberá um comentário e seu PR não ficará esmaecido. Isso pode parecer estranho, porque na maioria dos casos a ordem das propriedades não afetará o resultado final, mas lembramos: muitos projetos, um único alto nível de qualidade. Portanto, devemos ter o pedido máximo. Em todos os lugares. Até a ordem está na ordem das propriedades.
Devo dizer imediatamente que foi uma boa ideia corrigir o pedido. Ele permite que você escreva CSS mais estruturado e atencioso. Por exemplo, há uma regra para agrupar propriedades. Se você escrever display: flex, todas as propriedades relacionadas (alinhar itens, justificar conteúdo) deverão ser descritas lado a lado para facilitar a compreensão do que está acontecendo.
Agora, estamos gradualmente chegando à conclusão de que estamos colocando todas as regras em pauta para reduzir o número de comentários não críticos sobre a revisão, além de permitir que os revisores se concentrem em coisas realmente importantes, por exemplo, arquitetura.
A propósito, nossas configurações de linter são de domínio público, talvez sejam úteis para você. Faça o download das configurações .
Distribuição de tarefas
Então, a comunicação é estabelecida, as regras do jogo são fixas, mas como jogar? Por que Vanya faz apenas tarefas simples, e Pete fica complicado, e até mesmo em um projeto em que ninguém se envolveu há muito tempo?
De fato, existem projetos que:
- constantemente precisa de layout;
- constantemente precisa de layout e tudo muda constantemente;
- que foram escritas há muito tempo e começam a se desenvolver novamente.
Isso levanta outra questão: como distribuir tarefas de forma igual e justa?
A justiça é necessária?
Você pode usar o recurso administrativo e dizer rigidamente: "Petya, você executa essas tarefas, ninguém gosta delas, mas, por enquanto, levaremos essas interessantes com Vanya".
Isso, é claro, pode ser feito e, por algum tempo, até funcionará. Mas existem várias desvantagens disso:
- Petya começa a nos detestar um pouco, o que significa que ele está menos envolvido no trabalho em equipe;
- Um dia, Petya pode queimar e sair, sem aviso prévio, e teremos um buraco em nossos recursos;
- Petya tinha a maior experiência em projetos complexos e agora cada um dos demais precisará de muito tempo para entender os projetos de Petit.
Parece que você não deveria fazê-lo. Mas o que fazer?
Primeiro, você precisa selecionar vários grupos pelos quais pode interromper todas as tarefas recebidas.
Parece algo assim para nós.
Os projetos A, B e C geram constantemente centenas de tarefas e estão prontos para nos fornecer trabalho para o próximo ano. E existem outros projetos que vêm com uma ou duas tarefas a cada poucas semanas. Devido a limitações de recursos, concordamos que uma pessoa está constantemente trabalhando nos projetos A, B e C, e a quarta assume todas as tarefas de outros projetos. Parece que todos os recursos estão distribuídos, você pode trabalhar.
Mas, novamente, encontramos um problema quando uma pessoa que trabalha constantemente no projeto A não tem idéia do que está acontecendo no projeto C.
Para resolver esse problema, introduzimos o serviço de duas semanas.
A partir de segunda-feira e nas próximas duas semanas, Petya trabalha no projeto A, depois passa para o projeto B, depois C - então ele muda regularmente suas atividades.
Parece algo como isto:
O que isso nos dá? Em primeiro lugar, todos os caras são igualmente versados em todos os projetos e podem facilmente se substituir. Em segundo lugar, existem projetos mais interessantes e esse é o seu dever favorito, que adicionalmente motiva, fortalece e não permite o esgotamento do mesmo trabalho.
Além disso, para remover a regulamentação manual, concordamos que o próprio projeto define a prioridade do trabalho. Ou seja, destacamos a pessoa e ela executa as tarefas que o projeto dá. Isso é muito conveniente: não precisamos priorizar a equipe e pensar no pedido. Isso é feito pelo projeto, sua equipe e gerente de produto.
Verdade, você pode encontrar o problema. Uma pessoa entende as tarefas de todos os projetos que vêm de maneira irregular - aquele que não trabalha em nenhum dos principais projetos em serviço no momento.
Parece que ele pode ser bombardeado com tarefas, e os clientes serão puxados de todos os lados e, como resultado, não poderão trabalhar. Para eliminar esse risco, temos uma página especial com essas tarefas. Quando a próxima tarefa aparecer, ela será adicionada ao final da lista.
Aqui está um exemplo dessa página:
Todas as tarefas e seus status são visíveis nela. A qualquer momento, o cliente pode acompanhar o progresso e entender quando aproximadamente sua tarefa será executada.
Claro, todo mundo tem as tarefas mais urgentes e todo mundo quer sair do turno. Especialmente para tais situações, o seguinte mecanismo foi inventado: se o cliente está "pegando fogo" e ele quer que sua tarefa trabalhe mais rapidamente, ele deve concordar com alguém que está na lista acima dele. Se ele estiver pronto para dar o seu lugar - não há problema, troque as tarefas da lista.
Você pode pensar que este é um ponto bastante fraco e deve nos encher, mas há seis meses ele está funcionando.
Obviamente, as situações podem ser diferentes, mas ninguém cancelou a regulação manual e os recursos administrativos;)
Controle de qualidade
Todo mundo comete erros. Ainda não vi um único desenvolvedor ou designer de layout que nunca esteve errado. Como se pode minimizar o número de tais erros?
Para isso, aplicamos ativamente a prática de revisões de design. O que inclui?
Quando o trabalho no layout é concluído, o designer do layout chama o designer e mostra o resultado do trabalho em sua tela. Isso permite que você resolva vários problemas ao mesmo tempo:
- O designer pode ver o mais rápido possível o erro do designer de layout e o próprio erro, se uma imprecisão surgir no layout.
- Resolva prontamente problemas como "como ele deve ser exibido quando você passa o mouse ou se concentra?". A menos, é claro, que essas condições não se refletissem no design.
- E uma grande vantagem adicional: o designer pode ver que o resultado não parece ótimo e fazer alterações online.
No início da implementação dessa prática, tínhamos medo de que o trabalho fosse mais lento porque:
- o designer não está no lugar;
- o designer está doente e ninguém mais sabe;
- durante a revisão, o designer decidiu alterar completamente o layout.
Mas, na prática, essa abordagem funcionou bem e a implementamos na maioria dos projetos.
Revisão
Nós desenvolvemos bem a nossa equipe de layout, você pode trabalhar! Mas não, há mais uma coisa. Adotamos a prática da revisão cruzada.
Isso significa que qualquer pessoa pode revisar seus PRs e deixar comentários sobre eles. Apenas, para ser honesto, muitos desenvolvedores não gostam de se aprofundar na revisão do layout e estão prontos para oferecer a atualização "sem olhar" - se apenas o layout desaparecesse o mais rápido possível e eles pudessem escrever mais lógica.
Para evitar isso, temos uma regra: cada designer de layout é obrigado a adicionar todos os designers de layout a todas as suas solicitações de pool.
E o PR não pode ser congelado se você não tiver recebido pelo menos um upruv de outro tipógrafo. Nada mal, mas parece que existe o risco de engarrafamentos na forma de um grande número de RPs, porque os funcionários podem visualizar o código dos colegas de maneira inoportuna, o que atrasará o trabalho.
Para evitar isso, lembramos duas vezes por dia, às 10h e 15h, sobre a necessidade de realizar uma revisão dos colegas. E quando você entra no stash, vê quantos PRs estão aguardando sua análise.
Tentamos manter esse valor no mínimo. Para isso, temos outra regra de boa revisão. Se você examinou o PR até o final, ele não possui conflitos e não possui o status "em trabalho" - significa que você deve ter uma reação: "em alta" ou "para revisão". Se você deixou comentários, mas não indicou sua posição, significa que não assistiu completamente ao PR.
Além disso, há uma responsabilidade pessoal adicional por suas solicitações de piscina. O que isso significa?
Você fez o layout, tudo está de acordo com o layout, tudo é bonito, mas não há funcionalidade. E é impossível lançar um produto desse tipo no prod. Portanto, você não pode congelar no desenvolvimento. E você tem relações públicas abertas, existem aruvs e parece que você fez seu trabalho. Além disso, o desenvolvedor vem até você e diz: "Vamos aguardar alguns dias, carregarei a lógica diretamente em sua filial - e imediatamente trabalharei o recurso e é relegável?" Mas não! Então isso não funciona. E não deveria.
O trabalho não é considerado concluído até que o seu PR com layout não seja extinto. O que fazer em tal situação? Sim, é muito simples: o desenvolvedor cria seu próprio ramo, onde planeja escrever lógica, e nós imitamos o layout em seu ramo. Lucro
Cada tipógrafo monitora independentemente seus PR-s e lida com essas situações: quando não há lugar para congelar, as compilações não são coletadas, a empresa decidiu adiar a data de lançamento e assim por diante. Seu trabalho não foi concluído até que o PR esteja morto.
Periodicamente, organizamos uma pesquisa sobre telefonemas: quem tem quantos PRs abertos e quantos PRs precisam ser revistos. Os números são consistentemente menores que 10, e nos esforçamos para ficar menores que 5. Essas pesquisas confirmam que os lembretes automáticos no bate-papo ainda estão funcionando e que os funcionários estão respondendo a eles.
Agora, existe a sensação de que o trabalho foi desenvolvido muito bem. Você pode observar e ver infinitamente como as tarefas são transferidas de um status para outro (a propósito, seguimos rigorosamente isso), mas e o desenvolvimento? Tabelas de composição? Não sabe que a web não pára?
Desenvolvimento
Para que a equipe se desenvolva não apenas em termos de experiência entre os projetos, mas também em termos de habilidades, temos um dever semanal especial chamado Bandeira Verde. Se você é uma bandeira verde nesta semana, gasta tempo todos os dias procurando informações úteis sobre composição tipográfica, abordagens ou apenas tecnologias e lança links para artigos em nosso bate-papo particular. Isso geralmente é feito pela manhã ou imediatamente após o almoço.
As informações são obtidas sobre seus recursos favoritos, no mesmo "Habré", por exemplo. Isso é conveniente o suficiente, porque você sabe que seu colega lança links para os principais artigos do bate-papo todos os dias e só precisa lê-lo à noite depois do trabalho.
Vale a pena mencionar imediatamente: apesar de todos apoiarem essa atividade, muitos esquecem de fazê-la diariamente. Por isso, introduzimos outro dever, também semanal, que visa motivar a bandeira verde a não esquecer nossos deveres. E se você ainda esquecer a bandeira verde, o inspetor poderá retirar as informações de si mesmo. Curiosamente, mas essa abordagem funciona sem falhas e, às vezes, os dois atendentes lançam validade no chat.
Se você tem medo do número de deveres, tudo não é tão ruim. Estável Um funcionário tem um dever - este é o projeto no qual ele trabalha. E periodicamente é adicionada uma segunda inspeção - a bandeira verde ou o motivador da bandeira verde - que, de fato, é apenas uma formalidade.
Sumário
Então, reunimos do zero uma equipe de layout distribuída e, o mais importante, de trabalho. Vamos lembrar o que nos ajudou:
- O bate-papo privado permite que você resolva rapidamente todos os problemas emergentes.
- As negociações diárias ajudam você a acompanhar quem está fazendo o que e entender o quadro geral.
- As regras fixas de trabalho e a estrita adesão a elas permitem manter a consistência do código em todos os projetos.
- Os turnos contínuos de duas semanas permitem que você esteja no contexto de todos os projetos e forneça uma distribuição automática justa de tarefas.
- A revisão do projeto permite garantir a qualidade do resultado que chega ao cliente.
- Garantimos que a revisão seja realizada regularmente e que seu trabalho inacabado não se acumule.
- O diário responsável lança novos artigos no bate-papo para desenvolvimento, discute novas abordagens e práticas, tenta, aplica.
Tudo isso nos ajuda a fechar tarefas e fornecer layout para toda a unidade. E quais atividades estão em suas equipes?