Processos de construção do zero: do caos ao pedido

Neste artigo, falarei sobre a criação de fluxos de trabalho em um pequeno departamento de desenvolvimento da web. O departamento foi formado do zero e imediatamente iniciou um trabalho autônomo; portanto, tivemos que construir os processos de produção, pisar em todos os tipos de ancinhos e tirar as conclusões necessárias disso. Na esperança de que isso ajude alguém a economizar tempo, dinheiro e nervos, descreverei os problemas que enfrentamos e nossas opções para resolvê-los.

É importante notar que essa não é uma metodologia universal que pode ser implementada em qualquer equipe de desenvolvimento, e tudo será maravilhoso imediatamente. Essa é apenas uma mistura de técnicas conhecidas e experiência prática, que conseguimos ajustar efetivamente aos nossos recursos de desenvolvimento. Não existe uma solução única e simples para esse problema. Você sempre precisa aproveitar o tamanho e a experiência da equipe, as características do negócio, as especificidades dos projetos, etc.

Os dados iniciais de nosso departamento: uma equipe de produtos pequena (5 a 10 pessoas), parcialmente distribuída (alguns funcionários trabalham remotamente, outros no escritório) com clientes dentro da empresa. Projetos da Web. Não há especialistas em administração de sistemas no departamento, mas existem departamentos envolvidos na empresa.

Comunicação em equipe

Vamos começar criando uma comunicação eficaz dentro do departamento. Em qualquer equipe, é importante criar canais e formas de comunicação eficazes, mas quando a equipe se distribui, essa necessidade se intensifica. Atingiu sua nitidez máxima aqui, porque a equipe estava apenas parcialmente distribuída. Tivemos que aprender a mesclar o mundo dos escritórios e funcionários remotos.

A questão mais importante que encontramos são as discussões verbais. Os funcionários do escritório sempre têm a tentação de embalar rapidamente uma xícara de café e discutir o status do projeto. Entretanto, nesse caso, os trabalhadores remotos não poderão participar dessa discussão, portanto, não poderão contribuir com suas idéias e, na verdade, não saberão que algo está acontecendo. Como regra, isso resulta em uma dessincronização das ações da equipe, discussões repetidas devido ao surgimento de novos pensamentos e sugestões da parte distribuída da equipe e apenas um sabor desagradável.

Tornou-se claro que algumas coisas comuns importantes devem ser discutidas por escrito em bate-papos em geral ou em algumas chamadas de grupo.

Isso dá origem a outro problema muito comum que aparece nas equipes em que você precisa escrever muito - o problema da cultura da escrita. Você não pode simplesmente procurar um colega, puxar sua manga, desenhar algo em um guardanapo e adicionar gestos à sua história. Por um lado, isso complica o trabalho e, por outro, as pessoas desenvolvem a habilidade de escrever seus pensamentos de maneira compreensível e estruturada. Como resultado dessa abordagem, a documentação começou a ser melhor formalizada, as tarefas começaram a ser formuladas com mais clareza, todos começaram a pensar em como apresentar seus pensamentos de maneira que fossem compreensíveis para os outros desde a primeira leitura.

Tudo isso não significa que abandonamos completamente a comunicação pessoal, as chamadas de voz e vídeo. No entanto, estabelecemos como regra que os resultados de tais discussões sejam registrados por escrito, como um tipo de artefato de conhecimento, sempre disponível para todos.
Veja brevemente a lista banal de ferramentas com as quais resolvemos nossas tarefas de comunicação dentro da equipe.

Primeiro, começamos uma conversa no Telegram. Mas então, em conexão com o crescimento da equipe, percebemos que em um bate-papo já estávamos perto e mudamos para o Slack. Lá, dividimos o fluxo geral em canais temáticos e estabelecemos regras claras - por quais razões escrever para qual canal. Isso ajudou a evitar a mistura de informações úteis e inundações.

Além disso, a mudança para o Slack nos deu boas oportunidades de automação e integração com outros serviços, como um sistema de gerenciamento de repositório ou rastreador de erros.

• Chamadas de áudio e vídeo - Skype for Business.
• Realizamos tarefas em Jira.
• A base de conhecimento é armazenada no Confluence.

Planejamento, execução e controle de tarefas

Quando construímos as comunicações, o problema de definir, controlar e concluir tarefas dentro da equipe se tornou relevante (falarei sobre trabalhar com o cliente nesse sentido um pouco mais tarde).
Não tínhamos uma lista única de tarefas, suas prioridades, status de prontidão, etc. Em vez de um plano claro, transparente e rastreável, o planejamento e a execução espontâneos de curto prazo estavam presentes.

Para lidar com essa situação, começamos a usar um rastreador de bugs (na verdade, tentamos cinco deles). Esboços da direção geral do projeto começaram a aparecer, uma compreensão do estado em que certas tarefas e a visão geral como um todo apareceram. No entanto, enfrentamos o problema da falta de disciplina ao usar o rastreador de bugs, que começou a desvalorizar muitos de nossos empreendimentos. Nem todas as tarefas foram iniciadas no rastreador de erros, as existentes nem sempre foram atualizadas etc. Simplificando, a imagem do estado do projeto deixou de ser relevante e confiável.

Para combater isso, desenvolvemos e implementamos nossa própria cultura de gerenciamento de tarefas:

• O trabalho não deve ser executado até que a tarefa correspondente tenha sido iniciada. Isso ajuda a manter atualizado o histórico do projeto e o trabalho da equipe.
• Ao trabalhar com uma tarefa, é necessário alterar seu status em tempo hábil. No nosso caso, quatro status são suficientes: “A fazer” - o estado inicial da tarefa, “Em andamento” - a tarefa em andamento, “Em espera” - a tarefa que eles começaram a executar, mas o trabalho está suspenso (estamos aguardando algumas informações adicionais ), "Concluído" - a tarefa está pronta. A prontidão da tarefa deve, de alguma forma, ser confirmada pelo cliente ou gerente dentro da equipe.
• Com o tempo, o número de tarefas e projetos aumentou significativamente; portanto, dividimos a lista geral de trabalhos em subprojetos separados, e a tarefa deve ser iniciada de acordo com esta lista de subprojetos.
• A tarefa deve ter prioridade atribuída. Isso ajuda a entender quais tarefas em que ordem devem ser executadas para trazer o máximo benefício ao projeto.
• Tarefas revisadas periodicamente e suas prioridades. Como os projetos vivem e se desenvolvem, e os planos de negócios às vezes mudam com o tempo, algumas tarefas se tornam menos ou mais relevantes ou até exigem sua remoção.
• Algumas discussões importantes sobre tarefas que foram realizadas verbalmente ou por escrito no bate-papo exigem a solução final da tarefa em si, para que, quando a concluamos, sempre vejamos as informações mais relevantes sobre ela e seu histórico. Muitas vezes acontece que a declaração inicial do problema, após uma série de discussões, é transformada em algo completamente diferente, e precisamos monitorar isso.
• Se a tarefa for transferida de um grupo de especialistas para outro dentro da equipe, o grupo transferidor deverá fixar nela todos os artefatos de conhecimento necessários que devem ser transferidos para o próximo grupo. Por exemplo, uma equipe de design deve anexar modelos e toda a documentação necessária para o desenvolvimento antes de transferir a tarefa para a equipe de desenvolvimento. Isso evita perguntas desnecessárias, distrações e alternância de contexto.
• Anexar confirmações às tarefas. Usando algumas regras para nomear confirmações, anexamos automaticamente links a confirmações nas tarefas do GitLab. Isso ajuda muito no desenvolvimento para entender quem, o que, como e quando fez essa tarefa. E na direção oposta, por confirmações nomeadas corretamente, você sempre pode encontrar uma tarefa que contém o motivo das alterações feitas.

Comunicação com o Cliente

A próxima categoria de dificuldades que precisávamos resolver foi trabalhar com os clientes. A primeira coisa que tivemos que erradicar foi colocar palavras em palavras. Se introduzirmos a cultura da escrita dentro do departamento, chegou a hora de estendê-la aos contatos externos.

Não é segredo que outro gerente gosta de abordar o desenvolvedor, em palavras, dizer o que precisa ser feito, cutucar os dedos na tela para persuasão e sair, esperando que tudo seja feito bem e no prazo. Nessa situação, o gerente e o desenvolvedor podem ser substituídos por um proprietário do produto e um certo gerente da equipe de desenvolvimento que lidera todas essas tarefas. O resultado disso não será alterado.

Existem vários problemas com essa abordagem:

• O que é dito em palavras e gestos será esquecido (pelo menos parcialmente) sobre amanhã, na melhor das hipóteses, depois de amanhã. Não se trata apenas de pequenas coisas, mas do perigo de esquecer completamente a tarefa. Ao mesmo tempo, é impossível confirmar de qualquer maneira que você o colocou a alguém ou que alguém lhe prometeu fazer pelo menos alguma coisa.
• Geralmente, essa afirmação do problema é bastante caótica e não há detalhes profundos nela. Como resultado, é muito difícil esclarecer as informações ausentes.
• Como discutido anteriormente, a declaração do problema em palavras favorece a relutância corrompida em aprender a formular seus pensamentos por escrito, para que outras pessoas entendam.

Quando você tem muitos clientes e cada um tem suas próprias características, é difícil criar uma única ordem de trabalho com todos. Idealmente, gostaríamos de trazer todos os clientes para um rastreador de erros, onde eles poderiam definir tarefas, definir prioridades, discutir detalhes, aceitar trabalho. Mas isso continua sendo uma tarefa impossível. No entanto, conseguimos encontrar um compromisso no qual as tarefas fluem juntas em um fluxo estritamente escrito para o nosso departamento de correio corporativo e, de nossa parte, o gerente as inicia e as conduz ainda mais no rastreador de erros, de acordo com as regras já estabelecidas em nosso país. As tarefas deixaram de ser perdidas, esquecidas, armazenadas na mente de pessoas específicas, discutidas pela composição incompleta dos especialistas necessários, etc.

Em seguida, enfrentamos mais um problema importante: é difícil para o cliente formular uma tarefa. O cliente nem sempre é competente o suficiente (ou melhor, quase sempre insuficientemente competente) na formulação de especificações técnicas para a equipe técnica. E isso é normal. O fator humano não pode ser ignorado: pode ser banal para o cliente ficar constrangido e desconfortável de chegar à equipe com uma solicitação quando ele próprio ainda não foi capaz de formulá-lo completamente. Um dos critérios de uma equipe profissional madura é a capacidade de ajudar o cliente a identificar seus problemas, requisitos e soluções.

Muitas vezes acontece que o cliente, em vez de vir com um problema, vem com uma solicitação para a implementação de uma solução que ele já inventou. Para não surpreender a nós mesmos ou ao cliente com os resultados do trabalho no ToR elaborado “em um guardanapo”, criamos uma lista de verificação básica de perguntas para o cliente. Já com base nessas respostas, é mais fácil para o cliente entender o que ele realmente deseja e para a equipe de desenvolvimento o que é necessário. E então é a vez de fazer algumas perguntas sugestivas para esclarecer ou identificar requisitos.

Portanto, antes da primeira reunião com o cliente, solicitamos que você preencha (o máximo possível) e nos envie esta lista de verificação para que depois não precise perder tempo com as mesmas perguntas, mas inicie imediatamente um diálogo proveitoso. Vale a pena notar que, ao interagir com o cliente, é importante não apenas esclarecer as respostas que ele forneceu, mas também com base no problema declarado, para ajudá-lo a identificar os requisitos que ele talvez não tenha pensado.

Lista de perguntas para o cliente:

• Qual é o objetivo do projeto? Que problema isso resolve? Que valor comercial possui?
• Essa é a única solução possível para esse problema? Caso contrário, que outras opções existem?
• Existem requisitos gerais que passam por todo o projeto? Por exemplo, se for uma loja on-line, deverá cumprir totalmente a legislação que rege o comércio on-line.
• Existem requisitos funcionais? O que uma seção deve fazer (página, projeto)? Por exemplo, a seção deve fornecer informações sobre os produtos da empresa e, por meio do formulário na página, coletar aqueles que desejam fazer perguntas sobre esse produto ou adquiri-lo.
• Existem requisitos não funcionais? Quão bem ele deveria fazer isso? Por exemplo, o tempo de abertura da página não deve ser superior a 5 segundos.
• Requisitos adicionais. Formato livre no qual você pode derramar a alma.

Outro problema que tivemos que enfrentar: tarefas vindas de todos os lados simultaneamente. Quando existem muitos clientes em projetos diferentes, todos querem dar à sua tarefa a maior prioridade. No caso ideal geral, provavelmente, esse problema não pode ser resolvido 100%. Como vivemos com isso? Com a introdução da disciplina na formulação e gerenciamento de tarefas, bem como alguns elementos das metodologias Agile, nosso conjunto de tarefas se tornou mais simplificado, transparente para um observador externo e, o mais importante, previsível. Estabelecemos pedidos e planos em nossa equipe e precisamos apenas fortalecer o feedback com os clientes. Ao discutir prioridades, prazos e planos, aprendemos a construir um diálogo argumentativo, em vez de nos jogar cegamente em tarefas e constantemente extinguir incêndios flamejantes (que nem sempre são relevantes e nem sempre são relevantes).

Além disso, como parte deste parágrafo, tentamos erradicar o “gerenciamento de gaivota” antipadrão clássico, quando o cliente ou gerente voava, “punha” tarefas - e voava com total confiança de que uma vez que ele definisse a tarefa, certamente obteria um excelente resultado. Como a prática demonstrou, o resultado dessa abordagem não foi o mais impressionante. Como lidar com isso? Também aqui não há conselho universal, frase mágica que mude o comportamento das pessoas. Para fazer isso, você precisa conversar, educar, explicar, mostrar, você pode dizer educar. Somente o trabalho educacional e exemplos positivos e muito visuais ou muito mensuráveis ​​(e de preferência ambos) positivos e negativos ajudarão a superar suficientemente a "gestão de gaivotas".

Dev vs Ops

E nossa última questão importante é o problema de comunicação entre os departamentos de Desenvolvimento e Operações.
Estamos diante de uma situação clássica em que os desenvolvedores não entendem muito bem como o servidor funciona e uma equipe de administração de terceiros não entende realmente como o aplicativo funciona. Cada dificuldade na junção dessas duas esferas nos foi dada com dor e muito tempo. Era difícil até diagnosticar qual lado do problema:

• Você programou lá!
• Não, você tem algo com o servidor lá!

Nesse caso, nos ajudou a aparecer um desenvolvedor na equipe que era bem versado em administração. Ele conseguiu conversar com cada grupo em seu idioma e diagnosticar todos os problemas de ambos os lados. Discrepâncias começaram a declinar, mas continuamos ligados a esse homem. Para resolver todos esses problemas, ele começou a ajudar os administradores a entender como o aplicativo funciona e os programadores - o que está acontecendo no servidor. Acrescentamos à explicação da documentação da gravação de voz e obtemos não apenas o conhecimento de toda a equipe, mas também o trabalho mais coordenado dos departamentos de Desenvolvimento e Operações. Sim, em grandes seções da sangrenta empresa, há equipes especiais e pessoas qualificadas que configuram tudo para que os desenvolvedores nem saibam como e onde o trabalho deles funciona no servidor. No entanto, em equipes pequenas, seria bom desenvolver esse nível de competência nas pessoas, além de ter pelo menos um funcionário que já esteja bem desenvolvido nesse sentido.

Desenvolvimento

Paralelamente a tudo isso, iniciamos o desenvolvimento de uma cultura de desenvolvimento.
Não vou me concentrar na parte técnica, e agora ele já é um padrão de fato e quase todo mundo não entende como é necessário um sistema de controle de versão, CI / CD e outras ferramentas de desenvolvimento, montagem e implantação. Vou me debruçar apenas em momentos suaves de desenvolvimento.

• Codestyle É muito importante desenvolver e aprovar explicitamente as regras para o design do código. Em primeiro lugar, é esteticamente agradável ver um único olhar harmonioso no projeto, em vez de um zoológico de diferentes estilos e padrões. Em segundo lugar, aumenta a legibilidade do código e, como sabemos, na maioria das vezes o programador não escreve seu código, mas lê o de outra pessoa.
• A nomeação é confirmada . Introduzimos certas regras para nomear commits, de modo que, pelo nome do commit, ficou claro quais alterações foram feitas, por quem e dentro de qual tarefa.
• Revisão de código . As especificidades de nossos projetos e da equipe são tais que não temos uma revisão obrigatória de código, sem a qual é impossível despejar nosso código em produção. No entanto, adotamos a regra de que pelo menos uma pessoa analisa o código que um colega está pressionando. Isso ajuda a perceber as deficiências, a introduzir idéias alternativas e a manter-se a par de todas as partes do sistema. A revisão de código se tornou especialmente relevante com o crescente número e complexidade de projetos, e é por isso que todo desenvolvedor não tem mais tempo para trabalhar em todos os projetos o suficiente para entender todos os detalhes.
• Alinhando a arquitetura dentro da equipe desde o início . Muitas vezes acontece que, em um esforço para criar um recurso mais rapidamente, o front-end começa a fazer algo próprio, o back-end começa rapidamente e, em seguida, verifica-se que ele se integra com grande dificuldade ou não se integra. No desenvolvimento de grandes recursos, discutimos em conjunto previamente a arquitetura, os formatos de troca de dados etc. Como resultado, a integração deixou de ser longa e dolorosa.
• Desenvolvimento Orientado a CV . Esse é um problema no qual os desenvolvedores arrastam novas tecnologias (novas, elegantes, com altos salários) para o projeto, não por causa do projeto, mas por uma marca no currículo. Estamos abertos a novas tecnologias e tentamos desenvolver tecnologicamente nossos projetos, no entanto, é importante manter um equilíbrio no qual haja progresso tecnológico e projetos concluídos com sucesso dentro de um prazo razoável. Duas coisas são importantes neste tópico escorregadio: que o cliente não cumpra os prazos para que os desenvolvedores não tenham folga e que a equipe de desenvolvimento (ou, pelo menos, o líder da equipe ou equipe técnica competente) se preocupe não apenas com o desenvolvimento do perfil do LinkedIn, mas também com o bem-estar do projeto em geral

Refatoração, dívida técnica e o princípio da melhoria contínua

Nosso departamento começou a se formar em torno de uma frota existente de projetos feitos por terceirizados. Naturalmente, não havia documentação, ninguém seguiu a relevância e a qualidade do código. Como entendemos que ainda precisamos trabalhar com ele, manter e desenvolver por um longo tempo, foi decidido dedicar parte do tempo a colocar as coisas em ordem no projeto - refatoração, exclusão de códigos irrelevantes etc.

Como o projeto era grande, o nível de entropia também era alto. Percebemos que em uma sessão é impossível superar tudo fisicamente e moralmente desistir da perspectiva de um trabalho tão colossal. Decidimos aplicar o princípio japonês de melhoria contínua "kaizen". Dividimos a dívida técnica em muitas partes pequenas e pouco a pouco, mas as fechamos regularmente, modificando e melhorando continuamente os projetos e o trabalho da própria equipe.Moralmente, isso não causou nenhum inconveniente, mas, ao mesmo tempo, não teve um impacto significativo no desenvolvimento de novas funcionalidades e cobertura de requisitos de negócios. Depois de um ano e meio, descobrimos que a antiga dívida técnica foi completamente paga e isso abriu oportunidades para desenvolvermos a funcionalidade de um nível fundamentalmente novo de complexidade e importância.

Obviamente, isso não significa que agora não temos dívida técnica. À medida que os projetos vivem, evoluem, crescem e se desenvolvem, certamente aumenta. No entanto, monitoramos cuidadosamente, colocamos em um conjunto especial de tarefas e dedicamos regularmente algum tempo a pagar. Esse trabalho contínuo com dívida técnica nos permite encontrar um equilíbrio entre o desenvolvimento de novas funcionalidades e o suporte de alta qualidade para os antigos.

No nosso caso, nós, os desenvolvedores, fomos capazes de explicar e mostrar aos negócios a importância de pagar dívidas técnicas. Como fizemos isso? Na prática, demonstramos situações nas quais, se você não refatorar ou realizar outras alterações estruturais no projeto atual, desenvolver novas funcionalidades ou alterar a antiga será impossível em princípio (ou possível, mas várias vezes mais lento).

Implementar metodologias ágeis

A implementação de algumas idéias das metodologias ágeis nos permitiu aumentar a transparência do nosso trabalho, tanto dentro da equipe quanto para os negócios, para tornar o desenvolvimento mais previsível e flexível e o resultado mais estável.

A primeira coisa que fizemos foi organizar stand-ups diários dentro da equipe. Como a equipe está distribuída, o Slack atribuiu um canal separado para isso, no qual cada funcionário escreve três pontos todas as manhãs: em quais tarefas ele trabalhou ontem, no que planeja trabalhar hoje, existem problemas que o impedem. É proibido inundar neste canal, discutir questões ou problemas de alguém. Este canal é estritamente para agregação de informações sobre o estado das coisas. As discussões restantes devem ser conduzidas nos canais temáticos apropriados. Isso permitiu que cada pessoa da equipe entendesse o que seus colegas estão fazendo, o que está acontecendo com o projeto em geral, quem pode e deve ser ajudado. Se sem problemas os problemas foram abafados e, depois de muito tempo, subitamente se descobriu que a tarefa ainda não estava pronta, agora está claro quem precisa de ajuda,o que precisa ser feito para tornar a equipe mais eficiente.

Em seguida, decidimos desenvolver sprints. Toda sexta-feira, no final do dia, realizamos uma retrospectiva do sprint, analisamos quais tarefas foram planejadas, o que está pronto, o que não está pronto e, se algo não está pronto, por que isso aconteceu. Pensamos em quais problemas tivemos e o que poderíamos fazer para evitar dificuldades semelhantes no futuro. Planejamos um sprint para a próxima semana com base na carga de trabalho de diferentes áreas dentro das prioridades da equipe e dos negócios. Como resultado, no início da semana, todos os desenvolvedores sabem o que fazer e em que ordem, e a empresa sabe quais necessidades serão atendidas no futuro próximo e já pode formar sua própria "lista de desejos" para os próximos sprints. Vale dizer que não somos poupados de tarefas repentinas que podem atrapalhar nossos planos de sprint.Nesse caso, você precisa agir com base na natureza específica do trabalho: com que frequência essas tarefas surgem? Quanto? Isso pode ser previsto? Em nosso caso específico de desenvolvimento, calculamos experimentalmente quanto tempo, em média, cai em tarefas não planejadas e tentamos estabelecer essa margem no sprint. Separadamente, vale a pena notar que, depois de iniciar o trabalho em sprints, fomos capazes de descobrir especificamente quanto trabalho nos é entregue em uma entrada não programada, analisar e reduzir esse valor, discutir cuidadosamente as prioridades com o cliente e mostrar claramente como o desejo momentâneo de obter o recurso mais necessário no momento afeta sobre a produtividade geral de toda a equipe.qual é o tempo médio para tarefas não planejadas e tente estabelecer essa margem no sprint. Separadamente, vale a pena notar que, depois de iniciar o trabalho em sprints, fomos capazes de descobrir especificamente quanto trabalho nos é entregue em uma entrada não programada, analisar e reduzir esse valor, discutir cuidadosamente as prioridades com o cliente e mostrar claramente como o desejo momentâneo de obter o recurso mais necessário no momento afeta sobre a produtividade geral de toda a equipe.qual é o tempo médio para tarefas não planejadas e tente estabelecer essa margem no sprint. Separadamente, vale a pena notar que, depois de iniciar o trabalho em sprints, conseguimos descobrir especificamente quanto trabalho nos é entregue em uma entrada não programada, analisar e reduzir esse valor, discutindo cuidadosamente as prioridades com o cliente e mostrando claramente como o desejo momentâneo de obter o recurso mais necessário no momento afeta sobre a produtividade geral de toda a equipe.como um desejo momentâneo de obter um recurso desnecessário agora afeta a produtividade geral de toda a equipe.como um desejo momentâneo de obter um recurso desnecessário agora afeta a produtividade geral de toda a equipe.

Também mudamos de lançamentos longos para lançamentos curtos. Anteriormente, recebíamos TK, semanas ou meses, realizamos todo um pacote de recursos e só então o mostramos ao cliente. Como resultado, muitas vezes acontecia que o cliente mudou de idéia ou não esperava exatamente isso e começamos a refazer tudo ou parte do que já havíamos feito. E fazer alterações em um grande conjunto de recursos já prontos é um prazer duvidoso. Agora, estamos demonstrando todos os recursos o mais cedo possível, para que o cliente tome uma decisão - se é isso que ele realmente queria ou se algo precisa ser mudado. Quanto mais rápido ele aprovar ou enviar para revisão, menos mão-de-obra investiremos; portanto, mais rápido o recurso entrará em produção. Como resultado, os recursos começaram a chegar à produção mais rapidamente, as hipóteses foram testadas mais rapidamente e o projeto foi mais rápido.

Fator de barramento

Como nossa equipe é pequena, imediatamente começamos a pensar nos problemas que poderíamos encontrar durante a rotação de pessoal. Pessoas específicas tornaram-se os únicos guardiões de algum conhecimento, os projetos expandiram-se o suficiente e, portanto, começamos a desenvolver uma cultura de armazenamento e gerenciamento de conhecimento.

A erradicação desse problema foi ajudada pelo acúmulo de artefatos de conhecimento que passaram das cabeças de pessoas específicas para o mundo físico escrito. Ou seja:

• Todo o trabalho é realizado apenas se houver uma tarefa no rastreador de erros. Isso permite que você faça um histórico completo das alterações no projeto.
• Se em algum lugar no bate-papo ou no comício discutimos as mudanças na tarefa, devemos refletir na própria tarefa o resultado dessa discussão.
• . , Gitlab. , .
• Confluence , - , .
• - postmortem « — — — ».

Ainda há boas práticas, nas quais, é claro, você precisa conhecer a medida e não elevá-la ao absoluto: se você for perguntado sobre alguma parte do sistema que apenas você conhece, é aconselhável escrever documentação sobre ela e responder com um link para ela. Portanto, você nunca terá que responder a essa pergunta novamente e perguntar a outras pessoas.

Esse método de manutenção de artefatos de conhecimento nos ajudou repetidamente a encontrar informações sobre as partes do projeto que de outra forma seriam necessariamente perdidas. E ele também reduziu significativamente os riscos para o projeto e a equipe durante a rotação de pessoal. O último exemplo: recuperamos rápida e facilmente informações sobre a lógica comercial, o princípio de operação e o método de implantação da ferramenta, realizado pelo funcionário que saiu há dois anos.

Se aplicarmos trabalho com stand-ups e sprints a essa técnica, o fator de barramento será reduzido ainda mais. Há pouco tempo, realizamos um experimento: um desenvolvedor estava de férias e outro desenvolvedor funcionou. Nesse momento, quando o primeiro saiu de férias, o segundo saiu de férias. A essência do experimento não foi escrever cartas explicativas, mensagens, não entregar o caso e ver como seria difícil para uma pessoa, após longas férias, entender o que estava acontecendo na sua ausência, o que mudou, exatamente como e o que planejava para o futuro. Como a prática demonstrou, visualizar o rastreador de erros, confirmações, documentação, stand-ups e sprints permitiu ao funcionário entrar no curso dos negócios com bastante facilidade e continuar seu trabalho autonomamente.

Conclusão

Concluindo, gostaria de observar que nenhum dos problemas acima foi resolvido imediatamente e sem falhas. A mudança organizacional é sempre um trabalho longo e metódico. Você não pode simplesmente dizer "agora fazemos isso" e torcer para que agora tudo seja diferente. Qualquer decisão que você tome, qualquer evento que você organize, exige controle, treinamento e iluminação das pessoas, tempo para adaptar a equipe a novos métodos e os próprios métodos a uma situação específica. Noto também que a imposição de uma metodologia às pessoas é um processo muito trabalhoso e ineficiente. As pessoas descansam, esquecem, talvez até sabotam.

Para que as alterações necessárias comecem na equipe, a própria equipe deve querer fazer essas alterações. É necessário monitorar como ela está, identificar áreas problemáticas, estar ciente desses problemas, encontrar soluções e só então implementá-las. Obviamente, nem todo membro da equipe deve e deseja fazer isso, mas se houver alguém que viu esses problemas e apresentou suas soluções, ele primeiro esclarecerá a equipe.

Compartilhe seu conhecimento, observações, experiência, discuta, mostre e prove onde estão os problemas agora e que medidas podem ser tomadas para resolvê-los. Somente dessa maneira as principais transformações organizacionais podem ser realizadas da maneira mais eficiente possível. Mesmo que você seja um líder e queira promover sua posição e sua decisão - tente fazê-lo da maneira mais convincente e convincente possível, economizando tempo na implementação e salvando a equipe da negatividade indesejada.

Postado por Evgeny Antonov, chefe do grupo de desenvolvimento de tecnologias positivas