Управление проектами: операционный vs. проектный подход

    В одном из комментариев к посту автора, многоуважаемого пользователями Habr, я ответил, что основной причиной неудач проекта является не использование методологий «через %опу» или «как получится», а наличие только операционного управления в рамках проекта. Проектный подход у таких менеджеров заканчивается уже после составления сметы проекта.
    В этом посте проведу более детальное сравнение операционного подхода с проектным.

    Уровни управления проектом




    1. Операционный уровень — это уровень операций длительностью несколько часов (обычно называемых «тасками») и проблем, возникающих по мере выполнения этих задач. На этом уровне скапливается много «мелочовки», здесь некогда думать, нужно быстро выполнять.
    2. Проектный уровень — это уровень работ длительностью несколько дней, блоков работ и контрольных точек. На этом уровне нужно больше анализировать, прогнозировать, нежели скорее запускать задачу в работу. Здесь также решаются проблемы, проводится дополнительная работа с рисками.
    3. Программный уровень — это уровень куратора проекта или менеджера программы/портфеля, который в меньшей степени погружен в проект, и его как правило интересует прохождение контрольных точек, решение крупных проблем и рисков.
    4. Ручное управление. Это самый простой, однако и самый влиятельный подход по сравнению с другими. Если «вождь» отдал поручение, то оно обязательно к исполнению, не важно что там в планах и программах. Вся работа строится на поручениях менеджера. Нет поручений — нет работы.
    Внимание! Все перечисленные подходы применяются при управлении проектом, а не какой-то один конкретный из них.

    Метафоры


    Ручное управление
    Образ — указать рукой на то, что нужно делать.

    Операционное управление
    Образ — конвейер.
    Мы настраиваем работу конвейера. Формируем задачи, передаем их в конвейер, а он дальше самостоятельно распределяет их между освободившимися участниками команды.
    Главный принцип:«Нормально делай — нормально и будет».

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

    Горизонты мышления


    Даже если вы используете самые навороченные системы для управления задачами и проектами, то ваш мозг, опять же даже, при подсказке ЭВМ не способен управлять всеми задачами, содержащимися в этих системах. Поэтому и в ваше поле зрение будет попадать ограниченная доля информации.
    Ниже приведено сравнение горизонтов мышления для операционного и проектного уровней управления.


    Операционный уровень

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

    Проектный уровень

    Проектный подход подразумевает под собой контроль всего проекта целиком. Однако на на практике для проектов длительностью около года и более не всегда целесообразно держать весь проект в поле зрения. Поэтому в таких ситуациях применяется метод «набегающий волны». Вначале берется в работу один этап, он детализируется на более мелкие работы(длительностью 2-3 месяца). Затем выполняется работа по управлению преимущественно только этим этапом. А затем при переходе на следующий этап «приходит следующая волна» и процесс повторяется снова. Однако проектный подход не ограничивается только управлением текущего этапа, периодически нужно смотреть в далекое будущее — на следующие этапы.
    Итак, горизонт мышления — этап проекта (проект целиком — для небольших проектов).

    Контроль выполнения


    Для чего нужен контроль и какие результаты контроля мы должны получить?

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


    Результатами процесса контроля должна быть следующая информация:
    — Статус (что выполнено, какие проблемы возникли?)
    Содержание: что выполнено
    Сроки: сколько времени было затрачено
    Стоимость: сколько денег было затрачено
    Изменения: какие запросы на изменения появились (с оценкой влияния на содержание/сроки/стоимость)
    Проблемы: какие проблемы возникают
    и другое

    — Отклонения (что не успели выполнить или перевыполнили?)
    Содержание: что не успели выполнить/перевыполнили относительно планируемого
    Сроки: на сколько времени отстали/опередили? сколько времени нужно, чтобы доделать запланированное
    Стоимость: сколько денег было перерасходавано/сэкономлено? сколько средств нужно, чтобы доделать запланированное
    и другое

    — Прогноз (что будет в будущем, когда и как будут пройдены контрольные точки, какие проблемы могу возникнуть?)
    Содержание: какие результаты будут достигнуты в будущем
    Сроки: когда будут пройдены контрольные точки
    Стоимость: сколько денег будет потрачено на проект в контрольных точках
    Изменения: перечисленные выше прогнозы должны быть приведены с учетом включения изменений
    Проблемы: какие риски и как на них реагировать (риски — это и есть возможные проблемы и возможности в будущем)
    и другое

    Как часто проводить контроль?

    Контроль операций — проводить постоянно.
    Контроль проекта — регулярно (1 раз в неделю, 1 раз в 2 недели).

    Вывод


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

    Оба эти подхода должны использоваться в проектной деятельности.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 60
    • +1
      Поправьте меня, если я заблуждаюсь, но слово «операционный» в описании подходов к управлению проектами для меня очень странно звучит.
      Хоть я и не PM, а только частично занимаюсь управлению проектами, но мне всегда казалось что операционная деятельность и проектная чуть ли не противоположные сущности по сути.
      • 0
        В проекте могут быть операции, если в орг.структуре проекта есть функциональные подразделения. Но о таких проектах вряд ли идет речь сейчас. Так что вы скорее правы.
        • –2
          Готов доказать, что проект содержит операционную деятельность.
          Но основное, что имелось в виду — это разница в подходах.
          Операционная деятельность похожа на конвейер с однотипными задачами, что вчера, что сегодня, что завтра. Нет смысла думать о будущем. «Нормально делай — нормально и будет». Главное отработать подход на нескольких задачах, дальше все пойдет как по маслу.
          «Проектеры» управляют «уникальными» результатами, поэтому завтра может сильно отличаться от вчера и сегодня. Поэтому нужно мыслить на перспективу и заранее предугадывать сценарии развития.

          И в дополнение, приемы, используемые в операционной деятельности, применимы и в проектной. Однако, проектная деятельность содержит ряд уникальных методов.
          Например, метод критического пути или метод освоенного объема.
          • 0
            Все таки для меня, в зависимости от того, на каком уровне ты находишься, одно и то же может быть как проектной так и операционной деятельность,
            Только вот если на твоем текущем уровне какие то задачи идут как операционная деятельность, не стоит смотреть на управление проектами.
            По тому же pmbok «And a project is unique in that it is not a routine operation».

            Но по моему я вас понял, вы хотели сказать, сильно утрируя, что при управлении проектом необходимо видеть и отслеживать весь путь до цели, с разной степенью детализации, в зависимости от этапов.
            Но если правильно провести инициализацию и планирования проекта, и отслеживать что с ним происходит и корректировать, то так и получится, а если так не сделать, то какое это уже управление проектом?)
            • 0
              Операции — это действия. То что непосредственно исполняется. Действия могут исполнятся в рамках проектов или бизнес-процессов.
              • –1
                как вы все просто описали!
                • +1
                  Распутываем дальше.
                  Не операционный уровень, а оперативный.

                  Проект управляется в разных режимах. У вас это уровни:
                  1 операционный (от дня, до недели)
                  2 среднесрочный (от месяца, до трех)
                  3 долгосрочный (на весь срок)

                  Для каждого режима свои планы. Самые точные — операционные.
                  • 0
                    Благодарю, в терминах вы внесли больше ясности.

                    Даже методы достижения среднесрочных целей отличаются для разных типов деятельности (операционной и проектной).

                    ОПЕРАЦИОННАЯ ДЕЯТЕЛЬНОСТЬ
                    Например в операционной деятельности, возьмем показатель — объем выручки.
                    Есть план на неделю, есть на квартал. Чтобы выполнить среднесрочный план, нужно наращивать количество выполненных операций (утрирую, поскольку одна продажа может принести 500 руб, а другая 5 000 руб.).

                    ПРОЕКТНАЯ ДЕЯТЕЛЬНОСТЬ
                    Для проектной деятельности обычным наращиванием выполненных операций не всегда возможно добиться результата.
                    Тут нужно использовать методы критического пути, освоенного объема, оценки по трем точкам и т.д. в зависимости от навыков менеджеров. Потому что можно выполнять быстро и много операций, а они окажутся не на критическом пути, и результат так и не будет достигнут.

                    Вот такую мысль я и пытался заложить в статью.

                    • 0
                      То, о чем вы пишите, это не операционная деятельность. А деятельность в бизнес-процессах. Процессная.

                      Виды организации деятельности (не полный список):
                      1 Проектная (даже стандарты есть, PM BOK, ISO 21500)
                      2 Бизнес-процессы (Тема зовется BPM, стандарт BPM BOK, нотации описания BPMN, idef0 — в какой-то мере, ARIS)
                      3 Поручения
                      4 Программы
                      и т.д.

                      Все виды комбинируются и часто взамосвязаны.

                      В основе всегда набор конкретных операций (действий) которые исполняются конкретными людьми, на операционном уровне.

                      PS Прошу прощения, сам ошибся.
                      1 это оперативный уровень, и оперативные планы.
                  • 0
                    Операция — неделимый на другие операции блок действий, результат которого можно зафиксировать как переход продукта из состояния А в состояние А', где A' — в идеале, конечный (на данном этапе) работоспособный вариант продукта.

                    Мне кажется, что стоит присмотреться к определению операции в технологических процессах на производстве и адаптировать к специфике IT:
                    «Операция — законченная часть технологического процесса обработки заготовки, выполняемая на одном рабочем месте (на одном станке) непрерывно до перехода к обработке следующей заготовки.» (источник: delta-grup.ru/bibliot/10/68.htm)
              • 0
                Если кратко: Проект — то что делается единоразово. Операционная деятельность — повторяющийся набор операций.
              • +1
                То, о чем Вы пишете, кратко называется видение (вижн) проекта. Любой кто читал руководство к своду знаний по управлению проектами, это достаточно очевидно. Вы хорошо пишете, но не задели самого интересного — что управлять можно только хвостом проекта.

                Про операции и про прочее: менеджер вынужден иметь дело со всем что происходит на проекте. У меня однажды две девушки поссорились на проекте, и я их мирил (обоим объяснил что обе неправы). Я это к чему. К тому что не надо ломать определения. Проект это временное предприятие по созданию уникального результата, а операции — это не уникальные повторющиеся действия. Не надо называть таски операциями. Задача менеджера проекта — управление проектом для достижения его целей, а чем управлять — дело вторичное (всем!).

                Мышление конечным результатом и сегодншними действиями и статусом проекта — это основной инструмент менеджера проектов. Если Ваш опыт говорит о менеджерах, которые не мыслят конечными результатами проекта — подсуньте тем менеджерам пмбок.
                • –4
                  Вы пишите:
                  Вы хорошо пишете, но не задели самого интересного — что управлять можно только хвостом проекта.

                  Видимо, вы умеете управлять только тем, что отчетливо видно. Тем что вы не можете видетЬ, вы не можете управлять. В конце всегда все четче видно, чем в начале. Если вы управляли только тасками, а не управляли проектом, то хвостом уже управлять бесполезно, там нужно только «дожимать». А потом еще долго-долго дорабатывать и исправлять.
                  Почитайте мою статью, как использовать MS Projetc в качестве навигатора проекта и прогнозировать картину на много дней и недель вперед. Имея прогноз, вы всегда можете скорректировать что-то. Не имея прогнозов, вы может только надеяться.

                  Если Ваш опыт говорит о менеджерах, которые не мыслят конечными результатами проекта — подсуньте тем менеджерам пмбок.

                  Мой опыт работы в компаниях, входящих в ТОП-30 ИТ-компаний России, говорит о том, что менеджеры неэффективно используют инструменты, описанные хотя бы в PMBOK.
                  Я видел, как люди люди, управляющие проектами с бюджетами, кратными сотням млн. руб. акцентируются на тасках в JIRA, а дальше недели они ничего не видят. В итоге и проект срывается. Сам управлял такими проектами и знаю разницу в подходах.

                  Если для вас полноценный контроль — это обычное дело, то ответьте себе на вопрос:
                  — На сколько дней ваш проект отстает от намеченных планов на сегодняшний день?
                  — Когда завершится ваш проект/этап проекта (прогнозы)?
                  Тоже самое попробуйте проделать с финансами.
                  • +4
                    Кажется, меня вы не поняли. И я читал вашу статью про прорджект. Выдаете сермяжную правду за откровения, что там, что здесь. Бюджетами и топами светить вряд ли делу поможет. Но не суть.

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

                    А про управление хвостом вообще какая-то примитивная истина на самом деле. Я ее упомянул лишь с той целью, что она иллюстрирует неплохо эту спортивную метафору с бильярдом (мне првда шахматы больше по душе, хотя динамическая сложность наверное одна и та же).
                    • 0
                      Но управлять надо и тем и другим, и несмотря на то что роли могут быть разделены — процесс тоже зона ответственности менеджера.
                      Для налаживания процессного управления хорошо бы иметь отдельного человека. В моем опыте это был руководитель отдела разработки. Процессы — его вотчина. Руководитель проекта в это не лезет, только на уровне готовности/неготовности/когда отдельных тасков.
                      • 0
                        В каких-то матрицах возможно делегировать.
                  • +2
                    Проект это временное предприятие по созданию уникального результата, а операции — это не уникальные повторющиеся действия. Не надо называть таски операциями. Задача менеджера проекта — управление проектом для достижения его целей, а чем управлять — дело вторичное (всем!).


                    Проектная и операционная деятельность — части одного целого. Помните круглый восточный знак слияния? Вот примерно так. Или, если угодно, в них есть что-то от фрактальной геометрии. Смотришь на общий рисунок — проект, однозначно. Всмотрелся в его участок — дык, процесс! Всмотрелся в участок процесса — снова проект! :)

                    Пример из жизни конторы-разработчика.

                    Уровень 1.
                    Процессы конторы рутинны: пресейл, контракт, работа, сдача, повторить. Чистой воды конвейер в несколько линий, которым надо управлять (чтобы не остаться в нужный момент без ресурсов, например).
                    Всматриваемся глубже.

                    Уровень 2.
                    Отдельные проекты конторы. Совершенно уникальные, со сроками, бюджетами, рисками. Классика.
                    Всматриваемся глубже.

                    Уровень 3.
                    Предположим, в конторе околоagile. В проекте — итерация за итерацией. Постановка — работа — контроль — повторить. Снова конвейер.
                    Всматриваемся глубже.

                    Уровень 4.
                    Внутри итерации результаты уникальны. Реализуются конкретные фичи, публикуются конкретные артефакты. Снова ресурсы и сроки. Проект!
                    Всматриваемся глубже.

                    Уровень 5.
                    Аналитик пишет постановку на итерацию. Встретился с заказчиком, написал что-то в спеку. Сбегал к архитектору, дописал. Созвонился с разработчиком — дописал. Получил доп. информацию еще из какого-то источника — внес. Повторить. Обратно, конвейер.
                    Всматриваемся глубже.

                    Уровень 6.
                    Отдельная встреча с заказчиком. Уникальное мероприятие со своими участниками (ресурсами), бюджетом (продолжительностью), сроками (датой). Уникальные результаты. Снова проект?
                    Всматриваемся глубже.

                    Уровень 7.
                    Поздоровались, расселись, давай допрашивать. Вопрос — ответ, следующий вопрос — еще ответ, повторить. Конвейер…
                    Всматриваемся глубже.

                    * * *

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


                    А если они мыслят не только конечными результатами проекта, способны заглянуть как в микро-, так и в макромир — выдайте им премию и повысьте. :)
                    • +1
                      Ну круто, что. We need to go deeper. Мы лезем в дебри терминологии, которая если не усложнять жизнь, проста до безобразия.

                      Водораздел, если быть кратким, следующий:
                      1. Операция и процесс требуют стандартных интерфейсов, таска, итерация, проект — нет.
                      2. Операция и процесс выдают результаты по запросу, таска, итерация, проект — один раз.
                      3. Конвейер — это когда над одними и теми же объектами производят последовательно одни и те же операции.
                      4. Проект — это когда также последовательно выполняют преобразования, но, над одним объектом.
                      • 0
                        Все верно.

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

                        А терминология… Если надо, любую терминологию можно притянуть к реалиям за какое-нибудь хваткое место. Не на другой планете же ее выдумали.
                        • 0
                          Характер деятельности описан в терминах. В проектах даже если что-то и повторяется, то это (за редкими исключениями, о которых я упоминал выше) нельзя назвать операцией. Но мысль Вашу я естественно понял. Я в курсе, что события в проекте можно рассматривать в разном масштабе. И что в некоторых масштабах можно увидеть повторения, как их не называй.

                          Это просто следствие наличия в проектах целенаправленных действий по снижению неопределенности (с будущим результатом, которого достигают, снижается она путем переделки промежуточных результатов). В случае с производственным конвейером (уж извините, вернусь к терминам), повторение имеет иную природу (для конвейера повторение — следствие целевой функции системы).
                          • +1
                            Как обычно — все зависит от точки зрения.

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

                            А вот руководить менеджерам приходится не абстрактными категориями вроде «проекта» а конкретным, живым мной. Биологическим конвейером, то бишь. :)
                        • 0
                          А теперь поднимитесь на ступеньку наверх, там где много проектов. Там сидит какой-то чел, у которого болит голова, чтобы проекты всегда попадали в заданное место пресловутого треугольника. И что ему делать? Поставить проекты на поток, т.е. наладить процесс, очевидно. Так проекты становятся процессом, оставаясь при этом проектами.
                          • 0
                            Там где проектов много, место называется офисом управления проектами, а сами проекты образуют портфель. Который, будучи согласован со стратегией (отвечаю на комментарий ниже), является вполне уникальным, хотя всех волнуют его фин. параметры. Управление проектом, проектами, портфелем может быть, а по PMI и должно, организовано в виде процессов, однако сами проекты и портфели процессами от этого не становятся, даже для фин. директора проект по фин. показателям отличается от процесса.

                            Конечно, для стандартной аутсорсинговой конторы велико желание «поставить на поток» и рассматривать проекты как операционную деятельность. С юридической точки зрения и с точкм зрения бухгалтерии это ввсе так и есть — продаются услуги чаще всего, а не продукты, но с точки зрения управления, услуга не будет оказана, если продукт не выгорит в том самом треугольнике.
                            • 0
                              «Портфель проектов», «стратегия», управление по PMI… Это круто, это можно дорого продать. :)

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

                              Пока мой опыт, включая работу в интеграторах из ТОП-..., показывает именно такую картину.
                              • 0
                                Такие компании пусть и дальше продают часы исполнителей, и изобретают «конвейер» для производства «единичных изделий» работниками интеллектуального труда. Я эту картину видел, в интеграторе работал. Их стратегия — обеспечить загрузку «мощностей» и поживать на марже с продажи (часов исполнителей). Это не проектный бизнес, это тупо услуги, им и PMBoK не нужен, проектное управление у них — способ выжать больше маржи из фиксированного бюджета.

                                Но я видел и другие картины. В компаниях, которые делают свои продукты и внедряют их. Когда представители топов и не очень объединяются в команду стратегической сессии, когда портфельный комитет рассматривает анализ портфеля, составленный ОУП, в котором расписано, сколько заработаем на несколько лет вперед и какие есть риски и альтернативы.

                                Спросите какого-нибудь топа из знакомых — что бы он предпочел — день «Д» или управляемую перспективу. А насчет дорого продать… кому надо, сам сможет, а у кого деньги шальные, так те пусть покупают очередной Lexus. Им ОУП может только для имиджа или маркетинга, или информационный повод. С такими тоже не очень приятно работать.
                                • 0
                                  Бизнес, может, и не проектный. Но отдельных проектов в нем — целые пачки. Это снова про перетекание одного в другое. Кстати, там же «в недрах», при наборе критической массы компетенций, иногда рождаются собственные продукты (решения).

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

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

                                  И… эх… вот если бы работать только с теми, с кем приятно!
                                  • 0
                                    По первым двум тезисам отвечу…

                                    Проектом это является формально, по факту — это заказ (подряд) по выполнению определенного объема работ. Собственные продукты рождаются… никто не спорит. Всё хорошо. Или будет хорошо. Я против интеграторов ничего не имею. Как и общего с ними сейчас. В будущем — как карта ляжет :)

                                    В наших реалиях сколько заработаем на несколько лет вперед — благие намерения? А давайте вообще не будем считать? Как я это назвал комментарием ниже — похрену мороз. Просто рынок имеет смысл представлять не как бюджеты заказчиков, которые надо освоить и инсайды о тендерах, а как тренды в потребностях и эффективностью внедряемого. Впрочем, рынок наш разнороден, поэтому универсального совета не дам. Хотя когда-то магистерскую как раз по этому вопросу и защищал…
                                    • 0
                                      А давайте вообще не будем считать?

                                      Нет, считать давайте будем. Разве я призывал к отказу от планирования? Я лишь говорю, что в достаточно нестабильной (в первую очередь, экономически и административно) ситуации заниматься такими расчетами без определенной доли скепсиса не стоит. Ну и разумеется, нужно быть готовыми перекраивать стратегические планы «в связи с вновь возникшими обстоятельствами».

                                      Просто рынок имеет смысл представлять не как бюджеты заказчиков, которые надо освоить и инсайды о тендерах, а как тренды в потребностях и эффективностью внедряемого

                                      Ох, как это непросто… И дорого. Но правильно. Но поскольку дорого, далеко не у всех контор и конторок хватит ресурсов и смелости гнуть такую линию, даже несмотря на куда большие потенциальные барыши. Вот и живут «от зарплаты до зарплаты» (неплохо, в принципе, живут). Может, со временем будут больше внимания уделять стратегическому развитию.
                                      • 0
                                        Согласен. Только прокомментирую следующее:
                                        в достаточно нестабильной (в первую очередь, экономически и административно) ситуации заниматься такими расчетами без определенной доли скепсиса не стоит


                                        У (в частности) портфельного управления есть достаточно интересные инструменты работы с рисками и альтернативами. Да и у проектного тоже есть. Те же Торнадо, Риск-Эффективность-Стоимость, Дорожные карты с вероятностями, Реальные опционы, Монте-Карло. Сейчас, когда принятие решения по проекту достаточно понятный критерий имеет (NPV > 0, кстати по упомянутому газовому контракту эксперты расходятся во мнении о его положительности:)), остается развивать эту науку (без кавычек) именно в направлении оценки рисков и повышения гибкости управления. Это всё кажется дорогим, но и этот продукт можно сделать массовым, как PMBoK пошел в массы. Просто у нас через печень принято решать чаще.
                                        • 0
                                          есть достаточно интересные инструменты работы с рисками и альтернативами.

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

                                          Сейчас, когда принятие решения по проекту достаточно понятный критерий имеет (NPV > 0,

                                          Почему именно этот критерий и именно с таким порогом? По мне, так из него одного вообще ничего непонятно.

                                          по упомянутому газовому контракту эксперты расходятся во мнении о его положительности:)

                                          Да, я ознакомился с мнением эксперта Латыниной. :)
                                          Я его упомянул как пример того, что даже после заключения контракта далеко не всем исполнителям будут докладывать о подробностях. Даже важных. Состоятельность планов в таких условиях соответствует.

                                          как PMBoK пошел в массы.

                                          Индекс цитирования у него классный. А вот реального применения как-то не особо заметно. Тут совсем недавно опрос был по применяемым в проектах разработки методикам. :)
                                          • 0
                                            с другой — не очень подходящей средой их применения
                                            Если речь о головах некоторых потребителей отчетности, то соглашусь.

                                            Почему именно этот критерий и именно с таким порогом? По мне, так из него одного вообще ничего непонятно.
                                            Для одного проекта всё так.

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

                                            Индекс цитирования у него классный. А вот реального применения как-то не особо заметно.
                                            По-крайней мере, обучения PMBoK и организации деятельности по нему, куда как больше (чем даже Agile). В ИТ действительно применяют не так часто, как могли бы. А в других отраслях (есть ведь конкурирующие стандарты, IPMA например исторически раньше был в России) он вполне приживается.

                                            Некоторые компании настолько круты, что для своих проектов (это не ИТ, а добыча, там мне тоже довелось поработать), имеют свои собственные методологии (не методики). И это вполне закономерно. Для средних же компаний можно найти продукт, который они смогут адаптировать, я считаю. И стать в управленческом плане более технологичными, и рынок станет более цивилизованным и предсказуемым для всех. Но для этого и действительно нужна смелость, как Вы подметили. Или мода.
                                            • 0
                                              Некоторые компании настолько круты, что для своих проектов… имеют свои собственные методологии

                                              Да, доводилось наблюдать.

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

                                              Тут у меня впечатления двойственные. За время знакомства с различными методологиями и методами управления (в основном, западного или японского происхождения) у меня сложилось впечатление, что их задача — не столько добиться максимальной эффективности в деятельности конкретной компании, сколько обеспечить некий средний уровень прозрачной управляемости, ниже которого она не упадет. И достигается это ценой искоренения попыток сделать шаг влево или вправо вне зависимости от того, насколько оно потенциально полезно. То есть, имеет место шлифовка инструментария стандартизированного управления усредненной биомассой на все случаи жизни, вне зависимости от объекта управления. И что характерно — эта задача решается.

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

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

                                              и рынок станет более цивилизованным и предсказуемым для всех.

                                              А вот это вряд ли зависит от технологий, применяемых внутри отдельных организаций. По крайней мере, далеко не в первую очередь. :)
                                              • 0
                                                А вы возьмите для примера 1С-франчайзинг. Куча компаний, и все обеспечивают какую-то норму. Я не обещал сверхуспешность (я вообще ничего не обещал). Я считаю, что именно управленческая технологичность — путь к цивилизованному рынку. Знаете другой?
                                                • 0
                                                  А вы возьмите для примера 1С-франчайзинг.

                                                  Франчайзинг в этом отношении не очень удачный пример. Он как раз и заключается в том, чтобы взять готовые схемы. И «не дай Бог...», а то отберут.

                                                  Я считаю, что именно управленческая технологичность — путь к цивилизованному рынку. Знаете другой?


                                                  Я просто не вижу, как управленческая технологичность связана с цивилизованностью рынка.

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

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

                                                  А вот увеличивать технологичность ваших семейных отношений с женой при этом совсем не обязательно.
                                                  • 0
                                                    В отличие от семейных отношений, компании имеют больше интерфейсов, и их содержимое — результат той технологичности о которой я говорю.
                                                    • 0
                                                      Скорее, все-таки результат нормативно-правового регулирования. В данном случае — регулирования деятельности и отношений хозяйствующих субъектов. :)

                                                      Не будь регулирования, содержимое интерфейсов быстро бы вернулось к «эффективному» по меркам начала-середины 90х годов.
                                                    • 0
                                                      Можно удешевить проект -в индивидуальном порядке заняться карате или магией…
                                                • 0
                                                  del
                                    • 0
                                      Leonid76, согласен. На деле то что называется программой или портфелем проектов является всего лишь набором проектов.
                                      Программа — поменьше проектов, портфель — потолще.
                                      Никто не управляет выгодами программы, а про портфели и стратегические цели — я тоже промолчу.

                                      У нас в России еще как следует не развито управление проектами, а тут уже люди управляют портфелями.
                                      • 0
                                        Ну, как сказать… «Управление портфелями» (и креслами) имеет очень давние, фактически многовековые корни. Как минимум, с Екатерининских времен. А то и с Петровских. :)
                              • 0
                                Справедливо, только не ясно что с этим делать :)
                              • 0
                                Проект это временное предприятие по созданию уникального результата
                                Тут стоило бы упомянуть, для кого этот результат уникален. Для фин.директора подрядной конторы, например, все проекты, которые делает контора, описываются конечным числом измеримых финансовых параметров.
                                • 0
                                  ncix, поддерживаю все комментарии, которые вы написали!
                                  • 0
                                    Спасибо, видимо у нас был схожий профессиональный опыт.
                              • +2
                                Теория, это хорошо. Почему только нету практикующих управителей проектов? :)
                                • +1
                                  Может вы не встречали таких?
                                  Все выше описанное мной и моими коллегами используется на практике.
                                  • 0
                                    Вероятно я действительно не там ищу ПМ-ов :)
                                • 0
                                  Эм… Тот подход, который вы называете «проектным» применяется при создании чего-то нового, например, «давайте перенесем все наши ресурсы в облако». Тот же, что тут называется «операционным» — применяется для стабильных, рутинных проектов, например, «окей, перенесли в облако, а теперь давайте это грамотно поддерживать». Не уверен, что совмещать оба подхода будет эффективно.
                                  • 0
                                    Это не подходы, а уровни. В статье это явно написано.
                                    Грубо говоря, проектный уровень — это User Story, а операционный — Task.
                                    • –1
                                      Вы правильно меня поняли.
                                      Грубо говоря операционный уровень — это где скапливается много мелочи и эту мелочь нужно оперативно закрывать.
                                      Именно так многие и работают. «У нас нет времени, некогда думать, нужно быстрее делать!»
                                      На проектном уровне — нужно больше анализировать, прогнозировать и на основании этого корректировать проект, если такие прогнозы не в вашу пользу.
                                      • 0
                                        Я это понял по другому.
                                        Тут даже не UserStory, а Epic на проектном уровне, т.е. цельный продукт или некое задание от бизнеса.
                                        Операционный уровень — это UserStory или Task, о котором мы знаем, сколько ресурсов он потребует от нас для его выполнения (т.е. упрощенно — как минимум времени).
                                        Таски предсказуемы, мы можем набросать некий набор тасков и сказать, через какой период времени мы закроем этот набор.
                                        Соответственно с закрытием набора тасков у нас закрывается 1-2-… Эпика.

                                        Т.е. я воспринял эти уровни, как детализацию предыдущего уровня. Таким образом операционный уровень, это не мелочи, а элементарные таски, которые предсказуемы и мы знаем как они _планово_ закроются.

                                        А вы, как я понял, имеете в виду под операционным уровнем «вбросы» тасков отдельно от проектного уровня, «текучку».
                                        Таким образом в одном случае оперативный уровень — это качественный инструмент прогнозирования для более высоких уровней, а во втором не прекращающийся аврал и прочий геморрой.
                                        • –2
                                          Я больше говорю о подходах
                                          Операционный подход — некогда думать, быстрее выполнять!
                                          Проектный уровень — больше анализа, больше управленческих маневров, больше эффективности.
                                        • 0
                                          А, пардон, невнимательно прочитал, в целом согласен, только оперативный уровень без всех остальных это как раз второй описанный мной вариант.
                                    • +1
                                      Как-то все идеализировано.
                                      В реальности нет, как Вы называете, чистого операционного подхода и чистого проектного. Даже при хреновом подходе этапы так или иначе есть всегда (если продукт подразумевается все-таки написать и продать, а не бесконечно писать). Скажем, тут у нас будут этапы эскизного проекта, экспериментального образца, опытного образца и т.д. И, в принципе, на каждом этапе более-менее понятно, что должно быть готово, в какой стадии и в каком виде.

                                      А дальше мы берем операционный подход: делаем декомпозицию сложных задач на множество тасков, распределяем ее между работниками и пишем. Чтобы было понятно, что вообще происходит с проектом и как он развивается, вводим некоторых срок на закрытие тасков, именуемый спринтом, и обсуждаем, как оно и что.

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

                                      Кстати, что касается чисто «проектного менеджера». Это зло. Можно посмотреть на примере Российской Федерации. Главный проектный менеджер в лице президента говорит: «Сделать хорошие дороги в стране!». Проектный менеджер в лице министра транспорта говорит: «На все не хватит, делаем хорошие дороги в Москве и области». Проектный менеджер в лице заместителя министра транспорта говорит: «Нахрен всю область, делаем дороги на Рублевском шоссе». А программист в лице таджика кладет асфальт там и так, где насяльника пальцем показал.
                                      Т.е. и начинание хорошее, и слова правильные, но из-за того, что все «проектанты х***ы» ©, никакого пересекающегося с реальностью прогнозирования и проектирования нет.
                                      • 0
                                        Чисто операционный подход возможен, например, в стартапах, когда парни собрались в гараже и вообще не знают, куда им плыть. Если вектор ясен, тут точно будет симбиоз подходов.


                                        Ну как минимум они знают стартап «чего» они хотят сделать, так что задача есть, просто не четкая и растянутая во времени :)
                                        • 0
                                          Как-то все идеализировано.

                                          Все процессы, описанные выше (отклонения и прогнозы), у нас применялись на практике и это не теория.

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

                                          Кстати, что касается чисто «проектного менеджера». Это зло. Можно посмотреть на примере Российской Федерации.

                                          Не берите пример с плохих менеджеров портфелей.
                                          В РФ управление еще строится на поручениях. Переход к управлению через целевые программы еще только развивается. Даже Медведев еще не до конца понимает как это должно выглядить!

                                        • 0
                                          По-моему, вы всё напутали. Либо притянули за уши.
                                          У любой организации всегда есть следующие активности: операционная и проектная. Как правильно сказали выше, они едва ли не противоположны друг другу по смысле. И они никак друг друга не замещают. Да, операционные отделы в любом проекте участвуют почти всегда, но…
                                          Попробуйте, например, придти в бухгалтерию (типичный операционный отдел) с проектным подходом и посмотрите, что из этого получится.
                                          Проект не может работать как конвейер, т.к. по определению это уникальная активность с конечной длительностью.
                                          Короче говоря, операционный подход — это вряд ли про управление проектами.
                                          • –1
                                            1. В статье идет речь не о терминологии, а подходах, применяемых к управлению проектами.
                                            Приемы общего и операционного менеджмента применяются к управлению проектами (правильная постановка задач, мотивация команды и другое). Тут уж никуда не деться, менеджмент есть менеджмент.

                                            2. Также при управлении проектами должны применяться и другие ПРОЕКТНЫЕ методы, не используемые в ОПЕРАЦИОННОМ менеджменте, например составление ИСР, метод освоенного объема, метод критического пути. Последний — очень важный метод, который позволяет спрогнозировать оставшийся путь проекта и скорректировать его, если проект отстает. Обычным операционными методами здесь не решить проблему.

                                            3. Про присутствие операционной деятельности в проекте. Например, на одном из этапов вы внедряете систему в 50 магазинах розничной сети. У вас будут одинаковые операции при каждом внедрении:
                                            — установка ПО
                                            — передача инструкций по пользованию системы
                                            — обучение основным приемам
                                            и др.
                                            Это ли не операционная деятельность? И хороший менеджер постарается систематизировать такой вид деятельности и создать «конвейер».

                                            4. Еще раз скажу о своем опыте. Я взаимодействовал с ПМ-ами будучи менеджером проектного офиса в ИТ-компаниях из ТОП-30. Могу сказать из своего опыта, что многие из менеджеров работают по принципу «нужно решать задачи и проблемы по мере их поступления» (операционный подход). В проектном управлении этого недостаточно. В дополнении ко всему этому нужно регулярно смотреть в будущее, предугадывать проблемы и вовремя их предупреждать (проектный подход).
                                            • 0
                                              Т.е. вы в статье описали общие подходы, используемые в операционном и проектном менеджменте, так? Просто из текста это не понятно, читателю кажется, что вы пытались применять операционный менеджмент в управлении проектом и сравниваете результаты с проектным менеджментом. Понятно, что различные деятельности до опеределённого момента похожи друг на друга. Например, декомпозиция используется для решения задачи везде — от крупной компании до школьной контрольной работы. Но дальше всё будет по-другому.

                                              Про внедрение системы в 50 розничных магазинах. Тут речь идёт скорее о 50 под-проектах, которые строго говоря будут разные, т.к. как минимум магазины расположены в географически разных точках, как минимум будет разная логистика, разные бюджеты (т.к. очевидно, что аренда будет разная) и ещё много чего разного. Даже если форумлировка задачи будет звучать одинаково, при дальнейшей декомпозиции (которой, возможно, и не будет) отличия рано или поздно проявятся. Так что я бы не назвал это операционной деятельностью. Понятное дело, что будут и общие части и было бы глупо эту общность не использовать, но в целом — это разные (под-)проекты.

                                              В нефтедобывающей отрасли тоже, кажется, много операционной деятельности (утрированно, ибо не спец):
                                              — Разработать месторождение
                                              — Пробурить скважину
                                              — Построить трубопровод
                                              — Включить насосы

                                              На деле же каждая из этих задач будет отличаться от проекта к проекту и операционной деятельностью это никак нельзя назвать.

                                              ЗЫ: Опыт работы в ИТ компаниях из ТОП-30 — хороший опыт, однако, зная изнутри некоторые из этих компаний, могу сказать, что в очень многих случаях рассматривать их за образец точно не стоит.
                                              • 0
                                                50 одинаковых магазинов… в каждом по 50 одинаковых рабочих мест… на каждом по 50 инсталляций… Пусть не отличаются.
                                                Тогда можно согласиться ведь, возможно организовать на время проекта некоторое производство. Функциональное подразделение внутри проекта. На обучение возить (наверное преподов, это быстрее и дешевле), компы подготавливать (в одном месте, это быстрее и дешевле), и так далее. Какие-то куски действительно можно пустить в поток. Однако это всё равно будет временным предприятием по достижению уникального результата, несмотря на то, что результат достигается организацией производства. Просто производственный объект — промежуточный результат проекта. Всё равно что мы бы написали кодогенератор для создания продукта предварительно.

                                                Однако статья была не об этом. Статья была о том, что «выполняй и не думай» — это операционный (в понимании автора) подход, а проектный — «думай и выполняй». Вот весь спор в основном с тем, что операционный подход — это нечто иное (там тоже думай и выполняй с точки зрения управления), просто другая система. А мысль о том, что некоторые проекты управляются на «похрену мороз» (вот так в моём понимании называется «операционный подход»), пусть живет. Конечно это существует. И проблемы с этим связанные, очевидны.

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.