Мы хотим поделиться с сообществом информацией, как мы разбирались кто кем управляет (менеджер vs программист) и как мы изменили стратегию управления разработчиками.
Одна из целей была избавиться от того, что на картинке:
Наша история начиналась как у всех:
Сначала устные поручения сотрудникам: сделай то, сделай это, почему забыл? Ну ясное дело, что так не пойдет.
Таск-менеджер
Потом появился таск-менеджер. Сначала BugZilla, потом Mantis, потом попытка перейти на JIRA, потом Redmine (тут стоит признаться мы застряли на 6 лет), и потом перешли в наш OneBox. Но, это всего-лишь таск-менеджеры, они не задают стратегию очередности выбора задачи и показатели эффективности.
Что происходит, когда у вас есть таск-менеджер? Управленец (например, Project manager) назначает задачи, распределяет их между разработчиками. Но есть два НО:
- разработчик сам решает какую задачу сейчас делать. И, как правило, выбирает «самую интересную».
- управленец не знает, что сейчас делается, пока явно об этом не спросит.
- управленец и разработчик не знают когда будет сделано.
Возникает вопрос: кто-то вообще управляет процессом?
Почасовая оплата
Если к этому всему добавить еще почасовую оплату разработчиков за затраченное время, то получается настоящий ад:
- что мешает разработчику растянуть время? Реально на 30 минут задача, а он ее делает 60 минут?
- что мешает ускориться?
- потом менеджер не может продать, потому что выходит “дорого”
- в целом эта схема явно или не явно мотивирует разработчиков делать долго, просто отрабатывать часы, и результат не важен.
- и постоянно куча задач которые надо сделать “внезапно”.
Возникает второй вопрос: кто кем управляет? Управленец программистом или программист всеми?
Estimate-костыль
Такая схема у нас была 5 лет. И вместо того, чтобы признать кривость этой схемы, мы сначала придумали к ней костыль “а давайте спрашивать у разработчиков estimate time”. Эта классная идея привела к:
Менеджер дает задачу, просит ее оценить.
Разработчик говорит estimate и в большинстве случаев разработчик “попал”. Если он угадал estimate (чего как мы знаем никогда не бывает), то он молодец. Если он не успел — разработчик обозлиться, будет стараться сделать как можно быстрее (и не качественно), ведь estimate я называл 10 часов, а задачу делаю уже 12й час, а заплатят ведь за 10.
Поэтому, разработчики быстро просекают что надо завышать estimate в пару раз и делать как можно быстрее (качество страдает): я назвал 20, а сейчас сделаю за 10, а еще лучше за 5. Ух какой я молодец.
Первое управление производством
Суммарно нам понадобилось больше 6 лет чтобы признать, что так дальше дело не пойдет. Чтобы признать, что разработчики (а они по сути производство) управляет компанией, а не компания производством.
Оплата за часы, свобода выбора задачи разработчиками — это все неконтролируемые процессы, а все попытки их контролировать сводятся к придумыванию костылей на костылях.
И мы кардинально изменили схему:
- разработчик не выбирает, какую задачу ему делать. Порядок задач назначает руководитель отдела через нашу CRM-систему.
- все задачи ставятся таким образом, чтобы они не были больше чем на 2 часа. То есть, все дробиться на максимально мелкие задачи первого уровня, которые отвечают на один простой вопрос “что надо сделать”.
- KPI разработчиков — делать как можно больше задач в месяц. Заработная плата за начисляется за выполненные задачи.
Стало лучше, намного лучше. Мы уже не спрашивали “чем сейчас занимается разработчик Х”, потому что мы знали какая у него задача стоит в плане сейчас под приоритетом №1. Разработчиков не беспокоили дедлайны.
Позже мы научились прогнозировать, сколько в среднем конкретный разработчик делает задач в день, поэтому мы могли посчитать примерно когда какая задача будет выполнена. Научились строить планы на день, прямо в календаре. Простой механизм. Позже научили наш продукт CRM-систему автоматически распределять и группировать схожие задачи, чтобы не надо было прыгать «проект А, потом проект Б, потом снова А».
Вот так выглядит календарь разработчика на неделю. Разработчику нужно просто следовать плану.
Сначала это кажется странным — требовать от разработчика выполнения какого-то плана.
Но с другой стороны, если вы не работаете над задачами R&D, то ваши разработчики — это производство. Завод это тоже производство. Где вы видели, чтобы управляющий на заводе подходил к мастеру на станке и говорил «сколько заготовок ты сегодня сделаешь?». У производства есть план, надо делать столько-то в день.
У разработчиков тоже, только нужно правильно найти показатели и ставить правильные и реальные планы.
И еще, мы вообще убрали приоритеты задач. У всех задач один приоритет. Приоритет теперь это порядок выполнения задач.
А то раньше (Redmine) было примерно так:
Сегментация заработной платы
Но и у этой схемы через 6 месяцев полезли бока.
Пример: проект состоит из 120 задач, которые нужно сделать. Мы научились прогнозировать, когда будут готовы все 120 задач. У менеджеров есть дедлайн. Но разработчик вдруг делает 118 задач и не дожимает вовремя всего 2 задачи, и никак нельзя его заставить без “пнуть”. А “пнуть” это нарушение наших же правил, чтобы разработчики не думали про дедлайны.
В реальности разработчик не дожимает эти 2 задачи, потому что он понимает что и так сделал много, и думает “та ну еще две задачи на ЗП уже не сильно повлияют”.
Схему пофиксили так: сделали сегментацию заработной платы, причем не линейную.
За N выполненных задач — X USD.
За 1.5N задач — 2X USD
За 2N задач — 3X USD
и тд.
Эта схема мотивирует делать больше и больше.
Качество
И у нее полезли бока: разработчики делают как можно больше задач, и забыли про качество. Баг это тоже задача, значит если я сделаю баг, а потом его найдут и я пофикшу его — мне будет +1 задача.
Сразу была мысль “за баги не платить и баги не считать”, но это неверный путь:
- Когда мы говорим, что исправление бага засчитывается — то подсознание считает что “баги это хорошо”.
- Когда мы говорим, что исправление багов не засчитывается — то подсознание считает что “баги это норма”.
- Поэтому нам надо было сказать “баги это плохо и их нельзя делать”.
И мы ввели второй KPI — качество.
Качество, это соотношение количества выполненных задач за месяц к количеству найденных багов за этот месяц.
Например, разработчик сделал 100 задач, а тестировщики нашли 15 багов — значит процент баговости разработчика = 15%.
И показатель KPI у разработчиков — процент багов должен быть меньше 15%, иначе выше первой планки ЗП прыгнуть нельзя. Иными словами, всегда junior.
И вот в этот момент стало сначала плохо (потому что уволилось 3 разработчика), а потом просто отлично, потому что баги перестали появляться. Стоит только начать следить за каким-то показателем — и он тут же начинает меняться и подстраиваться.
Через 2 месяца мы перестали считать качество, потому что процент багов был меньше 10% у всех разработчиков. Подстроились все.
Что мы получили после этих внедрений?
- мы перестали пинать разработчиков «сделай это, потом сделай это»
- никто не может поменять приоритеты просто так, только у team lead есть доступ к календарям своих сотрудников
- мы научились прогнозировать время выполнения задач без вопросов «а за сколько ты это сделаешь»
- реально меняя порядок выполнения задач — мы управляем производством
- у нас вообще нет приоритетов как в большинстве таск-менеджеров
- ну и когда разработчики делают продукт, задачи по которому стоят в этом же продукте, это сносит крышу :)
Что дальше?
Мы догадываемся, что это не предел, что-то поломается и через некое время снова прийдется делать следующую схему.
Обязательно поделимся информацией.
Наша компания существует с 2006 года и мы начинали как все, как обычная веб студия. Когда все начиналось, мы еще ничего не знали об управлении персоналом, ничего не знали про найм и делегирование функциональных обязанностей и отвественности. Сейчас мы помешаны на эффективности работы сотрудников и автоматизации всех процессов. У нас 40 сотрудников, мы можем готовить +20 разработчиков за 4 недели, но об этом в следующей статье.
Автор: maxwp
