ГЛАВА 21

Проверка, приемка и приживление продукта

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

Никколо Макиавелли. Государь. 1513 год

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

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

 

О Джонни, я хочу как в синематографе. Прошу тебя, сделай монтаж.

К/ф «Человек с бульвара Капуцинов»

И здесь мы обнаружим, что проект мало правильно сделать. Его еще нужно правильно проверить. И не только правильно проверить, но еще и правильно принять. А потом еще нужно «приживить» — сделать так, чтобы пользователи начали им пользоваться. Но это не всегда легко.

Начнем с проверки. Она должна выявить несоответствие между требованиями и тем, что получилось. В теории управления проектами это также называется контролем качества. Уровень трудозатрат для него может очень серьезно различаться от проекта к проекту. Для строительства атомной станции он может быть крайне высок (там проверяется каждый сварной шов, и документы, подтверждающие качество, грузовиками возят). Для проекта создания сайта иногда это просто прохождение по страницам с указанием на несоответствия. Обычно по итогам проверки составляются контрольные листы или протоколы несоответствия. И при запуске / проверке надо всегда иметь план Б. А что, если выяснится, что продукт требованиям не соответствует? Что запускать его нельзя? Нужен план действий на этот случай.

И после того как продукт проверен, можно говорить о приемке. Вся наша работа на проекте была нацелена на то, чтобы получить финальные результаты. Теперь надо, чтобы заказчик и другие заинтересованные стороны подтвердили, что это именно то, что нужно. Для этого должен отработать механизм проверки и приемки результатов. И его нужно ОБЯЗАТЕЛЬНО продумывать заранее.

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

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

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

И вдруг он мне говорит: «А систему будешь принимать не ты, а твой коллега». Это тот, который заказчик. Я был крайне возмущен: ведь это мое детище, я фактически сам придумал, как все должно быть, и руководил воплощением своей идеи. Я очень активно возмущался. Но босс мой был человек жесткий и сообщил, что будет так, как он сказал. Делать нечего…

Я вернулся к разработчикам и сообщил им, что приемщиком будет другой человек: «Идите, ребята в соседний кабинет». Они пошли, а он им говорит: «Да, да, я в курсе. Но знаете что? У меня очень плотный график. Готов вам выделять два раза в неделю по полчаса. Вот будете показывать, что у вас получилось».

Дальше начался форменный АДъ. Они приходили и показывали ему кусочек функциональности системы. Он нещадно критиковал, говорил, что нужно переделать, и отправлял их дорабатывать. Они жаловались мне, я шел к нему объясняться, мы договаривались, какие изменения вносить, а какие нет. И так каждый раз. В итоге нам пришлось подписать аж СЕМНАДЦАТЬ актов приемки на разные части системы. Из-за этих приемок / переприемок проект затянулся почти на два месяца. Это была очень тяжелая история, которую и я, и мои коллеги еще долго вспоминали с содроганием. Ведь весь проект прошел очень хорошо и успешно. Я допустил всего одну, зато очень значимую ошибку: заранее не продумал и не согласовал порядок сдачи, не разработал и не согласовал механизм приемки. Если бы я его отработал заранее и согласовал со своим боссом, то сэкономил бы много времени и нервов и себе, и всем участникам этой истории.

Помните цитату из «Собаки Баскервилей» Артура Конан Дойла: «Провидению препоручаю я вас, дети мои, и заклинаю: остерегайтесь выходить на болота в ночное время, когда силы зла властвуют безраздельно»? Вслед за автором заклинаю вас: как можно раньше задумайтесь о том, КТО и КАК будет принимать результаты вашего проекта. Еще в начале проекта вы должны знать, кто и в какой форме скажет, что все сделано как надо: продукт соответствует требованиям, мы можем его принимать и закрывать проект.

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

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

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

Шаги механизма следующие.

1. Определение с заказчиком подхода к приемке. Как будет проводиться приемка финальных результатов — итерационно, по частям (лучше) или в конце (хуже). Будет принимать один человек (лучше) или комиссия; если второе — то кто в нее будет входить и как их привлечь в проект заранее.
2. Фиксация правил приемки в специальном документе. Он может называться «План приемки результатов», «Программа и методика испытаний» или как-то еще. Важно, что он должен быть согласован и утвержден теми, от кого реально зависит приемка.
3. Непосредственно проведение проверки и приемки. Для сложных продуктов оно может быть также очень непростым. Так, например, для IT-систем существует более 30 разных видов тестирования. Для их приемки готовятся специальная программа и методика испытаний (ПМИ). Для строительных проектов проверка тоже довольно нетривиальна. И это все нужно заранее определить и согласовать.
4. Фиксация несоответствий и принятие решения о дальнейших действиях. Здесь важный момент: редко все принимается, что называется, без сучка, без задоринки. Чаще всего находятся какие-то несоответствия. И надо заранее продумать, какие несоответствия критичны (без их исправления продукт принять нельзя); а какие могут быть исправлены после приемки в рабочем режиме (например, в рамках гарантийных обязательств). Решение порой затягивается.
5. Фиксация решения о приемке. Чаще всего это протокол или акт приемки. Он включает подтверждение всех результатов. Думаю, не нужно отдельно подчеркивать, что документ должен быть подписан «кем надо». Как говорил профессор Преображенский в «Собачьем сердце», «чтобы это была такая бумажка, при наличии которой ни Швондер, ни кто-либо другой не мог бы даже подойти к двери моей квартиры. Окончательная бумажка. Фактическая! Настоящая! Броня!».

 

Тем, кто не смотрел, очень рекомендую советский двухсерийный художественный фильм известного кинорежиссера Татьяны Лиозновой «Мы, нижеподписавшиеся». Той, что про Штирлица снимала; это как раз следующая ее работа после «Семнадцати мгновений весны». В фильме звездный состав: Леонид Куравлёв, Ирина Муравьёва, Аристарх Ливанов, Юрий Яковлев, Клара Лучко, Олег Янковский. И даже в камео Иосиф Кобзон. Кроме прекрасной актерской работы, там много полезного для размышлений о вечном в проектном управлении:

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

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

На сайте книги (см. ) есть шаблон приемки результатов — как полный, так и упрощенный. Выберите, какой вам больше нравится.

Когда механизм отработал, возникает соблазн решить, что раз продукт есть и заказчик его принял, то дальше уже все пойдет само собой. Опасное заблуждение! Необходимо продукт приживить!

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

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

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

В первый раз я с этим столкнулся в 2000 году в компании ТНК (еще до того, как она слилась в 2003-м с британской ВР и стала ТНК-ВР). Я был руководителем проекта по созданию первого в истории компании интранет-портала. Мы достаточно успешно все реализовали — уложились в бюджет, добавили все запланированные функции, только по срокам были некоторые накладки. Все-таки тогда только учились делать порталы, это еще не стало такой проработанной темой, как сейчас. Но после успешного запуска мы столкнулись с неприятной ситуацией: новеньким, с иголочки, порталом не пользовались! Те сервисы, которые мы придумали, оказались невостребованными.

Мы проводили совещание за совещанием, обсуждая, как завлечь людей. Главный информационный безопасник по этому поводу язвил: «А вы по рублю выдавайте каждому, кто на ваш портал зайдет. Тут-то все и повалят!»

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

Для меня тогда это стало уроком: об использовании того, что ты создаешь, нужно думать заранее!

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

Я много раз сталкивался с тем, что внедрить систему проще, чем убедить людей ее использовать. Историю про внедрение SAP в Avon я рассказывал выше. Но можно даже не смотреть на очень сложные системы — какую часть функциональности офисных приложений (MS Office, российский Р7-Офис) вы используете? Уверен, не очень большую. И большинство не смотрит на многочисленные функции, которые все добавляются и добавляются в продукт.

Сейчас многие уже осознают эту проблему, и в крупных компаниях, таких как «Северсталь», проект не запускается, пока не будет определена так называемая метрика приживаемости. Это показатель, который демонстрирует, что система реально используется. Пример: в рамках цифровой трансформации создается специальное приложение — калькулятор ферросплавов. Это программа, которая на основании сложных математических расчетов подсказывает оператору оптимальный состав сплава, и для нее метрикой приживаемости будет процент соблюдения рекомендаций. При внедрении в начале он был около 40%, но после доработки программы достиг 96%. Потому что над приживаемостью целенаправленно работали!

В статье Harvard Business Review о подходах к цифровой трансформации мне попалась любопытная история. Компания Veon была одним из основных акционеров «Билайна».

Новая цифровая платформа, представленная в 2017 году, представляла собой огромный проект, в котором участвовали 100 со­трудников в Амстердаме и еще около сотни в лондонском офисе. Идея заключалась в том, чтобы создать мобильное приложение, которое объединяет мессенджер, мультимедийный сервис и предложения от партнеров (таких, как Mastercard). Предполагалось разработать аналог китайского WeChat.

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

Не стоит думать, что проблема с приживаемостью может быть только у IT-проектов. Для проектов создания новых продуктов отторжение, нежелание клиентов использовать продукт — один из базовых, ключевых, самых высоких рисков.

Яркий пример — R1 (Russia One) — проект инновационного трамвая, разработанный на «Уралтрансмаше» и в ОКБ «Атом» (рис. 21.1). В июле 2014 года в Екатеринбурге на выставке «Иннопром» был представлен концептуальный макет. Представители СМИ, посетители выставки, а в дальнейшем и блогеры создали вокруг него ажиотаж. Трамвай получил несколько прозвищ: «iPhone на рельсах», «трамборджини», «трамвай Бэтмена».

Основной особенностью вагона должен был стать футуристический внешний вид — черный цвет и кабина с обратным углом наклона. По словам разработчиков, такая кабина увеличивает обзор для водителя, не нагревается под солнцем и меньше бликует. В базовой комплектации были предусмотрены навигация ГЛОНАСС, GPS, Wi-Fi, аудиосистема, которая должна подбирать музыку под погоду и время суток. В трамвае предполагалось установить антибактериальные поручни и подогрев ступеней против образования наледей.

Несмотря на внешнюю эффектность, проект оказался весьма спорным и непродуманным. В частности, отмечались незащищенность водителя при лобовом столкновении, травмоопасность для пешеходов, нерациональное использование пространства салона. Критиковали также низкую безопасность, ремонтопригодность и высокую стоимость. Предполагалось, что R1 будет предложен российским городам, принимающим чемпионат мира по футболу 2018 года. Ориентировочная стоимость вагона должна была составить 40–50 млн рублей в зависимости от комплектации, однако позже оценка повысилась до 50–70 млн рублей. В июле 2015 года стало известно, что российские города закупать его отказались — слишком дорого. В конце концов госкорпорация «Рос­тех» отказалась от серийного производства.

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

Провалы случаются не только на рынке B2B. Интересная история была опубликована в газете «Коммерсант».

В 2004 году компания Mars решила вывести на российский рынок популярные в Европе супы быстрого приготовления «Гурмания».

Вложения только в специально построенный завод в подмосковных Луховицах, без учета рекламы от BBDO, составили 10 млн долларов. В 2006-м компания рапортовала об успехе: ее доля на рынке жидких супов оценивалась в 90%, Mars рассчитывала, что рынок будет расти на 50% в год.

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

Ошибку Mars повторили и супы от прославленной Энди Уорхолом компании Campbell’s: выйдя в 2008 году на рынок, в 2011-м американцы свернули производство. До этого с российского рынка ушли супы Unilever под маркой Knorr, тоже «слишком готовые» для большинства российских хозяек.

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

Особенно известными стали афинские «белые слоны». Для летних Олимпийских игр 2004 года было построено 35 крупных спортивных объектов. Но планов по их использованию не было, и около 80% заброшены либо используются не на полную мощность и чаще всего не по назначению.

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

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

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

Одна из самых универсальных метрик для IT-проектов — DAU (Daily Active Users) — количество уникальных пользователей за сутки. Этот параметр (так же как и связанный с ним MAU — месячное количество пользователей) наглядно показывает, насколько прижилось приложение.

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

Проводилось внедрение довольно сложной и специфичной системы. У заказчика совсем не было времени — он дал общие требования и попросил меня, как человека, глубоко погруженного в тему, «выступить его голосом»: формулировать требования и участвовать в приемке. С самого начала проекта было ясно, что есть особая группа пользователей системы. Это высокооплачиваемые профессионалы, которые не привыкли пользоваться IT-системой в своей деятельности. Но вообще, она была им нужна. Впрочем, не сильно — помощники и администраторы могли для них выгружать все, что им нужно. Назовем их Сеятелями ввиду специфики деятельности.

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

Руководитель проекта со мной полностью согласился, но ввиду перегрузки команды оставил все эти задачи на потом. Система была успешно внедрена и пошла в работу, хотя и с существенной задержкой — у сотрудников не было времени ею заниматься. О запуске в эксплуатацию громко объявили по всей организации. Через несколько месяцев я случайно встретился в коридоре с руководителем проекта и спросил его, как там ситуация с Сеятелями. Он ответил: «Я вчера только смотрел статистику — в системе из них только два пользователя. Один из них ты…»

Система в этой важной, но специфичной группе не прижилась до сих пор…

Соответственно, нужно постоянно работать над вовлечением заказчика и пользователей в проект. Здесь пригодятся MVP, пилоты, промежуточные демонстрации продукта и другие аналогичные практики, которые помогут заранее получить обратную связь. Это называется итеративно-инкрементальной разработкой: когда мы постепенно, шаг за шагом, создаем продукт и показываем его пользователям, собирая обратную связь.

Не для всех типов проектов это легко реализовать, но если поставить себе такую цель, то возможно для очень многих. Например, в классической стройке сейчас активно развивается направление BIM-моделирования. Данная технология позволяет моделировать любые строительные объекты, включая здания, железные дороги, мосты, тоннели, порты и так далее. Соответственно, для пользователей можно устраивать «виртуальные демонстрации» — показывать продукт, которого еще нет, но который будет.

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

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

Вот шесть основных направлений работы по изменениям.

1. Контроль и отчетность. Обеспечиваются через контрольные точки и регулярный мониторинг метрик.
2. Коммуникации. Информацию о продукте, его целях и ценности, о том, как будет выглядеть жизнь после внедрения, необходимо доносить. У людей должно сформироваться понимание происходящего: причин и их неизбежности, длительности процесса изменений во времени и их конечности; понимание в пространстве — что должно измениться и как все это поймут; понимание в отношениях — с кем взаимодействовать и по каким вопросам.
3. Обучение. Все должны уметь работать с продуктом.
4. Мотивация. Все должны быть заинтересованы в использовании продукта.
5. Вовлечение. Возможность влиять на происходящее, чтобы сотрудники чувствовали себя частью процесса; возможность получать и давать обратную связь.
6. Менторство и поддержка. Это про наставничество, коучинг, да просто про службу поддержки — чтобы люди могли успешно адаптироваться к новым условиям и прийти к доверенному лицу с «глупым» вопросом.

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

• Модель управления изменениями Курта Левина.
• Модель Маккинзи 7С (McKinsey 7S).
• Теория Джона Коттера «Восемь шагов к изменениям».
• Теория подталкивания Ричарда Талера и Касса Санстейна.
• Модель ADKAR в управлении изменениями.
• Модель перехода Уильяма Бриджеса.
• Кривая изменений Элизабет Кюблер-Росс.
• Модель управления изменениями Вирджинии Сатир.
• Модель Рика Маурера «Три уровня сопротивления и изменения».

Резюмируя все вышесказанное: главное — принять как базовую угрозу, что ИСПОЛЬЗОВАТЬ ПРОДУКТ НЕ БУДУТ. С угрозой нужно на протяжении всего проекта работать, и это должно быть одним из важных фокусов внимания лиц, принимающих решения, заказчика (как последующего пользователя результатов и продуктов проекта) и лидера проекта. И если они это делают, то приживление пройдет значительно проще.

Далее мы перейдем к тому, как организовать работу по реализации проекта, и получению продукта.

Отправить