Pull to refresh

Как повысить КПД разработки, используя теорию ограничений

Reading time 4 min
Views 9.6K

Добрый день!


Хочу предложить небольшой экскурс в практическое применение теории ограничений для ИТ. А именно — в вопросе расчета "прохода" (throughput) отдела по разработке внутрикорпоративного ПО.


Про саму ТОС (Theory of Constraints) и мега-книгу "Цель" ("Goal") Элии Голдратта написано много, в том числе на Хабре, поэтому сразу перейду к делу.


Отдел, которым я руковожу, занимается поддержкой и развитием нескольких т.н. "inhouse" информационных систем, основные из которых WMS и TMS — системы управления складом и перевозками. Дальше сосредоточусь только на этих системах и только одной части бизнеса — услугах логистического оператора.


Каждый день в наш почтовый ящик сыпется с десяток новых задач, многие из них с пометкой "Срочно!", "Важно!" и т.п.


На текущий момент бэклог разросся примерно до семи сотен задач разной категории сложности.


Для того, чтобы как-то управляться с этим объемом, мы внедрили систему приоритетов, по степени влияния на бизнес:


A — сбои системы, либо проблемы, которые не позволяют в полном объеме выполнять контрактные обязательства (по основному бизнесу).


B — задачи, связанные с ростом выручки компании — то есть заездом новых клиентов.


C — задачи, связанные с повышением рентабельности, то есть задачи на оптимизацию производительности (всего — системы, рабочих процессов, людей, роста выработки и т.п.).


D — доработки по просьбам наших клиентов (отчеты, интеграция с транспортными компаниями и т.п.).


Внутри этих категорий есть еще один уровень деления (A1, A2, …), но для целей сегодняшней статьи это не существенно.


По логике вещей, выполнение задач должно быть построено по порядку: A-B-C-D.


На практике, план разработки — результат большого количества компромиссов. Как пример, задачи категории D часто выплывают на самый верх бэклога (клиентоориентированность, да).


То есть по факту, система приоритетов дает только общее направление для планирования, но не позволяет дать каждому объективный ответ на вопрос: "А почему моя задача так долго не делается?"


Также имеем проблему маленьких и больших клиентов, на которых тратится примерно одинаковый ИТ-ресурс. Теоретически, более жирные клиенты должны быть в приоритете, но маленьких тоже бросать нельзя, более того, маленький очень часто требует к себе особого внимания, как будто отгружает со склада не две газельки в неделю, а, как минимум, контейнерный поезд.


Понимая это и понимая, что компания — организация коммерческая, а не благотворительная, и в первую очередь должна приносить прибыль, мы решили прокачать систему планирования, используя теорию ограничений.


Ограничением в нашем случае является ресурс разработки.


ТОС вводит новое для бизнеса понятие "прохода" (throughput) — условной "скорости генерации дохода", которую следует непрерывно повышать. В отличие от издержек, рост прохода теоретически не ограничен ничем и может (может) стремиться к бесконечности.


В случае с разработчиками в качестве меры прохода будем использовать отдачу от человеко-часа, в рублях.


Алгоритм примерно такой:


  1. По каждой задаче необходимо провести оценку экономического эффекта от реализации. Это может быть экономия рабочего времени синего воротничка, либо экономия другого ресурса (например, дефицитных квадратных метров в зоне экспедиции, либо палетто-мест в зоне хранения, либо моточасов погрузчика). Желательно, в тысячах рублей / год. Провести такую оценку должен сам заказчик. Если он не может сделать этого самостоятельно, то обращается к своему руководителю.
  2. После того, как задача получила оценку с точки зрения эффекта, она поступает на проработку тимлиду, либо кому-то из синьоров. В итоге получаем некую предварительную оценку по затратам.
  3. Поделив первое на второе, получаем тот самый проход — скорость достижения эффекта.
  4. Ранжируем задачи в бэклоге по убыванию прохода.
  5. Отрезаем в очередной план/спринт кусок бэклога сверху.

К примеру, есть задача, эффект по которой заказчик оценил в 100 тыс.руб. в месяц, или 1,2 млн. руб. в год.
С нашей стороны на реализацию потребуется 40 часов разработки.
Проход, в результате, составит 1200 / 40 = 30 условных единиц.


По другой задаче ожидаемый эффект в 50 тыс.руб. в месяц, но на ее реализацию потребуется 100 часов. Итого, 600 тыс.руб / 100 = 6 у.е.


В итоге, мы сделаем обе задачи. Но сначала первую, а потом вторую.


Возвращаясь к категориям приоритетов, у нас образуется отдельный стрим на исправление (категория А), затем запуск новых клиентов (задачи планируются согласно существующих дедлайнов), а все остальное время засыпается разработкой по новой системе оценки прохода.


Плюс данной технологии в том, что она объективна. Даже при всех допущениях — как заказчик оценил эффект, неточности оценки сложности, уровень разработчика, который будет ее реализовывать — она дает реальную картинку важных и неважных задач с точки зрения бизнеса.


А что же с категорией D, спросите вы? Как там поживают хотелки клиентов, особенно мелких? Как они вписались в новую схему?


Этот вопрос пока остается открытым.


Для выстраивания объективной картины, по ним также необходимо оценивать экономический эффект, но уже, условно говоря, косвенный. То есть репутацию компании, клиентоориентированность, потенциальный рост бизнеса от этих клиентов, привлечение хороших референсов. Тут более тонкие материи, мы вместе с продажами и клиентским сервисом обсуждаем, как оцифровать эти показатели.


Конечная цель — получить объективную прозрачную систему выстраивания задач, которая позволит максимально использовать ресурс разработки. Возможно, как к гармонии, к ней можно только стремиться, однако теория ограничений однозначно утверждает — "Цель" достижима.


Как-то так.


По готовности очередной части ребуса поделюсь результатом.


P.S. За скобками оставлены пока вопросы рефакторинга и разнообразных инфраструктурных задач, к ним еще вернемся позже.

Tags:
Hubs:
+5
Comments 12
Comments Comments 12

Articles