Ну вот вы и создали какой-то полезный веб сервис, и даже накопили социальный капитал в виде какого-то количества ранних пользователей, которые рискнули и начали использовать ваш продукт.
А может быть уже даже начали конвертировать социальный капитал в финансовый – появилась первая выручка. Теперь становится важным вопрос о том, конкретно какая функциональность продукта должна быть приоритизирована и передана на разработку в первую очередь, а что может подождать до морковкиного заговенья. На ранних стадиях развития дела решение о том, чем заниматься в первую очередь, лежит на руководителе – он владелец продукта и вперёдсмотрящий матрос. Ошибиться в этом вопросе означает потерять темп, завязнуть в бессмысленных задачах и отпугнуть пользователей от своего продукта.
Я хочу поделиться своим опытом приоритизации функциональности веб сервиса на примере онлайн бухгалтерии для частных предпринимателей “Где Деньги”. Самый важный вывод, который я сделал на сегодняшний день: развитие продукта напоминает открытие кодового замка: вы можете тратить время на нужные задачи, но если вы решаете их в неверном порядке, то это приводит к проблемам.
История начиналась как обычно: был набросан список для создания минимально жизнеспособного продукта (MVP) и именно его (продукт) мы запустили 28 марта этого года. Потом, заполучив за месяц около 300 бета пользователей, мы начали добавлять ту функциональность, которую они просили в порядке “первый пришёл, первый ушёл”. У нас хватило ума быстро остановить этот идиотизм. В один и тот же день мы получили просьбу о создании функциональности метода калькулирования себестоимости по методу поглощения затрат и просьбу упростить сервис, потому что всё становится слишком сложным. Ой…
Поняв, что приоритизировать задачи по методу “первый попросил, первый получил” это ошибочный путь, я решил делать приоритизацию так:
Создал список всех задач на разработку в электронной таблице.
Сделал примерную оценку себестоимости каждой задачи в points. Points – это относительная единица измерения сложности выполнения задачи в Pivotal Tracker, который мы используем для организации работ по разработке. В принципе, можно в качестве себестоимости задачи указать и часы, и денежное выражение – это не имеет принципиального значения.
Рядом я добавил колонку, где указал полезность задачи с моей точки зрения, измерив её также в points.
В следующей колонке я разделил значение из пункта (3) на значение из пункта (2), тем самым получив ROI (возврат на инвестиции) каждой из задач. Задачи с самым высоким ROI получали приоритет в разработке.
Поработав так несколько недель, я отказался и от этого метода. Проблема возникла в оценке объективной полезности задачи. Ну например, что более важно: создать механизм надёжного шифрования данных или добавить возможность отслеживания передан ли акт выполненных работ заказчику? А может сделать API? Сравнение между собой этих задач – это проблема сравнения тёплого, синего и квадратного. Кроме того, якобы “объективная” оценка полезности той или иной задачи изменялась в контексте окружения этой задачи другими, новыми задачами: вновь добавляющиеся задачи подталкивали к переоценке уже оценённых ранее задач: “Эту функциональность мы сделаем, но смотри какую крутую штуку мы придумали. Это будет легко сделать и все будут нас благодарить”. Нет, обычно это сделать не легко и никто не благодарит.
Нужно было придумывать новую технологию расстановки приоритетов. Я поступил следующим образом: скопировав из предыдущей таблицы список задач по вертикали, я добавил следующие значения по горизонтали:
Дизайн, внешний вид, awesomness
Удобство использования
Безопасность сервиса
Соответствие законодательству и деловым практикам
Расширение сегментов использования сервиса
Поддержка
Automagic
Каждую из задач я отнёс к той или иной колонке. Некоторые задачи попали сразу в несколько колонок. Теперь, когда я получил такую таблицу с отличной визуализацией, стало понятно как именно двигаться дальше: делаем первыми задачи, которые попали в несколько столбцов, потом выполняем задачи равномерно по всем колонкам, так чтобы “Где Деньги” развивались гармонично. В какой-то степени это напоминает модель Нориаки Кано, которая делит функциональность продукта на три категории: basic, performance и excitement. MVP находится в центре этой диаграммы. Больше про модель Кано можно прочитать, например тут.
Сегодня я понял, что и эту технологию также пора менять. Появилась гипотеза, что верным подоходом будет создание приоритизации на основании важнейших метрик. Эти метрики для молодых web компаний давно известны и признанным авторитетом тут является Dave MacClure с его “Startup Metrics for Pirates: AARRR”. Если вы ещё не знате что это такое, то рекомендую посмотреть его слайды, например тут .
Идея проста: мантра для начинающих компаний – это “три пэ”: Построй, Померь, Пойми (не путать с “три пэ” подходом к ценообразованию!). Если мы создаём какую-ту новую функциональность в “Где Деньги”, то было бы неплохо иметь возможность измерить на что это повлияло, как сильно и позитивное это влияние или нет. Для этого нужно отобрать метрики, по которым мы будем сверять направление движения. Очевидно, для нас сейчас важнейшими метриками будут “Acquisition” (завоевание клиентов), “Activation” (люди начинают пользоваться сервисом) и “Revenue” (выручка). А значит, каждую задачу на разработку нужно рассматривать через увеличительное стекло этих метрик и, если запрашиваемая функциональность не помогает улучшать значения этих метрик, то беспощадно снижать приоритет таких задач вплоть до полного уничтожения.
Пока у меня ещё нет чёткого представления как эта технология приоритизации будет выглядеть на практике. Потребуется какое-то время чтобы её внедрить и отладить. Если результат будет интересным – я поделюсь и им.
Источник: ain.ua
|
