Это текстовая расшифровка митапа на тему профессионального развития инженера в компании. Дискуссия состоялась между CTO, техлидами и тимлидами из Miro, X5 Retail Group, FunBox, ManyChat и MadRobots.
Митап прошёл в рамках серии «Инженер заходит в бар», где инженеры из разных IT-компаний общаются на профессиональные не-инженерные темы. Серия мероприятий организована инженерами из компании Miro, при поддержке DevRel-бюро «Долгушев и Сторожилов».
20 августа состоится второй митап серии. Тема — токсичность в командах, компаниях и индустрии. Спикеры — инженеры и техлиды из AWS, Miro, SEMrush, Parma TG, Xsolla. Регистрация уже открыта.
Оглавление:
Артём Сусеков, Head of Product Software Engineering, Miro.Мы создаём продукт для онлайн-коллаборации команд, online collaborative whiteboard platform. В компании работает 400 человек, чуть меньше половины — инженеры. Офисы продуктовой разработки — в Перми и Амстердаме. Команды кросс-функциональные: инженеры, продакт-менеджеры, дизайнеры и, при необходимости, маркетологи. Работают по скраму, некоторые используют канбан. Для планирования — OKR на уровне кампании и на уровне отдельных команд.
У нас есть грейды, ожидания от каждого сформулированы в виде конкретных примеров поведения (behavior patterns). Это сделано для того, чтобы не зацикливаться только на формальных ожиданиях («сделать столько-то задач, получить такой-то сертификат»). Важнее, чтобы полученные знания применялись в ежедневной работе, именно это проявляется в конкретных примерах, которые описаны для каждого из грейдов.
Грейды стандартные: Junior, Middle, Senior, внутри каждого грейда несколько ступеней. Есть возможности после Senior расти в технического специалиста или стать тимлидом, а затем менеджером направления.
Есть Performance Review, которое проводим два раза в год. В ходе него ты получаешь обратную связь от коллег по команде, тимлиды получают обратную связь от тех, кто является для них direct report. Кроме этого сотрудник пишет self review, то есть самостоятельно оценивает свою работу.
Результаты суммируются, после чего проводится Career Conversation: что получилось хорошо, что получается отлично, на чём стоит сделать акцент в дальнейшем, с чем следует поработать. Дальше менеджер помогает сформировать план развития на следующие полгода или квартал.
Бо?льшую часть профита нам приносят наши IT-сервисы. То, как работает «Пятёрочка» и какие цены она даёт, возможно за счёт грамотно выстроенных логистики и системы управления этим большим процессом. У нас больше двух тысяч айтишников в компании, только в Иннополисе почти 150 человек.
За последний год это всё стало преобразовываться из формата отделов в форматы продуктовых команд. Мы разбили сервисы и продукты на микросервисы и под-продукты, за которые может отвечать одна команда. У нас появились Product Owners у каждого продукта, кросс-функциональные команды, в каждой из которых есть разработчики, тестировщики, аналитики и часть функций, в которых люди могут перекрывать друг друга.
Естественно, у нас есть встречи one-to-one, OKR, обратная связь 360. Из интересного — функция владельца ресурсного пула. Это люди, которые отвечают за пул Java, JS, Python, тестирования, аналитики и т.д. У каждого инженера в компании есть руководитель от бизнеса (Product Owner), который понимает, насколько человек вкладывается в продукт и сколько профита приносит его работа, и есть человек, который отвечает за техническое развитие в своей конкретной компетенции.
Мы отказались от формализации перехода между грейдами вроде «для перехода с Junior plus на Middle minus нужно сделать то-то и то-то». Мы опасаемся, что если дать чёткие критерии перехода, то люди начнут подходить к этому слишком формально. Но формальность здесь вредна, потому что в каждой команде всё может быть очень индивидуально: один и тот же человек может брать на себя больше ответственности и за счёт этого развиваться, либо прокачиваться в узком сегменте технологий, которые специфичны у нас, и за счёт этого становиться более ценным для бизнеса.
Сергей Аверьянов, CTO, Funbox. Мы более 10 лет разрабатываем ПО для операторов «большой тройки». На данный момент у нас порядка двух сотен разработчиков разного профиля и достаточно большое число технических специалистов в техподдержке.
С одной стороны, у нас нет монопродукта, которым занимается вся команда, а с другой стороны, нет большого потока проектов и задач как в аутсорсе. Отсюда растёт наша специфика профессионального роста инженеров. Мы осознанно отказались от формальных систем грейдов: возможно, этого хотели бы менеджмент и сами сотрудники, но это на редкость негибкая система, которая всех пытается причесать под одну гребёнку, что на практике не всегда возможно. Вместо этого мы пользуемся достаточно стандартными вещами: периодическая оценка прогресса сотрудника и беседы тет-а-тет. У нас есть возможность объективно оценить вклад каждого по Task Tracker. Всё это в совокупности даёт нам понимание уровня каждого из инженеров.
С другой стороны, одна из основных наших целей – дать каждому человеку понять, как и куда он может развиваться. Мы стараемся учитывать факт, что все люди разные: кому-то интересно работать техническим экспертам, минимально общаться с людьми и не погружаться в административные вещи; кому-то хочется общения, работы с людьми, участия в развитии коллег. Всё это нормально, все варианты развития возможны.
Мы пытаемся построить систему, которая позволяет повышать уровень инженеров и давать им понятные ориентиры, чего от них хочет бизнес и куда они могут двигаться дальше. Также мы большое внимание уделяем внутреннему росту. Я и вся команда считаем, что самый лучший специалист – это специалист, которого мы вырастили внутри команды. Поэтому мы активно вкладываемся во внутреннее развитие, в митапы, внутренне и внешние конференции. Это тоже одна из основных целей — полномерное и качественное развитие всех наших инженеров.
Такой подход даёт плюс нам и самим сотрудникам. Мы, с одной стороны, имеем постоянный органический рост среди персонала. С другой стороны, мы можем из бывших джунов делать синиоров и тимлидов, а сам сотрудник видит, что его непосредственный руководитель – это тот, кто четыре года назад на этом проекте был джуном, значит, перед сотрудничом сейчас те же самые возможности и понятные шаги для роста.
Михаил Мазеин, Engineering Lead, ManyChat. Мы занимаемся разработкой SaaS-маркетинговой платформы, которая позволяет устраивать коммуникации между бизнесами и их клиентами. Компания активно растёт: три года назад в команде было 15 человек, сейчас нас больше 120 человек. На первых этапах мы работали классическими функциональными командами: команда бэкэнда, фронтэнда, тестирования, дизайна. В каждой команде был тимлид, который отвечал за планирование спринтов и декомпозицию задач.
В процессе роста мы поняли, что это мешает двигаться с желаемой скоростью и переформатировали работу на кросс-функциональные команды. Сейчас у нас девять таких кросс-функциональных команд, тимлидов нет, так как команды получились самоорганизованными и могут сами отвечать за способ своей работы.
Для синхронизации функциональных вещей мы вырабатываем общие подходы, чтобы разработка не превратилась в анархию. Это нужно, например, когда бэкэнд-разработчики распределены по разным командам, но работают с одним проектом, с одной кодовой базой, и комитят туда код. Мы организуем функциональные сообщества, которые позволяют решать эти вопросы. В сообществах со временем появляются неформальные лидеры, которые драйвят процессы и коммуникации. Получается плоская структура, которая не ограничивает роль разработчика ролью инженера, который только пишет код, а позволяет заниматься различными вещами, которые полезны компании и одновременно интересны самому человеку.
Так как мы отказались от роли тимлида, нам понадобился процесс, который позволяет понятно и прозрачно выстраивать треки роста для инженеров. Для этого мы используем систему менторства: у каждого сотрудника есть ментор, который отвечает за его рост и развитие в рамках компании.
Мы выделяем три основных вектора развития:
Также мы попытались сделать систему грейдов: мы пока не можем формально описать все грейды, поэтому система выстроена на уровне вклада человека, уровне команды, уровне всей компании. Мы описали ожидания на каждом уровне, какую зону ответственности или зону влияния мы ожидаем от человека, с понятными примерами. Ментор, со своей стороны, человеку может подсказать, какие навыки нужно прокачивать, чтобы прийти в желаемую точку.
Антон Гришин, Head of Development, MadRobots. Наша компания с первого взгляда e-commerce, который занимается гаджетами, но вообще мы занимаемся дистрибуцией в России и развитием брендов крутых вещей.
Наша команда собралась относительно недавно, поэтому у нас ещё нет головной боли, связанной с развитием инженеров внутри компании. До Madrobots я 6 лет проработал в аутсорсе, три из которых непосредственно руководил производством в агентстве, и про этот опыт я и хотел бы рассказать подробнее.
В аутсорсе нашей болью были большой поток проектов и текучка кадров, в аутсорсе это всегда так. Мы решили, что нужно это как-то побороть и начали вкладываться в развитие сотрудников.
Да, у нас была система грейдирования, раз в полгода человек получал обратную связь от технического руководителя, выстраивал с ним свой путь на ближайшие шесть месяцев.
Впоследствии у нас появилась ещё одна боль. В потоке проектов, которых зачастую было довольно много, у людей терялся фокус на личное развитие. Это происходило не потому, что у них не хватало времени, а потому что они уставали от количества задач, по которым приходится прыгать. Мы ввели практику встреч one-to-one, раз в месяц, которые были направлены на то, чтобы поговорить с человеком и напомнить, что у тебя есть план развития и его действительно стоит придерживаться. Если тебе для этого нужно какое-то время, и тебя стоит освободить от текучки или постоянного офсайта, давай это обсуждать, потому что у тебя близится checkpoint и с этим надо что-то делать. Это помогло. Как правило, этим занималась ПМы команд, потому что кому, как не им, было виднее по планированию ресурсов на будущее.
Артем Сусеков, Miro. Сложно сделать систему грейдов сразу сбалансированной, поэтому мы двигаемся итерациями. Например, первая версия трека тимлида у нас получилась перегруженной: слишком высокие ожидания, универсальный суперсолдат, что в жизни вряд ли возможно.
Сейчас мы пытаемся упростить порог входа в роль тимлида, чтобы людям было проще переключиться из чисто инженерной ветки в менеджерскую ветку. Не хочется чересчур завышать планку, нужна возможность плавно идти в эту новую для себя сферу деятельности.
Другая сложность — слишком формальный подход к процессу. Например, «я сделал 8 из 10 пунктов в плане, значит, я соответствую ожиданиям и могу переходить на следующий уровень». Мы не хотим превращать всё это в чек-лист, который нужно просто закрыть, чтобы перейти на следующий уровень, как в игре.
Александр Борисов, X5 Retail Group. Люди часто не понимают, как именно можно расти в компании, потому что нет чётких алгоритмов. При этом люди, которых действительно уже можно повышать, сами находят вещи, в которых можно и нужно расти, те вещи, которые можно на себя взять и сделать лучше. Но бывает так, что есть потребность «просто расти». Но просто так расти в компании, потому что тебе хочется расти, наверное, невозможно.
Сергей Аверьянов, Funbox. Так как мы работаем уже много лет, у нас было много проблем и вызовов. Один из первых – понять, а с кем мы хотим работать, кого мы хотим развивать. В итоге мы пришли к выводу, что хотим работать с людьми, которые умеют что-то делать хорошо, причем не особо важно, на чём. Мы охотно берём специалистов с любого стека, которые готовы пользоваться тем, чем пользуемся мы. Это оказалось достаточно успешной практикой: развивать людей, которые уже имеют компетенцию в смежной предметной области – это всегда приятно и удобно. Пробел в знаниях, который есть у них, — не фатальный недостаток, а новая мотивация для человека, изучение новой сферы деятельности.
Второй вызов — понять, за счёт чего инженеры в компании могут расти. Для развития нужно создать комфортные условия работы: нормальный офис, понятные, простые, но строгие процедуры и регламенты работы, соблюдение ТК, нелюбовь к переработкам. Всё это даёт человеку уверенность в том, что он может без нервотрепки, без авралов, повышать свой уровень. Ему покажут, ему подскажут, ему помогут.
Последний вызов — не все люди хотят расти туда, куда мы хотим, чтобы они росли. Бывает, что сильный специалист ни при каких условиях не хочет заниматься административной нагрузкой и работой с младшими коллегами. Здесь вопрос не в формальных вещах, не в зарплате, а просто в том, к чему у человека интерес и склонность. Именно поэтому мы во всех инженерах ценим пассионарность, способность взять сложную задачу и провести её по многоходовому процессу от начала до конца. Любой инженер, который к этому способен, нам, как правило, интересен и нравится. Но, как я уже говорил, вместе с этим мы всегда оставляем возможность для человека стать техническим экспертом, не погружаясь в административные и управленческие функции.
Михаил Мазеин, ManyChat. Достаточно тяжело формализовать требования для грейдов, и мы тоже не старались их жестко формализовывать, ориентировались на примеры ожиданий того, что хотелось бы видеть от инженера на разных ступенях развития. Всё это обернули в конкретный impact, который вносят люди в процессы на уровне команды или компании.
Это создаёт трудности. С одной стороны, мы не ограничиваем людей в росте, перед ними возникает чистый холст, на котором они могут рисовать свой трек развития. Но нарисовать новую картину на чистом листе гораздо сложнее, чем двигаться по проторенным дорожкам. Эту проблему мы решаем менторством. Менторы помогают выстраивать треки, исходя из желаний людей и синхронизируя это с потребностями компании. Также стараемся развивать майндсет поиска проблем, чтобы инженеры отлавливали проблемы в процессах и сами старались инициировать их решение. В этом, опять же, помогают менторы.
Антон Гришин, MadRobots. Есть люди, для которых рост – это собственная потребность, и есть люди, которые растут, потому что так вокруг заведено и для этого созданы условия. Но у них всех периодически возникает вопрос – чтобы что? Теряется личная мотивация к изучению нового, к развитию, потому что это может быть неприменимо в текущих реалиях или с текущими коллегами.
В качестве одного из решений мы проводили внутренним митапы, но не как кружок по интересам, а как внутренняя конференция, с реальной подготовкой новой темы. Из этого вышла позитивная история, ребята между собой начали понимать, что если, например, фронтэнды могут что-то новое сделать, значит и мы, дизайнеры и проектировщики, можем переосмыслить сови подходы и попробовать новые инструменты. Получается естественная мотивация друг друга на то, чтобы попробовать сделать вместе что-то новое.
Сергей Аверьянов, FunBox: Нам помог сам факт роста компании. Когда инженеров не сильно много, все они варятся вместе, все друг друга знают и делают примерно одного типа задачи. А как только начинают выстраиваться разные виды проектов и роли в них, то все люди становятся наделёнными разными полномочиями. Кто-то делает задачи, кто-то занимается деплоями, кластерами, кто-то участвует в проектировании продукта.
Для нас важно, чтобы каждый член команды понимал, что он должен у себя прокачать, чтобы из разработчика стать разработчиком более высокого уровня или тимлидом.
Очень полезными являются внутренние митапы. Когда у компании много команд и несколько продуктов, люди варятся каждый в своём соусе, а на митапах они разговаривают, рассказывают, какие крутые штуки делают, обениваются знаниями. Это порождает не конкуренцию между командами, а стремление к совершенству.
Артем Сусеков, Miro: На одном этапе роста команды хорошо помогают разного рода гильдии, которые формируются вокруг технологий: бэкэнд, фронтэнд, QA. В гильдиях происходит обмен знаниями между разными командами.
Внутренние мероприятия тоже помогают: митапы, публичные Sprint Review, где команды делятся общим контекстом, рассказывают о результатах. Здесь важно помогать инженерам с подготовкой к таким выступлениям.
Александр Борисов, X5 Retail Group: Нельзя надеяться, что вы скажете о том, что митапы нужны, и люди начинают самоорганизовываться. Ими тоже надо заниматься. В случае наших масштабов, имеет смысл выделять ответственных людей, кто это организует. Часто внутри у команд есть классные вещи, но они варятся внутри себя, им просто не хватает времени на то, чтобы организовать митап и поделиться наработками. Кажется, что мы взяли бы полчаса, собрались в переговорке, и провели, но нет. Там есть свои нюансы.
Михаил Мазеин, ManyChat: Хорошо выстроенный процесс онбординга новых людей позволяет донести до них общие принципы и подходы, правильно сформировать картину о команде и проекте. Так культура с приходом новых людей будет накапливаться и передаваться дальше.
Вопрос от зрителя: «Вы не затрагиваете вопросы финансовой устойчивости организации. Каким образом определяется доля расходов компании на то, чтобы сотрудник в рабочее время читал книжки? Второе – это пример, пусть решение задачи занимает 80 часов у разработчика, который уже решал такую задачу, и 150 часов займет решение этой же задачи у незнакомого с контекстом разработчика, но при этом он подрастет, прокачается. Вопрос в том, кто оплатит разницу в 70 часов, затраченную на развитие».
Александр Борисов, X5 Retail Group: В нашем случае нет заказчика. Мы начали активно наращивать внутреннюю команду вместо продолжение аутсорсинга каких-то вещей, потому что понимаем, что компетенция для нас стоит очень дорого и выливается в итоге в финальных затратах, в повышение маржинальности бизнеса, конкретной «Пятерочки» у вашего дома. Это инвестиция, отложенная в будущее.
Но если человек вместо делания задачи на три часа на 150 часов ушел в чтение книжки, то здесь возникнет вопрос как раз у владельца продукта или у владельца ресурсного пула. Если это понятная инвестиция в то, что человек вырос, то, опять же, на уровне этих двух людей это легко решается. Например, план на спринт, соответственно, внутри него мы заложили то, что надо будет почитать, и мы в это уложились, это нормальная история.
Артем Сусеков, Miro: Есть договорённость уровне компании, что мы помогаем инженерам развиваться с помощью в том числе курсов и воркшопов, которые проводятся в рамках рабочего времени. То есть оплачивает это компания, это инвестиция в каждого члена команды, потому что мы верим, что такого рода инвестиции хорошо в дальнейшем помогают всей команде двигаться быстрее.
Конкретное зарезервированное время инженера для образования в рамках спринта обсуждается на уровне конкретной команды. Здесь важно, чтобы не было перекосов в другую сторону, что всё время спринта мы только изучаем и больше ничего не делаем.
Сергей Аверьянов, FunBox: Я думаю, что вопрос про 80 и 150 часов более острый для аутсорса, когда можно спросить – а почему мне, как заказчику, задачу делает 150 часов неопытный разработчик, если прошлую такую же мне за 80 сделал опытный? Как решает это аутсорс, я не могу сказать, потому что мы не аутсорс. В рамках продуктовой компании это решается тем, что бюджет консолидированный, и трудозатраты на развитие выражаются в профите за счёт того, что член команды повышает свой уровень, начинает работать лучше, быстрее.
По поводу чтения книжек в рабочее время. У нас практика, что необходимость изучения чего-то – это совершенно естественный шаг работы над задачей. Мы не кидаем разработчика в омут, ставя задачи вроде: «Прочитай книжку» или «изучи технологию, у которой нет конечной цели». Не должно быть такого, что человек сидит и думает – а я уже изучил технологию или мне надо ещё поизучать? Задача вне контекста, вне цели ведёт к прокрастинации, к тому, что человек теряет уверенность в себе и не знает, когда же ему что-то делать.
Антон Гришин, MadRobots: Я из того мира, где каждый час – это кто-то заработал, а кто-то потерял деньги. Как правило заказчику честно говорится: «Мы с тебя денег больше не возьмём, но будем делать дольше задачу». Платит всё равно за развитие инженера компания, его работодатель. Заказчик просто ждет подольше, но зато в перспективе он понимает, что теперь не один, а два разработчика занимаются развитием его продукта, всё решается быстрее, масштабы внедрения увеличиваются.
В студиях и агентствах, где нормально построены процессы, разработчика никогда не посадят на проект, который его объективно не потянет, потому что он принесёт больше убытков компании, чем заработает на разработке.
Александр Борисов, X5 Retail Group: Помимо мой работы в X5, у меня есть своя маленькая аутсорсинговая студия. Её экономику я очень хорошо понимаю. Мы оплаченных часов ставили 80, но понимали, что это 150, и количество оплаченных часов и срок разработки, они очень часто разнились. Какой-то запас мы брали всегда, и этот запас просто оплачивали из своих денег. Если где-то какой-то форс-мажор, значит, это из своих денег оплачивается.
Михаил Мазеин, ManyChat: Продуктовая разработка, где у нас нет внешнего заказчика, сильно развязывает нам руки в этом плане. В целом мы не трекаем производительность каждого отдельного человека, мы меряем производительность команды.
У каждой команды своё capacity и скорость, они могут сильно разниться, но в целом мы ориентируемся на производительность всей команды в целом. Насколько там свободного времени у конкретного инженера в текущем спринте, это для нас, как для компании, не сильно важно, это время всегда остаётся на обучение, и от спринта к спринту оно, в принципе, у каждого инженера отличается. Где-то в спринте бывает нагрузка больше на фронтенд, в следующем спринте будет нагрузка больше на бэкенд, и вся эта история в долгосрочной перспективе выравнивается.
Если говорить об оценке performance каждого конкретного человека, за это отвечает сама команда, она как саморегулирующаяся структура. Бывают ситуации, когда фидбэк приходит, например, от ментора этого человека, о том, что с перформансом что-то не так, либо же от его пиров из функционального комьюнити.
Сергей Аверьянов, FunBox: Я думаю, что могут существовать компании, которые ориентированы на специалистов фиксированного уровня, у них всегда одинаковая работа одинаковой квалификации, никого они не растить не хотят. Это решается тем, что существует большая текучка, а сотрудники, которые могли бы вырасти, находят новые места работы. Либо мы вкладываемся в развитие сотрудников и расширение компании, либо мы имеем текучку.
Артем Сусеков, Miro: Это уже можно посчитать, если мы про текучку, к этой метрике привяжемся, если про деньги, да? Стоимость привлечения каждого нового человека, сколько затрачивается времени рекрутёров, сколько тратим на онбординг и сколько мы потом, когда человек уходит, снова закрываем вакансию. Всё это можно посчитать в деньгах.
Сергей Аверьянов, FunBox: Кстати, интересный показатель, который для самого себя даже полезно смотреть — медианный период работы в компании. Он текучку позволяет оценивать, то есть сколько в медианном у нас работают люди. Когда ты видишь, что медиана большая и на краях этого распределения сидят люди, которые по восемь-десять лет проработали, не выгорели, у них всё хорошо и все друг другом довольны, — это радует.
Антон Гришин, MadRobots: Мне кажется, сейчас бизнесу необязательно всё это объяснять, это очевидно, что потребность в саморазвитии заложена в людей, которые занимаются созданием интеллектуальных продуктов. Поэтому я даже не могу придумать примеров, где нужны специалисты одинакового уровня, потому что сами технологии, которые мы используем, диктуют нам, что нужно развиваться.
Мишаня Сторожилов, Der-Rel Бюро: Мне кажется, здесь речь не только про людей с фиксированной производительностью и фиксированными технологиями. Я думаю, что эта история ещё про большой рефакторинг, большой технический долг. Мы работаем с компаниями, которые понимают необходимость развития инженеров, но вопрос про обоснование расходов на образование и развитие всегда встречается.
Сергей Аверьянов, FunBox: Здесь прозвучало слово «рефакторинг», к нему отношение бывает интересное. Многим ошибочно кажется, особенно не техническим специалистам, что это какие-то странные телодвижения чуваков в свитерах, которые ничего не делают и тратят деньги. Здесь проблема именно в коммуникации, то есть менеджер должен понимать, что тот рефакторинг, который не случился сегодня, — это увеличенные сроки разработки завтра. Сегодня мы сэкономим сколько-то человеко-часов, а завтра мы их потратим.
Естественно, это в конечном итоге предмет договорённости, но мы рефакторинг рассматриваем не как побочную активность и проедание ресурсов, а как часть рабочего процесса.
Артем Сусеков, Miro: Если говорить про продуктовую разработку, то важны договорённости. Например, что Product manager определяет приоритеты, исходя из скоринга, а команда или голос команды, техлид или тимлид, определяет, каким именно образом это делать. Product говорит, что? самое важное сейчас, инженер говорит, как мы будем это делать.
Александр Борисов, X5 Retail Group: Есть же термин «техдолг», и как раз на этапе общения команды с продактом мы понимаем, что если сейчас мы этого не делаем, это техдолг. Соответственно, через спринт техдолг будет больше, через полгода ещё больше и платить придётся с этим процентом. Фактически, как с обычным кредитом, ровно так же команда торгуется с продактом, если хочется либо быстрее, либо по-человечески. Если быстрее, то когда-то придётся заплатить гораздо больше. Как с кредитом.
Мишаня Сторожилов, Der-Rel Бюро: Либо просто этот долг превращается в «техническую ипотеку».
* * *
20 августа состоится второй митап серии. Тема — токсичность в командах, компаниях и индустрии. Спикеры — инженеры и техлиды из AWS, Miro, SEMrush, Parma TG, Xsolla.
Регистрация открыта.
Митап прошёл в рамках серии «Инженер заходит в бар», где инженеры из разных IT-компаний общаются на профессиональные не-инженерные темы. Серия мероприятий организована инженерами из компании Miro, при поддержке DevRel-бюро «Долгушев и Сторожилов».
20 августа состоится второй митап серии. Тема — токсичность в командах, компаниях и индустрии. Спикеры — инженеры и техлиды из AWS, Miro, SEMrush, Parma TG, Xsolla. Регистрация уже открыта.
Оглавление:
- Специфика компании и текущая система профессионального развития инженеров
- Вызовы в рамках текущих систем развития
- Как внедрять культуру развития на старте работы новой команды
- Горячий вопрос про деньги
- Как вы аргументируете бизнесу, что сотрудникам нужен процент времени на образование и развитие?
- Опрос про инструменты профессионального развития
Специфика компании и текущая система профессионального развития инженеров
Артём Сусеков, Head of Product Software Engineering, Miro.Мы создаём продукт для онлайн-коллаборации команд, online collaborative whiteboard platform. В компании работает 400 человек, чуть меньше половины — инженеры. Офисы продуктовой разработки — в Перми и Амстердаме. Команды кросс-функциональные: инженеры, продакт-менеджеры, дизайнеры и, при необходимости, маркетологи. Работают по скраму, некоторые используют канбан. Для планирования — OKR на уровне кампании и на уровне отдельных команд.
У нас есть грейды, ожидания от каждого сформулированы в виде конкретных примеров поведения (behavior patterns). Это сделано для того, чтобы не зацикливаться только на формальных ожиданиях («сделать столько-то задач, получить такой-то сертификат»). Важнее, чтобы полученные знания применялись в ежедневной работе, именно это проявляется в конкретных примерах, которые описаны для каждого из грейдов.
Грейды стандартные: Junior, Middle, Senior, внутри каждого грейда несколько ступеней. Есть возможности после Senior расти в технического специалиста или стать тимлидом, а затем менеджером направления.
Есть Performance Review, которое проводим два раза в год. В ходе него ты получаешь обратную связь от коллег по команде, тимлиды получают обратную связь от тех, кто является для них direct report. Кроме этого сотрудник пишет self review, то есть самостоятельно оценивает свою работу.
Результаты суммируются, после чего проводится Career Conversation: что получилось хорошо, что получается отлично, на чём стоит сделать акцент в дальнейшем, с чем следует поработать. Дальше менеджер помогает сформировать план развития на следующие полгода или квартал.
Career Сonversation сфокусирован не на обсуждении финансовой составляющей (хотя это, конечно, учитывается), а на формулировке дальнейших потенциальных зоны для развития: что мне как инженеру интересно развивать, что из этого будет максимально полезно бизнесу, какие возможности компания в этом может мне предоставить.Александр Борисов, Руководитель центра технологических компетенций «Иннополис», X5 Retail Group. Наверное, с компанией X5 знакомы по большей части все. Мы владеем сетями «Перекрёсток», «Пятёрочка» и «Карусель». Если ещё три года назад мы были компанией, которая продает помидоры, а сейчас стремимся стать IT-компанией, которая продает помидоры.
Бо?льшую часть профита нам приносят наши IT-сервисы. То, как работает «Пятёрочка» и какие цены она даёт, возможно за счёт грамотно выстроенных логистики и системы управления этим большим процессом. У нас больше двух тысяч айтишников в компании, только в Иннополисе почти 150 человек.
За последний год это всё стало преобразовываться из формата отделов в форматы продуктовых команд. Мы разбили сервисы и продукты на микросервисы и под-продукты, за которые может отвечать одна команда. У нас появились Product Owners у каждого продукта, кросс-функциональные команды, в каждой из которых есть разработчики, тестировщики, аналитики и часть функций, в которых люди могут перекрывать друг друга.
Естественно, у нас есть встречи one-to-one, OKR, обратная связь 360. Из интересного — функция владельца ресурсного пула. Это люди, которые отвечают за пул Java, JS, Python, тестирования, аналитики и т.д. У каждого инженера в компании есть руководитель от бизнеса (Product Owner), который понимает, насколько человек вкладывается в продукт и сколько профита приносит его работа, и есть человек, который отвечает за техническое развитие в своей конкретной компетенции.
Мы отказались от формализации перехода между грейдами вроде «для перехода с Junior plus на Middle minus нужно сделать то-то и то-то». Мы опасаемся, что если дать чёткие критерии перехода, то люди начнут подходить к этому слишком формально. Но формальность здесь вредна, потому что в каждой команде всё может быть очень индивидуально: один и тот же человек может брать на себя больше ответственности и за счёт этого развиваться, либо прокачиваться в узком сегменте технологий, которые специфичны у нас, и за счёт этого становиться более ценным для бизнеса.
Для Senior-позиций важным условием роста является распространение знаний. Ты не Senior в вакууме, ты делишься опытом с командой и тянешь за собой остальных.
Сергей Аверьянов, CTO, Funbox. Мы более 10 лет разрабатываем ПО для операторов «большой тройки». На данный момент у нас порядка двух сотен разработчиков разного профиля и достаточно большое число технических специалистов в техподдержке.
С одной стороны, у нас нет монопродукта, которым занимается вся команда, а с другой стороны, нет большого потока проектов и задач как в аутсорсе. Отсюда растёт наша специфика профессионального роста инженеров. Мы осознанно отказались от формальных систем грейдов: возможно, этого хотели бы менеджмент и сами сотрудники, но это на редкость негибкая система, которая всех пытается причесать под одну гребёнку, что на практике не всегда возможно. Вместо этого мы пользуемся достаточно стандартными вещами: периодическая оценка прогресса сотрудника и беседы тет-а-тет. У нас есть возможность объективно оценить вклад каждого по Task Tracker. Всё это в совокупности даёт нам понимание уровня каждого из инженеров.
С другой стороны, одна из основных наших целей – дать каждому человеку понять, как и куда он может развиваться. Мы стараемся учитывать факт, что все люди разные: кому-то интересно работать техническим экспертам, минимально общаться с людьми и не погружаться в административные вещи; кому-то хочется общения, работы с людьми, участия в развитии коллег. Всё это нормально, все варианты развития возможны.
Мы пытаемся построить систему, которая позволяет повышать уровень инженеров и давать им понятные ориентиры, чего от них хочет бизнес и куда они могут двигаться дальше. Также мы большое внимание уделяем внутреннему росту. Я и вся команда считаем, что самый лучший специалист – это специалист, которого мы вырастили внутри команды. Поэтому мы активно вкладываемся во внутреннее развитие, в митапы, внутренне и внешние конференции. Это тоже одна из основных целей — полномерное и качественное развитие всех наших инженеров.
Развитием сотрудника должен заниматься не абстрактный отдел развития. Это одна из обязанностей непосредственного руководителя.
Такой подход даёт плюс нам и самим сотрудникам. Мы, с одной стороны, имеем постоянный органический рост среди персонала. С другой стороны, мы можем из бывших джунов делать синиоров и тимлидов, а сам сотрудник видит, что его непосредственный руководитель – это тот, кто четыре года назад на этом проекте был джуном, значит, перед сотрудничом сейчас те же самые возможности и понятные шаги для роста.
Михаил Мазеин, Engineering Lead, ManyChat. Мы занимаемся разработкой SaaS-маркетинговой платформы, которая позволяет устраивать коммуникации между бизнесами и их клиентами. Компания активно растёт: три года назад в команде было 15 человек, сейчас нас больше 120 человек. На первых этапах мы работали классическими функциональными командами: команда бэкэнда, фронтэнда, тестирования, дизайна. В каждой команде был тимлид, который отвечал за планирование спринтов и декомпозицию задач.
В процессе роста мы поняли, что это мешает двигаться с желаемой скоростью и переформатировали работу на кросс-функциональные команды. Сейчас у нас девять таких кросс-функциональных команд, тимлидов нет, так как команды получились самоорганизованными и могут сами отвечать за способ своей работы.
Для синхронизации функциональных вещей мы вырабатываем общие подходы, чтобы разработка не превратилась в анархию. Это нужно, например, когда бэкэнд-разработчики распределены по разным командам, но работают с одним проектом, с одной кодовой базой, и комитят туда код. Мы организуем функциональные сообщества, которые позволяют решать эти вопросы. В сообществах со временем появляются неформальные лидеры, которые драйвят процессы и коммуникации. Получается плоская структура, которая не ограничивает роль разработчика ролью инженера, который только пишет код, а позволяет заниматься различными вещами, которые полезны компании и одновременно интересны самому человеку.
Так как мы отказались от роли тимлида, нам понадобился процесс, который позволяет понятно и прозрачно выстраивать треки роста для инженеров. Для этого мы используем систему менторства: у каждого сотрудника есть ментор, который отвечает за его рост и развитие в рамках компании.
Нельзя просто подойти к случайному человеку и сказать: «Давай ты будешь ментором». Во-первых, должно собраться несколько факторов: желание самого человека; высокий уровень доверия в коллективе к человеку; доверие от самой компании и от руководства. Одна из задач ментора – вырастить новых менторов. Получается такое почкование, от ментора к ментору.
Мы выделяем три основных вектора развития:
- Первый большой трек – это более глубокая работа в продуктовой команде по развитию продукта, с более глубоким пониманием бизнес-ценностей, метрик.
- Следующий трек – более технический, связанный с инфраструктурными задачами, с потенциалом перехода в инфраструктурную команду.
- Третий большой трек – менторский, он позволяет выращивать и улучшать процессы внутри команды и компании.
Также мы попытались сделать систему грейдов: мы пока не можем формально описать все грейды, поэтому система выстроена на уровне вклада человека, уровне команды, уровне всей компании. Мы описали ожидания на каждом уровне, какую зону ответственности или зону влияния мы ожидаем от человека, с понятными примерами. Ментор, со своей стороны, человеку может подсказать, какие навыки нужно прокачивать, чтобы прийти в желаемую точку.
Антон Гришин, Head of Development, MadRobots. Наша компания с первого взгляда e-commerce, который занимается гаджетами, но вообще мы занимаемся дистрибуцией в России и развитием брендов крутых вещей.
Наша команда собралась относительно недавно, поэтому у нас ещё нет головной боли, связанной с развитием инженеров внутри компании. До Madrobots я 6 лет проработал в аутсорсе, три из которых непосредственно руководил производством в агентстве, и про этот опыт я и хотел бы рассказать подробнее.
В аутсорсе нашей болью были большой поток проектов и текучка кадров, в аутсорсе это всегда так. Мы решили, что нужно это как-то побороть и начали вкладываться в развитие сотрудников.
Да, у нас была система грейдирования, раз в полгода человек получал обратную связь от технического руководителя, выстраивал с ним свой путь на ближайшие шесть месяцев.
В аутсорсе от тебя мало зависит, какими проектами ты будешь заниматься завтра. Поэтому мы ввели внутренние проекты, на которые людям выделялось время. Ценность проектов была в том, что человек осваивал новые навыки, а сами проекты отдавались на конкурсы, получали призовые места и работали на маркетинг компании.
Впоследствии у нас появилась ещё одна боль. В потоке проектов, которых зачастую было довольно много, у людей терялся фокус на личное развитие. Это происходило не потому, что у них не хватало времени, а потому что они уставали от количества задач, по которым приходится прыгать. Мы ввели практику встреч one-to-one, раз в месяц, которые были направлены на то, чтобы поговорить с человеком и напомнить, что у тебя есть план развития и его действительно стоит придерживаться. Если тебе для этого нужно какое-то время, и тебя стоит освободить от текучки или постоянного офсайта, давай это обсуждать, потому что у тебя близится checkpoint и с этим надо что-то делать. Это помогло. Как правило, этим занималась ПМы команд, потому что кому, как не им, было виднее по планированию ресурсов на будущее.
Вызовы в рамках текущих систем развития
Артем Сусеков, Miro. Сложно сделать систему грейдов сразу сбалансированной, поэтому мы двигаемся итерациями. Например, первая версия трека тимлида у нас получилась перегруженной: слишком высокие ожидания, универсальный суперсолдат, что в жизни вряд ли возможно.
Сейчас мы пытаемся упростить порог входа в роль тимлида, чтобы людям было проще переключиться из чисто инженерной ветки в менеджерскую ветку. Не хочется чересчур завышать планку, нужна возможность плавно идти в эту новую для себя сферу деятельности.
Другая сложность — слишком формальный подход к процессу. Например, «я сделал 8 из 10 пунктов в плане, значит, я соответствую ожиданиям и могу переходить на следующий уровень». Мы не хотим превращать всё это в чек-лист, который нужно просто закрыть, чтобы перейти на следующий уровень, как в игре.
Хочется, чтобы на основе плана люди могли задуматься о перспективах, подумать самостоятельно об интересных для них направлениях, то есть чтобы они работали с этим как со стратегией, а не как со списком формальных задач.
Александр Борисов, X5 Retail Group. Люди часто не понимают, как именно можно расти в компании, потому что нет чётких алгоритмов. При этом люди, которых действительно уже можно повышать, сами находят вещи, в которых можно и нужно расти, те вещи, которые можно на себя взять и сделать лучше. Но бывает так, что есть потребность «просто расти». Но просто так расти в компании, потому что тебе хочется расти, наверное, невозможно.
Вы растёте, только когда берёте на себя больше ответственности, берете на себя новые проекты.
Сергей Аверьянов, Funbox. Так как мы работаем уже много лет, у нас было много проблем и вызовов. Один из первых – понять, а с кем мы хотим работать, кого мы хотим развивать. В итоге мы пришли к выводу, что хотим работать с людьми, которые умеют что-то делать хорошо, причем не особо важно, на чём. Мы охотно берём специалистов с любого стека, которые готовы пользоваться тем, чем пользуемся мы. Это оказалось достаточно успешной практикой: развивать людей, которые уже имеют компетенцию в смежной предметной области – это всегда приятно и удобно. Пробел в знаниях, который есть у них, — не фатальный недостаток, а новая мотивация для человека, изучение новой сферы деятельности.
Второй вызов — понять, за счёт чего инженеры в компании могут расти. Для развития нужно создать комфортные условия работы: нормальный офис, понятные, простые, но строгие процедуры и регламенты работы, соблюдение ТК, нелюбовь к переработкам. Всё это даёт человеку уверенность в том, что он может без нервотрепки, без авралов, повышать свой уровень. Ему покажут, ему подскажут, ему помогут.
Можно сколько угодно кричать на картошку: «Картошка, расти! Помидоры, давайте!», — но они от этого расти не станут. Им нужна хорошая почва и полив.
Последний вызов — не все люди хотят расти туда, куда мы хотим, чтобы они росли. Бывает, что сильный специалист ни при каких условиях не хочет заниматься административной нагрузкой и работой с младшими коллегами. Здесь вопрос не в формальных вещах, не в зарплате, а просто в том, к чему у человека интерес и склонность. Именно поэтому мы во всех инженерах ценим пассионарность, способность взять сложную задачу и провести её по многоходовому процессу от начала до конца. Любой инженер, который к этому способен, нам, как правило, интересен и нравится. Но, как я уже говорил, вместе с этим мы всегда оставляем возможность для человека стать техническим экспертом, не погружаясь в административные и управленческие функции.
Михаил Мазеин, ManyChat. Достаточно тяжело формализовать требования для грейдов, и мы тоже не старались их жестко формализовывать, ориентировались на примеры ожиданий того, что хотелось бы видеть от инженера на разных ступенях развития. Всё это обернули в конкретный impact, который вносят люди в процессы на уровне команды или компании.
Это создаёт трудности. С одной стороны, мы не ограничиваем людей в росте, перед ними возникает чистый холст, на котором они могут рисовать свой трек развития. Но нарисовать новую картину на чистом листе гораздо сложнее, чем двигаться по проторенным дорожкам. Эту проблему мы решаем менторством. Менторы помогают выстраивать треки, исходя из желаний людей и синхронизируя это с потребностями компании. Также стараемся развивать майндсет поиска проблем, чтобы инженеры отлавливали проблемы в процессах и сами старались инициировать их решение. В этом, опять же, помогают менторы.
Антон Гришин, MadRobots. Есть люди, для которых рост – это собственная потребность, и есть люди, которые растут, потому что так вокруг заведено и для этого созданы условия. Но у них всех периодически возникает вопрос – чтобы что? Теряется личная мотивация к изучению нового, к развитию, потому что это может быть неприменимо в текущих реалиях или с текущими коллегами.
В качестве одного из решений мы проводили внутренним митапы, но не как кружок по интересам, а как внутренняя конференция, с реальной подготовкой новой темы. Из этого вышла позитивная история, ребята между собой начали понимать, что если, например, фронтэнды могут что-то новое сделать, значит и мы, дизайнеры и проектировщики, можем переосмыслить сови подходы и попробовать новые инструменты. Получается естественная мотивация друг друга на то, чтобы попробовать сделать вместе что-то новое.
Боль всегда вызывает личный подход каждого конкретного человека к собственному развитию.
Как внедрять культуру развития на старте работы новой команды
Сергей Аверьянов, FunBox: Нам помог сам факт роста компании. Когда инженеров не сильно много, все они варятся вместе, все друг друга знают и делают примерно одного типа задачи. А как только начинают выстраиваться разные виды проектов и роли в них, то все люди становятся наделёнными разными полномочиями. Кто-то делает задачи, кто-то занимается деплоями, кластерами, кто-то участвует в проектировании продукта.
Для нас важно, чтобы каждый член команды понимал, что он должен у себя прокачать, чтобы из разработчика стать разработчиком более высокого уровня или тимлидом.
Не просто прочитай книжку, чтобы узнать 125 бесполезных справочных знаний, а задумайся, где можно это применить на практике, чтобы это было не фигурой речи, а новой практикой в компании.
Очень полезными являются внутренние митапы. Когда у компании много команд и несколько продуктов, люди варятся каждый в своём соусе, а на митапах они разговаривают, рассказывают, какие крутые штуки делают, обениваются знаниями. Это порождает не конкуренцию между командами, а стремление к совершенству.
Артем Сусеков, Miro: На одном этапе роста команды хорошо помогают разного рода гильдии, которые формируются вокруг технологий: бэкэнд, фронтэнд, QA. В гильдиях происходит обмен знаниями между разными командами.
Внутренние мероприятия тоже помогают: митапы, публичные Sprint Review, где команды делятся общим контекстом, рассказывают о результатах. Здесь важно помогать инженерам с подготовкой к таким выступлениям.
Александр Борисов, X5 Retail Group: Нельзя надеяться, что вы скажете о том, что митапы нужны, и люди начинают самоорганизовываться. Ими тоже надо заниматься. В случае наших масштабов, имеет смысл выделять ответственных людей, кто это организует. Часто внутри у команд есть классные вещи, но они варятся внутри себя, им просто не хватает времени на то, чтобы организовать митап и поделиться наработками. Кажется, что мы взяли бы полчаса, собрались в переговорке, и провели, но нет. Там есть свои нюансы.
Михаил Мазеин, ManyChat: Хорошо выстроенный процесс онбординга новых людей позволяет донести до них общие принципы и подходы, правильно сформировать картину о команде и проекте. Так культура с приходом новых людей будет накапливаться и передаваться дальше.
Горячий вопрос про деньги
Вопрос от зрителя: «Вы не затрагиваете вопросы финансовой устойчивости организации. Каким образом определяется доля расходов компании на то, чтобы сотрудник в рабочее время читал книжки? Второе – это пример, пусть решение задачи занимает 80 часов у разработчика, который уже решал такую задачу, и 150 часов займет решение этой же задачи у незнакомого с контекстом разработчика, но при этом он подрастет, прокачается. Вопрос в том, кто оплатит разницу в 70 часов, затраченную на развитие».
Александр Борисов, X5 Retail Group: В нашем случае нет заказчика. Мы начали активно наращивать внутреннюю команду вместо продолжение аутсорсинга каких-то вещей, потому что понимаем, что компетенция для нас стоит очень дорого и выливается в итоге в финальных затратах, в повышение маржинальности бизнеса, конкретной «Пятерочки» у вашего дома. Это инвестиция, отложенная в будущее.
Но если человек вместо делания задачи на три часа на 150 часов ушел в чтение книжки, то здесь возникнет вопрос как раз у владельца продукта или у владельца ресурсного пула. Если это понятная инвестиция в то, что человек вырос, то, опять же, на уровне этих двух людей это легко решается. Например, план на спринт, соответственно, внутри него мы заложили то, что надо будет почитать, и мы в это уложились, это нормальная история.
Артем Сусеков, Miro: Есть договорённость уровне компании, что мы помогаем инженерам развиваться с помощью в том числе курсов и воркшопов, которые проводятся в рамках рабочего времени. То есть оплачивает это компания, это инвестиция в каждого члена команды, потому что мы верим, что такого рода инвестиции хорошо в дальнейшем помогают всей команде двигаться быстрее.
Конкретное зарезервированное время инженера для образования в рамках спринта обсуждается на уровне конкретной команды. Здесь важно, чтобы не было перекосов в другую сторону, что всё время спринта мы только изучаем и больше ничего не делаем.
Сергей Аверьянов, FunBox: Я думаю, что вопрос про 80 и 150 часов более острый для аутсорса, когда можно спросить – а почему мне, как заказчику, задачу делает 150 часов неопытный разработчик, если прошлую такую же мне за 80 сделал опытный? Как решает это аутсорс, я не могу сказать, потому что мы не аутсорс. В рамках продуктовой компании это решается тем, что бюджет консолидированный, и трудозатраты на развитие выражаются в профите за счёт того, что член команды повышает свой уровень, начинает работать лучше, быстрее.
По поводу чтения книжек в рабочее время. У нас практика, что необходимость изучения чего-то – это совершенно естественный шаг работы над задачей. Мы не кидаем разработчика в омут, ставя задачи вроде: «Прочитай книжку» или «изучи технологию, у которой нет конечной цели». Не должно быть такого, что человек сидит и думает – а я уже изучил технологию или мне надо ещё поизучать? Задача вне контекста, вне цели ведёт к прокрастинации, к тому, что человек теряет уверенность в себе и не знает, когда же ему что-то делать.
Исследование и чтение литературы, изучение чего угодно должны быть частью задачи, но при этом должна быть конечная осязаемая цель, на которую это изучение можно применять.
Антон Гришин, MadRobots: Я из того мира, где каждый час – это кто-то заработал, а кто-то потерял деньги. Как правило заказчику честно говорится: «Мы с тебя денег больше не возьмём, но будем делать дольше задачу». Платит всё равно за развитие инженера компания, его работодатель. Заказчик просто ждет подольше, но зато в перспективе он понимает, что теперь не один, а два разработчика занимаются развитием его продукта, всё решается быстрее, масштабы внедрения увеличиваются.
В студиях и агентствах, где нормально построены процессы, разработчика никогда не посадят на проект, который его объективно не потянет, потому что он принесёт больше убытков компании, чем заработает на разработке.
Александр Борисов, X5 Retail Group: Помимо мой работы в X5, у меня есть своя маленькая аутсорсинговая студия. Её экономику я очень хорошо понимаю. Мы оплаченных часов ставили 80, но понимали, что это 150, и количество оплаченных часов и срок разработки, они очень часто разнились. Какой-то запас мы брали всегда, и этот запас просто оплачивали из своих денег. Если где-то какой-то форс-мажор, значит, это из своих денег оплачивается.
Михаил Мазеин, ManyChat: Продуктовая разработка, где у нас нет внешнего заказчика, сильно развязывает нам руки в этом плане. В целом мы не трекаем производительность каждого отдельного человека, мы меряем производительность команды.
У каждой команды своё capacity и скорость, они могут сильно разниться, но в целом мы ориентируемся на производительность всей команды в целом. Насколько там свободного времени у конкретного инженера в текущем спринте, это для нас, как для компании, не сильно важно, это время всегда остаётся на обучение, и от спринта к спринту оно, в принципе, у каждого инженера отличается. Где-то в спринте бывает нагрузка больше на фронтенд, в следующем спринте будет нагрузка больше на бэкенд, и вся эта история в долгосрочной перспективе выравнивается.
Если говорить об оценке performance каждого конкретного человека, за это отвечает сама команда, она как саморегулирующаяся структура. Бывают ситуации, когда фидбэк приходит, например, от ментора этого человека, о том, что с перформансом что-то не так, либо же от его пиров из функционального комьюнити.
Как вы аргументируете бизнесу, что сотрудникам нужен процент времени на образование и развитие?
Артем Сусеков, Miro: Если менеджмент компании считает, что развиваться не нужно, такая компания не выживет в длительном периоде. Люди, которые хотят развиваться, просто уйдут из неё рано или поздно… скорее, рано.
Сергей Аверьянов, FunBox: Я думаю, что могут существовать компании, которые ориентированы на специалистов фиксированного уровня, у них всегда одинаковая работа одинаковой квалификации, никого они не растить не хотят. Это решается тем, что существует большая текучка, а сотрудники, которые могли бы вырасти, находят новые места работы. Либо мы вкладываемся в развитие сотрудников и расширение компании, либо мы имеем текучку.
Артем Сусеков, Miro: Это уже можно посчитать, если мы про текучку, к этой метрике привяжемся, если про деньги, да? Стоимость привлечения каждого нового человека, сколько затрачивается времени рекрутёров, сколько тратим на онбординг и сколько мы потом, когда человек уходит, снова закрываем вакансию. Всё это можно посчитать в деньгах.
Сергей Аверьянов, FunBox: Кстати, интересный показатель, который для самого себя даже полезно смотреть — медианный период работы в компании. Он текучку позволяет оценивать, то есть сколько в медианном у нас работают люди. Когда ты видишь, что медиана большая и на краях этого распределения сидят люди, которые по восемь-десять лет проработали, не выгорели, у них всё хорошо и все друг другом довольны, — это радует.
Антон Гришин, MadRobots: Мне кажется, сейчас бизнесу необязательно всё это объяснять, это очевидно, что потребность в саморазвитии заложена в людей, которые занимаются созданием интеллектуальных продуктов. Поэтому я даже не могу придумать примеров, где нужны специалисты одинакового уровня, потому что сами технологии, которые мы используем, диктуют нам, что нужно развиваться.
Мишаня Сторожилов, Der-Rel Бюро: Мне кажется, здесь речь не только про людей с фиксированной производительностью и фиксированными технологиями. Я думаю, что эта история ещё про большой рефакторинг, большой технический долг. Мы работаем с компаниями, которые понимают необходимость развития инженеров, но вопрос про обоснование расходов на образование и развитие всегда встречается.
Сергей Аверьянов, FunBox: Здесь прозвучало слово «рефакторинг», к нему отношение бывает интересное. Многим ошибочно кажется, особенно не техническим специалистам, что это какие-то странные телодвижения чуваков в свитерах, которые ничего не делают и тратят деньги. Здесь проблема именно в коммуникации, то есть менеджер должен понимать, что тот рефакторинг, который не случился сегодня, — это увеличенные сроки разработки завтра. Сегодня мы сэкономим сколько-то человеко-часов, а завтра мы их потратим.
Мы внутри себя договорились, что лидер команды имеет право сказать, что необходимое условие выполнения задачи – это проведение рефакторинга, без него получается такая ерунда, с которой работать невозможно.
Естественно, это в конечном итоге предмет договорённости, но мы рефакторинг рассматриваем не как побочную активность и проедание ресурсов, а как часть рабочего процесса.
Артем Сусеков, Miro: Если говорить про продуктовую разработку, то важны договорённости. Например, что Product manager определяет приоритеты, исходя из скоринга, а команда или голос команды, техлид или тимлид, определяет, каким именно образом это делать. Product говорит, что? самое важное сейчас, инженер говорит, как мы будем это делать.
Вопрос рефакторинга – это естественный процесс. Рефакторинг сегодня обойдётся нам гораздо дешевле рефакторинга через квартал. Это как с кредитом – если ты не платишь, то в следующий раз платить придётся больше.
Александр Борисов, X5 Retail Group: Есть же термин «техдолг», и как раз на этапе общения команды с продактом мы понимаем, что если сейчас мы этого не делаем, это техдолг. Соответственно, через спринт техдолг будет больше, через полгода ещё больше и платить придётся с этим процентом. Фактически, как с обычным кредитом, ровно так же команда торгуется с продактом, если хочется либо быстрее, либо по-человечески. Если быстрее, то когда-то придётся заплатить гораздо больше. Как с кредитом.
Мишаня Сторожилов, Der-Rel Бюро: Либо просто этот долг превращается в «техническую ипотеку».
Собрали пять инженеров, они всего полтора часа пообщались и уже начали про рефакторинг разговаривать.
* * *
20 августа состоится второй митап серии. Тема — токсичность в командах, компаниях и индустрии. Спикеры — инженеры и техлиды из AWS, Miro, SEMrush, Parma TG, Xsolla.
Регистрация открыта.
ivshinslava
Сначала показалось скучно и длинно, но потом оказались интересные идеи внутри.
Спасибо!