Можно сказать, что я фанат мыслительных инструментов ТОС. Я не совсем одержима и не предлагаю использовать их по поводу и без. И всё же, мне кажется, даже просто наличие знания и понимания этих инструментов не может не изменить подход к анализу и принятию решений. Как я понимаю мыслительные процессы — это формализация мышления Голдратта. Того самого мышления, которое позволяло ему видеть ясно и чётко, игнорируя "так заведено".
Например, в проектном управлении был, и есть распространённый подход к планированию проекта — диаграмма Ганта. Всё больше команд отказывается от него в пользу гибких подходов. Частая причина отказа от жёсткого плана — в начале проекта мы не можем спланировать необходимый конечный результат. Голдратт тоже отказался от "Ганта", но по другой куда более распространённой причине.
В стандартном подходе есть понятие срока задачи. Сроки задач складываются в срок проекта. Для того чтобы успеть проект в срок, каждая задача должна быть выполнена в срок. Мы с вами знаем, что крайне мало проектов вокруг нас заканчивается в срок. Ну или в срок, но с превышением бюджета, или с урезанием содержания (спецификации) .
Можно было бы оправдать срывы сроков тем, что иногда мы ошибаемся при оценке, и ставим не реалистично маленький срок. Но тогда, мы должны были бы ожидать и обратную ситуацию. Часть (причём заметная) проектов должна была бы завершаться до окончания срока, но этого не происходит.
Тогда у нас есть другое оправдание — закон Мёрфи: "если что-нибудь может пойти не так — оно пойдёт не так". Но это тоже не слишком убедительное оправдание. Чаще всего проекты вокруг нас выполняются и планируются людьми, которые уже сталкивались с реальностью. Они в курсе и про Мёрфи, и про заказчиков, которые не читают ТЗ, и про исполнителей, которые любят уйти в перфекционизм, творческий кризис и другие способы прокрастинации. Исполнители тоже знают, что их будут дёргать на другие проекты и задачи, перекладывать на них косяки предыдущих этапов и штрафовать за срыв сроков.
При планировании не первого проекта, каждый, кто имеет доступ к планированию, старается заложить себе подстраховку. И исполнитель, и его тимлид, и их начальник, и владелец продукта, и CPO, а иногда даже продажник. Иногда рынок требует, и мы идём на крайне напряжённый срок. Но почему-то слишком часто, даже если у нас есть огромный запас подстраховок, проект всё равно не укладывается в изначальные обязательства. Либо мы увеличиваем срок, либо бюджет, либо урезаем содержание, либо все пашут в выходные и до ночи.
Почему так? Куда уходит время? У каждого исполнителя есть масса поводов не заканчивать раньше срока задачи, или даже закончить позже. Все мы сдавали сессию. До экзамена либо полно времени, либо одна ночь. Студенческий синдром никуда не уходит после завершения института. Так что мы все любим откладывать до последнего.
Если всё же его победить, то появляется закон Паркинсона — когда работа занимает всё отведённое для неё время. Иногда мы всё же заканчиваем работу раньше срока, но тогда в дело может вступать перфекционизм. Можно же сделать немного лучше, начать улучшать и в итоге не успеть в срок.
Иногда нас ещё и финансово «мотивируют» в зависимости от трудоёмкости задачи. В таком случае есть повод растянуть трудоёмкость. Даже если премию не сокращают в случае, если задача была выполнена быстрее, я всё равно не буду стремиться сдавать результат быстрее. Если регулярно сдавать задачи раньше срока — оценки трудоёмкости начнут урезать.
А ещё иногда мы и правда недооцениваем сложность задачи, или появляются новые вводные, а потом ещё и Мёрфи с чёрным лебедем. В итоге есть куча поводом сорвать срок задачи несмотря на заметный запас подстраховки. Если я выполню задачу со срывом срока, то следующий исполнитель с более высокой вероятностью сорвёт срок уже своей задачи.
А что произойдёт, если я, несмотря на всё описанное выше, выполню задачу раньше срока? Скорее всего — ничего. У следующего исполнителя и так есть запас подстраховки, он не планировал начинать раньше и у него есть чем заняться.
Получается, что выигрыш по времени не передаётся, а опоздания накапливаются. Как итог, несмотря на огромные запасы подстраховки — сроки проектов срываются. И о том, что проект уже невозможно выполнить вовремя, мы чаще всего узнаем близко к сроку завершения.
Что предложил сделать Голдратт? Если подстраховка в любом случае нужна, но мы её разбазариваем — значит нужно изменить правила использования подстраховки. Во-первых, подстраховка становится общей, и каждый берёт из общего котла столько, сколько ему необходимо. Во-вторых, больше нет сроков задач, есть срок проекта. А как тогда нам понять, успеваем мы или опаздываем? На этот вопрос отвечает инструмент под названием "диагональный буфер". Он не только задаёт приоритеты — что делать вперёд, но и заранее сигнализирует о том, что срок проекта под угрозой.
Хотите узнать о том, как работает диагональный буфер — подписывайтесь, расскажу в следующих заметках. Или можно загуглить)
P. S. Мой канал в телеграм с уведомлением о новых заметках и короткими заметками, которые я публикую только там (кстати, если вам совсем не терпится, то там можно найти ответ)
P. P.S. Мой YouTube канал про Теорию Ограничений и не только. Там есть пару стримов с Максимом Дорофеевым, скоро появятся новые)
P.P.P.S Я люблю сердечки, сердечки — это красиво, и они повышают настроение????
Комментарии (13)
nikolz
25.04.2023 03:07фобии для пиара.
Вы серьезно?
Будете пересказывать книжки тем, кому лень их читать?
AlexanderplUs
25.04.2023 03:07+4Для того чтобы успеть проект в срок, каждая задача должна быть выполнена в срок
Уже неверный посыл. Срок всего проекта определяется по критическому пути - наиболее длительной последовательности зависимых задач от начала до конца проекта. Затягивание остальных задач может не повлиять на общие сроки.
Так же и с причинами срыва сроков. Очень часто не учитываются как раз зависимости между задачами, что приводит к простоям на критическом пути. Ну и систематическое «оптимистическое планирование» производительности самих людей, когда берется за базу производительность, близкая к максимальной, вместо средней.
Tarnella
25.04.2023 03:07Ну так автор здесь описывает т.н. "стандартный подход" к управлению, которому как раз противопоставляется посыл статьи.
klimkinMD
25.04.2023 03:07+2Опять реклама :-(.
... диаграмма Ганта. Всё больше команд отказывается от него в пользу гибких подходов.
По моим наблюдениям (не претендующим на репрезентативность), отказ от Ганта обусловлен банальным: "ниасилил". Руководить кажется привлекательным и простым делом, а псевдоотмазка: "в начале проекта мы не можем спланировать необходимый конечный результат", так и вообще гениальное изобретение.
sshikov
25.04.2023 03:07Причем, заметьте — диаграмма Ганта это в том числе зависимости между задачами (по сути — вот это можно параллельно, а вот это только в таком порядке). Можно от нее отказываться, можно не отказываться, но зависимости эти есть почти всегда, и критический путь в результате тоже есть всегда. Вы можете неправильно оценить сроки, но вы вряд ли можете неправильно оценить зависимости — ну или тут всяко сильно сложнее ошибиться.
Tarnella
25.04.2023 03:07Гант хорош когда имеется набор относительно типовых задач 2-3 уровней подчиненности как максимум. Когда начинается чередование уровней и декомпозиция задач, кода рядом могут сосуществовать задачи типа "разработать протокол обмена через кафку" и ""настроить маршрутизацию через VPN между удаленными сетями" в рамках одного проекта, он становится неудобен.
quarus
25.04.2023 03:07Каждая задача - это деньги для исполнителя. Оцените задачу и отдайте исполнителю деньги по её завершению, тогда и сроки сократятся (время- деньги), но жадность не позволяет. Вот, и мучаются РП, которые не обладают реальными полномочиями...
Tarnella
25.04.2023 03:07+1Попробовал. Почитал следующую статейку про диагональный буфер. Потыкался в либре на произвольных данных. Понравилось. Поизучаю получше, есть ощущение что потенциал у подхода тот что надо.
Только непонятно с инструментарием, на какой платформе это можно реализовать на практике. Не в таблицах же. В крайнем случае можно намутить что-нибудь свое, как обычно.
Bryzgalova Автор
25.04.2023 03:07Для меня самое доступное - таблицы) но намутить свое тоже неплохо) для компании, у которой закупки были через заявки в JIRA (не спрашивайте почему так)) прямо там добавили рассчёт приоритета и буфера, и запрос оставшегося времени работы.
Tarnella
25.04.2023 03:07Я собственными глазами видел, как заказы покупателей и заказы на производство немаленького завода велись в редмайне а-ля ERP, причем на одном учетном уровне а иногда как одно целое, так что закупки через жиру не самое удивительное что бывает.
Ну раз специализированного софта нет, то оно и к лучшему. У большинства подобных изделий к сожалению либо функционал урезан, либо интерфейс чудовищен. Запилить под себя, тем более когда все первичные данные для построения уже есть и оперативно вводятся кодерами и проектменеджерами, не великая проблема.
Bryzgalova Автор
25.04.2023 03:07Из целевого есть программа a-dato, дважды использовала ее в КБ. Первый раз это было 10 лет назад за деньги, а вот пару лет назад ребята как-то качали себе бесплатную версию и оставались в ее ограничениях.
gkarapet
❤️
Bryzgalova Автор
????