Первый блин комом - как мы попытались провести CustDev через проектное управление с отсутствием бэкграунда

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

Предлагаемое решение - кулинарное мобильное приложение с составлением меню на неделю и автоматическим списком покупок.

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

CustDev было решено проводить в рамках отдельного мини-проекта по Scrum’у, о котором мы так много слышали еще в университете, но ни разу не пользовались. По рекомендации знакомого решили опробовать управление проектной организацией по методу "Пульса".

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

А вот устав проекта оказался крайне полезен - мы чётко сформулировали основные границы проекта и возможные ограничения. Создав канву по нашему проекту, осознали, что из ресурсов имеем лишь почти неограниченный запас по времени, мы всё-таки еще студенты, ручку и льготный проездной.

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

На выполнение всех задач по нашим расчетам в таблице Excel должно было уйти от 15 дней (оптимистический) до 28 дней (пессимистический прогноз). Решили выделить резерв времени, чтобы обезопасить проект от неопределённости уложиться в сроки.

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

Так как основной функционал потенциального приложения - список продуктов и уменьшения спонтанных покупок в магазинах, мы решили пойти в ближайший от дома каждого участника Окей/Ашан/Ленту и начали опрашивать людей в “полях”.

Сначала мы составили список из 8 вопросов, чтобы наши респонденты не “уставали” к концу опроса. В основном использовали открытые вопросы для выявления пользовательского опыта. Важно было понять, существует ли реально проблема в приготовлении блюд и покупке ингредиентов, а если существует, тот как они сейчас справляются с этим. Список вопросов:

Вопросы типа “Как вы в большинстве случаев принимаете решение о том, что приготовить на завтрак/обед/ужин? “ и “Опишите, как проходит ваша обычная покупка продуктов питания?” позволил нам определить обычное поведение потенциальных пользователей. “Стараетесь ли вы улучшить процесс покупки продуктов питания для себя?” – как респонденты справляются с данными задачами сейчас. Остальные вопросы были направлены на выявления “ареала” обитания ЦА и выявление дополнительных проблем пользователя (возможно добавить в наш список “To Do”).

На первый взгляд наш проект не предполагал наличия каких-то подводных камней, однако мы определили две явные угрозы, одна из которых наступила. Люди, помимо обычного нежелания проходить чьи-либо опросы, в условиях пандемии попросту не хотели с нами общаться из-за несоблюдения социальной дистанции, а проводить интервью на расстоянии пары метров от респондентов было нереально. После получения около 50 личных отказов, мы решили перейти к плану “Б” и проводить дальнейшее анкетирование онлайн через гугл формы среди знакомых и друзей знакомых, подходящих под критерии ЦА.

По результатам анкетирования 190 людей, было выявлено следующее:

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

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

Канвас или устав проекта – простой и крайне полезный инструмент, который помог нам разложить по полочкам всю картину проекта а конкретно - что мы делаем, зачем мы это делаем, что считать за успех.

План управления проектом – как мы и писали ранее, план управления нам не понадобился, но потратили мы на него полдня. Возможно, это хороший инструмент для более масштабных проектов и крупных команд, что не соответствует нашему конкретному кейсу. Мы согласны, что "правила игры" задают конкретику и последовательность взаимодействий, но они не должны быть костылём, который используют потому что "так надо".

Обратное планирование – оказался действенным методом составления списка задач. Мы шли “от обратного”, от конечной цели до самого первого шага, который нам необходимо сделать. Декомпозируя шаг за шагом, мы понимали, какой цели нам надо достичь, чтобы решить задачу X или преодолеть препятствие Z. Таким образом, мы не потеряли ни одной задачи при планировании и уменьшили неопределенность. Также это помогло составить наш бэклог, чтобы в дальнейшем распределить задачи по спринтам.

Спринты – стоит отметить, что мы заранее распределили все задачи по спринтам, за счёт чего у нас отсутствовала фаза планирования будущего спринта. Мы можем назвать это ошибкой, так как несмотря на небольшой размер команды и перечень задач, мы не всегда укладывались в планируемые сроки. Получилось, что быстрые задачи были растянуты на целый спринт, а на самые трудоемкие задачи иногда не хватало времени. Всё это подтверждалось в диаграмме сгорания, когда мы резко вышли из буфера на 3 спринте.

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

Таким образом, опыт использования перечисленных выше инструментов позволил нам определить очерёдность выполнения задач правильно расставить приоритеты, а главное - цели всего проекта.

Одно радует – мы выяснили “будущее” нашего приложения до выпуска его на рынок, что помогло нам сберечь ресурсы для нового исследования. Если бы провели CustDev на первом этапе, а не после создания прототипа, мы бы сэкономили больше средств.