От программистов всегда требуются три вещи
- Быстрее сдавать проекты.
- Укладываться в собственную оценку трудозатрат.
- Расти и развиваться
Но по разным причинам они не всегда к этому готовы. Как мы мотивировали программистов на улучшения по всем трем направлениям, с какими сложностями столкнулись и что из этого вышло, расскажу в статье.
Как мы начать быстрее сдавать проекты
Сразу проговорим, почему это важно: если программист быстрее сдает проект, компания быстрее зарабатывает на запуске и в конечном счете быстрее зарабатывает и программист. Так как он быстрее переходит к следующему проекту, а предыдущий уходит на поддержку и продвижение. Казалось бы, все очевидно, тем не менее мы видели, что программисты выполняют задачи и сдают проекты не настолько быстро, насколько могли, и решили помочь им ускориться
Как мотивировали
Первый этап
Первым вариантом было составить зарплату программиста наполовину из оклада и наполовину из бонусов за выполнение проекта. В результате компания и разработчик будут «в одной лодке», и успешность одного будет прямо влиять на успешность второго. Казалось бы, все логично, остается только ускориться.
Что нужно, чтобы быстрее выполнить проект?
Очевидно, нужно быстрее программировать. Как это сделать? Меньше отвлекаться и все хорошо делать сразу, чтобы не пришлось переделывать.
Но здесь мы уперлись в другую проблему: программисты не всегда отвлекаются по своей вине или по своему желанию. Например, менеджер может перевести программиста на решение задач по поддержке его же более ранних проектов.
К тому же между разработкой и сдачей проекта находится длительный и проблемный процесс интеграции. Так что программист получал бонусы за разработку еще не сданного проекта. Это казалось не очень логичным, поэтому мы продолжили искать варианты.
Второй этап
Вторым решением было выплачивать бонусы по факту сдачи проекта, а не по факту его выполнения.
Теперь программистам стало еще хуже: на получение ими бонусов влияли не только сопутствующие задачи, но и, например, скорость предоставления заказчиком доступов для интеграции с оплатой и доставкой (а иногда это несколько месяцев), и скорость работы его 1С специалистов (для интеграции с 1С).
Также на этапе программирования вскрываются все ошибки предыдущих шагов: планирования, проектирования, дизайна. И программисту приходится их исправлять фактически за голый оклад (а он в рамках этой системы был очень мал).
Получается, что программист остается без бонусов (а они существенны) не по своей вине.
Такой расклад был недопустим и эксперимент с бонусами за проекты пришлось свернуть.
Здесь пришло время извиниться перед командой разработчиков за такие эксперименты. До сих пор поражаюсь, как они все тогда не разбежались.
Результатом эксперимента стало понимание того, что программисты достаточно сильно мотивированы делать задачу быстро и хорошо, если им при этом не мешать. И в дополнительных стимулах не нуждаются.
Так нужна ли в этом случае материальная мотивация?
Нужна. Небольшая премия по факту сдачи проекта мотивирует программиста не «лучше работать» (для этого, по нашему опыту, ему не нужен стимул), а вникать в смежные области. Например, программист вместе с менеджером проекта изучает дизайн-макеты до показа их клиенту, ищет в них нестыковки и проблемные места. В итоге проекты намного легче программируются и сдаются заказчику.
Соотношение оклада и премии при этом на уровне 80/20%.
Мотивируем укладываться в свою оценку трудозатрат
Если невозможно сдавать проекты быстрее за счет материальной мотивации разработчиков, то, может быть, стоит мотивировать программистов укладываться в собственные оценки сроков по задачам?
О чем речь: на основе оценок трудоемкости задач планируется работа программистов –расставляются задачи на краткосрочную (неделя) и долгосрочную (1–2 месяца) перспективу. Соответственно, если программист не уложится в указанный срок, то посыпется весь план-график работ, сдвинутся дедлайны по зависимым от него проектам И так далее.
Как помочь программисту укладываться в запланированные сроки?
Можно премировать, если уложился в оценку. Можно депремировать, если не уложился.
Однако и первое и второе решение предполагают, что дело тут исключительно в мотивации, а не во внешних причинах. Мы же уже выяснили, что программисты, если им не мешать, работают настолько хорошо, насколько это вообще возможно.
Мы начали проводить ретроспективы, чтобы выяснять, почему конкретная задача заняла больше времени, чем планировалось, с целью найти «узкие места» либо в самой задаче, либо в контексте ее исполнения, либо в знаниях программиста.
Это помогло, задачи стали чаще делаться за отведенный срок. Стало очевидно, что нужно узнавать о затянувшихся задачах раньше, чем они выпадут из дедлайна.
Для этого мы придумали «предварительные ретроспективы». Когда прошло более половины отведенного на задачу времени, а задача еще не близка к половине, то программист сообщает об этом менеджеру, и они вместе ищут причины.
Итак, из-за чего можно не уложиться в срок по задаче
Задача изначально была неверно оценена
Либо неверно оценили сложность, либо выбранное при оценке решение, в итоге не подошло. Это значит, что у программиста есть пробел в знаниях в конкретной области. Важно! Эта информация используется для обучения, а не для наказания программиста.
Задача обросла деталями по ходу
Если детали пришли от заказчика и на старте они не были очевидны, то программист корректирует оценку, а менеджер продает недостающие часы работы и сдвигает дедлайн.
Если детали были очевидны, но менеджер их упустил
То это уже говорит о пробелах в знаниях менеджера. Мы понимаем, что должен изучить менеджер, чтобы аналогичные проблемы более не возникали.
А все же нужна ли здесь финансовая мотивация
Нужна. Мы считаем премию по количеству часов, проданных заказчику и отработанных программистом. Цель остается той же: будучи мотивирован дать точную оценку, программист глубже вникает в задачу, иногда направляя ее на уточнение, иногда предлагая свои версии.
Обучение программистов и мотивация к развитию
На этапе ретроспектив мы находим пробелы в знаниях программистов.Но как заставить их учиться и закрывать эти пробелы?
Мы находимся в Краснодаре, и тут в общем одна ecommerce-студия (собственно, мы). Это значит, что готовых кадров взять особо неоткуда. И всех нужно либо выращивать с нуля, либо «доращивать» с того уровня, который у них был в других студиях.
Что должен знать программист
- Фронтенд
- Бэкенд
- Движок
- Интеграции (1С и так далее)
- Linux, Nginx, Apache
Таким образом, у нас есть 5 направлений компетенций. В каждом из них есть определенный набор навыков, из которых формируется карта компетенций программиста. Она определяет деление разработчиков на уровни (Стажер, Джуниор, Мидл, Сеньор).
С повышением уровня растет оклад.
Как мы растили разработчиков
Гипотеза 1
Первой идеей было выдать разработчикам карту компетенций и методические материалы и предложить самим развиваться по ней.
В Битрикс24 мы завели автоматические задачи, в которых каждый должен был отчитываться о прогрессе в обучении.
И тут я столкнулся с первой проблемой. Программисты почему-то не хотели учиться и не хотели расти по карте компетенций.
После пары месяцев тщетных попыток, я догадался спросить их: а что не так?
Оказалось, что слишком большая разница в компетенциях между разными уровнями. И она не мотивирует обучаться.
Гипотеза 2
Тогда я решил разбить уровни на несколько ступеней (в процентах от изученной карты компетенций). И за каждый уровень давать небольшую прибавку к окладу.
Стало несколько лучше. Программисты потянулись учиться и сдавать экзамены. Но все же слишком медленно.
Выяснилась следующая проблема: изучать материалы дома нет ни сил ни времени, а на работе программисты загружены задачами. Так что те, у кого есть полдня свободных на самообразование, продвигались по карте компетенций, а те, у кого нет — так и оставались на прежнем уровне, что здорово их демотивировало.
Гипотеза 3
Выдать свободное время. Между задачами программистам стали оставлять несколько часов в неделю на обучение.
И вот это — сработало. Программисты стали заниматься саморазвитием, сдавать тесты и расти в зарплатах.
Тех, кто не готов учиться при условии выделенного времени и перспектив роста, стоит просто оставить в покое. Есть люди, которым комфортно на их уровне и если они при этом могут закрывать какие-то задачи, то почему нет?
Выводы
По нашему опыту, программистам достаточно внутренней мотивации, и, если им не мешать, они работают настолько хорошо, насколько это возможно.
Премии служат дополнительным мотиватором не столько на качество работы, сколько на погружение в работу смежных специалистов (поиск проблемных мест в дизайне и ТЗ до того, как оно финально будет согласовано).
Все инструменты обучения бессмысленны, если нет двух важных вещей. Ощущения прогресса (в том числе достижимого вознаграждения) и выделенного для этого времени. Поверьте, когда программист, едва успев закрыть таски за день, час добирается до дома от работы, ему после этого уже абсолютно не до вашего «плана развития». И рассуждения я о том, что «ты сейчас выучишься и у тебя появится свободное время» будут рождать лишь одну молчаливую реакцию: «не верю».
Комментарии (36)
kreicer
21.08.2019 09:54Прочитав эту статью, я бы сказал, что работников нужно скорее перестать демотивировать подобными системами, чем пытаться строить их вовлеченность на деньгах. Для мотивации можно вполне выбрать другие материальные плюшки, нежели их изначальную зарплату.
iarga Автор
21.08.2019 09:54Примерно к этому же пришел и я, только ценой проб и ошибок. Надеюсь, кому-то поможет не повторять мой путь.
White_Scorpion
21.08.2019 11:53Где то тут на хабре прочитал: "Как не получить демотивированных сотрудников? Легко! Наберите мотивированных и не демотивируйте их".
lexnekr
21.08.2019 12:05Не понятно откуда взялась карта компетенций, насколько она корректна.
Не понятно как считается, что человек овладел компетенцией (ваш внутренний экзамен, какой-то внешний, просто факт прохождения «курса»?)
Не понятно как предполагается учиться, для каждой компетенции есть полный необходимый набор курсов? Откуда они взяты и насколько достоверно, что их (и только их) достаточно для овладения компетенцией? Курсы платные или бесплатные? Если второе, то платит кто?
А в целом да, если бы мою ЗП привязали к такому цирку (значительную часть ЗП), я просто уволился бы скорее всего. При этом я сам очень люблю проходить онлайн курсы в свободное время.iarga Автор
21.08.2019 12:16Карту компетенций составили, опираясь на решения более крупных студий.
«Овладение» проверяется либо выполнением соответствующего задания (тестового, или в реальном проекте), либо внутренним экзаменом.
Есть курсы, есть подборка методических материалов.
К счастью, никто не уволился, но эксперимент был недолгим, а отношения в коллективе хорошими.lexnekr
21.08.2019 12:27К сожалению, вы не ответили ни на один вопрос конкретно.
Это подводит к мысли, что в плане обучения у вас творился настоящий произвол. Я бы в такой ситуации скорее всего отказался бы участвовать в театре абсурда.
Arashi5
21.08.2019 12:51Мне кажется, что упущена весомая деталь. Есть ли в компании отдел продаж.
Если есть, то:
— Научите их качественным продажам и уметь продавать не только по кейсам(парусам)(Если менеджер работает только с малобюджетными проектами и прайсом, такой менеджер не нужен);
— Научите работать с заказчиком и заставьте уметь любить клиента( Скилл грамотно восхититься и грамотно наорать на клиента);
— Переведите их на процент;
— И… существует огромное количество литературы/вебинаров и прочего, где можно научиться продавать как можно дороже;
— Перевести прогеров на оклад с пересмотром раз в квартал( где зп рассматривается с отчетов ПМ и/или тимлида);
Если нет, то:
— Создать и взрастить отдел продаж;
— Оставить прогеров в покое, им необходимо работать;
Студия — это не вуз, и не школа. Здесь не стоит учебу ставить в априори, здесь надо зарабатывать.
И ставить такие задачи и брать такие проекты, на основе которых прогеры качали бы свои скилы.
iarga Автор
21.08.2019 12:53У нас не сверх дорогие проекты — в пределах миллиона. Все что выше, продается при помощи отраслевой экспертизы и кейсов.
Перевести менеджеров на процент — будет та же история что выше, только в профиль. Зачем менеджеру идти ко мне «на процент», если сосед платит 100к плюс процент?Arashi5
21.08.2019 13:11То есть ваша бизнес-модель выглядит так, что необходимо делать хороший, качественный, конкурентно-способный продукт, который будет продаваться за копейки?(либо вообще не продаваться, так как продавать не умеют/не хотят).
iarga Автор
21.08.2019 13:26Ну если для вас миллион — копейки, то помашите мне ручкой из личного вертолета)))
Arashi5
21.08.2019 13:38Просто немного личного опыта. Когда мы начали фильтровать заказы по цене и начали выбивать более дорогие(при условии, что затраты по времени на проект, условно, за 200к и за 800к при реализации каждого за 45 дней).
И на тот и на другой проект необходимо 2 бек, 1 фронт, 1 дизайнер и ПМ.
И менеджер по продажам получает(5% т.е. не 10к, а 40к и чувствует норм такую разницу и начинает топить(таки по звериному рвать) в сторону более дорогих проектов/задач).
Xander_Vi
21.08.2019 16:59Что должен знать программист: Фронтенд, Бэкенд, Движок, Интеграции (1С и так далее), Linux, Nginx, Apache
А это все должен знать 1 человек? Если да, то вы прям какого-то единорога хотите, над которым еще и эксперименты ставите.
У нас в компании бэкенд разработчики занимаются только бэком, а фронтэндщики — только фронтом. И так далее по списку. То есть, каждый специалист в первую очередь развивается вглубь свой сферы и только если ему интересно — может захватить смежные.iarga Автор
21.08.2019 17:32Есть немного базовых вещей от фронта, которые надо знать. Аналогично сервера — на базовом уровне.
В целом фронт делают отдельные специалисты конечно и сервера админит админ
Gradiens
22.08.2019 16:12Даааа…
Описанные эксперименты являются отличным примером демотивации. Хоть в учебник вставляй.
Управленческие решения вызывают такую оторопь, что в голове постоянно звенит ваш же вопрос:
До сих пор поражаюсь, как они все тогда не разбежались.
Хотя ответ вы по сути дали сами
Мы находимся в Краснодаре, и тут в общем одна ecommerce-студия (собственно, мы).
Это просто замечательно, что вы пришли к таким выводам:
Результатом эксперимента стало понимание того, что программисты достаточно сильно мотивированы делать задачу быстро и хорошо, если им при этом не мешать.
Жаль только, что по результатам выводов вы продолжаете разрушительные эксперименты.
Обучение — это замечательно. Играть с выделением времени для обучения, выдавать медальки, грамоты и даже премии — это нормально, тут даже в случае провала много вреда не нанесете.
Но экспериментировать с наказаниями, особенно в виде депремирования надо очень осторожно. Семь раз отмерить, затем поискать альтернативные решения, еще раз семь раз отмерить, и, может быть, в исключительных случаях применить. Депремирование сотрудника может сказаться на работе команды хуже увольнения этого самого сотрудника.
Я понимаю, что вы первопроходец, надо захватывать рынок. Понимаю, что кадрам от вас бежать почти некуда.
Но прошу вас, воздержитесь от наказаний!
Во-первых, это не работает. Вы, кажется, и сами это выяснили
Во-вторых, это для кармы вредно (как вашей, так и кармы компании),
Ну и наконец, вы убьете мотивацию людей и в долгосрочной перспективе имеете шанс угробить свою компанию.
Обиженный сотрудник будет продолжать на вас работать, если деваться некуда. Но вы получите разлагающийся изнутри коллектив. Оно вам надо?
З.Ы. Прошу прощения если оскорбил свое критикой, такого намерения не было. Я понимаю, что я всего лишь случайный читатель, который лезет в чужой монастырь. Просто было желание раскрыть другую точку зрения, которая, возможно, поможет сделать этот мир немножко лучше.
iarga Автор
22.08.2019 16:17Мы находимся в Краснодаре, и тут в общем одна ecommerce-студия (собственно, мы).
Тут 300 студий с меньшим опытом в екоммерс, которые с удовольствием отправляют офферы нашим программистам. Думаю, дело в коллективе и малой продолжительности эксперимента.
Но прошу вас, воздержитесь от наказаний!
Во-первых, это не работает. Вы, кажется, и сами это выяснили
Во-вторых, это для кармы вредно (как вашей, так и кармы компании)
Это мы уже переросли. В работу такие методы не пошли.
З.Ы. Прошу прощения если оскорбил свое критикой, такого намерения не было. Я понимаю, что я всего лишь случайный читатель, который лезет в чужой монастырь.
Спасибо вам в любом случае. Такой взгляд со стороны, прочитанный чуть раньше, избавил бы меня от кучи проблем.
Eggception
22.08.2019 16:48Интересно! Я работаю в американской консалтинговой компании, мы делаем на заказ не только сайты, но и платформы, искусственный интеллект и пр. Мне было интересно сравнивать, как мотивируете вы и как мовируют у нас, и заметила вот что:
1) Ни слова не написано про тестирование качества. Сдавать быстрее — это, конечно, здорово, но то, что кнопки работают в интернет-магазине — это не значит, что там багов нет и пользоваться удобно. Почему-то в статье упоминается только менеджер, который продает и работает с заказчиком, и программист. А тестировщики у вас вообще есть? А команда UX? Или программисты сами решают, как дизайнить страницы?
2) У нас обучение идёт через оплату программистам, архитекторам и тестировщикам лучших курсов по технологиях: LinkredIn Learning, Pluralsight etc. У нас от желающих учиться отбоя нет. Вы за это платите?
3) Когда кто-то поработал на интересном проекте, например, с нестандартной интеграцией, мы устраиваем Lunch & Learn, где человек делится своим опытом, показывает, как он сделал что-то. Поскольку дело идёт во время ланча, компания заказывает еду из ресторана (никакой дешёвой пиццы). Те, кто работают удалённо, могут подключаться через веб, и мы записываем видео на будущее.
4) В офисе бесплатно вода, кофе, печеньки, чтобы люди могли работать продуктивно, да ещё и денег сэкономить, если приходится работать долго.
Это все очень мотивирует и выгодно отличает от тех компаний где все ориентировано только на "кодь быстрее и сдавай"iarga Автор
22.08.2019 16:51Спасибо за вопросы :-)
Ни слова не написано про тестирование качества.
Мотивировать на число багов — спорное решение. Быстро договорятся с тестером.
пользоваться удобно
К программисту проект приходит после проектирования, аналитики и дизайна. Это уже не к нему вопрос.
У нас обучение идёт через оплату программистам, архитекторам и тестировщикам лучших курсов по технологиях: LinkredIn Learning, Pluralsight etc. У нас от желающих учиться отбоя нет. Вы за это платите?
Да, но если не выделять время, то и на оплаченных курсах не будут учиться (в нерабочее время один фиг, не захотят)
Когда кто-то поработал на интересном проекте, например, с нестандартной интеграцией, мы устраиваем Lunch & Learn, где человек делится своим опытом, показывает, как он сделал что-то. Поскольку дело идёт во время ланча, компания заказывает еду из ресторана (никакой дешёвой пиццы).
Проводим, но без еды
В офисе бесплатно вода, кофе, печеньки, чтобы люди могли работать продуктивно, да ещё и денег сэкономить, если приходится работать долго.
Это почти у всех есть :-)Eggception
22.08.2019 18:39Спасибо за ответ!
Я не предлагаю мотивировать на число багов, я говорю лишь о том, что гонка за быстрой сдачей часто рождает падение качества, если не установлены стандарты проверки качества. Я, как программист или как принимающий работу клиент, могу убедиться, что "снаружи" все работает и кликается классно, но "внутри" все может начать тормозить уже на 100К записей в базе, и это невозможно понять без нагрузочного тестирования, на которое у программистов времени нет.iarga Автор
22.08.2019 19:28Сдача это когда проверили сперва тестеры, потом еще менеджер (а иногда и тимлид), а потом запущено вместе с клиентом.
mathematician90
Капитан Очевидность просто
iarga Автор
«Капитаном» бывает инструкция. А это не инструкция, это история внедрения в отдельно взятой компании. Судя по вопросам/опросам в группах вебстудий, история местами очень даже актуальна :-)
mathematician90
Да я к тому, что не надо быть семи пядей во лбу, чтоб такие очевидные вещи понимать. Если вы не понимаете, что не надо дергать человека и тогда он нормально все делать будет (не только программиста, вообще, даже сантехника), тогда можно разворачиваться и уходить. Если вы изначально не понимаете, что человек в свободное от работы время не будет ваши курсы изучать — можно разворачиваться и уходить. Если не понимать, что у загруженного человека нет времени, поскольку таски все съедают — можно разворачиваться и уходить. Это те вещи, которые вполне себе очевидны без таких стремных экспериментов над людьми (потому что если неочевидны, то тех, кто эти эксперименты проводит, к работе с людьми на пушечный выстрел нельзя подпускать). Вопрос в другом: почему от вас люди не разбежались? Но это уже другой вопрос, видимо, были какие-то причины. Причем выводы вы в конце делаете абсолютно верные
iarga Автор
В отношении курсов я судил по себе — сам я вполне себе прохожу/проходил их в нерабочее время, чтобы в рабочее больше зарабатывать. Сложно было принять, что не для всех это так.
Xander_Vi
Думаю, дело в этом:
Так что люди, которые не хотят/не могут уехать в другой город, вынуждены терпеть.
iarga Автор
Ну у нас есть еще 300 студий, из которых 10 больше 10 человек и регулярно присылают моим программистам офферы. Думаю, дело в коллективе и малой продолжительности эксперимента.
mathematician90
Согласен. Еще и на сайте написали, что они номер 1 в разработке интернет-магазинов на Битрикс. Люди, вы серьезно? Требуем четкие измеримые метрики, по которым делалась оценка и дан такой вывод. В противном случае — это все очередная ЛПП
iarga Автор
спасибо что зашли на сайт))
По ссылке, обозначенной подчеркиванием, в этой фразе, есть диплом рейтинга рунета. Также информация продублирована в блоке «о компании»
DFooz
КЭП про это не знает. Новые конторы, стартапы, молодые начальники никогда сразу норм не работали в плане мотивации. По моему опыту
mathematician90
Мотивация нужна там, где нет нормальных бизнес-процессов между работником и работодателем, а есть всякая чушь типа описанного выше. Просто потому, что в такие условия нормальные люди не пойдут, и набирать приходится по остаточному принципу. По моему опыту в нормально отлаженных процессах все знают, что делать и как, потому вопрос мотивации неактуален
DFooz
нормальный бизнес-процесс и подразумевает учитывать мотивацию. И не все сразу доходят до нужной мотивации ввиду разного мировозрения и опыта