Comments 60
Поправьте меня, если я заблуждаюсь, но слово «операционный» в описании подходов к управлению проектами для меня очень странно звучит.
Хоть я и не PM, а только частично занимаюсь управлению проектами, но мне всегда казалось что операционная деятельность и проектная чуть ли не противоположные сущности по сути.
Хоть я и не PM, а только частично занимаюсь управлению проектами, но мне всегда казалось что операционная деятельность и проектная чуть ли не противоположные сущности по сути.
В проекте могут быть операции, если в орг.структуре проекта есть функциональные подразделения. Но о таких проектах вряд ли идет речь сейчас. Так что вы скорее правы.
Готов доказать, что проект содержит операционную деятельность.
Но основное, что имелось в виду — это разница в подходах.
Операционная деятельность похожа на конвейер с однотипными задачами, что вчера, что сегодня, что завтра. Нет смысла думать о будущем. «Нормально делай — нормально и будет». Главное отработать подход на нескольких задачах, дальше все пойдет как по маслу.
«Проектеры» управляют «уникальными» результатами, поэтому завтра может сильно отличаться от вчера и сегодня. Поэтому нужно мыслить на перспективу и заранее предугадывать сценарии развития.
И в дополнение, приемы, используемые в операционной деятельности, применимы и в проектной. Однако, проектная деятельность содержит ряд уникальных методов.
Например, метод критического пути или метод освоенного объема.
Но основное, что имелось в виду — это разница в подходах.
Операционная деятельность похожа на конвейер с однотипными задачами, что вчера, что сегодня, что завтра. Нет смысла думать о будущем. «Нормально делай — нормально и будет». Главное отработать подход на нескольких задачах, дальше все пойдет как по маслу.
«Проектеры» управляют «уникальными» результатами, поэтому завтра может сильно отличаться от вчера и сегодня. Поэтому нужно мыслить на перспективу и заранее предугадывать сценарии развития.
И в дополнение, приемы, используемые в операционной деятельности, применимы и в проектной. Однако, проектная деятельность содержит ряд уникальных методов.
Например, метод критического пути или метод освоенного объема.
Все таки для меня, в зависимости от того, на каком уровне ты находишься, одно и то же может быть как проектной так и операционной деятельность,
Только вот если на твоем текущем уровне какие то задачи идут как операционная деятельность, не стоит смотреть на управление проектами.
По тому же pmbok «And a project is unique in that it is not a routine operation».
Но по моему я вас понял, вы хотели сказать, сильно утрируя, что при управлении проектом необходимо видеть и отслеживать весь путь до цели, с разной степенью детализации, в зависимости от этапов.
Но если правильно провести инициализацию и планирования проекта, и отслеживать что с ним происходит и корректировать, то так и получится, а если так не сделать, то какое это уже управление проектом?)
Только вот если на твоем текущем уровне какие то задачи идут как операционная деятельность, не стоит смотреть на управление проектами.
По тому же pmbok «And a project is unique in that it is not a routine operation».
Но по моему я вас понял, вы хотели сказать, сильно утрируя, что при управлении проектом необходимо видеть и отслеживать весь путь до цели, с разной степенью детализации, в зависимости от этапов.
Но если правильно провести инициализацию и планирования проекта, и отслеживать что с ним происходит и корректировать, то так и получится, а если так не сделать, то какое это уже управление проектом?)
Операции — это действия. То что непосредственно исполняется. Действия могут исполнятся в рамках проектов или бизнес-процессов.
как вы все просто описали!
Распутываем дальше.
Не операционный уровень, а оперативный.
Проект управляется в разных режимах. У вас это уровни:
1 операционный (от дня, до недели)
2 среднесрочный (от месяца, до трех)
3 долгосрочный (на весь срок)
Для каждого режима свои планы. Самые точные — операционные.
Не операционный уровень, а оперативный.
Проект управляется в разных режимах. У вас это уровни:
1 операционный (от дня, до недели)
2 среднесрочный (от месяца, до трех)
3 долгосрочный (на весь срок)
Для каждого режима свои планы. Самые точные — операционные.
Благодарю, в терминах вы внесли больше ясности.
Даже методы достижения среднесрочных целей отличаются для разных типов деятельности (операционной и проектной).
ОПЕРАЦИОННАЯ ДЕЯТЕЛЬНОСТЬ
Например в операционной деятельности, возьмем показатель — объем выручки.
Есть план на неделю, есть на квартал. Чтобы выполнить среднесрочный план, нужно наращивать количество выполненных операций (утрирую, поскольку одна продажа может принести 500 руб, а другая 5 000 руб.).
ПРОЕКТНАЯ ДЕЯТЕЛЬНОСТЬ
Для проектной деятельности обычным наращиванием выполненных операций не всегда возможно добиться результата.
Тут нужно использовать методы критического пути, освоенного объема, оценки по трем точкам и т.д. в зависимости от навыков менеджеров. Потому что можно выполнять быстро и много операций, а они окажутся не на критическом пути, и результат так и не будет достигнут.
Вот такую мысль я и пытался заложить в статью.
Даже методы достижения среднесрочных целей отличаются для разных типов деятельности (операционной и проектной).
ОПЕРАЦИОННАЯ ДЕЯТЕЛЬНОСТЬ
Например в операционной деятельности, возьмем показатель — объем выручки.
Есть план на неделю, есть на квартал. Чтобы выполнить среднесрочный план, нужно наращивать количество выполненных операций (утрирую, поскольку одна продажа может принести 500 руб, а другая 5 000 руб.).
ПРОЕКТНАЯ ДЕЯТЕЛЬНОСТЬ
Для проектной деятельности обычным наращиванием выполненных операций не всегда возможно добиться результата.
Тут нужно использовать методы критического пути, освоенного объема, оценки по трем точкам и т.д. в зависимости от навыков менеджеров. Потому что можно выполнять быстро и много операций, а они окажутся не на критическом пути, и результат так и не будет достигнут.
Вот такую мысль я и пытался заложить в статью.
То, о чем вы пишите, это не операционная деятельность. А деятельность в бизнес-процессах. Процессная.
Виды организации деятельности (не полный список):
1 Проектная (даже стандарты есть, PM BOK, ISO 21500)
2 Бизнес-процессы (Тема зовется BPM, стандарт BPM BOK, нотации описания BPMN, idef0 — в какой-то мере, ARIS)
3 Поручения
4 Программы
и т.д.
Все виды комбинируются и часто взамосвязаны.
В основе всегда набор конкретных операций (действий) которые исполняются конкретными людьми, на операционном уровне.
PS Прошу прощения, сам ошибся.
1 это оперативный уровень, и оперативные планы.
Виды организации деятельности (не полный список):
1 Проектная (даже стандарты есть, PM BOK, ISO 21500)
2 Бизнес-процессы (Тема зовется BPM, стандарт BPM BOK, нотации описания BPMN, idef0 — в какой-то мере, ARIS)
3 Поручения
4 Программы
и т.д.
Все виды комбинируются и часто взамосвязаны.
В основе всегда набор конкретных операций (действий) которые исполняются конкретными людьми, на операционном уровне.
PS Прошу прощения, сам ошибся.
1 это оперативный уровень, и оперативные планы.
Операция — неделимый на другие операции блок действий, результат которого можно зафиксировать как переход продукта из состояния А в состояние А', где A' — в идеале, конечный (на данном этапе) работоспособный вариант продукта.
Мне кажется, что стоит присмотреться к определению операции в технологических процессах на производстве и адаптировать к специфике IT:
«Операция — законченная часть технологического процесса обработки заготовки, выполняемая на одном рабочем месте (на одном станке) непрерывно до перехода к обработке следующей заготовки.» (источник: delta-grup.ru/bibliot/10/68.htm)
Мне кажется, что стоит присмотреться к определению операции в технологических процессах на производстве и адаптировать к специфике IT:
«Операция — законченная часть технологического процесса обработки заготовки, выполняемая на одном рабочем месте (на одном станке) непрерывно до перехода к обработке следующей заготовки.» (источник: delta-grup.ru/bibliot/10/68.htm)
Если кратко: Проект — то что делается единоразово. Операционная деятельность — повторяющийся набор операций.
То, о чем Вы пишете, кратко называется видение (вижн) проекта. Любой кто читал руководство к своду знаний по управлению проектами, это достаточно очевидно. Вы хорошо пишете, но не задели самого интересного — что управлять можно только хвостом проекта.
Про операции и про прочее: менеджер вынужден иметь дело со всем что происходит на проекте. У меня однажды две девушки поссорились на проекте, и я их мирил (обоим объяснил что обе неправы). Я это к чему. К тому что не надо ломать определения. Проект это временное предприятие по созданию уникального результата, а операции — это не уникальные повторющиеся действия. Не надо называть таски операциями. Задача менеджера проекта — управление проектом для достижения его целей, а чем управлять — дело вторичное (всем!).
Мышление конечным результатом и сегодншними действиями и статусом проекта — это основной инструмент менеджера проектов. Если Ваш опыт говорит о менеджерах, которые не мыслят конечными результатами проекта — подсуньте тем менеджерам пмбок.
Про операции и про прочее: менеджер вынужден иметь дело со всем что происходит на проекте. У меня однажды две девушки поссорились на проекте, и я их мирил (обоим объяснил что обе неправы). Я это к чему. К тому что не надо ломать определения. Проект это временное предприятие по созданию уникального результата, а операции — это не уникальные повторющиеся действия. Не надо называть таски операциями. Задача менеджера проекта — управление проектом для достижения его целей, а чем управлять — дело вторичное (всем!).
Мышление конечным результатом и сегодншними действиями и статусом проекта — это основной инструмент менеджера проектов. Если Ваш опыт говорит о менеджерах, которые не мыслят конечными результатами проекта — подсуньте тем менеджерам пмбок.
Вы пишите:
Видимо, вы умеете управлять только тем, что отчетливо видно. Тем что вы не можете видетЬ, вы не можете управлять. В конце всегда все четче видно, чем в начале. Если вы управляли только тасками, а не управляли проектом, то хвостом уже управлять бесполезно, там нужно только «дожимать». А потом еще долго-долго дорабатывать и исправлять.
Почитайте мою статью, как использовать MS Projetc в качестве навигатора проекта и прогнозировать картину на много дней и недель вперед. Имея прогноз, вы всегда можете скорректировать что-то. Не имея прогнозов, вы может только надеяться.
Мой опыт работы в компаниях, входящих в ТОП-30 ИТ-компаний России, говорит о том, что менеджеры неэффективно используют инструменты, описанные хотя бы в PMBOK.
Я видел, как люди люди, управляющие проектами с бюджетами, кратными сотням млн. руб. акцентируются на тасках в JIRA, а дальше недели они ничего не видят. В итоге и проект срывается. Сам управлял такими проектами и знаю разницу в подходах.
Если для вас полноценный контроль — это обычное дело, то ответьте себе на вопрос:
— На сколько дней ваш проект отстает от намеченных планов на сегодняшний день?
— Когда завершится ваш проект/этап проекта (прогнозы)?
Тоже самое попробуйте проделать с финансами.
Вы хорошо пишете, но не задели самого интересного — что управлять можно только хвостом проекта.
Видимо, вы умеете управлять только тем, что отчетливо видно. Тем что вы не можете видетЬ, вы не можете управлять. В конце всегда все четче видно, чем в начале. Если вы управляли только тасками, а не управляли проектом, то хвостом уже управлять бесполезно, там нужно только «дожимать». А потом еще долго-долго дорабатывать и исправлять.
Почитайте мою статью, как использовать MS Projetc в качестве навигатора проекта и прогнозировать картину на много дней и недель вперед. Имея прогноз, вы всегда можете скорректировать что-то. Не имея прогнозов, вы может только надеяться.
Если Ваш опыт говорит о менеджерах, которые не мыслят конечными результатами проекта — подсуньте тем менеджерам пмбок.
Мой опыт работы в компаниях, входящих в ТОП-30 ИТ-компаний России, говорит о том, что менеджеры неэффективно используют инструменты, описанные хотя бы в PMBOK.
Я видел, как люди люди, управляющие проектами с бюджетами, кратными сотням млн. руб. акцентируются на тасках в JIRA, а дальше недели они ничего не видят. В итоге и проект срывается. Сам управлял такими проектами и знаю разницу в подходах.
Если для вас полноценный контроль — это обычное дело, то ответьте себе на вопрос:
— На сколько дней ваш проект отстает от намеченных планов на сегодняшний день?
— Когда завершится ваш проект/этап проекта (прогнозы)?
Тоже самое попробуйте проделать с финансами.
Кажется, меня вы не поняли. И я читал вашу статью про прорджект. Выдаете сермяжную правду за откровения, что там, что здесь. Бюджетами и топами светить вряд ли делу поможет. Но не суть.
У меня была как-то давненько статья про двухслойное управление проектом. Так что вашу мысль я понимаю, претензии скорее по формулировкам. Вкратце, следует отделять собственно управление именно проектом от управления процессом разработки. Но управлять надо и тем и другим, и несмотря на то что роли могут быть разделены — процесс тоже зона ответственности менеджера.
А про управление хвостом вообще какая-то примитивная истина на самом деле. Я ее упомянул лишь с той целью, что она иллюстрирует неплохо эту спортивную метафору с бильярдом (мне првда шахматы больше по душе, хотя динамическая сложность наверное одна и та же).
У меня была как-то давненько статья про двухслойное управление проектом. Так что вашу мысль я понимаю, претензии скорее по формулировкам. Вкратце, следует отделять собственно управление именно проектом от управления процессом разработки. Но управлять надо и тем и другим, и несмотря на то что роли могут быть разделены — процесс тоже зона ответственности менеджера.
А про управление хвостом вообще какая-то примитивная истина на самом деле. Я ее упомянул лишь с той целью, что она иллюстрирует неплохо эту спортивную метафору с бильярдом (мне првда шахматы больше по душе, хотя динамическая сложность наверное одна и та же).
Но управлять надо и тем и другим, и несмотря на то что роли могут быть разделены — процесс тоже зона ответственности менеджера.Для налаживания процессного управления хорошо бы иметь отдельного человека. В моем опыте это был руководитель отдела разработки. Процессы — его вотчина. Руководитель проекта в это не лезет, только на уровне готовности/неготовности/когда отдельных тасков.
Проект это временное предприятие по созданию уникального результата, а операции — это не уникальные повторющиеся действия. Не надо называть таски операциями. Задача менеджера проекта — управление проектом для достижения его целей, а чем управлять — дело вторичное (всем!).
Проектная и операционная деятельность — части одного целого. Помните круглый восточный знак слияния? Вот примерно так. Или, если угодно, в них есть что-то от фрактальной геометрии. Смотришь на общий рисунок — проект, однозначно. Всмотрелся в его участок — дык, процесс! Всмотрелся в участок процесса — снова проект! :)
Пример из жизни конторы-разработчика.
Уровень 1.
Процессы конторы рутинны: пресейл, контракт, работа, сдача, повторить. Чистой воды конвейер в несколько линий, которым надо управлять (чтобы не остаться в нужный момент без ресурсов, например).
Всматриваемся глубже.
Уровень 2.
Отдельные проекты конторы. Совершенно уникальные, со сроками, бюджетами, рисками. Классика.
Всматриваемся глубже.
Уровень 3.
Предположим, в конторе околоagile. В проекте — итерация за итерацией. Постановка — работа — контроль — повторить. Снова конвейер.
Всматриваемся глубже.
Уровень 4.
Внутри итерации результаты уникальны. Реализуются конкретные фичи, публикуются конкретные артефакты. Снова ресурсы и сроки. Проект!
Всматриваемся глубже.
Уровень 5.
Аналитик пишет постановку на итерацию. Встретился с заказчиком, написал что-то в спеку. Сбегал к архитектору, дописал. Созвонился с разработчиком — дописал. Получил доп. информацию еще из какого-то источника — внес. Повторить. Обратно, конвейер.
Всматриваемся глубже.
Уровень 6.
Отдельная встреча с заказчиком. Уникальное мероприятие со своими участниками (ресурсами), бюджетом (продолжительностью), сроками (датой). Уникальные результаты. Снова проект?
Всматриваемся глубже.
Уровень 7.
Поздоровались, расселись, давай допрашивать. Вопрос — ответ, следующий вопрос — еще ответ, повторить. Конвейер…
Всматриваемся глубже.
* * *
Мышление конечным результатом и сегодншними действиями и статусом проекта — это основной инструмент менеджера проектов. Если Ваш опыт говорит о менеджерах, которые не мыслят конечными результатами проекта — подсуньте тем менеджерам пмбок.
А если они мыслят не только конечными результатами проекта, способны заглянуть как в микро-, так и в макромир — выдайте им премию и повысьте. :)
Ну круто, что. We need to go deeper. Мы лезем в дебри терминологии, которая если не усложнять жизнь, проста до безобразия.
Водораздел, если быть кратким, следующий:
1. Операция и процесс требуют стандартных интерфейсов, таска, итерация, проект — нет.
2. Операция и процесс выдают результаты по запросу, таска, итерация, проект — один раз.
3. Конвейер — это когда над одними и теми же объектами производят последовательно одни и те же операции.
4. Проект — это когда также последовательно выполняют преобразования, но, над одним объектом.
Водораздел, если быть кратким, следующий:
1. Операция и процесс требуют стандартных интерфейсов, таска, итерация, проект — нет.
2. Операция и процесс выдают результаты по запросу, таска, итерация, проект — один раз.
3. Конвейер — это когда над одними и теми же объектами производят последовательно одни и те же операции.
4. Проект — это когда также последовательно выполняют преобразования, но, над одним объектом.
Все верно.
Водоразделы есть, но есть и взаимный переход одного в другое. Поэтому жесткие противопоставления не особо радуют.
Терминология тут не при чем, я говорю про характер деятельности.
А терминология… Если надо, любую терминологию можно притянуть к реалиям за какое-нибудь хваткое место. Не на другой планете же ее выдумали.
Водоразделы есть, но есть и взаимный переход одного в другое. Поэтому жесткие противопоставления не особо радуют.
Терминология тут не при чем, я говорю про характер деятельности.
А терминология… Если надо, любую терминологию можно притянуть к реалиям за какое-нибудь хваткое место. Не на другой планете же ее выдумали.
Характер деятельности описан в терминах. В проектах даже если что-то и повторяется, то это (за редкими исключениями, о которых я упоминал выше) нельзя назвать операцией. Но мысль Вашу я естественно понял. Я в курсе, что события в проекте можно рассматривать в разном масштабе. И что в некоторых масштабах можно увидеть повторения, как их не называй.
Это просто следствие наличия в проектах целенаправленных действий по снижению неопределенности (с будущим результатом, которого достигают, снижается она путем переделки промежуточных результатов). В случае с производственным конвейером (уж извините, вернусь к терминам), повторение имеет иную природу (для конвейера повторение — следствие целевой функции системы).
Это просто следствие наличия в проектах целенаправленных действий по снижению неопределенности (с будущим результатом, которого достигают, снижается она путем переделки промежуточных результатов). В случае с производственным конвейером (уж извините, вернусь к терминам), повторение имеет иную природу (для конвейера повторение — следствие целевой функции системы).
Как обычно — все зависит от точки зрения.
Я, например, на проекты смотрю по большей части с позиции ресурса. И для меня это бесконечная череда сменяющих друг друга проектов, с идентичными входами, выходами и характером работы, которую нужно проделать. Собственно, мне за это деньги и платят. Ну чем я не конвейер? А проекты в данном случае — преходящие мелочи.
А вот руководить менеджерам приходится не абстрактными категориями вроде «проекта» а конкретным, живым мной. Биологическим конвейером, то бишь. :)
Я, например, на проекты смотрю по большей части с позиции ресурса. И для меня это бесконечная череда сменяющих друг друга проектов, с идентичными входами, выходами и характером работы, которую нужно проделать. Собственно, мне за это деньги и платят. Ну чем я не конвейер? А проекты в данном случае — преходящие мелочи.
А вот руководить менеджерам приходится не абстрактными категориями вроде «проекта» а конкретным, живым мной. Биологическим конвейером, то бишь. :)
А теперь поднимитесь на ступеньку наверх, там где много проектов. Там сидит какой-то чел, у которого болит голова, чтобы проекты всегда попадали в заданное место пресловутого треугольника. И что ему делать? Поставить проекты на поток, т.е. наладить процесс, очевидно. Так проекты становятся процессом, оставаясь при этом проектами.
Там где проектов много, место называется офисом управления проектами, а сами проекты образуют портфель. Который, будучи согласован со стратегией (отвечаю на комментарий ниже), является вполне уникальным, хотя всех волнуют его фин. параметры. Управление проектом, проектами, портфелем может быть, а по PMI и должно, организовано в виде процессов, однако сами проекты и портфели процессами от этого не становятся, даже для фин. директора проект по фин. показателям отличается от процесса.
Конечно, для стандартной аутсорсинговой конторы велико желание «поставить на поток» и рассматривать проекты как операционную деятельность. С юридической точки зрения и с точкм зрения бухгалтерии это ввсе так и есть — продаются услуги чаще всего, а не продукты, но с точки зрения управления, услуга не будет оказана, если продукт не выгорит в том самом треугольнике.
Конечно, для стандартной аутсорсинговой конторы велико желание «поставить на поток» и рассматривать проекты как операционную деятельность. С юридической точки зрения и с точкм зрения бухгалтерии это ввсе так и есть — продаются услуги чаще всего, а не продукты, но с точки зрения управления, услуга не будет оказана, если продукт не выгорит в том самом треугольнике.
«Портфель проектов», «стратегия», управление по PMI… Это круто, это можно дорого продать. :)
А по жизни «портфель» — это куда контора смогла пролезть и где смогла урвать себе один или несколько кусков понажористее. Сейлы рыщут, аккаунты дергают связи, первые лица сажают печень в процессе установления доверительных отношений, а результат их общей работы валится на проектный офис (и других исполнителей) внезапно, поскольку до дня «Д» все было вилами по воде, а немногочисленные известные детали — «коммерческой тайной» (до тех пор, пока не договорились). Да и после дня «Д» некоторые моменты ей остаются (см., например, свежий «китайский» контракт Газпрома).
Пока мой опыт, включая работу в интеграторах из ТОП-..., показывает именно такую картину.
А по жизни «портфель» — это куда контора смогла пролезть и где смогла урвать себе один или несколько кусков понажористее. Сейлы рыщут, аккаунты дергают связи, первые лица сажают печень в процессе установления доверительных отношений, а результат их общей работы валится на проектный офис (и других исполнителей) внезапно, поскольку до дня «Д» все было вилами по воде, а немногочисленные известные детали — «коммерческой тайной» (до тех пор, пока не договорились). Да и после дня «Д» некоторые моменты ей остаются (см., например, свежий «китайский» контракт Газпрома).
Пока мой опыт, включая работу в интеграторах из ТОП-..., показывает именно такую картину.
Такие компании пусть и дальше продают часы исполнителей, и изобретают «конвейер» для производства «единичных изделий» работниками интеллектуального труда. Я эту картину видел, в интеграторе работал. Их стратегия — обеспечить загрузку «мощностей» и поживать на марже с продажи (часов исполнителей). Это не проектный бизнес, это тупо услуги, им и PMBoK не нужен, проектное управление у них — способ выжать больше маржи из фиксированного бюджета.
Но я видел и другие картины. В компаниях, которые делают свои продукты и внедряют их. Когда представители топов и не очень объединяются в команду стратегической сессии, когда портфельный комитет рассматривает анализ портфеля, составленный ОУП, в котором расписано, сколько заработаем на несколько лет вперед и какие есть риски и альтернативы.
Спросите какого-нибудь топа из знакомых — что бы он предпочел — день «Д» или управляемую перспективу. А насчет дорого продать… кому надо, сам сможет, а у кого деньги шальные, так те пусть покупают очередной Lexus. Им ОУП может только для имиджа или маркетинга, или информационный повод. С такими тоже не очень приятно работать.
Но я видел и другие картины. В компаниях, которые делают свои продукты и внедряют их. Когда представители топов и не очень объединяются в команду стратегической сессии, когда портфельный комитет рассматривает анализ портфеля, составленный ОУП, в котором расписано, сколько заработаем на несколько лет вперед и какие есть риски и альтернативы.
Спросите какого-нибудь топа из знакомых — что бы он предпочел — день «Д» или управляемую перспективу. А насчет дорого продать… кому надо, сам сможет, а у кого деньги шальные, так те пусть покупают очередной Lexus. Им ОУП может только для имиджа или маркетинга, или информационный повод. С такими тоже не очень приятно работать.
Бизнес, может, и не проектный. Но отдельных проектов в нем — целые пачки. Это снова про перетекание одного в другое. Кстати, там же «в недрах», при наборе критической массы компетенций, иногда рождаются собственные продукты (решения).
«Сколько заработаем на несколько лет вперед» в наших реалиях увы, суть благие намерения по дележу шкуры хитрободрого медведя. Хотя, за неимением лучшего, и оно сгодится. Надо же от чего-то отталкиваться.
Из моих знакомых даже не топы предпочтут быть богатыми и здоровыми, нежели наоборот. Но довольствуются тем, что могут достать плюс занимаются реализацией амбиций.
И… эх… вот если бы работать только с теми, с кем приятно!
«Сколько заработаем на несколько лет вперед» в наших реалиях увы, суть благие намерения по дележу шкуры хитрободрого медведя. Хотя, за неимением лучшего, и оно сгодится. Надо же от чего-то отталкиваться.
Из моих знакомых даже не топы предпочтут быть богатыми и здоровыми, нежели наоборот. Но довольствуются тем, что могут достать плюс занимаются реализацией амбиций.
И… эх… вот если бы работать только с теми, с кем приятно!
По первым двум тезисам отвечу…
Проектом это является формально, по факту — это заказ (подряд) по выполнению определенного объема работ. Собственные продукты рождаются… никто не спорит. Всё хорошо. Или будет хорошо. Я против интеграторов ничего не имею. Как и общего с ними сейчас. В будущем — как карта ляжет :)
В наших реалиях сколько заработаем на несколько лет вперед — благие намерения? А давайте вообще не будем считать? Как я это назвал комментарием ниже — похрену мороз. Просто рынок имеет смысл представлять не как бюджеты заказчиков, которые надо освоить и инсайды о тендерах, а как тренды в потребностях и эффективностью внедряемого. Впрочем, рынок наш разнороден, поэтому универсального совета не дам. Хотя когда-то магистерскую как раз по этому вопросу и защищал…
Проектом это является формально, по факту — это заказ (подряд) по выполнению определенного объема работ. Собственные продукты рождаются… никто не спорит. Всё хорошо. Или будет хорошо. Я против интеграторов ничего не имею. Как и общего с ними сейчас. В будущем — как карта ляжет :)
В наших реалиях сколько заработаем на несколько лет вперед — благие намерения? А давайте вообще не будем считать? Как я это назвал комментарием ниже — похрену мороз. Просто рынок имеет смысл представлять не как бюджеты заказчиков, которые надо освоить и инсайды о тендерах, а как тренды в потребностях и эффективностью внедряемого. Впрочем, рынок наш разнороден, поэтому универсального совета не дам. Хотя когда-то магистерскую как раз по этому вопросу и защищал…
А давайте вообще не будем считать?
Нет, считать давайте будем. Разве я призывал к отказу от планирования? Я лишь говорю, что в достаточно нестабильной (в первую очередь, экономически и административно) ситуации заниматься такими расчетами без определенной доли скепсиса не стоит. Ну и разумеется, нужно быть готовыми перекраивать стратегические планы «в связи с вновь возникшими обстоятельствами».
Просто рынок имеет смысл представлять не как бюджеты заказчиков, которые надо освоить и инсайды о тендерах, а как тренды в потребностях и эффективностью внедряемого
Ох, как это непросто… И дорого. Но правильно. Но поскольку дорого, далеко не у всех контор и конторок хватит ресурсов и смелости гнуть такую линию, даже несмотря на куда большие потенциальные барыши. Вот и живут «от зарплаты до зарплаты» (неплохо, в принципе, живут). Может, со временем будут больше внимания уделять стратегическому развитию.
Согласен. Только прокомментирую следующее:
У (в частности) портфельного управления есть достаточно интересные инструменты работы с рисками и альтернативами. Да и у проектного тоже есть. Те же Торнадо, Риск-Эффективность-Стоимость, Дорожные карты с вероятностями, Реальные опционы, Монте-Карло. Сейчас, когда принятие решения по проекту достаточно понятный критерий имеет (NPV > 0, кстати по упомянутому газовому контракту эксперты расходятся во мнении о его положительности:)), остается развивать эту науку (без кавычек) именно в направлении оценки рисков и повышения гибкости управления. Это всё кажется дорогим, но и этот продукт можно сделать массовым, как PMBoK пошел в массы. Просто у нас через печень принято решать чаще.
в достаточно нестабильной (в первую очередь, экономически и административно) ситуации заниматься такими расчетами без определенной доли скепсиса не стоит
У (в частности) портфельного управления есть достаточно интересные инструменты работы с рисками и альтернативами. Да и у проектного тоже есть. Те же Торнадо, Риск-Эффективность-Стоимость, Дорожные карты с вероятностями, Реальные опционы, Монте-Карло. Сейчас, когда принятие решения по проекту достаточно понятный критерий имеет (NPV > 0, кстати по упомянутому газовому контракту эксперты расходятся во мнении о его положительности:)), остается развивать эту науку (без кавычек) именно в направлении оценки рисков и повышения гибкости управления. Это всё кажется дорогим, но и этот продукт можно сделать массовым, как PMBoK пошел в массы. Просто у нас через печень принято решать чаще.
есть достаточно интересные инструменты работы с рисками и альтернативами.
Есть. Только применение их ограничено с одной стороны, неумением и нежеланием ими пользоваться, а с другой — не очень подходящей средой их применения. Эффект, как говорится, кумулятивный.
Сейчас, когда принятие решения по проекту достаточно понятный критерий имеет (NPV > 0,
Почему именно этот критерий и именно с таким порогом? По мне, так из него одного вообще ничего непонятно.
по упомянутому газовому контракту эксперты расходятся во мнении о его положительности:)
Да, я ознакомился с мнением эксперта Латыниной. :)
Я его упомянул как пример того, что даже после заключения контракта далеко не всем исполнителям будут докладывать о подробностях. Даже важных. Состоятельность планов в таких условиях соответствует.
как PMBoK пошел в массы.
Индекс цитирования у него классный. А вот реального применения как-то не особо заметно. Тут совсем недавно опрос был по применяемым в проектах разработки методикам. :)
с другой — не очень подходящей средой их примененияЕсли речь о головах некоторых потребителей отчетности, то соглашусь.
Почему именно этот критерий и именно с таким порогом? По мне, так из него одного вообще ничего непонятно.Для одного проекта всё так.
Я его упомянул как пример того, что даже после заключения контракта далеко не всем исполнителям будут докладывать о подробностях.Управление овощами — модно нынче. И об этом совсем не хочется думать.
Индекс цитирования у него классный. А вот реального применения как-то не особо заметно.По-крайней мере, обучения PMBoK и организации деятельности по нему, куда как больше (чем даже Agile). В ИТ действительно применяют не так часто, как могли бы. А в других отраслях (есть ведь конкурирующие стандарты, IPMA например исторически раньше был в России) он вполне приживается.
Некоторые компании настолько круты, что для своих проектов (это не ИТ, а добыча, там мне тоже довелось поработать), имеют свои собственные методологии (не методики). И это вполне закономерно. Для средних же компаний можно найти продукт, который они смогут адаптировать, я считаю. И стать в управленческом плане более технологичными, и рынок станет более цивилизованным и предсказуемым для всех. Но для этого и действительно нужна смелость, как Вы подметили. Или мода.
Некоторые компании настолько круты, что для своих проектов… имеют свои собственные методологии
Да, доводилось наблюдать.
Для средних же компаний можно найти продукт, который они смогут адаптировать, я считаю. И стать в управленческом плане более технологичными
Тут у меня впечатления двойственные. За время знакомства с различными методологиями и методами управления (в основном, западного или японского происхождения) у меня сложилось впечатление, что их задача — не столько добиться максимальной эффективности в деятельности конкретной компании, сколько обеспечить некий средний уровень прозрачной управляемости, ниже которого она не упадет. И достигается это ценой искоренения попыток сделать шаг влево или вправо вне зависимости от того, насколько оно потенциально полезно. То есть, имеет место шлифовка инструментария стандартизированного управления усредненной биомассой на все случаи жизни, вне зависимости от объекта управления. И что характерно — эта задача решается.
С другой стороны, мне неизвестно, чтобы небольшие компании с наиболее высокой нормой прибыли добились ее благодаря внедрению «технологичных» методов управления. Скорее, наоборот — благодаря наличию «мозговых центров», методы управления которых никакой прозрачностью не отличались и научно особо не описывались.
В общем, я бы не стал безоглядно ратовать за поголовное внедрение сколь угодно хороших, раскрученных и проверенных методов управления. Эффект может быть обратным.
и рынок станет более цивилизованным и предсказуемым для всех.
А вот это вряд ли зависит от технологий, применяемых внутри отдельных организаций. По крайней мере, далеко не в первую очередь. :)
А вы возьмите для примера 1С-франчайзинг. Куча компаний, и все обеспечивают какую-то норму. Я не обещал сверхуспешность (я вообще ничего не обещал). Я считаю, что именно управленческая технологичность — путь к цивилизованному рынку. Знаете другой?
А вы возьмите для примера 1С-франчайзинг.
Франчайзинг в этом отношении не очень удачный пример. Он как раз и заключается в том, чтобы взять готовые схемы. И «не дай Бог...», а то отберут.
Я считаю, что именно управленческая технологичность — путь к цивилизованному рынку. Знаете другой?
Я просто не вижу, как управленческая технологичность связана с цивилизованностью рынка.
Чтобы что-то в человеческом обществе стало цивилизованным, нужно действовать по принципу «не можешь — научим, не хочешь — заставим». Требуется добротное нормативно-правовое регулирование с обязательным соблюдением его положений.
Например, хочешь безопасно гулять с женой поздно вечером в спальном районе — сначала объясни населению, что грабить и насиловать — нехорошо. Тех, кто не согласен — изолируй. Обеспечь видеонаблюдение, наладь агентурную работу в криминальной и криминогенной среде, разработай маршруты патрулирования, выпусти на них подготовленных правоохранителей, подготовь группы немедленного реагирования и ситуационные центры. И тогда вероятность огрести обрезком трубы по темечку приблизится к величине статистической погрешности.
А вот увеличивать технологичность ваших семейных отношений с женой при этом совсем не обязательно.
del
Leonid76, согласен. На деле то что называется программой или портфелем проектов является всего лишь набором проектов.
Программа — поменьше проектов, портфель — потолще.
Никто не управляет выгодами программы, а про портфели и стратегические цели — я тоже промолчу.
У нас в России еще как следует не развито управление проектами, а тут уже люди управляют портфелями.
Программа — поменьше проектов, портфель — потолще.
Никто не управляет выгодами программы, а про портфели и стратегические цели — я тоже промолчу.
У нас в России еще как следует не развито управление проектами, а тут уже люди управляют портфелями.
Справедливо, только не ясно что с этим делать :)
Проект это временное предприятие по созданию уникального результатаТут стоило бы упомянуть, для кого этот результат уникален. Для фин.директора подрядной конторы, например, все проекты, которые делает контора, описываются конечным числом измеримых финансовых параметров.
Теория, это хорошо. Почему только нету практикующих управителей проектов? :)
Эм… Тот подход, который вы называете «проектным» применяется при создании чего-то нового, например, «давайте перенесем все наши ресурсы в облако». Тот же, что тут называется «операционным» — применяется для стабильных, рутинных проектов, например, «окей, перенесли в облако, а теперь давайте это грамотно поддерживать». Не уверен, что совмещать оба подхода будет эффективно.
Это не подходы, а уровни. В статье это явно написано.
Грубо говоря, проектный уровень — это User Story, а операционный — Task.
Грубо говоря, проектный уровень — это User Story, а операционный — Task.
Вы правильно меня поняли.
Грубо говоря операционный уровень — это где скапливается много мелочи и эту мелочь нужно оперативно закрывать.
Именно так многие и работают. «У нас нет времени, некогда думать, нужно быстрее делать!»
На проектном уровне — нужно больше анализировать, прогнозировать и на основании этого корректировать проект, если такие прогнозы не в вашу пользу.
Грубо говоря операционный уровень — это где скапливается много мелочи и эту мелочь нужно оперативно закрывать.
Именно так многие и работают. «У нас нет времени, некогда думать, нужно быстрее делать!»
На проектном уровне — нужно больше анализировать, прогнозировать и на основании этого корректировать проект, если такие прогнозы не в вашу пользу.
Я это понял по другому.
Тут даже не UserStory, а Epic на проектном уровне, т.е. цельный продукт или некое задание от бизнеса.
Операционный уровень — это UserStory или Task, о котором мы знаем, сколько ресурсов он потребует от нас для его выполнения (т.е. упрощенно — как минимум времени).
Таски предсказуемы, мы можем набросать некий набор тасков и сказать, через какой период времени мы закроем этот набор.
Соответственно с закрытием набора тасков у нас закрывается 1-2-… Эпика.
Т.е. я воспринял эти уровни, как детализацию предыдущего уровня. Таким образом операционный уровень, это не мелочи, а элементарные таски, которые предсказуемы и мы знаем как они _планово_ закроются.
А вы, как я понял, имеете в виду под операционным уровнем «вбросы» тасков отдельно от проектного уровня, «текучку».
Таким образом в одном случае оперативный уровень — это качественный инструмент прогнозирования для более высоких уровней, а во втором не прекращающийся аврал и прочий геморрой.
Тут даже не UserStory, а Epic на проектном уровне, т.е. цельный продукт или некое задание от бизнеса.
Операционный уровень — это UserStory или Task, о котором мы знаем, сколько ресурсов он потребует от нас для его выполнения (т.е. упрощенно — как минимум времени).
Таски предсказуемы, мы можем набросать некий набор тасков и сказать, через какой период времени мы закроем этот набор.
Соответственно с закрытием набора тасков у нас закрывается 1-2-… Эпика.
Т.е. я воспринял эти уровни, как детализацию предыдущего уровня. Таким образом операционный уровень, это не мелочи, а элементарные таски, которые предсказуемы и мы знаем как они _планово_ закроются.
А вы, как я понял, имеете в виду под операционным уровнем «вбросы» тасков отдельно от проектного уровня, «текучку».
Таким образом в одном случае оперативный уровень — это качественный инструмент прогнозирования для более высоких уровней, а во втором не прекращающийся аврал и прочий геморрой.
А, пардон, невнимательно прочитал, в целом согласен, только оперативный уровень без всех остальных это как раз второй описанный мной вариант.
Как-то все идеализировано.
В реальности нет, как Вы называете, чистого операционного подхода и чистого проектного. Даже при хреновом подходе этапы так или иначе есть всегда (если продукт подразумевается все-таки написать и продать, а не бесконечно писать). Скажем, тут у нас будут этапы эскизного проекта, экспериментального образца, опытного образца и т.д. И, в принципе, на каждом этапе более-менее понятно, что должно быть готово, в какой стадии и в каком виде.
А дальше мы берем операционный подход: делаем декомпозицию сложных задач на множество тасков, распределяем ее между работниками и пишем. Чтобы было понятно, что вообще происходит с проектом и как он развивается, вводим некоторых срок на закрытие тасков, именуемый спринтом, и обсуждаем, как оно и что.
Чисто операционный подход возможен, например, в стартапах, когда парни собрались в гараже и вообще не знают, куда им плыть. Если вектор ясен, тут точно будет симбиоз подходов.
Кстати, что касается чисто «проектного менеджера». Это зло. Можно посмотреть на примере Российской Федерации. Главный проектный менеджер в лице президента говорит: «Сделать хорошие дороги в стране!». Проектный менеджер в лице министра транспорта говорит: «На все не хватит, делаем хорошие дороги в Москве и области». Проектный менеджер в лице заместителя министра транспорта говорит: «Нахрен всю область, делаем дороги на Рублевском шоссе». А программист в лице таджика кладет асфальт там и так, где насяльника пальцем показал.
Т.е. и начинание хорошее, и слова правильные, но из-за того, что все «проектанты х***ы» ©, никакого пересекающегося с реальностью прогнозирования и проектирования нет.
В реальности нет, как Вы называете, чистого операционного подхода и чистого проектного. Даже при хреновом подходе этапы так или иначе есть всегда (если продукт подразумевается все-таки написать и продать, а не бесконечно писать). Скажем, тут у нас будут этапы эскизного проекта, экспериментального образца, опытного образца и т.д. И, в принципе, на каждом этапе более-менее понятно, что должно быть готово, в какой стадии и в каком виде.
А дальше мы берем операционный подход: делаем декомпозицию сложных задач на множество тасков, распределяем ее между работниками и пишем. Чтобы было понятно, что вообще происходит с проектом и как он развивается, вводим некоторых срок на закрытие тасков, именуемый спринтом, и обсуждаем, как оно и что.
Чисто операционный подход возможен, например, в стартапах, когда парни собрались в гараже и вообще не знают, куда им плыть. Если вектор ясен, тут точно будет симбиоз подходов.
Кстати, что касается чисто «проектного менеджера». Это зло. Можно посмотреть на примере Российской Федерации. Главный проектный менеджер в лице президента говорит: «Сделать хорошие дороги в стране!». Проектный менеджер в лице министра транспорта говорит: «На все не хватит, делаем хорошие дороги в Москве и области». Проектный менеджер в лице заместителя министра транспорта говорит: «Нахрен всю область, делаем дороги на Рублевском шоссе». А программист в лице таджика кладет асфальт там и так, где насяльника пальцем показал.
Т.е. и начинание хорошее, и слова правильные, но из-за того, что все «проектанты х***ы» ©, никакого пересекающегося с реальностью прогнозирования и проектирования нет.
Чисто операционный подход возможен, например, в стартапах, когда парни собрались в гараже и вообще не знают, куда им плыть. Если вектор ясен, тут точно будет симбиоз подходов.
Ну как минимум они знают стартап «чего» они хотят сделать, так что задача есть, просто не четкая и растянутая во времени :)
Как-то все идеализировано.
Все процессы, описанные выше (отклонения и прогнозы), у нас применялись на практике и это не теория.
На практике эти процессы переплетаются. Но замечу, что даже в лидирующих ИТ-компаниях проектное управление часто заканчивается после составления план-графика. Далее идет оперативное выполнение задач и решение возникающих проблем.
Кстати, что касается чисто «проектного менеджера». Это зло. Можно посмотреть на примере Российской Федерации.
Не берите пример с плохих менеджеров портфелей.
В РФ управление еще строится на поручениях. Переход к управлению через целевые программы еще только развивается. Даже Медведев еще не до конца понимает как это должно выглядить!
По-моему, вы всё напутали. Либо притянули за уши.
У любой организации всегда есть следующие активности: операционная и проектная. Как правильно сказали выше, они едва ли не противоположны друг другу по смысле. И они никак друг друга не замещают. Да, операционные отделы в любом проекте участвуют почти всегда, но…
Попробуйте, например, придти в бухгалтерию (типичный операционный отдел) с проектным подходом и посмотрите, что из этого получится.
Проект не может работать как конвейер, т.к. по определению это уникальная активность с конечной длительностью.
Короче говоря, операционный подход — это вряд ли про управление проектами.
У любой организации всегда есть следующие активности: операционная и проектная. Как правильно сказали выше, они едва ли не противоположны друг другу по смысле. И они никак друг друга не замещают. Да, операционные отделы в любом проекте участвуют почти всегда, но…
Попробуйте, например, придти в бухгалтерию (типичный операционный отдел) с проектным подходом и посмотрите, что из этого получится.
Проект не может работать как конвейер, т.к. по определению это уникальная активность с конечной длительностью.
Короче говоря, операционный подход — это вряд ли про управление проектами.
1. В статье идет речь не о терминологии, а подходах, применяемых к управлению проектами.
Приемы общего и операционного менеджмента применяются к управлению проектами (правильная постановка задач, мотивация команды и другое). Тут уж никуда не деться, менеджмент есть менеджмент.
2. Также при управлении проектами должны применяться и другие ПРОЕКТНЫЕ методы, не используемые в ОПЕРАЦИОННОМ менеджменте, например составление ИСР, метод освоенного объема, метод критического пути. Последний — очень важный метод, который позволяет спрогнозировать оставшийся путь проекта и скорректировать его, если проект отстает. Обычным операционными методами здесь не решить проблему.
3. Про присутствие операционной деятельности в проекте. Например, на одном из этапов вы внедряете систему в 50 магазинах розничной сети. У вас будут одинаковые операции при каждом внедрении:
— установка ПО
— передача инструкций по пользованию системы
— обучение основным приемам
и др.
Это ли не операционная деятельность? И хороший менеджер постарается систематизировать такой вид деятельности и создать «конвейер».
4. Еще раз скажу о своем опыте. Я взаимодействовал с ПМ-ами будучи менеджером проектного офиса в ИТ-компаниях из ТОП-30. Могу сказать из своего опыта, что многие из менеджеров работают по принципу «нужно решать задачи и проблемы по мере их поступления» (операционный подход). В проектном управлении этого недостаточно. В дополнении ко всему этому нужно регулярно смотреть в будущее, предугадывать проблемы и вовремя их предупреждать (проектный подход).
Приемы общего и операционного менеджмента применяются к управлению проектами (правильная постановка задач, мотивация команды и другое). Тут уж никуда не деться, менеджмент есть менеджмент.
2. Также при управлении проектами должны применяться и другие ПРОЕКТНЫЕ методы, не используемые в ОПЕРАЦИОННОМ менеджменте, например составление ИСР, метод освоенного объема, метод критического пути. Последний — очень важный метод, который позволяет спрогнозировать оставшийся путь проекта и скорректировать его, если проект отстает. Обычным операционными методами здесь не решить проблему.
3. Про присутствие операционной деятельности в проекте. Например, на одном из этапов вы внедряете систему в 50 магазинах розничной сети. У вас будут одинаковые операции при каждом внедрении:
— установка ПО
— передача инструкций по пользованию системы
— обучение основным приемам
и др.
Это ли не операционная деятельность? И хороший менеджер постарается систематизировать такой вид деятельности и создать «конвейер».
4. Еще раз скажу о своем опыте. Я взаимодействовал с ПМ-ами будучи менеджером проектного офиса в ИТ-компаниях из ТОП-30. Могу сказать из своего опыта, что многие из менеджеров работают по принципу «нужно решать задачи и проблемы по мере их поступления» (операционный подход). В проектном управлении этого недостаточно. В дополнении ко всему этому нужно регулярно смотреть в будущее, предугадывать проблемы и вовремя их предупреждать (проектный подход).
Т.е. вы в статье описали общие подходы, используемые в операционном и проектном менеджменте, так? Просто из текста это не понятно, читателю кажется, что вы пытались применять операционный менеджмент в управлении проектом и сравниваете результаты с проектным менеджментом. Понятно, что различные деятельности до опеределённого момента похожи друг на друга. Например, декомпозиция используется для решения задачи везде — от крупной компании до школьной контрольной работы. Но дальше всё будет по-другому.
Про внедрение системы в 50 розничных магазинах. Тут речь идёт скорее о 50 под-проектах, которые строго говоря будут разные, т.к. как минимум магазины расположены в географически разных точках, как минимум будет разная логистика, разные бюджеты (т.к. очевидно, что аренда будет разная) и ещё много чего разного. Даже если форумлировка задачи будет звучать одинаково, при дальнейшей декомпозиции (которой, возможно, и не будет) отличия рано или поздно проявятся. Так что я бы не назвал это операционной деятельностью. Понятное дело, что будут и общие части и было бы глупо эту общность не использовать, но в целом — это разные (под-)проекты.
В нефтедобывающей отрасли тоже, кажется, много операционной деятельности (утрированно, ибо не спец):
— Разработать месторождение
— Пробурить скважину
— Построить трубопровод
— Включить насосы
На деле же каждая из этих задач будет отличаться от проекта к проекту и операционной деятельностью это никак нельзя назвать.
ЗЫ: Опыт работы в ИТ компаниях из ТОП-30 — хороший опыт, однако, зная изнутри некоторые из этих компаний, могу сказать, что в очень многих случаях рассматривать их за образец точно не стоит.
Про внедрение системы в 50 розничных магазинах. Тут речь идёт скорее о 50 под-проектах, которые строго говоря будут разные, т.к. как минимум магазины расположены в географически разных точках, как минимум будет разная логистика, разные бюджеты (т.к. очевидно, что аренда будет разная) и ещё много чего разного. Даже если форумлировка задачи будет звучать одинаково, при дальнейшей декомпозиции (которой, возможно, и не будет) отличия рано или поздно проявятся. Так что я бы не назвал это операционной деятельностью. Понятное дело, что будут и общие части и было бы глупо эту общность не использовать, но в целом — это разные (под-)проекты.
В нефтедобывающей отрасли тоже, кажется, много операционной деятельности (утрированно, ибо не спец):
— Разработать месторождение
— Пробурить скважину
— Построить трубопровод
— Включить насосы
На деле же каждая из этих задач будет отличаться от проекта к проекту и операционной деятельностью это никак нельзя назвать.
ЗЫ: Опыт работы в ИТ компаниях из ТОП-30 — хороший опыт, однако, зная изнутри некоторые из этих компаний, могу сказать, что в очень многих случаях рассматривать их за образец точно не стоит.
50 одинаковых магазинов… в каждом по 50 одинаковых рабочих мест… на каждом по 50 инсталляций… Пусть не отличаются.
Тогда можно согласиться ведь, возможно организовать на время проекта некоторое производство. Функциональное подразделение внутри проекта. На обучение возить (наверное преподов, это быстрее и дешевле), компы подготавливать (в одном месте, это быстрее и дешевле), и так далее. Какие-то куски действительно можно пустить в поток. Однако это всё равно будет временным предприятием по достижению уникального результата, несмотря на то, что результат достигается организацией производства. Просто производственный объект — промежуточный результат проекта. Всё равно что мы бы написали кодогенератор для создания продукта предварительно.
Однако статья была не об этом. Статья была о том, что «выполняй и не думай» — это операционный (в понимании автора) подход, а проектный — «думай и выполняй». Вот весь спор в основном с тем, что операционный подход — это нечто иное (там тоже думай и выполняй с точки зрения управления), просто другая система. А мысль о том, что некоторые проекты управляются на «похрену мороз» (вот так в моём понимании называется «операционный подход»), пусть живет. Конечно это существует. И проблемы с этим связанные, очевидны.
Тогда можно согласиться ведь, возможно организовать на время проекта некоторое производство. Функциональное подразделение внутри проекта. На обучение возить (наверное преподов, это быстрее и дешевле), компы подготавливать (в одном месте, это быстрее и дешевле), и так далее. Какие-то куски действительно можно пустить в поток. Однако это всё равно будет временным предприятием по достижению уникального результата, несмотря на то, что результат достигается организацией производства. Просто производственный объект — промежуточный результат проекта. Всё равно что мы бы написали кодогенератор для создания продукта предварительно.
Однако статья была не об этом. Статья была о том, что «выполняй и не думай» — это операционный (в понимании автора) подход, а проектный — «думай и выполняй». Вот весь спор в основном с тем, что операционный подход — это нечто иное (там тоже думай и выполняй с точки зрения управления), просто другая система. А мысль о том, что некоторые проекты управляются на «похрену мороз» (вот так в моём понимании называется «операционный подход»), пусть живет. Конечно это существует. И проблемы с этим связанные, очевидны.
Sign up to leave a comment.
Управление проектами: операционный vs. проектный подход