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

Константин Елистратов

Основатель и генеральный директор студии интернет-продаж IARGA

Есть три вещи, которые всегда требуются от программистов:

• Быстрее сдавать проекты.
• Укладываться в собственную оценку трудозатрат.
• Расти и развиваться

Но по разным причинам они не всегда к этому готовы.

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

Как начать быстрее сдавать проекты

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

Как мотивировали

Первый этап

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

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

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

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

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

Второй этап

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

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

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

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

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

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

Так нужна ли в этом случае материальная мотивация?

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

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

Мотивируем укладываться в свою оценку трудозатрат

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А все же нужна ли здесь финансовая мотивация?

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

Обучение программистов и мотивация к развитию

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

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

Что должен знать программист

• Фронтенд
• Бэкенд
• Движок
• Интеграции (1С и так далее)
• Linux, Nginx, Apache

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

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

Как мы растили разработчиков

Гипотеза 1

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

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

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

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

Гипотеза 2

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

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

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

Гипотеза 3

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

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

Выводы

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