Оригинал: Orchestrating Rapid and Successful Proofs of Concept
Автор: Майлз Суер (Myles Suer)
В своей книге «Гипотеза новатора» Михаэль Шраге (Michael Schrage) подчеркивает роль недорогих экспериментов. В переосмыслении будущего корпораций первую скрипку сегодня играют ИТ-директора. И важная станция на этом пути — демонстрационный пилотный проект (Proof of Concept, POC).
По словам Риты Макграт (Rita McGrath), POC полезен в ситуации, когда «непроверенные предположения принимаются за факты, и руководство, не вникая в детали проекта, отдает команду — полный вперед к новой операционной модели, и наплевать на мины по курсу». Макграт говорит: «прототип — отличный способ узнать мнение клиентов об предлагаемых инновациях, прежде чем начинать вкладывать в них массу ресурсов». Итак, когда и как ИТ-директор должен использовать POC?
В каких проектах следует использовать POC
POC помогает обосновать инвестиции в новое решение — говорит ИТ-директор Антони Макмахон (Anthohny McMahon). «POC должен быть недорогим, а его отмена не должна приводить к негативным последствиям.»
ИТ-директор Педро Мартинес Пуиг (Pedro Martinez Puig) подчеркивает, что для успеха POC важно вовлечение заинтересованных сторон. «От POC выигрывает любая перспективная идея, требующая поддержки нескольких заинтересованных сторон. Один POC лучше тысячи слайдов как по убедительности, так по возможности получить ценную обратную связь на ранней стадии проекта.» В числе прочего, POC должен продемонстрировать, что предлагаемое решение подойдет для удаленной работы.
Бывший ИТ-директор Джоанна Янг (Joanna Young) предлагает простое правило: «чем сильнее решение сказывается на предлагаемых клиентам продуктах и услугах, тем важнее выполнить надежный POC». Что касается целей, ИТ-директор Джонатан Фельдман (Jonathan Feldman) говорит: «POC должен уменьшить бизнес-риски».
В добавление к этому, бывший ИТ-директор Тим Макбрин (Tim McBreen) считает, что «проектами POC следует руководить, как и реальными проектами, а также управлять ожиданиями заинтересованных сторон». По словам аналитика Диона Хинчклиффа (Dion Hinchcliffe), это нужно в том числе для того, чтобы «проверить с помощью POC способность и аппетит организации к изменениям. Сильный ИТ-директор может это оценить, опираясь на свою интуицию и опыт.» С точки зрения Хинчклиффа, «POC является бесценным способом уточнения требований не только в инновационных проектах, но и в любой новой, неизвестной, непроверенной или неподтвержденной области».
Привязывайте POC к бизнес-целям, демонстрируя потенциальную выгоду
Вовлекая заинтересованные стороны, ИТ-директор должен заранее договориться о критериях успеха POC и последующего внедрения, говорит Кэти Роуз (Katie Rose), руководитель отдела ИТ-стратегии, планирования и архитектуры. «Это внесет ясность относительно того, получили ли вы ожидаемые выгоды. Эти критерии должны отражать взгляд конечных пользователей, бизнес-функции и ИТ-службы. Они должны следовать из тщательно подготовленного бизнес-обоснования.» Хинчклифф продолжил констатацией: «Реальный и практический ответ на большинство вопросов относительно рентабельности инвестиций в ИТ — наглядная демонстрация получаемых выгод. В противном случае POC не приблизит вас к внедрению. Но идеальный вариант — сравнить значения KPI для текущих методов работы с показателями по результатам POC.»
Стив Джонс (Steve Jones), главный архитектор данных в Capgemini, подчеркивает важность «подтверждения полезности в противоположность POC, как подтверждения технологической концепции. Подтверждение полезности отталкивается не от технологий — от него ожидается бизнес-обоснование, а не амбициозные планы в отношении технологий. Если только вы не являетесь чисто ИТ-компанией, подтверждение технологической концепции редко бывает оправданным, учитывая, что другие уже это делали.» Джоанна Янг соглашается: «если бы мне платили по доллару каждый раз, когда в результате POC обнаруживалось что-то новое или первоначальные требования становились неактуальными, то я была бы богачом». Директор по информационным технологиям Питер Никол (Peter Nichol) добавляет: «важно, чтобы POC проверял реалистичность бизнес-обоснования. Если не получается, то это не значит, что технология или инновация не работоспособны — это означает, что технология не самая оптимальная для данной бизнес-проблемы.»
В каких ситуациях стоит договариваться с вендором о POC и что он должен подтвердить
Джоанна Янг повторяет высказанную ею мысль: «чем сильнее решение скажется на клиентах, тем POC нужнее и тем четче следует его фиксировать в договорных документах». Хинчклифф говорит, что обращаться к вендору за POC в первую очередь следует в следующих ситуациях:
- пригодность сомнительна
- стоимость и/или сложность внедрения трудно оценить
- обещаний много, но непонятно, удастся ли их реализовать
- необходимо убедиться в наличии необходимых навыков у ИТ-команды
- технология не проверена
Без участия требуемых заинтересованных сторон в POC от начала и до конца необходимая информация не будет получена. Не привлекать к POC большого внимания иногда бывает полезно, но это может привести к тому, что результат не будет должным образом зафиксирован и доведен до сведения заинтересованных сторон.
Советы по организации успешного POC
Джоанна Янг утверждает, что крайне важно «определить рамки POC и, в идеале, сохранить его небольшим. Хорошая идея — реализовать серию POC вместо одного мега-POC.
Очень важно определить критерии успеха.
Хорошая документация важна, но не пытайтесь объять необъятное.
Хинчклифф добавляет: «как минимум, я бы попросил, чтобы проект POC продемонстрировал следующее:
- Да или нет в ответ на гипотезу, для проверки которой был инициирован POC.
- Оценка времени реализации при более масштабном использовании.
- Какие преимущества по сравнению с другими методами достигаются по осям сроки — стоимость — объемы?»
Заключительные слова
Несколько лет назад я встречался с корпоративным архитектором крупного канадского банка. Он рассказал мне страшную историю о традиционном каскадном («водопадном») управлении проектом. В качестве аналитика он работал над требованиями вместе с коллегой от бизнеса. Когда продукт показали клиенту, тот сказал, что это не то, что они имели в виду. Это привело к перепроектированию, на которое ушло шесть месяцев.
Мы надеемся, что в цифровую эпоху POC позволит преодолеть проблемы водопадной разработки и сократить путь к решениям, приносящим реальную пользу бизнесу.
В конце Питер Никол подчеркнул: «POC лишь проверяет осуществимость, в то время как MVP — это уже функционирующий продукт».
Обсудить