Цель. Процесс непрерывного совершенствования.
Эту книгу Элияху Голдратта мне посоветовал бывший руководитель где-то год назад. Я начал читать и… бросил, увы. Дочитал относительно недавно и не смог на этом остановиться.
Голдратт - автор теории ограничений систем (Theory of Constraints, TOC), которую он и изложил в этой книге, представленной в формате бизнес-романа. Если очень вкратце, основная суть теории в том, что каждая сложная система состоит из взаимосвязанных элементов, и её общая пропускная способность ограничивается самым слабым элементом этой цепи. Поэтому для совершенствования результатов нет смысла распыляться на улучшение всего и сразу, а вместо этого лучше сфокусироваться на имеющемся ограничении и устранить его.
Но я сейчас не об этом, а о двух ключевых для себя инсайтах: 1) То, что теория описывается на примере завода, породило у меня цепочку мыслей, приведшей в итоге к пониманию, что в производстве на заводе и в IT довольно много общего, и все встало на свои места. Scrum, Kanban, Lean (и другие популярные в IT практики), TOC, производственная система Toyota - все это ветви одного дерева, корнем которого являются труды Эдвардса Деминга. Если кто-то читал его "Выход из кризиса" - делитесь впечатлениями, у меня она пока в TO DO. 2) В “Цели” для меня самое важное это всё же не сама TOC, а вопрос, которым главный герой задается в последних главах - как научиться мыслить так, чтобы находить лучшее решение в любой ситуации? Я давно для себя понял: главное, что отличает специалиста, рядового менеджера и C-level - это мышление. Свою версию автор изложил в книге “Выбор. Правила Голдратта”. Рекомендую прочитать сразу после “Цели”. P.S. Если читали “Цель 2” и “Цель 3” - дайте знать, может там тоже есть ответы. У меня пока они также в TO DO.
Открыт к дискуссиям. Буду рад обсудить эти книги или узнать, какие книги по управлению у вас в must read.
· 02.06
Я прочитал все "Цели" и Выбор и даже спец книгу Теория ограничений Голдрата от Уильяма Детмера.
По сути это методолгия системного анализа, причём далеко непопулярная.
Там где эту теорию активно применяли очень неохотно использовали базовые инструменты: деревья (тучи, дерево будущего и т.д.).
Этот метод очень сложен для восприятия и основан на проииворечиях и внутренних метаниях самого менеджера: что выбрать? Сроки или качество?
И почему-то всегда побеждают сроки, потому что построение всех деревеьев и поиск корневых причин — отнимает ещё больше времени.
Ты либо должен думать как Голдрат и его ученики, либо использовать соьственные подходы к системному анализу
Ведь системный анализ — это то, как работают наши мозги по умолчанию, по природе и переделать это очень сложно.
Лично мне проще составлять таблицу за и против и аргументировать с двух позиций: критик и генератор идей, причём критик всегда долден проиграть, но его роль в том, чтобы вывалить весь свой опыт, чтобы генератор идей пробил все препятствия.
Я нарисовал в своё время много туч и осознал: рисовал их ради рисования. Решения всё равно принимал на других основах.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 02.06
Большое спасибо за развернутый комментарий, очень ценно! У меня Детмер сейчас на начальной стадии чтения, так что про инструментарий поговорить пока не могу, поделюсь своим опытом позже. На текущий момент, после первой Цели и Выбора, сформировал для себя гипотезу о рациональности проектирования команды и процесса в IT таким образом, чтобы узким местом стало тестирование - выглядит, что это принесет ряд полезностей. Сбалансированные заводы то банкротятся =) Распишу отдельными постами у себя позже. А в целом, согласен, что будь ТОС панацеей, все бы по ней работали, а "в массы", во всяком случае в IT, пошли другие методологии. Но может получится, имея в багаже знания и опыт применения разных подходов, комбинировать их и формировать свой собственный.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 02.06
Безусловно, многоаспектность восприятия повышает когнитивные способности.
Немного призакрою окно 😁 У вас ошибка на текущем этапе в том, что первый шаг по ТОС — найти бутылочное горлышко, а не сделать его (я про тестирование, как узкле место).
2. Шаг — получить контроль над узким местом.
3. Шаг — расшить ограничения (если есть экономическая целесообразность.
4. Перейти на первый шаг.
Это и есть процесс непрерыного улучшения по ТОС.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 02.06
Да, как говорится, но. Я тут все ж не про явное применение ТОС. В "Цели" в главе про поход скаутов явно звучит вывод (или мне он показался явным) - лучше всего, когда узкое место расположено в конце системы. На заводе такое невозможно, а в IT вполне может получиться. Это повысит предсказуемость поставки, т.к. статистические колебания аналитики и разработки будут гаситься буфером перед тестированием. А избыточные мощности, которые должны появиться для создания этого буфера, можно потратить на лучшую проработку задач аналитикам и на рефакторинг, на которые всегда не хватает времени. А чтобы тестирование не завалило, вводим WIP-лимиты. Таким образом, чтобы в дальнейшем увеличить пропускную способность нашего ИТ-конвейера, нужно не просто "расшить" тестирование, наняв доп. человека или улучшив процессы (этим мы просто перенесем узкое место), а подумать о сохранении вот такого нарушенного баланса.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 02.06
кстати, вы, как человек с большим опытом в QA, можете увидеть бреши в этой теории? Есть что-то такое в тестировании, чем можно заниматься, при этом не увеличивая общее кол-во задач в работе команды? Кроме разве что бесконечного рефакторинга тестовой модели.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 02.06
Это всё верно, если у вас сейчас действительно тестирование - узкое место.
Но мне ваша ситуация неизвестна, поэтому могу ошибаться. Спасибо за дискуссию.
Но всё же ещё раз озвучу: вы не стейкхолдер и вам должно быть всё равно где находится ограничение системы и не нужно вести это ограничение куда-то, куда хочется. ТОС учит управлять ограничениями независимо от хотелок менеджера.
К сожалейнию, у всех окружающих меня менеджеров - их хотелки главная преграда на пути к эффективности.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 02.06
Я "директор завода", временно безработный =) Delivery manager - моя задача обеспечить максимальную эффективность производственного процесса в IT. Алексу Рого было все равно, где находится узкое место на его заводе? Нет. Затем, когда узким местом стал не завод, он пошел к маркетингу и сказал "дайте мне заказы". А затем стал руководителем всего предприятия. Неплохой карьерный трэк, мне нравится. Да, в общем смысле ТОС мои потуги могут вообще никак не сказаться на эффективности организации, потому что узкое место может быть вообще не в IT. Но с чем можем, с тем и работаем) ТОС учит управлять ограничениями - да. С точки зрения пропускной способности команды неважно где узкое место, оно так или иначе будет ограничивать всех и по ТОС мы должны с ним работать, пока не устраним. Но, как уже озвучил, избыточным мощностям в аналиткие или разработке проще найти полезное применение, не генеря при этом излишних "тмц".
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён