Quando um produto é grande, os desenvolvedores vão ao extremo:
- o código é muito bonito - lançamentos lentos,
- muita atenção aos processos - pouca atenção ao desenvolvimento,
- envio rápido de novos recursos em produção - código ruim,
- muita atenção aos autotestes - é difícil fazer alterações,
- preocupação com a velocidade da interface - evitando novos recursos,
- Melhoria da interface do usuário - pouca atenção à arquitetura de código.
No relatório, falei sobre como evitar esses extremos e obter um trabalho em equipe bem-sucedido.
- Quero falar sobre como viver em grandes equipes. Uma equipe grande é quando há ainda mais pessoas do que nesta sala.
E eu quero que eles funcionem tão bem quanto esses caras no GIF:
Não tenho uma equipe muito grande, mas apenas observei um pouco o que está acontecendo com as grandes equipes da empresa como um todo e só quero compartilhar isso com você.
Para imaginar a escala, você precisa dizer coisas bastante óbvias. Esse Yandex é um pouco mais do que uma página de pesquisa. Muitos de nós, mais de 10 mil
E entre esses "muitos", a maioria são desenvolvedores. Fabricamos muitos produtos diferentes, não apenas para a web. Tem tudo a ver com mercadorias, carros, comida, todo tipo de ferro, inteligência artificial. E os desenvolvedores estão envolvidos nisso. Mesmo se, ao que parece, estamos falando de carros ou de comida.
Temos muitos serviços. Eles não cabem no slide. Espero ter convencido você de que o Yandex é muito grande. Coisas grandes são difíceis de gerenciar.
Um ponto importante. O que continuarei a dizer é, em primeiro lugar, uma simplificação muito forte; em segundo lugar, tenho lapsos de memória, então vou interpretar alguma coisa; terceiro, algumas coisas que eu deliberadamente mexo um pouco com a coerência da história, etc. Enquanto isso, idéias gerais serão verdadeiras.
Vou começar de tempos muito antigos. Eu acabei de chegar ao Yandex. Então foi organizado de maneira muito diferente do que agora. A divisão era por especialização - legal para desenvolvedores. Parecia algo assim. A empresa estava estruturalmente dividida em gerentes, eles fizeram algo entre si. Havia outras especializações. Na verdade, não havia designers na época, mas transmite o significado. E, claro, havia desenvolvedores. Dentro dessa estrutura, ele foi cortado em fragmentos ainda menores.
Os desenvolvedores estavam com serras ou alicates. Havia caras de boné com batidos, caras de capacete eram mais hardcore, designers que não estavam lá na época e gerentes que compravam para todos. Eles, portanto, foram preparados.
Se você se aprofundar nessa história, então dentro da hierarquia havia algo assim. Havia um cara no capacete mais difícil, com todos os obstáculos. Ele tinha gerentes sutis sob seu comando, depois gerentes menos graves. Eu exagerei, mas a ideia é clara. E a mesma hierarquia funcionou para cada especialização.
Caras com smoothies em caps funcionaram da mesma maneira, e é divertido. Você é um desenvolvedor, você obedece a outro desenvolvedor, ele entende o que você está fazendo, ele o elogia por algo que ele próprio gosta. Ótimo.
Mas suponha que uma idéia chegue a algum produto. E ele tem apenas outros gerentes subordinados - isto é, se ele tiver sorte e tiver pelo menos alguém que seja subordinado. Todo o resto não o obedece, mas de alguma forma a idéia precisa ser realizada.
E ele diz: “Camarada Chefe Designer, tenho uma ideia legal. Eu preciso de um designer. Ele responderá: “Bem, primeiro, sua ideia é estranha e, segundo, todos os designers estão ocupados comigo. Venha para o Q5. ”
Se o gerente acreditar nele neste momento, ele não terá nada. Se ele for persistente, talentoso e pronto para superar todas as dificuldades, talvez ele convença esse designer-chefe. Ele dirá - ok, em dois meses você aceitará esse cara, ele deve estar livre. Cara, é claro, o prazo terminará e será lançado em quatro meses, mas pelo menos haverá uma chance para o desenvolvimento do processo.
Então, esse gerente irá ao desenvolvedor principal, dizer: “Eu tenho um design legal, uma ideia incrível. Eu preciso de um back-end. E tudo isso continuará: "O backender está ocupado, você tem uma idéia mais ou menos, o design é ruim".
No final, ele pode conseguir uma equipe de desenvolvimento e fazer alguma coisa. Por um lado, dessa maneira, apenas a idéia mais legal sobrevive; por outro, é realmente difícil fazer alguma coisa.
Mas para o desenvolvedor, isso é legal. Os desenvolvedores são avaliados por outros desenvolvedores. Os desenvolvedores, é claro, adoram tudo o que é técnico. E sobre a mercearia, deixe o gerente primeiro convencer que essa é uma ideia interessante. E, como todos os desenvolvedores da mesma estrutura se comunicam, todos têm partes em comum, a troca de conhecimentos técnicos está muito bem estabelecida. Com a experiência em produtos, as coisas não são muito legais, mas quem se importa? E muita pesquisa, porque é para os fãs. Serão avaliados por outros desenvolvedores que também são fãs. Você pode inventar coisas de alta tecnologia.
Obviamente, essa abordagem tem um problema. Os desenvolvedores não estão muito preocupados com o que há com o produto, porque eles não obedecem aos gerentes. Os gerentes de capacete serão ridicularizados se algo der errado, mas eles não têm influência especial nos desenvolvedores. E o produto, por sua vez, é bastante difícil de mudar. Na verdade, eles podem apenas persuadir, convencer e de alguma forma dançar para provar que a ideia deles é legal. Então o desenvolvedor acreditará nele e, é claro, fará tudo doer.
Mas acontece que, nessa grande fila de desenvolvedores, você precisa pegar alguém acidentalmente, todo mundo faz algo interessante, mas montar algo grande e complexo e em constante interação é problemático.
Enquanto isso, tudo isso acontece, a empresa pega e cresce duas vezes em um ano. E você precisa fazer alguma coisa. Como Arkady Volozh costumava dizer, administrar uma empresa é como fritar uma almôndega. Ele precisa ser constantemente revertido.
A estrutura da empresa está mudando. Em vez de dividir todos por especialização, dividir por produto. E o gerente está se tornando um cara muito mais importante.
Acontece que aproximadamente esse esquema, se bastante simplificado e muito exagerado. Temos um pedaço grande do produto, por dentro ele se divide em partes menores e, para cada parte, uma equipe totalmente equipada se destaca. Existem designers, desenvolvedores, gerentes e todos eles fazem esse produto.
Parece que o problema foi tratado, mas há um novo problema. As equipes podem ser bem pequenas e, naturalmente, haverá um front-end, um back-end, um designer, metade analista e outra pessoa. Eles são brega com ninguém para falar sobre sua área de assunto, e parece que isso não é necessário. Eles estão vendo seu projeto, mas todas as invenções que recebem no processo, não têm ninguém para transmitir, não têm ninguém para perguntar como fazer melhor. Eles não sabem o que estão fazendo atrás da parede adjacente e talvez estejam fazendo o mesmo. Além disso, eles fazem o mesmo diretamente naturalmente.
O gerente parece ter mais poder, mas ele não entende tão bem todas as sutilezas do desenvolvimento. Um desenvolvedor talentoso, se desejar, pode dizer a ele que, sem uma reescrita completa do projeto, em lugar nenhum. E qual é a próxima escolha do gerente? Ou ele acreditará nele ou o proibirá, todos ficarão insatisfeitos. Em geral, há um problema.
Quero, de alguma forma, equilibrar tudo em termos de produto. Por exemplo, um produto tem uma equipe e, por exemplo, acredita que um código bonito é importante. E enquanto eles aprimoram esse código ao ideal, fica claro que os lançamentos estão sendo adiados. Não é legal. Ou a equipe pensa: “Tudo bem, se houvesse processos legais e o código acontecer de alguma forma”. De fato, não, isso não acontece. Também é necessário que isso seja observado por alguém.
Ou a equipe diz: "Precisamos avançar muito rapidamente, é importante lançarmos recursos todos os dias", mas nesse momento a qualidade do código está ficando fora de foco. Ou a equipe diz: “Ok, a última vez que jogamos no rake, percebemos que a qualidade é importante. Vamos cobrir tudo com autotestes. Os autotestes são escritos para cada recurso, mas agora esses testes devem ser executados em cada solicitação de pool e demoram muito tempo para serem concluídos, e tudo fica lento.
Ou: “Sabemos que nossos usuários, se a interface estiver lenta, estão saindo. Vamos acelerar as interfaces. ” Mas acontece que cada novo recurso é um código extra que precisa ser transmitido pela rede e executado, além de diminuir a velocidade da interface. "Então não vamos criar novos recursos - tudo funcionará mais rápido". Ou: “O usuário adora quando bonito. Vamos fazer lindamente. Mas não importa o que está dentro.
Em busca desse equilíbrio, verifica-se que algo precisa ser mudado novamente. Enquanto isso, a equipe está crescendo dramaticamente novamente.
Como isso geralmente é resolvido? Pegue uma palavra da moda. Nós levamos isso também. Temos um scrum bastante comum, mas com nossas próprias invenções. O que diz isso? Ele diz que vamos refrescar a equipe das equipes para que todos sejam responsáveis pelo resultado final, com toda a experiência necessária. E deixe essa equipe escolher quais tarefas executar primeiro, escolher quais processos eles devem ter dentro. Em geral, um produto é mais importante que processos. Isso é tudo. Parece bom. Parece até resolver parte dos problemas.
Mas ainda há um problema. Por exemplo, supõe-se que essas equipes de scrum se adaptem constantemente ao que está acontecendo ao seu redor, mudam constantemente (sua composição muda, elas podem formar-se, dissolver-se) e, em princípio, não há um lugar comum onde o histórico de desenvolvimento do funcionário seja agregado.
Ou seja, existe algum tipo de desenvolvedor e ele tem alguns pontos fortes, ele está queimando em algum lugar. E ele entra em uma nova equipe de scrum, e eles não sabem sobre esses pontos fortes e não começam a usá-los ali mesmo. E, pelo contrário, talvez ele não se segure em algo, não há ninguém que saiba disso, garanta que ele seja bombeado nisso e garanta que o projeto não sofra com o fato de que ele não possui experiência lá.
E há soluções que agora estamos tentando aplicar em uma parte separada da empresa e ver o que acontece. A ideia é a seguinte. Existe alguma estrutura bastante estável na qual existem links entre o desenvolvedor e seu líder, também o desenvolvedor. Tudo é como no começo, quando o líder entende o que você está fazendo, compartilha interesses com você, ele pode aconselhá-lo em termos de como trabalhar com mais eficiência e ajudá-lo em algum lugar. Esses links foram mantidos por um longo tempo ao longo de vários anos.
Para atender às necessidades do produto, juntamente com uma estrutura estável e constante, equipes de scrum virtuais rápidas ainda são formadas para cada produto e até para cada aspecto individual do produto. Agora vou falar mais sobre isso.
As equipes são temporárias, rápidas, podem se concentrar em algumas das coisas mais críticas no momento.
Parece algo assim. Aqui temos um pequeno pedaço, por exemplo, a web. E por dentro, se você olhar, um monte de pessoas que estão vendo essa web.
É assim que ocorre o equilíbrio de toda a história. Existem caras verdes, eles são responsáveis por garantir que as interfaces sejam rápidas. E tudo o que lhes interessa é que tudo deve ser o mais legal possível, de acordo com as métricas de velocidade. Deixe tudo o que quiser como quiser. Mas há outros caras que, em princípio, a velocidade não é tão importante, mas é importante por algum período que conseguimos lançar um monte de novos recursos interessantes para o usuário em produção. E agora é impossível que os caras digam: “A velocidade é mais importante. Não corra nada. Porque para essa equipe isso é fundamentalmente inaceitável.
Mas, pelo contrário, a equipe responsável pelos recursos não pode mais lançar um monte de código novo e dizer: “Então tivemos que iniciar os recursos, tudo ficou mais lento, mas os recursos foram iniciados”. Eles vão concordar um com o outro, de alguma forma ajudar um ao outro, e no final tudo ficará bem. Gajos azuis estão escrevendo testes freneticamente, constantemente. E eles cobriram tudo com testes, e agora existem muitos testes, e todos eles trabalham devagar. E os caras não se importam, porque eles são os únicos responsáveis pela cobertura.
Mas é ótimo que outras pessoas digam: "Mas é importante para nós que o processo de desenvolvimento como um todo seja rápido. Desde o momento em que definimos a tarefa até o momento em que nossos usuários começam a usá-la, esse período deve ser reduzido. ” E eles vão concordar, e tudo ficará bem. Eles ajudarão as pessoas que escrevem testes para que eles sejam executados mais rapidamente.
Alguém é responsável apenas por garantir que tudo seja arquitetonicamente legal. Além disso, eles podem nem precisar pensar no que está acontecendo agora no código. Eles podem pensar em termos de: "E para onde tudo deve ir daqui a um ano e meio?" - e agora se concentre neste futuro. Mas, ao mesmo tempo, haverá alguém que aperta os cantos arredondados, corrige as sombras e pensa na animação para que o usuário fique mais feliz amanhã. E quando existe tal distribuição de responsabilidade, e cada equipe se complementa mutuamente, um equilíbrio é obtido.
Existem vários papéis para tudo isso. Eu já disse algo sobre isso, mas, no entanto, isso é uma coisa importante. Cada um tem seu supervisor imediato, que sabe tudo sobre ele e garante que uma pessoa cresça profissionalmente, cresça pessoalmente e seja feliz. Ao mesmo tempo, há um líder dessa equipe que diz que a cobertura dos testes deve crescer e tudo o resto é menos importante. E quando esses dois papéis ocorrem simultaneamente, fica mais ou menos bem.
E há outras coisas diferentes. Em tal situação, verifica-se que, para desenvolvedores envolvidos no mesmo produto, reunidos de diferentes estruturas em uma equipe virtual, muito mais atenção é recebida de diferentes gerentes. E, no total, essa experiência permite que o produto seja melhorado ...
... e depois transfira para outros produtos analisados pelos gerentes estruturais, algumas invenções que surgiram durante o trabalho dessa grande equipe. Ou vice-versa, ou seja, essas setas podem ser giradas na direção oposta, e isso também será verdade. Isso transforma o estouro e a experiência, e é conveniente, de alguma maneira, reunir as equipes no produto em que é mais importante agora. Assim, a quantidade de atenção a diferentes produtos dos camaradas mais experientes da empresa aumenta.
OK, meio que concordou como tudo deveria funcionar. Mas se temos um chefe estrutural e um chefe sobre um produto, como avaliar se tudo saiu bem? Sergey Berezhnoy falou sobre isso em detalhes no ano anterior ao último sábado. Vou repetir brevemente a idéia geral.
A decisão sobre se uma pessoa em particular funcionou bem é tomada, primeiramente, em comparação com outros participantes no processo e, em segundo lugar, coletivamente por todos os envolvidos. Ou seja, tanto seu líder estrutural, que monitora como se desenvolve no segmento de longo prazo, quanto a pessoa responsável pelas tarefas e estimativas de curto prazo do produto, não em termos do fato de que a pessoa se esforçou muito e não dormiu à noite, mas em termos de como ele realmente alcançou seus objetivos. E é assim que, no momento, parece-nos o mais justo. Se você se destacar, mesmo sem forçar - bonito, vamos te louvar. Tal equilíbrio parece-nos a funcionar, bom.
Benefícios adicionais. Quando concordamos que podemos montar rapidamente equipes individuais, reagrupar pessoas para cada necessidade específica, torna-se crítico que essa transição seja a mais simples possível. E isso só é possível se tudo estiver bem descrito e documentado. Essa construção em si força a necessidade de documentação. E, ao escrever a documentação, os produtos se tornam automaticamente melhores em geral. Esse é o benefício em duas direções.
Além de trocar conhecimentos, as transições das pessoas tornam os produtos diferentes mais semelhantes entre si - em termos de aparência e de organização. Você também pode se beneficiar com isso - os usuários entendem como usar os sistemas, porque eles usaram algo semelhante em outro projeto. E, claro, você pode finalmente reutilizar as melhores práticas.
Essas equipes se concentram em cada aspecto separadamente: elas escrevem testes ou são responsáveis pela velocidade ou pela beleza - mas ainda não conseguem pontuar o que está acontecendo com os vizinhos. O fato é que o líder deles é responsável pelos desenvolvedores de outras equipes, e eles próprios podem em breve mudar para outra equipe. É óbvio para eles que, condicionalmente, amanhã os afetará. Portanto, ao focar, a responsabilidade por tudo como um todo não se perde. Como resultado, é fácil alternar entre projetos.
Ao mesmo tempo, as pessoas têm muitas oportunidades de crescimento. Porque em uma estrutura em que tudo é moldado em granito e não se mistura, as pessoas chegam a uma situação em que já entendem tudo. Eles tentaram tudo nesse projeto e simplesmente seguiram o fluxo. eles não precisam fazer esforços repentinos consigo mesmos o tempo todo. E se eles precisam mudar constantemente a equipe, mudar constantemente o ângulo de continuação de seus talentos, seus conhecimentos aumentam automaticamente, tudo isso fortalece o sistema como um todo. E de qualquer maneira, não é chato. É improvável que você não concorde com isso.
, : « , , ?». , . , , . , - , , .
, . , , . ? , , , , .
,
. , - , , . , . , , — , , , : «, , . ».
, — . , , , , , ? . . , , , . , , . . , — , , , . -, , .
: — , , , , . — . .