MVP за 7 недель. Как это было
Когда я собрал ребят и сказал, что нам нужно успеть сделать MVP (minimum viable product) нового сервиса к 31 мая, они переглянулись и сказали: «Это невозможно». И вот спустя почти 7 недель разработки, каждый из нас может с гордостью сказать: «Мы сделали это!»
Эта статья — продолжение материала "Как не сделать «какашку»? Личный опыт создания продукта", где я описывал этапы исследования и проектирования продукта. Теперь мне бы хотелось поделиться личным опытом и рассказать о том, как нам удалось реализовать «неподъемный» на первый взгляд проект в срок, чем пришлось пожертвовать и показать вам, что в итоге у нас получилось.
Немного лирики про качество и MVP
Вокруг нас множество «серых» обычных вещей. Оглянитесь! Мебель, одежда, машины, техника и даже ваша ручка. Что из этого вам действительно нравится? Что вас восхищает? Что приковывает внимание? Мне очень нравятся красивые, качественно сделанные и продуманные вещи. Это может быть миксер Bosh, багажник SKODA Octavia или картина "Вавилонская башня" (Питер Брейгель Старший, 1563г). Ну не красота же?
И тут, когда ты с нуля создаешь новый продукт, у тебя бьет фантазия ключом как у художника, тебя берут и помещают в рамки MVP. MVP переводится как «минимально жизнеспособный продукт» и подразумевает какой-то простой прототип, который позволит проверить жизнеспособность идеи на практике. Об идеальности речи не идет. Разве так можно? Оказывается — можно. Вот те самые несколько приемов, которые позволили нам найти компромисс между сроками, MVP и нашими представлениями об идеале.
Что мы сделали?
1. Мы «забили» на инфраструктуру. Часто бывает, когда новый проект начинается с нового офиса, а не с рабочего прототипа =) Поэтому для всего проекта мы делали только тот минимальный набор инфраструктурных задач, который был «кровь-из-носа» необходим. Например, до недавнего времени у нас даже не было сервера под проект, он появился только на 5 итерации. До этого весь проект делался ребятами на локале. А тестовый магазин для нашего сервиса, где впервые запустили решение «во вне», мы сделали на бесплатной платформе за 5 минут, хотя вначале думали над вариантом полноценного развертывания одной из CMS на нашем сервере.
В результате накопилась целая куча задач «на потом», причем такая, что нам даже пришлось их классифицировать. Они морально давят и по сей день, но ребятам удалось найти баланс между разработкой «фасада» и «каркаса» нашего продукта. Вот небольшая их небольшая часть:
2. Больше думай, меньше делай. Первая мысль, которая приходила мне в голову в самом начале проекта: «Парни! Что же мы сидим, давайте кодить, иначе не успеем!» Но практика показывает, что, чем меньше строчек кода будет написано, тем лучше. Мы реально много времени тратили на исследование и выбор технологий, на коммуникацию внутри команды. Такие затраты с лихвой окупались в последующей продуктивности и экономии времени. А для того, чтобы повысить эффективность коммуникации на первые 3 итерации мне пришлось переехать в наш Брянский офис разработки и на последующие итерации каждую пятницу приезжать для Demo и Sprint Planing.
3. Первым делом мы перешли на недельные итерации. Было сразу понятно, что нам придется сильно поменять наш существующий подход к разработке, так как выпуск нового продукта и поддержка/развитие старого кардинально отличались. Когда есть большая неопределенность, результаты нужно получать как можно быстрее. Сделал? Покажи! К тому же недельные итерации проще планировать, особенно если задачи между собой сильно взаимосвязаны.
4. «Нафиг» — стало нашей любимой фразой. Из системы мы выкинули почти все, кроме ключевых фишек нашего продукта. Оставили только те возможности, которые позволили бы проверить гипотезы или без которых продуктом нельзя было бы пользоваться в принципе. Но то что оставляли — делали хорошо! Простой пример. В нашем сервисе есть функционал отправки follow-up писем покупателям через несколько дней после покупки товара. Вот как мы рассуждали и отрезали возможности:
Возможность изменить тему и текст письма— нафиг, так как вариант по умолчанию достаточно хорош и единицы реально будут что-то менять.Возможность указать имя и email отправителя— нафиг, так как не так много покупателей будут обращать внимание на email отправителя и еще меньше клиентов сервиса будут этот самый email настраивать.Возможность полной кастомизации шаблона письма— нафиг, так как опыт текущего проекта показал, что менее 1% клиентов этим занимаются. Тем более наш шаблон сверстан профессионально и адаптирован под разные устройства и почтовые клиенты.- Возможность брендирования (легкая) — оставили, чтобы покупатели магазинов не пугались.
- Возможность задать период отправки писем — оставили, так как магазины из разных товарных категорий должны рассылать email с разной задержкой.
5. Чем проще, тем лучше. Оставшиеся после обрезки возможности мы старались реализовать максимально просто и эффективно. Так, например, возможность настройки внешнего вида виджета отзывов мы упростили до всего одного параметра — цвета кнопки и элементов. И первые внедрения у наших клиентов показали, что этого достаточно!
Так же мы старались не делать второстепенного. Если какой-то функционал не ведет нас напрямую к цели сделать MVP к 31 мая, то мы его просто не делали. Например, мы реализовали возможность восстановления пароля только в 6 итерации, когда стало понятно, что мы можем себе это позволить. Если бы мы не успевали, то оставили бы как есть. Если возникали сомнения в нужности или целесообразности реализации чего-то — мой ответ сразу «Нафиг».
Итоги
Наш MVP несколько отличается от того первоначального, который мы планировали сделать на этапе разрезки макетов на UserStory. Красной линией на фото ниже отмечены те US, которые мы планировали сделать, а синяя — то что получилось в итоге. В живую потыкать палочкой наш MVP можно на этом тестовом стенде.
Команда состояла из 3 профессиональных разработчиков + 1 Product Owner. В течение проекта один из разработчиков на 1 неделю уходил в отпуск. Выделенного дизайнера, как и верстальщика, в команде нет. Для ускорения разработки использовали купленный макет. По ночам и выходным не работали, но в рабочее время трудились напряженно =)
Вся команда получила массу эмоций и отличный опыт разработки MVP нового продукта. Мы многому научились и еще много предстоит сделать. Надеюсь наш опыт будет вам полезен и если у вас есть вопросы, буду рад ответить в комментариях.
Автор: STdio