Oh, meu código: como se tornar um líder de TI

Como se tornar um diretor técnico, o que fazer em situações de emergência, como alcançar salários mais altos e crescimento na carreira, além de como o desenvolvimento do Am.ru funciona - falamos sobre isso na décima quarta edição dos talk shows para programadores “Oh, meu código”.


O anfitrião do programa é Pavel Shcherbinin, diretor técnico de projetos de mídia, convidado - Alexander Melnichuk, diretor técnico do Am.ru.

Conte um pouco sobre você.
Eu me formei no ITMO. Ele tentou estudar na faculdade, estava envolvido em difração de raios-x em ângulo pequeno. Então a era da Internet começou, todos começaram a fazer portais. Em 2009, um amigo meu ligou e disse que seu amigo Oleg queria iniciar seu projeto e montar uma equipe em São Petersburgo. Nós nos conhecemos no metrô. Desde então, trabalho na am.ru. Durante a primeira reunião, Oleg contratou imediatamente duas pessoas: eu, então o gerente de desenvolvimento, e Sergey, o desenvolvedor principal. Ou seja, escrevemos as primeiras linhas de código.

"Venha ao nosso diretor técnico?" - “E quantas pessoas teremos sujeição?” "Até agora, só você."
Ninguém falou sobre o diretor técnico então. "Diretor Técnico" é geralmente uma posição muito estranha. Por um lado, esse é um tipo de gerenciamento, por outro - um especialista técnico. Existem diferentes variações. Por exemplo, quando um CTO escreve muito código. De fato, este é um desenvolvedor líder. Então ele geralmente tem um descontentamento sério com vários trabalhos gerenciais. No meu caso, o oposto é verdadeiro. Eu gerencio equipes 100% do meu tempo. Parei de escrever código a partir de 2009, porque simplesmente não há tempo para isso. Eu posso escrever, mas depois tenho que me enviar para o time inimigo.

Mas você ainda é o diretor técnico. Você deve estar ciente do desenvolvimento da tecnologia, saber como o frontend e o backend estão se desenvolvendo.
Eu leio, assisto, comunico-me constantemente com os desenvolvedores. Eu entendo o que é feito e como. E então, antes disso por 8 anos, eu mesmo escrevi algo. Claro, isso não era ciência do foguete. Mas eu posso ler o código agora.

Como se tornar um diretor técnico?
Primeiro de tudo, você precisa querer se tornar um. Isso não quer dizer que um CTO seja algo super legal, melhor do que qualquer outra coisa. Todas as profissões são boas. Você pode ser um desenvolvedor feliz e se divertir. Você precisa ser um diretor. Fazer tarefas administrativas é uma certa habilidade. Você precisa entender que, na maioria dos casos, não escreverá código. Às vezes, nas vagas, eles indicam que você precisa de um diretor técnico com conhecimento do Symfony e até remotamente. Em geral, algum tipo de inferno. Essas pessoas estão se enganando. E, às vezes, um arquiteto é entendido como um "diretor técnico", e isso também é bastante comum.

Quantas pessoas estão na sua equipe agora e qual é a sua estrutura?
43 pessoas. A estrutura é plana, ou seja, todas essas pessoas são subordinadas administrativamente a mim. Não temos gerentes de projeto nem líderes de equipe. Mas uma estrutura lógica suficientemente desenvolvida de 5 equipes separadas, de perfil estreito e amplo, que estão envolvidas em várias áreas ao mesmo tempo. Todas as equipes são completamente independentes, trabalhando nos locais dos projetos. Eles têm autogoverno, e isso é muito bom.

As tarefas passam por você ou diretamente para a equipe?
Claro, diretamente para a equipe. Se eles passassem por mim, provavelmente eu teria morrido há muito tempo, porque o fluxo de tarefas é enorme. Minha função é reduzir as comunicações ao mínimo necessário. Se uma pessoa precisa de algo, ela deve saber onde obter esse conhecimento, com quem conversar diretamente.

Certamente muitos de nossos leitores terão uma pergunta: por que você precisa de você? As tarefas vão diretamente para a equipe, as equipes são legais e auto-organizadas. Parece que o diretor técnico nem existe.
Um amigo meu disse uma vez que a tarefa do diretor é criar um trabalho em equipe para que ele possa ser demitido facilmente. Estamos nos esforçando para isso, mas ainda não o alcançamos.

Um desejo interessante de ser demitido.
Sonhos, sonhos ...

Você não acha que muitos aspiram aos cargos de líderes e diretores com o objetivo de trabalhar menos?
Ontem eu saí do trabalho cerca de 22 horas. Sendo um CTO, muitas vezes invejo os desenvolvedores. Isso é maravilhoso: chegou, você tem uma tarefa que gosta, você mesmo escolheu, fez, viu o efeito. Tudo é super. Cansado - bebeu café, jogou, descansou. Se você tiver alguma dificuldade, conversou com seus colegas e concluiu a tarefa. Você pode colocar seus fones de ouvido, ouvir sua música favorita e fazer seu trabalho. Se você se sentir mal, poderá trabalhar em casa, poderá inventar algo à noite.

O diretor técnico está completamente errado. Meu dia normal começa com uma folha de papel A4, onde escrevo o que quero fazer hoje. Eu escrevi. Então ainda isto, isto, então eu pego a segunda folha, depois a terceira. Eu apago as tarefas durante o dia. Existem muitos, são pequenos, mudam constantemente. Quando você faz uma coisa, o seguinte e o seguinte surgem.

Às vezes acontece que à noite você tem que terminar alguma coisa, e uma hora antes disso, novas mensagens introdutórias aparecem. E você precisa repetir tudo. Este é um mundo que está mudando constantemente. Esse é o principal problema. Não tenho nenhuma grande tarefa, tenho um grande número de pequenas tarefas pelas quais preciso tomar decisões constantemente. Isso é complicado.

Você pode falar sobre as tarefas repetidas com mais frequência ou, por exemplo, algo interessante de ontem? O que está incluído nas suas principais tarefas?
A principal tarefa é que tudo funcione, que sejamos liberados sem demora, dentro do cronograma, para cumprir as tarefas definidas pelo gerenciamento do produto, para que os projetos sejam entregues dentro do prazo. Como vou fazer isso são minhas dificuldades. As dificuldades são muito diferentes. Por exemplo, as pessoas vieram ao data center para descarregar os servidores e o carregador não foi permitido, porque ele tinha um passaporte suspeito. Ou os agentes de segurança pedem algumas informações e você precisa encontrar alguém que as forneça. Ou o produto está mudando, respectivamente, novas tarefas e prazos aparecem, você precisa de alguma forma integrar essas tarefas no plano e resolvê-las.

Como o Agile se encaixa no seu sistema de desenvolvimento?
Vivemos inteiramente no Agile. Temos equipes trabalhando no Scrum, e há equipes trabalhando no Kanban. Eu nem sei como poderíamos ter passado sem isso. Era uma vez, quando eu ainda não conhecia esse termo, tentamos construir um sistema semelhante, mas não tivemos êxito porque era uma iniciativa sem um livro didático, com um toque. Por exemplo, há muito tempo uma “alergia” para gerentes de projeto e pessoas que precisam distribuir tarefas e pintar quadrados. Eu nunca tive gerentes de projeto.

Como é o trabalho da equipe?
Temos um CPO comum (principal proprietário do produto. - aprox. Ed.), Que diz como o produto se desenvolverá. Além disso, existe um número de APO (proprietário do produto Area. - aprox. Ed.), Responsáveis ​​por suas áreas. De fato, a estrutura organizacional é um pouco mais complicada, mas descrevo a lógica. Cada direção tem uma equipe separada. As equipes recebem tarefas do APO e, às vezes, se definem. As tarefas são adicionadas à lista de pendências geral, a lista de pendências do sprint é formada e, em seguida, concluída.

No início de cada sprint, o planejamento é feito. Separadamente em todas as equipes. Surge a pergunta: “E a coordenação de objetivos comuns?” Existe um planejamento geral no nível do proprietário do produto. Aqui estão as tarefas previamente coordenadas entre as direções. Além disso, precisamos de coordenação técnica, que é realizada de várias maneiras.

Se um funcionário precisa de coordenação com outra equipe, ele chega ao stand-up e diz que ele tem esse e aquele problema, pede ajuda. Chamamos esses funcionários de "escoteiros".

Além disso, temos uma reunião técnica geral, Master Sync, que reúne desenvolvedores e representantes de todas as equipes, sem proprietários de produtos. Nele, resolvemos apenas problemas técnicos, discutimos como resolvê-los corretamente, como sincronizar uma tecnologia comum. tarefas entre equipes. Às vezes, no Master Sync, são formuladas tarefas executadas por funcionários de duas ou mais equipes ou colocadas em um backlog comum para uma solução conjunta adicional.

Para elaborar um plano, é executado um PBR (refinamento da lista de pendências do produto. - Aprox. Ed.). Os desenvolvedores avaliam tarefas e ajudam os proprietários de produtos a fazer planos e priorizá-los. A PBR pode ocorrer tanto em uma equipe quanto entre várias equipes. Às vezes, o planejamento é realizado com uma equipe externa, se o produto envolver integração.

Termina com uma demonstração semanal do produto. Quem quiser pode vir. Estamos transmitindo online. Os proprietários do produto assistem, assistem ao CPO, às vezes marketing, pessoal de vendas, suporte. As equipes falam sobre recursos implementados, APIs, documentação, testes e tudo o que foi feito. Os envolvidos em arquitetura ou administração podem falar sobre suas decisões e planos. Ou seja, a demonstração é um tipo de marco comum que mostra os resultados do trabalho de toda a equipe em uma semana ou duas, dependendo da duração do ciclo da equipe.

Além disso, cada equipe realiza sua própria retrospectiva, sobre a qual são discutidas questões organizacionais. Se a equipe não puder decidir algo dentro de si mesma, as perguntas serão submetidas ao retroentro da equipe. Realizamos uma vez a cada duas semanas e decidimos o que se aplica a todas as equipes, todo o escritório e todo o produto. De acordo com os resultados do retro, a cada tarefa é atribuída uma pessoa responsável que pode resolvê-la ou seguir sua decisão, se depender de serviços externos. Para o próximo retro ou Master Sync, os responsáveis ​​contam o que fizeram ou não, por quais razões, quais vantagens e desvantagens foram reveladas.

Conte-me sobre uma situação inesperada e anormal.
Situações anormais acontecem, mas cada vez menos. Por exemplo, uma vez em nosso site, todas as JS na área de trabalho pararam de funcionar. O mais importante era encontrar a causa do problema e resolvê-lo. Falando em termos científicos, recorremos à metodologia Andon: paramos todos os processos, toda a equipe procurou uma razão. Encontrado com rapidez suficiente. Foi necessário mais tempo para resolver o problema.

Qual foi o motivo?
Adicione um pouco mais de óleo ao fogo. No front-end, não atualizamos nada. E por que tudo quebrou, ninguém entendeu. Mas quebrou todos os lugares imediatamente. Acabamos lançando uma pequena ferramenta utilitária, que exibia uma biblioteca JS de terceiros, que apresentava um erro. Esta biblioteca foi substituída imediatamente em todo o código. Como resultado, JS choveu. Ninguém esperava que uma ferramenta completamente estranha no painel de administração do sistema de controle pudesse quebrar tudo.

Você mencionou a metodologia Andon. O que é isso
Todo mundo tem algum tipo de especialização. Sou o diretor técnico, existem desenvolvedores de front-end, desenvolvedores de dispositivos móveis, administradores de sistema, DevOps etc. Parece que se eu sou um programador de C ++, escreverei em C ++. Mas se o front-end quebrou JS? " O que é JS? Algo incompreensível das humanidades, eu não farei isso. - Mas geralmente sou um administrador de sistema ou DevOps. Não tenho nada a ver com isso, use seu próprio JS .

Andon foi projetado para evitar tais situações. Nosso projeto quebrou, é o nosso comum. Estamos todos começando a procurar onde ele quebrou. No caso descrito por mim, o motivo foi encontrado pelo desenvolvedor de back-end habitual, que apenas se sentou e começou a procurar, sem dizer que não escrevia em JS, que não sabia de nada. Ou seja, Andon reside no fato de que todos desistem e começam a resolver o problema o máximo que podem.

Você disse que o problema surgiu devido a algum tipo de utilitário interno do sistema. Você não usou contêiner, o que é muito popular agora?
Não.

Agora você tem uma janela de encaixe em produção?
Sim

Ou seja, você mudou ativamente para o Docker e o usa?
Esta é uma das principais direções do nosso trabalho.

Quais são as suas impressões?
Bom Eu nem sei como viveríamos sem ele. Anteriormente, tínhamos PHP - vamos nos livrar dos scripts e eles começaram. E agora você não pode mais viver sem contêineres.

Você, como diretor técnico, está envolvido na "saúde" da equipe. Conte um pouco sobre isso.
Uma das minhas principais qualidades: eu gosto de ouvir as pessoas. Estou tentando me colocar no lugar deles, isso possibilita entender o humor, os problemas, por que eles tomam certas decisões, por que sentem isso. E isso me ajuda a encontrar o caminho certo para sair da situação, tomar a decisão certa. Para mim, a “saúde” da equipe, o “bem-estar” de cada pessoa é extremamente importante: é bom para ele, ele está confortável na equipe, quais objetivos ele está se movendo, o que ele deseja alcançar.

Certa vez, um desenvolvedor disse em uma conversa pessoal: “ Eu costumava sonhar em me tornar um técnico ou diretor técnico para obter mais dinheiro, ter poder e assim por diante. Agora eu trabalho em uma estrutura plana, não temos techlide. Mas há um diretor técnico que executa tarefas gerenciais e os desenvolvedores tomam decisões técnicas. Onde devo apontar? Como eu moro? Os princípios da vida estão quebrados. Não está claro para onde ir mais longe . "

Gradualmente, percebi que não era esse o ponto. Um homem deve ser feliz. As tarefas que ele executa, ele deve gostar. E ele pode escolhê-los por si mesmo. A carreira oferece crescimento financeiro, mas pode ser alcançada de outra maneira: você resolve problemas mais complexos, ajuda os outros, sua equipe trabalha mais rápido, fornece recursos complexos mais rapidamente. Tanto para o crescimento da carreira, salário, taxa está crescendo. Alterações na pasta de trabalho são secundárias. Trabalhe bem - você desfruta disso. E se isso afetar positivamente o produto, o salário aumentará e a posição na pasta de trabalho mudará.

Como se tornar um líder de equipe?
Você pode simplesmente não ser. O significado do trabalho em equipe é fazer o que você gosta. Na minha prática, houve casos em que uma pessoa foi prescrita com timlid a seu pedido. Bem, escrevemos um memorando, mudamos a entrada no trabalho, aumentamos o salário. Ao mesmo tempo, a pessoa diz que é um líder de equipe, mas a equipe não o reconhece.

Acontece o contrário: uma pessoa explica à equipe como fazer algo e a equipe a reconhece. Estes são os melhores líderes de equipe. Se você quer se tornar um líder de equipe, você será. E se você não quiser, não vai.

Você diz que gosta de ouvir os desenvolvedores, dá muitos exemplos quando eles dizem alguma coisa. Mas os desenvolvedores geralmente são introvertidos; às vezes é difícil extrair uma palavra deles. Como você lida com isso? Como falar com o desenvolvedor?
Todos os introvertidos. Todo mundo odeia pessoas. Esse não é o ponto. Trabalhamos juntos. Eu tento conversar com as pessoas individualmente, de vez em quando. É extremamente útil obter feedback. Uma vez eu não conseguia entender o que estava acontecendo com uma pessoa. Então concordamos que nos encontraríamos uma vez a cada duas semanas e conversaríamos. E depois disso, tudo correu bem. Digo a ele que não gosto dele, ele me diz que não gosta dele. Encontramos pontos em comum, tomamos decisões, discutimos o que faremos a seguir dessa maneira. E seguir em frente. Funciona muito bem. Precisamos nos comunicar mais.

Nossa pequena pesquisa blitz. Qual sistema operacional você escolherá?
Mac OS

Qual é o melhor IDE?
JetBrains

O último aplicativo, site, startup que impressionou você?
Mobile Banking do Tinkoff Bank.

Qual é o melhor: uma startup ou uma grande empresa?
Se você quer apenas viver confortavelmente e ser pago, vá para uma grande empresa. Se você constantemente se enfurece, quer movimento, adrenalina, aventuras, uma startup é tudo para você. Não há necessidade de ir para uma startup se você quiser apenas muito dinheiro. Isto não é assim.

Ontem, a tendência era móvel primeiro. Hoje é o aprendizado de máquina primeiro. O que acontecerá amanhã?
Em um treinamento, eles disseram que existem pessoas especiais que determinam o que acontecerá amanhã, até empatam cartas sobre esse assunto e as vendem por dinheiro. O aprendizado de máquina é uma espécie de exagero. Há também big data, realidade virtual, nano e biotecnologia. Vi um mapa semelhante: uma espécie de emaranhado de gravatas emaranhadas que se movem em direções diferentes. Previsões ao nível da astrologia. Eu diria que amanhã não haverá aprendizado de máquina, mas big data. Já se sabe muito sobre qualquer pessoa que esteja online. Você só precisa aprender como usá-lo corretamente. Esse conhecimento é coletado, processado, é uma fonte de renda.

Quando os robôs substituirão você?
Podemos dizer que eles já foram substituídos. Eu comprei um aspirador de pó robô.

Como você valoriza as tarefas: em horas ou nos Story Points?
Tanto nos Story Points quanto em horas. Quem quer isso.

Que última coisa você não poderia pagar?
Subaru Ascent.

Quantos bitcoins você tem?
Zero

Não está interessado neste tópico?
Isso é hype.

O que seus amigos costumam perguntar sobre am.ru?
Quando dominamos o mundo.

E quando?
Em breve.

Source: https://habr.com/ru/post/pt414179/


All Articles