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

24.06.19

Бизнес-анализ

Многие менеджеры вынуждены работать в условиях многоклиентской среды с ограниченными ресурсами. И вовремя сдавать проекты в таких условиях сложно. Как добиться того, чтобы поставки делались без нарушений сроков, рассказал гостям и участникам конференции Infostart Event 2018 управляющий партнер BIPULSE.RU Алексей Васильев.

Справка

Алексей Васильев, выпускник Санкт-Петербургского национального исследовательского университета информационных технологий, механики и оптики. Прошел путь от разработчика до менеджера и консультанта. Внедрял Agile c момента его появления в России, с 2001 года. Имеет большую практику в применении и синтезировании разных адаптивных подходов. С 2015 года координатор Санкт-Петербургского клуба менеджеров 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 2018 EDUCATION.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Как реорганизовать работу проектного департамента, чтобы быть №1

Внедрение изменений Бесплатно (free)

Методики быстрореагирующего производства и QRM-ячейки применимы не только к станкам, но и к проектным командам. О том, как за счет разделения проектного офиса на многофункциональные QRM-ячейки обеспечить равномерную загрузку работу сотрудников, вырасти в два раза и существенно повысить лояльность заказчиков и коллектива, пойдет речь в статье.

14.02.2024    526    0    user1270271    2    

7

Управление ожиданиями на проекте

Работа с заинтересованными сторонами Бесплатно (free)

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

08.02.2024    429    0    izybaevda    0    

3

Как внедрить 1С:ERP за 2 года и не сойти с ума

Анализ предметной области Анализ потребностей и поиск решений Внедрение изменений Бесплатно (free)

Для руководителей подразделений новые проекты вызывают желание получить максимальный эффект от реализации идей, а также опасения, верно ли выбран ориентир нововведений. О том, как справиться с трудностями, дойти до цели и внедрить 1С:ERP на производственном предприятии, ежедневно выпускающем десятки тысяч единиц готовой продукции, расскажем в статье.

30.01.2024    6537    0    user1578851    16    

16

Свободное программное обеспечение в крупной компании – миф или реальность? Как мы переводили 2500 пользователей на Linux

Внедрение изменений Бесплатно (free)

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

29.01.2024    2403    0    user1063453    2    

5

Зачем нужны аналитики на проектах автоматизации

Анализ потребностей и поиск решений Бесплатно (free)

Исторически сложилось так, что аналитик 1С многими воспринимается как вечный падаван, который обеспечивает разработчиков информацией, а пользователей – инструкциями. Не согласимся с таким подходом и на примере реального кейса покажем, почему именно аналитик должен стать лидером проекта автоматизации.

18.01.2024    1537    0    user1754524    19    

12

Радио "Аналитик", 7 выпуск 2 сезона. Про работу аналитика с бизнесом и повышение бизнес-компетенций с Константином Семёновым

Анализ предметной области Работа с заинтересованными сторонами Анализ потребностей и поиск решений

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

28.11.2023    400    0    Radio_Analyst    0    

2

Радио "Аналитик", 4 выпуск 2 сезона. Про решение проблем с Анастасией Московкиной

Анализ потребностей и поиск решений

В четвертом выпуске второго сезона подкаста Радио “Аналитик“ поговорили, как анализировать и приоритизировать проблемы, как работать с неопределенностью и решениями, которые приняли без нас.

17.10.2023    349    0    Radio_Analyst    0    

2
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. for_sale 970 24.06.19 19:12 Сейчас в теме
Ничё не понял, но очень интересно)

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


В проекте есть три задачи, на трёх разработчиков. Каждый даёт Х на задачу. Получаем 3Х нужного нам времени на проект. Теперь, если делать, как описано, то нужно 0.5х + 0.5х + 0.5х - это время на задачи и ещё 0.5х + 0.5х + 0.5х в буфер. В результате получаем те же 3Х. Что изменилось? Для чего строить все эти цепи, если мы всё равно ничего не изменили, каждый всё равно затратит время Y на решение задачи и каждый всё равно будет пользоваться своим личным буфером, который он заложил на оценку?

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

В общем, если честно, не очень понял суть метода, буду благодарен за разъяснения, потому что тема интересная.
3. Glebis 13 25.06.19 12:51 Сейчас в теме
(1) Плюс корректировка на коэффициент точность оценки времени (70% если брать общий для всех 3х разработчиков):
общее время работы = 3Х + 3/7*3Х,
после контролируем буфер (3Х + 3/7*3Х)/2 времени.
2. Glebis 13 25.06.19 12:12 Сейчас в теме
(1) При истечении 3Х начинаем контролировать буфер в течении 1,5Х по каждому из 3х проектов, не разбираясь какой разработчик чем занят. Тот кто закончит свой проект и не растратит 1,5Х буфера должен помогать тому, у кого буфер в красной зоне.
4. for_sale 970 25.06.19 13:54 Сейчас в теме
(2)
При истечении 3Х начинаем контролировать буфер в течении 1,5Х

Это ещё непонятнее. В статье написано, что от оценки мы отнимаем половину и закидываем в буфер. А тут, получается, работа 3Х и ещё буфер 1.5Х? Если да, то откуда мы берём оплату на 1.5Х, если закладывали только 3Х? Если нет, тогда я ничего не понял))
5. TerveRus 27.06.19 08:47 Сейчас в теме
(4) так там же не про деньги, а про планирование. Про то, как назначит сроки и все успеть)

При первоначальном расчете у нас, например, время оценки программиста просто умножали на 2 и выставляли счет. Ну справился быстрее - молодец и премия повыше)

Но, конечно же, не все могут позволить себе увеличивать ценник на время буфера.
6. for_sale 970 27.06.19 09:44 Сейчас в теме
(5)
Т.е. статья просто о том, что чтобы всё успеть, нужно просто умножить срок на два?))
7. decline12 22 28.06.19 10:20 Сейчас в теме
Когда уже перестанут планировать работу программистов и начнут планировать работу менеджеров?
1. Программирование это творческая работа, как у художника, ну не стоит сегодня творить и создавать шедевры и вот хоть какие планы рисуй они все будут выполнены с этим показателем да и говнокодить я думаю все умеют.
2. Можно ли программировать все 100% времени? 8x21? или 10x21? а вы сами пробовали? попробуйте что-то писать не отрываясь от процесса и так на протяжении месяцев / лет.
3. Вы учитываете тот факт что на рынке программистов меньше чем предложений о работе и специалист любого уровня в любой момент времени может уйти с проекта, сдадите все в срок? а если это был ключевой игрок.

У вас метод когда все работает в идеальных условиях в идеальной среде в идеальном мире, на практике все не так.
Deslime; mRconik; anosin; +3 Ответить
8. RustIG 1301 04.07.19 11:01 Сейчас в теме
(7) вот вы программист, и вы когда входите в проект честно признайтесь, что эффективно работаете 4 часа в день, и по данному проекту хотите работать два дня в неделю.

Руководитель проекта под вас подберет задачи.

Еще раз, вы не должны программировать 8 часов/день х 5 дней в неделю. В таком режиме (постоянно думать и выдавать корректный адекватный идеальный результат) сходят с ума.
Деятельность необходимо менять - сегодня вы общаетесь с клиентами , завтра два дня программируете, след. день тестируете гипотезы, след. день читаете форумы и помогаете коллегам...
Может быть 3 дня программируете, может быть 5 дней по разным проектам....

Главное, что вы знаете свой ресурс, заявляете об этом руководителю, далее руководитель распределяет задачи...
Если руководитель видит в вас машину по зарабатыванию денег , и распределяет на вас задач в объеме 8 часов/день х 5 дней в неделю, то это проблема уже руководителя, а не ваша... Ищите адекватного руководителя, мой совет в таком случае.

И тогда не будет у вас такой обратной связи
а вы сами пробовали?
9. DAV 13.08.19 10:55 Сейчас в теме
(7)
Когда уже перестанут планировать работу программистов и начнут планировать работу менеджеров?

Собственно метод Голдратта "Критическая цепь" как раз про планирование работы менеджера ))) Что бы тот постоянно был в тонусе. Для этого и собственно делается этот самый буфер и режется длительность основной задачи. Т.е. если в обычном планировании ты обратишь внимание на задачу когда она израсходует свое время и перелезет в буфер, то может быть уже поздно. А разработчик, как правило за временем следит "спустя рукава" и о такой мелочи, как предупредить РП о том, что он перелезет за границы он не будет, так как искренне верит в то, что успеет :) Собственно, потому то и придуман этот способ: режем основное время на задачу (поначалу лучше не зверствовать с 50%, а начинать так с 70-75%), а остальное в буфер. И как только основное время закончилось (а ведь есть вероятность, что человек закончит работу в это время, и не нулевая), то РП воленс-ноленс обратит внимание на задачу... Таким образом он всегда в "фокусе" ... Как то так ;)
Оставьте свое сообщение