Содержание курса

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

1)  Потребность в его создании. Кому-то он действительно нужен, кто-то получит разумные выгоды от его использования.

2)  Возможность его создания. Кто-то может его реализовать, в обозримые сроки, используя определенные технологии.

3)  Возможность финансирования его создания. Кто-то сможет оплатить все стадии производства.

При этом проведение самой фазы Инициации и анализа чаще всего является инвестицией, которая окупится (иногда с лихвой) в случае не наступления высоковероятных рисков неблагоприятных исходов производства (организационных, технических, неактуальных требований, сроков, обеспечения качества и безопасности, финансовых и прочих). Другими словами, стадия направлена на снижение уровня неопределенности результата производства и избегания необходимости внесения изменений уже в ходе реализации и внедрения.

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

1.  Этап 1. Запуск производства.

Запуск производства ИТ-продукта может происходить при различных начальных условиях и обстоятельствах. Чтобы лучше понять контекст и аспекты этого события, рассмотрим возможные варианты процесса инициации:

1.1. Вариант 1. Потребность в автоматизации возникает у самого стейкхолдера ИС – потенциального заказчика.

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

В такой ситуации требуется специалист, способный сумбурные, разрозненные хотелки стейкхолдеров подчинить единой значимой цели, достижение которой принесет ощутимый эффект от автоматизации бизнес-деятельности. Этот специалист может называться: “Специалистом по взаимодействию с заказчиком”, “Бизнес-архитектором”. В проф.стандарте это: “Бизнес-аналитик. Код_06.037”,

В такого рода деятельности иногда необходимо применить приемы манипуляции сознанием заказчика, чтобы выявить его потаенные желания от продукта, которые он не решается озвучивать, но которые реально могут повысить эффективность его работы. Существуют и другие эффективные инструменты. Больше о способах сбора и формализации информации можно прочитать в курсе “Проектирование Информационных систем. Часть 1. Введение”.

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

В классификации производства (в Разделе II) этот вариант по характерным чертам можно отнести к следующим категориям:

Классификация производства

Вариант

1. В парадигме управления

1.2. Управление производством как живым организмом

4. По структуре команд

4.2. Кросс-функциональная структура

5.1. По цели автоматизации

5.1.3. Ради качества и стабильности

5.2. По степени готовности процесса к автоматизации

5.2.1. Хаотичный (не готов к автоматизации)

6. По фактору характера необходимых преобразований

6.4. Структурные (архитектурные) преобразования

1.2.  Вариант 2. Потенциальный заказчик имеет доступные ресурсы и ощущает необходимость развиваться.

В подобных ситуациях, как правило, о еще только зарождающемся желании клиента узнают прозорливые специалисты отдела продаж какого-нибудь ИТ-бренда и убеждают потенциального потребителя, что ему крайне необходим, именно продаваемый ими продукт. Такие специалисты в перечне проф.стандартов представлены как: “Менеджер по продажам информационно-коммуникационных систем. Код_06.029”. Они способны презентовать массу примеров, где практически на таком же предприятии успешно внедрена их ИС и даже демонстрирую восторженные отзывы искренне благодарных пользователей. Не поверить им очень сложно.

Уже после сделки на объект выезжают все те же бизнес-аналитики и “натягива��т” проданное решение на действительные потребности и реальные возможности клиента. Эти дополнительные активности чаще всего становятся весьма неожиданными и болезненными для клиента, да еще и связаны с дополнительными затратами. Хорошо, если команда повидавшая виды и уже включила в ценник эти издержки сообразно своему предыдущему опыту.

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

Чаще всего в этот сегмент охватывает крупные предприятия, у которых уже функционируют Корпоративные ИС.

В классификации производства (в Разделе II) этот вариант по характерным чертам можно отнести к следующим категориям:

Классификация производства

Вариант

1. В парадигме управления

1.1. Управление производством как фабрикой

4. По структуре команд

4.3. Команды по продукту / компоненту

4.2. Кросс-функциональная структура

4.4. Проектные команды

5.1. По цели автоматизации

5.1.3. Ради качества и стабильности

5.1.4. Ради масштабируемости

5.2. По степени готовности процесса к автоматизации

5.2.2. Описанный (частично готов)

5.2.3.  Управляемый (готов к автоматизации)

5.3.  По экономическому эффекту (ROI-модель)

5.3.1.  Как расходы отражаются в балансе компании и влияют на налоги.

6. По фактору характера необходимых преобразований

6.5. Процессные преобразования

1.3.  Вариант 3. Разработка с участием штатных сотрудников предприятия.

В подобном варианте предприятие само по себе выступает одновременно и заказчиком, и исполнителем, и кошельком производства, а разработка чаще всего ведется силами штатных программистов –многостаночников, которые выступают по совместительству в роли и аналитиков, и исполнителей, и внедренцев в одном флаконе. В проф.стандарте они так и представлены “Программист. Код_06.001”. Тестировать такие ИС нередко приходится непосредственным пользователям продукта. Такой себе эконом вариант.

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

В классификации производства (в Разделе II) этот вариант по характерным чертам можно отнести к следующим категориям:

Классификация производства

Вариант

1. В парадигме управления

1.3. Управление операционным производством

4. По структуре команд

4.1. Функциональная структура

4.2. Кросс-функциональная структура

5.1. По цели автоматизации

5.1.1. Ради эффективности (снижение затрат)

5.1.5. Ради управляемости и контроля

5.2. По степени готовности процесса к автоматизации

5.2.3. Управляемый (готов к автоматизации)

5.3.  По экономическому эффекту (ROI-модель)

5.3.2.  Цели инвестиций и типу экономии (Функциональный ROI)

6. По фактору характера необходимых преобразований

6.2. Улучшающие (эволюционные) преобразования

1.4.  Вариант 4. Кто-то креативный, формулирует потребность в ИС от имени потенциальных пользователей.

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

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

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

В классификации производства (в Разделе II) этот вариант по характерным чертам можно отнести к следующим категориям:

Классификация производства

Вариант

1. В парадигме управления

1.2. Управление производством как живым организмом

4. По структуре команд

4.4. Проектные команды

5.1. По цели автоматизации

5.1.2.  Ради скорости (Time-to-Market)

5.2. По степени готовности процесса к автоматизации

5.2.1. Хаотичный (не готов к автоматизации)

6. По фактору характера необходимых преобразований

6.6. Радикальные (трансформационные) преобразования

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

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

На такое производство, чаще всего ориентированное на продуктовые линейки, может привлекаться: Product manager (менеджер-продукта) или Product owner (владелец-продукта). В проф.стандарте он обозначен как: “Менеджер продуктов в области информационных технологий. Код_06.012”.

В классификации производства (в Разделе II) этот вариант по характерным чертам можно отнести к следующим категориям:

Классификация производства

Вариант

1. В парадигме управления

1.2. Управление производством как живым организмом

4. По структуре команд

4.3. Команды по продукту / компоненту

4.6. Потоковые команды (Value Stream Teams)

5.1. По цели автоматизации

5.1.2.  Ради скорости (Time-to-Market)

5.2. По степени готовности процесса к автоматизации

5.2.4. Измеряемый (автоматизированный, но не оптимальный)”

5.3.  По экономическому эффекту (ROI-модель)

5.3.3.  Портфельное управление

6. По фактору характера необходимых преобразований

6.3. Функционально – расширяющие преобразования

6.4.  Структурные (архитектурные) преобразования

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

2.  Этап 2. Определение предмета автоматизации

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

Важно, как можно более четко понять и формализовать, что из себя должен представлять целевой ИТ-продукт.  

Другими словами, необходимо заполнить (истолковать) “Облако неопределенности” между целями организации и целевой ИС.

В результате предпроектного исследования должен появиться документ “Видение” (перспективы), который позволит команде понимать стратегию, инвесторам видеть перспективу, а пользователям понимать ценность продукта.

2.1.  Видение в IT-производстве

Видение (Vision) в IT-производстве — это стратегический документ, который отвечает на самый главный вопрос: “Какой мир мы создаем своим продуктом и почему это важно?”.

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

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

1.     Проблема и потребности (фокус на пользе, а не технологиях)

  • Какую проблему или возможность решает проект?

  • Почему эта проблема важна для пользователей?

2.     Целевая аудитория

  • Кто будет пользоваться продуктом, инициаторы, косвенные выгодоприобретатели?

  • Какие у них боли, ожидания, потребности?

3.     Уникальное предложение (УП)

  • Как продукт должен восприниматься (ассоциации и стиль)?

  • Чем продукт отличается от аналогов?

  • Почему пользователи выберут именно его?

4.     Цели и результаты (четкое понимание “что именно мы производим”.)

  • Чего мы хотим достичь с помощью производства? Какие ИТ-продукты, сервисы создаются. Жизненный цикл продуктов.

  • Ключевой функционал ИС.

  • Ограничения, понимание границ, важные допущения.

  • Критерии успеха, какие ключевые метрики определяют успешность реализации?

5.     Подход к реализации

  • Предполагаемая методология работ по реализации.

  • Общий подход к разработке и поставке.

6.     Ресурсы и сроки (укрупнённо)

  • Примерные сроки.

  • Основные ресурсы.

  • Ориентир по бюджету.

7.     Бизнес-модель

  • Как проект будет монетизироваться?

  • Какие источники дохода предусмотрены?

8.     Развитие и улучшение

  • Что будет происходить с продуктом после выпуска первых версий?

  • Как должен эволюционировать продукт?

Теперь кратко рассмотрим приемы и инструменты, помогающие качественно сформировать документ Видение.

2.2.  Прием - гипотеза о продукте

Чтобы перейти от модели “сделать то, что сказал заказчик” к модели “найти и проверить решение, которое сработает” используют инструмент Гипотеза о продукте - это предположение о том, как создаваемая ценность (продукт, сервис, фича) решит проблему пользователя и принесет пользу бизнесу. Это не требование, а проверяемое утверждение, которое команда стремится подтвердить или опровергнуть с минимальными затратами.

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

Для того, чтобы точнее осознать, что именно проверяется, правильно подобрать способ валидации и расставить приоритеты, гипотезы разбивают на виды:

  • Гипотеза ценности. Решает ли предполагаемое решение реальную проблему стейкхолдеров, буду ли ими пользоваться?

  • Гипотеза удобства (UX). Могут ли пользователи легко и эффективно использовать предлагаемое решение?

  • Гипотеза реализации. Может ли команда технически это реализовать? Какая архитектура лучше?

  • Гипотеза роста. Как можно будет привлекать и удерживать клиентов?

  • Бизнес-гипотеза. Принесут ли новации прибыль?

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

  1. Проблема. Какую боль пользователя решаем?

  2. Целевая аудитория. Для кого именно?

  3. Решение. Что предлагаем (продукт / функция / изменение)?

  4. Ожидаемый эффект. Какой результат хотим получить?

  5. Метрика успеха. Как поймем, что гипотеза подтвердилась?

  6. Структура (шаблон) сильной гипотезы.

Наиболее популярные и эффективные форматы шаблонов те, которые позволяют упаковать в одной фразе информацию одновременно о ценности, метриках и доказательствах:

•  Классическая формула. “Мы считаем, что для [целевой аудитории] *[решение] поможет [решить проблему], что приведёт к [измеримому результату], и мы узнаем это по [метрике].”

Например:

“Мы считаем, что добавление онлайн-оплаты для клиентов интернет-магазина сократит количество брошенных корзин, что увеличит конверсию заказов на 10%” и мы проверим это по метрике conversion rate.

•  Формат Geoffrey Moore (из книги "Crossing the Chasm"):
"Для [целевой аудитории], которая сталкивается с [проблемой], наш продукт – это [категория продукта], который предоставляет [ключевая ценность]. В отличие от [конкурентов], наш продукт [уникальное преимущество]."

•  Формат "Elevator Pitch" (короткое описание за 30 секунд)
"Мы создаём [продукт], который помогает [целевой аудитории] решать [проблему] с помощью [ключевого решения]. В результате они получают [основное преимущество]."

Жизненный цикл гипотезы (процесс работы).

  1. Формулировка (по шаблону выше).

  2. Приоритизация. Какую гипотезу проверять следующей? Часто используют матрицы: ICE/RICE Score: Оценка по влиянию (Impact); уверенности (Confidence); простоте (Ease) или охвату (Reach); Cost of Delay: Какова цена отсрочки проверки?

  3. Планирование эксперимента. Выбираем самый быстрый и дешевый способ проверки. Способы: CustDev интервью; опрос; лендинг/дождевая страница; фейковый дверной тест (fake door); прототип; A/B тест на существующем трафике.

  4. Проведение эксперимента и сбор данных.

  5. Анализ и вывод. Установление факта: гипотеза подтвердилась, опровергнута или требует уточнения?

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

2.3.  Прием - сегментирование рынка

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

Например:

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

  1. Определить базовые критерии сегментации. Вместо простой сегментации (по полу и возрасту) используйте более релевантные для цифровых продуктов поведенческие и психографические критерии.

  2. Собрать данные и гипотезы. Анализ рынка, интервью, онлайн-опросы.

  3. Кластеризировать и выявить сегменты. На основании данных выявите 3-4 ключевых сегмента, способствующих входу на определенный рынок.

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

  5. Конкретизировать Видение и продукт на основе сегментации. Сфокусируйте “размытые” формулировки точными определениями, сформировав Ядро продукта и выделив ключевые фичи.  

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

2.4.  Прием - составление портрета пользователя

Практический методы перехода от абстрактного сегмента рынка к живому, детальному и полезному образу вашего идеального пользователя – это составление портрета пользователя (User Persona).

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

Стандартный шаблон может включать:

  • Имя и аватар. Дайте имя и найдите релевантное стоковое фото. Это делает персонажа живым.

  • Демография. Возраст, пол, локация, образование, должность, доход (если релевантно).

  • Цитата-девиз. Одна фраза, которая отражает главную мотивацию или отношение. "Главное — не потратить время зря".

  • Роль/Контекст. Кто он в рамках вашего продукта? (Начинающий инвестор, руководитель отдела продаж, молодая мама).

  • Биография/Контекст жизни. Краткая история, которая объясняет его текущую ситуацию и ценности.

  • Цели (Goals). Чего он хочет достичь в работе с вашим продуктом? (Высокоуровневые и конкретные).

  • "Боли" (Pains). Страхи, фрустрации, препятствия, которые мешают ему достичь целей.

  • Мотивация/Выгоды (Gains). Что он считает успехом? Какие конкретные выгоды ищет?

  • Сценарии (Scenarios / Jobs to be Done). Как он приходит к необходимости решить проблему? "Когда я вижу интересную статью в метро, но нет времени читать, я хочу сохранить её в удобном формате, чтобы прочитать позже с любого устройства".

  • Отношение к технологиям/каналы. Как он ищет информацию? Какие устройства и соцсети использует?

  • Влияние на покупку/использование. Как принимает решение? Что для него важно при выборе (цена, удобство, репутация)?

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

2.5.  Прием - конкурентная разведка

Конкурентная разведка" (Competitive Intelligence, CI) - это систематический и этичный процесс сбора, анализа и применения информации о конкурентах, рынке и отрасли для принятия стратегических решений. Оговоримся сразу, что это не шпионаж, а легальное исследование открытых данных, которое систематизирует и превращает хаос информации в конкурентные преимущества.

Цель - не просто узнать, что делает конкурент, а понять, почему он это делает, куда движется, и как использовать это знание для своей стратегии.

Задачи конкурентной разведки:

  • Определить позиционирование. Как нас и конкурентов воспринимает рынок?

  • Выявить слабые и сильные стороны конкурентов. Где они уязвимы? Где нас обгоняют?

  • Предсказать действия. Какие новые продукты, рынки или фичи они могут запустить?

  • Обнаружить рыночные тренды и "слепые зоны". Какие потребности клиентов не закрыты?

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

  • Обосновать инвестиции и приоритеты. Например, "Конкуренты уже вкладывают в AI-чатботов, нам нельзя отставать".

Основные приемы и источники сбора данных.

  • Продуктовая разведка. Анализ характеристик продуктов конкурентов и пользовательского опыта их фичей, API, юзабилити.

  • Анализ цифрового следа и маркетинга. Изучение рекламных кампаний, отзывов, SEO (ключевые слова, объем трафика, источники), контент-стратегий (о чем пишут в блогах, проводят вебинары).

  • Финансовая и юридическая разведка. Исследование инвестиций, выручки, структуры цен, годовых отчетов, презентаций инвесторов.

  • Технологическая разведка. Анализ технологий, стеков, патентов.

  • Кадровая разведка. Мониторинг найма, вакансий, структуры команды.

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

Существует еще множество инструментов и приемов, помогающих профессионально сформировать Видение.

Дальше мы рассмотрим вопрос: как можно произвести предварительную оценку ресурсоемкости предлагаемого решения.