Привет!

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

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

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

Первая сторона — монетизация

Это важный фактор, но про него часто забывают. Ведь как бывает: прибегает заказчик с горящими глазами (и не менее горящими сроками), сообщает свои пожелания и конкретный дедлайн. И тут важно подумать о монетизации, а не сразу стремиться реализовать проект, лишь базово обсудив план. Стоит уже на этом этапе активно интервьюировать заказчика и уточнять, какую именно ценность принесёт внедрение того или иного продукта или доработки. Ценность обычно предстаёт в двух ипостасях. Это или экономия или доход.

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

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

Доход. Более понятная ситуация. Как показывает практика, доход от реализации проекта заказчики обычно склонны преувеличивать. Иногда — ощутимо. И наша ответственность тут как проектного офиса — аккуратно возвращать заказчика из мира единорогов в суровую реальность, где есть калькуляторы, и вовлекать его в оценку проекта, в обсуждение ценности, которую мы можем получить.

Всё это нужно для того, чтобы расставлять приоритеты для тех проектных офисов, у которых всегда в работе множество доработок.

А если мы говорим про бизнес-ценность конкретного проекта или доработки, можно вспомнить такого идеолога процессного управления, как Михаил Рыбаков, и его прекрасную формулировку довольно важной мысли, которая работает и в проектном подходе: «Всё, что мы делаем, мы делаем для одного-единственного элемента системы в любом бизнесе — для клиента». Любой бизнес перестанет существовать, если у него не будет клиентов. Причём клиенты могут быть как внешние, так и внутренние. Для меня, как руководителя проектов по развитию CRM Siebel в МКБ, существуют две категории клиентов: потребители банковских продуктов и внутренние сотрудники, которые работают с нашей CRM.

Разберём ценности в виде экономии и дохода в этом разрезе.

Экономия — сокращение времени работы сотрудника в CRM. Над этим мы активно работаем. Доход — это прибыль, которую клиент принесёт банку, воспользовавшись разработанным нами продуктом.

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

Вторая сторона — смещение фокуса с методологии на потребителя продукта

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

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

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

Существуют ли методологии, изначально работающие на заказчика? Рассмотрим, например, Lean-методологию, которая в лучших традициях соответствует мнению заказчика о продукте: быстро, качественно, не очень дорого. Но и тут есть свои минусы — Lean-методология предъявляет высокие требования к качеству на каждом этапе производства продукта. То есть мы не можем взять и перейти к следующему этапу производства продукта, пока предыдущий не будет соответствовать определённым критериям качества. Данная методология не будет применима, например, в условиях запуска MVP.

Технически компетентный заказчик

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

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

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

Автоматизация ради автоматизации

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

• одного сотрудника переводят в неактивное состояние по той или иной причине;

• все его задачи и активности передаются другому сотруднику/ его заместителю/ новому члену команды, вышедшему на эту должность.

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

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

Оценка проекта в соответствии с типом организации

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

В случае с реализацией доработок в крупных компаниях объём предъявляемых критериев возрастает ещё и с целью избежать своеобразного «зоопарка» IT-систем.

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

Формирование индивидуального подхода к конечному потребителю продукта

Как-то к нам пришёл заказчик и попросил небольшую доработку — возможность рассылать новым клиентам МКБ email-уведомления с благодарностью за их выбор.

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

Здесь мы получаем win-win-ситуацию. Клиент в приветственном письме получает информацию об интересных именно ему банковских продуктах, а не просто конвейерную рассылку с каталогом услуг. А мы дополнительно монетизируем процесс, благодаря тому, что клиент переходит по ссылкам из письма на продукты МКБ.

Резюмируя

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

1. Поймите, что и для кого именно вы делаете

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

2. Рисуйте реальную картину на старте

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

3. Автоматизируйте что-то ради результата, а не ради автоматизации

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