Разработка бизнес-приложений: Как сократить бюджет, отобрав только самые полезные функции

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

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

Что такое отбор функций по приоритетности?

Это процесс создания матрицы бизнес-целей с назначением значимости и приоритетности каждой из них. Такой подход помогает сбалансировать мнения разных департаментов, основываясь на объективных данных, а не на том, кто громче всех отстаивает свою позицию на митинге или пишет самые воодушевленные email’ы.

Кому нужно задумываться о приоритетности функций?

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

Для чего нужна расстановка функций по приоритетности?

Она позволит сберечь Ваши нервы и средства. Вы сможете:
  • Добиться объективности. В бизнесе не место эмоциям. Обратившись к стандартизированной процедуре, Вы оперируете логикой и измеримыми показателями. Ничто не будет одобрено без железной аргументации, а команде разработки не придется получать 10 разных инструкций от 10 руководителей и тратить уйму ценного времени впустую.
  • Увеличить ценность разрабатываемого ПО для бизнеса. Создание любого софта – непростая и дорогостоящая инициатива. Исследование, проводимое перед стартом разработки, обойдется в разы дешевле, чем реализация излишних функций и опций. Чем четче поставлена задача перед командой разработки – тем лучше, и тем меньше вероятность дополнительных расходов на переделки и исправления.
  • Сгладить острые углы. Все, кто участвует в принятии решения, будут работать сообща, а не друг против друга. Процесс нацелен на выявление оптимальных для бизнеса решений, а не самых инновационных или ярких идей и людей, которые их генерируют.

Основные принципы

Задавайте вопросы

Первый шаг – задать бизнес-ориентиры: выделить цели, проблемы, целевую аудиторию. Ниже приведено 6 важных вопросов, на которые должны ответить все участники:

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

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

Будьте открыты

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

Проанализируйте имеющиеся данные

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

Проводим обсуждение приоритетности функций

Чтобы встреча прошла успешно, назначьте модератора – человека, который будет ее вести, следить за временем и отвечать за заполнение матрицы приоритетов.

Соберите полный список функций

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

Давайте рассмотрим процесс на примере. Допустим, писатели Москвы создают мобильное приложение, чтобы общаться и взаимодействовать с жителями города. Назовем его «Другая Москва». Участники объединения хотят проводить разные мероприятия и использовать приложение, чтобы стать ближе к ценителям современной литературы. В результате обсуждения был сформирован такой список возможностей и особенностей приложения:

  • Отзывы и комментарии
  • Простой и красивый UX
  • Инструменты для аналитики и сбора данных
  • Рассылка информации в приложении от организаторов мероприятий
  • Бонусная система для посетителей
  • Push-уведомления
  • Календарь встреч с писателями
  • Интеграция с социальными сетями: Facebook, Вконтакте, Twitter, Instagram
  • Интегрированный сервис почтовой рассылки (например, MailChimp)

Определите цели разработки

Далее модератор просит участников задать ключевые бизнес-ориентиры. В нашем воображаемом примере они будут следующими:

  • Повышение вовлеченности
  • Распространение информации
  • PR
  • Набор пользовательской базы
  • Создание имиджа бренда и ассоциаций с ним
Определите цели разработки

Определите значимость каждого критерия

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

Определите значимость каждого критерия

Дайте оценку каждой функции

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

Значимость 25 40 15 10 10 100
Функция приложения Тема Повышение вовлеченности Распространение информации PR Набор пользовательской базы Создание имиджа бренда Итого
Отзывы и комментарии Взаимодействие 5 4 4 4 3 83
Простой и красивый UX UX 5 4 5 4 4 88
Инструменты для аналитики и сбора данных Изучение поведения ЦА 5 5 3 4 2 86
Рассылка информации в приложении от организаторов мероприятий Информирование 5 5 5 3 3 92
Бонусная система для посетителей Удержание пользователей 5 5 2 5 3 72
Push-уведомления Информирование 4 3 2 2 1 56
Календарь встреч с писателями Информирование 4 3 2 2 1 56
Интеграция с социальными сетями: Facebook, Вконтакте, Twitter, Instagram Взаимодействие 4 3 2 2 1 56
Интегрированный сервис почтовой рассылки (например, MailChimp) Информирование 4 1 1 4 1 41
Купоны Удержание пользователей 5 1 3 1 2 48

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

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

Формула расчета суммарной оценки

Здесь:

  • Сф — суммарная оценка функции;
  • Ц1 — оценка влияния функции на бизнес-цель 1;
  • Ц2 — оценка влияния функции на бизнес-цель 2;
  • ЦN — оценка влияния функции на бизнес-цель N;
  • З1 — значимость бизнес-цели 1;
  • З2 — значимость бизнес-цели 2;
  • ЗN — значимость бизнес-цели N;
  • N — число бизнес-целей.

Что в итоге?

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