Как запустить стартап, не утонув в доработках и не потеряв бюджет? Рассказываем на примере биржи локальной работы Needhand.ru — от абстрактной идеи до готового сервиса с картой, откликами и чатом.
Часто заказчики приходят с мыслью, что идея уже готова, осталось только заплатить программистам — и все взлетит. Но практика показывает, что большинство проблем в проектах возникает, когда исполнители стараются быстрее приступить к задаче, не разобравшись в ней. Из-за этого возникают несостыковки и постоянные переделки, а заказчик получает не то, что хотел.
Мы практикуем другой подход. Кейс needhand.ru — хорошая иллюстрация, как мы работаем с клиентами. Мы начинаем с десятков вопросов, обсуждения логики работы сервиса и отсечения лишнего. А затем предлагаем подходящие решения, которые не только выполняют задачу клиента, но и часто экономят ему время и бюджет.
Needhand.ru — это биржа локальной работы. Сервис позволяет найти работу поблизости, например, погрузку, ремонт или клининг, или наоборот — подобрать помощника для своих бытовых задач. Основная «фишка» сервиса — это привязка к геолокации, которая позволяет исключить лишние объявления и подбирать исполнителей рядом, а не из другого города. 
Задача
К нам обратился заказчик, у которого была идея создать новый сервис. Он понимал, что хочет видеть карту, заявки, отклики и отзывы, но не представлял, с чего начать и как это все будет связано между собой. Это классическая ситуация предпринимателя с видением, но без технического лида. Многие исполнители здесь делают ошибку, сразу хватаясь за код.
Наша команда начала с детального разбора идей заказчика, фиксации всех деталей и переноса их в черновики-макеты с описанием каждой кнопки. Мы задавали очень много вопросов и уточняли, правильно ли мы понимаем идею клиента. Обычно в ходе этого диалога находится много несостыковок и белых пятен.
Такой подход позволяет сократить сроки разработки, а значит, сэкономить бюджет заказчику. Иногда в разы. Исправить ошибку в техническом задании займет несколько минут, а переписать код и переделать логику работы — часы работы.
Решение
Этап обсуждения (аналитики) часто недооценивают и пытаются пропустить. Но именно он позволяет не уйти в бесконечную разработку и главное — не потратить бюджет заказчика на вещи, которые никто не будет использовать. В ходе обсуждения выяснилось, что заказчику важно как можно быстрее запустить сервис и увидеть, есть ли на него спрос.
Опираясь на наш опыт, мы упростили или убрали функции, которые не влияют на первую проверку гипотезы, указали на неочевидные места, способные «съесть» много времени, и предложили замену трудоемким функциям на более простые без потери ценности для пользователя. В итоге получилось детальное техническое задание с понятными этапами и приоритетами, и абстрактная идея клиента превратилась в дорожную карту с датами и бюджетом.
В процессе составления технического задания возникает много важных вопросов и уточнений
Мы реализовали полноценную гибкую систему, которую легко доработать по итогам тестов на реальных пользователях.
В итоговой версии были реализованы:
- система пользователей с привязкой к их локации;
- создание заявок на работу;
- вывод заявок на карте;
- механизм откликов и выбора исполнителя;
- профили пользователей с информацией о предлагаемых услугах и отзывами;
- чат для обсуждения деталей;
- система контрактов для фиксации договоренностей;
- административная часть для модерации контента и другое.
Чат внутри сервиса для обсуждения деталей
Профили пользователей
Объявления пользователя об услугах
Отклики на объявления
Все работы выполнялись поэтапно с еженедельными демонстрациями и отчетами, поэтому клиент видел прогресс каждый понедельник и мог вовремя сказать, что нужно упростить или, наоборот, добавить.
Поскольку техническое задание было выверено до мельчайших деталей, разработка прошла без сюрпризов
После релиза мы не бросили проект. Продолжили поддерживать сервис и добавлять новые функции уже по запросам реальных пользователей. К сожалению, несмотря на то, что с технической стороны нареканий не было, этого оказалось недостаточно для стартапа и раскрутки сервиса. И здесь важно сказать: такое развитие событий — нормальная история для большинства стартапов. Именно поэтому в похожих случаях мы рекомендуем запускать сначала минимально жизнеспособный продукт (MVP). Если бы заказчик сразу вложил огромный бюджет в полноценную систему, не проверив гипотезу на реальных пользователях, потери были бы в разы выше. А так — проект честно прожил свою жизнь, дал свои уроки, и его закрытие стало естественным итогом проверки бизнес-идеи.
Если вы сейчас находитесь с идеей, но без технической команды не знаете с чего начать и не хотите переплачивать — напишите нам. Первичный разбор идеи и технического задания мы делаем в формате бесплатной консультации.
ВКОНТАКТЕ
TELEGRAM