A reunião foi realizada como parte da série “Engenheiro entra em um bar”, onde engenheiros de diferentes empresas de TI falam sobre tópicos profissionais não relacionados à engenharia. Uma série de eventos foi organizada por engenheiros da empresa Miro , com o apoio do Dolgushev e Storozhilov DevRel-bureau .
O segundo encontro da série será no dia 20 de agosto. O assunto é toxicidade em equipes, empresas e indústria. Palestrantes - engenheiros e líderes técnicos de Miro, SEMrush, Parma TG, Xsolla. As inscrições já estão abertas .
Índice:
- As especificidades da empresa e o sistema atual de desenvolvimento profissional de engenheiros
- Desafios nos sistemas de desenvolvimento atuais
- Como implementar uma cultura de desenvolvimento no início de uma nova equipe
- Questão quente sobre dinheiro
- Como você defende em uma empresa que os funcionários precisam de uma porcentagem de seu tempo para educação e desenvolvimento?
- Pesquisa de ferramentas de desenvolvimento profissional
As especificidades da empresa e o sistema atual de desenvolvimento profissional de engenheiros
Artyom Susekov, Chefe de Engenharia de Software de Produto, Miro. Criamos um produto para colaboração online de equipes, uma plataforma de quadro branco colaborativo online. A empresa emprega 400 pessoas, pouco menos da metade são engenheiros. Escritórios de desenvolvimento de produtos - em Perm e Amsterdã. As equipes são multifuncionais: engenheiros, gerentes de produto, designers e, se necessário, profissionais de marketing. Eles usam scrum, alguns usam kanban. Para planejamento - OKRs no nível da campanha e no nível da equipe individual.
Temos notas, as expectativas de cada um são formuladas na forma de exemplos específicos de comportamento (padrões de comportamento). Isso é feito para não se deter apenas em expectativas formais ("para fazer tantas tarefas, obtenha tal e tal certificado"). O mais importante é que o conhecimento adquirido seja aplicado no dia a dia do trabalho, é isso mesmo que se demonstra nos exemplos específicos que são descritos para cada uma das séries.
Classes padrão: Junior, Middle, Senior, existem várias etapas dentro de cada série. Há oportunidades após o Sênior se tornar um especialista técnico ou se tornar um líder de equipe e depois um gerente de direção.
Existe uma Avaliação de Desempenho, que realizamos duas vezes por ano. Durante ele, você recebe feedback de seus colegas de equipe, os líderes de equipe recebem feedback daqueles que são subordinados diretos deles. Além disso, o funcionário faz a autoavaliação, ou seja, ele avalia seu trabalho de forma independente.
Os resultados são resumidos, após a qual é realizada a Conversa de Carreira: o que deu certo, o que deu certo, o que deve ser enfatizado no futuro, o que deve ser trabalhado. Em seguida, o gerente ajuda a formular um plano de desenvolvimento para os próximos seis meses ou um trimestre.
Career onversation ( , , ), : , , .Alexander Borisov, Chefe do Centro de Competência em Tecnologia Innopolis, X5 Retail Group. Provavelmente, quase todos estão familiarizados com o X5. Somos proprietários das cadeias Perekrestok, Pyaterochka e Karusel. Se há três anos éramos uma empresa que vende tomates, agora estamos nos esforçando para nos tornar uma empresa de TI que vende tomates.
A maior parte do lucro vem de nossos serviços de TI. Como funciona a Pyaterochka e quais os preços que ela dá, talvez devido a uma logística bem construída e um sistema de gestão para este grande processo. Temos mais de dois mil especialistas em TI na empresa, são quase 150 pessoas só em Innópolis.
No ano passado, tudo isso começou a se transformar de um formato de departamento para um formato de equipe de produto. Dividimos os serviços e produtos em microsserviços e subprodutos, pelos quais uma equipe pode ser responsável. Agora temos Product Owners para cada produto, equipes multifuncionais, cada uma das quais com desenvolvedores, testadores, analistas e parte das funções nas quais as pessoas podem se sobrepor.
Naturalmente, temos reuniões individuais, OKRs, feedback 360. De interesse é a função de proprietário do pool de recursos. Essas são as pessoas responsáveis pelo conjunto Java, JS, Python, testes, análises, etc. Cada engenheiro da empresa tem um gerente de negócios (Product Owner) que entende quanto uma pessoa investe em um produto e quanto lucro seu trabalho traz, e existe uma pessoa que é responsável pelo desenvolvimento técnico em sua competência específica.
Abandonamos a formalização da transição entre as séries do tipo “passar do Júnior mais para o Meio menos, você precisa fazer isso e aquilo”. Tememos que, se dermos critérios claros para a transição, as pessoas comecem a abordar isso de maneira muito formal. Mas a formalidade aqui é prejudicial, pois em cada equipe tudo pode ser muito individual: uma e a mesma pessoa pode assumir mais responsabilidades e por isso desenvolver, ou bombear em um estreito segmento de tecnologias que são específicas para nós, e por isso se torna mais valioso para o negócio.
Para os cargos seniores, a difusão do conhecimento é um pré-requisito importante para o crescimento. Você não é um Sênior no vácuo, você compartilha sua experiência com a equipe e puxa o resto com você.
Sergey Averyanov, CTO, Funbox. Há mais de 10 anos desenvolvemos software para as três grandes operadoras. No momento, temos cerca de duzentos desenvolvedores de vários perfis e um número bastante grande de especialistas técnicos em suporte técnico.
Por um lado, não temos um único produto que envolva toda a equipe e, por outro lado, não existe um grande fluxo de projetos e tarefas como no outsourcing. É aqui que cresce nosso desenvolvimento profissional específico de engenheiros. Abandonamos deliberadamente os sistemas de classificação formal: talvez seja isso que a administração e os próprios funcionários gostariam, mas é um sistema extremamente inflexível que tenta estilizar a todos com o mesmo pincel, o que nem sempre é possível na prática. Em vez disso, usamos coisas razoavelmente padronizadas: avaliação periódica do progresso do funcionário e conversas individuais. Temos a oportunidade de avaliar objetivamente a contribuição de cada um pelo Task Tracker. Tudo isso em conjunto nos dá uma compreensão do nível de cada um dos engenheiros.
Por outro lado, um dos nossos principais objetivos é fazer com que cada pessoa compreenda como e onde pode se desenvolver. Procuramos levar em conta o fato de que todas as pessoas são diferentes: alguém se interessa em trabalhar como especialista técnico, comunicar-se minimamente com as pessoas e não mergulhar nas coisas administrativas; alguém quer se comunicar, trabalhar com pessoas, participar do desenvolvimento dos colegas. Tudo isso é normal, todas as opções de desenvolvimento são possíveis.
Estamos tentando construir um sistema que nos permita elevar o nível dos engenheiros e dar-lhes uma orientação clara sobre o que a empresa deseja deles e para onde podem ir em seguida. Também damos muita atenção ao crescimento interno. Eu e toda a equipe acreditamos que o melhor especialista é o especialista que criamos dentro da equipe. Por isso, estamos investindo ativamente no desenvolvimento interno, em encontros, conferências internas e externas. Este também é um dos principais objetivos - o desenvolvimento pleno e de alta qualidade de todos os nossos engenheiros.
Um departamento de desenvolvimento de abstratos não deve estar envolvido no desenvolvimento de funcionários. Esta é uma das responsabilidades do gerente de linha.
Essa abordagem é uma vantagem para nós e para os próprios funcionários. Por um lado, temos um crescimento orgânico constante do quadro de funcionários. Por outro lado, podemos transformar os juniores em juniores seniores e líderes de equipe, e o próprio funcionário vê que seu supervisor imediato é aquele que era junior neste projeto há quatro anos, o que significa que antes de colaborar agora as mesmas oportunidades e passos compreensíveis para crescimento.
Mikhail Mazein, líder de engenharia, ManyChat.Estamos desenvolvendo uma plataforma de marketing SaaS que permite que você organize a comunicação entre empresas e seus clientes. A empresa está crescendo ativamente: há três anos havia 15 pessoas na equipe, agora somos mais de 120. Nos primeiros estágios, trabalhamos com equipes funcionais clássicas: back-end, front-end, teste, equipes de design. Cada equipe tinha um líder que era responsável pelo planejamento do sprint e pela decomposição de tarefas.
No processo de crescimento, percebemos que isso estava nos impedindo de avançar na velocidade desejada e reformatamos o trabalho em equipes multifuncionais. Agora temos nove dessas equipes multifuncionais, não há líderes de equipe, pois as equipes se mostraram auto-organizadas e podem ser responsáveis pela forma como trabalham.
Para sincronizar coisas funcionais, desenvolvemos abordagens comuns para que o desenvolvimento não se transforme em anarquia. Isso é necessário, por exemplo, quando os desenvolvedores de back-end são distribuídos por equipes diferentes, mas trabalham com um projeto, com uma base de código e confirmam o código lá. Organizamos comunidades funcionais para resolver esses problemas. Com o tempo, líderes informais aparecem em comunidades que conduzem processos e comunicações. O resultado é uma estrutura plana que não limita o papel do desenvolvedor ao papel de um engenheiro que apenas escreve código, mas permite que você faça várias coisas que são úteis para a empresa e ao mesmo tempo interessantes para a própria pessoa.
Como abandonamos o papel de líder de equipe, precisávamos de um processo que nos permitisse construir de maneira clara e transparente trilhas de crescimento para engenheiros. Para isso, utilizamos um sistema de mentoring: cada colaborador tem um mentor que é responsável pelo seu crescimento e desenvolvimento dentro da empresa.
Você não pode simplesmente ir até uma pessoa aleatória e dizer: "Deixe você ser um mentor." Em primeiro lugar, vários fatores devem ser reunidos: o desejo da própria pessoa; alto nível de confiança na equipe para a pessoa; confiança da própria empresa e da gestão. Uma das tarefas de um mentor é levantar novos mentores. Acontece que esse brotamento, de mentor para mentor.
Nós distinguimos três vetores principais de desenvolvimento:
- A primeira grande trilha é um trabalho mais profundo na equipe de produto para o desenvolvimento do produto, com uma compreensão mais profunda dos valores e métricas do negócio.
- – , , .
- – , .
Tentamos também criar um sistema de notas: ainda não podemos descrever formalmente todas as notas, então o sistema é construído no nível da contribuição de uma pessoa, no nível da equipe, no nível de toda a empresa. Descrevemos as expectativas em cada nível, qual área de responsabilidade ou área de influência esperamos de uma pessoa, com exemplos claros. O mentor, por outro lado, pode dizer a uma pessoa quais habilidades precisam ser aprimoradas para chegar ao ponto desejado.
Anton Grishin, chefe de desenvolvimento, MadRobots. À primeira vista, nossa empresa é um e-commerce que lida com gadgets, mas em geral estamos engajados na distribuição na Rússia e no desenvolvimento de marcas de coisas legais.
Nossa equipe se reuniu há relativamente pouco tempo, então ainda não temos a dor de cabeça associada ao desenvolvimento de engenheiros dentro da empresa. Antes da Madrobots, trabalhei 6 anos em terceirização, sendo três deles diretamente responsáveis pela produção da agência, e gostaria de contar mais sobre essa experiência.
Na terceirização, a nossa dor foi um grande fluxo de projetos e rotatividade de pessoal, na terceirização sempre é o caso. Decidimos que precisávamos superar isso de alguma forma e começamos a investir no desenvolvimento dos colaboradores.
Sim, tínhamos um sistema de notas, uma vez a cada seis meses uma pessoa recebia feedback de um gerente técnico, construindo com ele seu próprio caminho pelos próximos seis meses.
, . , . , , , .
Posteriormente, tivemos outra dor. No fluxo de projetos, dos quais muitas vezes eram alguns, as pessoas perderam o foco no desenvolvimento pessoal. Não porque eles não tivessem tempo suficiente, mas porque estavam cansados da quantidade de tarefas que tinham de realizar. Introduzimos a prática de encontros um a um, uma vez por mês, que visavam conversar com uma pessoa e lembrar que você tem um plano de desenvolvimento e que realmente deve ser cumprido. Se você precisa de algum tempo para isso e precisa se livrar da rotina ou do constante afastamento, vamos discutir isso, porque seu posto de controle está se aproximando e você precisa fazer algo a respeito. Isso ajudou. Via de regra, isso era feito pelos GPs das equipes, pois quem, senão eles, sabia melhor em planejar recursos para o futuro.
Desafios nos sistemas de desenvolvimento atuais
Artem Susekov, Miro. É difícil equilibrar o sistema de notas imediatamente, então fazemos as iterações. Por exemplo, a primeira versão da trilha do líder da equipe acabou ficando sobrecarregada: expectativas muito altas, um super soldado universal, o que dificilmente é possível na vida.
No momento, estamos tentando simplificar o limite para entrar na função de líder de equipe para tornar mais fácil para as pessoas mudarem de uma filial puramente de engenharia para uma filial de gerente. Eu não quero superestimar a barra, precisamos de uma oportunidade para nos movermos suavemente para este novo campo de atividade.
Outra dificuldade é a abordagem excessivamente formal do processo. Por exemplo, "Acertei 8 de 10 pontos no plano, o que significa que atendi às expectativas e posso passar para o próximo nível." Não queremos transformar tudo isso em uma lista de verificação que você só precisa fechar para passar para o próximo nível, como em um jogo.
Gostaria que as pessoas pudessem pensar em prospectos com base no plano, pensar de forma independente nas áreas que lhes interessam, ou seja, trabalhar com isso como estratégia, e não como uma lista de tarefas formais.
Alexander Borisov, X5 Retail Group. Muitas vezes as pessoas não entendem exatamente como crescer em uma empresa, porque não existem algoritmos claros. Ao mesmo tempo, as pessoas que realmente já podem ser promovidas encontram coisas nas quais podem e devem crescer, coisas que podem ser assumidas e melhoradas. Mas acontece que é preciso “apenas crescer”. Mas provavelmente é impossível crescer na empresa desse jeito, porque você quer crescer.
Você só cresce quando assume mais responsabilidades, novos projetos.
Sergey Averyanov, Funbox . Como trabalhamos há muitos anos, tivemos muitos problemas e desafios. Uma das primeiras é entender com quem queremos trabalhar, com quem queremos desenvolver. Como resultado, chegamos à conclusão de que queremos trabalhar com pessoas que saibam fazer algo bem, e não importa o quê. Aceitamos de boa vontade especialistas de qualquer pilha que estejam prontos para usar o que usamos. Essa se revelou uma prática bastante bem-sucedida: é sempre agradável e conveniente desenvolver pessoas que já tenham competência em uma área relacionada. A lacuna de conhecimento que possuem não é uma falha fatal, mas uma nova motivação para uma pessoa, o estudo de um novo campo de atividade.
O segundo desafio é entender como os engenheiros da empresa podem crescer. Para o desenvolvimento, é necessário criar condições de trabalho confortáveis: um escritório normal, compreensível, simples, mas com procedimentos e normas de trabalho rígidos, conformidade com o Código do Trabalho, antipatia pelo excesso de trabalho. Tudo isso dá à pessoa a confiança de que pode aumentar seu nível sem complicações, sem pressa. Eles vão mostrar a ele, dizer a ele, ajudá-lo.
Você pode gritar com as batatas o quanto quiser: “Batatas, cresçam! Tomates, vamos! ”- mas não vão crescer com isso. Eles precisam de um bom solo e água.
O desafio final é que nem todas as pessoas querem crescer onde queremos que cresçam. Acontece que um especialista forte em hipótese alguma quer lidar com a carga administrativa e trabalhar com colegas mais jovens. Aqui a questão não está nas coisas formais, nem no salário, mas simplesmente no que a pessoa tem interesse e inclinação. É por isso que em todos os engenheiros valorizamos a passionalidade, a capacidade de assumir uma tarefa complexa e realizá-la em um processo de várias etapas do início ao fim. Via de regra, qualquer engenheiro capaz disso é interessante e agradável para nós. Mas, como eu disse, ao mesmo tempo sempre deixamos a oportunidade para uma pessoa se tornar um especialista técnico sem mergulhar em funções administrativas e gerenciais.
Mikhail Mazein, ManyChat... Já é difícil formalizar os requisitos de notas e também não tentamos formalizá-los de forma rígida, focados em exemplos de expectativas do que gostaríamos de ver de um engenheiro em diferentes estágios de desenvolvimento. Tudo isso embrulhado em um impacto específico que as pessoas trazem para os processos em nível de equipe ou empresa.
Isso cria dificuldades. Por um lado, não limitamos as pessoas em crescimento, surge diante delas uma tela em branco, na qual podem traçar seu caminho de desenvolvimento. Mas desenhar uma nova imagem em uma folha de papel em branco é muito mais difícil do que se mover ao longo do caminho conhecido. Resolvemos esse problema com mentoria. Os mentores ajudam a construir trilhas a partir dos desejos das pessoas e sincronizando-as com as necessidades da empresa. Também estamos tentando desenvolver a mentalidade de busca de problemas para que os engenheiros identifiquem os problemas nos processos e tentem iniciar sua solução eles mesmos. Nisso, novamente, os mentores ajudam.
Anton Grishin, MadRobots.Há pessoas para as quais o crescimento é uma necessidade própria, e há pessoas que crescem porque está tão estabelecido em volta e para isso foram criadas as condições. Mas todos eles periodicamente têm uma pergunta - para quê? A motivação pessoal para aprender coisas novas, para o desenvolvimento se perde, porque isso pode não ser aplicável na realidade atual ou com os colegas atuais.
Como uma das soluções, realizamos encontros internos, mas não como hobby group, mas sim como uma conferência interna, com uma preparação real de um novo tema. Uma história positiva emergiu disso, os caras começaram a entender entre si que se, por exemplo, frontends podem fazer algo novo, então nós, designers e designers, podemos repensar nossas abordagens e experimentar novas ferramentas. Acontece que a motivação natural um do outro é tentar fazer algo novo juntos.
A dor sempre evoca a abordagem pessoal de cada pessoa ao seu próprio desenvolvimento.
Como implementar uma cultura de desenvolvimento no início de uma nova equipe
Sergey Averyanov, FunBox: O próprio crescimento da empresa nos ajudou. Quando não há muitos engenheiros, todos cozinham juntos, todos se conhecem e realizam o mesmo tipo de tarefa. E assim que diferentes tipos de projetos e funções neles começam a se alinhar, todas as pessoas se tornam dotadas de poderes diferentes. Alguém executa tarefas, alguém está envolvido em implantações, clusters, alguém está envolvido no design do produto.
É importante para nós que cada membro da equipe entenda o que precisa ser atualizado para passar de desenvolvedor a desenvolvedor de nível superior ou líder de equipe.
, 125 , , , , .
Os encontros internos são muito úteis. Quando uma empresa tem muitas equipes e vários produtos, cada pessoa cozinha em seu próprio molho, e nos encontros eles conversam, contam o que fazem, trocam conhecimentos. Isso não gera competição entre as equipes, mas sim a busca pela excelência.
Artem Susekov, Miro: Em um estágio de crescimento da equipe, várias guildas formadas em torno de tecnologias ajudam muito: backend, frontend, QA. Nas guildas, o conhecimento é trocado entre equipes diferentes.
Os eventos internos também ajudam: encontros, Sprint Reviews públicas, onde as equipes compartilham um contexto comum, falam sobre resultados. É importante aqui ajudar os engenheiros a se prepararem para tais desempenhos.
Alexander Borisov, X5 Retail Group:Você não pode esperar que diga que encontros são necessários e as pessoas começam a se organizar. Eles também precisam ser tratados. No caso de nossa escala, faz sentido destacar as pessoas responsáveis que a organizam. As equipes costumam ter coisas legais dentro, mas cozinham dentro de si, simplesmente não têm tempo suficiente para organizar um encontro e compartilhar suas melhores práticas. Parece que teríamos levado meia hora, reunidos em uma sala de reuniões, e gasto, mas não. Existem algumas nuances.
Mikhail Mazein, ManyChat: Um processo de integração bem estruturado para novas pessoas nos permite transmitir a elas os princípios e abordagens gerais, para formar uma imagem correta da equipe e do projeto. Assim, a cultura com a chegada de novas pessoas vai se acumulando e sendo repassada.
Questão quente sobre dinheiro
Pergunta de um espectador: “Você não está abordando as questões de sustentabilidade financeira da organização. Como é determinada a parcela das despesas da empresa para que o funcionário leia livros durante o expediente? O segundo é um exemplo, deixe a solução de um problema levar 80 horas para um desenvolvedor que já resolveu tal problema, e 150 horas levarão a solução do mesmo problema para um desenvolvedor que não está familiarizado com o contexto, mas ao mesmo tempo ele vai crescer e bombar. A dúvida é quem vai pagar a diferença de 70 horas gastas no desenvolvimento. ”
Alexander Borisov, X5 Retail Group:No nosso caso, não há cliente. Passamos a formar ativamente nossa equipe interna ao invés de continuar terceirizando algumas coisas, porque entendemos que competência é muito cara para nós e resulta em custos finais, em aumentar a marginalidade do negócio, de uma determinada Pyaterochka em sua casa. É um investimento para o futuro.
Mas se uma pessoa, em vez de fazer uma tarefa por três horas por 150 horas, começou a ler um livro, a questão surgirá apenas do proprietário do produto ou do proprietário do pool de recursos. Se este é um investimento compreensível no fato de que uma pessoa cresceu, então, novamente, no nível dessas duas pessoas, isso é facilmente resolvido. Por exemplo, um plano para um sprint, respectivamente, dentro dele colocamos algo que vai precisar ser lido, e nos encaixamos, essa é uma história normal.
Artem Susekov, Miro:Existe um acordo ao nível da empresa que ajudamos os engenheiros a desenvolverem-se através de cursos e workshops, que decorrem dentro do horário de trabalho. Ou seja, a empresa paga por isso, é um investimento em cada membro da equipe, pois acreditamos que esse tipo de investimento vai ajudar toda a equipe a andar mais rápido no futuro.
O tempo específico reservado para o engenheiro para educação dentro do sprint é discutido no nível de equipe específico. É importante aqui que não haja distorções na outra direção, que o tempo todo durante o sprint, apenas estudemos e não façamos mais nada.
Sergey Averyanov, FunBox:Acho que a pergunta sobre 80 e 150 horas é mais aguda para a terceirização, quando você pode perguntar - por que um desenvolvedor inexperiente faria 150 horas por mim, como cliente, se um desenvolvedor experiente fez o mesmo por mim acima dos 80? Como a terceirização resolve isso, não posso dizer, porque não estamos terceirizando. No âmbito de uma empresa de produtos, isso se resolve pelo fato de que o orçamento é consolidado e os custos de mão de obra para desenvolvimento são expressos em lucro pelo fato de um membro da equipe subir de nível, começar a trabalhar melhor, mais rápido.
Sobre a leitura de livros durante o horário de trabalho. Temos a prática de que a necessidade de aprender algo é um passo completamente natural para resolver um problema. Não jogamos o desenvolvedor em um turbilhão, definindo tarefas como: "Ler um livro" ou "estudar uma tecnologia que não tem um objetivo final". Não deve ser tal que uma pessoa se sente e pense - já estudei a tecnologia ou preciso estudar mais? Uma tarefa fora do contexto, fora de um objetivo leva à procrastinação, ao fato de a pessoa perder a autoconfiança e não saber quando fazer algo.
Pesquisar e ler literatura, estudar qualquer coisa deve fazer parte da tarefa, mas deve haver um objetivo final tangível para o qual este estudo possa ser aplicado.
Anton Grishin, MadRobots: Eu sou do mundo onde cada hora alguém ganhava e alguém perdia dinheiro. Como regra, o cliente é informado honestamente: "Não aceitaremos mais dinheiro de você, mas faremos a tarefa por mais tempo." A empresa, seu empregador, paga de qualquer maneira pelo desenvolvimento de um engenheiro. O cliente simplesmente espera um pouco mais, mas no futuro ele entende que agora não um, mas dois desenvolvedores estão engajados no desenvolvimento de seu produto, tudo se resolve mais rápido, a escala de implementação está aumentando.
Em estúdios e agências, onde normalmente os processos são construídos, o desenvolvedor nunca será colocado em um projeto que objetivamente não o atraia, pois trará mais prejuízos para a empresa do que ganhará no desenvolvimento.
Alexander Borisov, X5 Retail Group:Além do meu trabalho na X5, tenho meu próprio pequeno estúdio de terceirização. Eu entendo muito bem sua economia. Fixamos 80 horas pagas, mas entendemos que eram 150, e o número de horas pagas e o tempo de desenvolvimento, muitas vezes eram diferentes. Sempre compramos algum tipo de ação e simplesmente pagamos por essa ação com nosso próprio dinheiro. Se em algum lugar houver algum tipo de força maior, significa que é pago com o próprio dinheiro.
Mikhail Mazein, ManyChat: O desenvolvimento de produtos, onde não temos um cliente externo, desata muito as nossas mãos a este respeito. Em geral, não acompanhamos o desempenho de cada indivíduo, medimos o desempenho da equipe.
Cada equipe tem sua capacidade e velocidade, podem variar muito, mas no geral, focamos no desempenho de toda a equipe como um todo. Quanto tempo livre um determinado engenheiro tem no sprint atual não é muito importante para nós, como empresa, esse tempo sempre resta para o treinamento, e de sprint para sprint, em princípio, difere para cada engenheiro. Em algum lugar do sprint, haverá mais carga no front-end, no próximo sprint haverá mais carga no back-end, e toda essa história se nivelará no longo prazo.
Se falamos em avaliar o desempenho de cada pessoa, a própria equipe é responsável por isso, é como uma estrutura autorreguladora. Existem situações em que o feedback vem, por exemplo, do mentor dessa pessoa, de que algo está errado com o desempenho, ou de seus colegas da comunidade funcional.
, ?
, Miro: , , . , , … , .
Sergey Averyanov, FunBox: Acho que pode haver empresas que se concentram em especialistas de nível fixo, eles sempre têm o mesmo trabalho com as mesmas qualificações, não querem criar ninguém. Isso é resolvido pelo fato de que há uma grande rotatividade e os funcionários que poderiam crescer encontram novos empregos. Ou investimos no desenvolvimento dos colaboradores e na expansão da empresa, ou temos um turnover.
Artem Susekov, Miro: Isso já pode ser calculado, se estamos falando de faturamento, vamos nos ater a essa métrica, se for sobre dinheiro, certo? O custo de atrair cada nova pessoa, quanto tempo é gasto com recrutadores, quanto gastamos com integração e quanto nós, então, quando a pessoa sai, fechamos a vaga novamente. Tudo isso pode ser contado em dinheiro.
Sergey Averyanov, FunBox:Aliás, um indicador interessante e útil até para si mesmo é o tempo médio de trabalho na empresa. Permite estimar o turnover, ou seja, quantas pessoas trabalham em nossa mediana. Quando você vê que a mediana é grande e nas bordas dessa distribuição há pessoas que trabalharam oito a dez anos, não se esgotaram, estão bem e todos estão felizes uns com os outros, essa é uma boa notícia.
Anton Grishin, MadRobots: Parece-me que agora o negócio não precisa explicar tudo isso, é óbvio que a necessidade de autodesenvolvimento é inerente às pessoas que criam produtos intelectuais. Portanto, não consigo nem pensar em exemplos em que sejam necessários especialistas do mesmo nível, porque as próprias tecnologias que usamos ditam que precisamos desenvolver.
Mishan Storozhilov, DevRel-bureau:Parece-me que não se trata apenas de pessoas com desempenho fixo e tecnologias fixas. Acho que essa história também é sobre grande refatoração, grande dívida técnica. Trabalhamos com empresas que entendem a necessidade de desenvolver engenheiros, mas sempre surge a questão de justificar o custo da educação e do desenvolvimento.
Sergey Averyanov, FunBox:Aqui, a palavra "refatoração" soou e a atitude em relação a ela pode ser interessante. Muitas pessoas pensam erroneamente, especialmente especialistas não técnicos, que esses são alguns gestos estranhos de caras de suéter que não fazem nada e gastam dinheiro. O problema aqui está justamente na comunicação, ou seja, o gerente deve entender que a refatoração que não aconteceu hoje é o aumento do tempo de desenvolvimento amanhã. Hoje vamos economizar algumas horas de trabalho e amanhã vamos gastá-las.
Concordamos internamente que o líder da equipe tem o direito de dizer que uma condição necessária para completar a tarefa é realizar a refatoração, sem ele ficamos com tantas bobagens que é impossível trabalhar.
Naturalmente, isso é basicamente uma questão de acordo, mas não consideramos a refatoração como uma atividade secundária e desperdício de recursos, mas como parte do fluxo de trabalho.
Artem Susekov, Miro: Se falamos sobre desenvolvimento de produtos, acordos são importantes. Por exemplo, o gerente de produto determina as prioridades com base na pontuação e a equipe ou a voz da equipe, líder de tecnologia ou líder de equipe, determina exatamente como fazê-lo. O produto diz o que é mais importante agora, o engenheiro diz como faremos.
Refatorar é um processo natural. Refatorar hoje vai nos custar muito mais barato do que refatorar em um quarto. É como um empréstimo - se você não pagar, da próxima vez terá que pagar mais.
Alexander Borisov, X5 Retail Group: Existe um termo "dívida técnica", e apenas na fase de comunicação entre a equipe e o produto, entendemos que se não estamos fazendo agora, é uma dívida técnica. Com isso, o débito técnico com o sprint será maior, em seis meses será ainda maior e você terá que pagar com esse percentual. Na verdade, como acontece com um empréstimo normal, exatamente da mesma forma que a equipe barganha com o produto, se você quiser mais rápido ou humanamente. Se for mais rápido, algum dia você terá que pagar muito mais. Tal como acontece com um empréstimo.
Mishanya Storozhilov, DevRel-bureau: Ou essa dívida simplesmente se transforma em uma “hipoteca técnica”.
Reunimos cinco engenheiros, eles conversaram apenas uma hora e meia e já começaram a falar sobre refatoração.
* * * O
segundo encontro da série acontece no dia 20 de agosto . O assunto é toxicidade em equipes, empresas e indústria. Palestrantes - engenheiros e líderes técnicos de Miro, SEMrush, Parma TG, Xsolla.
As inscrições estão abertas .