Аттестация сотрудников цода: как и зачем ее проводят в linxdatacenter / хабр

На каких этапах разработки продукта подключаются кодеры разных уровней?

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

В зависимости от стадии развития жизненного цикла продукта, потребности в разработчиках отличается:

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

Разработка. Создание MVP (minimum viable product — минимально жизнеспособный продукт). На этом этапе закладывается ядро продукта. Конечно, наши читатели могут сказать, что MVP нужно выкидывать и всё писать заново и правильно, но сколько вы видели случаев, когда бизнес так делал? “Ничего не бывает настолько постоянным, как временное”, в случае разработки это высказывание ну очень актуально. И именно поэтому здесь нужны senior-разработчики, которые с очень высокой степенью вероятности сразу все сделают правильно. Если нанять специалиста с более низкой квалификацией, то, скорее всего, потом придётся переписывать большую часть кодовой базы проекта.

Наш собственный кейс — сеньоры проделали львиную часть работы в разработке одного сложного продукта — платформы для проведения торгов по товарам/услугам в реальном времени между b2b, b2c, c2b и т.д. Они заложили в фундамент важные свойства availability (доступность), performance (производительность) и modifiability (модифицируемость). Ну а все остальное достроили миддлы с джуниорами.

Выпуск продукта на рынок. Стадия перехода из MVP в production — в этот момент количество задач начинает расти. Данные задачи в будущем будут частью core составляющей продукта и для их реализации желательно искать senior-разработчиков, которые смогут заранее заложить качественную архитектуру. К сожалению, здесь есть одна проблема. Дело в том, чтобы найти одного хорошего senior-разработчика, нужно потратить не менее 2-3 месяцев. Но выход есть. Так, если в команде уже есть один или два сильных разработчика, то под их начало можно привлекать middle-разработчиков, которые закроют потребность на этой стадии.

Рост продаж. Стадия быстрого роста продукта. Тут впервые сталкиваемся с highload. Если заложили подходящий фундамент в виде продуманной архитектуры, соответствующей НФТ (не функциональным требованиям), то можем усилить команду разработчиками уровня middle. В противном случае у команды будут бессонные ночи.

Зрелость (насыщение рынка). К этому времени появляется много задач по техническому долгу плюс идёт оптимизация ресурсов. Появляется возможность взять на обучение разработчиков уровня junior и вырастить их под свой стек и продукт.

Но это картинка идеального мира. В реальности senior-разработчиков часто подменяют middle-разработчиками из-за малых бюджетов, сроков, отсутствия опытных ревьюеров, способных найти подходящих senior’ов.

Завершая статью, отмечу, что за прошедшие несколько лет разрыв в плане знаний/скиллов между разными категориями если увеличился, то не сильно. Что гораздо важнее — значительно усилились требования ко всем разработчикам. Если рассматривать juinior’а, то пять лет назад можно было знать только базовую часть языка без различных фреймворков, баз данных и т.д. Сейчас же с этими знаниями тяжело даже попасть на должность стажёра куда-либо.

Альтернативы СММ

ISO 9000. Многие организации-разработчики и заказчики ПО успешно используют
широко известную серию стандартов ISO 9000. Новая версия стандартов этой серии
вышла в 2000 году и содержит в себе такие понятия, как процессы и совершенствование
процессов, заимствованные из модели СММ и отсутствовавшие в предыдущих версиях
ISO 9000. Следует, однако, заметить, что стандарты этой серии универсальны,
не ориентированы на какую-либо конкретную отрасль и не учитывают специфики IT-сферы.
Кроме того, ISO 9000 не предполагает никаких градаций (уровней) соответствия
и, тем самым, затрудняет определение «истинных» возможностей той или иной организации
(соответственно, и путей их дальнейшего развития).

SPICE/ISO15504. Другой альтернативой является модель SPICE (Software
Process Improvement and Capability dEtermination) и ее развитие — проект
международного стандарта ISO 15504 . Они сделаны на основе СММ и при непосредственном
участии того же SEI. Отличительной особенностью SPICE/ISO15504 по сравнению
с оригиналом является уход от последовательно-ступенчатого (staged) представления
и самого понятия технологической зрелости (process maturity). Модель SPICE/ISO15504
(как и ISO 9000) не выделяет ключевых областей процессов, а лишь устанавливает
общие и индивидуальные показатели уровня совершенства для всех процессов подряд.
Организации, которая использует SPICE/ISO 15504, по всей видимости, будет не
лишним обратиться к СММ для определения приоритетов своего развития.

CMMI. Наконец, еще одна альтернатива CMM for Software версии 1.1 — новая
интегрированная модель технологической зрелости CMMI .
Эта модель является результатом усилий Питтсбургского SEI по интеграции созданных
ранее моделей:

Software (SW) CMM для организаций-разработчиков ПО (именно она описана
в статье);
Systems Engineering (SE) CMM для организаций-разработчиков систем;
Integrated Product Development (IPD) CMM для организаций-разработчиков
интегрированных продуктов и технологий;
Software Acquisition (SA) CMM для организаций-заказчиков ПО.
Модель CMMI является ответом на стандарт ISO 15504, гармонизирована с ним
и предоставляет пользователю на выбор два варианта представления: последовательно-ступенчатое
(как в SW CMM) и сплошное (как в SPICE/ISO 15504).

Приложения

Turner & Jain (2002) утверждают, что, хотя очевидно, что между CMMI и гибкая разработка программного обеспечения, оба подхода имеют много общего. Они считают, что ни то, ни другое не является «правильным» способом разработки программного обеспечения, но в проекте есть этапы, на которых один из двух лучше подходит. Они предлагают объединить различные фрагменты методов в новый гибридный метод. Sutherland et al. (2007) утверждают, что сочетание Scrum а CMMI обеспечивает большую адаптируемость и предсказуемость, чем любой другой. Дэвид Дж. Андерсон (2005) дает советы о том, как интерпретировать CMMI в гибкой манере.

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

CMMI можно оценивать с использованием двух разных подходов: поэтапного и непрерывного. Поэтапный подход дает результаты оценки как один из пяти уровни зрелости. Непрерывный подход дает одно из четырех уровни возможностей. Различия в этих подходах ощущаются только при оценке; лучшие практики эквивалентны, приводя к эквивалентным результатам улучшения процессов.

Начнем с того, что должен знать junior, middle и senior

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

Junior-разработчик:

hard: знать основы ЯП (языка программирования);

hard: иметь минимальные знания стека, используемого в продукте;

hard: уметь самостоятельно решать простые типовые задачи;

soft: адекватно воспринимать критику;

soft: помимо 8 часов работы самостоятельно дополнительно обучаться 2-3 часа в день.

Middle-разработчик:

hard: знать хорошо основной ЯП, в том числе его тонкости, ограничения, best practices;

hard: знать и применять шаблоны и стандарты промышленной разработки;

hard: уметь подбирать несколько решений нужной задачи и находить оптимальный вариант;

hard: знать и уметь работать со стеком, используемым в компании;

soft: быть наставником для менее опытных коллег;

soft: находить общий язык с тем, от кого зависит решение задач: аналитик, тестировщик, DevOps и другие разработчики;

soft: понимать требования бизнеса;

soft: оценивать свои силы и трудозатраты по своим задачам;

soft: новое качество (на удаленке). Тайм-менеджмент и умение разделять работу и личную жизнь.

Senior-разработчик:

hard: уметь быстро изучить и внедрить новый инструмент в продукт;

hard: прорабатывать архитектуру новых компонентов в продукте;

hard: смотреть на продукт шире и видеть все его ограничения, узкие места и т.д.;

soft: понимать, для чего создается продукт, и задавать направление дальнейшего его развития;

soft: проводить декомпозицию задач;

soft: делегировать задачи;

soft: быть наставником для middle разработчиков;

soft: переключаться между своей ролью и другими ролями в команде, к примеру иногда быть как аналитиком, так и DevOps;

soft: видеть сильные и слабые стороны менее опытных коллег, помогать команде стать лучше;

soft: новое качество (на удаленке). Тайм-менеджмент и умение разделять работу и личную жизнь.

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

Стажер

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

Junior

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

Senior

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

Предпосылки к созданию инструмента

Задачу на создание модели зрелости поставил наш технический директор

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

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

Мы хотели создать модель, которая помогла бы избежать ряда проблем в будущем:

Развитие инженерных команд происходит, но понимание базового уровня у всех разное.
Одни команды знают, что прокачивать, и им нужно лишь задать вектор. Другие команды считают, что они знают, что прокачивать, но качают не то, что нужно компании. Есть и команды, которые не хотят прокачиваться — нет времени точить пилу, потому что надо пилить.
Когда нет общего стандарта, одни команды могут убежать далеко вперед, а другие — стоять на месте. Через какое-то время им станет тяжело находить общий язык и скоординированно достигать результатов.
Если ничего не делать, то со временем будут увеличиваться расходы компании на качество. Внесение изменений будет становиться всё дороже и дороже. В итоге пострадает технический или продуктовый бренд.
Мало кому интересно работать в незрелой команде. Хочется использовать последние технологии и лучшие практики.

История появления СММ

Еще в середине 70-х годов первые «симптомы» кризиса ощутили на себе военные
заказчики США, столкнувшиеся с взрывоподобным ростом объема и сложности задач,
возлагаемых на программное обеспечение, который был вызван появлением новейших
(по тем временам) средств вычислительной техники. Новые грандиозные проекты
требовали привлечения все новых и новых ресурсов для их реализации. Сроки выполнения
проектов постоянно срывались, качество ПО (соответствие ожиданиям заказчика)
оставалось на неприемлемо низком уровне, и Министерство обороны США начало всерьез
беспокоиться об эффективности расходования бюджетных средств.

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

В конце концов, был сделан вывод, что фундаментальная проблема «хронического
кризиса ПО» состоит в неспособности организаций управлять технологическим процессом
разработки программного обеспечения . И тогда военные приступили к поиску
формальных и объективных методов оценки способности организации-разработчика
произвести ПО требуемой сложности в установленные сроки и с требуемым уровнем
качества. В результате целенаправленного и плодотворного сотрудничества министерства
обороны США и Питтсбургского института программной инженерии (Software Engineering
Institute — SEI) в 1993 г. появляется окончательная версия т. н. «Модели технологической
зрелости организации-разработчика ПО» (Capability Maturity Model for Software
— SW CMM). Не вдаваясь в изнурительную дискуссию о принципиальной невозможности
однозначного перевода, здесь и далее по тексту используем достаточно свободную
интерпретацию основных понятий СММ, стремясь (там, где это возможно) донести
суть предмета в привычной или понятной для всех терминологии.

Модель зрелости Авито и как её адаптировать для своей компании

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

Чтобы начать адаптировать документ для своей компании, сделайте его копию. Для этого выберите в верхнем меню «Файл» → «Создать копию». В документе мы оставили только те секции, которые напрямую связаны с инженеркой.

Вкладка «Критерии оценки»

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

Мы оцениваем зрелость инженерных команд по шести основным блокам:

Информационная безопасность.
Обеспечение качества.
Перформанс.
Фронтенд.
Бэкенд.
Продакт-delivery.

Delivery — это процесс от продуктового бэклога до внедрения задачи в продакшен.

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

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

Вкладка «Оценки команд»

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

Оценка	Когда ставить
Команда на уровне 0 по критериям оценки.
1	Команда на уровне 1 по критериям оценки.
2	Команда на базовом уровне.
3	Команда на уровне 3 по критериям оценки.
	Команда не знает, какую оценку поставить. Нужно оценить уровень на встрече с экспертом.
N/A	Not applicable — пункт неприменим к конкретной команде. Например, команда инфраструктуры поиска в Авито не ставит себе оценки в секции по фронтенду, так как им не занимается.

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

Процесс оценки устроен следующим образом:

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

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

У нас много разных команд, и модель помогает всем, несмотря на то, что они разные. Это происходит за счёт того, что мы можем не ставить оценки по конкретным пунктам. В начале пути у нас были мнения, что для продуктовых команд и для технической платформы модели должны быть разными, но в итоге мы решили это противоречие через оценку N/A. Причём может быть так, что внутри одной секции половина пунктов к команде применима, а половина — нет. Ничего страшного в этой ситуации нет, оценка подтверждается через консультацию с экспертом, и в новых кварталах команда на такой пункт модели уже не смотрит.

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

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

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

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

CMM ( Capability Maturity Model)

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

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

Начальный. «Или как повезет». В организации нет повторяемости результата.
Успех одного проекта не гарантирует успех другого, хотя иногда случается. Причем успех — когда проект удалось завершить.
Результат определяется индивидуальными способностями инженеров.
Роль аналитика не выделена. «Требования к ПО ? — Нет не слышали».

Управляемый(Managed). «Не тушкой, так чучелком».
На этом уровне появляется гарантия достижения результата, но не соблюдение параметров проекта.
Появляется контур управления результатом, который преимущественно состоит из процессов управления проектом, управления требованиями (requirements management) и тестирования.
Собранные требования позволяют «мучать» команду до тех пор, пока не будет достигнуто соответствие требованиям.
Такой уровень зрелости процессов разработки лучше всего соответствует «Водопаду», в связи с частыми возвратами и пересмотру первоначальных требований. На этом уровне качество результатов значительно выигрывает при переходе к Гибким методологиям.

Определенный процесс (Defined). «Ведают что творят».
Стабильно воспроизводимый результат. Процессы разработки технологизированы (осознаны) на уровне компании в достаточной степени для достижения стабильного результата.
Снижена зависимость результата от компетенции отдельных сотрудников, в том числе благодаря процессам работы с компетенциями отдельных исполнителей.
Такие организации в состоянии достаточно надёжно предсказывать затраты на проекты, аналогичные выполненным ранее. Работа с требованиями переходит на качественно иной уровень — Проектирование требований (Requirements Development)

Особое внимание уделяется определению целей разработки и созданию «нужного» ПО. Гибкие методологии применяются осознанно в областях недостаточной экспертизы или в гибридном режиме.

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

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

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

К сожалению, в самой идеологии аттестации заложена предпосылка неверной трактовки уровней зрелости. Оценка подразумевает наличие доказательств того, что соответствующий процесс имеет место быть и имеет определенную результативность. И чем больший уровень зрелости имеет компания, тем большее количество процессов требует документального подтверждения при аттестации.
Т.е. с точки зрения CMMI — документирование процесса не является требованием (и тем более документирование всех процессов), скорее хорошей практикой в области организационного фокуса, но для того чтобы осуществить аттестацию, многие компании идут на бессмысленную и вредную бюрократизацию процесса …

Что примечательно

Хосе Луис Ипаррагирре (Jose Luis Iparraguirre), с которым мы работали над процессами компании NetCracker, рассказывал историю, что создатели модели первоначально не предполагали существование компаний 4,5 уровней в области разработки ПО. Эти уровни были созданы так сказать на вырост. «Представьте себе удивление команды разработчиков модели, когда оказалось, что такие компании уже реально существуют !» И это в 1991 году.

Выученные уроки и итоги

Чтобы модель зрелости работала и приносила компании пользу, нужны:

Эксперты и их вовлечённость в процесс. Это ключ к росту и динамике.
Мягкие коммиты от команд, чтобы они сами говорили, что будут прокачивать и когда.
Контроль процесса и его прозрачность. Нужно, чтобы всё было визуализировано в JIRA, гугл.документах или любых других инструментах.
Эпизодический пересмотр секций и повышение базового уровня.
Ответственный за саму модель, который сделает так, чтобы шестерёнки проекта крутились на уровне компании.

Благодаря внедрению модели нам удалось обналичить ситуацию такой, какая она есть. Мы поняли, где есть отставание от базового уровня и какое оно в разных командах. В самом начале пути на базовом уровне не было никого. За последний год нам удалось поднять до него 20% инженерных команд Авито.