Как выстроить систему обучения и мотивации программистов: история одной компании | SEO кейсы: социалки, реклама, инструкция

19 августа 2019, 16:00

Новости

10/11/2024 Как купить игру в Steam с использованием Mastercard

10/11/2024 Способы пополнения кошелька Steam в России

31/10/2024 Документы для ипотеки на вторичное жилье с материнским капиталом

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

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

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

1-ый этап

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

Что необходимо, чтоб прытче выполнить чертеж?

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

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

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

2-ой этап

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

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

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

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

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

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

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

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

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

Доказываем улечся в свою оценку трудозатрат

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

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

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

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

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

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

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

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

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

Задачка вначале была ошибочно оценена

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

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

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

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

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

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

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

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

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

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

Что обязан знать программер

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

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

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

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

Догадка 1

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

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

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

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

Догадка 2

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

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

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

Догадка 3

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

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

Выводы

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