Как не сделать «какашку»? Личный опыт создания продукта

    В этом посте хочется поделиться личным опытом создания продукта с нуля. Путь «а давайте запилим/скопируем и выкинем на рынок» мы уже проходили. Такой подход чуть не убил нашу компанию.

    image

    По статистике, около 50% фич среднестатистического продукта никогда не используются и только 12% опций клиенты используют активно. Как всегда попадать в эти 12% функционала? А что, если я сам не являюсь пользователем этого продукта? Как сделать продукт простым и удобным? Наконец, стоит ли его вообще делать нашей компании? И как понять, будет ли продукт востребован рынком еще до его создания?

    Я помню этот день, как будто все случилось только вчера. В понедельник 27 января 2014 года совершенно случайно наткнулся на документ «How Spotify builds products». Этот небольшой мануал уложил 3 предыдущих года разработки, десятки статей и несколько тренингов в стройную систему в голове. Схема всего процесса из мануала приведена в заголовке поста.

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

    И вот, наконец, мы подошли к первому шагу «Think IT»





    • Первым делом мы сами для себя ответили на такие важные вопросы: Зачем мы это делаем? Какие выгоды/преимущества мы хотим получить от этой затеи? Почему мы будем делать именно это, а не 10 других возможных продуктов?
    • Далее мы сформулировали ключевые метрики, которые наш продукт будет улучшать для наших клиентов.
    • Также сформулировали гипотезы продукта (те допущения, которые будут проверены на реальных клиентах). Основные гипотезы две: гипотеза ценности продукта для клиента и гипотеза роста (как этот продукт будет распространяться).

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

    image

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

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

    image

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



    В идеале, нужно было бы пойти с этими прототипами к клиентам и дать им поиграться с этим материалом. Этот шаг мы решили пропустить и сразу сделать Mockup. Для этих целей была куплена тема на Bootstrap за $20 и за несколько часов создан симпатичный Mockup.

    Еще за пару часов была сделана презентация несуществующего продукта с нашими мокапами и разослана нескольким клиентам. После вопросов: «Когда можно купить?» и «Сколько стоит?» — стало понятно, что как минимум, живой прототип нужно делать!



    В общей сложности на Эмпатию и этап «Think IT» мы потратили около 1,5 месяцев. Эта работа велась параллельно основной деятельности компании. С уверенностью могу сказать – это время потрачено не зря. Мы ответили на ключевые вопросы, вникли в предметную область, определили набор функционала для MVP и подготовили прототипы, проверили саму идею и нашли более 15 бета-тестеров.

    Что теперь? Начинаем кодить (Build IT)!


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

    image

    Делали мы это в команде в первый раз и возникало много вопросов. Если мы делаем MVP, то нужно ли делать прототипы (а соответственно и StoryMap)продукта на вырост или достаточно того, что приблизительно войдет в MVP? Насколько сильно нужно детализировать Таски и сами Фичи? Как получившийся StoryMap порезать на релизы, а релизы на итерации?

    Сегодня у нас началась четвертая итерация и первоначальные взгляды на вопросы выше немного поменялись:
    1. В MVP мы включили только те опции, которые:
    1. Позволяют проверить гипотезы.
    2. В необходимости которых мы уверены на 100% (были классные идеи, но на текущем этапе не ясно, сработают ли они).
    3. Без которых просто невозможно использовать продукт и которые не вошли в п.1.

    2. Если посмотреть на фото выше, то в первый релиз для клиентов мы включили почти все таски (оранжевые листы). Наш релиз был очень «плоский» и сильно растянут в ширину. В таком подходе мы увидели следующие минусы:
    1. Мы сможем предоставить больше возможностей, но они будут жутко неудобны и ограничены.
    2. Стремясь охватить максимум тасков, мы сильно оттягиваем момент начала использования продукта живыми клиентами, а значит есть риск сделать ненужную клиентам опцию.

    3. Чтобы избежать рисков п.2 и как можно раньше дать клиентам уже работающий продукт (но пока еще не MVP) мы обрезали релиз в ширину и немного увеличили «глубину». Да, в первом релизе для пользователей мы не сможем проверить все гипотезы, но преимуществ такого подхода значительно больше!

    Схема самого шага Build IT представлена ниже. По сути, в течение ближайших 1,5 месяцев мы будем с каждой итерацией приближаться к MVP и открытому бета тесту. В нашем случае мы не ждем этапа Ship IT для запуска живых пользователей. Наши Альфа тестеры будут работать с продуктам уже на стадии Build IT.

    image

    Кстати, все те идеи, которые мы набросали на этапе Think IT, я перенес в отдельный документ IdeaLog. Этот документ предоставляет из себя .xls файл, где на первой странице представлен список продуктов/модулей (например: authorization, search и т.п.), а на второй – идеи в формате JobStory (см. полезные ссылки). У каждой идеи указан автор, дата, тип (JobStory, Epic, Theme) и к какому продукту/модулю она относится. В таком виде легко выбрать все идеи, касающиеся нового продукта. Или выбрать идеи новых продуктов.

    Заключение


    Когда мы внедрили Scrum, мы существенно увеличили скорость разработки. И перед нами встал новый порос: «Что за хрень мы с такой скоростью делаем»? Данный подход позволил перевести количество в качество. Мы только в начале пути, но результаты – поразительны! Надеюсь, наш опыт поможет и вам. Буду рад вопросам и личным советам в комментариях.

    Полезные ссылки по теме:
    1. How Spotify builds products (перевод)
    2. Product Owners Manual
    3. Почему JobStory лучше UserStory
    4. Темы для админки и сайта (от $10)
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 28

      +4
      О, у нас эту диаграмму (то есть похожую, но с такими же этапами) рисовали на прошлой неделе на лекции в универе
        +5
        Это в каком таком замечательном универе показывают такие диаграммы? =)
          +7
          Невинномысский Технологический Институт (филиал) Северо-Кавказского Федерального Университета
          У нас просто препод по надежности ИС сам объездил кучу стран и руководил реальным производством, поэтому и знает чего рассказывать. Как раз «от идеи и исследования рынка до послепродажной поддержки»
            0
            Вы иногда делитесь интересными лекциями )
              +3
              Вам нереально повезло, мои преподы по околокомпьютерным дисциплинам ограничивались фразой «читайте книжки», причем на сдаче выяснялось, что сами они эти книжки не читали.
              Интересно как удалось заполучить человека, который может руководить реальным производством в образование?
                0
                Надо будет спросить. Вообще если мне память не изменяет, то тот преподаватель нашу кафедру изначально и создавал. Сейчас-то уже на пенсии, так что работает, читая лекции и подготавливая аспирантов.
        • UFO just landed and posted this here
            +1
            Кому как.
              0
              Шедевр однако, благодарю! Ребёнка только жалко.
                0
                А мне больше нравится клип вот с ней

              0
              Спасибо, есть полезные мысли в вашем посте. Схема в начале тоже очень порадовала.

              Мы над своим продуктом примерно по такой схеме и работали. Единственное что, никак не можем вырваться из закольцованности «Build It» и желанию сделать максимально привлекательный и полезный для пользователей продукт. Понимаю замечательно, что это часто становится камнем преткновения во многих молодых командах, мешает росту продукта и корреляции в соответствии с отзывами пользователей. Хотя уже полгода назад при демонстрации продукта на выставке клиенты просили нас начать продавать свой продукт. Как вы прошли через эту критическую точку?
                0
                -delete
                  0
                  Когда мы разложили проект в виде StoryMap, стало четко понятно, какую минимальную функциональность мы можем дать клиентам, чтобы они получили хоть какой-то результат. При этом, разумеется, то что мы будем предлагать будет выглядеть довольно прилично. «Приличность» достигнута за счет купленной темы админки, фрейворков и т.д. + максимальным упрощением всего и вся.
                  0
                  Может быть сделать заголовок более приличным и убедительным? Я не ханжа, но посылать ссылку коллегам на статью с таким заголовком… Не уверен, что меня поймут и не знаю как воспримут его люди с серьезными лицами. :))
                    0
                    Многие, именно из-за заголовка её и откроют =)
                      0
                      Маркетинг? ))
                        0
                        В том числе =) А вообще стараюсь называть вещи своими именами.
                    +2
                    Хорошо бы выделить этап первого реального внедрения у клиента. Это очень непростой этап на самом деле. У клиента часто возникают новые фундаментальные требования к продукту и серьезные фич-реквесты на пару месяцев разработки. Кроме того поддержка клиентов начинает съедать много ресурсов команды. Пишу по собственному опыту.
                    • UFO just landed and posted this here
                        0
                        Немного об этом тут
                        +3
                        Так вы не сделали какашку потому, что ещё не сделали ничего? :)

                        Обманчивый заголовок, создаёт ощущение, что вы сделали что-то реально работающее, продающееся и приносящее пользу.
                          0
                          Продукт — это то, что имеет клиентов. Если клиентов нет, то это не продукт, а груда железа и кода, прототип, идея и т.д.
                            0
                            Согласен, может оказаться, что мы как не крути все равно сделали «какашку». Как будет первая продажа — отпишусь, если не забуду.
                          0
                          Какие использовали инструменты электронные? Trello, Pivotal? Многие команды распределенные, доска на стене не у всех возможна.
                            0
                            Trello — только для меня, команда ее не видит, а я там систематизирую продукты/модули по этапам.
                            Excel для IdeaLog и BackLog.
                            Реальная доска для Скрама.
                            0
                            поделитесь, пожалуйста, а в чем вы рисовали такие диаграммы? :)
                              0
                              Рисовал не я, были готовые.
                              0
                              Спасибо за статью, было интересно почитать про реальный опыт.
                              Скажите, пожалуйста, какого размера была команда на этапе «Think IT», кто в неё входил?

                              Only users with full accounts can post comments. Log in, please.