Управляем стоимостью проекта с Earned Value Management

    Как измерять и контролировать эффективность исполнения планов проектов — такие вопросы являются постоянной головной болью их руководителей. Подходов к решению этих задач много. В данной статье мы рассмотрим основные элементы техники по управлению освоенным объемом (Earned Value Management, EVM), которая применяется повсеместно в проектах США, а у нас только набирает популярность в проектном управлении с учетом обновления Practice Standard for Earned Value Management, PMI. (В 2012 году я уже писал в одном известном в узких кругах журнале о ней.) Вы сможете узнать, как использовать EVM, а в комментариях давайте обсудим, у кого и как на опыте это получалось. В ЛАНИТ мы используем подходы Earned Value Management не везде, но стараемся применять лучшие техники. Также готовы поделиться своими наработками с вами.

    Источник

    Ключевые точки проекта


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

    Техника управления освоенным объемом Earned Value Management  помогает справиться с этими задачами. Она интегрирует в себе анализ всего объема работ по проекту с планом выполнения работ и стоимостью его выполнения. Благодаря ей, можно наблюдать за основными метриками состояния проекта и оценивать реальное положение дел, внося необходимые управленческие коррективы.

    Источник

    Выстраиваем работу по EVM


    Вы — руководитель и решили, что вы будете использовать Earned Value Management. Поговорим о практических шагах, которые вам необходимо предпринять. Сначала планирование проекта, затем измерение и анализ сроков выполнения работ и их стоимости по мере реализации проектных задач.

    Планируем


    Определяем полный объем работ: что должно быть разработано и поставлено заказчику. Объем указывается в содержании работ (Statement of work, SOW), у нас этот термин имеет привычные названия — тех.задание, технические/функциональные требования. На его основе составляется план выполнения проекта и рассчитывается стоимость. Начало простое, все как в классике.

    Источник

    Каждая работа разбивается на составляющие задачи, что позволяет лучше контролировать исполнение плана — производится декомпозиция работ. Ведь не даром «слона едят по частям».

    Иерархическая структура работ (ИСР, Work breakdown structure, WBS) позволяет уточнить проект до управляемых частей — элементов, которые охватывают весь объем работ. К листьям дерева WBS работы все более детализируются.

    Иерархическая структура работ создания программного продукта

    Теперь определяем исполнителей работ и их зоны ответственности — готовим организационную структуру проектной команды (ОС, Organizational breakdown structure, OBS).

    Организационная структура проектной команды

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

    Ответственность по этим точкам, роли участников указываем в матрице разграничения ответственности (Responsibility assignment matrix, RAM) — проводим пересечение WBS (скоупа работ, отвечая на вопрос «Что должно быть сделано?») и OBS (участников проекта, отвечая на вопрос «Кто ответственен за выполнение задачи?»), тем самым определяем ответственных по контрольным точкам. Один ответственный может отвечать за несколько контрольных точек, но контрольная точка не может быть контролируемой нескольким ответственными.

    На этом рисунке контрольные точки выделены желтым цветом.

    Определение контрольных точек

    Делаем основной план выполнения проекта (integrated master schedule, IMS). В плане все задачи разбиваем на этапы исполнения задач (до самого нижнего уровня WBS) с указанием их длительности и логических связей. Затем отмечаем бюджет для каждой задачи.
     
    Главный план выполнения проекта

    Составляем бюджет


    Для применения Earned Value Management план выполнения работ должен быть интегрирован с плановыми затратами по проекту. В самом конце планирования IMS (очень рекомендую именно тогда) необходимо разработать бюджет. Бюджет должен быть четко привязан к временным интервалам выполнения задач, чтобы понимать, когда и сколько бюджетных средств будет израсходовано.

    Источник

    Бюджет проекта — один из основных элементов Earned Value Management. Он учитывается:

    • в совокупной запланированной стоимости (Budget at completion, BAC), сюда не входят управленческие резервы;
    • в плановых значениях – плановый объем (Planned value, PV, или плановая стоимость запланированных работ, Budgeted cost of work scheduled, BCWS);
    • в «освоенных» значениях – освоенный объем (Earned value, EV) — отражение плановой стоимости фактически выполненного объема работ за определенный период времени; иногда его также называют плановой стоимостью выполненных работ (Budgeted cost of work performed, BCWP);
    • в фактических значениях – фактическая стоимость выполненных работ (Actual cost, AC, или Actual cost of work performed, ACWP).

    Вариант развития проекта. Пример отображения EV, PV и АС

    Из примера приведенного мной выше видна ситуация на проекте — аналитический блок работ выполнялся раньше времени, но с момента согласования требований началось отклонение от плана, в том числе и в разработке…

    Сумма всех бюджетов контрольных точек и еще нераспределенного бюджета является базовым уровнем измерения производительности (Performance measurement baseline, PMB). Он пригодится нам для сравнения стоимости в ходе реализации плана работ.

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

    Рассмотрим основные постулаты техники EVM:

    • в случае, если задача завершена, освоенный объем равен бюджету этой задачи,
    • в случае, если задача еще не началась, освоенный объем равен нулю,
    • в случае, если задача продолжается, освоенный объем равен её бюджету, умноженному на процент её выполнения.

    Измеряем прогресс


    Источник

    Существует несколько основных подходов определения прогресса выполнения задачи.

    Фиксированная формула
    Удобен для небольших задач. Пример такого подхода – метод 50/50, когда 50% завершения задач указываются при старте их выполнения, а остальные 50% — после завершения. Могут быть использованы альтернативные формулы 25/75 и 0/100. Моё же любимое соотношение – 10/70/20 (старт работ, значительное исполнение задачи, и завершение её выполнения) – позволяет пройти по трёхступенчатому процессу оценки 0% → 10% → 80% →100%.

    Взвешенные контрольные точки
    Эффективен для длительных задач, когда есть промежуточные результаты. Задача делится на части. Конец каждой части – контрольная точка. После достижения каждой контрольной точки задаче присваивается соответствующий процент ее выполнения.

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

    Если есть какие-то количественные показатели, то процент можно рассчитать на их основе. Например, мигрированно 65 356 элементов из 110 320, т.е. 59%.

    Распределенный объем работ
    Если задача связана с другой задачей, у которой есть свой EV, значение для зависимой задачи может быть определено на основе главной задачи. Такими могут быть синхронные задачи.

    Уровень загрузки (level of effort, LOE)
    Если результат задачи нематериален и другие перечисленные подходы не могут быть применены, то используем этот подход. Например, для таких задач, как управление проектом или техническое сопровождение пользователей – ответственные за задачи заняты на фиксированный % времени. Таким образом, достаточно просто вычислить, какой будет прогресс, если ответственные занимались этими задачами.

    Анализируем отклонения



    Earned Value Management позволяет выявлять возможные отклонения от планов с помощью анализа своих основных элементов — освоенного объема, плана выполнения работ и фактических расходов. На их основе можно определить:

    • отклонение по стоимости (cost variance, CV), указывается в абсолютных значениях и показывает перерасход или экономию на проекте;
    • отклонение по срокам (schedule variance, SV), указывается в абсолютных значениях и показывает запаздывание или опережение графика работ;
    • индекс стоимости выполнения (cost performance index, CPI), показывает, насколько эффективно команда проекта использует ресурсы;
    • индекс сроков выполнения (schedule performance index, SPI), показывает, насколько эффективно команда проекта использует свое время.

    Как же их вычислить? Формулы расчета просты. Вот они:
     
    $CV=EV-AC$; $SV=EV-PV$; $CPI=EV/AC$; $SPI=EV/PV$

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

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

    Состояние проекта в зависимости от показателей

    Прогнозируем


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

    Прогноз по завершению проекта (Estimate at completion, EAC)
    Позволяет определить, когда закончится проект и сколько в итоге средств уйдет на него с учетом текущего тренда.

    Отклонения по завершению (Variance at completion, VAC)
    Информирует об экономии или перерасходе средств в конце проекта в абсолютных или относительных величинах за период.

    Индекс производительности до завершения (To complete performance index, TCPI)
    Показывает необходимую эффективность использования командой оставшихся ресурсов, чтобы в конце стоимость соответствовала значениям BAC (или EAC, в случае если он был рассчитан экспертным методом). После определения индекса нужно определить, какие действия предпринять для изменения CPI в сторону нового значения, равного TCPI.

    Прогноз до завершения (Estimate to complete, ETC)
    Показывает ожидаемые затраты на выполнение оставшихся работ по проекту. Его можно рассчитать и экспертным путем, и с помощью математических расчетов на основе эффективности выполнения работ, определяемой CPI.

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

    Для понимания, как элементы EVM связаны друг с другом, ниже нарисую график зависимости элементов.


    Расчет всех элементов EVM привожу в интеллект-карте ниже в удобном для печати формате (считайте – шпаргалка).

    Элементы EVM и их расчетные формулы

    SV и SPI считаются на основе трудозатрат выполненных и запланированных работ. Поэтому возможна ситуация, когда работы будут завершены позже планового срока, но при этом показатели будут показывать идеальное состояние проекта — SV=0 и SPI=1. В этом случае применяется метод измерения производительности задач, когда используется время как основной показатель – вместо PV и EV необходимо использовать плановое время (PT) и фактически затраченное время (AT). Так, при выполнении всего объема работ и наличии задержки выполнения можно будет рассчитать альтернативные значения SV и SPI, акцентировав внимание на ней. Расчет для этих величин есть на схеме выше.

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

    Качественный отчет по анализу отклонений содержит:

    • описание проблемы,
    • причину отклонений,
    • меры для снижения влияния отклонения на проект.

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

    Источник

    Используем на практике


    Earned Value Management во всем мире зарекомендовала себя как полезный инструмент для контроля производительности и получения обратной связи о состоянии проекта в ходе управления им. За рубежом EVM активно используется такими компаниями, как IBM, Jacobs, Toshiba, SAP, Boeing. В России же её официально признают не так много компаний, например,  «Лукойл» и «Ренессанс Капитал».

    В своей практике в ЛАНИТ мы тоже используем технику Earned Value Management. А вы сталкивались в своей работе с EVM? Были ли вам полезны ее подходы?  Предлагаю высказаться в комментариях.

    Послесловие


    PMI развивает идеи ESM (earned schedule management) — управление освоенным графиком, применяя подходы EVM. Уже сейчас есть драфты используемых механик для целей ESM, позволяющие таргетированно контролировать критический путь и критическую цепь. Но это уже совсем другая история, которую могу рассказать, или о которой можете прочитать в стандарте Practice Standard for Earned Value Management, 2nd edition (2011), бесплатном приложении к PMBOK для членов PMI.

    А пока вы размышляете над прочитанным, решите небольшую задачку, ответы пишите в комментариях.

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

    А ситуация у него на проекте непростая.

    На проекте трудятся 3 программиста – Вячеслав, Роман и Егор (с заработной платой в 100 золотых в день) и 1 аналитик Петр (с заработной платой в 120 золотых в день), ну и конечно же он сам (с заработной платой в 143 золотых в день). На проектном комитете план проекта был принят с базовой длительностью 4 месяца.

    В начале выполнения проекта аналитик Петр с точностью до секунды уложился в сроки подготовки материалов для своих коллег программистов, постановки были выверены и согласованы с клиентом, спецификации для разработки были отточены до «11 знаков после запятой». И со спокойной совестью, уходя с работы, он написал письмо разработчикам о готовности материалов для них спустя две недели (как и было запланировано ранее) после старта своих работ. Но забыл приложить номер из Jira с материалами задач,  сервер почты как раз был недоступен, и письмо повисло в исходящих.

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

    К концу вторых суток Петя решил уточнить, всё ли в порядке, и что случилось, почему ребята не ответили в Jira, что взяли в работу. И тут проблема вскрылась. Так спешивший Пётр, не проконтролировав принятие задачи в работу, не зная того сам, поставил под сомнение отпуск Ивана.

    Впереди было чуть больше трех месяцев работы, спецификации и постановки не вызвали дополнительных вопросов, и команда работала стабильно, не перерабатывая (по 8 часов в день), все было на их стороне, чтобы сдать свою часть проекта в срок. Такая ситуация была до очередного дня рождения Ивана, который наступил спустя 2 месяца после начала проекта. После торжества Роман «сломался», и ушел на больничный на целых 2 недели. Понимая всю ответственность, Роман после выхода с больничного отрабатывал по 11 часов в день.

    И вот спустя неделю после выхода Романа из отпуска, наш Иван задался таким вопросом «Может ли он себе позволить отпуск в конце своего проекта?»


    Задание
    Помогите Ивану :) Может ли он идти в отпуск, согласно здравой логике после анализа CPI, SPI, SV, CV, TCPI. Приложите расчеты данных показателей и индикаторов, график EV/AC/PV.

    Правильно ответившие, welcome на собеседование.
    ГК ЛАНИТ
    242,00
    Ведущая многопрофильная группа ИТ-компаний в РФ
    Поделиться публикацией

    Комментарии 55

      0
      Не может. Потому, что на сдаче любого проекта выяснится, что сделано было не совсем то и так как ожидал заказчик (не важно как кропотливо были выверены требования) и придется этот вопрос в срочном порядке утрясать иначе денег от заказчика они не получат.

      Странно конечно, что во всей выкладке не ясно какая часть работ была выполнена по прошествии 11 недель из 16. Только это решает можно идти в отпуск или нет.
        +2
        Все зависит от Ивана, того, как он ведет внешние коммуникации и управление требованиями. Думаю, у него с этим проблем нет, знающий EVM знает правила эффективных коммуникаций и верные подходы и механики управления изменениями и требованиями.

        С точки зрения EV — выполнен ровно тот объем, который равен объему по затраченному времени. Вопрос действительно важный)
        +1
        Прекрасная статья! Практическоая иллюстрация к тому, что написано в PMBOK. Вдвойне приятно видеть столь системный подход к управлению проектами в российском бизнесе. Не далее чем 5 лет назад все эти наши руководства PMI в глаза называли «ненужной бюрократией». Который раз вижу российскую компанию, причём крупную, где проверенные временем методы используются и помогают зарабатывать деньги.
          +3
          Да, развитие идет, подходы применяются. Сейчас все больше маленьких компаний (с количеством сотрудников до 100-150) более зрелые, нежели гиганты (с точки зрения того же OPM3). Перестроить годами отработанный механизм сложно, если нет на то поддержки руководства, с этим у нас проблем нет =)
          0
          В задании сборище идиотов еще не сдали проект заказчику и началось — понос и золотуха. А потом еще удивляются. Таким товарищам никакие техники не помогут. Если это текущие реалии разработки на планете земля, то все понятно почему каждая вторая программа багнутая насквозь.
            +2
            Вообще проекты в IT — это темные лошадки с многими неизвестными.
            Топовые способы разработки и управления командой разработчиков можно пересчитать по пальцам двух рук) Но конечно нужно не забывать, что в жизни может случается все что угодно, и молния может ударить в одно место =) нужно быть готовым во все оружии.

            В этом случае я бы Ивану посоветовал задуматься о мотивации, не в классическом её бехевиаристском понимании, а в новых трендах — Мотивации 2.0 и коррекции окружения команды под идеологию "человеческого фактора" (есть такой замечательный труд Т.Листера и Т.ДеМарко)
            0

            Описана классическая схема управления проектом. Сразу возникает вопрос — а в чём отлчие от других?
            Проблемы здесь точно такие же.
            Во первых представляется крайне сомнительным что можно заранее расписать все задачи и определить из трудоёмкость. Это можно сделать только для очень простых проектов.
            Во вторых также крайне сомнительна возможность создать иерархию задач. Обычно иерархия недостаточно точно описывает систему.
            Ну и про Ивана — отпуск это святое, конечно он может уйти.

              +3
              Это не схема управления проектом. Управление проектом — это комплекс мероприятий и действий. Здесь же приведена методика контроля хода проекта, позволяющая делать прогноз по ходу проекта о его завершении с учетом финансовой составляющей.
              Попробуйте привести еще пару методик позволяющую строить такой прогноз =) и вы ответите на свой вопрос.

              При должном уровне компетенции, проектирования решений, наличии опыта, построить такие модели по проектам IT индустрии не представляет сложностей.
              Иерархия описывает не систему, а структуру работ — классическое понимание WBS или ИСР. Подробней можно прочитать в стандартах по управлению проектов от ведущих проектных институтов (как пример IPMA, PMI).
                0
                На мой взгляд иерархия не может правильно описать структуру работ. И от этого пойдут все остальные проблемы. Которые конечно есть и в остальных ведущих проектных институтах.
                  +2
                  Именно по этому ракеты летят в космос, запускаются крупные информационные системы, и появляются уникальные продукты на рынке, в том числе и на рынке IoT.
                    0
                    Это общие слова. Можно также сказать что именно поэтому ракеты падают и ряд уникальных проектов не появился на рынке.

                    У вас пример из области программирования. Вот простой пример который не укладывается в иерархию. Вводим допущение, что в компании, где работает Иван, Вячеслав и другие разработчики, в течении долгого времени разрабатывается какая то библиотека. На основе этой библиотеки делаются разные проекты для разных заказчиков. Библиотека развивается, каждый новый проект для заказчика вносит что то новое. Или улучшает старое. Команда программистов бережно относиться к этой библиотеке, её развивает, холит и лелеет.
                    В результате описать ВСЕ работы компании в виде иерархии не получается. В рамках проектного управления будет отдельный проект для библиотеки, отдельные проекты для каждого из заказчиков. Но это уже искусственное ограничение. Эти работы могут быть описаны в рамках сетевой модели, и это будет органично.
                      +1
                      Мы говорим о проектной деятельности, не операционной.
                      Развитие продукта подразумевает выполнение нескольких проектов / проведение операционной деятельности. То что вы написали — развитие продукта, здесь нужна другая компетенция, конечно компетенция проектного управленца нужна, но её не достаточно, для этого дополнительно необходимо еще навыки стратегического менеджмента и операционного управления.
                        0
                        Т.е. вы соглашаетесь с тем что для моего примера проектная деятельность является совершенно лишней?
                          +1
                          Ваш кейс — это развитие продукта, которое включает элементы проектного управления. Наличие только проектной деятельности возможно — но это будет совершенно не эффективно, необходимо использовать эффект синергии от схожих проектов и централизованного развития продукта.
                            0
                            Не совсем так. В моём случае предполагается разработка разнообразных новых продуктов. Я совершенно согласен что проектный подход в данном случае совершенно не нужен. Но это же типичная ситуация для многих компаний. И тогда возникает вопрос — а зачем нужен проектный подход или проектная деятельность? Откуда эти восторги про новое слово в разработке?
                              +1

                              Я не сказал, что проектный подход не нужен, он необходим, но не достаточен.


                              Этому слову в разработке IT в России, как минимум 15 лет, в мире же в IT проекты появились начиная с 50х годов. Сам руковожу проектами разработки уже более 10 лет, и поверьте именно такой подход наиболее эффективен для создания продуктов, программ и игр.
                              А вот методик разработки много, и в каждом проекте есть свои наиболее эффективные.

                                0
                                Когда я учился в институте (начало 90-х) нам рассказывали про системный подход. Если отвлечься от терминов — то примерно то же самое. В НИИ тоже было примерно то же самое, но опять же без модных терминов.
                                Так что проектный подход это просто модный термин. За ним стоит только одно — это система распределения денег. Собственно именно это является основным в PMBoK. Остальное — дымовая завеса. Где-то в какой то компании это сработало. Видимо в результате случайностей кто-то из авторитетных руководителей придумал схему и модный термин. У них получилось. А дальше просто образовался карго-культ. Вот давайте сделаем такие же названия и оно само образуется. И ещё метрики введём. И чем более непонятны метрики тем лучше.
                                Так что позвольте вам не поверить про наиболее эффективный подход. Проектный подход как то работает, он создаёт иллюзию контроля. Но считать его панацеей и серебрянной пулей как то странно.
            –1
            А вот вопрос — что делает в проекте Иван с зарплатой 143?
            Он что-то полезное делает?
            Или только руководит?
              +3
              Есть такое понятие проектное управление, включающее в себя как минимум 10 областей знаний =) в каждой из областей есть определенные мероприятия для качественного исполнения процесса. По этому вопросу могу посоветовать литературу в виде проектных стандартов, кстати ГОСТа по управлению проектами.
              Но самое главное — Иван первый кто берет на себя ответственность за успех проекта, в том числе, первый кто попадет под санкции.
              –1
              Я знаю про проектное управление. В вашем случае получается что Иван занимается только руководством проектом. Т.е. берёт ответственность, заполняет планы. На мой взгляд, он получает неоправданно много. Нормальный уровень оплаты — около 20.
                +2
                Иван занимается проектным управлением =) а не администрированием, это разные вещи.
                  0
                  Тогда попытайтесь сформулировать что он делает, но пожалуйста без отсылки к стандартам. Там слишком много воды.
                  И давайте уточним его квалификацию, что он вообще может делать.
                    +2
                    Без отсылки к стандартам:
                    — управление стоимостью проекта
                    — управление сроками проекта
                    — управление рисками проекта
                    — управление заинтересованными сторонами проекта
                    — управление поставками/закупками проекта
                    — управление содержанием проекта
                    — управление интеграцией проекта
                    — управление качеством проекта
                    — управление человеческими ресурсами проекта
                    — управление коммуникациями проекта
                      0
                      Опять же — это просто общие слова, за которыми ничего нет.
                      Вот давайте ещё раз рассмотрим вашу задачу:
                      В начале выполнения проекта аналитик Петр с точностью до секунды уложился в сроки подготовки материалов для своих коллег программистов, постановки были выверены и согласованы с клиентом, спецификации для разработки были отточены до «11 знаков после запятой».

                      Т.е. всё самое важное — сделал Пётр. По контексту видно что он не советовался с программистами и руководителем.
                      Что делал Иван в это время? Подходил и спрашивал «как дела ?»
                        +2
                        За этими словами находится огромный пласт работ =) Если будет интересно — попробую отразить в одной из следующих статей свои подходы в управлении при разработке программных продуктов, с раскрытием каждого из этих пунктов.

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

                        А еще, если ему руководство доверяет, он может делать пре-сейлы, сейлы и ап-сейлы по другим проектам =)
                          0
                          Вы сейчас сказали самую главную вещь — ему руководство доверяет. Отсюда следует — что остальным не доверяют. Или скажем аккуратнее — доверяют меньше. Но это уже вопрос к руководству — зачем брать на работу людей, которым они не доверяют.
                          То что вы написали про руководителя проекта это конечно классическое определение. Но оно ещё как то может быть оправдано для больших проектов. Но не для проекта в котором задействовано четыре человека.

                          Я не зря спросил про квалификацию Ивана. Давайте всё таки выясним что он может делать. Основные вопросы:
                          1. Он является специалистом в предметной области?
                          2. Он является программистом?
                          3. Он работал вместе с Петром над спецификациями? Т.е. он вообще знает что в проекте твориться?

                          Пока из ваших ответов я понял что он занимается общим руководством, для меня это означает что он является совершенно бесполезным человеком в этом проекте. Из этого вытекает следствие, что самое лучшее что он может сделать это уехать в отпуск. Это нужно что бы не мешаться под ногами у программистов в самый ответственный момент.
                            +2

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

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

                                  +2

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


                                  Теория штука такая, пока не будешь применять на практике, она работать не будет. Попробуйте, увидете.

                                    0
                                    Пробовал. Причём с разных сторон. Так что все мои высказывания на основе личного опыта.
                                      0
                                      А что по вашему опыту работает, если проектный подход не работает?
                                        0
                                        Например обычная иерархическая структура с профильными отделами или лабораториями. При условии что во главе отделов стоят наиболее опытные разработчики а не администраторы.
                                        Это кстати то что PMBoK сразу отвергает, утверждая что это неэффективная структура но не приводя убедительных доказательств.
                                          +2
                                          Цитату, пожалуйста, из PMBoK с отвержением такой структуры приведите.
                                            +2
                                            Вы или не читали PMBoK, или знаете его крайне поверхностно. И как мы уже выяснили — очень предвзято.
                                            PMBoK описывает разные варианты организационной структуры и как от этого зависит реализация проектов. Описанный вами вариант зачастую является наиболее неблагоприятным для проектной деятельности из-за больших информационных и управленческих издержек.
                                              0
                                              Как ни странно, но наиболее неблагоприятной структурой для проектной деятельности является проектная команда. Это сразу ограничивает кругозор рамками данного проекта. Это задаёт методику поведения — после нас хоть потоп. Т.е. сейчас сдадим и всё. Следующий проект с чистого листа.

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

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

                                              Давайте ещё раз рассмотрим гипотетическую ситуацию. Компания в течении долгого времени разрабатывает библиотеку. На основе этой библиотеки выполняются различные проекты для совершенно разных заказчиков. Где в этой структуре место для проектного подхода? Где место руководителя, где место программистов и главное — как и за что платить деньги программистам.
                                                +1
                                                Это сразу ограничивает кругозор рамками данного проекта.
                                                С одной стороны это не плохо, потому что одна из задач менеджера проекта — предотвратить расползание проекта (scope creep).
                                                С другой стороны есть такая штука как управление знаниями, библиотека извлеченных уроков и т.д. — чтобы не держать проекты в информационной изоляции.
                                                А так же есть программное и портфельное управление, обеспечивающее взаимодействие проектов между собой.
                                                Это задаёт методику поведения — после нас хоть потоп.
                                                Проект направлен на создание УНИКАЛЬНОГО продукта или услуги. Поддержка проекта после сдачи — задача важная, но относится к операционной деятельности. Частично относится к проекту, а в остальном — к портфельному уровню управления.
                                                Т.е. сейчас сдадим и всё. Следующий проект с чистого листа.
                                                Если проект нормально документировался, были оформлены извлеченные уроки и т.д. — это с успехом может быть взято в следующий проект.
                                                Только потому что это модно?
                                                Всё вы пытаетесь выставить PMBoK в уничижительном свете. А даже если и так, то он модный потому что… хороший?
                                                аргументов в защиту проектного подхода
                                                Давайте определимся с терминами. Если вы против проектного подхода, то есть некий не проектный? Это какой? Не проектный это по идее операционный подход. Попробуйте при операционном подходе сделать что-то уникальное в срок и бюджет.
                                                Проектный подход — ответ на высокую неопределенность и изменения. Я не буду вспоминать про Гантта, но такие инструменты как Метод критического пути и PERT появились в 40-х — 50-х годах ещё задолго до PMBoK и затем успешно в него вошли.
                                                Плюсы проектного подхода — в том числе в его универсальности. ГОСТ 34 расскажет вам как создать, испытать, задокументировать автоматизированную систему, но ничего не скажет про сроки и бюджет. И к созданию автомобиля его не особо применишь. А проектный подход создает управленческий каркас, внутрь которого помещается нужное техническое наполнение.
                                                Давайте ещё раз рассмотрим гипотетическую ситуацию. Компания в течении долгого времени разрабатывает библиотеку. На основе этой библиотеки выполняются различные проекты для совершенно разных заказчиков. Где в этой структуре место для проектного подхода? Где место руководителя, где место программистов и главное — как и за что платить деньги программистам.
                                                Проекты выполняются, но проектному подходу места нет? Это как? То, что вы описываете, по идее вотчина системной интеграции — адаптация «библиотеки» к ИС организации или к бизнес-процессам организации. Не понятно что мешает платить программистам по часам и возможно некоторый бонус за успешное завершение в срок.
                                                  0
                                                  Вот здесь мы опять подходим к сути:
                                                  Проект направлен на создание УНИКАЛЬНОГО продукта или услуги. Поддержка проекта после сдачи — задача важная, но относится к операционной деятельности. Частично относится к проекту, а в остальном — к портфельному уровню управления.

                                                  Что такое уникальный? Если в проекте задействовано 10% наработок от предыдущих это уникальный проект? А если 90%? А можно сказать что операционной деятельностью компании является разработка новых проектов?

                                                  В примере компании действительно выполняются проекты но нет места проектному подходу. К обсуждению нового проекта и выработке плана реализации привлекаются наиболее квалифицированные разработчики. Они принимают решения о модификации исходной библиотеки (если необходимо). Далее оперативное руководство выполняют руководители подразделений.

                                                  Платить программистам по часам это ПРИНЦИПИАЛЬНО не правильно. В долгосрочной перспективе это приведёт к тому, что программисты будут вырабатывать человеко часы а не программы. И вместо оптимальных решений будут искать решения которые позволят им заполнить человеко часы на проекте. Про единую библиотеку можно забыть. Так что в долгосрочной перспективе (десятки лет) проектный подход вреден.
                                                    +2
                                                    А вы упорный :)
                                                    Что такое уникальный? Если в проекте задействовано 10% наработок от предыдущих это уникальный проект? А если 90%? А можно сказать что операционной деятельностью компании является разработка новых проектов?

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

                                                    Вообще, если у вас такой негативный опыт с проектным управлением, то может, что-то в консерватории подправить? Ничего удивительного в таком положении вещей нет. Вот опрос ~120 руководителей проектов на одной из недавних конференций:

                                                    А про ЗП программистов я просто не понял ваш вопрос. Тут я не великий эксперт в системе оплаты труда именно программистов (как формируется премиальная часть, какие KPI и т.д.). У меня программных проектов очень мало, в основном интеграционные и поставочные.
                                                      0
                                                      А вы упорный :)

                                                      Рад стараться :-)

                                                      Вообще, если у вас такой негативный опыт с проектным управлением, то может, что-то в консерватории подправить?

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

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

                                                      График показывает что предпочтительная область проектного подхода — это разработка с нуля. Но это достаточно редко. По сути — это создание новой компании для новой деятельности. В реальности все разработки идут на основе предыдущего опыта. У нас норма это 80-90% задела. Если меньше — скорее всего не заработает.

                                                      А про ЗП программистов я просто не понял ваш вопрос.

                                                      Тут тоже всё просто — если вы собираетесь платить за отработанное время, то люди будут вырабатывать время. Если за результат — будут вырабатывать результат. Если результат будет представлен в виде KPI — будут вырабатывать KPI.
                                                      Причём здесь есть обратная зависимость. Идеальное состояние это когда люди не работают а результат есть. Классический пример — это ремонтная бригада на заводе Форда. Они получали деньги когда сидели в комнате отдыха. Также и с программистами. Надо что бы они минимальными усилиями получи максимальный результат. Оплата за отработанные часы в проекте это самый худший вариант из всех.
                                                        0
                                                        по другому нельзя работать.
                                                        Да почему же нельзя? Конечно можно. На PMBoK свет клином не сошелся, есть ещё семейство Agile подходов. Хотя в последней редакции PMBoK рассказали и об Agile.

                                                        Так вот, на «считаю ложными утверждения о том что проектный подход (и в частности PMBoK) это наше всё и по другому нельзя работать» вспомнился анекдот: «жили они плохо, но не долго».
                                                          0
                                                          Мне кажется, нужно просто встретиться и рассказать личные истории успеха, =)

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

                                                          Вопрос оплаты — это вопрос вторичный. Приведенный вами пример — пример не из проектной деятельности. Подходы Форда верные, но они в операционке — не забывайте.

                                                          Есть замечательные специалист которые на своем опыте могут вам рассказать что такое проектный подход и как его внедрять, крайне советую. Но как минимум — ознакомьтесь с книгами, которые я порекомендовал. А потом, предлагаю обсудить =)
                                                            0
                                                            Я прочитаю ещё раз.

                                                            Весь мир живет в проектном управлении

                                                            Не надо говорить за весь мир, это не так.

                                                            Есть замечательные специалист которые на своем опыте могут вам рассказать что такое проектный подход и как его внедрять

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

                                                            А потом, предлагаю обсудить =)

                                                            Тоже хорошая мысль. Обсудим.
                      +3
                      Спасибо. Было интересно решать ваш кейс: docs.google.com/spreadsheets/d/12t7sEcJb_Ik29YT-jG3eOj8GmFvqnylZFLkqfdMBUQg/edit?usp=sharing
                        +1
                        Спасибо, за удобочитаемый расчет. Посмотрим ближе к ночи :)
                          0
                          На мой взгляд — абсолютно оторвано от реальности.
                            +2
                            Поясните, что именно? EVM позволяет в цифрах оценить текущий статус проекта. Как интерпретировать эти цифры — уже задача проектного менеджера. Это всего лишь еще один взгляд на ситуацию на проекте и ответ на вопрос «Как дела?»
                              +1
                              Совершенно верно. Это средняя температура по больнице. Опытный главврач может по увеличению температуры определить что началась эпидемия.
                              Но я подвергаю сомнению самые основы — откуда взялись эти цифры. Например с трудоёмкостями. Например можно посчитать поставленные задачи и выполненные. Получаем процент. Вот только чего? Задачи равнозначные? Или есть какая-то сложная задача и много мелких.
                              Но перед самой сдачей проекта средняя температура не имеет никакого смысла. Имеет значение только список не сделанных задач. Причём каждая задача требует индивидуальной оценки. А здесь мы опять возвращаемся к вопросу о квалификации руководителя проекта.
                                +2
                                Это средняя температура по больнице

                                Все верно. Оценка по EVM нужна чтобы РП ( а на самом деле куратор проекта, который выделяет бюджет) понял — проект сейчас ОК или не ОК. Детали и причины конечно же одной двумя цифрами не раскрываются. Но если у вас индекс 0.6, то объяснить, что все идет нормально вам будет трудновато )

                                Но я подвергаю сомнению самые основы — откуда взялись эти цифры. Например с трудоёмкостями. Например можно посчитать поставленные задачи и выполненные. Получаем процент. Вот только чего? Задачи равнозначные?

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

                                На самом деле EVM позволяет учитывать и декомпозицию работ. Только все работы нужно оценивать в одних у.е. = деньгах, часах, попугаях, кому как нравится.
                                  0
                                  Наверное при цифре 0.6 будет сложно сказать что всё Ок. Но я боюсь что сотрудники очень быстро научатся делать нужные цифры. И очень скоро будет показатель 0.99 но при этом до полной готовности будет очень далеко.
                                    +2
                                    Вы слишком негативны настроены на восприятие нового.
                                    Если с первого раза не получиться применить технологию, обращайтесь, поможем.

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

                        Самое читаемое