Услуги в области ИТ. Матчасть – Часть 5. Не все проекты одинаково проекты

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

Именно это происходит с понятием «проект». Если есть ограничения по финансам, срокам и это делается один раз, то всё – это проект! Давайте воткнём управление проектом и всё будет хорошо!

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

Что такое настоящий проект?

Я смотрю на понятие проект глазами PRINCE2. Согласно PRINCE2 у проекта есть 3 порождающие одна другую категории того полезного, что возникает в ходе проекта:
  • Непосредственные «конечные продукты» на выходе проекта (Outputs). Это всё то осязаемое, что будет создано в рамках проекта и передано пользователям. Например,
    • «ПО для автоматизации процесса»;
    • «обновлённые рабочие инструкции процесса»;
    • «работающая служба поддержки автоматизации процесса».
  • «Конечные результаты» проекта (Outcomes). Это те результаты изменения в реальности, которые произошли в результате использования «продуктов» проекта и деятельности в рамках проекта. Например,
    • «повышение среднего количества заказов обрабатываемых в день на 10%».
  • «Выгоды» от проекта (Benefits). Это те измеримые выгоды (доходы, экономия, доля рынка и т.д.), которые были получены в результате того, что реальность после проекта стала другой. Например,
    • «снижение себестоимости обработки заказа на 10%»;
    • «повышение привлекательности у покупателей за счёт ускоренного на 10% времени обработки заказа».



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

Называть проект стоит, прежде всего, по конечным результатам. Соответственно то, что понимается, как «проект по разработке ПО», существующий внутри компании-получателя выгод, должен, например, пониматься как:
  • проект по повышению производительности процесса посредством автоматизации;
  • проект по созданию новой линии бизнеса вокруг создаваемого программного продукта
или как-нибудь ещё, в соответствии с осваиваемой проектом возможности получения выгод.

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

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

А чем тогда занимаются компании-разработчики заказного ПО?

А они занимаются деятельностью, которая в рамках Гражданского Кодекса (ГК) РФ классифицируется как «подряд». Подряд, как неудивительно, тоже имеет ограничение по срокам, финансам и делается обычно один раз.
Очень рекомендую всем разработчикам ПО на заказ почитать статьи 702-729 нашего ГК.

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



По своей сути, подряд – это профессиональная услуга для ИТ-проектов. И управляться он должен, прежде всего, как услуга.

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

Так как разработка ПО – дело дорогое и рискованное, то компания-подрядчик может завести у себя внутри суррогатный проект. Но все должны чётко понимать, что такой проект ни в коем случае не замена нормальному, полноценному проекту на стороне компании-получателя выгод. «Гальваническая развязка» услуги никуда не денется от того, что не то будут называть проектом…

Как выглядит настоящий проект

Упрощённая модель проектной организации согласно PRINCE2 изображена на диаграмме ниже.



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

Пример из жизни ICL Services


Проект по улучшению имиджа бренда ICL Services и созданию канала лидов посредством веб-сайта. Фактически он коротко назывался у нас внутри как «создание сайта», но это была правильно организованная с позиции PRINCE2 проектная деятельность. У нас был свой внутренний менеджер проекта, который раздавал большое количество задач внутри компании, управлял подрядчиком и организовывал взаимодействие всех участников и заинтересованных сторон.

Созданием автоматизации и визуального представления сайта занимался сторонний подрядчик. Несмотря на то, что наверняка у подрядчика работа кипела все это время, мне, как рядовому участнику и нерядовому заинтересованному лицу проекта, это было почти не заметно. Более того, работа на нашей стороне кипела ещё больше.
В рамках этого проекта помимо созданного подрядчиком сайта было сделано, как минимум:
  • большое количество материалов на русском языке;
  • процесс по отработке лидов с документацией и выделенными ресурсами;
  • процессы по актуализации материалов и содержимого сайта, как в маркетинговой, так и в HR-области.

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

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

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

Источники:
  1. Managing Successful Projects with PRINCE2®. 4.2 «Business case defined», 5.3 «The PRINCE2 approach to organization»
  2. Официальный русскоязычный глоссарий PRINCE2®
ICL Services
102.38
Цифровые технологии для бизнеса
Share post

Comments 9

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

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

    Если по понятиям не придираться, то мысль о разделении ответственности (между подрядчиком и заказчиком) известна всем, кто чуть больше полугода в сфере управления проектами проработал. Хотя статья озаглавлена как "… Матчасть...", так что тут не придраться.
      0
      я всё-таки настаиваю на предложенной терминологии: «проект» и «подряд», а не «проект» и «проект».
      Хотя всем снаружи вашей компании всё равно, как вы называете, то, чем занимаетесь, но у людей реальная каша в головах, когда проектом называют и проект и подряд.
      Сразу неконкретными становятся понятия «менеджер проекта», «требования проекта», «бюджет проекта», «сроки проекта» и т. п.
      В итоге начинают путаться и заказчик (особенно не очень зрелый), менеджер подряда и команда подрядчика. Люди начинают договариваться не понятно о чём.
      В общении с заказчиком имеет смысл разговаривать на его языке, исходя из его центра системы координат.

      Не согласен с введением понятия «инвестиционный проект». Настоящий проект — это не про увеличение свободных денег, а про увеличение стоимости компании (если с точки зрения финансистов).
      Проект — это способ реализации организационного изменения. А подряд — это способ реализации объёма работ.
      Подрядчик в рамках подряда ничего полезного для себя не создаёт, поэтому рассмотрение подряда как отдельного проекта, имеет мало смысла. Это действительно костыльно получается. Подряд в B2B всегда имеет смысл рассматривать как часть проекта и со стороны заказчика и со стороны подрядчика.
        0
        1. free cash flow ;)
        2. подряд — это не когда не создают полезное, это когда делают вместо кого-то, подряжаются. а проект — это когда временно делают некоторый результат. подряд — это юридический формат, проект — организационный. а по факту и то и то — выполняемые работы.

          0
          1. Увеличение стоимости компании — это про balance sheet, а не про cash flow. Надеюсь, вы понимаете разницу между тем, что описывается документами "cash flow statement", "balance sheet" и "income (или profit and loss) statement" и не надо писать статью про то, что не все деньги одинаково деньги.
          2. Вы можете, пожалуйста, привести пример, когда «когда делают вместо кого-то, подряжаются» и при этом «создают полезное для себя». И вам не кажется, что подряд тоже подпадает под определение «когда временно делают некоторый результат»?
          Процитирую сам себя, первый абзац:
          Предметные области услуг и управления в ИТ достаточно сложны и нетривиальны. Эта сложность происходит из-за неосязаемости большинства предметов в этих областях. Несмотря на это, люди почему-то используют очень простые подходы к классификации предметов. Буквально по нескольким атрибутам.
          Скажу честно, вы можете жить с подобным подходом, тратя время на решение заложенных в нём конфликтов, недопонимания и неверных ожиданий. Мы тоже тратили, и я всего лишь на хочу, чтобы кто-то другой ещё тратил. И плюс этот семантический хаос автоматизировать end-to-end нормально не сможете, если будете переходить на более крупный масштаб деятельности.
            0
            1. Вы не о том. Причем тут документы. Я про деньги. Если хотите, про NPV. Который (да) вклад в стоимость.
            2. Проект он и у подрядчика проект, и у заказчика проект, это разные проекты, но это проекты. «уникальный продукт, результат или услуга» — вот что результат проекта. Называть «подрядом» проект у исполнителя можно. Но от этого он не перестанет быть проектом, если им управляют как проектом.

            Проект — организационное понятие, подряд — юридическое.
            Догово́р подря́да — соглашение, в соответствии с которым одна сторона (подрядчик) обязуется выполнить по заданию другой стороны (заказчика) определённую работу и сдать её результат заказчику, а последний обязуется принять результат работы и оплатить его
            (Википедия)

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

            Скажу честно, вы можете жить с подобным подходом, тратя время на решение заложенных в нём конфликтов, недопонимания и неверных ожиданий.

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

              2. Есть подозрение, что вы совсем неточно используете термин "неграмотность".

              Проект — организационное понятие, подряд — юридическое.

              Совершенно верно. «Подряд» — это понятие делового оборота, закреплённое в юридической терминологии. Поэтому трактовать его можно достаточно узко и точно. В отличии, от понятия «проект», за неточное использование которого никому ничего не будет, кроме споров с коллегами.

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

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

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

              Заказчику может не быть никакого дела, как подряд выполняется, в форме проекта, или вообще как угодно.
              Это одна из мыслей, которую я и хотел донести. Заказчику абсолютно по фигу на ваш «проект», главное, чтобы вы выполняли ваш подряд.
          +1
          я всё-таки настаиваю на предложенной терминологии: «проект» и «подряд», а не «проект» и «проект».

          А почему не «проект» и «подпроект»?
          У проекта есть более-менее четкое и принятое определение, что-то вроде (к сожалению пишу на память) «набор взаимосвязанных работ, направленных на получение какого-либо результата, имеющего обычно уникальный характер».

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

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

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

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

          P.S. Прошу прощения, букв много получилось :)
        0
        В рамках организационной модели действительно можно выделить работы подрядчика как «подпроект». Но это необязательно.
        Если зависимости сильные, что возможно лучше будет работы подрядчика интегрировать в общий план проекта заказчика и рассматривать как «пакеты работ» (work packages) или даже прямо как отдельные «задачи».

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

        При этом подряд — это отдельная и явная единица управления. Менеджер «проекта» на стороне подрядчика является прежде всего менеджером подряда.
        Например, он должен оценивать и учитывать в смете не только затраты на выполнение работ проектного характера, но и затраты на выполнение всех обязательств, взятых в рамках подряда (например, гарантийные обязательства и т.п.). Он должен понимать договор конкретно его подряда, и знать права и обязанности подрядчика в рамках законодательства.

        Only users with full accounts can post comments. Log in, please.