Внедрение решений: как выполнять все обязательства в срок в условиях ограниченных ресурсов

Справка

Алексей Васильев, выпускник Санкт-Петербургского национального исследовательского университета информационных технологий, механики и оптики. Прошел путь от разработчика до менеджера и консультанта. Внедрял Agile c момента его появления в России, с 2001 года. Имеет большую практику в применении и синтезировании разных адаптивных подходов. С 2024 года координатор Санкт-Петербургского клуба менеджеров IT-проектов. В настоящее время тренер, консультант, управляющий партнер BIPULSE.

О чем пойдет речь

Компания (учебный центр) BIPULSE помогает менеджерам сдавать проекты вовремя. И проблемы, о которых я буду говорить, знакомы многим.

В каком мире мы живем? В мире, когда у нас много клиентов и мало ресурсов. И при этом объем работы точно не известен: и не так страшны первые 90% проекта, как вторые 90% проекта. Мы контрактуемся на один объем работы, а по факту он растет. Сроки и бюджет при этом фиксированные. Поэтому нам нужно все это как-то подружить между собой. Ситуация усугубляется тем, что поток заказов неравномерный, и это тоже очень сильно напрягает.

Возникает вопрос, как выжить в условиях, когда нужно удерживать в голове многие вещи.

Какие подходы можно применить

Посмотрим, что обычно делают менеджеры, и какие подходы для работы есть в принципе.

Самый простой способ – это нанять больше сотрудников. Мы наймем больше сотрудников, и тогда все успеем. Много клиентов – больше сотрудников, все замечательно.

Но это приводит к увеличению фонда оплаты труда.

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

Получается, намного лучше удерживать компанию на текущем состоянии и не увеличивать количество сотрудников. Т.е. этот вариант не работает.

Что еще можно сделать? Наверное, усилить контроль. Команда не успевает выполнять задачи, поэтому вы, как менеджер, должны контролировать сроки исполнения задач. Например, разработчик пообещал, что сделает задачу за два дня, и не сделал. Вы к нему приходите и начинаете ругать, мол, обещал и не сделал, надо в следующий раз успевать, давать правильную оценку сроков. И вы начинаете метаться: здесь разработчик, там разработчик. И сам менеджер становится ограничением. Почему? Потому что от него начинают ждать принятия решений. Сотрудники перестают работать самостоятельно, они ждут, когда их «пнут». И менеджер пытается «пинать». Появляется «выученная беспомощность» – без начальственного взора ничего не работает, не делается.

И вы, как руководитель, становитесь ограничением.

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

Какие еще есть варианты? Например, Agile, всякие другие методики. Может, он нам поможет в условиях, когда много клиентов. Возможно, но есть проблема – эти все подходы рассчитаны на однопроектную, однопродуктовую среду. Там ничего нет про многоклиентность, там все делается под монопродукт, который создает команда – большая или маленькая.

А если Project-менеджмент использовать, может, он поможет? Но Project-менеджмент – это толстая книжка, читать ее долго (там 600 листов), а как применить – непонятно.

Есть еще теория ограничений, но тоже непонятно, как ее использовать в нашем производстве, в нашей разработке.

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

Решение есть – скрестить разные подходы и адаптировать их под себя

Один из вариантов, который я предлагаю, – скрестить разные способы.

Для этого возьмем то, что решает проблему, адаптируем к нашей среде, и находим новое решение уже на уровне синтеза разных подходов. Некоторые уже говорили, что не стоит упираться в методологии. На самом деле в методологиях всё есть, но нужно знать, что брать. В каждой методологии есть одна часть, которая работает именно в нашей среде. Мы ее можем взять и адаптировать. И даже первый принцип Agile гласит: «Адаптируй!». Поэтому небольшие изменения вполне приемлемы.

Что мы будем брать? Я предлагаю взять метод критической цепи теории ограничений, конечно же, Agile, добавить сюда щепотку «Мифического человека месяца» Брукса и «Профессиональной разработки программного обеспечения» Макконнелла. Все это приправим фирменным соусом моего авторства – у меня 20 лет разработки, поэтому я могу это скрестить.

Метод критической цепи: как работает и что из него можно использовать

Начнем с теории ограничений. Она придумана в 1984 году Голдраттом. И самое основное в ней – это оптимизация денежного потока компании. Также в ней есть решение для управления проектами, дистрибуцией и так далее.

В чем суть Теории? В любой системе есть только один фактор, ограничивающий возможность зарабатывания денег. Все очень просто, остается только его найти. Поэтому самое важное – это найти ограничение.

Где у нас чаще всего бывают ограничения? Ограничений у нас часто два:

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

2. Загруженный ресурс – разработчик, который жутко загружен, его все ждут. Это очень большой профессионал, его надо ждать, но зато все знает. Но он является ограничением нашей системы и не дает нам больше зарабатывать, точнее, ограничивает пропускную способность нашей компании по деньгам.

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

Что он дает? Он позволяет сдать проекты в срок. 97% проектов, выполненных методом критической цепи, завершаются в срок или раньше срока. В остальных случаях статистика показывает своевременную сдачу 70%. Кроме того, он экономит внимание руководителя: ему нужно меньше тратить внимание на то, чтобы делать микроменеджмент и прочие вещи.

И самое важное – он выстраивает поток работы на ресурсе-ограничении. Это позволяет управлять всем конвейером.

За счет чего это работает?

Все лгут. Лгут оптимистично или лгут пессимистично. Приведу пример: руководитель спрашивает оценку, за сколько человек сделает. Он ориентировочно говорит, что дня за два. Но проходит три дня, а работа так и не сделана. И руководитель начинает ругаться, что человек подводит, что он не очень хороший сотрудник. Что сделает человек в следующий раз? Заложит подстраховку!

Он не хочет, чтобы повторялись эти разговоры, и он закладывает подстраховку. У него появляется много времени, чтобы выполнить задачу, уложиться в срок. Но срабатывает закон Паркинсона – всякая работа занимает все отведенное под неё время. Человек заложил себе в два раза больше времени, но не успел, потому что потратил его на какие-то другие дела, например, на соцсети.

Или бывает иначе. Человек думает, что у него много времени, поэтому откладывает выполнение задачи на потом. Наверное, многие сдавали курсовую работу в последнюю ночь. Это синдром студента: мы все откладываем на последний момент. То есть у нас много времени, но мы откладываем задачу на последний момент. И, конечно, мы не успеваем. И пропускаем все сроки, нарушаем все свои обещания.

Есть еще одна важная деталь – многозадачность. Это когда руководитель прибегает с новым проектом, который нужно срочно-срочно делать. Все начинают заниматься новым проектом, а старый бросают. А ведь старый тоже надо делать. Поэтому мы сначала одним проектом занимаемся, потом другим, у нас переключения, нервный срыв у разработчиков, у менеджера, тем более. И команда ничего не успевает.

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

Эффективность в режиме многозадачности – процентов 30 от максимума. У разработчиков еще хуже: они могут только на одном сфокусироваться. Тем не менее, мы считаем, что многозадачность есть, и такой фактор нужно учитывать. И метод критической цепи тоже это учитывает.

Но самая важная деталь – это закон Мёрфи: все, что может пойти не так, пойдет не так.

Можем, конечно, вспомнить про риск-менеджмент. Но кто его применяет? Им пользуются нечасто. Хотя закон Мёрфи говорит: как бы хорошо мы риски не проанализировали, все равно что-то пойдет не так, что-то будет не учтено. Но метод критической цепи учитывает и это тоже – те самые риски, которые могут произойти (дефекты, новые требования, которые неожиданно откуда-то появляются).

Как работает метод критической цепи? Очень просто: берем оценку с вероятностью завершения 50%. Например, разработчик нам сказал, что сделает за 2 дня. Мы эту оценку делим пополам, и половину пишем в буфер. И так от каждой задачи половину оценки записываем в буфер. Буфер нас защищает от неопределенности, высказанной Мёрфи.

После этого исключаем многозадачность и строим критическую цепь.

Как правило, если задачи крупные, мы можем выстроить их в какой-то последовательности. Например, мы договорились о последовательности поставки, и у нас получится какая-то критическая цепь. Она будет выглядеть примерно так, как на картинке ниже: красным выделена критическая цепь. В конце у нас буфер. То, что не красное, то выполняется не с помощью метода критической цепи.

После того, как построили цепь, нужно контролировать буфер. Это четвертый шаг – отслеживать потребление буфера.

Вот четыре шага метода критической цепи.

Буфер надо контролировать. В чем суть контроля буфера? Посмотрите на график.

То, что по оси Х, – это процент исполнения проекта или процент исполнения цепи. Если проект в зеленой зоне – все хорошо, мы можем не вмешиваться в работу команды. В желтой – нужно держать руку на пульсе, потому что с проектом что-то не так, еще чуть-чуть, и он выйдет из-под контроля. Эти показатели говорят о том, что за проектом нужно наблюдать, готовиться договариваться о чем-то. Если проект в красной зоне все плохо: его уже надо спасать, нужно думать, как перебросить ресурсы, надо ли спасать проект или не стоит.

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

Для IT-проектов метод придется изменить

Все это замечательно, всего четыре простых шага. Но в IT-проекте есть такая проблема, что объем меняется. Поэтому у нас различные доски популярнее, чем календарные планы-графики, и их часто приходится менять.

А если меняется цепь, если ее надо перестраивать, это затраты на перепланирование.

Но с другой стороны, разработчик делает то, что ему больше нравится. Как бы хорошо вы ни планировали, если вы дадите ему пять задач, он выберет самую интересную для себя, потому что ее интересно делать. Неинтересная остается «на завтра», «на вечер» или «на потом». Поэтому план устаревает, в том числе, за счет того, что меняются приоритеты.

Кроме того, IT – это командная игра, и назначить конкретного человека на задачу мы не можем, мы должны назначать ее на команду.

А еще инженеры – оптимисты. Если задачка очень короткая, то он может на нее заложить 2 дня. И если его еще не били по голове вопросами «почему не сделал вовремя, как обещал», то он будет оценивать ее оптимистично. Поэтому важно «не бить по голове», не спрашивать, почему он не сделал. А нужно коэффициент точности планирования, то, насколько разработчик ошибся, посчитать, записать себе куда-нибудь, а в дальнейшем использовать это при планировании сроков. Но если мы учтем эту оценку в цепи без подстраховки, то у нас буфер быстро израсходуется, он будет соответствовать точности и не защитит нас.

Поэтому нам нужно адаптировать этот метод критической цепи.

Как можно адаптировать

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

У нас получится что-то вроде расчета, пример которого вы видите ниже.

У нас оценен объем (оптимистично оценен). Обратите внимание: маленькие задачи содержат неточность планирования, ошибку, в них нет подстраховки. А оценки по выполнению больших задач нужно делить на 2, потому что в них подстраховка. Например, когда на задачу дают 4 дня, там уже подстраховка точно есть, а если задача должна быть выполнена за один день, там подстраховки, как правило, может не быть.

Мы учитываем точность планирования (нормальный показатель – примерно 70%). И добавляем буфер списания, это примерно 30% контрактных сроков или 50% от оцененного объема. То есть мы упрощаем весь расчет цепи до такого простого метода.

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

Для надежной поставки достаточно семи шагов

1. После  оценки мы должны контролировать буфер. Если мы его не контролируем, все бесполезно. Буфер надо заложить, и его надо контролировать. Если вы его заложите, но не будете контролировать, у вас будет дырявое ведро, из которого все резервы просто пропадут, их просто не будет. Потому что на буфере сразу видно, кого спасать, куда бежать, как и когда договариваться.

2. О том, как договариваться, мы можем взять из прогноза срока завершения. На основе диаграммы сгорания мы знаем срок завершения проекта. Если нам надо договариваться об объемах, мы можем сказать заказчику, что закончим в такой-то срок с учетом текущей скорости. Надо объяснить, что вы рассчитывали закончить раньше, но не успеваете, поэтому предлагаете обсудить объемы работ, может быть, что-то сместить или не делать, или упростить. И вы уже знаете, о чем договариваться, но у вас должен быть четкий ответ, когда вы точно сделаете работу.

3. Самое важное – каскадируем проекты. Так как у нас ресурс – вся команда, то мы каскадируем проекты на одной команде. Один проект в один момент времени – это важно. Когда у вас один проект в один момент времени выполняется одной или двумя командами, то у них растет взаимовыручка, у них появляются общие темы для обсуждения на ежедневных стендапах, им становится интересно, что делает коллега. А когда ребята работают на разных проектах, у каждого свои задачи, никто друг другу не помогает. Поэтому когда 1-2 команды работают над одним проектом, то мы можем его делать быстрее за счет взаимовыручки и помощи. Задачи закрываются быстрее, проект закрывается быстрее, мы быстрее получаем деньги за завершение. В итоге у нас повышается скорость генерации дохода, мы быстрее начинаем зарабатывать.

Четвертый шаг – запускаем проект по Agile, где есть частая поставка, уточнение требований, формирование цикла обратной связи, развитие команды проекта через ретроспективы. Всю процессную часть мы делаем по Agile-стандартам, потому что у нас один проект, мы привели систему в то состояние, где работает Scrum, где работают Agile-подходы, где работает Канбан метод. И система становится рабочей за счет того, что снаружи у нас критические цепи.

5. Но у нас же есть неопределенность по клиентам: мы не знаем, когда они появятся. В то же время мы знаем прогноз занятости сотрудников на основе того, сколько проектов у нас стоит в очереди, какие ключевые ресурсы заняты, и можно спрогнозировать, когда освободится ключевой сотрудник, который может начать делать новый проект. Если  он освободится через полгода, контрактуемся за 2 месяца, мы даже можем поднять стоимость проекта и заработать больше. Если наоборот, то опускаем стоимость и запускаем проект быстрее в работу. И за счет этого мы можем на тех же ресурсов начать зарабатывать больше. Но для этого надо знать, когда освободится ключевой разработчик – не по завершении проекта, а именно по завершению запланированной работы ресурса-ограничения. Вот такая тонкость. И таким образом мы  можем выровнять поток заказов.

Шестой шаг – определить, какой из проектов в красной зоне ускорять. Здесь будет битва: когда вы начнете договариваться о том, куда бросать ресурсы, на какой проект.

Здесь должны быть простые правила: мы ускоряем не тот проект, менеджер которого пришел и больше всех кричит, а тот проект, который у нас требует больше внимания, – больше находится в красной зоне. Если правило один раз определить, это опять-таки снимет нагрузку на вас, как на управленцев. У вас машинка будет работать сама, люди на местах на основе правил будут принимать сами решения. Это сильно упростит вам работу.

И седьмой шаг – регулярно планировать, выполнять, проверять, корректировать. Т.е. цикл Деминга-Шухарта никуда не девается, и надо проводить планерки, делать работу, проверять результат, что получилось, корректировать планы и процессы. Обратите внимание, тут две корректировки – и планов, и процессов. Проверять мы можем на основе метрик, прогнозов, данных по буферу, и при необходимости и корректировать наши процессы.

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

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

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 EDUCATION. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.