Как мы строили систему обучения и мотивации в студии

В моей студии 15 человек, половина из которых - программисты. Студия специализируется на разработке интернет-магазинов, так что программисты для нас - основной ресурс.

От программистов всегда требуются три вещи

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

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

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

Что нужно, чтобы быстрее выполнить проект?

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

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

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

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

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

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

Получается, что программист остается без бонусов (а они существенны) не по своей вине.

Такой расклад был недопустим и эксперимент с бонусами за проекты пришлось свернуть.

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

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

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

Соотношение оклада и премии при этом на уровне 80/20%.

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

О чем речь: на основе оценок трудоемкости задач планируется работа программистов –расставляются задачи на краткосрочную (неделя) и долгосрочную (1–2 месяца) перспективу. Соответственно, если программист не уложится в указанный срок, то посыпется весь план-график работ, сдвинутся дедлайны по зависимым от него проектам И так далее.

Можно премировать, если уложился в оценку. Можно депремировать, если не уложился.

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

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

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

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

Задача изначально была неверно оценена

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

Задача обросла деталями по ходу

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

Если детали были очевидны, но менеджер их упустил

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

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

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

Мы находимся в Краснодаре, и тут в общем одна ecommerce-студия (собственно, мы). Это значит, что готовых кадров взять особо неоткуда. И всех нужно либо выращивать с нуля, либо «доращивать» с того уровня, который у них был в других студиях.

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

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

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

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

И тут я столкнулся с первой проблемой. Программисты почему-то не хотели учиться и не хотели расти по карте компетенций.

После пары месяцев тщетных попыток, я догадался спросить их: а что не так?

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

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

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

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

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

И вот это - сработало. Программисты стали заниматься саморазвитием, сдавать тесты и расти в зарплатах.

Тех, кто не готов учиться при условии выделенного времени и перспектив роста, стоит просто оставить в покое. Есть люди, которым комфортно на их уровне и если они при этом могут закрывать какие-то задачи, то почему нет?

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

Премии служат дополнительным мотиватором не столько на качество работы, сколько на погружение в работу смежных специалистов (поиск проблемных мест в дизайне и ТЗ до того, как оно финально будет согласовано).

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