Необходимость описания персон для создания внутренних продуктов организации (автоматизация бизнес процессов) может показаться продуктовой блажью, отголоском agile фанатизма или развлекательной пищей для скучающего ума. Но это поверхностное мнение, ведь изменения бизнес-процессов компании зачастую затрагивают продуктовые характеристики для внешнего клиента. Создавая внутренний продукт, вы можете воздействовать на очертания внешнего и наоборот.
Можно встретить много примеров того как применять customer development, который опирается на “персоны”, для B2C, B2B продуктов, даже для B2BC решений, но сегмент продуктов внутреннего потребления как правило скрыт от посторонних взглядов. Их чаще называют проектами по “автоматизации бизнес-процессов”, которые решают задачу для внутреннего клиента. Особенностью таких проектов/продуктов является секретность, неотвратимость пользования создаваемым продуктом (как считают многие оптимизаторы) и возможность “дотянуться” до потребителя рукой.
[IMG alt="Знать врагов автоматизации - это вовремя очертить границу профессионального подхода
(кадр из фильма Вий 1967г.)"]https://habrastorage.org/r/w1560/ge...93408ded67ee13f5f055fb91fd58a1.png[/IMG]Знать врагов автоматизации - это вовремя очертить границу профессионального подхода (кадр из фильма "Вий" 1967г.)
Метод customer development, в который входит формулирование целевой персоны, прежде всего, основывается на предположении того, что ваш потребитель продукта неизвестен, и его требуется найти. Но при разработке решений автоматизации бизнес-процессов внутри компании, где все текущие пользователи известны, можно услышать следующие фразы:
Отсутствие выгоды в новом продукте, как правило, очевидно самому конечному пользователю, но может хорошо скрываться за богатством требований (кадр из фильма "Ван Хельсинг" 2014г.)
MVP продукта должен был с помощью скрипта MS excel упрощать процедуру дозакупки и доставки товаров на торговые точки. В основу разработки положено два ложных представления:
На практике обычно игнорируется отсутствие личной выгоды конечных пользователей от улучшенного продукта. Сотруднику оплачивается труд, значит ему выгодно постоянное улучшение производительности? Ну или мнение конечных пользователей заглушает авторитет начальствующего звена, декларативно вещающего про светлое будущее с новым продуктом.
Проблема начинает лечиться “потом”, как похмельный синдром: вместо здорового образа жизни — таблетка по обучению персонала и пакет нематериальных мотиваций для новых технологий постфактум. Разменной монетой в таких кейсах приходилось наблюдать менеджера по улучшению, который затеял все эти нововведения. С ним проще расстаться, чем с персоналом, обеспечивающим функционирование бизнес-процессов на старом продукте.
За ярким описанием персоны у команды должна рождаться фантазия о красочном разрешении всех её проблем! (кадр из фильма "Блейд" 1998г.)
Принцип JTBD. Какую задачу вашего пользователя вы решаете?
Но всё это меркло перед опытом потухшего стартапа, где я был совладельцем: функций для реализации MVP было выбрано так много, что проект запускался слишком долго. Финансовое терпение инвестора иссякло, а психические ресурсы команды измотаны. Масла в огонь размышлений подлили слова Н.Талеба: “Социолог науки Стив Шэпин, который долго наблюдал в Калифорнии за инвесторами, вкладывающими капитал в рискованные проекты, отмечает, что инвесторы чаще поддерживают не идеи, а конкретных предпринимателей. Решения сплошь и рядом принимаются исходя из того, кто именно занимается проектом: как говорят сами инвесторы, ставить надо на жокея, а не на лошадь. Почему? Потому что инновация — штука скользкая, и инвесторам нужен фланёр, который способен поймать удачу за хвост вместо того, чтобы погрязнуть в бюрократическом болоте.”
Бывает, что у сотрудника есть жгучая мотивация на упрочнение работодателя. Он всё поддерживает, но реально помочь не может —- не хватает знаний в продуктовом подходе или доменной области.
Существуют и другие вариации маскировки: накидывание бесконечных требований как выпячивание экспертности. Много идей — это ни хорошо, ни плохо, отсутствие их валидации —- это езда по шоссе ночью с выключенными фарами. Иногда это бывает кому-то выгодно.
"Оседлать удачу" - это не всегда про этичность: для каждого своя удача. Удачей может быть удобный для ключевых лиц PO. "В тихом омуте.." "победителей не судят" - к этому имеет смысл относиться как к общечеловеческой норме (кадр из фильма "Вий" 1967г.)
Но учитывайте мнение представителей заказчика: вам нужны представители раннего большинства для внедрения изменений.
Что двигало Виктором Франкенштейном при оживлении его творения? Амбиции, страсть эксперимента, жажда денег, желание облегчить свои страдания или стремление к помощи всему человечеству? А что должно двигать Вами для создания объекта гордости? (кадр из фильма "Виктор Франкенштейн, 2014г.)
habr.com
Можно встретить много примеров того как применять customer development, который опирается на “персоны”, для B2C, B2B продуктов, даже для B2BC решений, но сегмент продуктов внутреннего потребления как правило скрыт от посторонних взглядов. Их чаще называют проектами по “автоматизации бизнес-процессов”, которые решают задачу для внутреннего клиента. Особенностью таких проектов/продуктов является секретность, неотвратимость пользования создаваемым продуктом (как считают многие оптимизаторы) и возможность “дотянуться” до потребителя рукой.
В статье аккумулированы некоторые кейсы, выстраданные многолетней практикой по автоматизации бизнес-процессов в десятке отраслей, где я побывал на разных ролях: от business analyst до product manager. Ключевой объект суммирования опыта — люди, а именно знаниях об их осознанных или неосознанных потребностях, которые являются отправной точкой улучшений.
[IMG alt="Знать врагов автоматизации - это вовремя очертить границу профессионального подхода
(кадр из фильма Вий 1967г.)"]https://habrastorage.org/r/w1560/ge...93408ded67ee13f5f055fb91fd58a1.png[/IMG]Знать врагов автоматизации - это вовремя очертить границу профессионального подхода (кадр из фильма "Вий" 1967г.)
Метод customer development, в который входит формулирование целевой персоны, прежде всего, основывается на предположении того, что ваш потребитель продукта неизвестен, и его требуется найти. Но при разработке решений автоматизации бизнес-процессов внутри компании, где все текущие пользователи известны, можно услышать следующие фразы:
- Мы описали все функции отдела и должностей, однозначно знаем, что нам нужно улучшать — вот список
- У нас есть эксперт, он за всех расскажет про функции, которые требуется автоматизировать
- Все сотрудники, которых затронет модернизируемый функционал, остро нуждаются в изменениях и ждут его с нетерпением
Ситуация №1: новый продукт работоспособен, но им никто не может (не хочет?) воспользоваться
Такое случается, когда в основу разработки нового продукта положено ложное представление о навыках и мотивации персоны, которых должно хватить для эффективного удовлетворения потребности за счет обновленного ПО:- продукт сделан по лекалу “идеального” для самого продвинутого пользователя (перегруз вариативных опций)
- для самого невзыскательного сотрудника (функциональная недоразвитость и технологический тупик)
- для всех пользователей или неопределенного круга пользователей (гарантированный архитектурный тупик при отсутствии vision продукта).
Причина: пользователям неочевидна выгода или присутствует выгода в неиспользовании
MVP продукта должен был с помощью скрипта MS excel упрощать процедуру дозакупки и доставки товаров на торговые точки. В основу разработки положено два ложных представления:
- об уверенном пользовании функциями табличного приложения сотрудником, занимающимся распределением складских запасов;
- о наличии мотивации в модернизации.
На практике обычно игнорируется отсутствие личной выгоды конечных пользователей от улучшенного продукта. Сотруднику оплачивается труд, значит ему выгодно постоянное улучшение производительности? Ну или мнение конечных пользователей заглушает авторитет начальствующего звена, декларативно вещающего про светлое будущее с новым продуктом.
Проблема начинает лечиться “потом”, как похмельный синдром: вместо здорового образа жизни — таблетка по обучению персонала и пакет нематериальных мотиваций для новых технологий постфактум. Разменной монетой в таких кейсах приходилось наблюдать менеджера по улучшению, который затеял все эти нововведения. С ним проще расстаться, чем с персоналом, обеспечивающим функционирование бизнес-процессов на старом продукте.
Профилактика: формулируя персону под продукт автоматизации, исследуйте личную мотивацию будущих пользователей
Не существует универсальных критериев под все продукты, опираясь на которые можно судить о том, что персона будет описана “как надо”. Описание должно быть достаточным, чтобы понять: кто, что делает и почему? Пользователь вашего продукта должен быть описан ярко так, чтобы любой член команды как минимум вдохновился от устранения его проблемы.
Принцип JTBD. Какую задачу вашего пользователя вы решаете?
- создаете удобный планировщик для сотрудников — в основу описания персоны заложена нехватка времени ваших будущих клиентов
- разрабатываете интеллектуальную новостную ленту корпоративного портала —- предполагаете информационный перегруз вашей персоны
- планируете переход на быстрый модернизированный софт для бухгалтерии — ваша персона хочет быть энергична, а не испытывать негодование от ожидания перед монитором с крутящимся колёсиком и т.д.
Ситуация №2: внутренний продукт успешно разрешает заявленные перед его созданием потребительские кейсы, но эффективность потребителей для организации не улучшена
Внутренний продукт решает нужды конечных клиентов, но его финансирует организация, которая получает выгоду от производительности ваших клиентов. Если смотреть на процедуру снятия требования со стороны бизнес-аналитика, то для него важнее корректно быть понятым системным аналитиком или архитектором, чем создать выгодный продукт для инвестора ИТ банкета. Ту же участь может постигнуть роль Product owner, если в компании не внедрена культура осознанного data driven approach. Для product manager (для многих это одно и то же что product owner) уже непозволительно заслоняться отговоркой “таковы были требования”.Причина: в основе функций продукта не лежат проверенные практикой гипотезы полезности, сформулированные персоной
Ещё на студенческой скамье я окунулся в манящий мир ТЭО для крупных финансовых вливаний в проекты железнодорожной отрасли. Считалось, что без ТЭО инвестиции преступны, а с ним обоснованны. А уж как оно получилось в отношении отдельного объекта — не так уж важно, главное, чтобы общий показатель всех проектов был в плюсе, и всем хватало на годовую премию. А если в минусе — РЖД переживёт, как структура, держащая стратегически важную отрасль. Ту же позицию заслушал от PMI, готовясь к экзамену на PMP: есть рассчитанный кейс перед Уставом проекта — значит опору на его показатели можно считать твердой.Но всё это меркло перед опытом потухшего стартапа, где я был совладельцем: функций для реализации MVP было выбрано так много, что проект запускался слишком долго. Финансовое терпение инвестора иссякло, а психические ресурсы команды измотаны. Масла в огонь размышлений подлили слова Н.Талеба: “Социолог науки Стив Шэпин, который долго наблюдал в Калифорнии за инвесторами, вкладывающими капитал в рискованные проекты, отмечает, что инвесторы чаще поддерживают не идеи, а конкретных предпринимателей. Решения сплошь и рядом принимаются исходя из того, кто именно занимается проектом: как говорят сами инвесторы, ставить надо на жокея, а не на лошадь. Почему? Потому что инновация — штука скользкая, и инвесторам нужен фланёр, который способен поймать удачу за хвост вместо того, чтобы погрязнуть в бюрократическом болоте.”
Бывает, что у сотрудника есть жгучая мотивация на упрочнение работодателя. Он всё поддерживает, но реально помочь не может —- не хватает знаний в продуктовом подходе или доменной области.
Существуют и другие вариации маскировки: накидывание бесконечных требований как выпячивание экспертности. Много идей — это ни хорошо, ни плохо, отсутствие их валидации —- это езда по шоссе ночью с выключенными фарами. Иногда это бывает кому-то выгодно.
Профилактика: описывая персону, ответьте на вопрос “есть ли у неё навык формулирования гипотез полезности и опыт их апробации?”
Роберт Фитцпатрик в своей книге, рассуждая о том, как правильно “снимать требования с клиента”, уводит читателя от цикла смерти продукта: “Хочешь загубить продукт — спроси пользователя, что ему нужно”. Если ваша персона способна запускать улучшающие бизнес-процессы, эксперименты и имеет “шкуру на кону” за их результат —- шансы велики доехать даже с закрытыми глазами до продукта внутренней автоматизации за который не стыдно, нащупывая путь “от требования к требованию”. Таких редких персонажей можно встретить среди:
- въедливых владельцев малых бизнесов с ежедневной осознанной борьбой за выживание (им не до жиру),
- сотрудников, которые просят об автоматизации для улучшения вероятности получения бонусов (вот где “шкура на кону”),
- начальников, которые не могут пускать пыль в глаза “масштабной неизбежно успешной трансформацией” по личностным убеждениям.
Но учитывайте мнение представителей заказчика: вам нужны представители раннего большинства для внедрения изменений.
Ситуация №3: технологический тупик после успешного создания продукта — им пользуются, он создает ценность для бизнеса, но улучшить его нельзя
Любая технология, роль в бизнес-процессе или даже сам бизнес устаревает. Высший менеджмент должен быть готов к процессу непрерывных инноваций, когда один продукт на закате своей зрелости подменяется другим на восходе. Для лица, возглавляющего создание внутреннего продукта, важно очертить его будущее, чтобы не получить “франкенштейна” или множество открытых приложений у сотрудника, истерично клацающую мышь и высокие требования к производительному железу.
Причина: не прописан vision роли персоны в будущем продукте
Профилактика: вредно — не мечтать о роли нового продукта в бизнесе. Vision определяет не только точку пространства в будущем с уникальными продуктовыми характеристиками, но и опыт вашего клиента, следовательно и самого клиента. Розовые очки можно снять с помощью трезвого взгляда лиц, принимающих решения или найти в них единомышленников. На случай неуспеха вместе посмеетесь над анекдотом:И напоследок
Настойчивые подталкивания со стороны заказчиков автоматизации в сторону решений типа “Сделай кнопку - “БАБЛО”!” — это лучше, чем месяцами марать бумагу требованиями. Многие решения по автоматизации могут быть сделаны так быстро, что “расписывать” персону просто бессмысленно. Баланс нужен во всём: в статье не случайно использованы кадры из фильмов ужасов, где эмоции зашкаливают, а страсти преувеличены. Но без них иногда бывает просто скучно. Мне дался опыт работы в двух крайностях: рассмотренные кейсы не единственные, а типовые. Сейчас я ищу в свою команду бизнес-аналитика, который мечтает дорасти до PO и ищет интересные вызовы для наработки опыта на острие продуктового подхода в сложных инфраструктурных проектах.
Метод персон против Франкенштейна: эликсир продакта для бизнес анализа
Необходимость описания персон для создания внутренних продуктов организации (автоматизация бизнес процессов) может показаться продуктовой блажью, отголоском agile фанатизма или развлекательной пищей...
habr.com