Отбирали только пидорков?

Переходили с пассивной агрессии на активную

Простите, тимлидский попугай прошел по клавиатуре

Такс, ребят, прочитал тут Цель Годрата, хочу обсудить.

Книга классная. Но с самого начала в процессе чтения в голове держался вопрос о границах применимости. У нас в IT у большинства всё же r&d, а не конвеерное производство. Покрутив в голове - не особо смог придумать, куда это применить.

Можно попробовать натянуть сову на глобус и решить, что выхлоп команды - это не деньги и продуктовые метрики, а фичи (хотя это резко противоречит самой идее книги). Но даже так - подчинение скорости разработки самому медленному узлу кажется не лучшей идеей для it - у нас нет издержек на хранение

Можно сказать, что основное, что для it надо вынести оттуда - это что «надо мерить метрики» и «оптимизируйте узкие места», но это звучит как-то слишком очевидно, чтоб ради этого целую книгу читать - можно было бы обойтись одной статейкой.

В то же время - постоянно вижу эту книгу в рекомендациях к прочтению лидами.

В общем, расскажите мне, чего я там не уловил (если это есть) и как это применять к it (если имеет смысл)

> у нас нет издержек на хранение

Несмерженные пулреквесты требуют ребейзов. Залитый мертвый код устаревает

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

Но всё же они как будто не столь сильно нас аффектят, как конвеер

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

Отказ от локальных показателей эффективности для меня тоже было инсайтом. Цель не занять всех работой, а обеспечить проток: сократить цикл производства (быть Agile)

Кажется, теория ограничений воплощается в Kanban. По применению его в it много материалов) Я с Kanban познакомился до прочтения книги, и меня повсюду преследовали инсайты "так вот как и почему оно работает".

Подожди, но цель ведь не в этом - цель заработать денег с пользователей) Если мы это можем сделать вообще без разработки - это же классно и можно разработку разогнать

С канбаном интересно, осмыслю этот момент

Все так

Идеальная система не существует, но выполняет свою функцию

Дальше в порядке убывания эффективности

И если уж приходится разрабатывать, то саамый минимум миниморум, да с самым простым процессом

С минимальными потерями

В общем, тут нет противоречия

согласен. Это кажется больше про Discovery: говоря контекстом из книги, взаимодействие с отделом макркетинга и участие в комерческих предложениях клиенту.
Если мы все же решили делать что-то, то кажется стоит сфокусироваться на заводе (Delivery)

Да тут вообще, подход сам

Делать только то, что нельзя не делать

Потому что делание увеличивает энтропию

И управленческую сложность и тп

Если так смотреть на разработку (от процессов до технологий) то становится очевидным, что если что-то и вводить/реализовывать, то только тогда, когда без этого нельзя обойтись (цена неделания выше неизбежных последствий негативных от делания)