10 tipógrafos para 30 equipes. Você é doido?

Olá pessoal! Meu nome é Kostya e sou chefe do departamento de layout da Wrike .
Atualmente, existem 10 pessoas trabalhando em nosso departamento, e todos esses caras vieram para a empresa em momentos diferentes, eles têm experiências e tarefas diferentes em equipes separadas. Ao mesmo tempo, todos os funcionários são excelentes especialistas, que juntos com dez conseguem cobrir as necessidades de layout de todo o produto.

Neste artigo, quero falar sobre quais práticas nos ajudam a alinhar o nível técnico geral da equipe, aderindo às mesmas abordagens no trabalho, e oferecer oportunidades de desenvolvimento para que eles possam melhorar e melhorar a interface do nosso produto.

Para quem tem muitas letras, há um vídeo .



E agora um pouco de contexto. Somos uma empresa de produtos Wrike dedicada ao desenvolvimento de um único produto. Este é um aplicativo de página única (SPA) para colaborar em tarefas e projetos. No total, a empresa tem mais de 700 pessoas e mais de 300 engenheiros estão trabalhando no desenvolvimento. Todos os funcionários são divididos em 30 equipes de produtos - cada um deles trabalha de acordo com a metodologia Scrum e é composto por diferentes especialistas: back-end, front-end, testadores, designers de layout, designers de UX, etc. Cada equipe trabalha em seu próprio produto. Todas essas peças são montadas em um grande produto, usado por mais de 16 mil empresas em todo o mundo.

O produto é tão grande e complexo que é importante distinguir claramente entre desenvolvedores Frontend que criam lógica de negócios no cliente e desenvolvedores de UI, em essência, codificadores que lidam apenas com o layout das interfaces, mas com imersão máxima e, consequentemente, , com a máxima qualidade.

Ao mesmo tempo, não acreditamos que o designer de layout seja um estágio intermediário de desenvolvimento no desenvolvedor Frontend. Para nós, esse é um ramo separado do desenvolvimento, com sua própria pilha de tecnologias e suas próprias complexidades. Nem todo designer de layout deve poder programar, mas nem todo desenvolvedor de Frontend deve ser capaz de digitar.

Apesar de apenas 30 equipes trabalharem no Wrike, codificadores de dez atendem às necessidades de apenas 20. O fato é que nem todas as equipes trabalham em tarefas para alterar a interface; portanto, apenas 20 delas estão "armadas" com seu designer de layout permanente.

A equipe do Wrike é distribuída, temos vários escritórios em todo o mundo: de San Diego a Voronezh. O principal centro de desenvolvimento está localizado em São Petersburgo, parte do empreendimento está em Voronezh, e agora é aberto um escritório em Praga, onde algumas das equipes de produtos se moverão.

Quando um número tão grande de pessoas trabalha em um produto em diferentes equipes, cidades e países, pode ser difícil manter uma abordagem uniforme, os engenheiros têm o mesmo nível e, consequentemente, consistência e qualidade igualmente alta do código. Se você não prestar atenção especial a isso, uma variedade de problemas poderá surgir.

Imagine que você é um tipógrafo e trabalha em sua equipe de produtos. Em um belo dia de maio, caras de outra equipe procuram você e pedem ajuda com urgência: o designer de layout adoeceu alguns dias antes do lançamento importante e ele precisa ser substituído rapidamente, tendo concluído tudo o que não tinha no caminho. Você não está muito ocupado no momento e concorda em ajudar: leva apenas alguns dias. Em seguida, você baixa o repositório em que seu colega trabalhou e ... afoga-se por uma semana, apenas para descobrir o que está acontecendo lá. Noites sem dormir, prazos rasgados e um tique nervoso são dados como bônus.

Ou pior: você é o mesmo codificador doente. E, saindo da lista de doentes, você atualiza seu repositório e recebe 28 confirmações de seu colega, que destroem completamente a arquitetura esbelta estabelecida desde o início. Porque Porque seu colega trabalhou duro à noite sem conhecer suas idéias e a capacidade de sincronizar com o autor. E, ao que parece, a tarefa atual está de alguma forma concluída, mas desenvolver ainda mais esse código será um pesadelo. Tudo precisa ser refeito, e é bom que você possa explicar à equipe e colocar mais uma semana de trabalho no que parece ter sido feito.

Trabalho com desenvolvimento web há algum tempo: trabalhei como desenvolvedor e gerente. Ele trabalhou em estúdios da web, agências, produção de terceirização e agora trabalho em uma equipe de produtos. Eu já vi tudo, vi situações semelhantes com a pressa e em empresas muito menores do que a Wrike. E, portanto, estou muito feliz que, no Wrike, pelo menos em termos de desenvolvimento da interface do usuário, não exista essas situações e não possa existir, e estou pronto para compartilhar práticas que nos ajudem a evitar isso.

Em geral, se você pensar bem, fica claro que tudo está nas pessoas e nos processos. São as pessoas que escrevem código, são elas que constroem processos e de alguma forma interagem. As pessoas são uma fonte de soluções e uma fonte de problemas. E se estamos falando de engenheiros, tudo parece ser simples. Para não ter problemas, algumas condições devem ser observadas:

1. Todos os caras devem ser igualmente de alto nível. Todo mundo usa todo o conjunto de tecnologias necessárias, conhece todos os pontos fortes e as limitações, é versado nos processos e adota as mesmas abordagens. Então, de fato, você pode dar a tarefa a qualquer engenheiro, e ele a resolverá, assim como a qualquer outro colega;
2. Todo mundo escreve código igualmente bem. Bem, ou pelo menos da mesma forma. Então, de fato, quando combinado com o primeiro parágrafo, obteremos um código consistente e bem mantido com o qual qualquer membro da equipe pode trabalhar;
3. Todo mundo sabe quem faz o quê. Isso reduz o limiar de entrada ao alternar entre tarefas e, de fato, mesmo que alguém fique doente ou "caia" no fluxo de trabalho por qualquer outro motivo, qualquer um dos colegas estará disponível: isso reduz a probabilidade do chamado fator de barramento;
4. Os membros da equipe “compartilham brotação” O número de equipes está crescendo, assim como a necessidade de engenheiros. Já é difícil contratar pessoas que correspondam aos três primeiros pontos, por isso seria bom se os caras existentes pudessem compartilhar brotações ou clonagem, mantendo o conhecimento atual. Então sim, não haverá problemas com a escala;
5. Ensine todos a voar. Para uma empresa com vários escritórios em diferentes países, é necessário poder reunir pessoas de escritórios diferentes em um só lugar, porque o valor da comunicação não verbal para estabelecer a comunicação dificilmente pode ser superestimado. E seria legal se os caras, quando precisassem sincronizar com alguém, pudessem "voar" para outro escritório, como nos quadrinhos. Então, talvez, não haverá problemas com a distribuição de equipes em todo o mundo.

E se, de alguma forma, tudo isso é implementado em um engenheiro, chamá-lo de "designer de layout" está de alguma forma errado, e um título como "designer de layout universal no vácuo" é melhor.

Parece que é impossível cumprir todos esses pontos, especialmente os dois últimos. Mas nós, no departamento de layout da Wrike, estamos perto disso. E agora vou falar sobre sete práticas que nos ajudam a estar o mais próximo possível do ideal pelo qual nos esforçamos.

1. Lista atual de competências

Se sabemos quais tarefas devem ser resolvidas, precisamos entender quais competências são necessárias para resolvê-las. Obviamente, seria bom que todos soubessem tudo no mundo, mas objetivamente isso é impossível e vale a pena destacar a lista mínima de conhecimentos que pelo menos alguém do departamento deve ter e melhor para todos.

O que isso dá? Requisitos claros para os candidatos - quanto mais o conhecimento dele corresponder à lista de competências necessárias, melhor.

Como fazer as pazes? Em algum momento, reunimos em todo o departamento e, em algumas reuniões, escrevemos no papel todas as tecnologias que já estamos usando ou que gostariam de estudar e começar a usar no futuro. E com a ajuda da facilitação, chegamos a uma lista de competências com as quais todos concordam.

Como resultado, nossa lista de competências contém coisas muito abstratas, por exemplo, a capacidade de encontrar rapidamente informações e tecnologias muito específicas, até os comandos específicos do utilitário de console git, que achamos que deveria poder usar.
Ao mesmo tempo, é completamente normal que em um momento apenas uma ou duas pessoas em um departamento tenham uma das competências - nesse estágio, o principal é que pelo menos alguém possua esse conhecimento; caso contrário, o departamento enfrenta tarefas que ninguém incapaz de resolver.

Depois de concluir a lista completa de competências, agrupamos-as em 13 direções. Aqui estão elas:

• A capacidade de pesquisar no Google;
• Ambiente (ferramentas, git, servir, etc.);
• HTML
• CSS
• Abordagens gerais (HTML / CSS);
• Kit de interface do usuário;
• Scrum;
• Angular + Dardo;
• Revisão de código;
• JS;
• Noções básicas de programação;
• UI / interfaces;
• Teclas de atalho

E se o mesmo HTML / CSS são padrões comuns do setor, e podemos esperar que os candidatos estejam familiarizados com eles, houve coisas bastante específicas. Por exemplo, nossa biblioteca interna do UI Kit. Ou nossas ferramentas específicas internas, recursos do ambiente, recursos de abordagens para resolver problemas específicos etc. O mesmo Dart Angular (escrevemos o front end do produto no Dart) é algo raro, poucas pessoas trabalharam com ele e esperavam que pelo menos um desses padrões fosse familiar para um candidato em potencial - pelo menos ingênuo. Acontece que, mesmo que contratemos um especialista experiente, ele ainda não saberá boa parte do que consideramos necessário para a conclusão bem-sucedida de nossas tarefas. Acontece que contratar e adaptar uma nova pessoa a uma equipe é sempre um pouco de treinamento. E quanto mais conhecimento é acumulado, o treinamento é mais complexo e demorado.

Acontece que é simplesmente impossível encontrar uma pessoa que 100% atenda aos nossos requisitos de conhecimento técnico, e precisaremos aprendê-la. Portanto, um iniciante deve ter certas habilidades de aprendizado. E esses são recursos pessoais, as chamadas Soft Skills.

Quando o departamento e o produto são pequenos e o conhecimento acumulado é pequeno, é vantajoso contratar pessoas com alto conhecimento para compartilhá-lo em equipe. E aqui já o Hard Skills sai por cima.

Quando o departamento cresce e, ao mesmo tempo, aumenta a quantidade de conhecimento acumulado sobre o produto, torna-se inútil contratar crianças com vasta experiência, porque será mais difícil para elas se adaptarem a novas realidades difíceis de mudar rapidamente. E aqui é útil contratar profissionais que, mesmo que não possuam muita experiência técnica, mas que possam se adaptar e aprender rapidamente as tecnologias necessárias. E o Soft Skills vem à tona - a saber, alta capacidade de aprendizado, boas habilidades de comunicação. E é importante que uma pessoa compartilhe valores já estabelecidos e fortaleça a equipe, e não comece a brigar com ela. É sobre o chamado Ajuste Cultural.

É importante que, após ingressar em uma equipe, uma pessoa o mais rápido possível tenha um entendimento de tecnologias e processos e comece a trazer benefícios. E isso nos leva a uma segunda prática importante:

2. Integração com treinamento integrado

Já decidimos que simplesmente contratar pessoas experientes não é suficiente e, imediatamente depois que uma pessoa vai trabalhar, precisamos ensinar rápida e efetivamente o que ela não conhece atualmente. E não importa se isso é algo mundano, como flex ou grid, ou alguma ferramenta específica com a qual era simplesmente impossível encontrar fora do Wrike.

Para fazer isso, usamos o Onboarding - do inglês “on-board” - o processo de adaptar uma nova pessoa a uma equipe. Mas, na Wrike, essa não é apenas uma história sobre onde um recém-chegado tem um emprego e onde examinar suas tarefas. Percebemos que para nós a integração é como cursos de educação continuada - um tipo de treinamento por vários meses: com uma avaliação do nível atual, um plano de treinamento, um mentor-mentor, vários treinamentos sobre o produto, tecnologias e processos. De acordo com os resultados da integração, esperamos que uma pessoa aprenda tudo o que é necessário para concluir suas tarefas e se torne o mais próximo possível de suas habilidades até mesmo dos caras mais experientes do departamento.

Em geral, o processo de integração é um tópico para um artigo separado, mas, por enquanto, quero me concentrar em uma coisa importante: a rosa das competências.

Com base nos grupos de competências que formulamos anteriormente, podemos avaliar qualquer funcionário ou mesmo candidato em cada direção e criar um diagrama radial:



Cada raio é um certo grupo de habilidades. O ponto principal é a porcentagem de tecnologias e abordagens dominadas inerentes a esse grupo. Quanto mais uma pessoa sabe e sabe como, mais próximo seu diagrama do círculo ideal. Quem tem absolutamente todas as habilidades da nossa lista de competências é o designer de layout muito esférico no vácuo que precisamos.

É importante entender que esse gráfico (também conhecido como a rosa das competências) não é usado para análise de desempenho, ou seja, não o usamos para entender quem é um bom designer de layout e quem é ruim. Não existe um nível mínimo em cada uma das áreas abaixo das quais é impossível cair. Este gráfico fornece uma compreensão de onde uma pessoa tem pontos fortes e onde estão os pontos de crescimento. Estamos preparados para o fato de que todos no departamento não sabem algo, especialmente se for iniciante. Mas, olhando para a rosa das competências, é fácil entender o que as coisas devem ser feitas em primeiro lugar.

Quando um recém-chegado chega até nós, uma rosa é construída para ele e eles, juntamente com seu mentor, elaboram um plano de treinamento por 2 a 3 meses, movendo-se ao longo do qual uma pessoa é bombeada e se aproxima do ideal desejado.

E, de acordo com os resultados, depois de passar por esse treinamento, a rosa está sendo reconstruída e o progresso está se tornando evidente.



Não esperamos 100% de resultados em cada direção, é importante para nós que haja um progresso significativo. E, de fato, esse diagrama pode ser usado mesmo após a conclusão da integração, para não ficar parado e se desenvolver ainda mais. Alguém pode bombear suas próprias direções de interesse em até 100% e ainda mais, e alguém pode adicionar uma nova direção e evoluir de um tipógrafo para alguma área adjacente. Também temos esses exemplos e práticas.

O que isso dá? Um plano de desenvolvimento claro para iniciantes. Assim, todos chegamos a um único nível, minimizando a diferença entre os "antigos" e os "recém-chegados".

Além disso, isso reduz os requisitos para os candidatos: se você ainda treina, não é a mesma coisa para quê? Como resultado, não temos requisitos realmente obrigatórios para Hard Skills para os candidatos. É claro que não podemos contratar pessoas sem conhecimentos básicos, mas muito pode ser aprendido no estágio de integração. O principal é que uma pessoa é capaz, e o resto é um negócio.

Então, sabemos quem estamos procurando, quais habilidades são necessárias e como treiná-las, mas esse conhecimento é relevante hoje. E o trem da frente corre a toda velocidade, manchando todos os que tropeçam e acompanham os trilhos. E precisamos de algum tipo de processo de introdução de novos conhecimentos para que todo o departamento não fique atrás dos requisitos modernos. E isso nos leva a uma terceira boa prática:

3. Atividades regulares de treinamento

Para acompanhar o mundo moderno, é importante monitorar o que está acontecendo nele. Vá a conferências, leia artigos especializados, experimente novas tecnologias e implemente-as em seu trabalho.

Seria estranho arrastar todos para todas as conferências e cursos disponíveis, isso não é eficaz. Mas um dos caras, de uma forma ou de outra, está estudando algo por conta própria ou com o apoio do Wrike - enviamos para conferências, pagamos por cursos especializados e geralmente apoiamos de todas as formas aqueles que desejam bombear. E se em todo o fluxo de informações for possível buscar algo útil para si, seria bom levá-lo ao departamento e compartilhar conhecimento com todos. Para isso, eventos regulares de treinamento interno nos ajudam. Mas como entender quem e o que todo o departamento poderia ensinar? A mesma rosa de competências nos ajuda nisso. Mas não no contexto de cada funcionário, mas no contexto de todo o departamento.



Observando esse gráfico, é fácil destacar um especialista em alguma área e pedir para compartilhar seu conhecimento com todos os outros.

Você também pode ver que, apesar de termos determinado um certo nível de conhecimento em uma das áreas, ninguém no departamento tem 100% de conhecimento. E é uma ocasião para atrair um especialista externo que realizará uma oficina ou palestra para nós e aumentará o nível geral de conhecimento em todo o departamento. Por exemplo, devido à necessidade de aprender o básico da linguagem Dart, encontramos um mentor na empresa - um desenvolvedor forte que conduziu um curso de palestras sobre Dart para todo o departamento de layout. Isso não nos fez desenvolvedores, porque não havia essa tarefa, mas pelo menos agora entendemos melhor o front-end. Ou talvez alguém, tendo sentido a nova tecnologia, pense em como treinar novamente na EF, o que também é bom.

Tudo o que resta para nós é revisar regularmente a lista de nossas competências, complementando as novas tecnologias relevantes. Em seguida, a rosa será reconstruída e veremos o nível geral do departamento, seremos capazes de gerenciá-la e nunca ficaremos atrás do mecanismo de front-end.

Portanto, temos um conjunto de especialistas legais que são aproximadamente iguais em força e não ficam atrás das tendências atuais. E sabemos até como reabastecer suas fileiras. Como agora para sincronizar seu trabalho? A quarta prática importante nos ajuda com isso:

4. Revisão cruzada obrigatória

Deixe-me lembrá-lo de que todo o nosso trabalho é realizado em equipes de produtos. E cada equipe cujas tarefas estão associadas à alteração da interface possui seu próprio tipógrafo permanente. Um tipógrafo pode ter vários comandos, mas apenas se não o carregar a 100%. E se você deixar o especialista sozinho, então, mais cedo ou mais tarde, ele cria sua própria maneira de escrever, que o resto nunca saberá.

Para que isso não aconteça e as mesmas tarefas sejam resolvidas praticamente da mesma forma, cada tarefa e a Solicitação de mesclagem passam por um código de revisão obrigatório.

É importante olhar para a revisão de código, não tanto quanto a função de controle, para que ninguém coloque algo ruim no mestre, mas no estágio em que dois engenheiros de equipes diferentes, com antecedentes e tarefas diferentes, concordaram em como resolvê-lo. um ou outro problema.

O que dá uma revisão cruzada?

Na fase de revisão, você pode obter uma visão externa - como a tarefa pode ser executada melhor, o que reduz o número de erros e torna o código consistente. Também é um processo de aprendizado mútuo - não apenas o autor do código passa na "validação" do revisor, mas também pode ver como o problema foi resolvido e colocá-lo em serviço. E assim, através do processo de revisão cruzada, viagens comuns são desenvolvidas e distribuídas por toda a empresa.

Tendo desenvolvido abordagens comuns, seria bom salvá-las em algum lugar, para que os iniciantes possam obter esse conhecimento não apenas dos colegas, mas também de forma independente. Isso nos leva à seguinte prática importante:

5. Estilo de código e linting automático

É importante que o código seja consistente e consistente com as regras gerais desenvolvidas no departamento. O mais básico é o Codestyle comum a todos. É importante que essas regras sejam claramente fixas e acessíveis ao público para qualquer pessoa na empresa. Porque você nunca adivinhará com antecedência quem precisará trabalhar com seu código.

Melhor ainda, verifique se o código corresponde às regras fornecidas automaticamente verificadas pelo linter: as máquinas devem sofrer, não as pessoas. Por exemplo, desenvolvemos e implementamos linting para modelos de marcação e linting de menos arquivos.

O que o linting automático oferece?

Bem, primeiro, é banal escrever código - todos os erros são destacados diretamente no código, enquanto você ainda está no contexto. E não há necessidade de se distrair verificando o estilo do código: isso será feito pelo plugin do IDE.

Em segundo lugar, é mais fácil realizar e passar por uma revisão de código - no MR simplesmente não há erros e não pode haver erros de estilo de código e você pode se concentrar na essência da tarefa.

Em terceiro lugar, o linting automático no processo de escrever código também é uma maneira de estudar o estilo do código. Não importa se você está familiarizado com o estilo do código ou não, já no momento de escrevê-lo e, ainda mais, quando você tenta confirmar o código, o linter exibe uma lista de erros e links para as regras que eles violam exatamente na quantidade necessária aqui e agora . E assim, você inevitavelmente aprenderá o estilo do código por tentativa e erro.

Parece que, apesar de todos trabalharem em equipes diferentes e em tarefas diferentes, há muito em comum. E eles precisam ser capazes de coordenar: quem, o que e quando revisar, quem, quando, o que, quais regras introduzir no estilo do código e quais não, etc. Todas essas atividades precisam ser capazes de sincronizar. Outra prática importante nos ajuda com isso:

6. Suporte diário

O departamento não possui sprints e planejamento próprios (apenas equipes de produtos com designers de layout trabalham para eles), mas aprendemos algumas das práticas do Scrum. Nomeadamente, a reunião diária é uma reunião para a qual reunimos e discutimos questões prementes: discutimos tarefas concluídas e atuais e discutimos futuras. Isso é importante se apenas no contexto da sequência de tarefas da revisão e, como bônus, você pode discutir os problemas que surgem, pedir conselhos aos colegas ou compartilhar notícias de suas equipes.

É importante que o stand-up passe rapidamente, não mais que 15 minutos por dia. Porque mesmo 15 minutos por dia, multiplicados por 10 pessoas, custam de 40 a 50 horas-homem por mês. É como uma semana inteira do trabalho de uma pessoa. Portanto, o rally em si deve ser o mais curto e eficaz possível. E somente se houver questões que exijam uma discussão separada, elas ficarão fora da estrutura do Diário e serão discutidas separadamente pelas pessoas interessadas, sem perder o tempo de outras pessoas.

Utilizamos um quadro interativo com tarefas com as quais qualquer designer de layout pode trabalhar a qualquer momento, em qualquer cidade. No Daily, todos os que se reúnem em São Petersburgo em um gabinete na TV em que esse quadro é exibido e os que trabalham em outras cidades se conectam via Zoom. Além das webcams, isso dá o efeito de problemas de presença e distribuição que não experimentamos.

O stand-up diário nos fornece um certo espaço comum de informações onde qualquer pergunta sobre layout pode ser resolvida - basta perguntar em voz alta e a mente coletiva sintetiza a resposta, porque alguém já se deparou com isso. Ou algum grupo de interessados ​​pode ajudar a encontrar uma solução para uma nova tarefa estranha.

Assim, sabemos como contratar e treinar especialistas legais, sabemos como coordenar suas ações para manter um código de alta qualidade. Mas há uma emboscada - se uma pessoa quer se desenvolver como especialista e fazer seu trabalho bem, ela o fará, não importa o quê. Mesmo que todos esses processos não existam. Eles apenas ajudam. E se ele não quiser, mesmo os processos ideais e o super treinamento não farão a pessoa se mexer. Todos devem estar realmente envolvidos e interessados ​​no destino futuro deles, da empresa e do produto. E este é o último da lista, mas, na verdade, a prática mais importante:

7. Envolvimento de todos em projetos de departamento

Idealmente, cada funcionário deve ter um plano compreensível para o desenvolvimento de si mesmo e do departamento pelo menos no próximo trimestre. E é bom se todos tiverem isso na cabeça. Mas o fluxo de tarefas atuais nem sempre tem tempo para pensar sobre isso.

Para que ninguém se mantenha no nível atual e não "azeda" em sua equipe, introduzimos a prática de reuniões "individuais" regulares com seu líder ou líder de equipe. São reuniões nas quais você pode conversar sobre seu desenvolvimento, o desenvolvimento da equipe, departamento e empresa e o que você pode fazer por isso agora. Na reunião, você pode obter feedback sobre si mesmo e coordenar ações, ou sobre suas tarefas, sobre os processos na equipe ou departamento e, portanto, influenciá-los.

Além do 1: 1 regular, "projetos" foram bem conosco. De uma forma ou de outra, os processos e tecnologias no departamento precisam ser bombeados, algo novo deve ser introduzido e o antigo e o irrelevante devem ser descartados. Todos no departamento têm a oportunidade de propor uma mudança como, por exemplo, introduzir uma nova tecnologia. Ou recorte uma abordagem herdada que interfira na vida.

E, se essa mudança for realmente útil, qualquer pessoa poderá assumir o projeto para sua implementação. Isso significa que você realiza alguma pesquisa ou trabalho de forma independente, ou reúne uma equipe de projeto e gerencia suas atividades para atingir os objetivos do projeto. Freqüentemente, isso requer um estudo aprofundado de novas tecnologias ou a busca de respostas para perguntas anteriormente insolúveis.

Todos podem escolher por si mesmos o projeto que lhe interessa. Assim, uma pessoa se desenvolve em uma área de seu interesse e bombeia todo o departamento.

E uma vez por mês, para que o trabalho dos projetos seja transparente para todos, reunimos todo o departamento em estilo retrô e compartilhamos nossos sucessos ou oferecemos novos projetos.

Essas sete práticas nos permitiram contratar e integrar 6 designers de layout ao departamento e às equipes em um ano. No momento, isso é quase ⅔ de todo o departamento. Bom resultado.

E os vôos?

Não poderia prescindir da magia - tudo graças à magia da automação e à nossa fada das viagens Ane.
Se, por algum motivo de trabalho, você precisar estar em outro escritório, por exemplo, conversar pessoalmente, basta preencher um formulário especial diretamente no Wrike, indicar as datas e o objetivo da viagem. E no momento certo no correio haverá bilhetes de avião. Tudo o que resta é pegar um laptop, passaporte e não se atrasar para o voo. Portanto, nossos tipógrafos voam sem problemas :)

Mas e se sua empresa ainda não tiver essas práticas?

Se você é um líder de equipe ou líder, o conselho é muito simples: "Aqui está a lista de verificação, pegue-a e implemente-a". Acho que todo líder está interessado no crescimento de seus funcionários e na qualidade do código.

E se você é um tipógrafo simples ou mesmo freelancer, não precisa contar com o suporte "do ar"? Curiosamente, o conselho é exatamente o mesmo.

O truque é que a implementação de todas essas práticas não requer grandes investimentos ou custos de mão-de-obra, pode ser promovida “de baixo para cima” por iniciativa de funcionários comuns. O principal é que há um desejo de se bombear e melhorar o mundo ao seu redor.