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

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

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

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

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

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

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

• Что было сделано на прошлой неделе;

• Что будет сделано на текущей;

• Какие есть сложности или вопросы.

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

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

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

• За счет прозрачности процесса распределять время команды и деньги заказчика получается эффективнее;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Это быстро — отодвинув не критически важный функционал, можно быстрее запустить продукт и занять свою нишу;

• Не так рискованно — если продукт вопреки прогнозам окажется не таким невостребованным, потери времени и денег будут минимальны;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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