Возможно ли применять теорию ограничений Элияху Голдратта в разработке?

Question

[pixik]

Доброго времени!
Уважаемые менеджеры и просто хорошо организованные личности,
Знакомы ли вы с теорией ограничений Голдратта? Применяли ли вы ее в своих проектах? Есть ли какие то альтернативные теории, возможно более эффективные?
Имеет ли смысл применять данную теорию разработчику в своих проектах, где он единственный?
Всем спасибо!

Answer 1

[Алексей Уколов]

Возможно ли применять теорию ограничений Элияху Голдратта в разработке?

Вся третья книга про применение его теории в разработке. А вот запись семинара по теме.

Имеет ли смысл применять данную теорию разработчику в своих проектах, где он единственный?

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

Comments

[pixik]

А третья книга, это которая?)
Список книг из вики:
«Цель» (в соавторстве с Джеффом Коксом)
«Цель-2. Дело не в везении»
«Цель-3. Необходимо, но не достаточно»
«Критическая Цепь» — (ТОС для управления проектами)
«Синдром стога сена» — ТОС и внедрение ERP
«Я так и знал! Теория ограничений для розничной торговли» (в соавторстве с Айланом Эшколи и Джо Браунлир).
«Выбор», 2008

[Алексей Уколов]

Цель 3

[pixik]

Алексей Уколов:
| В ит-проектах, которые, как правило, уникальны и на конвеер не встают,...

Да, совершенно согласен, но можено ведь посмотреть на процесс разработки отдельного разработчика как на конвеер, в котором разработчик применяет различные утилиты для повышения продуктивности и какие-то навыки/методологии, с помощью которых ход разработки принципиально меняется.
После прочтения книги "Цель", я попробовал применить данный подход к себе, как к заводу/конвееру, в котором есть различные стадии работы с информацией и у каждой стадии есть свои пропускные ограничения. Я нашел несколько слабых звеньев (бутылочных горлышек) которые влияют на общий выхлоп всей системы (количество хорошо написанного кода, количество доведенных до конца проектов итп). Но после этого я задумался, а может быть я не правильно понял главную мысль автора и опошлил всю идею применив ее к "наболевшему"?

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

Так же, согласен. Думаю, введение данной методологии поможет немного изменить структуру общей системы (к чему бы это не было применено), и после того, как система войдет в устойчивое состояние, с помощью периодической сверки того "как оно работает" с тем "как должно работать", немного корректировать звенья системы. Т.е. основные затраты по времени идут в начале, а после, нужно только поддерживать состояние сложившейся системы.

[Алексей Уколов]

Но после этого я задумался, а может быть я не правильно понял главную мысль автора и опошлил всю идею применив ее к "наболевшему"?

Даже если и так - что в этом плохого? Главное, чтобы для вас польза была.