🙎 👩🏿‍🤝‍👨🏽 🐑 Como fazer com que os vizinhos trabalhem em seu projeto, ou InnerSource para um banco 💸 🔕 🐓

O que é desenvolvimento em Sber? Aos olhos de um especialista em TI comum: "Aqui é onde o código foi escrito, vá lá!" Mas isso tem sido um estereótipo há muito tempo e eles não são bons. O rápido desenvolvimento do código aberto prova que essa cultura se tornou obsoleta e a empresa (se for inteligente) revisou por muito tempo a abordagem de desenvolvimento baseada em silos. A publicação de todo o software bancário em código aberto é uma ~~maneira eficaz de cometer suicídio, uma~~ decisão bastante controversa e é necessário algum tipo de estágio intermediário. Com a escala do banco, podemos lançar nosso código-fonte aberto interno, em vez de tentar verificar o que podemos mostrar a todos e tremer de medo por nossos pequenos segredos.

O que é um InnerSource?

Em 2000, Tim O'Reilly descreveu o termo fonte interna como um possível passo em direção a uma empresa fechada que entra no belo mundo da fonte aberta. Esta é a aplicação das melhores práticas de código aberto dentro da corporação: da abertura geral e assistência mútua proativa à formação de um mercado para as melhores soluções. A empresa continua a escrever código proprietário, mas cada um de seus funcionários tem a oportunidade de refinar qualquer sistema interno.

As vantagens do InnerSource podem ser listadas por um longo tempo: reduzindo o tempo de colocação no mercado, melhorando a qualidade do código, substituindo a contratação externa por interna, melhorando a interação entre equipes e assim por diante.

A dificuldade está no fato de que tudo descrito acima requer uma mudança na cultura da comunicação entre funcionários e equipes, e isso não é tão fácil de ser feito em uma organização que trabalha de maneira diferente há décadas.

Obviamente, o Sberbank não é a única empresa que fez algo assim. Em 2015, foi criada a comunidade InnerSource Commons , que popularizou a abordagem e removeu a lacuna do termo para facilitar a localização nos mecanismos de pesquisa. Essa comunidade reuniu a experiência de dezenas de empresas e fez recomendações eficazes para a implementação do InnerSource em sua empresa, e realiza uma conferência de troca de experiências duas vezes por ano. Ainda existem muitas empresas de tecnologia bem conhecidas que fazem isso ~~desde os Pechenegs e Polovtsy~~ antes de se tornar mainstream.

Na Rússia, até onde sabemos, apenas um grande varejista no mercado de serviços de construção com um logotipo verde está envolvido ativamente na implementação intencional do InnerSource, outras empresas não divulgam sua experiência ou não participam da comunidade.

Cada uma dessas empresas tem suas próprias experiências positivas e negativas. A conclusão geral neste caso é muito semelhante: os benefícios mais deliciosos só podem ser obtidos com a participação da grande maioria.

Por que eu colecionaria isso?

Quase todas as conversas sobre desenvolvimento no Sberbank abordam a questão "quantos programadores você tem lá?". Em todo o país, temos mais de dez mil deles, eles estão trabalhando ativamente em milhares de componentes, sistemas, bibliotecas e outros como eles. Como conseqüência de tais volumes, todos os dias temos que resolver os problemas de gerenciamento de dependências de equipes relacionadas, o relacionamento de liderança e as fases do Mercúrio.

No final da pesquisa sobre o que prejudicou os engenheiros, no final de 2018 em Sber, foi decidido criar um SberWorks tribal, que assumia tudo relacionado aos processos e ferramentas para a produção de software no banco. As tarefas e objetivos da unidade seguiram quase completamente da lista de dores coletadas pelos desenvolvedores.

Tenho vergonha de admitir que a maior dor no final do ano passado foi a falta de conhecimento do que os vizinhos da oficina ou mesmo do quarteirão vizinho em espaço aberto fazem. Por isso, inventamos não apenas a roda, mas também duas (substitua o número desejado) das mesmas rodas em unidades diferentes, tanto em cidades diferentes quanto em locais de trabalho vizinhos. Como resultado, tendo enormes recursos na empresa, muitas vezes em vez de voar para Marte, nossas equipes fizeram varreduras, sem saber que as varetas vizinhas haviam sido coletadas há muito tempo.

O que fazer com tudo isso?

Tempo. Para resolver os problemas de integração e encontrar as pessoas certas, crie um único registro de API para todos os sistemas do banco com um grande número de automação: geração de chamadas, stubs para a próxima versão da API, controle de versão e similares. Agora, esse registro se transformou em um produto legal separado, que é definitivamente digno de seu artigo, mas isso é outra história.

Dois. Crie um tipo de "guarda-chuva" com um único mecanismo de pesquisa em todas as ferramentas de engenharia (JIRA, Confluence, Bitbucket, Nexus), combinando os segmentos interno e externo (sim, infame alfa e sigma).

Três. Código, listas de pendências e artefatos, exceto aqueles que proíbem explicitamente a segurança de abrir, devem estar abertos a todos os funcionários da empresa.

O que foi sugerido?

No processo de comunicação com os desenvolvedores, identificamos o principal motivo de uma equipe tão fechada dentro de nós: as formas atuais de interação entre produtos. Qualquer discussão sobre o refinamento de sistemas relacionados ocorreu de acordo com um dos três cenários.

"Aguarde"

A maneira mais comum de interagir. A equipe adjacente estabelece um prazo, geralmente nos convém, adiamos a tarefa mais profundamente na lista de pendências.
Em geral, uma opção aceitável. Mas se a cadeia tiver dependências de várias equipes e o recurso, como de costume, precisar ser exibido na produção ontem, será necessário procurar compromissos.

Compromissos

Popularmente, esse método é chamado de escalação. Tenha um gerente mais substancial com você e faça parte de uma equipe adjacente para aumentar sua tarefa no backlog. As desvantagens dessa abordagem são óbvias: a maioria das equipes pode jogar esta carta apenas algumas vezes, após as quais o relacionamento entre as equipes se deteriora.

“Esboço permanente temporário”

Vi sua bicicleta Frankenstein com muletas e bazucas temporárias que duplicam a funcionalidade do sistema no qual o vício apareceu. O mais triste, já que quase sempre permanece por muito tempo (se não para sempre), gera duplicação de código e a equipe é forçada a apoiar uma solução de muleta.

Propusemos uma quarta via. Refine a base de código da equipe adjacente sob sua supervisão sensível, reduzindo o tempo de execução.

InnerSource

Após a conclusão dessa interação, a equipe “A” da imagem recebe um feedback precioso, nutre a experiência em um campo adjacente e reduz o TTM de seu refinamento. No futuro, no banco, essas interações adquiriram rapidamente formatos de troca de vários tipos: a equipe "A" fecha as tarefas da dívida técnica da equipe "B" enquanto realiza o refinamento necessário.

Nosso caminho

Desde o início, parecia-nos que precisamos encontrar lugares em que o InnerSource esteja com a máxima demanda no momento. Enquanto estávamos pensando em como fazer isso, sem cair em um ciclo de pesquisas intermináveis, a liderança sábia apreciou a ideia e propôs garantir cem por cento de prontidão de cem por cento dos sistemas Sberbank até o final do ano. Ficamos tensos, nosso gerente perguntou “o que é cem por cento?”. E o número de sistemas foi reduzido em cerca de 20 vezes para moderno e / ou crítico para os negócios.

Depois disso, iniciou-se o processo rotineiro de difundir essa prática nas equipes, no final do qual vimos um campo coberto com uma lista de repositórios e regras para trabalhar com cada um deles.

Tivemos várias reuniões em vários níveis, primeiro com os líderes técnicos dos departamentos, depois com os líderes de equipe e os proprietários de serviços e, finalmente, com os membros da equipe. Solicitamos aos representantes de serviço que forneçam informações sobre o próprio sistema, a pilha de desenvolvimento e links para repositórios, lista de pendências e documentação. Nas mesmas reuniões, fomos capazes de obter informações sobre dor em primeira mão: lista interminável, falta de recursos, pilha de tecnologia antiga (por exemplo, Delphi).

No processo de circulação, formamos uma compreensão dos elos fortes e fracos do banco. Havia equipes muito maduras (por exemplo, desenvolvimento móvel) que já trabalham nos princípios da InnerSource em escala industrial e compartilharam um grande número de cones e abordagens. Mas havia várias equipes (olá aos pechenegues) que nos desencorajavam pela falta de testes automáticos, práticas de registro e revisão de código.

Entre nossas equipes, há uma enorme lacuna cultural entre "minha unidade militar está trabalhando nas tarefas mais corretas" e "vamos fazer isso juntos legal". A maioria das reações foi bastante monótona: "não queremos pegar o código de outra pessoa e, em seguida, responder por ele", "não queremos dar a nossos desenvolvedores porque eles vão embora, mas não há recursos". Nesse ponto, decidiu-se investir mais na cultura do que em tecnologia:

HR : Google, , 10 % .
PR : Microsoft, open source.
: , - Delphi GraphQL, 10 % , !
, API, JIRA- .

Com algum erro, aprendemos a rastrear as interações entre equipes que ocorrem no BitBucket e recebemos informações de que temos cerca de 30 a 50 novos autores de alterações no InnerSource adicionados todos os meses. O número em termos de número de desenvolvedores no banco não é muito impressionante, mas essas são apenas melhorias nas tarefas de negócios.

Espera-se que as mudanças conduzidas por dados em vários barramentos de integração e serviços ETL se tornassem muito populares. Isso é facilmente explicado pelo grande número de tarefas e pelo baixo custo de melhorias.

Estudamos cuidadosamente essas melhorias no exemplo do nosso ESB. Uma transição para uma nova solução está planejada para ela em um futuro próximo, portanto, nenhum recurso adicional foi alocado para a equipe, enquanto os pedidos de revisão apenas aumentaram. Na InnerSource, os caras viram a salvação, rapidamente se agitaram e montaram um priorizador que eleva sua tarefa o máximo possível, se você estiver pronto para fazê-lo. Em números, é assim: em outubro-novembro, quase metade (101 de 209) pedidos de revisão foram concluídos pelas próprias equipes. Isso resultou em uma redução de quatro vezes no tempo de espera de 2,5 meses para 2,5 semanas.

Inesperadamente, os designers participaram ativamente, felizes em ajudar as equipes relacionadas quando estas não possuem recursos ou exigem uma nova aparência. Como se viu, existem algumas equipes que podem utilizar designers 100%, e elas mesmas são criativas e gostam de mudar o foco para algum novo produto.

Posfácio

Os primeiros passos para introduzir transparência e interações entre equipes em uma empresa que está acostumada a cumprir as leis da empresa são sempre os mais difíceis. Podemos dizer com segurança que as primeiras paredes foram rompidas e uma quantidade suficiente de histórias bem-sucedidas da InnerSource foi acumulada para que o movimento dentro do Sberbank ganhe impulso.

O principal desafio no futuro é evitar a lei de Goodhart . Em qualquer empresa de médio e grande porte, a eficiência deve ser medida: crie um número e faça-o crescer. Em uma conferência em Baltimore, no outono passado, foram apresentados vários casos em que o estabelecimento de metas para a prontidão das equipes e o número de melhorias levaram à sabotagem das métricas e à exaustão dos líderes do movimento.

Acreditamos que os benefícios resultantes desencorajam completamente o esforço investido, e a abertura em si mesma tem inúmeras vantagens. Estamos prontos para contar o nosso caminho com mais detalhes e trocar experiências, escreva-ligue - innersource@sberbank.ru . Beijos, Sberbank.