Как карта развития помогает справляться со стихийными повышениями и неосознанной некомпетентностью

Меня зовут Сергей Черепанов. Я сооснователь и CTO команды разработчиков MetaLamp (Fullstack Development до 2021 года), с 2012 практикующий веб-разработчик. На старших курсах университета я заинтересовался кодом: начал что-то «пилить», брался за проекты на фрилансе «для опыта», а позже нашёл работу в стартапе Rizzoma. Постепенно вокруг сформировался «студенческий кружок» таких же энтузиастов, и у нас появлялись задачи с бюджетом, а не просто за опыт. К 2014 году этот «кружок» вырос в компанию с большими коммерческими проектами, в которой к 2016 году мы доросли до собственного стартапа курьерской доставки на 200 заказов в день.

Но как и в университете, так и сейчас, когда в нашей команде пять десятков разработчиков, основная проблема — это развитие. Как, куда и зачем двигаться разработчику — вот вопросы, на которые я ищу ответы с 2012 года. Сейчас расскажу, как нашёл ответ на этот вопрос в карте развития и чем она будет полезна вам.

Наша команда разработчиков — это фронтендеры и бэкендеры. Фронтенд на TypeScript и React, а бэкенд — на Haskell. Мы помогаем разрабатывать аналитические системы, платформы визуализации данных, финтех и martech-проекты. С 2014 года проекты постоянно усложняются. Если в 2014, условно, мы разрабатывали небольшой портал в команде из пары человек, то в 2016 уже занимались криптовалютными биржами командами по 7 разработчиков в течение года и больше.

Но здесь есть нюансы.

Все проекты мы оцениваем стандартно: прикидываем стек, архитектуру, разбиваем задачу на части и этапы, прогнозируем время на исполнение. Оценить лендинг — это одно (как говорится «вжух и в продакшн»), а оценить задачу «написать бэкенд для торговой площадки» — уже другое. Здесь нужно точно подобрать разработчиков с опытом и знаниями. А как понять, что знания есть?

• Интуитивно: «Я помню, Лёха чем-то таким занимался?».
• Провести One-on-One, чтобы понять, кто что осилит.

В первом случае оценка неточная и субъективная, а во втором — слишком долгая: заказчик не будет ждать пока мы там «языками чешем».

Вот было бы здорово, если бы был такой «эталонный» документ, где все разработчики «отсортированы» по знаниям, навыкам, технологиям, опыту и другим параметрам.

Без понимания знаний команды мы страдали от неосознанной некомпетентности. Например, переводим миддла с проекта виджета аналитики на «UBER для курьеров», где ему нужны принципы SOLID. Но он почему-то регулярно их нарушает. Может просто не знает? Оказывается, да — о принципах SOLID он не слышал. Если бы он где-то что-то читал, то у него была бы иллюзия знаний. Здесь же нет даже иллюзии, а есть некомпетентность, которая не осознаётся.

Мы доверяем разработчику, но объективной оценки его знаний не проводили. Как понять, в каких областях он «хромает»? Можно через ревью или One-on-One. Но если мы проведем несколько десятков таких мероприятий с нашей командой, что уже долго, то в итоге у нас получится пара десятков документов с разбором знаний наших ребят. А если мы их потом изучим, то вычленим повторяющиеся вопросы. Опять получается, что нам нужна некая общая система для «ревью знаний».

«Ревью знаний» мы провели. Дальше мы можем повышать квалификацию разработчиков, чтобы они могли работать над проектами всё сложнее и масштабнее. Как это сделать?

• Тянуть. Для прокачанных разработчиков мы предлагаем проекты со сложным фронтендом, например, криптовалютную биржу. Начинающим можем отдать unit-тесты несложных проектов, но потом его обязательно поставим на проект сложнее, чтобы рос.
• Оставить на самотёк. Несмотря на то, что у нас никто никого не заставляет заниматься самообучением, сами ребята тоже хотят расти и браться за задачки посложнее.

Но это всё несистемно и мешает самим разработчикам, в первую очередь. Они не понимают траекторию развития, хватаются за всё подряд, глубоко не вникая. Как следствие, плодятся велосипеды. Для большинства проблем уже есть известные решения, паттерны, библиотеки, но вместо этого появляется ad-hoc для конкретной проблемы. Это лишняя работа (и оплата), которую в будущем придётся исправлять.

Если оставить развитие на самотёк, то знания будут приобретаться неравномерно. Обычно изучается только то, что связано с задачей (и то не всё). Многие темы, необходимые в целом для системного развития, останутся за бортом. Джуниор будет скакать по темам почти рандомно — это будет зависеть от задач на проекте. Задачи же, могут быть связаны с исправлением багов или поддержанием легаси (в основном). В итоге джун ещё не успев толком прокачаться, уже застревает в болоте, а вытащить на более сложные проекты его еще непросто, так как он пока не тянет. Замкнутый круг.

Опять же, нужна система оценки знаний, которая помогала бы систематизировать рост разработчиков.

Это уже следствие неосознанной некомпетентности и отсутствия системы развития.

Как понять когда разработчику поднимать зарплату без точного понимания, что он может и не может? Это сложный вопрос, который создает локальные военные конфликты в коллективе. Иногда разработчики сами просят повышения, когда считают, что доросли. Но получается, кто громче просит — тот быстрее получает? Чаще всего, большинство не приходит с такими просьбами, а просто копит недовольство и чувство недооценённости, пока где-то не выстрелит.

Разработчикам хочется регулярного повышения зарплаты без разговоров с менеджерами и «выклянчивания» (а кому не хочется?). Поэтому в крупных компаниях есть грейды (уровни). Они предсказуемы: всегда понятно за что, когда и как можно получить повышение без разговоров с менеджером и «вытряхивания» из него новой зарплаты.

Эти 4 причины привели нас к идее создать систему оценки знаний разработчиков — карту развития. Получился некий «эталон», к которому можно «приложить» проект, чтобы понять, кто из наших ребят его «затащит».

Грейды — уровни развития разработчика, от которых зависит должность, зарплата, уровень сложности задач, наличие менторства и свобода в решениях.

Примечание. Карта развития не наше изобретение, их довольно много для разных направлений и специализаций, например, для тестировщиков или аналитиков.

Карта разделена на бэкендеров и фронтендеров.

Когда человек хочет повышения, то смотрит, что изучать, чтобы шагнуть на уровень выше. Условно, есть три больших грейда: джуниор, миддл и сеньор. У нас они разбиты на «подгрейды».

В каждом грейде содержится свой список навыков и знаний.

Если углубиться дальше, то увидим список вопросов.

Отвечая на них, разработчик учится, а потом «сдаёт» грейд (об этом чуть позже) и получает новую зарплату и «звезду» на погоны.

Для фронтенда сейчас 8 уровней, а для бэкенда — 4: три для джуниоров и один для миддла (сеньоров пока ещё нет).

Для каждого грейда есть список технических и нетехнических вопросов.

Начнем с Junior. В нашей компании джун — это самостоятельная «боевая единица». Он умеет решать локальные декомпозированные задачи, которые укладываются в принятые в проекте соглашения и архитектурные принципы. По нашей карте джун уверенно владеет вёрсткой, хорошо знает JS, React и unit-тесты.

Middle больше про концептуальные знания, а не конкретные инструменты. Например, в миддловских грейдах мало вопросов про JS, а про React и вовсе нет. Зато много про ООП, принципы SOLID, DDD, и архитектуру в целом.

В нашей команде Middle не просто исполнитель. Он понимает, какую бизнес-ценность приносит команде и продукту, поэтому может предложить своё решение с аргументацией. Чаще всего он умеет задавать вопросы не только «Как решать задачу?», но и другие, например, «Почему эта задача важна?».

Senior не просто знает все принципы проектирования, а уверенно владеет, потому что опробовал на практике, собрав кучу костылей. В целом, он понимает боли и проблемы бизнеса, и от этого и отталкивается. Senior сам может выстраивать свою личную карту развития, потому что подкован по ближайшим темам и может себя здраво оценить.

Карта у нас охватывает разные области знаний и компетенций. Например, в списке к изучению на Junior-3 у нас есть книга Барбары Минто о том, как структурировать текст.

Книга пригодится разработчикам, чтобы лаконично и сжато донести какую-то свою идею, например, на стендапе за 2 минуты.

Навыки коммуникации важны. Наше основное направление — это коммерческая разработка в команде. Поэтому важно уметь доносить свои идеи как технарям (причём не только технические ценности), так и остальной части команды, например, объяснять сложные технические термины простым языком.

Также у нас есть вопросы по схемам управления, которые мы используем, информация про планирование, управление своим временем, декомпозирование и приоритизирование задач.

В первую очередь карта помогает разработчикам получать повышения.

Когда разработчик хочет перейти на следующую ступень, например, с Junior-1 на Junior-2, он:

• готовит одну или несколько тем из грейда;
• ищет 2-3 разработчиков, что уже сдавали эти темы;
• просит принять грейд.

Грейды может принимать любой член команды, который сам уже перешёл на этот же грейд или выше. Это обеспечивает бесперебойную и успешную работу инструмента.

Процесс принятия. Все договариваются об удобном времени для интервью в Telegram, а интервью проводят чаще в офисе. Но у нас треть сотрудников на удалёнке, поэтому мы встречаемся и в Zoom.

Интервью похоже на экзамен, когда 2-3 человека «прогоняют» разработчика по условному чек-листу вопросов. Но заучить ответы не получится, потому что всегда есть вопросы между строк, а ещё разные сеньоры любят «залетать все в белом и на коне» и «рубить» вопросами, аки Чапаев шашкой белых офицеров.

Примечание. Интервьюеры стараются собеседовать беспристрастно, потому что если они примут интервью «для галочки», то это нарушит работу всей команды в целом.

Сдача темы занимает пару часов, а подготовка — пару недель. После сдачи сдающий получает много обратной связи: дополнительные вопросы, источники от миддлов, которые нужно изучать. Вопросы потом «кочуют» по другим интервью: когда разработчик сдал грейд, а потом принимает сам, то тоже может их вспомнить. После этого вопросы могут стать частью карты.

Практика сдачи грейдов помогает также и интервьюерам, потому что «повторение — мать учения». Я регулярно спрашиваю наших разработчиков, что полезного они вынесли из последних приёмов, в которых они участвовали (именно приём, а не сдача). В ответ слышу, что польза в том, что это помогает систематизировать свои знания: темы осознаются гораздо глубже и запоминаются надолго. После таких разговоров мне часто представляется новый формат экзаменов в универе, где не только преподаватель принимает у студентов билеты, но и студенты принимают их у преподавателя 😄

В среднем, переход на следующий грейд занимает несколько месяцев. Например, наш рекорд — 10 месяцев до middle–1 с нуля, и 4 месяца до junior-3. Когда разработчик сдаёт грейд, мы объявляем об этом всей команде. Это маленький праздник и повод для гордости, особенно, если грейд был сдан быстро.

Ещё до онбординга мы оцениваем кандидатов по карте и отправляем ссылку, чтобы они понимали, что требуется знать для трудоустройства. Это удобно:

• на берегу рассказываем о ценностях в нашей команде;
• готовим к интервью, «раскладываем» все технические «карты» на стол;
• заранее отсекаем тех, кто не подойдёт;
• с теми, кто остался, проще договариваться о трудоустройстве.

Конечно, мы не требуем от новых разработчиков 100% знаний по всему грейду (который им присвоен). Пробелы заполняются в процессе адаптации и развития по карте.

Карта — это хороший инструмент адаптации: помогает оценить свои знания, подталкивает к тому, чтобы расти и знакомиться с командой. До и во время сдачи грейдов приходится искать коллег, которые сдавали недавно, уточнять нюансы и договориться с ними об интервью, обсуждать уровни.

Это создаёт атмосферу дружественного саморазвития, провоцирует разговоры в курилках и на обеде. Джуны у нас быстро кооперируются, обсуждают какие-то темы вместе, приходят и спрашивают у миддлов как они сдавали. Бывает, что бомбят на какие-то темы, но это здорово!

Начнём с минусов.

Сложность. Наша карта не всегда коррелирует с рынком. Наш Junior примерно равен среднестатистическому Middle-разработчику в какой-нибудь продуктовой компании (не сочтите за хвастовство). Мы стараемся ориентироваться на топовые компании и максимально прокачивать наших ребят. Поэтому в карте нет упора на то, чтобы выучить какие-то библиотеки и фреймворки за пару недель, а вопросы глубже. Мы хотим, чтобы наши ребята разбирались в своей сфере лучше. Но это сознательный выбор и для нашей команды себя оправдывает.

Примечание. У нас есть ещё проблема найма мидлов со стороны, потому что требования выше.

Распределение по грейдам субъективно. Это будет в любой карте, просто потому что в каждой компании свой стек. С этим придётся смириться.

Мало практики. Многие темы тяжело изучать, потому что мало практики. Но мы уже работаем над этим — экспериментируем с возможными решениями.

Для нас их больше.

Постоянные обновления. На GitHub карта постоянно развивается: она открыта, в неё можно добавлять дополнения. Когда разработчики изучают или сдают тему, они также могут через issue внести предложение или дополнительные вопросы. Карта дополняется также после интервью, на которых возникают «удачные» вопросы.

Культура. В нашей компании она основана на желании развиваться. Карта — маркёр желания.

Гибкость. В карте нет жестких правил, например, по срокам сдачи грейдов или количеству попыток. Но есть пара нюансов.

Ограничение есть для ребят, что выпускаются после нашей программы обучения. После учёбы они получают уровень junior-1 по нашей карте. Если они попадают к нам в команду, то мы обговариваем, что они должны в течение трёх месяцев (испытательный срок) обязательно сдать на junior-2.

Такое же ограничение действует, если мы берём на работу человека с «авансом». Например, даём ему уровень junior-3 с не очень уверенными знаниями. Также в течение испытательного он закрывает все пробелы по своим знаниям.

Подробности. Карта даёт довольно полное понимание о важных в нашей команде вещах, например, о разных нюансах TypeScript у фронтендеров или о расширениях компилятора Haskell у бэкендеров. Благодаря этому у нас есть собственная уверенность в силах разработчиков, сдавших грейды, ведь они подробно описаны.

Структура. Даёт чёткое определение тех знаний и компетенций, которые мы ждём от своей команды на разных уровнях.

Рекрутинг. Карта — дополнительный инструмент рекрутинга. Когда к нам приходят новые ребята (в том числе из нашей программы обучения), мы можем им сразу выдать максимально простой и понятный инструмент.

Мы не используем карту как инструмент увольнения. Наоборот, всегда стараемся лишний раз кого-то повысить. Бывали случаи, когда разработчик получил повышение, а его знания были ещё сыроваты. Но ребятам самим было некомфортно в компании людей того же грейда, у которых пробел меньше, и они всё «добирали» до занимаемого уровня.

Такая «страховка» сформировала систему открытости и ответственности. Плохая сдача интервью не повлияет на карьеру разработчика, но и не повод пропускать всех с сырыми знаниями, а самому человеку так и сидеть с ними.

Для замены One-on-One, Performance review или индивидуальных планов развития. Карта дополняет эти инструменты, как часть комплексной системы. Например, один из наших первых сотрудников, что перешел на удалёнку, «пинал» карту последние годы, но допинать до чего-то существенного не смог. Мы провели с ним One-on-One (также с одним из первых) и это помогло. Мы смогли обсудить проблемы, найти страхи и убедить просто начать.

Профессиональный рост. Карта помогает постоянно узнавать что-то новое, поддерживать интерес в профессии, писать код лучше и находить более интересные решения для задач.

Больше денег — грейды привязаны к зарплатной вилке (с 2019 года). Переходя на грейд выше разработчик будет получать больше. Но и внутри этого грейда он будет получать повышения в пределах вилки. Наша узкая специфика здесь помогает — легче описать каждый грейд, когда в стеке пара языков, чем когда описание стека занимает пару страниц. Оценивать работу, соответственно, тоже проще.

Это весело. Прозрачная система прокачки, как игра, только бонусы не магические бусы или кольцо удачи, а реальный кэш.

Добавить больше практических упражнений. Например, тему ООП тяжело проиллюстрировать, закрепить на каких-то реальных задачах и проектах, когда их нет под рукой. Разработчик может попасть в команду, где ООП не применяется, но сдавать ему всё равно придётся и знать на будущее.

Перевести на английский. У нас есть планы выхода на интернациональный уровень аутсорса. Для этого мы уже кое-что делаем:

• Формулируем (пытаемся) на английском вопросы от 2 Middle и выше.
• Все новые вопросы в карте сразу пишем на английском.
• Понемногу переводим старые темы на младших уровнях.

Когда мы окончательно решим представить карту мировому сообществу, подключим редакторов и корректоров, которые исправят перевод. В дальнейшем планируем публиковать карту на международных источниках.

Текущая версия карты со всеми уровнями находится на GitHub в публичном доступе. Все изменения (вопросы, комментарии, дополнения) вносим через pull request или issue. Поэтому добавить своё дополнение может любой, даже джун.

Несколько непрошенных советов, если понравился инструмент и решите внедрить его у себя.

Просто начните. Соберитесь с единомышленниками, найдите какие-то варианты карт, обсудите, и запустите самое простое MVP. Карту можно оформлять в любом документе, например, первую версию мы запустили на Rizzoma. Это некий аналог Google Docs — древовидный документ, который могут редактировать несколько человек: добавлять комментарии, исправления, ссылки.

Запустите первое демо. На MVP в Rizzoma мы потратили 50 часов: 2 уровня Junior (low и high) и 3 уровня Middle, 50 вопросов на каждый уровень. Сейчас в карту вложено уже 750 человеко-часов и только на уровне Junior больше 500 вопросов, довольно подробных. 50 часов — небольшая цена, чтобы понять, будет ли интересна команде идея карты развития, и будет ли она полезна вообще.

Запланируйте фичи. Добавьте в карту возможности обратной связи и Peer-to-Peer обучения. Например, у нас это реализовано через интервью. Когда разработчики сами проверяют знания у других разработчиков, сами что-то объясняют, рассказывают, это прокачивает их скиллы снова и снова.

Карта развития — полезный инструмент, который может помочь сделать систему максимально справедливой и минимально субъективной. Помните, что при работе с людьми стоит склоняться к false positive системе — тогда цена ошибки будет стремиться к нулю.