Якщо постояти де б то не було досить довго, за тобою вишикується черга.
«Закони Мерфі, та пов'язані з ними висновки»
Сегодня хотел бы поговорить о разработке и поддержке. Поделиться, как мне кажется, удачным примером борьбы с потоком важных и срочных задач, которые нужны на вчера… Точнее с созданием правил работы с рутинными задачами разработки.
Правил, которые позволят отвлекаться на рутину только в случае каких-то отклонений.
В свое время я был руководителем отдела разработки. Весьма сильного отдела, который занимался тем, что поддерживал (актуализировал к изменениям законодательства, адаптировал к изменениям процессов) ERP систему.
Система – типичный «монолит» (который мы, кстати, понемногу разобрали на независимые составляющие): в ней и казначейство, и планирование, и бухгалтерия, и у правление качеством, и склад, и продажи, и еще куча всего, в том числе специфического для фармкомпании. Т.е. процессы большинства подразделений «завязаны» на эту систему. И задачи, причем весьма активно, ставят все подразделения.
В каждом подразделении есть «Key user» - один (или несколько) пользователей, которые имеют максимальную компетенцию в бизнес-процессах своего подразделения и в системе. Они формулируют запросы на разработку, они отвечают за внедрение этих разработок в свои бизнес-процессы. Обычно это локальные задачи, касающиеся бизнес-процессов только этого одного подразделения. Если автоматизация касается нескольких подразделений – на задачу назначается аналитик из отдела разработки, который согласовывает новый общий бизнес-процесс со всеми заинтересованными лицами.
Трекинг задач осуществляется в «самописной» системе. Она поддерживает необходимый минимум: позволяет задать название задачи, срок к которому заказчик ожидает ее выполнения, важность, ряд служебных реквизитов и, самое главное, позволяет организовать обсуждение по задаче с сохранением всей переписки и информированием ее участников по почте о появлении нового комментария.
В целом, когда мне «сдавал дела» предыдущий руководитель отдела разработки, все казалось весьма неплохо организовано.
Ну, да система трекинга «самописная», но она поддерживает все, что нужно. Может не всегда удобно, в нее не вложены сотни человеко-часов разработки, над ней не работали дизайнеры, но работать вполне можно. Ну да, ERP весьма «переписанная», от коробочной версии мало что осталось (о том, какая это была система больше всего говорил логотип при старте), но она работала, поддерживала все процессы компании, а некоторые вещи в ней были организованы очень классно. И, как показало время, система позволила, под многократно увеличившейся нагрузкой, вполне нормально обеспечивать работу компании (да, после некоторой оптимизации).
Институт ключевых пользователей работает и это позволяет системе развиваться…
Но «дьявол кроется в деталях» и мне позже с этим пришлось разбираться.
В нашей системе трекинга задач, как и во многих других, кроме всего прочего, были 2 поля: «Ожидаемый срок», к которому заказчику нужна задача и ее «Важность» (низкая, средняя, высокая). Важные задачи сразу выделялись красным цветом шрифта, чтобы обратить на себя внимание, кроме этого, красным выделялись просроченные задачи - срок которых был нарушен.
И вот я начал замечать, что список задач начал «краснеть». И всем нужно срочно (хорошо если на завтра, а не на сегодня) и у всех задачи важные… Особенно отличилось одно подразделение – его постановщик вообще не имел иных задач, кроме важных и срочных.
Видимо возрос спрос на задачи разработки, и мы перестали успевать его удовлетворять. Новых разработчиков вот так сразу никто не утвердит. Аутсорс был не вариант по внутренним политикам компании. Список задач неуклонно «краснел» в нем становилось все больше важных и просроченных задач. Назревала конфликтная ситуация, которую нужно было решать.
Однако решать не получалось: встречи с руководителями один на один проблему не решали – у каждого свои приоритеты и проблемы соседних департаментов их конечно волнуют, но намного меньше, чем свои. Групповые собрания (некий предшественник комитета по ИТ) так же организовать не получилось: большинство задач были настолько рутинными и частными, что обсуждать, например, с финансистами запросы HR и совместно их как-то ранжировать, было бесполезно. Мы просто теряли время ТОП менеджеров компании, а решения не было…
ТОПов можно было собирать, когда обсуждались какие-то значительные проекты (организация ЭЦП, цепочек продаж и пр). И это были продуктивные встречи, задачи таких проектов нормально проходили цикл разработки. Но был еще вал рутинных задач и для рутины нужно было иное решение.
Мне это не нравилось.
Я в этом какое-то время барахтался, а потом решил: «Стоп, хватит! Почему это моя головная боль: как «сшить из этой шкурки семь шапок»? А заказчики (внутренние) упорно хотят все и на вчера?». Ведь мы с заказчиком тратим впустую время на все эти приоритеты, требуемые даты готовности и пр... Куча времени «в никуда». И я решил донести это до заказчиков.
И произошло это не совсем стандартным способом – мы просто убрали реквизиты «Важность» и «Ожидаемый срок». Вообще. А вместо этого ввели понятие «Очередь».
Задачи каждого подразделения выстраивались в очередь, строго одна за одной, как они и должны были заходить в разработку. И руководители подразделений, путем попарного сравнения или еще каким-то методом, должны были сами выстроить задачи согласно своим приоритетам. (Ключевые пользователи все так же ставили задачи, а вот руководители уже их ранжировали). Т.е. мы сказали: «Нельзя все и сразу, программисты работают одновременно над одной задачей, и от вас будем забирать по одной».
Таким образом, у нас ушли много «красных» задач от каждого подразделения, а по каждому подразделению появились упорядоченные (по важности и срочности) очереди из задач. Суть в том, что я вернул проблему туда, где она возникла и где была возможность ее решать. Руководители увидели задачи, как очередь, а не как набор сущностей с датами.
А дальше это работает следующим образом:
- Постановщики ставят задачи.
- Разработчики, которым достаются эти задачи, примерно раз в день выделяют время и делают предварительную оценку трудозатрат (в человеко-днях или человеко-часах) на каждую такую задачу. (Техлид и я следим за достоверностью этих оценок).
- Система сама автоматически строит уже очереди задач по разработчикам. Принцип мы выбрали сначала очень простой: задачи в очередь к разработчику берутся из топа очередей по подразделениям опять же по очереди. Не важно, сколько времени заняла у разработчика прошлая задача от бухгалтерии, после ее выполнения, программист берется за задачу следующего подразделения, где он назначен исполнителем, и к следующей задаче бухгалтерии он вернется после того, как выполнит по задаче из топа очереди всех других подразделений. Позже мы думали все же сменить принцип на какой-то иной, но этот так и прижился. «Нет ничего более постоянного, чем временное…».
На основании этих очередей и оценочной длительности выполнения задач мы смогли построить диаграмму Гантта по каждому разработчику, получить плановые даты начала и окончания по всем задачам в очередях всех подразделений.
- Руководители подразделений получили возможность не просто переставлять свои задачи в очереди, но и видеть их плановые даты выполнения (мы пересчитывали все цепочки «на лету»). И на смену мифическому «Ожидаемому сроку» пришли «Плановая дата начала» и «Плановая дата завершения».
Красота!
А еще мы стали прозрачными – все могли видеть нашу загрузку, каждого разработчика: каждый, кто имел доступ к системе, мог построить диаграмму Гантта по разработчику и увидеть из чего состоит очередь разработчиков и почему его задача выполниться по плану через месяц, а не завтра (хотя она такая важная и срочная). Отмечу, что в этом графике каждый мог видеть суть (название) задач только своего подразделения. Задачи других подразделений, просто отображались прямоугольниками, и он видел лишь, что задачи есть и видел какого подразделения это задачи.
Эта видимость дала возможность вернуться к встречам на уровне ТОПов только уже предметных, а не как ранее. Если кого-то не устраивали сроки по какой-то задаче (ам), он видел кто на диаграмме ему предшествует и договаривался уже с конкретным руководителем. Комитетом по ИТ это так и не стало, но с чего-то нужно начинать…
Решение нам помогло не только настроить процесс, но и оценить трудоемкость имеющегося на любой момент бэклога и рассчитать плановые даты завершения всех поставленных задач. Это, кстати, дало возможность измерить необходимость в дополнительном разработчике. И вскоре наша команда усилилась еще одним участником.
На реализацию описанного выше в нашей трекинговой системе нам понадобилось совсем не много времени. Тот факт, что она была нами же написана здесь был очень кстати. Мы смогли заложить в систему все, что захотели. Новое решение мы «продали» бизнесу, как повышение прозрачности процесса разработки, чем, собственно, оно и было. Сопротивления как такового не было. Мы немного «допилили» механизм по ходу эксплуатации после запуска и все заработало «как часы».
Это не идеальная система.
Но она смогла дать постановщикам задач понятие ценности времени разработки. Теперь им приходится понимать необходимость и ценность каждой задачи и отдавать в работу самое ценное. Это еще не продажа своих услуг внутренним клиентам, но первая ступень в понимании того, что твой запрос – это затраты времени и ресурсов иного подразделения и к нему нужно относиться экономно.
Это стало первым маленьким шагом к комитету по ИТ. После этого изменения ряд ТОПов стал собираться, если нужно что-то сделать большое или сменить приоритеты – у бизнеса появляется понимание механики разработки.
Система в таком виде (с минимальными изменениями) проработала уже больше четырех лет и работает сейчас. Прижилась…
Планы на будущее - глобально 2 пункта:
- Сделать 2 очереди исполнителей – одну для аналитиков, а вторую для разработчиков. Часть задач требуют обработки аналитиками ИТ и это иногда существенное время, иногда оно больше, чем время разработки (особенно когда речь идет о постановке нового процесса в нескольких подразделениях).
- Перенести механизм из «самописной» системы в какую-то из систем управления задачами. Где есть интеграции с различными каналами связи, дизайн и прочие плюшки.
На п. 2 никак не найду систему, где это можно сделать. По этой причине не делаю пока п. 1 – хочется его сделать уже в новой системе, а не в старой.
Вот так и живем…
