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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если у вас есть задача разработать сайт или мобильное приложение, то напишите в Телеграм, мы это обсудим: 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