Как делать приоритизацию задач при разработке web сервиса?
Ну вот вы и создали какой-то полезный веб сервис, и даже накопили социальный капитал в виде какого-то количества ранних пользователей, которые рискнули и начали использовать ваш продукт. А может быть уже даже начали конвертировать социальный капитал в финансовый — появилась первая выручка. Теперь становится важным вопрос о том, конкретно какая функциональность продукта должна быть приоритизирована и передана на разработку в первую очередь, а что может подождать до морковкиного заговенья. На ранних стадиях развития дела решение о том, чем заниматься в первую очередь, лежит на руководителе — он владелец продукта и вперёдсмотрящий матрос. Ошибиться в этом вопросе означает потерять темп, завязнуть в бессмысленных задачах и отпугнуть пользователей от своего продукта.
Я хочу поделиться своим опытом приоритизации функциональности веб сервиса на примере онлайн бухгалтерии для частных предпринимателей “Где Деньги”. Самый важный вывод, который я сделал на сегодняшний день: развитие продукта напоминает открытие кодового замка: вы можете тратить время на нужные задачи, но если вы решаете их в неверном порядке, то это приводит к проблемам.
История начиналась как обычно: был набросан список для создания минимально жизнеспособного продукта (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” (выручка). А значит, каждую задачу на разработку нужно рассматривать через увеличительное стекло этих метрик и, если запрашиваемая функциональность не помогает улучшать значения этих метрик, то беспощадно снижать приоритет таких задач вплоть до полного уничтожения.
Пока у меня ещё нет чёткого представления как эта технология приоритизации будет выглядеть на практике. Потребуется какое-то время чтобы её внедрить и отладить. Если результат будет интересным — я поделюсь и им.
Комментарии | 38
в слове приоритИзация ошибка 😉
Это все, что вы вынесли из статьи?
Да, Вы правы.
Вадим, де ти черпаєш всі ці знання? Поділися, що читаєш?
Вадим, Вы в прошлой жизни явно были консультантом, верно? Это чувствуется…
У меня не было прошлой жизни.
Вадим, большое Вам спасибо за статью. Приятно, что есть люди, которые готовы поделиться опытом.
Мне кажется, что вы слегка рано запустились. Т.е. начали теститься когда продукт еще был не готов. А пол дела обычно не показывают.
ps И лично мое мнение, наверно стоило употреблять русские эквиваленты «Activation», «Acquisition» т.к. что подразумевалось лично мне не понятно. Но возможно я редкое исключение.
Пол дела не показывают? Вы давно в Google+ заходили?:)
Артур, увы не пускает меня Google+ даже с инвайтом, токма скрины на ain.ua видел 🙂
По сути есть разница между «шаровым» проектом, где клиент не платит. И коммерческой программой, где консультанту-тестировщику после работы еще предложат купить продукт. имхо.
Игорь, мы сделаем специальное предложение тем, кто был с нами, когда «Где Деньги» были бесплатные. А насчёт «шаровых» сервисов: я уже говорил на DOU, что в Web если ты не платишь за продукт, то ты сам и есть продукт. 🙂
Ок.
А як зрозуміти, де половина, коли продукт постійно росте?…
І потім, є значна частина людей, для яких інтерфейс командної строки — це уже цілком готовий до вживання продукт.
Все они правильно сделали с запуском. Почитайте «four steps to the epiphany» и для вас многое станет ясно, а взгляд на подобные вещи поменяется на противоположный.
дело в том, что Вадим не изобретает принципиально новый продукт, он делает бухгалтерию, перенимая опыт российских коллег. проект запустился больше трех месяцев назад, но функционал в нем практически не изменился и остался таким же минимальным: выписка пары-тройки видов первичных документов, формирование отчетности. по сути все. на мой взгляд жидковато для того, чтобы по очереди применять кучу методик, чтобы решить, что делать дальше. создается впечатление, что у Вадима самого нет целостного представления о том продукте, который он создает. ну и налицо стремление применять разные премудрые зарубежные методики по любому поводу: для формирования роадмапа проекта, для прайсинга и т.д. 🙂 это подход «консультантов»: если мы все будем делать как в умных книжках написано, то у нас все получится 🙂 реальность обычно бывает совсем другой.
второе наблюдение, которое я сделал и хочу озвучить: Вадим явно не торопится. забыл про заповедь «be fast!». прошло уже ТРИ!!!! месяца с момента громкого анонса «первой онлайн-бухгалтерии», появился ряд статей в СМИ, ведутся разговоры про прейскурант и почему не будет бесплатных пользователей, но функционал остается все таким же аскетично-минимальным, ничего не меняется. прошло три месяца и «первая онлайн-бухгалтерия» уже давно не первая, а все так же в приват-бете. поверьте на слово, я не новичок в разработке софта и знаю, что за три месяца при должной пассионарности можно очень много сделать. конечно, возможно, команда Вадима готовит некий супер-релиз, в котором будет ого-го сколько всего, после чего будет промышленный запуск, но мне слабо в это верится. Что касается обещанных сроков запуска, то Вадим уже их все профакапил 🙂 видимо, пока перебирал методики приоретизации и размышлял над ценником 😉
Опыт российских коллег важен. Например с Масксимом Яремко («Моё Дело») мы поддерживаем отношения, консультируемся и так далее. Но мы равняемся в основном на другие продукты. В России есть специфика, которой нет у нас. Вы очень пристально наблюдаете за мной (мне это приятно) и не можете не знать, что я большую часть своей жизни посвятил «тяжёлому» экономическому ПО. Есть очень чёткое понимание чего в «Где Деньги» не будет никогда. Нет желание создавать 1C в облаке.
И я не совсем понял: что именно я профакапил? Уточните, пожалуйста.
Вадим, Вы не обижайтесь 🙂 я так, в порядке здоровой критики 🙂
я действительно заинтересовался Вашим сервисом и сделал ресеч в гугле в поисках доп. информации. уж не помню в каких именно статьях, но Вы озвучивали сроки комм. запуска сервиса — это я точно помню. время идет, но сервис по прежнему в бете, а множатся только публикации. это я и называю: профакапить обещанные сроки запуска.
еще раз повторю свою мысль: на мой взгляд, Вы слишком медленно двигаетесь. я могу не все знать, конечно, но за 3 месяца состояние сервиса не изменилось. т.е. пропорция пиарного материала к функционалу несколько завышена 🙂
то, что у Вас есть понимание, чего в сервисе не будет никогда — это здорово. но в моем понимании, когда создаешь продукт, всегда должна быть прежде всего своя гипотеза о том, как этот продукт должен выглядеть и за что люди будут платить деньги. идея в том, чтобы проверить гипотезу как можно скорее, и скорректировать ее по результатам обратной связи. и двигаться такими итерациями далее.
ну да что я Вам рассказываю, Вы сами все знаете 😉 я уверен, что у Вас все получится, только быстрее надо в наше динамичное время 🙂
Про один продукт его злопыхатели так говорят постоянно. Его название Basecamp.
каждый сервис мнит себе Бэйзкампом и это в общем, правильно — нужно стремиться к великим ) но правда жизни заключается в том, что Бэйзкамп один такой
дело в том, что Вадим не изобретает принципиально новый продукт, он делает бухгалтерию, перенимая опыт российских коллег. проект запустился больше трех месяцев назад, но функционал в нем практически не изменился и остался таким же минимальным: выписка пары-тройки видов первичных документов, формирование отчетности. по сути все. на мой взгляд жидковато для того, чтобы по очереди применять кучу методик, чтобы решить, что делать дальше. создается впечатление, что у Вадима самого нет целостного представления о том продукте, который он создает. ну и налицо стремление применять разные премудрые зарубежные методики по любому поводу: для формирования роадмапа проекта, для прайсинга и т.д. 🙂 это подход «консультантов»: если мы все будем делать как в умных книжках написано, то у нас все получится 🙂 реальность обычно бывает совсем другой.
второе наблюдение, которое я сделал и хочу озвучить: Вадим явно не торопится. забыл про заповедь «be fast!». прошло уже ТРИ!!!! месяца с момента громкого анонса «первой онлайн-бухгалтерии», появился ряд статей в СМИ, ведутся разговоры про прейскурант и почему не будет бесплатных пользователей, но функционал остается все таким же аскетично-минимальным, ничего не меняется. прошло три месяца и «первая онлайн-бухгалтерия» уже давно не первая, а все так же в приват-бете. поверьте на слово, я не новичок в разработке софта и знаю, что за три месяца при должной пассионарности можно очень много сделать. конечно, возможно, команда Вадима готовит некий супер-релиз, в котором будет ого-го сколько всего, после чего будет промышленный запуск, но мне слабо в это верится. Что касается обещанных сроков запуска, то Вадим уже их все профакапил 🙂 видимо, пока перебирал методики приоретизации и размышлял над ценником 😉
Метрика Дэйва действительно полезная штука, только там есть еще один важный пункт как удержание пользователей. По сути они ведь платят за сервис.
имхо, пожелания к сайту:
— на главной нет демо продукта, есть только описание функционала
— на главной нет четкого пояснения преимуществ и почему этим нужно воспользоваться
— возможно кейсы кто, как это использует и их отзывы помогут увеличить первую метрику
— возможно расчеты эффективности использования сервиса помогли бы привлечь больше пользователей
Антон, спасибо. Вы правы. Мы заканчиваем работы на demo, нужно переписать материалы с точки зрения проблемы, а не решения и добавить кейсы использования.
+1. Демо и кейсы — это главное, что привлечет новых пользователей.
Покажите им, как изменится их бизнес на простом примере и какую выгоду они получат (укажите конкретные часы/гривны).
Вадим, хорошая статья. Спасибо. Правда меня не покидало ощущение, что ее аудитория на developers.org.ua.
Ты думаешь она рассчитана на программистов?
Я подумал, что она проливает свет на сложные темы для тех, кто близко работает с заказчиком программных продуктов. Проектные менеджеры, бизнес-аналитики и менеджеры по продуктовой разработке. И они там есть.
Я рад, что она Вам понравилась. Может быть Вы правы — она получилась несколько «тяжеловата». С другой стороны — это AIN, сюда приходят люди, которым интересен интернет и бизнес, построенный вокруг него. Ну ведь правда — нет ничего более интересного, чем заглянуть за кулисы и увидеть как там всё происходит? 🙂 Надеюсь, людям далёким от разработки, было интересно.
Ну и самое важное. Я по-прежнему рассчитываю на дискуссию с тем, кто это всё уже переживал и указал бы другой, лучший путь.
По поводу развития продукта.
Я так понял, плана выпуска обновлений у вас нет.
Обязательно заведите его.
Пользователей, которые уже пришли, легче будет удержать, если они будут четко видеть: через 2 недели — нужная им фишка, через 4 — еще одна.
Александр, Вы имеет в виду какую-ту дорожную карту, где будут расписан планируемый выпуск обновлений?
Александр, Вы имеет в виду какую-ту дорожную карту, где будут расписан планируемый выпуск обновлений?
В общем случае — да.
Вообще то как вам удобнее, так и публикуйте план.
Тут важно, чтобы вы, как руководитель проекта, или команда не погрязли в излишнем «бумагомарательстве».
Можно просто заявить, что каждую неделю/две/месяц вы будете выпускать обновление и по факту создавать
новость с перечнем нововведений.
А можно сделать именно план: дата — список запланированного.
Если есть жалобы пользователей в недостатке функционала (тем более, вас критикуют за молчание и срыв заявленных сроков) или вы сами не успеваете заниматься планом, то я бы остановился на первом варианте.
В средине срока можно публиковать запланированные на текущий этап работы. К этому времени уже будет известно, что вы успеваете, а что нет.
Так вы и пользователей подогреете и команда не будет расслабляться.
В вашем случае я бы выбрал период неделя/две.
С одной стороны, не слишком долго, с другой — за этот срок вполне реально добавлять видимые пользователям и вам, как владельцу проекта, плюшки.
Сейчас публикуете новость о переходе к регулярным обновлениям, объявляете сроки и какими задачами будете заниматься в первую очередь. Не обязательно конкретно озвучивать задачи, можно просто описать направления развития. А потом — циклически по рекомендуемому выше принципу в рамках заявленных сроков.
Сейчас время отпусков. Если у вас люди уходят на отдых, скажите об этом и укажите сроки, когда ваша команда снова выйдет на обычный режим работы.
Но, мне кажется, вам сейчас не время отдыхать.
Если продукт новый и только формирует рынок, мне кажется, пожелания пользователй стоит собирать, но вот полагаться на них не стоит. Даже, если они целевой сегмент, это сегмент может не совсем понимать, что ему на самом деле важно и нужно, и уж тем более как оно должно выглядеть. Тут задача продак менеджмента быть визионером.
Вадим, с вашим прикладным веб сервисом тройные интегралы ни к чему. Сделайте минимум, который нужен предпринимателям. И за который им будет не жалко заплатить. Например, последняя запись в блоге gdedengi.com.ua посвящена сдаче отчетности. И называется «можно ли отчитаться по почте». Зачем предлагаете возвращаться к бумажному прошлому?Предоставьте возможность онлайн подписать и отправить ваши электронные отчеты в ГНИ и ПФУ. Все. Одного этого будет многим предпринимателям достаточно для принятия решения в пользу вашего сервиса. Приоритет в вашем случае предлагаю рассчитывать не только графиками. Решайте первоочередные задачи клиента, экономьте его дорогое время. Вам это будет выгодно.И еще. Такие штуки, как юзабилити и безопасность важны — ставьте их на второе место. А вот дизайн может отсутствовать (по опыту 1С — абсолютно).
Спасибо, Александр. Это, наверное, самый правильный совет. Работа над подачей отчётности через интернет идёт полным ходом. После того, как закончим — возможно я расскажу как именно это происходит в Украине. Вынос мозга, конечно. Так драма на уровне сертификационных центров, которые воюют друг с дружкой. Наши российские коллеги решили вопрос проще: они оформились как налоговые представители, собирают доверенности с пользователей и сдают вместо них. Такой вот полуавтоматический SaaS :). Я считаю — это не очень хороший вариант.
Хороший продукт. Уверен всё у вас пойдёт!
Мой совет таков: на главной странице разместите ( желательно гда то по центру 🙂 ) очень качественный ролик о вашем продукте, и о его пользе клиенту. На это дело не жадничайте ни денег ни времени. От его качества зависит скорость принятия решения клиентов. Согласитесь ваш клиент это не супер юзер. Он бывший более-менее хороший наёмный сотрудник, которому в новой для него среде, нужно на пальцах показать что, как, и почему и как вы решите его проблемы. Только тогда большинство из них даже не станет задумыватся и сделает нужен вам выбор. Сдесь самое главное — простота обьяснения.А что касается ядра клиентов, то оно наверное состоит из тех кто ещё не уверенно освоил компьютер и интернет. Это же не те более продвинутые юзеры (им скорее всего нужны продукты более прогресивные), а скорее тот кто решил попробовать работать сам на себя. И его нужно привлекать в основном с Офлайна с помощью агентов в лице сотрудников регистрационных палат, налоговых, пенсионных фондов, центров зайнятости и прочих. Сделайте их своими помочниками в росте клиентской базы за разовый хороший бонус и они обзвонят всех кого надо 🙂 Будет интересно и ваше мнение по этому поводу и мнение других товарищей.Спасибо.
Хорошая статья! Спасибо. Взял некоторые моменты для себя.
От себя порекомендовал бы всем методику Бодо Шефера (книга «Искуство управлять своим временем») по приоритетам и их класификации на категории A, B, C, D. (очень всё просто и гениально). Советую всем. Есть также аудио вариант. Также желательно концентрироватся на задачах по принципу похожему на тот который написан више Александром Шацким. А именно 20/80. То-есть 20% роботы делает 80% дохода.
Собственный опыт таков: стараюсь множество разных методик и подходов (только самые стоящие) обьеденить о одну. Сложно но можно. Кстати неплохо получается. Думаю что со временем поделюсь. Результаты стоящие.
да уж такой продуманный подход ко всему. Но раставление всех приоритетов иногда забирает слишком много времени
интересная статья спасибо большое