Превращение велосипеда в космический лайнер: дорожная карта развития IT-продукта

Мы много раз писали об этапах разработки, но ни разу не говорили о том, как эти этапы организуются. Сегодня предлагаем взглянуть на то, как развивается сложный веб-сервис на примере нашего внутреннего проекта: с чего начинается работа, как определить, какие задачи приоритетнее и какие методики помогают запустить проект быстрее.

Превращение велосипеда в космический лайнер: дорожная карта развития IT-продукта

С чего начинается работа над проектом в нашей студии

Работа над проектом начинается с предпроектной аналитики. Это — MustHave.

Большой ее плюс в том, что нам она помогает структурировать будущую работу над проектом, а заказчику — получить 100% релевантный продукт. Подробно об этом этапе мы говорили здесь.

Как это происходит?

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

У проекта появляется крепкий «фундамент», на основе которой создается прототип.

Как выстраивается дальнейшая работа

Для каждого проекта выделяется команда во главе с менеджером. Он курирует работу внутри студии и взаимодействует с заказчиком. Периодически к встречам подключаются другие сотрудники, которые задействованы на разных этапах разработки. При необходимости заказчик может напрямую задавать вопросы людям, которые работают над проектом. Раз в неделю клиент получает от нас отчет, в котором указано:

  • что было сделано на прошлой неделе;
  • что будет сделано на текущей;
  • какие есть сложности или вопросы.

По итогам каждого этапа мы демонстрируем результат.

Несколько слов о Scrum — как и зачем этот метод позволяет наращивать функционал продукта постепенно, опираясь на обратную связь от пользователей.

Scrum — это гибкий метод управления проектами. Под каждый проект собирается команда специалистов с распределенными ролями, работающая на общий результат. Разработка ведется спринтами — короткими периодами в 1, 2 или 3 недели. По окончанию каждого спринта команда получает обратную связь о работе, а заказчик может посмотреть и протестировать самые важные с точки зрения его бизнеса функции.

3 причины, почему Scrum эффективнее традиционной «водопадной» модели, в которой все этапы выполняются в строго фиксированном порядке:

  • за счет прозрачности процесса распределять время команды и деньги заказчика получается эффективнее;
  • срок запуска проекта короче — работа делится на спринты так, чтобы как можно быстрее выпустить первую рабочую версию, собрать обратную связь от пользователей, и на основе этого наращивать функции;
  • возможность контролировать проект и влиять на бюджет — сумма согласуется на определенное количество спринтов, в идеале — на один, а не сразу на весь проект. При этом у заказчика заранее есть ориентиры: стоимость часа разработки и предварительная оценка задач.

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

Представьте, что вы строите дом. Строительство (разработка) на базе фреймворка — это неограниченный запас материалов — кирпичей, бетона, краски — из которых можно создать дом мечты, и при необходимости в любой момент поменять расположение окон и форму крыши

Как мы уже сказали, Scrum делит рабочий процесс на равные спринты — обычно это 2-3 недели. Перед его запуском оговариваются задачи на текущий этап, в конце выдается и обсуждается результат, а команда начинает новый спринт.

Как понять, какие задачи выполнять в первую очередь?

Скрам предполагает Backlog — таблицу с перечнем рабочих задач, расположенных в порядке важности. Задачи в таблице оцениваются по приоритетам, их обозначают цифрами. Между цифрами остаются промежутки, в которые можно добавлять новые задачи, легко меняя приоритетность. Благодаря этому работа становится предсказуемой, планировать спринты становится проще.

Когда закинул фичу в самый конец бэклога
Когда закинул фичу в самый конец бэклога

Формировать список задач на весь проект необязательно — достаточно, чтобы он был известен на несколько этапов.

Перед спринтом команда смотрит в бэклог и «вытаскивает» оттуда наиболее приоритетные задачи.

Как понять, какие задачи в бэклоге приоритетнее?

Есть разные методы приоритезации задач: Story Mapping, Lean Prioritization, модель Кано, MoSCoW и другие. Каждый из них хорош по своему, кто-то может не знать, как они называются, но применять интуитивно. Мы же руководствуемся логикой и здравым смыслом.

Превращение велосипеда в космический лайнер: дорожная карта развития IT-продукта

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

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

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

Бывает и так, что приоритеты меняются. Если мы понимаем, что одна задача будет выполняться весь спринт, это будет неправильно. В таком случае лучше взять задачи меньше, но их будет больше по объему.

Финальные шаги перед запуском спринта

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

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

Команда оценивает задачи, и в соответствии с итоговыми оценками план корректируется и детализируется. Начинается спринт.

Первые спринты и MVP

Первые спринты дают MVP — минимально жизнеспособный продукт. Это та версия продукта, которая позволяет команде собрать максимальное количество сведений о пользователях с наименьшими усилиями.

Почему лучше делать MVP, а не сразу полноценный продукт?

  • Это быстро — отодвинув не критически важный функционал, можно быстрее запустить продукт и занять свою нишу.
  • Не так рискованно — если продукт вопреки прогнозам окажется не таким невостребованным, потери времени и денег будут минимальны.
  • Показательно и гибко — отдавая MVP реальным пользователям, вы получаете обратную связь, с помощью которой можете улучшать и переделывать продукт прямо на ходу. Скрам как раз и предполагает такие изменения
Например, MVP шаурмы — мясо в соусе, завернутое в лаваш. Картошка и салат появятся уже после полученной обратной связи от пользователей, исходя из того, чего им не хватило
Например, MVP шаурмы — мясо в соусе, завернутое в лаваш. Картошка и салат появятся уже после полученной обратной связи от пользователей, исходя из того, чего им не хватило

MVP реально разработать за 2-3 месяца, после этого постепенно наращивать функционал.

Далее покажем как строилась работа по спринтам на примере нашего внутреннего проекта Happens.

Как мы планировали работу по Happens

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

Превращение велосипеда в космический лайнер: дорожная карта развития IT-продукта

Работа по проекту начиналась с планирования. По какому принципу мы определяли, что реализуем в первую очередь?

По принципу логики. Оценили с заказчиком (им выступал наш директор), какие функции должны быть обязательно разработаны перед релизом. Happens — мобильное приложение. Без чего оно не может работать? Без аутентификации (регистрации, авторизации), главного экрана (у нас это карта) и возможности создания контента. Разработка этих функций и вошло в первый спринт.

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

В третий спринт мы включили возможность загружать и просматривать истории, удалять посты/мероприятия/новости. Добавили поиск, лайки, подписки, экраны «Избранное» и «Я пойду», отправку транзакционных писем, возможность редактирования профиля, добавления и удаления друзей, регистрацию через соцсети.

Результатом первых трех спринтов, как мы говорили выше, становится MVP — минимально жизнеспособный продукт. Но у нас получилась его альтернатива — MLP. Это продукт с каким-то преимуществом, за которое потребитель готов выбрать именно его, даже если он не закрывает его потребности полностью.

Почему MLP, а не MVP? Потому что в нашем случае в релиз продукт пошел с бОльшим функционалом, нежели минимальным. И поскольку это внутренний проект, у нас не было задачи выпустить продукт как можно скорее. Во главу поставили проработанность и наполненность функционалом, а не скорость релиза.

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

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

То есть работа по спринтам строится по принципу важности. Сначала самое важное, затем — все остальное.

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

Что такое Roadmap, и как он помогает планировать долгосрочную работу над проектом

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

Эта работа проводится в самом начале. Дорожная карта Happens выглядела так:

Превращение велосипеда в космический лайнер: дорожная карта развития IT-продукта

Вместо заключения

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

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

Если у вас есть задача разработать сайт или мобильное приложение, то напишите в Телеграм, мы это обсудим: https://t.me/sashadzen

Заказать разработку сайта, веб-сервиса или мобильного приложения на нашем сайте: https://vk.cc/cuglQZ

Партнерская программа, где мы платим от 10 000 до 200 000 рублей за контакты тех, кому нужен дизайн или разработка: https://vk.cc/cuglXT

Телеграм-канал Саши Комбарова про управление агентством, проектами, людьми: https://t.me/sasha_kombarov

Телеграм-бот, который бесплатно выдает чек-листы, памятки и регламенты по управлению, маркетингу, аналитике, дизайну и разработке: https://t.me/regulations_pyro_bot

4545
36 комментариев

боже, какая же это шляпа.
вы садитесь и обсуждаете, вырабатываете и тд и тп..
в реальности происходит так: собственник/заказчик от бизнеса/и тд продавил какую то свою идею (при этом это не что то конкретное, а просто какая-то аморфная хуита в голове) .
в департамент спустили указание - сделать. департамент разработки понадувал щеки, мол, так нельзя, ресурсов нет, надо обсуждать.. но ему как обычно заткнули рот и велели "по быстрому" что то наклепать, чтоб показать. бизнес сказал вот вы разработчики и пишите ТЗ, документацию м вообще развивайте идею. нам срочно надо.
проходит месяц - полтора активного ИБД и всё утихает до новой итерации.
скрам и срам..
это во всех конторах и коммерч и гос..

6
Ответить

Возможно, есть компании, в которых бизнес-процессы выстроены именно так как вы сказали. У нас они построены по другому.

1
Ответить

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

Ответить

MVP хорошая штука, а то страшновато в релиз выходить, когда функционала по максимуму сразу сделали)

2
Ответить

Я бы свои сервисы никогда не запустил, если бы не mvp, сейчас это в разы сложнее продукт

2
Ответить

Да, во многих случаях без MVP никуда.

Ответить

Наконец-то я узнал, что такое MVP — другие авторы не затрудняют себя расшифровками.

Картинки в статье отдельно доставляют. Спасибо! )

2
Ответить