Одна из целей была избавиться от того, что на картинке:
Наша история начиналась как у всех:
Сначала устные поручения сотрудникам: сделай то, сделай это, почему забыл? Ну ясное дело, что так не пойдет.
Таск-менеджер
Потом появился таск-менеджер. Сначала 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 недели, но об этом в следующей статье.
Комментарии (15)
edwardspec
08.06.2015 03:06+5Привет,
я ранее работал в отделе Tier 3 Support (поддержка третьей линии, куда прилетают самые сложные баги). Внесу свои пять копеек.
История про процент багов выглядит очень неправдоподобно. Этот критерий надо убирать как можно скорее.
Очень подозреваю, что разработчики договорились с тестировщиками и что-то заметается под ковёр, чтобы процент был хорошим. И это потом аукнется через год-другой как огромный технический долг.
Процент багов разработчик может уменьшить, «если сильно захочет», только если высокий процент ранее объяснялся регулярным пренебрежением тестированием и т.п. Все остальные баги уменьшить мотивацией невозможно.
Ещё проблема — допустим, баг нашёл не тестировщик, а разработчик (реализовывал какую-то фичу и заметил ошибку в коде) — думаете, он сообщит о таком баге, зная, что за это влетит его коллеге за соседним столом?
В качестве альтернативы могу предложить иметь подотдел именно что Tier 3 Support — программистов, ответственных за устранение технического долга (не только багов), которые будут только чинить баги. Это решит проблему «если баг — это задача, то [...]».
maxwp Автор
08.06.2015 12:20Спасибо за комментарий.
По-моему, процент багов достаточно хороший показатель качества.
Если разработчик нашел свой баг, и устранил его сам, то это не засчитывается ему в «баг», это идет как «improve».
Разработчику выгодно править даже не свои баги, потому что баг ему не засчитывается, а фикс бага засчитывается. Поэтому да, он не сообщит, чтобы не влетело коллеге, а исправит сам. Всем хорошо, и нам особенно :)
Тестировщику тоже не выгодно преподносить баги как improve, потому что от этого страдают его KPI.
И у нас сейчас есть TIER 2 Support, я просто об этом не написал.
edwardspec
08.06.2015 03:19+2Ещё проблема с багами — какие-то баги есть всегда, а в вашей схеме если баги нашлись, то это плохо.
А плохо-то наоборот когда они не нашлись.maxwp Автор
08.06.2015 12:21Самый хороший показатель — это когда баги не появляются, когда их почти нет.
Когда экосистема в команде разработчиков построена так, что даже тестировщики не нужны. Сами все находят, сами все правят, без пинков :)
argent00m
08.06.2015 13:19Пожалуй, одна из лучших публикаций о распределении ролей в процессе организации бизнеса.
Разработчик (рабочий) не должен ставить себя во главе угла, так как страдают все: заказчики (ждущие ненормированное количество времени своего заказа), менеджеры (которые не знают, когда будет готовый результат, а могут примерно угадывать) и вся бизнес-система в целом (уменьшение лояльности клиентов и менеджеров).
Но тут главное не переборщить и не бороться за каждую сэкономленную секунду.
0leGG
08.06.2015 16:17Проблема в том, что с введением формальных критериев качества люди устремляются достигать не результата, а выполнения именно этих формальных критериев. Хорошо об этом написано вот тут
maxwp Автор
08.06.2015 16:42Согласен, поэтому одного KPI не достаточно, даже двух недостаточно.
Чем больше критериев, тем тяжелее обмануть систему.0leGG
08.06.2015 17:43И тут мы резко начинаем не видеть леса за деревьями. При такой постановке люди начинают работать по принципу «как бы чего не вышло» вместо того, чтобы делать крутые вещи и получать от этого удовольствие.
excoder
09.06.2015 02:14+1Тут скорее речь не о разработчиках, а о кодерах, машинах исполнения задач. Автор в статье, на самом деле, это и признаёт. В результате вероятность вот такого – высокая: «Как программист я понимаю, что надо было сделать ещё это и это, но поставлено этого мне не было, потому и не сделано. Ты менеджер, ты и решай». Даже у водителя мусоровоза пространство решений оказывается не в пример богаче.
kravtsov_dim
09.06.2015 09:03Maxwp расскажите, как у вас организован R&D, чем он отличается от производства, как устанавливаете сроки и как их выдерживаете?
maxwp Автор
09.06.2015 11:00Это тянет на отдельную статью, постараюсь ответить в ближайшее время.
Основная идея:
1. те кто способны придумывать задачи, не способны качественно и стабильно их выполнять. Поэтому, это разные люди.
2. если поставить задачу «придумать 100 фишек за день», то это сначала кажется не реальным, но когда ситуация безвыходная, мозг придумывает решение и выдает 100 фишек. Потом при помощи SWOT отбираем нужные, расписываем в production «что и как надо сделать».fcoder
09.06.2015 17:47+1Регулярно слышу от других людей про разделение на тех кто придумывает и на тех кто пишет — за исключением очень редких случаев это просто не работает. По моему опыту продукт такого симбиоза получается не просто с багами а опасно нестабильным. Архитекторы которые сами не участвуют в написании кода проекта — жалкое зрелище. Впрочем как и кодеры, которые понятия не имеют как их код взаимодействуют со связанными компонентами.
Может конечно у Вас более позитивный опыт — очень хотелось бы почитать.
AlexTest
Для типовых проектов и следовательно типовых же задач описанная вами схема может и подойдет. Но если надо делать уникальные проекты, то ничего другого, кроме как найма супер-спецов с большим опытом разработки, достаточным для прогнозирования сроков/затрат на уникальную разработку пока еще никто не придумал. И да, это будет уже не серийное производство, а творчество. И кстати нигде в древних текстах не указано, что Творец Всего делал эстимейт на создание нашего мира. Просто поработал как следует достаточное количество времени над очередным проектом, посмотрел на то что у него получилось, и сказал Он что это хорошо!
maxwp Автор
Отчасти я с вами согласен. Просто мы используем другой подход:
Немножко другой пример:
«Сварить борщ» это не задача, это примерно 15 задач: нарезать картошку, нарезать лук, налить воды, поставить кастрюлю на огонь, и т.д.
И мы расписываем задачи настолько подробно, чтобы ошибиться было нельзя.
Чуть позже научили OneBox расписывать так задачи самостоятельно.