Практика TOC в проектном менеджменте

Доброе время суток господа и дамы.

У меня к Вам вопрос о применении TOC в управлении разработками программных продуктов.
Кто применял на практике или по крайней мере пытался применить метод критической цепи и упрвление буферами на свох проектах или знает случаи успешного применения в чужих проектах? Поделитесь опытом.
Меня терзают смутные сомнения в двух исходных предпосылках гуру Элияху о графике вероятности и выборе точки для оценки. Соответственно не вполне ясно как можно применить в реальности данные практики.

Если есть практики ТОС среди нас и они не против, то с удовольствием пообщаюсь лично.

Громандная просьба — придерживаться темы топика.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Громандная просьба — не обращать внимание на тролей вообще и на <reality_hacker> в частности и не превращать тему в холивар.
Люди не согласные с вами, которые вызывают у вас негативные эмоции, это не тролли.
Тролли это только те кто нарочно провоцирует.
95% из всех случаев, когда в интернете кого-то называют троллем, это не нарочная провокация, а просто когда одного человека раздражает мнение другого человека, от которого тот, другой человек не готов так просто отказаться.

Упоминания троллей в посте, и просьба на них не обращать внимание, это +50% к вероятности появления холливара, и +10% к вероятности появление негативных предубеждений у читающего в сторону автора темы, и +200% к вероятности привлечения к теме внимания настоящего тролля (хотя базовая вероятность очень низкая).

P.S. Жаль что администрация добавила возможность чистить темы автору. Не было бы по крайней мере бесполезной тонны мусорных сообщений.
А вы не думали, что ваш пост тоже входит в эту категорию, бесполезных мусорных сообщений?
Люди не согласные с вами, которые вызывают у вас негативные эмоции, это не тролли.
В данном случае человек сместил фокус с конкретного топика (Применение ТОС) на холиварную тему (Менеджеры бесполезны)
95% из всех случаев, когда в интернете кого-то называют троллем, это не нарочная провокация, а просто когда одного человека раздражает мнение другого человека, от которого тот, другой человек не готов так просто отказаться.
В данном случае меня не раздражает мнение этого человека. Как Вы могли увидеть, я ему практически не отвечаю. Меня больше инетерсует тема которую поднял я. Учить и менять парадигму на расстоянии — не форумный формат.
Но я не хочу, чтобы пост стал площадкой для холивара. Лучший способ — не отвечать тролю.
А вы не думали, что ваш пост тоже входит в эту категорию, бесполезных мусорных сообщений?
Если мой топик не будет интересен его проигнорируют и я не обижусь. Но я не начинаю холивар в соседних ветках форума на отвлеченные темы. Разница есть.
Если мой топик не будет интересен его проигнорируют и я не обижусь. Но я не начинаю холивар в соседних ветках форума на отвлеченные темы. Разница есть.
Разницы нету. Точно также вы можете проигнорировать не интересный вам комментарий. К тому же если он не интересен вам, это не означает что он не интересен всем другим людям. Вообще от человека желающего жить в свободном обществе, ожидается что он не будет призывать к удалению чужих комментариев, которые по его мнению являются лишними (мы же не говорим о спаме — массовой рассылке рекламных сообщений, или флуде — большом количестве одинаковых сообщений, или комментарий которые состоят только из оскорблений и ругательств). У человека есть свое мнение, и он хочет его высказать. Или вы сторонник цензуры и не свободного общества?
В данном случае меня не раздражает мнение этого человека. Как Вы могли увидеть, я ему практически не отвечаю.
Зачем же вы тогда называете его троллем? И вообще его упоминаете?
Лучший способ — не отвечать тролю.
Пока что у вас не получается это делать. Мало того вы ещё и использовали волшебное слово, несколько раз.
В данном случае человек сместил фокус с конкретного топика (Применение ТОС) на холиварную тему (Менеджеры бесполезны)
А почему вы считаете что тема «Применение ТОС», не холиварная? Если для большого количества людей эффективность ТОС — сомнительна, то можно ожидать соответствующей реакции с их стороны.
А если вы хотите слышать только мнение людей серьёзно занимающихся ТОС, тогда вам стоит поискать какой то специализированный (возможно закрытый) форум для последователей ТОС.

Это суть открытого форума для разработчиков — каждый разработчик может высказать свое мнение по поводу темы, и всего что с ней связано.

Вы так защищаете парня, что создается ощущение, что это Ваш второй ник на форуме. Но я, конечно могу ошибаться.

У человека есть свое мнение, и он хочет его высказать.
Да кто же ему мешает.
Он может открыть новый топик о бесполезности менеджеров и дискутировать сколько угодно.
Он даже может постить в другие, совершенно не относящиеся к полезности или бесполезности менеджеров топики и в мой в том числе. Но смысла в топике если посты в нем не в тему я не вижу.
Если парень не сознательный троль или не сознательный и ему так важно высказать свою мысль и обсудить ее, то лучшее средство новый топик.
Зачем же вы тогда называете его троллем? И вообще его упоминаете?
Принято.
Пока что у вас не получается это делать. Мало того вы ещё и использовали волшебное слово, несколько раз.
Если он и Вы одно лицо, тогда таки не получается. А волшебное слово — это не обращение к нему а характеристика постов.
А почему вы считаете что тема «Применение ТОС», не холиварная?
Какие проблемы? Но какое она имеет отношение к «теме» о бесполезности менеджеров.
Ну сказал бы человек — ТОС бесполезна, но речь-то зашла о другом.
Это суть открытого форума для разработчиков — каждый разработчик может высказать свое мнение по поводу темы, и всего что с ней связано.
Вы же понимаете, что такое оффтопик? ru.wikipedia.org/.../Сетевой_этикет
Вы так защищаете парня, что создается ощущение, что это Ваш второй ник на форуме. Но я, конечно могу ошибаться.
То-есть по вашему, один человек не может защищать другого, если они против вас, и у них нету реальной фотографии в профиле, или тем более реального имени? И если такое происходит, то скорее всего это тот же человек, под другим именем?
Это кстати хорошо сочетается с идей, что если человек пишет что-то, что вам не нравится, то он автоматически — тролль.
У меня на этом форуме нету других профилей, и прежде чем утверждать подобное, убедитесь что у вас достаточно доказательств, так как это не очень приятные обвинения.
Да кто же ему мешает.
Вы, вы называете людей троллями, и взываете к модераторам, что вам необходимо право удалять неугодные вам комментарии.
Но смысла в топике если посы в нем не в тему я не вижу.
Кто-то скрыл их от вас? Когда вы регистрируетесь на форуме, вам не даются гарантии, что абсолютно все сообщения которые вам придется читать — содержать полезную с вашей точки зрения и для вас информацию.
С той же точки зрения, я могу спросить — зачем этот форум, если большая часть тем — мне не интересна и бесполезна?
И это суть свободы слова в интернете, на форумах. Ну если вы против свободы слова, то можете высказать свое мнение администрации сайта, возможно они введут опцию удаления неугодных автору темы комментариев, ваше право.
Если он и вы одно лицо, тогда таки не получается.
Я, это не он. Но мы же не только о нем говорим, исходя из вашей классификации — я тоже тролль (я же пишу бесполезные оффтопик комментарии), а вы продолжаете со мной говорить.
Ну сказал бы человек — ТОС бесполезна, но речь то зашла о другом.
Возможно с его точки зрения, эти вещи взаимосвязаны.
Вы же понимаете, что такое оффтопик? ru.wikipedia.org/.../Сетевой_этикет

Во-первых:

Правила этикета не являются всеобщими и жестко установленными — в разных сообществах они могут значительно различаться

Во-вторых, граница между топиком и офф-топиком не четкая. С уверенностью сказать что комментарий является офф-топиком, только если в нем вообще не содержится ничего связанного с темой, и с тем что другие люди пишут в теме. Люди в обсуждениях часто затрагивают смежные темы. Даже то что вы написали в теме про троллей, можно считать что вы затронули ещё одну тему.

Вы, конечно, простите, что я отказываюсь продолжать этот трид, но мне он не интересен и мне жаль на это время.

У нас со всеми задачами отлично справляется KFC: facilityconcept.appspot.com/history.html, TOC не нужен, это какой то еще один способ оправдать существование менеджеров.

Пытаемся следовать правилам, используем соответствующий подход и фреймворки.

неправильно я вопрос задал) что разрабатываете я имел ввиду?
одно дело разрабатывать штучные продукты, другое дело командой внедренцев работать на 3-4 длительных проектах. подход к управлению разный будет

веб сайтег спешно разрабатываем.

KFC, вроде бы, совсем другие задачи решает, нежели TOC?

Дима, каждый смотрит на жизнь и необходимось того или другого со своей точки зрения.
Ну нет человеку необходимости в применении ТОС. Даже в менеджерах необходимости нет. Значит такой круг задач и интересов.

Про TOC и вопросов нет — сам слышал об этой методике только в теории. А вот насчет

Даже в менеджерах необходимости нет.

действительно интересно, где это может работать?

В Гильдии Серых Братьев :)

Даже в менеджерах необходимости нет.
действительно интересно, где это может работать?
Смотрел фильм office space и эпизод о том как собеседовали менеджера? И вот так же подавляющее большинство работает. И пытаются показать свою важность собирая безсмысленные митинги, делая ненужные питчи, навязывая странные процессы.

Тема необходимости менеджеров в среде программистов и вообще всех работников не управленческого состава — это всегда красная тряпка. И начинающие менеджеры быстро слетаются на такой холивар.
Но в данном топике это оффтопик :)

Тема необходимости менеджеров в среде программистов и вообще всех работников не управленческого состава — это всегда красная тряпка.
Почему, некоторым повезло, повыганяли нахлебником. Ну или существенно понизили в полномочиях и соответственно в компенсации, сведя обязанности до административных.
И начинающие менеджеры быстро слетаются на такой холивар.
Смотря на количество постов которое ты оставил в подветке, понятно что ты самоидентифицировался.

Толстый троль, такой троль :)

От, того что ты тут набрасываешь твои процессы нужнее не становятся, как и твоя роль погоняльщика в аутсорсе ближе к рокетсайнс.

Увы, не смотрел. Я и не спорю, менеджер, который только то и делает, что пытается доказать свою нужность, создавая видимость бурной деятельности — не нужен. С другой стороны, я видел ряд примеров, когда менеджер действительно был нужен и решал ряд задач, которые разработчикам решать, обычно, не свойственно и вряд ли они бы делали это более эффективно, чем он.

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

Пока своими глазами не увижу, не поверю.

Кому-то ж повезет с женой. Или не повезет :)

И это во времена когда скрум шагает по планете.

1. Далеко не везде, увы, шагает — фиксед прайс (вернее, fixed-all) проекты никуда не делись, а в них чистый Скрам неприменим.
2. Для того, чтобы Скрам работал «по книжке», команда должна быть зрелой не только в техническом, но и в моральном, что ли, плане. Самоорганизация, которую воспевают в аджайле, не случается сама по себе, более того, некоторые команды самоорганизоваться не могут в принципе из-за неподходящей для этого комбинации характеров. И вот в таких-то случаях и нужен ПМ как организующий и направляющий работу фактор.

1. Далеко не везде, увы, шагает — фиксед прайс (вернее, fixed-all) проекты никуда не делись, а в них чистый Скрам неприменим.
Та нет, вполне применим, с очень положительным качеством, в конце пути вместо «ничего» может получится «хоть что-то» что сильно повышает вероятность что заказчик раскошелится на экстрабюджет.
2. Для того, чтобы Скрам работал «по книжке», команда должна быть зрелой не только в техническом, но и в моральном, что ли, плане. Самоорганизация, которую воспевают в аджайле, не случается сама по себе, более того, некоторые команды самоорганизоваться не могут в принципе из-за неподходящей для этого комбинации характеров. И вот в таких-то случаях и нужен ПМ как организующий и направляющий работу фактор.
Ну вот мое мнение по этому поводу что менеджментом тасков должен заниматься тимлид, так как он намного ближе к телу, у него намного более адекватное представление о сроках и способностях людей.
Вообще сколько я не видел абстрактных проджект менеджеров, именно менеджить в программистских проектах у них получалось херово, они слишком оторваны от реалий, поэтому что-бы оправдать свое существование они перенимали функции individual contributors, кто-то тестил сам и ругал программеров за баги, кто-то писал доки, кто-то подрабатывал офис менеджером, а вот когда менеджер начинает внедрять процессы, которые модны в этом месяце, задалбывая программеров, это самый худший вариант.
Та нет, вполне применим, с очень положительным качеством, в конце пути вместо «ничего» может получится «хоть что-то»

Мы здесь точно не путаем Agile и итеративно-инкрементальную разработку (это не одно и то же)? Последняя в фиксед-прайсе действительно работает хорошо, а вот Agile — увы, нет, так как его философия «не планируй наперед» в условиях фикскед прайса с большой вероятностью приведет проект к краху.

что сильно повышает вероятность что заказчик раскошелится на экстрабюджет

Эмм... фиксед прайс на то и фиксед прайс, что не раскошелится. Поставщик юридически обязуется по контракту выкатить полный объем функционала за энную сумму. И если за эти деньги получится «хоть что-то», а не все, под чем исполнитель подписался, то остальное исполнитель тупо будет доделывать за свой счет.

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

Так именно тимлид, обычно, и занимается управлением на «тактическом уровне». ПМ больше отвечает за общий бюджет, контроль earned value, нередко выступает локальным product owner’ом, строит отношения с заказчиком. Другое дело, что на маленьком проекте роли тимлида и ПМа может выполнять один человек.

они перенимали функции individual contributors, кто-то тестил сам и ругал программеров за баги, кто-то писал доки, кто-то подрабатывал офис менеджером

Это были плохие, неправильные менеджеры :) Хотя... по поводу тестирования, иногда на проекте так «повезет» с тестировщиком, что нелишне будет и менеджеру еще раз все перепроверить перед релизом.

менеджер начинает внедрять процессы, которые модны в этом месяце

Если именно «модны в этом месяце», без понимания, чем они помогут команде — то опять же, это плохой, неправильный менеджер. Впрочем, если речь про Agile, продавцы скрама и прочего аджайла так основательно промыли всем мозг, что поначалу даже и не совсем уже зеленые менеджеры (включая вашего покорного слугу) на это купились.

Мы здесь точно не путаем Agile и итеративно-инкрементальную разработку (это не одно и то же)? Последняя в фиксед-прайсе действительно работает хорошо, а вот Agile — увы, нет, так как его философия «не планируй наперед» в условиях фикскед прайса с большой вероятностью приведет проект к краху.
Инкрементальная разработка — неотьемлемая часть аджайла. А «не планируй наперед» — такого нету. Есть адаптивное планирование, важная часть которого опять же инкрементальная разработка.
Эмм... фиксед прайс на то и фиксед прайс, что не раскошелится. Поставщик юридически обязуется по контракту выкатить полный объем функционала за энную сумму. И если за эти деньги получится «хоть что-то», а не все, под чем заказчик подписался, то остальное исполнитель тупо будет доделывать за свой счет.
Я видел много продолбаных по срокам проектов, но ни разу бе видел что бы кто-то с кем то судился. Вообще по моим наблюдениям stakeholders с обоих сторон всегда готовы к продолбаным срокам, имеют резервные бюджеты, но не показывают этого, т.к. за вовремя(или раньше) сданый проект получают бонусы, сравнимые с бюджетами на украинских кодеров.
М больше отвечает за общий бюджет, контроль earned value, нередко выступает локальным product owner’ом, строит отношения с заказчиком. Другое дело, что на маленьком проекте роли тимлида и ПМа может выполнять один человек.
Не сильно понимаю что ты имеешь в виду под earned value, но локальный product owner это individual contributor а не менеджер, часто бизнес аналитик или продакт менеджер(слово менеджер не значит что он менеджит), а про роль аниматора у клиентов опять отсылаю тебя к интевью в office space, посмотри, культовое кино.
Это были плохие, неправильные менеджеры :) Хотя... по поводу тестирования, иногда на проекте так «повезет» с тестировщиком, что нелишне будет и менеджеру еще раз все перепроверить перед релизом.
Я ж говорю, пока не увижу правильного, не поверю.
Если именно «модны в этом месяце», без понимания, чем они помогут команде — то опять же, это плохой, неправильный менеджер. Впрочем, если речь про Agile, продавцы скрама и прочего аджайла так основательно промыли всем мозг, что поначалу даже и не совсем уже зеленые менеджеры (включая вашего покорного слугу) на это купились.
Ну вот я уверен что ТС раньше продавал скрам, возможно если он давно в индустрии, то до этого был RUP и всякие сертификации, а сейчас вот новая фишка появилась.

ну ладно еще в нашей заблудшей стране. вот интересно в европах и америках(гуглах всяких) этим ТОСом пользуются?

Даже в нашей внедряют и отзывы хорошие публикуют (кто же плохие опубликует на сайтах консультантов :) ). Но вот в софтверной сфере еще не слышал.

когда работал в 2гис применяли эту теорию
порисовали схемки, таблички — нашли узкое место, перераспределили работу — стали успевать больше

А с буферами не работали? Изначальные эстимейты не урезали?

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

Некоторые да. И причем больше из тех, что описаны для потока (а не для проекта), насколько я понимаю.

Между серийным производством и разработкой таки есть существенная разница.

Конечно, именно поэтому, видимо, Голдрат и выпустил книгу «Критическая цепь», в которой описал приемы ТОС для проектной работы.

Понятие критической цепи — уже давным давно как часть PMBoK, иными словами — все те, у кого фиксед прайс проекты и (или) проекты с жесткими дедлайнами используют как минимум этот инструмент ТОС в своих проектах.

Чаще видел, что используют метод критического пути чем цепи. Понятно, что зависит от проекта.
Однако цепь это еще не все. Я никогда не видел привязки цепи к буферам, а без годратовского управления буферами цепь не будет работать настолько эффективно, насколько это описано в теории.
Вот мне и было интересно есть ли практика применения голдратовских буферов. Есть несколько базовых моментов, которые хотел бы уточнить.

Метод критического пути не учитывает ограничения по ресурсам, т.е после него еще делают левелинг (которая по сути и превращает критический путь в цепь). Поскольку мало кто парится на тему разницы между этими понятиями, полученную после левелинга структура и назвают критическим путем :-)

Насчет буферов, насколько помню, основная идея Голдрата состоит в том, что защищать буфером нужно только критическую цепь ?

Насчет буферов, насколько помню, основная идея Голдрата состоит в том, что защищать буфером нужно только критическую цепь ?
И это тоже. Есть буфер ресурсный и есть буфер цепи. Плюс буферизация в тех местах где некритическая ветка соединяется с критической.

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

Вы считаете, что именно ТОС не нужен? Поделитесь тогда своими соображениями. Особенно интересно будет узнать с точки зрения управления буферами и критической цепи.

Про буферы и критические цепи пока особо сказать не могу — надо прочесть матчасть сначала.
Меня сейчас как раз интересуют именно они.

Я встречал практики использования ТОС только в оптимизации процессов на производственных предприятиях и немного не розничной торговле, но в IT не встречал, как и не видел поля для его применения.

Голдрат написал «Критическую цепь» с точки зрения именно проектного менеджмента и даже мульти проектного. Предыдущие книги были действительно о производстве, маркетинге, дистрибуции.

При чем тут Теория Операционных систем к управлению разработкой ПО.

Предлагаю для прочтения «Критическая цепь» Голдрата. Это ответит на Ваш вопрос.
Книга небольшая, первый раз читается легко и не сильно нудно.

Могли бы просто ответить, что имеется в виду «Теория Ограничений Системы», а не отсылать к прочтению не нужной человеку литературы.

Ну почему не нужной? Литература очень даже интересная с общечеловеческой точки зрения. Одна грозовая туча чего стоит :)

TOC = Theory Of Constraints, ака Теория ограничений
ru.wikipedia.org/...рия_ограничений

Неужели у нас все так плохо с применением TOC? :)

Задай вопрос Андрею Колотову из Apple Consulting, возможно у него был опыт.

Спасибо за наводку. Спрошу.

Если будет интересно: в целом у Андрея не было опыта работы с софтверной отраслью.

Подписаться на комментарии