Um funcionário que sabe muito, sabe como e está pronto para apagar qualquer incêndio em sua campina, é claro, muito bem. Mas se esse herói sai de férias ou até mesmo sai, tempos difíceis vêm. Acontece que é importante não apenas saber muito, mas também poder compartilhar esse conhecimento.
Aleksey Troshin (
morroz ) está na profissão há quase 20 anos, trabalha como gerente de projetos e produtos desde 2002. Durante esse período, ele trabalhou em várias empresas, liderou equipes de 2 a 150 pessoas e agora gerencia o desenvolvimento no FINAM. Aqui, Alex criou um sistema que ajuda não apenas a espalhar conhecimento, mas também a motivar os desenvolvedores a crescer na direção certa de negócios e equipe. No entanto, o sistema não é usado em todas as equipes. Porque Aprendemos sobre isso, bem como as abordagens usadas, sob o corte.
O artigo é baseado em um relatório de Aleksey Troshin no Saint TeamLead Conf, que conta como o conhecimento é disseminado no FINAM: como a força e a habilidade dos Jedi crescem, como os Padawans são treinados e o que acontece no lado sombrio da Força (onde seria sem ele).Equipe de Produtos e FINAM
Primeiro, falarei sobre alguns de nossos produtos para determinar o contexto da empresa.
Site Finam.ru - site número 1 sobre tópicos financeiros, contendo muitas seções diferentes com informações financeiras, além de serviços úteis, por exemplo, uma loja de ações on-line. Você pode, por exemplo, comprar uma parte da Apple e entregá-la a alguém no aniversário.
A plataforma de negociação FinamTrade , que também possui uma taxa de comissão zero para iniciantes.
Comon.ru - um sistema de repetição automática de transações de traders profissionais - uma solução para investidores iniciantes e aqueles que não têm tempo livre suficiente para criar seu próprio portfólio de investimentos.
Rede social para comerciantes e muito mais .
FINAM IT é de 150 pessoas divididas em 25 equipes. O desenvolvimento é apenas interno, quase não atraímos empresas de terceiros para nossas necessidades. A imagem do título mostra perfeitamente como tudo está organizado conosco. A composição das equipes pode ser diferente: algumas equipes têm um Dono do Produto, mas não há testadores, por exemplo, outros têm testadores, mas não há Dono do Produto, mas há analistas.
No desenvolvimento, usamos diferentes pilhas de tecnologia:
- Frontend: React.js, VUE.js.
- Idiomas: C #, PHP, C ++, Java, móvel.
- Bancos de dados: MSSQL, PostgreSQL, Oracle.
- Plataformas: SharePoint, 1C, Diasoft, MS CRM e muito mais.
Quando entrei na empresa, tentamos desenhar equipes, produtos e relacionamentos. O resultado foi um esquema tão complexo, em que os círculos indicam os produtos que estamos desenvolvendo:
Por cor, mostrei que as equipes estão organizadas de maneiras diferentes. Alguns fazem um produto, outros fazem vários produtos. E existem produtos que várias equipes estão desenvolvendo ao mesmo tempo (por exemplo, um back office interno).
Vou liderar minha história nos exemplos de duas equipes, chamando-as condicionalmente de equipe 1 e equipe 2.
Time 1
A primeira equipe desenvolveu um sistema de informação interno. Inicialmente, era assim:
- Um funcionário era especialista na versão atual da plataforma. Havia uma tarefa de transferir essa plataforma para novos trilhos, porque a versão antiga não era mais suportada.
- Adotamos um novo funcionário especialista na nova versão da plataforma. Ele estava envolvido em portar todas as funcionalidades para esta nova versão.
Time 2
A segunda equipe desenvolveu vários sistemas internos:
- Um funcionário é especialista em um sistema.
- Outro funcionário é especialista em outros sistemas.
- E alguns sistemas foram desenvolvidos pelos dois funcionários juntos.
Sobre especialistas
Não é por acaso que a palavra "especialista" está destacada no texto acima, e quero esclarecer quem é o especialista no contexto dessa conversa. Como mestre em Guerra nas Estrelas, essa pessoa tem o Poder: competência profunda em sua área de atuação, em tecnologia, no produto. Isso geralmente é conveniente para uma empresa, porque fornece um ponto de entrada: os especialistas são questionados sobre como fazê-lo ou quando isso será feito, se for uma questão de novas tarefas, ou eles perguntarão se algo quebrou ou não está funcionando corretamente.
Eu imagino um especialista como um Mestre Jedi do filme "Guerra nas Estrelas" - ele pode fazer qualquer coisa (bem, ou quase tudo).
Mas o especialista Jedi tem suas desvantagens:
- Ele precisa ser "ressuscitado" por um longo tempo para aceitar esta Força.
- Quando ele sai de férias, é sempre: "O que todos nós vamos fazer?"
Para superar a influência desses desvantagens, desenvolvemos um sistema para manter matrizes de competências, que discutirei mais adiante. Observo que não o implementamos em todas as equipes, mas apenas onde houve problemas. O pior de tudo foi em pequenas equipes.
Nossa principal dor de cabeça foi a pergunta "O que acontece se algo acontecer com o especialista, como acontece com o Mestre Yoda na figura abaixo?"
E você provavelmente também ouviu falar sobre o conceito de fator Bus.
Fator de barramento
O fator de barramento é uma medida da concentração de informações entre os membros individuais do projeto.
Na definição da Wikipedia, está escrito que esse fator determina o número de participantes do projeto, após a perda da qual o projeto não pode ser concluído pelos demais participantes. Convencionalmente, isso significa quantas pessoas devem mover o ônibus para que um desastre irreparável ocorra com o projeto.
Quando você tem um especialista, o fator Bus é igual a um, ou seja, todos os riscos do projeto estão nas mãos de uma pessoa, e isso é ruim.
Um exemplo da história: em 2010, perto de Smolensk, houve um acidente de avião no qual 96 pessoas morreram, incluindo a alta liderança da Polônia. Após esse evento, uma regra foi aprovada na Polônia - os quatro principais líderes do estado (presidente, primeiro ministro, presidente do Senado, presidente do Sejm) não devem, sob nenhuma circunstância, voar juntos. Este é um fator de proteção contra o fator Bus.
Como você sabe, nas equipes 1 e 2, os especialistas não eram intercambiáveis, e isso criava problemas em potencial. Era necessário fazer algo para aumentar o fator Bus e expandir as competências dos especialistas Jedi. Tomamos as seguintes etapas.
Etapa 1. Aumente o fator Bus
Os Jedi não deveriam estar sozinhos. Portanto, é necessário treinar e treinar os Jedi, para que haja mais deles.
Esclarecerei que o
Jedi é um papel, não uma competência . Jedi pode ser criado. O segundo papel (em termos de Guerra nas Estrelas) é
Padawan , um discípulo dos Jedi. Ele luta pela plenitude do conhecimento dos Jedi e o substitui quando ele está de férias. Além disso, pode haver mais de um Padawan - se a equipe for grande, podemos cultivar vários Padawans ao mesmo tempo. Mas os Jedi continuam sendo os principais tomadores de decisão.
Quando decidimos quem se torna um Jedi, concordamos com os Padawans, distribuímos as funções e as visualizamos na tabela de gerenciamento:
Aqui estão os produtos, áreas ou módulos horizontais. Por exemplo, se o produto for 1C, ele poderá ser "Salário e Pessoal" ou "Contabilidade" ou outros módulos. As colunas verticais indicam os funcionários. No cruzamento, entramos nos papéis - quem é o Jedi, quem é o Padawan. Isso resulta em uma distribuição clara.
Existem algumas regras que concordamos em iniciar a distribuição.
Regras de distribuição, parte 1:- Um produto, área ou módulo - um Jedi . Lembramos que queremos manter a conveniência de um "balcão único", especialista e responsável.
- Pelo menos um Padawan . Trata-se apenas do fator Bus, quanto mais houver, melhor.
- A distribuição uniforme dos Jedi . Para não sobrecarregar os funcionários, com justiça.
Parece que tudo foi logicamente distribuído e ficou assim:
Na primeira equipe trabalhando em um produto, uma pessoa trabalhou no produto antigo (Sunset) e a outra no novo (Sunset 2.0). Na versão "própria" do produto, o funcionário era considerado um Jedi, na versão "alienígena" - Padawan, estudante de outro funcionário.
Na segunda equipe, os funcionários inicialmente recém-chegados estavam matriculados nos Padawans, porque ainda não sabiam nada sobre eles. E então é semelhante ao Sudoku - tentamos obter aproximadamente o mesmo número de Jedi e Padawans em linhas e colunas.
Etapa 2. Controle o compartilhamento de conhecimento
Mas como verificar se o Padawan se tornará um Jedi, possuindo todo o poder do conhecimento?
Fixamos conhecimento
Para isso, fixamos o conhecimento de nossos produtos: faça uma lista de todo o conhecimento e coloque-o em uma tabela. Para cada um dos produtos em uma página separada do Confluence, simplesmente anotamos o conhecimento de que o produto consiste e os decompomos. A decomposição do conhecimento pode ser feita de diferentes maneiras, e lembro-me de que essas tabelas são desenhadas sob a página com a distribuição dos Jedi e Padawans. Por exemplo, para a equipe 1, uma página para o conhecimento do Sunset, outra página para o conhecimento do Sunset 2.0.
Além disso, algumas capturas de tela do Confluence com exemplos de decomposição.
Por módulos do produto. Por exemplo, um dos produtos possui módulos de software separados: empréstimos, depósitos, controle de moeda - acabamos de pintá-los e começamos a trabalhar com eles.
Por funcionalidade. Aqui, pintamos as unidades de conhecimento nas páginas e seções do sistema.
Para conhecimento técnico. Apresentamos alguns produtos simplesmente de acordo com o conhecimento técnico da equipe.
Você pode se decompor de qualquer outra maneira, o principal é que você pode pulverizar o conhecimento do seu produto em um número maior de elementos atômicos.
Adicionar documentação
Depois de detalharmos as listas de conhecimento, adicionamos a coluna "documentação" à tabela e começamos a preenchê-la gradualmente - cada linha de conhecimento tem sua própria página com uma descrição.
Devo dizer imediatamente que este não é um processo rápido, que levou vários meses, mas com o tempo, a lista de documentação foi preenchida e, no final, escrevemos algum tipo de documentação em todas as áreas do conhecimento do produto.
Adicionar classificações
À direita da coluna "Documentação", adicionamos uma coluna para cada membro da equipe e avaliamos quanto cada funcionário tem esse conhecimento.
Vou decifrar as classificações:
- 1 - se você não viu ou tocou nesta área de conhecimento.
- 2 - viu ou ouviu algo, sabe onde está. Por exemplo, li a documentação, solicitei acesso ao servidor ou ao repositório.
- 3 - visto, tocado, pode fazer. Por exemplo, resolvi um bug nesta parte do código, verifiquei algo com as mãos.
- 4 - trabalhou mais de uma vez, pode contar aos outros.
Na primeira versão, tínhamos cinco séries - a escola nos ensinou a contar de 1 a 5. Mas, no fim das contas, o sistema de quatro pontos era suficiente, paramos.
Ao pontuar para uma revisão do conhecimento, podemos fazer perguntas de controle. Uma das equipes para apresentar os novatos ao projeto tem um vídeo de uma hora que você precisa assistir e responder a perguntas na lista de verificação. Se uma pessoa não respondeu a todas as perguntas, acredita-se que ela não entendeu nada, o vídeo precisa ser revisado, porque possui todas as respostas.
Etapa 3. Visualize
Na terceira etapa, surgiu a pergunta - como eu, o gerente, vejo imediatamente e claramente como ocorre a acumulação de conhecimento dentro da equipe?
Visualizamos o estado atual pintando os quadrados Jedi e Padawans em cores diferentes: verde - o treinamento está concluído, cinza - no processo de aprendizado, vermelho - não começou a estudar. No começo, geralmente muito vermelho, mas no final todos deveriam "ficar verdes".
A princípio, tocamos um semáforo e pensamos que deveria haver amarelo entre vermelho e verde, mas a cor amarela brilhante nos distraiu da essência. Portanto, a abandonamos e ficamos cinza. Na verdade, o principal é se livrar do vermelho o mais rápido possível. Imagem com um exemplo de semáforo:
Depois disso, refinamos ainda mais nossas regras.
Regras de distribuição, parte 2:- Os Jedi devem "ficar verdes" primeiro. Ou seja, nos concentramos em bombear os Jedi. O chefe responsável deve se tornar competente o mais rápido possível. Especialmente se este for um novo funcionário.
- Pelo menos um Padawan deve ser verde, tendo completado o treinamento completamente. Mas ele pode não estar com pressa de alcançar o conhecimento dos Jedi, a principal coisa aqui é não parar.
- O restante dos padawans pode estar no processo de aprendizado. Nossa tarefa não é esquecer de "manchar" o conhecimento, para garantir que as áreas de conhecimento dos funcionários se cruzem e a cobertura seja máxima.
Requisitos diferenciadores
Para o primeiro estágio do lançamento do sistema, no qual a descrição e a digitalização do conhecimento estão apenas começando, há boas práticas: separar os requisitos dos Jedi e Padawan.
Vamos lembrar as estimativas: Padawan recebe uma marca verde para os "três" se ele fez pelo menos algo nesta área, e os Jedi devem estar perfeitamente orientados na mesma área para os "quatro". Além disso, é ruim para os Jedi (cor vermelha) se o acesso não for obtido, a documentação não for escrita, etc., ou seja, seu limite mais baixo é "dois". Essa abordagem é ilustrada na tabela abaixo.
Isso foi o suficiente para começar. No próximo estágio, você pode elevar a fasquia e dizer que agora todos os números devem ser os mesmos.
E agora nossos pratos são pintados e tudo ficou mais interessante e compreensível:
Fomos a algumas fotos verdes por ano e meio. Nós lentamente nos reunimos com os líderes da equipe, uma vez a cada duas semanas ou um mês, assistimos o que estava acontecendo, atualizamos constantemente alguma coisa.
Quando adicionamos novas funcionalidades, dados vermelhos apareceram. Então, na próxima reunião do Timlid, verificamos se eles continuavam vermelhos. Nesse caso, começaram a descobrir por que, em duas semanas, o treinamento não havia progredido. Se o vermelho acabar, os quadrados cinza permanecem, nós os verificamos periodicamente. Os resultados da reunião da equipe foram registrados no Confluence em listas de verificação, onde o status foi anotado. Por exemplo: "Empregado 1 - nivelando 10 em 20". Se em duas semanas esses valores não mudassem, eles procurariam o porquê.
Cada novo funcionário está sempre na zona vermelha, ele precisa ser treinado e bombeado o mais rápido possível. Mas como
Etapa 4. Bombeando conhecimentos e habilidades
Preenchimento: preenchendo a documentação
Chegamos a entender que devemos nos esforçar para garantir que uma linha da tabela decomposta do produto corresponda a um conhecimento (uma página da documentação).
A descrição imperfeita é apenas visível nesta tabela. Isso significa que as áreas de conhecimento na coluna da esquerda são muito detalhadas e, do lado direito, há provavelmente uma grande folha de documentação que é difícil de ler e difícil de aprender. Ou seja, eles lêem uma página da documentação e divulgam cinco linhas de conhecimento de uma só vez - é ilógico obtê-lo de alguma forma. É melhor que uma linha corresponda a uma página no Confluence. É mais fácil marcar a caixa (número) em que todas as páginas são estudadas e aprendidas.
Utilizamos dois métodos de preenchimento:
- Escrevendo da memória (método especialista). Quem sabe fazer alguma coisa, senta-se e começa a registrar suas etapas, por exemplo, complementando a descrição com capturas de tela.
- O segundo método - pesquisa - que vejo, depois escrevo. Dessa forma, usamos quando estávamos trabalhando com um sistema que ninguém lembrava do que fazer com ele. O funcionário sentou-se para entender e anotou tudo o que fez em etapas: aqui você precisa solicitar direitos e, em seguida, escrever uma carta etc. Assim, a documentação foi preenchida para a parte que ele investigou.
Acontece que os interesses dos desenvolvedores em termos de autodesenvolvimento não coincidem com o que a empresa precisa. Aqui você pode jogar com as probabilidades. Por exemplo, você precisa de um aumento nas habilidades de análise, o que significa que colocamos um coeficiente de 0,5 na análise. Torna-se claro que você pode "ficar verde" mais rápido. Mas onde os funcionários estão mais interessados, mas não a equipe, as chances são maiores. Nessas seções, o bombeamento levará mais tempo.
Além de trabalhar com documentos, realizamos conversas técnicas. Mas a documentação é básica. Eu acredito que esta é a melhor maneira de controlar todos os processos. Na documentação, tudo está disposto nas prateleiras, uma imagem completa é visível e você pode influenciar a disseminação e o acúmulo de conhecimento.
Então, documentamos tudo o que precisamos. O próximo passo é atualizar.
Actualização
É muito bom quando todos os membros da equipe têm o direito de editar a documentação. Então, qualquer funcionário, familiarizando-se com a documentação, lendo como fazer alguma coisa, pode tropeçar em algum lugar e corrigi-la imediatamente. Por exemplo, o nome do servidor mudou ou algo mais, um funcionário pode alterar imediatamente a documentação. Assim, ocorre
a atualização e reposição automáticas de conhecimento .
Se sua equipe no seu espaço Confluence estiver inscrita nessas alterações, ela receberá notificações onde o que foi adicionado, alterado, melhorado, porque no Confluence Atlassian existem:
- Histórico de alterações de página - você sempre pode ver o que e quando foi alterado.
- Assine as notificações de atualizações da página.
- Excluir através da lixeira.
Convenientemente, há uma exclusão através da cesta. Se alguém clicar acidentalmente em "Excluir página", ele ainda não será perdido. Você pode restaurá-lo e descobrir por que alguém tentou arrancar esse conhecimento do seu espaço.
A maioria de nossas equipes não possui um processo separado para revisar a documentação. Assim, em uma das equipes a disseminação de conhecimento foi uma grande dor, o líder da equipe se esqueceu de fazê-lo. Então começamos a fazer uma revisão lá a cada seis meses. Criamos uma nova página e começamos tudo de novo, a data da revisão foi corrigida.
O principal critério para a qualidade do compartilhamento de conhecimento para mim é a saída de um funcionário em férias. Se uma pessoa sai de férias e ninguém escreve para mim, não liga e não pede nada, acho que tudo está em ordem nesta equipe.
E se antes de planejar as férias houver discussões "o que faríamos sem ele", para mim, essa é uma ocasião em uma reunião pessoal com o líder da equipe para discutir o que acontece com a transferência de conhecimento em sua equipe.
Você precisa entender que a documentação nem sempre é sobre ler ou aprender alguma coisa. Muitas vezes, você precisa fazer algo: solicitar acesso, instalar o programa, abrir algo no programa. No curso dessas ações, a atualização ocorre. , , . , , , . .
Use
?
. . , 4 , . , , - . , , . , , . , .
, . : « , . , ».
, — , . «», , . , : « , . ».
. , , 1, 2, 3, 4 . , , . . , , 1, 2, 3, 4. .
« »KPI, : « - KPI , - - , ». , , , , . — .
— , , .
Bus factor: , . , bus- , , , . : , . , . , , . , , . . : «, . - , ».
, , . () . , , . ( ). . , — . .
. , , . , . , . .
Conclusões
, , , .
« ! ». . !
TeamLead Conf 2020 , . , «», . , . , , , telegram- . 10 11 !