Услуги в области ИТ. Матчасть – Часть 5. Не все проекты одинаково проекты
Предметные области услуг и управления в ИТ достаточно сложны и нетривиальны. Эта сложность происходит из-за неосязаемости большинства предметов в этих областях. Несмотря на это, люди почему-то используют очень простые подходы к классификации предметов. Буквально по нескольким атрибутам.
Именно это происходит с понятием «проект». Если есть ограничения по финансам, срокам и это делается один раз, то всё — это проект! Давайте воткнём управление проектом и всё будет хорошо!
Но хорошо не будет, особенно если это «проект по разработке ПО». Если какая-либо деятельность заинтересованными лицами воспринимается именно так, то это НЕ проект и/или проект, но с огромными разочарованиями и болью в конце.
Что такое настоящий проект?
Я смотрю на понятие проект глазами PRINCE2. Согласно PRINCE2 у проекта есть 3 порождающие одна другую категории того полезного, что возникает в ходе проекта:
- Непосредственные »конечные продукты» на выходе проекта (Outputs). Это всё то осязаемое, что будет создано в рамках проекта и передано пользователям. Например,
- «ПО для автоматизации процесса»;
- «обновлённые рабочие инструкции процесса»;
- «работающая служба поддержки автоматизации процесса».
- »Конечные результаты» проекта (Outcomes). Это те результаты изменения в реальности, которые произошли в результате использования «продуктов» проекта и деятельности в рамках проекта. Например,
- «повышение среднего количества заказов обрабатываемых в день на 10%».
- »Выгоды» от проекта (Benefits). Это те измеримые выгоды (доходы, экономия, доля рынка и т.д.), которые были получены в результате того, что реальность после проекта стала другой. Например,
- «снижение себестоимости обработки заказа на 10%»;
- «повышение привлекательности у покупателей за счёт ускоренного на 10% времени обработки заказа».
Другими словами, настоящий проект — это всегда организационное изменение, и связка «продукты — конечные результаты — выгоды» всегда должна находиться в поле зрения. А организационное изменение по-настоящему может осуществляться только изнутри компании. Соответственно, настоящим проектом может называться и пониматься только та временная организация, управление которой находится в компании-получателе выгод и конечных результатов от этого проекта. Фактически, компания даёт менеджеру настоящего проекта полномочия её (компанию) менять.
Называть проект стоит, прежде всего, по конечным результатам. Соответственно то, что понимается, как «проект по разработке ПО», существующий внутри компании-получателя выгод, должен, например, пониматься как:
- проект по повышению производительности процесса посредством автоматизации;
- проект по созданию новой линии бизнеса вокруг создаваемого программного продукта
или как-нибудь ещё, в соответствии с осваиваемой проектом возможности получения выгод.
Как вы думаете, как много общего между двумя вышеперечисленными «проектами по разработке ПО»? Надеюсь, что разница понятна, и что словосочетание «проект по разработке ПО» теперь будет звучать для вас как «проект по сборке молотка».
Не должно быть проектов, которые создают ПО. Это прекрасные проекты для разработчиков ПО, но ужасные проекты для бизнеса. Проект должен реализовывать изменение бизнеса, изменения поведения и/или способов работы людей и ещё до завершения демонстрировать измеримый положительный эффект. Люди в значительной массе не любят изменений, и любое нововведение будет вызывать у них сопротивление. И для любого настоящего проекта это один из самых больших рисков, без устранения которого проект не должен закрываться.
А чем тогда занимаются компании-разработчики заказного ПО?
А они занимаются деятельностью, которая в рамках Гражданского Кодекса (ГК) РФ классифицируется как »подряд». Подряд, как неудивительно, тоже имеет ограничение по срокам, финансам и делается обычно один раз.
Очень рекомендую всем разработчикам ПО на заказ почитать статьи 702–729 нашего ГК.
Соответственно то, что называется «проектом по разработке ПО», существующим вне компании-получателя выгод, является ничем иным как «подрядом на разработку ПО». Именно по этой причине подобная деятельность должна оформляться договором подряда, а, например, не договором на оказание услуг.
Ниже привожу сравнительную таблицу, которая поможет вам лучше различать «проект» и «подряд».
По своей сути, подряд — это профессиональная услуга для ИТ-проектов. И управляться он должен, прежде всего, как услуга.
Если на стороне компании-получателя выгод проектная организация не сформирована, то шансы на провал проекта заметно возрастают. Подряд — это НЕ настоящий проект и подрядчик не может эффективно делать следующие критически важные для успеха проекта вещи:
- выявлять все заинтересованные стороны, особенно в крупном бизнесе;
- своевременно реагировать на изменения бизнеса;
- предлагать изменения, которые будут сочетаться со стратегией компании и другими проектами;
- мотивировать или заставлять сотрудников компании-получателя выгод делать необходимые для успеха проекта вещи.
Так как разработка ПО — дело дорогое и рискованное, то компания-подрядчик может завести у себя внутри суррогатный проект. Но все должны чётко понимать, что такой проект ни в коем случае не замена нормальному, полноценному проекту на стороне компании-получателя выгод. «Гальваническая развязка» услуги никуда не денется от того, что не то будут называть проектом…
Как выглядит настоящий проект
Упрощённая модель проектной организации согласно PRINCE2 изображена на диаграмме ниже.
Как вы можете увидеть, подрядчик — это тоже участник проекта, но настоящий проект — это гораздо больше чем подряд.
С другой стороны, для того, чтобы подрядчик был максимально эффективным участником проекта, необходимо прикладывать усилия, для того, чтобы он понимал суть проекта, для которого он разрабатывает продукт, а также знал, что происходит у других участников.
Пример из жизни ICL Services
Проект по улучшению имиджа бренда ICL Services и созданию канала лидов посредством веб-сайта. Фактически он коротко назывался у нас внутри как «создание сайта», но это была правильно организованная с позиции PRINCE2 проектная деятельность. У нас был свой внутренний менеджер проекта, который раздавал большое количество задач внутри компании, управлял подрядчиком и организовывал взаимодействие всех участников и заинтересованных сторон.
Созданием автоматизации и визуального представления сайта занимался сторонний подрядчик. Несмотря на то, что наверняка у подрядчика работа кипела все это время, мне, как рядовому участнику и нерядовому заинтересованному лицу проекта, это было почти не заметно. Более того, работа на нашей стороне кипела ещё больше.
В рамках этого проекта помимо созданного подрядчиком сайта было сделано, как минимум:
- большое количество материалов на русском языке;
- процесс по отработке лидов с документацией и выделенными ресурсами;
- процессы по актуализации материалов и содержимого сайта, как в маркетинговой, так и в HR-области.
Кроме того, в приёмочное тестирование (валидацию) сайта был вовлечён весь топ-менеджмент. Какое бы качественное тестирование (верификацию) на своей стороне не организовал подрядчик, финальную валидацию могут сделать только те, кому придётся пользоваться ПО и/или отвечать за него. Проект завершился заметно позже приёмки сайта как результата работы подрядчика. Он финишировал после приёмки сайта как конечного продукта проекта.
В результате на выходе проекта мы получили не просто веб-приложение, доступное из Интернета, а работающий инструмент, вплетённый в процессы компании.
Ни один подрядчик не сделает этого за вас. Ни один подрядчик не сможет замотивировать или заставить использовать сотрудников вашей компании разработанную им систему максимально эффективно. Это ваша работа, которую стоит делать в рамках настоящего проекта.
Источники:
- Managing Successful Projects with PRINCE2®. 4.2 «Business case defined», 5.3 «The PRINCE2 approach to organization»
- Официальный русскоязычный глоссарий PRINCE2®
© Megamozg
