В качестве предисловия
Началось все в феврале 2014 года с приглашения посетить конференцию AgileDays2014. Вечером того же дня я засел на сайте конференции, чтобы выделить интересные мне темы и спланировать посещение докладов. Через 5-10 минут я уже смотрел запись выступления с AgileDays 2013 “Свобода и ответственность” Антона Волкова из Alternativa Platform.
Основная проблематика, освещенная в докладе, заключается в том, что многие сотрудники просто проводят время на работе, мало у кого есть чувство ответственности. Тем более нет командной ответственности, зато есть отговорки, много отговорок. Тут появляются проблемы с эффективностью, качеством, требуется постоянный контроль над сотрудниками. Всех все устраивает, нет желания меняться.
Для того, чтобы взрастить чувство ответственности нужно:
- Добровольное принятие ответственности. Например, когда человек сам называет срок выполнения задачи, он принимает ответственность. А если срок спускают сверху ни о каком принятии ответственности речи не идет, она на том, кто спустил срок;
- Свобода выбора — люди в праве решать какую работу брать, выбирать стратегию решения задачи, с кем работать (определяют состав команд);
- Последствия (положительные и отрицательные) от принятых решений, действий и бездействий. Например, сдал качественно выполненный функционал в срок, получил признание коллег и, возможно, дополнительное денежное вознаграждение. Или, допустил баг в продуктовой среде, получи нагоняй и порицание от коллег.
Итогом стала интересная методология, в которой у каждого сотрудника (включая директоров) есть индивидуальный общедоступный рейтинг/карма, который накапливается при своевременном и качественном выполнении соглашений (об этом далее) и “сливается” при возникновении рисков прописанных в соглашениях.
Соглашение — это договор между исполнителем и заказчиком. Состоит из критериев завершения и рисков. Имеет стоимость в очках кармы, а так же, стоимость каждого отдельного риска.
Есть единый список соглашений в порядке приоритета. Когда команда берет что-то в работу, она сама определяет свой состав (реализуется свобода выбора с кем работать) и срок реализации. Состав команд динамически меняется от соглашения к соглашению в зависимости от необходимых компетенций для достижения цели соглашения.
Таким образом у сотрудников практически полная свобода — выбор способа решения поставленных задач, выбор с кем работать (состав команд), какие задачи брать и т.п.
До кармы
На тот момент в компании, где я работаю, шло активное внедрение гибких методологий. Забавно, что практически все, о чем говорил Антон в первой части своего выступления, повторялось у нас с легкими отличиями. Даже команда ScrumTrek у нас побывала (Асхат, привет!!! Ты по нам скучаешь?). Скажу только, что мои попытки “продать” понравившиеся идеи, успехом не увенчались.
Прошло пол года, магия Agile на нас не снизошла. Качество не выросло, скорость осталась практически такой же, по прежнему требовался постоянный контроль. Зато пошли разговоры о введении KPI в ИТ. Вот тут то до меня дошло, что карма — это единственный вменяемый KPI, который реально можно применять в ИТ. Эта мысль была озвучена руководству, но я не был услышан. В конечном итоге глобальную тему с KPI в ИТ замяли, но тему с кармой я решил продолжать хотя бы в сфере своего влияния. Если кому-то интересен масштаб, то это 17 человек задействованных в процессе разработки — разработчики, менеджеры проектов и аналитики.
Внедрение кармы
Была проведена презентация методологии для всей группы разработки. Сразу скажу, что примерно половина группы вначале отнеслись к этой идее скептически. Часть из них спустя некоторое время все-таки осознала, в чем прелесть и присоединились к сторонникам. Остальные втянулись уже на этапе внедрения (а куда им деваться с подводной лодки?). Те, кто принял идею сразу, сформировали инициативную группуи работа закипела. Везде, где далее будет фигурировать слово МЫ, его надо понимать как инициативную группу по внедрению KDD.
Когда мы стали погружаться в детали методологии, сразу стали появляться вопросы:
- Как определять стоимость соглашения так, чтобы ни у кого не возникало вопросов и не тратилось на это слишком много времени?
- Как адаптировать наш рабочий процесс под методологию?
- По каким принципам определять приоритеты задач среди нескольких проектов?
Предлагаю вашему вниманию итоговый вариант адаптированной методологии.
Карма
Индивидуальный рейтинг/репутация каждого человека.
Накопление происходит путем качественного выполнения соглашений (см.ниже).
Понижение происходит при возникновении рисков, прописанных в соглашениях, а так же при низкой загрузке в течении месяца.
Для упрощения расчетов мы приравняли 1 карму к стоимости 1 человеко-дня. Таким образом у каждого сотрудника появляется план равный количеству рабочих дней минус отпуск и больничный. Низкой загрузкой при этом можно считать менее 80% от плана.
Карма имеет 2 показателя:
- Показатель месяца — в случае превышения над планом, может быть использован для расчета повышающего коэффициента премиальной части ЗП;
- Накопительный показатель — показывает насколько в целом человек полезен для компании. Здесь ежемесячно накапливается дельта между планом и фактом. При этом мы следим за тем, чтобы никто не перерабатывал. Отдохнувший разработчик значительно эффективней уставшего.
Соглашение
Договор о решении задачи между заказчиком и исполнителем. Состоит из критериев завершения и рисков. Имеет стоимость в очках кармы, а так же, стоимость каждого отдельного риска.
В качестве заказчиков могут выступать любые сотрудники с соответствующей компетенцией.
Исполнителем может быть как отдельный сотрудник, так и команда. В случае, если соглашением занимается команда, то стоимость соглашения распределяется на всех членов команды пропорционально участию (%) в решении задачи.
Команды не фиксированные. Люди самостоятельно определяют с кем кооперироваться для выполнения того или иного соглашения.
Исполнитель сам оценивает и договаривается о стоимости и сроках реализации с заказчиком.
Мы очень долго бились над вопросом “Как же в AlternativaPlatform рождается цена соглашения?”. Как ни крути вменяемая цена может появится, только если провести анализ задачи и прикинуть способы реализации, а это требует огромное количество времени. К такой нагрузке я лично не был готов, эта проблема сводила все плюсы методологии на нет. Через какое-то время снизошло озарение… А что если применить коммерческий подход. Исполнитель сам озвучивает стоимость работ и сроки завершения. Мне же будет достаточно очень высокоуровнево оценить соглашение, и если мне покажется, что названа слишком большая цена или срок, я просто попрошу “смету”. На этом и остановились.
В качестве основы используется Kanban со следующими статусами и статусными переходами:
Перед тем, как переместить задачу в очередь на анализ или реализацию, практически каждый запрос от бизнеса тестируется универсальным вопросом “То, что вы просите нужно для того, чтобы что?”. Все дело в том, что бизнес как правило приходит в ИТ с готовым решением и практически никогда не обозначает цель. Для того, чтобы полностью удовлетворить потребности бизнеса нам нужна именно цель. Этот шаг мы называем экспресс-анализ — результатом шага выступает сформулированная цель и решение «берем в работу или отклоняем».
Приходит заказчик и просит прострелить ему ногу.
Можно конечно это сделать сразу, вроде как мы даже молодцы и сделали ровно то, о чем нас попросили. Только потом заказчик опять придет, правда с проблемой “Простреленная нога болит, сделайте что-нибудь”. Будем мазями мазать и лейкопластырь лепить.
А можно задать вопрос “То, что вы просите нужно для того, чтобы что?” и тут выясняется, что у человека нога просто чешется.
Мы: “Давайте мы ногу просто почешем”
Заказчик: “А что, так тоже можно?”
(Не знаю, кто автор этого сюжета, я его услышал от Асхата из ScrumTrek. Здесь краткий пересказ в моей интерпретации)
Как видно по схеме у нас для задачи может быть до 2-х соглашений, отдельно на анализ и отдельно на реализацию. Сделано в целях декомпозиции, повышает точность оценки.
Кроме того, выделенный этап анализа нужен, чтобы появилось однозначное понимание проблемы. Для этого:
- формируются критерии завершения — позитивные сценарии использования утвержденные заказчиком;
- оцениваются риски — негативные сценарии.
Прямой переход в очередь реализации, минуя анализ, возможен для мелких задач, где нужно просто брать и делать, анализировать собственно нечего.
Чтобы взять задачу на реализацию из очереди сотрудники сами проводят техническую оценку, определяют за сколько времени и каким составом может быть выполнена задача, а так же озвучивают желаемую цену в карме. Результатом служит подписанное соглашение о выполнении работ.
Очень интересно у нас получилось с контролем качества. Изначально этот этап планировался таким же как в AlternativaPlatform, т.е. все задачи нужно протаскивать через необходимые центры качества в зависимости от задачи (качество проектирования структуры БД, качество кода, UI/UX и т.п.). Если через центр качества задача не проходит, то команда получает минус в карму. Типа нечего некачественно делать работу. Так вот на эту тему были жаркие дискуссии, практически невозможно сформулировать стандарты качества разработки так, чтобы они всех устраивали, есть много вкусовщины, особенно в вопросах качества кода. Плюс есть моменты, когда код, хотя в нем и есть что поправить, вроде бы не так плох, чтобы за него штрафовать.
В итоге обязательные центры качества были переиначены в центры компетенций (далее ЦК), куда любой сотрудник может обратиться с задачей на обзор. Таким образом обращение в ЦК стало опциональным. Кроме того, для стимулирования обращений в ЦК мы предложили следующее:
- За простое желание получить обратную связь по проделанной работе исполнитель (человек или команда) получает дополнительные 10% от стоимости задачи. Просто отдал задачу на ревью — уже получаешь бонус. Сразу отсеялись скептики, бубнящие про то, что все это не нужно. Напротив, они были первыми, кто стал сдавать задачи на обзор в ЦК;
- Если ЦК нечего было порекомендовать (работа выполнена на отлично) либо если были внесены изменения в соответствии с рекомендациями, то исполнитель получает еще 10% от стоимости задачи.
Что хорошего получили от внедрения?
На момент публикации статьи, мы работаем по KDD около месяца. Пока мы работаем только в плюс и накапливаем статистику, т.е. минусы за риски еще не запускали.
- Возможно это самообман, но мне кажется, что работа стала выполняться быстрее и качественнее просто за счет наличия оцифрованного показателя эффективности и обзоров ЦК;
- Деятельность абсолютно прозрачная — теперь я намного лучше ориентируюсь в том, что делают подчиненные, при этом не приходится спускаться до микро-менеджмента;
- Психологический климат стал лучше за счет самостоятельного выбора кому с кем работать;
- Эффект кадровой санитарии — выявляются ненужные люди, с которыми никто не хочет работать;
- Не нужно никого пинать, люди сами приходят и просят дать соглашение;
- Стендапы стали реально быстрыми и эффективными. Раньше в команде из 7 человек стендап мог проходить минут 30-40, сейчас 17 человек укладываются в 15 минут!
Хочу заметить, что промежуточные итоги достаточно сильно совпадают с тем, что озвучивалось в докладе Антона Волкова. Для меня это показатель того, что методология реально работает.
Автор: wizi4d
