- PVSM.RU - https://www.pvsm.ru -
Началось все в феврале 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 и т.п.). Если через центр качества задача не проходит, то команда получает минус в карму. Типа нечего некачественно делать работу. Так вот на эту тему были жаркие дискуссии, практически невозможно сформулировать стандарты качества разработки так, чтобы они всех устраивали, есть много вкусовщины, особенно в вопросах качества кода. Плюс есть моменты, когда код, хотя в нем и есть что поправить, вроде бы не так плох, чтобы за него штрафовать.
В итоге обязательные центры качества были переиначены в центры компетенций (далее ЦК), куда любой сотрудник может обратиться с задачей на обзор. Таким образом обращение в ЦК стало опциональным. Кроме того, для стимулирования обращений в ЦК мы предложили следующее:
На момент публикации статьи, мы работаем по KDD около месяца. Пока мы работаем только в плюс и накапливаем статистику, т.е. минусы за риски еще не запускали.
Хочу заметить, что промежуточные итоги достаточно сильно совпадают с тем, что озвучивалось в докладе Антона Волкова. Для меня это показатель того, что методология реально работает.
Автор: wizi4d
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/83965
Ссылки в тексте:
[1] Источник: http://megamozg.ru/post/10834/
Нажмите здесь для печати.