Senior

Вместо эпиграфа

Когда в 2004 году я окончил университет, в нашем городе почти не было команд разработчиков.
Где работать, у кого набираться практического опыта?
Выбор был прост: админом или в Москву. Или уйти из профессии.
Сейчас я преподаю веб-разработку в местных ВУЗах, руковожу большим коллективом и мне важно, чтобы в моем городе хотели жить толковые молодые ребята, чтобы наш город не считался тухлым местом.

Суть статьи коротко

Мы с коллегами умеем растить веб-программистов с почти нуля до уровня уверенного профессионала (Senior / Архитектор).
Хотим рассказать как все работает и поделиться с сообществом материалами и методикой.

Статья написана для студентов, начинающих и растущих веб-разработчиков.

Далее описан трек развития веб-разработчика, уровни компетенций Стажер, Junior, Middle, Senior и Architect, как я их вижу и даны примеры аттестационных заданий.

Пирамида способностей программиста или что качать на старте

Как стать хорошим веб-программистом? Нужно ли заканчивать информатику в хорошем ВУЗе? Или хватит месячных курсов? Или с книжкой и мышкой все можно изучить?

Три кита, на которых стоит профессия любого разработчика на любом стеке технологий, это алгоритмизация, базы данных и собственно программирование (язык + ООП + паттерны).

Что такое алгоритмизация?

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

Логика очевидна: разделил на части и проверил каждую. Удивительно, но многие люди не умеют так мыслить. У настоящего программиста это в крови.

Базы данных

Курс БД один из основных, как физика для инженера. Плохо что часто преподают их одинаково плохо: сводят к пересказыванию параграфов.

В БД важны и теория, и практика. Программист должен уметь и писать запросы, и разбираться в логике ORM, и проектировать структуру.

Какие технологии нужно знать программисту?

Из чего вообще состоит профессионализм разработчика?
Указано примерное время освоения при классическом пути развития (начиная с ВУЗа).



По уму алгоритмизации учат в школе/ВУЗе. Тратится на это 1-2 года, и этот период определяет высоту будущего профессионального взлета. Если вы не освоите алгоритмизацию, то никогда не вырастете.

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

Фреймворки часто включают сотни модулей/классов/расширений и постоянно развиваются. Освоение фреймворка займет у вас несколько месяцев как минимум.

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

Конкретные технологии (например AJAX, серверный рендеринг JS, push&pull, распределение нагрузки по гео-кластеру, профилировка долгих запросов в xhprof, очереди сообщений, NoSQL базы данных) бесконечно разнообразны. Учить их можно вечно.

Эту пирамиду нужно проходить снизу вверх. Если вы начнете с фреймворка и напишете красивое резюме, но не будете знать как работает голый JS или чем get-запрос отличается от post профи вам не быть.

Какие задачи нужно решать?

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

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



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

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

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

Это очень сложный переход. Многие программисты не делают его никогда: они становятся разработчиками одной программы или всегда пишут проекты не более чем в 200 строк. Это не уровень профи.

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


Большие задачи реальные сервисы, которыми пользуются люди, где команда состоит минимум из 2 человек, и состоящие из тысяч строк кода. Такие проекты формируют уверенного специалиста.

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

Более сложная и более полезная книга Шаблоны корпоративных приложений Мартина Фаулера. Ее тоже нужно прочитать, примерно через год-полтора работы в профессии.

А зачем? Можно просто закончить 3-месячные курсы веб-разработчика?

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

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

Хороший программист знает теорию и применяет на практике, все время думая как сделать правильно. На спинном мозге и копировании кусков кода из гугла далеко не уедешь. Нужна база и практика.

Как получить эту базу? Где правильно учиться? Есть два пути.
Первый 4-5 лет в хорошем ВУЗе.
Второй несколько лет упорного самообучения и практики. Можно стать сильным программистом без профильного образования, если у вас светлая голова, открытое сердце, а вы сами готовы много работать.

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

Матрица компетенций. Стажер Junior Middle Senior Architect

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

По ссылке доступна полная матрица с примерными вопросами по аттестации.

Это таблица, разделенная на грейды (стажер, junior, middle, senior). Каждый грейд содержит набор уникальных компетенций. Вопросы сгруппированы по областям знаний (PHP, SQL, Frontend, веб-технологии в целом и управление серверным хозяйством)

Стажер

На старте стажер должен быть способен:

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

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

Junior

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

Что практически должен уметь Junior на старте:

• переписать (а значить досконально понимать) авторизацию на сайте;
• уверенно править настройками и кодом фреймворка работу каталогов, ленты новостей, формы;
• собирать простые интерфейсы управления данными и целые сайты на фреймворке;
• писать простую интеграцию с внешним API.

Middle

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

Что практически должен уметь Middle на старте:

• работать с внешней авторизацией (войти через внешний провайдер или сделать свой код провайдером авторизации);
• уверенно программировать интерфейсы публичных интернет-магазинов, маркетплейсов или интранет-порталов (в зависимости от специфики);
• собирать сложные интерфейсы управления данными и разделы на фреймворке;
• писать сложные интеграции с внешним API, реализовывать веб-сервисы.

Senior

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

Вот например, что сам Senior должен знать и уметь по блоку Работа с серверами и Linux.

• Сборка нетиповой системы выкатки изменений
• Работа с микросервисами.
• Организация нагрузочного тестирования
• Настройка continuous integration
• Синхронизация файлов и репликация данных
• Сборка отказоустойчивого и высоконагруженного кластера на Bitrix Framework и без него.
• ELK / другие системы логирования и аналитики
• Серверы очередей Gearman / RabbitMQ и построение распределенных систем

Как правило, Senior играет роль технического лидера группы разработчиков.

Architect

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

Такие специалисты играют ключевую роль в технически и организационно сложных проектах.

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

Управление развитием программиста

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

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

Как устроена проверка уровня (аттестация)?

Что такое аттестация?
Это процедура подтверждения квалификации программиста. Ее проходят все программисты.
Аттестация включает лабораторные работы и устные экзамены.

В результате аттестации в матрице компетенций появляются Да напротив подтвержденных компетенций. От этого увеличивается грейд, например, Стажер-54% Junior-27%.

Как проходит аттестация?

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

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

Многие блоки матрицы компетенций закрываются практикой и теоретических вопросов по ним нет.

Теория. Устный экзамен

Компетенции, не покрытые лабораторными работами нужно подтвердить на устном экзамене.

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

Практика. Лабораторные работы

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

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

Примерные формулировки заданий

Мы разработали около 20 заданий (называем их привычно для студентов лабораторные работы). Несколько опубликуем.

Вот примеры простых заданий.

Задание 2а. Базовый web. Реализуем CRUD на чистом PHP.

Компетенции:

• PHP: Аутентификация и авторизация на сайте
• PHP: Обработка форма обратной связи с сохранением данных и валидацией
• Фронт: Создание форм на html
• Фронт: Синтаксис и селекторы CSS, общее представление о весах селекторов
• SQL: Основы Mysql
• SQL: Типы данных
• PHP: Синтаксис языка PHP

Суть:

• завести репозиторий на bitbucket и выполнять в нем;
• сразу сделать ветку и pull request;
• в PhpStorm установить плагин Statistic, максимальное кол-во строк на весь проект 1500:
• через PhpStorm создать необходимые таблицы и заполнить их данными;
• сделать страницу аутентификации;
• сделать страницу с формой обратной связи, на которой есть: текстовое поле, многострочное текстовое поле, радиокнопки, флажки, выпадающий список, кнопка сброса формы, кнопка отправки формы;
• форма обратной связи доступна только авторизованным пользователям, критерий допуска вход в систему выполнен;
• все красиво сверстать, показать пример использования основных типов селекторов: id, class, attribute, pseudo-class, pseudo-element;
• обе формы должны обрабатываться без JS;
• проверить через PhpStorm, что данные добавляются в таблицу.

Проверка:

• проверяется качество декомпозиции php, js, css;
• умение выделить ответственность и установить правильные зависимости между компонентами MVC/ECB;
• безопасность (доступ);
• безопасность (XSS, SQL injection);
• корректность редиректов;
• единство стиля оформления кода.

Развитие задания

Задание 2б. Развитие CRUD-интерфейса на PHP.

Компетенции:

• 3 способа подключения скрипта
• Создание форм на html
• Синтаксис и селекторы CSS, общее представление о весах селекторов
• JS: операторы, функции
• Отладка JS с помощью консоли браузера
• Основы Mysql
• Типы данных

Суть продолжаем работу над сайтом из задания 2а:

1. сделать мини-админку:
2. список отправленных форм обратной связи;
3. список должен быть отсортирован по дате отправки, новые сначала;
4. список можно обновить, это делается с помощью AJAX;
5. совет: для интерактивного тестирования запросов к БД используйте консоль БД в PhpStorm;
6. отправленную форму можно удалить из админки, все на AJAX;
7. таким образом продемонстрировать все способы подключения JS;
8. отправленные данные можно отредактировать (использовать уже разработанную форму, без AJAX);
9. можно использовать jQuery.
10. открыть инструменты разработчика (желательно Firefox):
11. найти источник запроса из лога запросов;
12. установить точку останова, спровоцировать выполнение кода, изучить пошаговое выполнение кода;
13. во время пошагового выполнения просмотреть значения переменных через соответствующий инспектор;
14. добавить watch;
15. воспользоваться консолью для доступа к переменным в текущей области видимости.

Проверка:

1. проверяется качество декомпозиции php, js, css;
2. умение выделить и установить правильные зависимости между компонентами MVC/ECB;
3. безопасность (доступ);
4. безопасность (XSS, SQL injection);
5. единство стиля оформления кода;
6. все пункты по использованию инструментов разработчика продемонстрировать.

Вот пример средней сложности

Задание 10. Парсинг сайтов

Компетенции:

• Регулярные выражения
• HTTP-запросы с сервера, cURL
• TODO: написание консольных утилит (и одноразовых скриптов) на кодовой базе Bitrix Framework
• TODO: добавить CRON

Суть:

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

Проверка:

• корректность CLI-окружения
• декомпозиция регулярных выражений
• экономичность по запросам
• обработка ошибок
• возможность параллельного парсинга нескольких объектов сразу
• Работа в консольном и интерактивном режиме
• *работа в режиме внешнего сервиса, доступного по HTTP, с поддержкой очередей

Посмотреть и скачать матрицу компетенций 2020

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

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

Давайте приведем возможные доводы за то, чтобы строить HR политику на наборе джуниоров и их последующем росте.

Дисклеймер 1: Безусловно разделение на junior-middle-senior, используемое в статье, крайне условное и мало связано с опытом работы, а градация и зарплатные уровни сильно зависят от компании, в которой дается оценка. Однако мы живем в реальности, в которой на hh в вакансиях ведущих it компаний используется такая терминология, и все мы, так или иначе, понимаем о чем речь, и примерно какой набор требований предъявляется в том или ином случае. И предвосхищая дальнейший текст статьи, заверяю, что абсолютные величины не так важны для сделанных выводов.

Дисклеймер 2: Рассуждения по большему счету не про топ компании, в которых и так все в порядке, а скорее про остальное большинство. Так же разговор идет про технически сложные продукты, правда в возможность существования простых, в общем случае, особо и не верю. Простые продукты (вспоминая Пола Грэма и его книгу "Хакеры и Художники") вряд ли могут успешно существовать на конкурентном рынке, в противном случае их было бы слишком просто скопировать и повторить.

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

Практически все доводы несостоятельны. Давайте по порядку.

Себестоимость продукта с джунами выше чем с профессионалами

Платя зарплату джуниору, вы не платите за работу над продуктом, вы платите этакий базовый минимум, чтобы ему было на что существовать, ну и конечно за надежду, что когда-то и он полноценно встанет у станка. Дальнейший рост зарплаты от старта сильно не пропорционален росту эффективности. Т.е. себестоимость выполненной работы у малоквалифицированного сотрудника выше, чем у более квалифицированного. Поясним это. Платя мидлу, половина платы уходит в упомянутый выше базовый набор, а остальное уже в продукт. Ведь условно ЗП мидла это две ЗП джуниора, а сеньора 3 зарплаты джуниора. Таким образом, вместо двух сеньоров можно взять 6 джунов или 3 мидла. В случае 2 сеньоров, 2/3 зарплатного фонда идет в продукт, а 1/3 в базовый набор. В случае 3 мидлов 1/2 зарплатного фонда идет в создание продукта и 1/2 в базовый набор. А теперь вспомним про кривую роста эффективности.

График построен на моем опыте. Принимаем допущение, что уровень программиста соответствует ЗП. Конечно же он выглядит не справедливым.

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

"Мифический человеко-месяц":

Руководители программистских проектов давно уже поняли, как значительны различия в производительности хороших и плохих программистов. Тем не менее результаты точных измерений этой величины просто поражают. В одной из своих работ Сакмен, Эриксон и Грант измеряли производительность группы опытных программистов. Даже внутри этой группы отношение максимальной и минимальной
производительности в среднем составило 10:1, а для времени работы программы и затрат памяти 5:1. Короче говоря, производительность труда программиста, получающего 20 тыс. долларов в год, может быть в 10 раз больше, чем у того, кто зарабатывает 10 тыс. долларов. Обратное также может быть справедливо. Статистические данные утверждают, что нет никакой зависимости между опытом и производительностью. (Сомневаюсь, впрочем, чтобы это было верно всегда.)

Коммуникация узкое место

Продолжая сравнивать 3 джуниоров против одного сеньора нельзя забывать и о том, что на коммуникацию и синхронизацию 3 джуниров уйдет порядка 10-20% общего времени. Чем больше людей, тем больше издержек. Таким образом, набор джуниоров идет и против стратегии сохранения наименьшего количества разработчиков работающих над проектом. То, о чем говорил Келли Джонсон в Skunk Works, ну и конечно же Брукс.

Джуниор это инструмент, но не самодостаточная единица

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

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

Подобное к подобному

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

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

Наем профессионала vs джуниора

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

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

Джуниоры крадут время у наиболее боеспособных единиц

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

Подводя итоги: команда мечты

Получается что вообще сторониться джуниоров? Куда же им тогда податься?
Конечно же джуниоров можно брать, но на "сдачу". Наем джуниоров как стратегия на далекое будущее, в некотором роде рискованные инвестиции. По моему опыту на команду из 5 человек максимально допустимо иметь 1 джуниора и 1 мидла. И это не история про то, что джун и мидл это тестеры, devops'ы, техписы.

Допустим у нас на команду есть бюджет 550-600 т.р.
Можно пойти двумя путями и попытаться сформировать классическую команду из 7 человек, либо сделать упор на максимальное количество профессиональных разработчиков.

Попытаемся представить как могла бы выглядеть первая команда:

Команда строящаяся на основе джуниоров

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

1) Сеньор-лид 150 т.р. (8х 4x (Половина времени на обучение и организацию) = 4x)
2) Мидл? 110 т.р. (5х 1х Обучение = 4х)
3) Мидл? 80 т.р. (2x)
4) Мидл? 65 т.р. (1x)
5) Мидл? 60 т.р. (1x)
6) Джун 55 т.р. (0.2x)
7) Джун 50 т.р (0)

Общая производительность без учета потерь на коммуникацию: 12.2x
Принято считать, что добавление каждого нового члена в команду отъедает до 5% общего времени на коммуникацию. Т.о. общая производительность с учетом потерь на коммуникацию: 12.2x * 0.7 = 8.54x
КПД: 66 т.р. за 1x производительности.

Проблемы этого варианта, кроме низкого КПД:

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

Команда на основе сеньоров

1) Сеньор-лид 170 (8x 2x (Орг. деятельность) = 6х)
2) Сеньор 160 (8x)
3) Сеньор 160 (6x)
4) Мидл 100 (3x)

Общая производительность без учета потерь на коммуникацию: 23x
Общая производительность с учетом потерь на коммуникацию:23x * 0.8 = 18.4x

КПД: 32 т.р. за 1x производительности.

Дополнительные плюсы, кроме высокого КПД:

• Большой запас по КПД дает возможность увеличения ЗП для удержания сотрудников, прежде чем команда станет не эффективна по сравнению с командой на джуниорах
• Продукт качественнее (быстрее, эффективнее, юзабельнее, проще)

Выводы

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

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

Давайте приведем возможные доводы за то, чтобы строить HR политику на наборе джуниоров и их последующем росте.

Дисклеймер 1: Безусловно разделение на junior-middle-senior, используемое в статье, крайне условное и мало связано с опытом работы, а градация и зарплатные уровни сильно зависят от компании, в которой дается оценка. Однако мы живем в реальности, в которой на hh в вакансиях ведущих it компаний используется такая терминология, и все мы, так или иначе, понимаем о чем речь, и примерно какой набор требований предъявляется в том или ином случае. И предвосхищая дальнейший текст статьи, заверяю, что абсолютные величины не так важны для сделанных выводов.

Дисклеймер 2: Рассуждения по большему счету не про топ компании, в которых и так все в порядке, а скорее про остальное большинство. Так же разговор идет про технически сложные продукты, правда в возможность существования простых, в общем случае, особо и не верю. Простые продукты (вспоминая Пола Грэма и его книгу "Хакеры и Художники") вряд ли могут успешно существовать на конкурентном рынке, в противном случае их было бы слишком просто скопировать и повторить.

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

Практически все доводы несостоятельны. Давайте по порядку.

Себестоимость продукта с джунами выше чем с профессионалами

Платя зарплату джуниору, вы не платите за работу над продуктом, вы платите этакий базовый минимум, чтобы ему было на что существовать, ну и конечно за надежду, что когда-то и он полноценно встанет у станка. Дальнейший рост зарплаты от старта сильно не пропорционален росту эффективности. Т.е. себестоимость выполненной работы у малоквалифицированного сотрудника выше, чем у более квалифицированного. Поясним это. Платя мидлу, половина платы уходит в упомянутый выше базовый набор, а остальное уже в продукт. Ведь условно ЗП мидла это две ЗП джуниора, а сеньора 3 зарплаты джуниора. Таким образом, вместо двух сеньоров можно взять 6 джунов или 3 мидла. В случае 2 сеньоров, 2/3 зарплатного фонда идет в продукт, а 1/3 в базовый набор. В случае 3 мидлов 1/2 зарплатного фонда идет в создание продукта и 1/2 в базовый набор. А теперь вспомним про кривую роста эффективности.

График построен на моем опыте. Принимаем допущение, что уровень программиста соответствует ЗП. Конечно же он выглядит не справедливым.

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

"Мифический человеко-месяц":

Руководители программистских проектов давно уже поняли, как значительны различия в производительности хороших и плохих программистов. Тем не менее результаты точных измерений этой величины просто поражают. В одной из своих работ Сакмен, Эриксон и Грант измеряли производительность группы опытных программистов. Даже внутри этой группы отношение максимальной и минимальной производительности в среднем составило 10:1, а для времени работы программы и затрат памяти 5:1. Короче говоря, производительность труда программиста, получающего 20 тыс. долларов в год, может быть в 10 раз больше, чем у того, кто зарабатывает 10 тыс. долларов. Обратное также может быть справедливо. Статистические данные утверждают, что нет никакой зависимости между опытом и производительностью. (Сомневаюсь, впрочем, чтобы это было верно всегда.)

Коммуникация узкое место

Продолжая сравнивать 3 джуниоров против одного сеньора нельзя забывать и о том, что на коммуникацию и синхронизацию 3 джуниров уйдет порядка 10-20% общего времени. Чем больше людей, тем больше издержек. Таким образом, набор джуниоров идет и против стратегии сохранения наименьшего количества разработчиков работающих над проектом. То, о чем говорил Келли Джонсон в Skunk Works, ну и конечно же Брукс.

Джуниор это инструмент, но не самодостаточная единица

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

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

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

Подобное к подобному

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

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

Наем профессионала vs джуниора

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

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

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

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

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

Джуниоры крадут время у наиболее боеспособных единиц

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

Подводя итоги: команда мечты

Получается что вообще сторониться джуниоров? Куда же им тогда податься?

Конечно же джуниоров можно брать, но на "сдачу". Наем джуниоров как стратегия на далекое будущее, в некотором роде рискованные инвестиции. По моему опыту на команду из 5 человек максимально допустимо иметь 1 джуниора и 1 мидла. И это не история про то, что джун и мидл это тестеры, devops'ы, техписы.

Допустим, у нас на команду есть бюджет 550-600 т.р.

Можно пойти двумя путями и попытаться сформировать классическую команду из 7 человек, либо сделать упор на максимальное количество профессиональных разработчиков.

Попытаемся представить как могла бы выглядеть первая команда:

Команда строящаяся на основе джуниоров

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

1) Сеньор-лид 150 т.р. (8х 4x (Половина времени на обучение и организацию) = 4x)
2) Мидл? 110 т.р. (5х 1х Обучение = 4х)
3) Мидл? 80 т.р. (2x)
4) Мидл? 65 т.р. (1x)
5) Мидл? 60 т.р. (1x)
6) Джун 55 т.р. (0.2x)
7) Джун 50 т.р (0)

Общая производительность без учета потерь на коммуникацию: 12.2x
Принято считать, что добавление каждого нового члена в команду отъедает до 5% общего времени на коммуникацию. Т.о. общая производительность с учетом потерь на коммуникацию: 12.2x * 0.7 = 8.54x
КПД: 66 т.р. за 1x производительности.

Проблемы этого варианта, кроме низкого КПД:

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

Команда на основе сеньоров

1) Сеньор-лид 170 (8x 2x (Орг. деятельность) = 6х)
2) Сеньор 160 (8x)
3) Сеньор 160 (6x)
4) Мидл 100 (3x)

Общая производительность без учета потерь на коммуникацию: 23x
Общая производительность с учетом потерь на коммуникацию:23x * 0.8 = 18.4x

КПД: 32 т.р. за 1x производительности.

Дополнительные плюсы, кроме высокого КПД:

• Большой запас по КПД дает возможность увеличения ЗП для удержания сотрудников, прежде чем команда станет не эффективна по сравнению с командой на джуниорах
• Продукт качественнее (быстрее, эффективнее, юзабельнее, проще)

Выводы

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