Неограниченные хотелки и ограниченные возможности

В этой заметке хотелками я называю запросы, задачи, проекты. Для меня это слово нейтральное или даже позитивное. Хотелки часто бывают нужные и важные.

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

Те, кто читал «Цель» Голдратта, знают историю про детский поход и самого медленного мальчика Герби. Пока Греби не дойдёт, поход нельзя считать законченным. А раз так, то нужно ли всем остальным бежать сломя голову? Мы часто стремимся к локальной эффективности во всех точках в надежде, что вся система от этого выиграет. Но в итоге такой подход порождает кучу конфликтов, которых можно было избежать. И при этом всё равно усиливает цепь только на то значение, на которое мы усилили самое слабое звено.

Практически каждый раз, когда мы начинаем обсуждать ускорение поставки ценности, мы начинаем говорить о сокращении работы в работе. Это значит, что мы не запускаем новый проект, пока не завершим один из старых. Часто такая «задержка» пугает, особенно заказчиков. У нас есть стойкое ощущение, что чем быстрее задачу возьмут в работу, тем быстрее она будет закончена.

Ещё мы часто верим, что чем позже будет начата работа над задачей, тем позже она будет выполнена. Но есть другое, противоречащее этому утверждение: чем больше задач одновременно запущено в работу, тем дольше они будут выполняться. Увеличивается и время появления каждого результата, и трудоёмкость каждой задачи. Есть куча объяснений и доказательств этого, кто хочет — может накидать ссылки в комментарии. Я пока ограничусь выдуманным примером (спасибо Андрею).

Мне нужно прочитать пять книжек. Есть два крайних варианта, как я могу это сделать. Я могу прочитать их последовательно, а могу все пять читать параллельно. Вероятно, что в первом случае я справлюсь быстрее. В варианте с постоянным переключением между книжками я буду каждый раз много времени тратить на то, чтобы вспомнить, на чём я остановилась, и что было до этого. Иногда мне даже придётся перечитывать заново несколько последних страниц. Качество усвоения также будет заметно отличаться.

Грубо: чем меньше задач мы будем выполнять параллельно, тем быстрее начнём получать результаты и потратим на каждую задачу меньше времени.

Допустим, мы поверили в WIP-лимиты (work in progress) и решили ограничить количество работы в работе. Когда заказчик внешний, не всегда, но часто, нам довольно просто не посвящать его в подробности и не пугать задержкой старта. Но когда заказчик внутренний, например, наш начальник или владелец продукта, то задачка немного усложняется. А ещё она усугубляется тем, что чаще всего, внутренний заказчик не платит за реализацию своих хотелок. Они для него бесплатны и в основном ограничены только фантазией.

С другой стороны, ресурсы, необходимые для реализации хотелок, часто имеют вполне ощутимое ограничение. Хотелки будут появляться всегда. Всегда. Допустим, мы научимся их приоритизировать и даже научимся ограничивать число проектов/задач, над которыми работаем в один момент времени. Всё равно будут постоянно возникать новые хотелки. Если скорость появления хотелок будет превосходить скорость реализации, значит, проектами с приоритетом ниже некоторого, мы не займёмся никогда.

Это значит, что нужно научиться выделять эту часть проектов и сразу отправлять их в условный архив. Не стоит засорять ими даже бэклог. Но всё же полезно копить информацию об «отменённых» проектах. Хотя бы для того, чтобы не повторяться. Чтобы не получалось так, что кто-то придумал инициативу, её оценили и приняли решение не реализовывать. Спустя год, кто-то другой притаскивает ровно такую же инициативу, и мы снова начинаем её анализировать.

В нескольких кейсах мы приоритизировали проекты, оценивая условную выгодность и длительность проекта. Оба параметра оценивали в попугаях, сравнивая с несколькими эталонными проектами. В одном из кейсов мы оценивали выгодность как сумму трёх параметров: потенциальное влияние на проход, ROI, и срочность. Потом также в попугаях оценивали длительность проекта и делили выгодность на длительность. Мы хотим получать не просто как можно больше выгоды, но и как можно быстрее. Хотя 1 тыс. рублей вроде бы лучше, чем 100 рублей. Но если 100 завтра, а 1000 через год, то лучше 100.

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

Для каждого проекта мы получили коэффициент, который сравнивали со шкалой. Если приоритет был ниже «красной линии»(невнятная выгода, либо слишком большая длительность), то мы сразу убирали проект в архив. Между «жёлтой» и «зелёной» — отправляли на проработку. Выше «зелёной» (многообещающие и быстрые проекты) — сразу в бэклог. После проработки мы могли уточнить коэффициент, часть отправить в архив, а остальные в бэклог.

Конечно, иногда бывают очень масштабные и вроде бы необходимые изменения, но даже их полезно разбить на этапы. Если каждый этап будет приносить ощутимую пользу, то такие проекты не будут отсеиваться нашей системой приоритетов. А заодно мы исключим такие проекты, когда мы за год внедрили систему автоматизации, которая бы очень помогла нам год назад, но сегодня она совершенно не отражает текущую действительность. Не буду здесь писать про плюсы итеративности, вероятно, вы уже и сами их знаете.

А что такого плохого может быть в том, чтобы просто складывать все проекты в бэклог? Ну и пускай там висят в конце списка со своим маленьким приоритетом😈.

P.P.S. Мой канал в телеграм с уведомлением о новых заметках и короткими заметками, которые я публикую только там.

Александра Брызгалова