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

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

Но хочется показать, как это происходит с точки зрения человека прошедшего эти этапы.

Стажер и действия

Первая ступень - это стажер. Что должен уметь стажер, что бы его взяли на работу, и он на ней остался? Чаще всего - ничего. Чуть реже - “что бы глаза горели”. Большие и известные компании чуть повышают планку, что бы срезать залетных. И от размера и известности конторы сложность планки повышают еще больше.

Но глобально это не сильно меняет ожиданий от этой карьерной ступени. Основное что все ожидают от стажера - это некоторые знание технических навыков и инструментов. И конечно же желание работать.

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

И как раз большие компании управляют входящим потоком резюме за счет изменения планки количества обычных технических навыков. Мелкие и неизвестные конторы не могут себе позволить проводить такую грубую фильтрацию кандидатов, поэтому снижают планку.

Но это я обсудил только момент входа на позицию стажера.

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

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

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

Да, только в одной из десятка тысяч компаний есть отдельный процесс для стажеров. В остальных случаях им приходится пользоваться общими процессами и инструментами (например, таск-трекерами).

Но на протяжении карьеры все равно есть этап когда человек является стажером. И может выполнять только базовые действия.

Джун и задачи

Очень быстро все смекают, что действия на работе складываются в цепочки действий. И в рамках этой и окружающих статей давайте договоримся, что задачами называются именно цепочки простых, сложно-делимых действий в рамках процесса разработки. О том, чем отличается задача от фичи в разделе ниже.

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

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

Что значит самостоятельно? Самостоятельно в данном контексте означает, что старшие коллеги показывают джуну место в системе (например, микросервис и название метода в нем), откуда начать первоначальный ресерч. И человек может от этой точки пройти все этапы разработки.

Что значит полноценно? Полноценно можно как раз разделить на те базовые действия, которые мы ожидали от стажера. Но теперь это джун, который понимает как построить действия в цепочку и, что самое важное, сделать все требуемые действия.

Если ты разработчик (про других я просто не знаю), то обычно для выполнения задачи, в компаниях с хорошо построенными процессами нужны следующие действия.

• Внимательно прочитать задачу

• Узнать где в системе эту задачу нужно решить

• Разобраться как система работает сейчас (TODO ссылку), без этой задачи.

  Тут как раз можно почувствовать разницу, какой тип задачи нужно было заводить менеджеру - баг или новая функциональность. В баге описано два поведения системы: текущее и требуемое. В новой функциональности обычно не пишут о текущем поведении.

• Написать или изменить код

• Проверить, что написанное тобой не просто рандомно напечатанный текст. Протестировать. Обычно, юнит тестами.

  Если этот этап сложно сделать, значит архитектура кодовой базы должна быть пересмотрена 💩

• Пройти ревью старших коллег, поправить все замечания

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

Q: Процесс описанный выше выглядит как что-то в вакууме.
A: Согласен, тепличные условия практически всегда расходятся с реальностью. Но как раз из-за этого и получается современный хаос при разработке. Что не изменяет общего процесса, но позволяет работникам расти профессионально. А так же оценивать - нравится ли им такая специальность. А так же что ждет впереди.

Мидл и фичи

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

Если не появляется, то стоит спросить почему. И возможно, с менеджментом что-то не так.

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

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

И вот на этом этапе появляется первые сложности связанные с софт-скилами для разработчика. Причем обе сложности противоположны друг другу.

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

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

И испытание состоит в том, что бы разработчик не перешел тот порог между выполнением задач и выполнением фичей. Тут важно, что размер выдаваемой функциональности не должен вырастать с прошлых задач, до размера фичей. Здесь многие разработчики совершают ошибку, считая что им все еще выдают задачи. И поставлять нужно их. Но это не так.

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

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

Ожидается что разработчик сможет самостоятельно пройти по процессу разработки и донести выполненную работу до заказчика или потребителя. Но он это делает не маленькими независимыми кусочками, а одним большим мешком с котом. Почему с котом? Потому что, как показывает моя практика, большие МРы никто не смотрит качественно. Хотя когда кода написано много, и будет сделано много изменений в системе, проверять результат работы нужно особенно тщательно.

Иногда, сами процессы CI/CD компании заставляют разработчиков правильно декомпозировать фичи на задачи. Например, если фича должна быть сделана в нескольких сервисах. Или если обновление схемы базы данных отделено в другой процесс, отличный от релиза кода приложения. И это как раз свидетельствует о том, что все подстраивают процессы разработки именно под задачи, а не под фичи.

Итого, что бы стать уверенным мидлом, нужно научиться правильно работать с цепочками задач - фичами. Уметь вести процесс разработки (программировать, тестировать, релизить) именно по задачам. Которые должны появиться после декомпозиции фичи.

Сеньор и проекты

Сеньор должен уметь делать целые проекты.

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

Ожидается, что сеньор сам декомпозирует проект на нужные куски. И поняв их количество, сможет определить сколько ресурсов (практически всегда это время, но не только) нужно ему для воплощения проекта в жизнь.

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

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

Тем не менее сеньор должен уметь думать на уровне проекта. И по мере набора скилов по реализации проектов можно выходить на новый уровень.

Лид и направления

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

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

Как пользоваться фреймворками. Уметь выбрать его (если политика компании позволяет это делать). Проводить код ревью и рассказывать младшим коллегам почему так не стоит делать в конкретном случае.

Тут хочется подчеркнуть, что от техлида ожидается что он будет вести за собой других. Странно видеть, когда лычку техлида надевают на ребят которые просто много знают. Много знать в домене тоже важно. Но если человек просто хорошо делает новые сложные фичи или проекты, это не делает его лидером. Он просто отличный специалист, которому скорее всего много платят. И в этом случае лучше назваться каким-нибудь “экспертом”, или в англоязычном мире используют слово principal.

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

Если посмотреть с точки зрения развития бизнеса на иерархию, то тимлиды как раз являются теми людьми, кто поставляет бизнес ценность в компанию. Просто они это делают руками своих подчиненных.

Вот и получается, что

• в разных компаниях от тимлидов ожидают разного
• практически всегда тимлидам все равно нужно уметь во все три навыка: проджект менеджмент, пипл менеджмент, техническую экспертизу
• находится между двух огней: продуктом/заказчиками и разработчиками. А иногда и трех, когда структура компании на столько большая, что СТО и другие отделы существуют и продвигают свои цели независимо от бизнеса

Топ и проблемы

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

Но это я только пересказываю, что бы можно было осознать масштаб работ.

Пример

Такую лестницу можно представить на примере сбора конструктора лего.

Сначала учатся просто скреплять детали, понимать какие скрепляются а какие - нет. Следующим этапом становится сбор небольших моделей или наборов. После можно начать собирать большие модели. Но к умению просто их собирать по инструкции добавляется небольшое требование - уметь заменять части конструкции, если это нужно, или требуется в условиях окружающей действительности. Далее человек уже набирается опыта и свободно собирает конструктор из доступных ему деталей. Может сформулировать, какие детали ему хотелось бы добавить, а какие - критически необходимы. После уже можно становится или дизайнером таких моделей, или координатором отрядов сборщиков конструкторов. Причем, достаточно часто по рынку приходится выполнять обе роли. Ну и так далее.

Собеседования

Очевидно, что в зависимости от размера компаний разные лычки не означают разный набор навыков. Например, тимлид команды разработки человек на 10-15 из большой корпорации вполне мог бы быть техническим директором небольшого стартапа на 30 человек.

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

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