Quando em artigos e relatórios eles falam sobre casos no gerenciamento de equipes, geralmente se limitam a dizer o que estava errado e como eles mudaram a situação. Mas desta vez temos uma oportunidade única de descobrir como a equipe viveu mais e como tudo terminou - na verdade, não terminou, mas continuou.

Aqui está uma continuação da história intitulada " Como sobreviver a um escalpo no scram escalável e manter o controle sobre a qualidade do código " sobre a transformação Agile no ivi. Na TeamLead Conf, o diretor técnico da empresa, Evgeny Rossinsky ( eross ), explicou por que pode ser necessário reverter toda a reorganização da equipe, como não brigar e ajudar os desenvolvedores, mas também para manter e aumentar a eficiência dos negócios.

Contexto da empresa

ivi - o maior cinema jurídico da Internet, com uma audiência de 48 milhões de usuários, que coletivamente gastam 70 milhões de horas mensalmente. O Ivi possui 62 mil unidades de conteúdo, disponíveis em diferentes dispositivos e sempre em excelente qualidade.

Aconteceu que no mesmo dia em que Eugene falou na TeamLead Conf com este relatório, era o aniversário da empresa. Há 9 anos, ocorreu o primeiro lançamento da versão web do projeto e, após 2 dias, a força do Channel One trouxe um grande número de usuários ao ivi. A empresa até pensou que era DDoS, mas conseguiu resistir com dignidade.

Este artigo é sobre o lançamento de um novo produto - uma reinicialização completa de todos os aplicativos.

Assista ao vídeo para ouvir a versão sem censura ou leia a transcrição do relatório na primeira pessoa.



Primeiro, vamos falar sobre as tecnologias e competências usadas para entender a extensão do dano.

Competências:

• Back-end (Python, Golang, Java);
• Web (JavaScript, Node.js);
• Android (Java)
• iOS (Objective-C, Swift);
• SmartTV (JavaScript);
• Windows / XBox (C #);
• Sony PS (JavaScript).

Para cada uma dessas competências em 2016, tínhamos nossa própria equipe, ou seja, Equipe iOS, equipe Android, etc. Havia também uma equipe de back-end e, separadamente, uma equipe de gerentes de produto que criaram novos recursos.

O principal problema, devido ao qual era necessário transformar, era que todas as plataformas são diferentes, inclusive que tinham diferentes atrasos e prioridades. E realmente queríamos criar um único espaço de informações em nossos aplicativos.

Muitas vezes acontecia que um recurso complexo aparecia em todas as plataformas 4 meses depois de ter sido concebido. Ao mesmo tempo, ele apareceu em uma plataforma após três dias e, dependendo da priorização de backlogs, foi implementado em plataformas diferentes em velocidades diferentes. Ficou monstruoso pelas seguintes razões:

• Por 4 meses, o recurso já pode adquirir um significado completamente diferente e a necessidade dele pode desaparecer.
• Devido a problemas de comunicação, que são óbvios neste caso, as pessoas implementaram recursos de maneiras diferentes.

Como o produto possui três modelos de monetização que funcionam com eficiência diferente em plataformas diferentes, a priorização da lista de pendências em cada plataforma era diferente. Alguns recursos nunca poderiam, em princípio, ser implementados em plataformas separadas.

Uma breve recontagem da transformação

Em 2017, introduzimos o conceito de fluxo de valor - são equipes multifuncionais responsáveis ​​por tarefas comerciais específicas. Para entender o que nossa empresa tem tarefas específicas, reunimos cerca de 25 a 30 pessoas de toda a empresa, convidamos treinadores engajados em metodologias flexíveis e, em 2 dias, formulamos que tipo de valor devemos ter - orientações de desenvolvimento.

Tem 5-6 fluxos de valor. Eles plantaram esses caras juntos, deram a cada um um Product Owner, que estaria se afogando nessa direção em particular (mais detalhes aqui ).

Sabíamos dor, sangue, lágrimas e alegria e alcançamos indicadores muito bons:

• Descarregamento síncrono de recursos idênticos em diferentes plataformas .
• Uma diminuição múltipla no tempo de colocação no mercado . O lançamento de muitos recursos permaneceu apenas no ciclo de gerenciamento de lançamento em cada plataforma, pois, por exemplo, a Apple não permite descarregar cada recurso separadamente. Portanto, os recursos são agrupados e, em média, seremos lançados a cada duas semanas.
• Eliminação de "gargalos" , que eram proprietários de produtos e gerentes técnicos e líderes de equipe.
• Os desenvolvedores começaram a entender por que estão "vendo" novas funcionalidades.

Sobrevivemos muito bem ao ano - em 2017, a receita quase dobrou .

Mas isso não foi suficiente, e a vida no final de 2017 - início de 2018 nos surpreendeu.

Por que você precisava de um novo produto

Os negócios estabeleceram novas metas. A surpresa foi que o desenvolvimento de qualquer software existe para o bem de alguma coisa. Poucos escrevem código por motivos altruístas. Para que a empresa justifique sua existência, seus proprietários e acionistas estabelecem certas metas que a equipe deve cumprir.

Nossos acionistas não dizem como fazê-lo, eles dizem o que querem alcançar. Como - a equipe deve decidir.

A equipe enfrentou a tarefa de descobrir como ganhar mais . Realizamos um brainstorm, e o departamento de compras, juntamente com o técnico, chegou à conclusão de que, para atingir objetivos ambiciosos (por convenção, dobrar o tamanho da audiência pagante), devemos, em princípio, mudar a ênfase da exibição gratuita do filme para paga.

Quase todas as hipóteses apresentadas se encaixam muito mal no conceito do produto antigo. Mais precisamente, não se encaixava absolutamente - qualquer fluxo motivacional nas transições de usuários se baseava no fato de que em algumas plataformas isso é implementado, em outras não, há algumas limitações, outras lá. Nossa equipe tem 9 anos e acumulamos muitas coisas que nos arrastaram para o fundo. De uma maneira boa, foi necessário reescrever tudo.

Vários estudos qualitativos e quantitativos mostraram os problemas do produto antigo . Aconteceu que estamos 2-3 anos atrás do que a humanidade sábia pensou. Por exemplo, se há cerca de 5 anos em dispositivos móveis, era moderno e moderno colocar um menu de hambúrguer no canto superior esquerdo, com o advento de telas grandes as pessoas paravam de chegar lá. Até 2018, tínhamos realmente um menu de hambúrguer, e as pessoas de alguma forma lidavam com ele.

O usuário pobre se acostuma a tudo, mas isso não significa que você precise deixar tudo como está.

Muitas estruturas precisavam de refatoração. Encontramos falhas lógicas e, como em qualquer código de longa duração, tínhamos muitos códigos antigos e não muito bons. Os desenvolvedores realmente não gostaram.

Por exemplo, é muito difícil contratar desenvolvedores que desejam escrever no Objective-C. Todos somos influenciados pela moda e até preguiçosos - se houver alguma ferramenta que permita fazer a mesma coisa, mas com mais rapidez e eficiência, queremos usá-la. E a situação no mercado de trabalho é tal que você pode escrever em um resumo: "Quero escrever em Swift" e, mesmo que você não saiba escrever em Swift, definitivamente chegará a algum lugar.

Algo precisava ser feito com isso, e esse é um dos problemas que impedem o desenvolvimento. Portanto, tivemos que reescrever componentes obsoletos e implementar estruturas modernas.

Objetivos

Queríamos:

• Crie um novo produto com um único design.
• Torne nosso bom sistema de recomendações responsável pela emissão de todos os blocos de nosso produto.
• Corrija erros de interface lógica.
• Limpe o código.
• Migrar para um novo sistema de estatísticas.
• Implemente um sistema de design.

Todos os desafios são bastante ambiciosos, especialmente o sistema de design, porque existem muito poucos sistemas de design que funcionam em várias plataformas e se divorciam do código do programa. Eles produzem principalmente o mecanismo JS, usado em plataformas diferentes. De fato, o mecanismo para transmitir informações sobre a aparência do produto está dentro do código.

Não podemos fazer isso muito bem, porque trabalhamos com vídeo, e trabalhar com vídeo requer o uso de mais ou menos ferramentas nativas. Além disso, se você não usar ferramentas nativas, sempre haverá um backlog de 1-2 etapas nas versões do sistema operacional. Todas as estruturas universais como o Xamarin ainda precisam ser recuperadas após os lançamentos. E somos muito gananciosos antes de aparecermos - o Google e a Apple nos recomendam apenas porque usamos ferramentas nativas.

As ferramentas nativas ajudam a criar aplicativos de qualidade, bons e rápidos. No caso do vídeo, isso é simplesmente necessário.

Procure soluções de gerenciamento

Tendo designado as metas, sintonizamos sua rápida conquista. Deixe-me lembrá-lo de que estávamos divididos no Value Stream, que diferentes desenvolvedores estavam sentados em equipes diferentes e que estávamos diante da dura realidade - o que fazer?

Parece que tínhamos um sistema ao qual acostumamos as pessoas há algum tempo, e agora as regras do jogo mudaram.

Obviamente, no começo, tentamos trabalhar como antes, usando o Value Stream, aceitando os seguintes cálculos lógicos: "Deixe o Value Stream, que está envolvido nessa direção do negócio, refatorar todos os componentes associados a essas áreas".

Oh, como estávamos errados! Cerca de um mês depois, descobriu-se que, para reescrever o núcleo de cada um dos aplicativos, você precisa entrar em todas as áreas das regras de negócios.

Era muito difícil diferenciar a área de responsabilidade do Value Stream, que assume qual parte quando as pessoas estão sentadas em andares diferentes, em salas diferentes.

O mais triste é que, devido às diferentes linguagens e recursos das plataformas de desenvolvimento, o efeito da colaboração desapareceu completamente.

Na estrutura do Value Stream, os desenvolvedores de iOS e Android estão vendo o mesmo recurso e têm algo a discutir, discutindo a lógica de negócios. E quando cada um deles vê uma estrutura de baixo nível, que está fracamente correlacionada com o que será mais tarde no produto final, a sincronização desaparece completamente.

Havia pessoas que, em princípio, se separaram do significado do que estava acontecendo. Os Timlids foram os primeiros a desanimar, porque, como pessoas responsáveis, precisavam tropeçar e descrer nos funcionários da humanidade para retornar ao seio da igreja verdadeira, para que escrevessem um código adequado na direção certa. Acabou muito mal.

Após um mês e meio, chegou-se à conclusão de que o Value Streams funciona muito bem em produtos acabados, mas geralmente é ineficaz quando um produto precisa ser gravado do zero.

Como todas as verdades simples, você as entende somente depois de andar descalço e até mesmo deixar a corrente passar pelo ancinho.

Tudo novo é bem esquecido de idade.

Vamos devolver tudo como estava

Após a transformação triunfante do Agile, decidimos fazer tudo como em 2016, porque o direito à democracia deve ser conquistado.

Para que todos tenham o direito de votar, e esse direito seja reivindicado e usado, é necessário formar as regras e o ecossistema em que trabalhará.

Quando não há ecossistema, algumas coisas precisam ser feitas de forma autoritária, para que as regras sejam formadas.

Fez o seguinte:

• Eles trouxeram as pessoas de volta para a ala dos timlids, redirecionando-as da programação orientada a recursos para a programação normal.
• Os gerentes de produto foram designados para usuários de fluxo. No nosso caso, isso é download, autorização etc.
• Tentamos formalizar todos os requisitos para um novo produto, com os quais concordamos no início do desenvolvimento.

Tudo parece ser lógico, mas há dois anos, enfrentamos os mesmos problemas.

Não vai funcionar, mais uma vez problemas na organização

Os principais problemas de dois anos atrás foram: centralização e tomada de decisão.

O autoritarismo leva ao surgimento de "gargalos" - líderes de equipe, gerentes técnicos e gerentes de produto que não têm tempo para transmitir recursos ao desenvolvimento. Um produto que foi serrado por 8 anos antes é difícil repensar em alguns meses. Não é legal quando 80% do conceito está pronto e 20% (exatamente onde está a celulose) ainda não está lá. Isso irritou e aborreceu bastante a equipe.

Quando os desenvolvedores retornaram formalmente ao gerenciamento dos líderes de equipe, houve muito menos comunicação ao vivo com os gerentes de produto e houve a necessidade de formalizar o TK. O que foi perfeitamente substituído pela comunicação verbal novamente se transformou em formalismo - ele voltou, ninguém o devolveu. Mas os engenheiros estão dispostos dessa maneira, são ensinados no instituto: há uma declaração de problema - precisa ser resolvida, não há declaração de problema - o mundo está falhando, o algoritmo não funciona.

No processo, erros e erros de cálculo foram descobertos, tanto lógicos quanto arquitetônicos. Imagine criar código por vários anos, e todo esse tempo você deseja refatorá-lo e, quando surgir a oportunidade, acontece que todas as idéias e conceitos não são muito bons ou nem funcionam. O sonho acaba sendo falso.

Ao mesmo tempo, como geralmente ocorre na avaliação de prazos, uma empresa ouve uma coisa, o desenvolvimento ouve outra. Além disso, o negócio ainda se divide em dois, e então começa a pressionar os prazos e deseja obter um novo produto ontem. Na hora X, verifica-se que o desenvolvimento acha que ainda há 3-4 meses, e o negócio estava aguardando o lançamento ontem. Todo mundo está chateado, a equipe começa a chorar.

O que voce fez

Realizamos uma retrospectiva em larga escala sobre como vivemos e revelamos o que é mais preocupante para desenvolvedores e líderes de equipe.

A necessidade de refazer a funcionalidade , e geralmente 3 vezes. Para ser sincero, exatamente metade dos problemas estava do lado da declaração do problema, a segunda metade estava do lado da implementação. No entanto, os desenvolvedores, é claro, estavam firmemente convencidos de que todo o problema estava na formulação do problema. No lado da tarefa, os diretores eram os mesmos. Ninguém quer se considerar errado ou culpado, todo mundo diz que o problema está do outro lado.

Suporte para o aplicativo antigo . Um serviço com uma audiência multimilionária não pode ser simplesmente abandonado. Paralelamente à escrita de um novo produto, algo precisa ser feito com o antigo. Isso é terrivelmente chato!

Implementação de um sistema de design. Estamos muito orgulhosos dessa direção: ela realmente permite que você faça rapidamente coisas muito complexas, e o produto parece uniforme. Mas eu tive que treinar designers sobre o que é JSON, e os designers tiveram que transmitir aos desenvolvedores que a aparência também é muito importante. Muitas cópias foram quebradas sobre isso.

Falta de informações e respostas para a pergunta "Por quê?". Sem o fluxo de valor, alguns desenvolvedores não entendem mais por que estão fazendo algo. Houve uma interrupção na transmissão de informações e a relação causa-efeito desapareceu parcialmente. Aqueles que encontraram forças para perguntar por que estávamos fazendo isso ficaram felizes. Pessoas pouco comunicativas pensavam que idiotas estavam sentados em algum lugar no andar de cima que inventam coisas que não podem ser projetadas.

Falta de documentação sobre novas regras de negócios. Devido à falta de informações, havia uma falta de documentação na qual seria explicado como o aplicativo deveria funcionar corretamente.

Todo mundo experimentou o papel de arquiteto, e nem todo mundo gostou. Para mim, foi a maior descoberta. Pela primeira vez, os líderes de equipe estimaram os prazos para o processamento de aplicativos em cerca de um ano e meio, o que é inútil. Isso aconteceu porque cada líder de equipe queria deixar passar todas as partes do sistema, ou seja, ele realmente não queria delegar e decompor a arquitetura do aplicativo, mas queria manter tudo para si.

Com essa abordagem, você realmente precisa de um ano e meio para refazer a arquitetura. Mas com tais termos neste mundo não há nada a fazer. Portanto, após longas discussões, chegamos à conclusão de que as funções arquitetônicas do líder de equipe devem ser delegadas a certos lutadores experientes do desenvolvimento em determinadas áreas-chave que, entre outras coisas, queriam participar e se sentir como um arquiteto.

Acabou sendo um fato interessante - acontece que assumir responsabilidades é desagradável.

Chamar a si mesmo de arquiteto ou líder de equipe e ser líder de equipe são duas grandes diferenças. Nem todo mundo acabou pronto para aceitar que, se você tomar cuidado e desperdiçar uma conversão, isso será apenas de sua responsabilidade.

Eu era ingênuo e, por algum motivo, achava que todos em nossa equipe possuíam tanta coragem. Esqueci que antes de Timlid você precisa amadurecer e crescer um pouco. Ao longo do ano, muitos de nós passaram por essa direção, e alguns perceberam que não queriam crescer, mas em amplitude, e não queriam ser líderes de equipe.

Como consertar a situação

Além da decomposição e diferenciação dos papéis do timlid em várias áreas arquitetônicas, formamos as chamadas Unidades de Retaliação Voadora (VOC) e atraímos especialistas em controle de qualidade (QA). Primeiro, eles eram mais livres do que todos - ainda não há um produto novo, e você pode escrever casos de teste e suítes de testes para regressões subseqüentes agora.

Depois, descobriu-se que as regras de negócios ainda não foram totalmente formuladas e a empresa não possui muitas pessoas que sabem como o novo aplicativo deve funcionar.

Definimos as seguintes tarefas para o controle de qualidade:

• Precisamos de documentação atualizada sobre regras de negócios e a lógica na qual o aplicativo funciona.
• São necessários adeptos da nova lógica de negócios, e não apenas gerentes e gerentes técnicos.

Como temos um novo aplicativo e precisamos fazer tudo de novo, precisamos de pessoas que possam fazer perguntas como: como lidar com esse erro, como o aplicativo deve se comportar em tal situação. Repito, os principais casos foram descritos, mas o diabo está nos detalhes - esses mesmos 20% precisavam ser fechados.

Começamos a criar microcommandos dinâmicos. Apesar de as pessoas não terem sido transplantadas em lugar algum, mas ligadas a um produto de uma direção específica, uma pessoa do controle de qualidade que metodicamente estava envolvida no trabalho do projeto, a saber, era responsável por:

• coletando perguntas dos desenvolvedores, criando questionários;
• organização e gravação de reuniões;
• formalização de documentação;
• escrevendo casos de teste e suítes de teste com antecedência.

Quando chegamos à linha de chegada, isso nos permitiu conectar terceirizados, terceirizados para testes, a fim de aumentar a velocidade de preparação para o lançamento. Temos um grande número de plataformas, o que listei são apenas as ferramentas com as quais trabalhamos. Por exemplo, na SmartTV, existem 6-7 plataformas, para cada uma das quais você precisa liberar separadamente, faça uma regressão separada etc. Se você tiver casos comerciais pré-registrados, poderá conectar facilmente terceirizados e terceirizados aqui.

A introdução de VOCs aliviou bastante os Timlids. Eles tiveram a oportunidade de não se distrair com as tarefas gerenciais, mas de tomar decisões estratégicas sobre o desenvolvimento do código com base no material desenvolvido.

O projeto “Os Esquadrões Voadores da Retribuição” atendeu às expectativas e entramos na linha de lançamento sem nos matarmos.

O que vem a seguir?

2018 , — , , . . , , . «, ,» — .

, , 2016 Value Stream. , . , , . .

, , .

, , . , , , 2018 4 . , , , .

.

.

— . , , , , , . -, , .

: , , , . . .

O programa TeamLead Conf de São Petersburgo está quase pronto. Vamos fazer algumas execuções, adicionar os retoques finais para revelar todos os tópicos planejados e começar a falar sobre os relatórios em blocos. Por enquanto, você pode avaliar independentemente a lista de relatórios e reservar os dias 23 e 24 de setembro para aprimorar as habilidades dos colegas de equipe.