Comments 97
Супер. Спасибо.
Очередной рационализаторский подход к иррациональному делу.
"Одной из причин выделения управления проектами в отдельную область знаний является неопределенность. То, как мы управляем неопределенностью в проекте (в том числе и рисками), напрямую влияет на длительность проекта, на его успех."
Вы прикалываетесь? По отдельности слова понятны, но предложения?
Управлять неопределенностью это очень, очень сильно.
Но за статью спасибо.
"Одной из причин выделения управления проектами в отдельную область знаний является неопределенность. То, как мы управляем неопределенностью в проекте (в том числе и рисками), напрямую влияет на длительность проекта, на его успех."
Вы прикалываетесь? По отдельности слова понятны, но предложения?
Управлять неопределенностью это очень, очень сильно.
Но за статью спасибо.
По-моему, гиблое дело применять такой аппарат при работе над ЛЮБЫМ проектом, не только в Сети. Люди - не константы, всегда (опять же по закону Мерфи) найдетс человек, который сдвинет все ваши диаграммы далеко за пределы буферов.
И знаете, что самое интересное? Все хотят найти серебрянную пулю, когда получают солью в зад.
Текст классный (Roman_Mix уже отъехал), много букаф - но читать и вникать - извините.
Мы используем такой подход уже 4й год и он вполне естественно оформился и живет. Только без графиков, формул и брутальной лексики а-ля "критические цепи".
Если интересно, как работаем мы - отпишитесь, попробую рассказать
И знаете, что самое интересное? Все хотят найти серебрянную пулю, когда получают солью в зад.
Текст классный (Roman_Mix уже отъехал), много букаф - но читать и вникать - извините.
Мы используем такой подход уже 4й год и он вполне естественно оформился и живет. Только без графиков, формул и брутальной лексики а-ля "критические цепи".
Если интересно, как работаем мы - отпишитесь, попробую рассказать
Для меня вполне понятно откуда у статьи растут ноги. Когда бизнес целиком завязан на успешную продажу проектов и последующего их выполнения в соответствии со сроками и бюджетом, то тем кто планирует очень важно совершенствоваться в составлении планов. То что могут быть люди которые съедают буфер совершенно не отменяет того факта что бывают хорошие планы, а бывают плохие планы.
Согласен. Попробую расширить и подытожить.
Планы - планами. Замечательные такие планы - но результат зависит на 80% от исполнителей этого плана. Его не только составить-нарисовать надо, его надо соблюсти, потестировать систему, промотивировать исполнителей, утирая попутно сопли заказчику.
В ракурсе проблемы разработки софта полезнее делать упор на личные качества исполнителей и методов разработки, потому как составляет план менеджер, который знает возможности и особенности исполнителей, занет бюджет и техническую базу.
Ну а рассматривать все это в комплексе - тянет на кандидатскую.
Автору поста - еще раз спасибо от ожившей аудитории)
Планы - планами. Замечательные такие планы - но результат зависит на 80% от исполнителей этого плана. Его не только составить-нарисовать надо, его надо соблюсти, потестировать систему, промотивировать исполнителей, утирая попутно сопли заказчику.
В ракурсе проблемы разработки софта полезнее делать упор на личные качества исполнителей и методов разработки, потому как составляет план менеджер, который знает возможности и особенности исполнителей, занет бюджет и техническую базу.
Ну а рассматривать все это в комплексе - тянет на кандидатскую.
Автору поста - еще раз спасибо от ожившей аудитории)
На своем опыте скажу что с хорошими исполнителями и плохими планами намного сложнее чем с хорошими исполнителями и с хорошими планами.
Это было просто замечание по жизни, а не какое-либо возражение )
Никто не говорит, что планы и их дальновидное составление с использованием различных техник (как, например, этой) может навредить)
Обеспечить качество и сроки - стремится выжать 100% из имеющихся исходных данных и ресурсов. И я даже погорячился насчет 20% успеха, которые выделил на грамотный план - в некоторых проектах он тянет на все 50%.
Обеспечить качество и сроки - стремится выжать 100% из имеющихся исходных данных и ресурсов. И я даже погорячился насчет 20% успеха, которые выделил на грамотный план - в некоторых проектах он тянет на все 50%.
Отписываюсь, расскажите, пожалуйста.
Я управляю своими проектами исключительно "по наитию", без специального образования, подобных заумных статей и "брутальных терминов". Возможно, все эти вещи применимы для управления проектами запуска освоения новых нефтяных источников, но для разработки в вебе это чересчур.
Однако, мне всегда интересен конкретный опыт занятых в той же области, что и я.
Я управляю своими проектами исключительно "по наитию", без специального образования, подобных заумных статей и "брутальных терминов". Возможно, все эти вещи применимы для управления проектами запуска освоения новых нефтяных источников, но для разработки в вебе это чересчур.
Однако, мне всегда интересен конкретный опыт занятых в той же области, что и я.
Кратко: есть deadline, установленный по утвержденному с заказчиком плану. За 2-3 суток до deadline'а ставится внутренний redline. Итерация этапа (milestone - мы этим словом пользуемся) оканчивается к redline'у - у нас появляется буфер для тестирования, исправления багов.
В этот буфер часть участников плотно общается с QA, фиксит баги (удается за этот буфер найти и обезвредить процентов 80%-90%).
Вторая половина (lead и его свита - скажем так) идет дальше и начинает следующую итерацию.
1. Выкатываем заказчику на deadline с svn'а ту версию, которая должна быть по milestone'у
2. Играем на опережение - буфер может расти к концу проекта, может быть потрачен на задачи, на которые время было рассчитано неверно (менеджер с каждым разом все точнее бьет в цель).
Естественно, заказчик и менеджер также должны утверждать следующий milestone минимум за несколько дней до deadline'а.
Думаю, порядок ясен))
В этот буфер часть участников плотно общается с QA, фиксит баги (удается за этот буфер найти и обезвредить процентов 80%-90%).
Вторая половина (lead и его свита - скажем так) идет дальше и начинает следующую итерацию.
1. Выкатываем заказчику на deadline с svn'а ту версию, которая должна быть по milestone'у
2. Играем на опережение - буфер может расти к концу проекта, может быть потрачен на задачи, на которые время было рассчитано неверно (менеджер с каждым разом все точнее бьет в цель).
Естественно, заказчик и менеджер также должны утверждать следующий milestone минимум за несколько дней до deadline'а.
Думаю, порядок ясен))
Ну понятно, это вполне стандартная схема. Еще раз убеждаюсь, что данный пост предназначен для других задач, вроде "моделирования стохастических процессов в бизнесе"
Ну а мы по старинке :)
Ну а мы по старинке :)
UFO just landed and posted this here
Согласен, когда уровни моих разработок и проектов уткнутся в подобную необходимость, я достану этот пост из избранного )
Лучше пусть всю жизнь пылится в избранном, если это для людей. Ибо такой подход (я его прочитал наконец-то) это вообще что-то с чем-то.
Коллеги, это клиника, претендующая на уникальность. Нарисовать нормальное распределение, немножко его ужать справа (график разъ) и радостно заявить о буфере безопасности. Н-да. Ладно, закон Паретто автор не читал, ладно он не смотрел как работают люди, ладно он сам никогда не пытался организовать работу людей. Но, блин, хотя бы подумать больше 15 минут можно? Потому что тогда придет в голову простая и незатейливая мысль, что в реальном мире очень мало линейной работы, выполняемой человеками, что работа команды зависит от действий каждого члена этой команды, часто без результата, полученного одним человеком, другой работать не начнет. Где это все в вышепредлагаемой схеме? Где синхронизация отедлов? Где, наконец, потери от организационной структуры? Где непрямые издержки? Где трансакционные издержки?
Коллеги, это клиника, претендующая на уникальность. Нарисовать нормальное распределение, немножко его ужать справа (график разъ) и радостно заявить о буфере безопасности. Н-да. Ладно, закон Паретто автор не читал, ладно он не смотрел как работают люди, ладно он сам никогда не пытался организовать работу людей. Но, блин, хотя бы подумать больше 15 минут можно? Потому что тогда придет в голову простая и незатейливая мысль, что в реальном мире очень мало линейной работы, выполняемой человеками, что работа команды зависит от действий каждого члена этой команды, часто без результата, полученного одним человеком, другой работать не начнет. Где это все в вышепредлагаемой схеме? Где синхронизация отедлов? Где, наконец, потери от организационной структуры? Где непрямые издержки? Где трансакционные издержки?
Всё правильно говорите. И автор поста прав по-своему.
Как разживусь кармой, напишу в этот блог пост об управлении проектами с ЧЕЛОВЕЧЕСКОЙ точки зрения, где ни один из этих законов работать не будет, но при этом, с данным вопросом сталкиваются гораздо чаще, причем на проектах любого уровня.
Как разживусь кармой, напишу в этот блог пост об управлении проектами с ЧЕЛОВЕЧЕСКОЙ точки зрения, где ни один из этих законов работать не будет, но при этом, с данным вопросом сталкиваются гораздо чаще, причем на проектах любого уровня.
UFO just landed and posted this here
В соответствии с PMBOK есть организации у которых образ действия операционный, а есть проектный. Насколько я понял по Вашим статьям у вас больше операционный образ действия, когда надо делать какую-то работу, а не то что называется проектом.
Про зависимости между задачами в этом статье не забывается. На счет остальных издержек мне не совсем понятно. Если есть риски связанные с тем что синхронизация отделов повлияет на сроки сдачи проекта, то с ними надо поступать как с обычными рисками, т.е. продавать, обходить, и т.д.
Другие издержки менеджеру проекта обычно не очень интересны, это больше к тем кто управляет финансами и портфелем проектов.
Про зависимости между задачами в этом статье не забывается. На счет остальных издержек мне не совсем понятно. Если есть риски связанные с тем что синхронизация отделов повлияет на сроки сдачи проекта, то с ними надо поступать как с обычными рисками, т.е. продавать, обходить, и т.д.
Другие издержки менеджеру проекта обычно не очень интересны, это больше к тем кто управляет финансами и портфелем проектов.
Вот она и проблема: другие издержки никому не интересны. Вместе с этим, именно другие издержки и влияют на дело в целом. Простенький пример: вашим сотрудникам надо работать через интернет, но сеть не то чтобы лежит, она валяется. Вместе с этим, вам надо, чтобы приходили и письма, которые кто-нибудь фильтровал. Админ один. Что ему делать? Пример простенький, но вполне в схемку не впимсывающийся.
Ок. Вот второй пример: у вас есть 10 программеров, которым в течение месяца надо сделать сайт. Один пишет безопасность, второй пытается оптимизировать запросы к БД, третий разрабатывает ЦМС. Вопрос: как хотя бы этих трех синхронизировать? Запланировать, что безопасность следует написать к 10 числу, а ЦМС к 13. Дык, тут такое количество проблем вылезет, что решать их все равно придется в режиме дедлайна.
Ок. Вот второй пример: у вас есть 10 программеров, которым в течение месяца надо сделать сайт. Один пишет безопасность, второй пытается оптимизировать запросы к БД, третий разрабатывает ЦМС. Вопрос: как хотя бы этих трех синхронизировать? Запланировать, что безопасность следует написать к 10 числу, а ЦМС к 13. Дык, тут такое количество проблем вылезет, что решать их все равно придется в режиме дедлайна.
Ну управление проектом и организация эффективного бизнеса разные вещи. В идеале компания должна предоставить среду для менеджера проектов, чтобы оне не думал про эти вещи, а работал в своем "проектном" мирке подключая ресурсы компании (исполнителей, сисадминов, юристов, и т.д.) когда необходимо. Эта задача уровня выше, чем выполнение какого-то конкретного проекта в срок.
Насчет второго примера: ну уж извините :) Это и есть планирование. Планирование задач может в часности осуществлятся на основе архитектурной декомпозиции, когда есть на высоком уровне понимание как задачи соотносятся между собой. Нужно закладывать время на интеграцию, нужно выделять задачи и готовить архитектуру таким образом, чтобы минимизировать издержки на коммуникацию, использовать технику непрерывной интеграции, и т.д.
Вообще если задача изначальна поставлена так что в течении месяца десяти программистам надо сделать сайт - это плохой сетап. Хороший сетап - когда ПМ получает хорошо оформленные требования (от заказчика, продукт менеджера, и т.д.), делает свою оценку по ним и отвечает за реализацию продукта на основе этих требований в рамках бюджета и в срок.
Насчет второго примера: ну уж извините :) Это и есть планирование. Планирование задач может в часности осуществлятся на основе архитектурной декомпозиции, когда есть на высоком уровне понимание как задачи соотносятся между собой. Нужно закладывать время на интеграцию, нужно выделять задачи и готовить архитектуру таким образом, чтобы минимизировать издержки на коммуникацию, использовать технику непрерывной интеграции, и т.д.
Вообще если задача изначальна поставлена так что в течении месяца десяти программистам надо сделать сайт - это плохой сетап. Хороший сетап - когда ПМ получает хорошо оформленные требования (от заказчика, продукт менеджера, и т.д.), делает свою оценку по ним и отвечает за реализацию продукта на основе этих требований в рамках бюджета и в срок.
А если идеала не ссуществует?
А если задача стоит такая, какая она есть?
А если кроме нужно время для... еще и работать пытаться мотивировать сотрудников? Понимаете, я вовсе не против каких-то подходов. Просто они настолько смешны, что я не могу удержаться от иронии. :)
А если задача стоит такая, какая она есть?
А если кроме нужно время для... еще и работать пытаться мотивировать сотрудников? Понимаете, я вовсе не против каких-то подходов. Просто они настолько смешны, что я не могу удержаться от иронии. :)
Ну такие эвристики из статьи больше подоходят для организаций типа где мне приходится работать. Вот случае когда на вход получаешь требования и нужно сказать когда будет готов результат и сколько это будет стоить, после чего нужно сделать по этой оценке.
Когда задача ставится таким образом, что надо успеть за месяц, то фактически никто за нее не отвечает. Что если задачу в принципе нельзя сделать за месяц? Кто согласился что сделает ее за месяц? Кто виноват если через месяц нет сайта?
Когда задача ставится таким образом, что надо успеть за месяц, то фактически никто за нее не отвечает. Что если задачу в принципе нельзя сделать за месяц? Кто согласился что сделает ее за месяц? Кто виноват если через месяц нет сайта?
Типа: "Нам тут думать некогда, работать нужно. Все же ж сложно и непонятно, задачу фиг поймешь, сотрудников мотивировать, президент новый, а вы со своими рисками и методологиями лезете."
Сформулируйте свое понимание риска и свое понимание неопределенности. Я настаиваю на том, что неопределнность не может быть управляема. Можно выработать набор мер, направленных на компенсацию возможных отрицательных последствий неопределенности. К примеру, елси вы не уверены, что ваши сотрудники сделают проект через месяц, то можно заложить, что к 15 числу нужно сделать 70% проекта. Если к 15 числу 70% проекта сделано не будет, то к 17 надо быть способным найти людей, которые подтянут проект к 20 числу до этих 70%. Тут я соглашусь (со значительными оговорками). Тем не менее, все пишут о каком-то буфере. Отсюда я и делаю вывод, что подобные интеллектуальные извраты вещь очень интересная, значимая, но неприменимая на практике.
Риск вида "проект не будет сделан вовремя" обычно слишком выского уровня, чтобы с ним можно было иметь дела менеджеру проекта (хотя данная статья призвана помочь уменьшить вероятность именно такого риска). Это скорее риск для бизнеса заказывающего проект. Вообще нужно разделять эти роли, у бизнеса и у проекта могут быть противоположные интересы )
Лично я имею в виду стандартные определения, которые можно например на википедии найти. http://en.wikipedia.org/wiki/Uncertainty, http://en.wikipedia.org/wiki/Risk_manage…
Лично я имею в виду стандартные определения, которые можно например на википедии найти. http://en.wikipedia.org/wiki/Uncertainty, http://en.wikipedia.org/wiki/Risk_manage…
См. ссылки на википедию.
Пример управления неопределенностью: мы не знаем, какая из технологий (А, Б, В) лучше подойдет нам для реализации проекта. Соответственно, не знаем каких лучше подбирать специалистов и сколько займет проект.
Поэтому мы сначала тратим часть времени на исследования и возможно POC, после чего неопределенность в вопросе наиболее подоходящей технологии исчезает.
(Остается только риск, что мы ее неправильно выбрали :)
Пример управления неопределенностью: мы не знаем, какая из технологий (А, Б, В) лучше подойдет нам для реализации проекта. Соответственно, не знаем каких лучше подбирать специалистов и сколько займет проект.
Поэтому мы сначала тратим часть времени на исследования и возможно POC, после чего неопределенность в вопросе наиболее подоходящей технологии исчезает.
(Остается только риск, что мы ее неправильно выбрали :)
Ну вот, видите вы уже признали, что кроме существования полубредовых РМВОК есть еще интересные вещи. То, о чем вы говорите является обычной задачей на оптиум управления с минимизацией рисков. Читайте внимательнее: минимазация рисков, но уж никак не управление ими.
Минимизация - это одна из стратигий в управлении рисками.
Хм, я бы даже сказал, что они все исходят из этого утверждения. В общем, подводя итог вышесказнному: стратегия может быть одна основанная на математическом подходе и после прочтения учебника по теории вероятностей. А вышеназванный подход это попытка объяснить ребенку, откуда появляются дети. Сделать в принципе можно, только стыдно.
Да нет, стратегий может быть несколько. Например идеально (и иногда получается) когда риск продается. Например, если стороней библиотекой поддерживается функционал, то время решения нашей задачи - 1 день, если не поддерживается - то 2 недели чтобы написать с нуля. Если изначально заложить в план 2 недели и заказчик соглашается - то можно считать что риск продан.
Ну задача-то не только в том, чтобы написать. И то в примере с библиотекой можно за уши притянуть то, что риск минимизируется, поскольку перекладывается на других людей. Проблема в том, что это и не риск в полном смысле. Вот если вы работаете, а главный архитектор заболевает, вот тогда это риск. :)
Если кратко, то выглядит это так: в дедлайн делается 80% нужной работе. Во время до дедлайна делается 20%. Гениально, коллега.
Озвучьте размеры ваших проектов в трудозатратах.
Все в порядке, так и делайте дальше. Должен же кто-то выполнять роль тех, на чьих ошибках остальные учатся.
"гиблое дело применять такой аппарат при работе над ЛЮБЫМ проектом, не только в Сети. Люди - не константы, всегда (опять же по закону Мерфи) найдетс человек, который сдвинет все ваши диаграммы далеко за пределы буферов"
Поздравляю - Вы только что объявили бессмысленными любые попытки управлять чем-либо, связанным с людьми. Ну да, люди же - не константы. Нахуя мне управлять космическим кораблем, если в ней человек? Он же сейчас там все тумблеры с дури понажимает, и все взорвется!!!
Кстати, процесс о котором Вы говорите ниже - самый обычный процесс, адаптированный для конкретно _Вашей_ команды и _Вашего_ типа проектов, и он, несмотря на все рассуждения про "гиблое дело, ..." и т.д. - вполне реально помогает Вам здесь и сейчас бороться с неопределенностью и рисками.
Поздравляю - Вы только что объявили бессмысленными любые попытки управлять чем-либо, связанным с людьми. Ну да, люди же - не константы. Нахуя мне управлять космическим кораблем, если в ней человек? Он же сейчас там все тумблеры с дури понажимает, и все взорвется!!!
Кстати, процесс о котором Вы говорите ниже - самый обычный процесс, адаптированный для конкретно _Вашей_ команды и _Вашего_ типа проектов, и он, несмотря на все рассуждения про "гиблое дело, ..." и т.д. - вполне реально помогает Вам здесь и сейчас бороться с неопределенностью и рисками.
Ну если говорят об управление рисками, то почему бы не говорить об управлении неопределенностью.
потому что никто ими не управляет. Ни риском, ни неопределенностью. Управляемая неопределенность это миф. Это такой бред, который даже с элементарной логикой не дружит.
Все менеджеры/архитекторы проектов так или иначе управляют рисками, или инстинктивно или по какому-нибудь учебнику.
Ну неужели не понятно, что это логический бред? Управление рисками. Еще больший бред это управление неопределенностью (риск является ее частью). Бред потому, что неопределенность неопределена, а вот управление вполне себе определено. Хотя бы по наличию объекта управления.
Управление рисками это тоже самое, что управление машиной без тормозов с завязанными глазами, без рук и под советы 4 окружающих вас блондинок. В данной ситуации поведение водителя может быть в принципе любым, результат может быть тоже любым, но вот зависимость от поведения водителя и результата будет весьма сомнительным.
Управление рисками это тоже самое, что управление машиной без тормозов с завязанными глазами, без рук и под советы 4 окружающих вас блондинок. В данной ситуации поведение водителя может быть в принципе любым, результат может быть тоже любым, но вот зависимость от поведения водителя и результата будет весьма сомнительным.
Чапек К. "Двенадцать приемов литературной полемики"
11. Impossibile (здесь: нельзя допускать — лат.) . Не допускать, чтобы противник хоть в чем-нибудь оказался прав. Стоит признать за ним хоть крупицу ума и истины — проиграна вся полемика. Если иную фразу нельзя опровергнуть, всегда еще остается возможность сказать: "Господин Икс берется меня поучать...", или "Господин Икс оперирует такими плоскими и давно известными истинами, как его "открытие...", или "Дивись весь мир! Слепая курица нашла зерно и теперь кудахчет, что...". Словом, всегда что-нибудь да найдется, не так ли?
11. Impossibile (здесь: нельзя допускать — лат.) . Не допускать, чтобы противник хоть в чем-нибудь оказался прав. Стоит признать за ним хоть крупицу ума и истины — проиграна вся полемика. Если иную фразу нельзя опровергнуть, всегда еще остается возможность сказать: "Господин Икс берется меня поучать...", или "Господин Икс оперирует такими плоскими и давно известными истинами, как его "открытие...", или "Дивись весь мир! Слепая курица нашла зерно и теперь кудахчет, что...". Словом, всегда что-нибудь да найдется, не так ли?
Почему бред? Под управлением рисками подразумевается вполне конкретный набор работ. Если минимально, то перед подготовкой плана проекта можно иметь список рисков и понимать что какие-то риски в случае их возникновения включены в план,а какие-то нет. Бывают конечно самые общие риски - вроде задача была недооценена, заняла больше времени чем предполагалась, и т.д. В данной статье как раз описано как минимизировать ущебр от этих рисков по проекту в целом. Бывают совершенно конкретные риски, которых ближе к концу проекта становится все меньше и меньше.
Вообще считается что уровень неопределенности к началу проекта высок, а к концу проекта низок. Когда неопределенностью управляют - это значит что у менеджера есть понимание того как именно она уменьшается )
Вообще считается что уровень неопределенности к началу проекта высок, а к концу проекта низок. Когда неопределенностью управляют - это значит что у менеджера есть понимание того как именно она уменьшается )
Для управления неопределенностью нужен объект управления. В условиях неопределенности определить объект нельзя. Если проводятся какие-то мероприятия, которые проводят все или которые логичны, это просто означает, что управление неопределенностью пытаются осущствить при помощи шаманских плясок. :) Я не уверен, что это не эффективно, я также сомневаюсь и в эффективности.
Примеры неопределенностей:
- через неделю становится понятно ложится ли человек в больницу на месяц или нет
- является ли third party код достаточно стабильных для использования в данном проекте
- интеграция с продуктом заказчика может занять неопределенное время.
Можно забить на все и действовать по ходу дела, действовать по наитию, а можно вести какую-нибудь формальную дейтельность вокруг этого как советуют светлые умы. Например, начинать попросить передать наиболее критичные знания другому разработчику, провести предварительное тестирование библиотеки, продать больше времени на интеграцию заказчику.
Я уверен что когда какие-нибудь крупные компании аутсорят проекты каким-нибудь крупным исполнителям риск мэнеджмент будет достаточно формальным, чтобы обе стороны знали что происходят с теми рисками которые известны и не вылезают ли какие-нибудь новые.
- через неделю становится понятно ложится ли человек в больницу на месяц или нет
- является ли third party код достаточно стабильных для использования в данном проекте
- интеграция с продуктом заказчика может занять неопределенное время.
Можно забить на все и действовать по ходу дела, действовать по наитию, а можно вести какую-нибудь формальную дейтельность вокруг этого как советуют светлые умы. Например, начинать попросить передать наиболее критичные знания другому разработчику, провести предварительное тестирование библиотеки, продать больше времени на интеграцию заказчику.
Я уверен что когда какие-нибудь крупные компании аутсорят проекты каким-нибудь крупным исполнителям риск мэнеджмент будет достаточно формальным, чтобы обе стороны знали что происходят с теми рисками которые известны и не вылезают ли какие-нибудь новые.
Давайте будем спорить о вкусе устриц с теми, кто их ел :)
Неблагодарное дело - учить нубов жизни, особенно если учиться они не собираются.
Пусть товарищ снизойдет с высоты своей кармы и для начала ознакомится с PMBOK или хотя бы с вводной информацией по управлению рисками. После этого может быть хоть какой-то разговор, так - трата времени...
Неблагодарное дело - учить нубов жизни, особенно если учиться они не собираются.
Пусть товарищ снизойдет с высоты своей кармы и для начала ознакомится с PMBOK или хотя бы с вводной информацией по управлению рисками. После этого может быть хоть какой-то разговор, так - трата времени...
Наверное и про управление рисками на храбре будут посты :)
Ну, сдается мне, что это мне. Ок. Объясняю специалистам по РМВОК и прочих страшных слов. Задача, описываемая вами, требует типично математического подхода. В кратце необходимо найти оптиум управления по многомерным вариациям (если вы с высоты своего интеллекта способны понять о чем я). После чего можно извратиться и начать описывать при помощи тензоров (хе-хе), а возможность смены состояния системы (ляжет не ляжет в больничку) дивергенцией тензора по времени. После чего можно забацать модель, основанную на нечеткой логике +/- другие извраты. А в моделке предусмотреть возможность ввода неверных данных (вы понимаете, что это значит?). На основе всего этого построить соответствующую модель. Вот такую модель я согласен обсудить, ибо интересно мне это.
Где вы взяли неопределенность? Вы работаете в системе, параметры которой определены (ляжет не ляжет это не неопределенность). Неопределенностью можно назвать следующее: кто ляжет, когда ляжет, ляжет ли или что-то другое (останется дома и работать не сможет)? То, о чем вы говорите, подчиняется обычной простенькой задачкой, в которой следует искать оптиум управления по многомерным вариациям (в общем случае). И просто с некоторыми неопределенными параметрами в вашем примере. Вопрос, это что так сложно? Если бы автор не пытался совокупить теорию вероятностей с наукой принятия правильных решений в гуманитарном ее понимании, он бы действительно занимался управлением.
является задачкой. Ивзините.
Любую неопределенность можно как-то определить что с ней можно работать. Если неопределенности возникают постоянно и неожиданно как на поле боя - ну значит такая среда, где важнее оперативное принятие решений. Думаю под управлением можно понимать такие неопределенности которые можно идентифицировать заблаговременно, и как-то с ними работать.
Давайте конкретный пример. Потому чвто определить можно все, но будет ли это соответствовать действительности?
Лучше вы дайте пример определенности, с которой нельзя работать. Как только формируется описание неопределенности, так сразу придут на ум стратегии как можно с ней поступить, или как лучше разбить эту неопределенность на вероятные исходы. Высокоуровневые неопределенности вроде "проект не будет выполнен в срок" лучше не рассматривать.
Важно понимать что, что успех проекта может зависит от того или иного развития событий в рамках описанной неопределенности.
Важно понимать что, что успех проекта может зависит от того или иного развития событий в рамках описанной неопределенности.
Неопределенность проявляется и в том, чтобы нельзя было ее определить. ;)
Так вот, простая задача: обеспечить получение прибыли в заданном размере через 2 месяца. неопределенность тут во всем. :)
Так вот, простая задача: обеспечить получение прибыли в заданном размере через 2 месяца. неопределенность тут во всем. :)
суть понятна. какие программные продукты из популярных и доступных с этим работают? можно привести небольшой пример, скажем, для процесса разработки сайта или пуска сервиса?
кто автор? олег клименко это вы? несколько непонятна последняя фраза. кросспост не особо радует, а если это вы и есть так и пишите
статья идеальна с точки зрения оформления. гранд респект
кто автор? олег клименко это вы? несколько непонятна последняя фраза. кросспост не особо радует, а если это вы и есть так и пишите
статья идеальна с точки зрения оформления. гранд респект
Спасибо за статью.
По Стивену Кови, с которым авторы, безусловно, перекликаются, наибольшая часть работы выполняется когда цель важна, но не критична по времени. Задача менеджера, соответственно, регулировать эти два параметра, мотивировать и не создавать авралов, если упрощенно.
По этому методу оба параметра в описанном методе и правда регулируются, т.к. единовременно задача всегда одна, следовательно, важность единственной задачи заведомо выше ее же в числе многих, и есть заранее запланированный запас (буфер) времени.
Но подача уж слишком мудреная. На основе тех здравых мыслей, коих в статье много, можно сделать схему проще, или эту проще описать.
По Стивену Кови, с которым авторы, безусловно, перекликаются, наибольшая часть работы выполняется когда цель важна, но не критична по времени. Задача менеджера, соответственно, регулировать эти два параметра, мотивировать и не создавать авралов, если упрощенно.
По этому методу оба параметра в описанном методе и правда регулируются, т.к. единовременно задача всегда одна, следовательно, важность единственной задачи заведомо выше ее же в числе многих, и есть заранее запланированный запас (буфер) времени.
Но подача уж слишком мудреная. На основе тех здравых мыслей, коих в статье много, можно сделать схему проще, или эту проще описать.
Вот многие основываются на milestone'ах диаграмм Гантта - но ведь в каждый из них входит несколько задач!
Мне больше импонирует подход с короткими итерациями, который используется в XP. Тут задача всегда единственна и максимально изолированная. Сел, сделал, прогнал тесты, пошел дальше. Не зацикливаешься. Согласны?
Мне больше импонирует подход с короткими итерациями, который используется в XP. Тут задача всегда единственна и максимально изолированная. Сел, сделал, прогнал тесты, пошел дальше. Не зацикливаешься. Согласны?
Сейчас занимаюсь моделированием стохастических процессов в бизнесе. Очень хорошо если бы менеджеры по управлению проектами включали недетерминированость сроков и ресурсов в свои планы. За статью плюс.
Прекраный материал, нечасто тут встречается. (А Голдрат не "Элияху" случаем? я видел такой вариант перевода в бумажной литературе)
В статье почему-то не упоминается, что Метод критической цепи является развитием Метода критического пути, только с добавлением буферов, покрывающих риски.
Просто не осилил.
Это для роботов, а не для людей.
UFO just landed and posted this here
Работаю дизайнером в маленькой компании.
Пытался донести до всех что при малых ресурсах планирование должно быть еще более важно. На что все только улыбаются и разводят руками, типа зачем оно нам, раньше ведь и без планирования работали.
Пытался донести до всех что при малых ресурсах планирование должно быть еще более важно. На что все только улыбаются и разводят руками, типа зачем оно нам, раньше ведь и без планирования работали.
На моей практике, диаграмму ганта (он с одной т) никто действительно не соблюдает. Руководители проектов исходят из того, что перед ними обычные в общем-то люди, поэтому они и не пытаются им навязать подобный стиль мышления. Т.е. руководители проектов знают, с кем они работают.
Вот приличный заголовок, что и не говори. На первой странице. Даже и не важно что там внутри. Просто приятно открыть Хабр в присутствии посторонних, что бы все видели, что читаю я - Метод критической цепи: эффективное управление проектами. Сразу уважение у окружающих людей. Общечеловеческая жизненная карма растёт. Близкие опять же понимают - я делом занят, а не в какой-то там социальной сети вишу.
Ото зайдёшь бывает, а там что-нить типа - Кармазадроты готовят очередную революцию. Тьфу... Да. Стыдоба.
Ото зайдёшь бывает, а там что-нить типа - Кармазадроты готовят очередную революцию. Тьфу... Да. Стыдоба.
О, а я как раз по этой теме диплом бакалавра защищал :) Писал на Ruby реализацию этого дела - высчитывало все упомянутые параметры и рисовало красивый график. Спасибо за статью.
Где можно посмотреть на ваш инструмент в действии?
А можно посмотреть ваш проект и дипломную работу? Очень было интересно почитать и то и другое.
Я поищу чуть позже и вышлю, что есть. Но предупреждаю сразу: половина работы - паливо чистейшей воды, - мне было интересно реализовать сам алгоритм на Ruby, но оформить это в полноценный продукт, довести до ума и тем более написать хорошо сопровождающий документ интереса уже не хватило. Тем более, что преподы из нашей комиссии всё равно ничего бы не поняли - они по пониманию IT остались где-то в 80х.
Плюс вам в карму. Спасибо за замечательную статью.
UFO just landed and posted this here
Вот тут кстати прикольно про метод написано:
http://www.headfirstlabs.com/PMP/critica…
http://www.headfirstlabs.com/PMP/critica…
Sign up to leave a comment.
Метод критической цепи