Можно сказать, что я фанат мыслительных инструментов ТОС. Я не совсем одержима и не предлагаю использовать их по поводу и без. И всё же, мне кажется, даже просто наличие знания и понимания этих инструментов не может не изменить подход к анализу и принятию решений. Как я понимаю мыслительные процессы — это формализация мышления Голдратта. Того самого мышления, которое позволяло ему видеть ясно и чётко, игнорируя "так заведено".
Например, в проектном управлении был, и есть распространённый подход к планированию проекта — диаграмма Ганта. Всё больше команд отказывается от него в пользу гибких подходов. Частая причина отказа от жёсткого плана — в начале проекта мы не можем спланировать необходимый конечный результат. Голдратт тоже отказался от "Ганта", но по другой куда более распространённой причине.
В стандартном подходе есть понятие срока задачи. Сроки задач складываются в срок проекта. Для того чтобы успеть проект в срок, каждая задача должна быть выполнена в срок. Мы с вами знаем, что крайне мало проектов вокруг нас заканчивается в срок. Ну или в срок, но с превышением бюджета, или с урезанием содержания (спецификации) .
Можно было бы оправдать срывы сроков тем, что иногда мы ошибаемся при оценке, и ставим не реалистично маленький срок. Но тогда, мы должны были бы ожидать и обратную ситуацию. Часть (причём заметная) проектов должна была бы завершаться до окончания срока, но этого не происходит.
Тогда у нас есть другое оправдание — закон Мёрфи: "если что-нибудь может пойти не так — оно пойдёт не так". Но это тоже не слишком убедительное оправдание. Чаще всего проекты вокруг нас выполняются и планируются людьми, которые уже сталкивались с реальностью. Они в курсе и про Мёрфи, и про заказчиков, которые не читают ТЗ, и про исполнителей, которые любят уйти в перфекционизм, творческий кризис и другие способы прокрастинации. Исполнители тоже знают, что их будут дёргать на другие проекты и задачи, перекладывать на них косяки предыдущих этапов и штрафовать за срыв сроков.
При планировании не первого проекта, каждый, кто имеет доступ к планированию, старается заложить себе подстраховку. И исполнитель, и его тимлид, и их начальник, и владелец продукта, и CPO, а иногда даже продажник. Иногда рынок требует, и мы идём на крайне напряжённый срок. Но почему-то слишком часто, даже если у нас есть огромный запас подстраховок, проект всё равно не укладывается в изначальные обязательства. Либо мы увеличиваем срок, либо бюджет, либо урезаем содержание, либо все пашут в выходные и до ночи.
Почему так? Куда уходит время? У каждого исполнителя есть масса поводов не заканчивать раньше срока задачи, или даже закончить позже. Все мы сдавали сессию. До экзамена либо полно времени, либо одна ночь. Студенческий синдром никуда не уходит после завершения института. Так что мы все любим откладывать до последнего.
Если всё же его победить, то появляется закон Паркинсона — когда работа занимает всё отведённое для неё время. Иногда мы всё же заканчиваем работу раньше срока, но тогда в дело может вступать перфекционизм. Можно же сделать немного лучше, начать улучшать и в итоге не успеть в срок.
Иногда нас ещё и финансово «мотивируют» в зависимости от трудоёмкости задачи. В таком случае есть повод растянуть трудоёмкость. Даже если премию не сокращают в случае, если задача была выполнена быстрее, я всё равно не буду стремиться сдавать результат быстрее. Если регулярно сдавать задачи раньше срока — оценки трудоёмкости начнут урезать.
А ещё иногда мы и правда недооцениваем сложность задачи, или появляются новые вводные, а потом ещё и Мёрфи с чёрным лебедем. В итоге есть куча поводом сорвать срок задачи несмотря на заметный запас подстраховки. Если я выполню задачу со срывом срока, то следующий исполнитель с более высокой вероятностью сорвёт срок уже своей задачи.
А что произойдёт, если я, несмотря на всё описанное выше, выполню задачу раньше срока? Скорее всего — ничего. У следующего исполнителя и так есть запас подстраховки, он не планировал начинать раньше и у него есть чем заняться.
Получается, что выигрыш по времени не передаётся, а опоздания накапливаются. Как итог, несмотря на огромные запасы подстраховки — сроки проектов срываются. И о том, что проект уже невозможно выполнить вовремя, мы чаще всего узнаем близко к сроку завершения.
Что предложил сделать Голдратт? Если подстраховка в любом случае нужна, но мы её разбазариваем — значит нужно изменить правила использования подстраховки. Во-первых, подстраховка становится общей, и каждый берёт из общего котла столько, сколько ему необходимо. Во-вторых, больше нет сроков задач, есть срок проекта. А как тогда нам понять, успеваем мы или опаздываем? На этот вопрос отвечает инструмент под названием "диагональный буфер". Он не только задаёт приоритеты — что делать вперёд, но и заранее сигнализирует о том, что срок проекта под угрозой.
Хотите узнать о том, как работает диагональный буфер — подписывайтесь, расскажу в следующих заметках. Или можно загуглить)
P. S. Мой канал в телеграм с уведомлением о новых заметках и короткими заметками, которые я публикую только там (кстати, если вам совсем не терпится, то там можно найти ответ)
P. P.S. Мой YouTube канал про Теорию Ограничений и не только. Там есть пару стримов с Максимом Дорофеевым, скоро появятся новые)
P.P.P.S Я люблю сердечки, сердечки — это красиво, и они повышают настроение🥰
Диагональный буфер — это часть решения по управлению проектами в Теории Ограничений Голдратта (ТОС). Это только часть решения, части проблем. Решения не бывают хорошими или плохими вне контекста. Если вы не читали мою первую статью, то я рекомендую начать с неё. В ней я описываю проблему, которую решает диагональный буфер, время прочтения — шесть…
К слову сказать, Голдратт не то чтобы отказался от диаграммы Ганта, он просто сделал предложение по НЕБОЛЬШОЙ модификации в процессе управления рисками. Вы не поверите, но обычно критический путь работает не хуже, чем критическая цепь. Хотя критическая цепь несколько лучше. Но дело не в этом. И даже не в том, что сверху на все это можно навернуть более мощные инструменты.
Дело в том, что для использования всего этого счастью нужно обладать определённой базой знаний, навыков и понимания, которые бы позволяли делать проекты в заданный срок и бюджет. Вот этой базы у людей сейчас нет. Во времена Голдратта была, а сейчас это чуть ли не потерянное знание.
Что до самого ТОС, то в нем очень много иных полезных вещей. Одно «дерево» для поиска корневой проблемы чего стоит. Либо сам подход ТОС. Это вещи, которые нужны не только в проектном управлении, и они не так требовательны к базе человека. Возможно, лучше писать об этом? Аудитория будет шире.
Внедрение критической Цепи в голову 5 лет идет.
Внедрение ИСУП с реализацией CCPM умирает на фазе "я хочу жестко задавать светофоры" . Те кто внедрили у себя Цепь получили отличные результаты, но некоторым это уже не помогло. (поздно было)