Необходимость описания персон для создания внутренних продуктов организации (автоматизация бизнес процессов) может показаться продуктовой блажью, отголоском agile фанатизма или развлекательной пищей для скучающего ума. Но это поверхностное мнение, ведь изменения бизнес-процессов компании зачастую затрагивают продуктовые характеристики для внешнего клиента. Создавая внутренний продукт, вы можете воздействовать на очертания внешнего и наоборот.
Можно встретить много примеров того как применять customer development, который опирается на “персоны”, для B2C, B2B продуктов, даже для B2BC решений, но сегмент продуктов внутреннего потребления как правило скрыт от посторонних взглядов. Их чаще называют проектами по “автоматизации бизнес-процессов”, которые решают задачу для внутреннего клиента. Особенностью таких проектов/продуктов является секретность, неотвратимость пользования создаваемым продуктом (как считают многие оптимизаторы) и возможность “дотянуться” до потребителя рукой.
Создание продуктов для внутреннего потребления это как правило либо что-то большое, дорогое или долгое, сродни амбициям громких трансформаций (что чаще сопровождает проектный менеджмент), либо собранное из подручных средств теми, кто не понимает разницу между product и project management, а слова agile и customer development - это что-то на хипстерском.
В статье аккумулированы некоторые кейсы, выстраданные многолетней практикой по автоматизации бизнес-процессов в десятке отраслей, где я побывал на разных ролях: от business analyst до product manager. Ключевой объект суммирования опыта — люди, а именно знаниях об их осознанных или неосознанных потребностях, которые являются отправной точкой улучшений.
Метод customer development, в который входит формулирование целевой персоны, прежде всего, основывается на предположении того, что ваш потребитель продукта неизвестен, и его требуется найти. Но при разработке решений автоматизации бизнес-процессов внутри компании, где все текущие пользователи известны, можно услышать следующие фразы:
Мы описали все функции отдела и должностей, однозначно знаем, что нам нужно улучшать — вот список
У нас есть эксперт, он за всех расскажет про функции, которые требуется автоматизировать
Все сотрудники, которых затронет модернизируемый функционал, остро нуждаются в изменениях и ждут его с нетерпением
Принимая вышеуказанные утверждения, можно попасть в ситуации, последствия которых на самом деле не нужны ни создателю продукта, ни заказчику, ни владельцу компании.
Ситуация №1: новый продукт работоспособен, но им никто не может (не хочет?) воспользоваться
Такое случается, когда в основу разработки нового продукта положено ложное представление о навыках и мотивации персоны, которых должно хватить для эффективного удовлетворения потребности за счет обновленного ПО:
продукт сделан по лекалу “идеального” для самого продвинутого пользователя (перегруз вариативных опций)
для самого невзыскательного сотрудника (функциональная недоразвитость и технологический тупик)
для всех пользователей или неопределенного круга пользователей (гарантированный архитектурный тупик при отсутствии vision продукта).
При этом стоит особо отметить, что персона, которая исследуется сейчас и та, которая будет эксплуатировать продукт в будущем, могут быть совершенно разными. Такое возможно, если продукт “оптимизирует” часть функций или подменяет роль старой персоны.
Причина: пользователям неочевидна выгода или присутствует выгода в неиспользовании
MVP продукта должен был с помощью скрипта MS excel упрощать процедуру дозакупки и доставки товаров на торговые точки. В основу разработки положено два ложных представления:
об уверенном пользовании функциями табличного приложения сотрудником, занимающимся распределением складских запасов;
о наличии мотивации в модернизации.
Эти предположения возникли вследствии того, что сотрудник сам выступил инициатором разработки и даже активно участвовал в обсуждении требований. Но в ходе интервью был упущен тот факт, что разработка простимулирована методом “сверху”: неоднократный вызов на ковёр к боссу показал, что нужно что-то менять и срочно! Так неудавшийся проект по автоматизации был бы хорошей защитой для инициатора при предъявлении претензий к его работе: “Делаю всё, что могу, а все улучшение — это вот к тем, кто ими занимается”. При этом удавшийся проект добавил бы значительно больше неудобства: KPI деятельности по распределению товаров был бы повышен, пришлось бы постигать новые профессиональные высоты. Поэтому вероятность того, что MVP не будет внедрен в бизнес процессы по причине недооценки мотивации персоны повышается пропорционально стимуляции сверху (метод: морковка сзади). Люди инертны и не хотят выходить из зоны комфорта. Китайская мудрость в таких ситуациях советует вогнать человека в зону экстремально стресса (читать подробнее про “сжигание кораблей” в Технологии жизни. Книга для героев).
На практике обычно игнорируется отсутствие личной выгоды конечных пользователей от улучшенного продукта. Сотруднику оплачивается труд, значит ему выгодно постоянное улучшение производительности? Ну или мнение конечных пользователей заглушает авторитет начальствующего звена, декларативно вещающего про светлое будущее с новым продуктом.
Проблема начинает лечиться “потом”, как похмельный синдром: вместо здорового образа жизни — таблетка по обучению персонала и пакет нематериальных мотиваций для новых технологий постфактум. Разменной монетой в таких кейсах приходилось наблюдать менеджера по улучшению, который затеял все эти нововведения. С ним проще расстаться, чем с персоналом, обеспечивающим функционирование бизнес-процессов на старом продукте.
Профилактика: формулируя персону под продукт автоматизации, исследуйте личную мотивацию будущих пользователей
Не существует универсальных критериев под все продукты, опираясь на которые можно судить о том, что персона будет описана “как надо”. Описание должно быть достаточным, чтобы понять: кто, что делает и почему? Пользователь вашего продукта должен быть описан ярко так, чтобы любой член команды как минимум вдохновился от устранения его проблемы.
Принцип JTBD. Какую задачу вашего пользователя вы решаете?
создаете удобный планировщик для сотрудников — в основу описания персоны заложена нехватка времени ваших будущих клиентов
разрабатываете интеллектуальную новостную ленту корпоративного портала —- предполагаете информационный перегруз вашей персоны
планируете переход на быстрый модернизированный софт для бухгалтерии — ваша персона хочет быть энергична, а не испытывать негодование от ожидания перед монитором с крутящимся колёсиком и т.д.
Ситуация №2: внутренний продукт успешно разрешает заявленные перед его созданием потребительские кейсы, но эффективность потребителей для организации не улучшена
Внутренний продукт решает нужды конечных клиентов, но его финансирует организация, которая получает выгоду от производительности ваших клиентов. Если смотреть на процедуру снятия требования со стороны бизнес-аналитика, то для него важнее корректно быть понятым системным аналитиком или архитектором, чем создать выгодный продукт для инвестора ИТ банкета. Ту же участь может постигнуть роль Product owner, если в компании не внедрена культура осознанного data driven approach. Для product manager (для многих это одно и то же что product owner) уже непозволительно заслоняться отговоркой “таковы были требования”.
Причина: в основе функций продукта не лежат проверенные практикой гипотезы полезности, сформулированные персоной
Ещё на студенческой скамье я окунулся в манящий мир ТЭО для крупных финансовых вливаний в проекты железнодорожной отрасли. Считалось, что без ТЭО инвестиции преступны, а с ним обоснованны. А уж как оно получилось в отношении отдельного объекта — не так уж важно, главное, чтобы общий показатель всех проектов был в плюсе, и всем хватало на годовую премию. А если в минусе — РЖД переживёт, как структура, держащая стратегически важную отрасль. Ту же позицию заслушал от PMI, готовясь к экзамену на PMP: есть рассчитанный кейс перед Уставом проекта — значит опору на его показатели можно считать твердой.
Но всё это меркло перед опытом потухшего стартапа, где я был совладельцем: функций для реализации MVP было выбрано так много, что проект запускался слишком долго. Финансовое терпение инвестора иссякло, а психические ресурсы команды измотаны. Масла в огонь размышлений подлили слова Н.Талеба: “Социолог науки Стив Шэпин, который долго наблюдал в Калифорнии за инвесторами, вкладывающими капитал в рискованные проекты, отмечает, что инвесторы чаще поддерживают не идеи, а конкретных предпринимателей. Решения сплошь и рядом принимаются исходя из того, кто именно занимается проектом: как говорят сами инвесторы, ставить надо на жокея, а не на лошадь. Почему? Потому что инновация — штука скользкая, и инвесторам нужен фланёр, который способен поймать удачу за хвост вместо того, чтобы погрязнуть в бюрократическом болоте.”
Бывает, что у сотрудника есть жгучая мотивация на упрочнение работодателя. Он всё поддерживает, но реально помочь не может —- не хватает знаний в продуктовом подходе или доменной области.
Существуют и другие вариации маскировки: накидывание бесконечных требований как выпячивание экспертности. Много идей — это ни хорошо, ни плохо, отсутствие их валидации —- это езда по шоссе ночью с выключенными фарами. Иногда это бывает кому-то выгодно.
Профилактика: описывая персону, ответьте на вопрос “есть ли у неё навык формулирования гипотез полезности и опыт их апробации?”
Приходит однажды чукча в Госплан:
- Однако 300 кирпичей надо!
- Зачем? — удивились в Госплане.
- Экологическая эксперимента!
Дали ему 30 кирпичей. Через год снова приходит:
- Однако, еще 300 кирпичей надо!
- Что, опять экологическая эксперимента?
- Ага.
Дали ему кирпичи. Через год опять этот чукча приезжает и кирпичи требует. Ему дали, но решили проверить, куда он народное добро девает. Приезжает комиссия в тундру, а там чукча сидит и кирпичи в воду кидает!
- Что ты делаешь??? — удивилась комиссия.
- Однако вот думаю, почему кирпич квадратный, а след на воде круглый?
Роберт Фитцпатрик в своей книге, рассуждая о том, как правильно “снимать требования с клиента”, уводит читателя от цикла смерти продукта: “Хочешь загубить продукт — спроси пользователя, что ему нужно”. Если ваша персона способна запускать улучшающие бизнес-процессы, эксперименты и имеет “шкуру на кону” за их результат —- шансы велики доехать даже с закрытыми глазами до продукта внутренней автоматизации за который не стыдно, нащупывая путь “от требования к требованию”. Таких редких персонажей можно встретить среди:
въедливых владельцев малых бизнесов с ежедневной осознанной борьбой за выживание (им не до жиру),
сотрудников, которые просят об автоматизации для улучшения вероятности получения бонусов (вот где “шкура на кону”),
начальников, которые не могут пускать пыль в глаза “масштабной неизбежно успешной трансформацией” по личностным убеждениям.
Если же ваша персона путается в аналитике, не может сформулировать рычаги своего воздействия на эффективность бизнес-процессов, не страдает физически за неудачные эксперименты - будьте готовы запускать проектную разработку (что позволит разграничить ответственность) или найти аргументы на ресурсы для перепроверки требований от такой персоны.
Но учитывайте мнение представителей заказчика: вам нужны представители раннего большинства для внедрения изменений.
Ситуация №3: технологический тупик после успешного создания продукта — им пользуются, он создает ценность для бизнеса, но улучшить его нельзя
Любая технология, роль в бизнес-процессе или даже сам бизнес устаревает. Высший менеджмент должен быть готов к процессу непрерывных инноваций, когда один продукт на закате своей зрелости подменяется другим на восходе. Для лица, возглавляющего создание внутреннего продукта, важно очертить его будущее, чтобы не получить “франкенштейна” или множество открытых приложений у сотрудника, истерично клацающую мышь и высокие требования к производительному железу.
Причина: не прописан vision роли персоны в будущем продукте
Профилактика: вредно — не мечтать о роли нового продукта в бизнесе. Vision определяет не только точку пространства в будущем с уникальными продуктовыми характеристиками, но и опыт вашего клиента, следовательно и самого клиента. Розовые очки можно снять с помощью трезвого взгляда лиц, принимающих решения или найти в них единомышленников. На случай неуспеха вместе посмеетесь над анекдотом:
Стоит мужик у букмекерского окна на ипподроме и думает, на какую бы лошадь поставить. Тут подходит к нему старая кобыла и говорит: «Ставь на меня, мужик. Я хоть и старенькая, но раньше чемпионкой была, и сегодня в отличной форме! На меня больше никто не ставит, выиграю забег — сорвешь большой куш!» . Подумал-подумал мужик и поставил на кобылу все деньги. Начинается заезд, кобыла дергается с места, делает несколько шагов, падает на землю и больше не поднимается. Мужик подходит к ней после забега с угрожающим видом. Кобыла смотрит на него виновато и шепелявит: “Ну не шмогла я, не шмогла!”
И напоследок
Настойчивые подталкивания со стороны заказчиков автоматизации в сторону решений типа “Сделай кнопку - “БАБЛО”!” — это лучше, чем месяцами марать бумагу требованиями. Многие решения по автоматизации могут быть сделаны так быстро, что “расписывать” персону просто бессмысленно. Баланс нужен во всём: в статье не случайно использованы кадры из фильмов ужасов, где эмоции зашкаливают, а страсти преувеличены. Но без них иногда бывает просто скучно. Мне дался опыт работы в двух крайностях: рассмотренные кейсы не единственные, а типовые. Сейчас я ищу в свою команду бизнес-аналитика, который мечтает дорасти до PO и ищет интересные вызовы для наработки опыта на острие продуктового подхода в сложных инфраструктурных проектах. Буду рад конструктивному обмену мнениями в комментариях.