Вложили год (ну, почти) в разработку и не запустились. Как извлечь из этого пользу?

Бывают задачи, которые в итоге идут «в стол». Это, можно сказать, нормально, как событие: допустили ошибку в планировании или экономике, затянули со сроками, а может задача вообще оказалась не нужна. Это все неприятная часть рабочей рутины и маркер ошибок менеджмента команды.

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

Расскажу, как наша команда из четырех человек (бекенд и фронтенд инженеры, дизайнер и менеджер) несколько лет назад вложила 8 месяцев в работу над pet-проектом, собрала рабочий MVP, но полноценного запуска не произошло. Да, опыт не самый приятный. Менеджером был я, ну вы понимаете: ошибка, по большей части, моя.

Хотелось вынести какой-то осмысленный вывод, который поможет избежать подобных ошибок в будущем. И раз вынес, делюсь результатами и опытом — кому-то (надеюсь!) может быть полезно.

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

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

Чаще такие продукты заточены под универсальные кейсы, вроде «у тебя есть интернет-магазин, вот тебе виджет, через который можно общаться с пользователями», но если вы делаете более комплексные продукты, где нужна кастомная логика, то все становится сложнее.

И как это обычно бывает, мы решили сделать собственный инструмент для b2c коммуникации. Видели интерфейсы чат-ботов на сайтах? Вот и мы задумали сделать (собственно, и сделали) что-то похожее. Отличие от схожих решений: возможность объединения тредов с одним пользователем через разные каналы коммуникации (от чата на сайте и мессенджеров, до социальных сетей и телефонии) в один диалог.

Сформулировали ключевые требования к финальному продукту:

• Простота установки: если пользователю не нужно ничего, кроме базового функционала в виде чат-интерфейса для веба, то работать все должно достаточно просто, чтобы справился младший менеджер;
• Возможность подключения разных каналов коммуникации: социальные сети, мессенджеры, телефония, почта. Не в первой итерации, но это было важной целью, чтобы замкнуть всю коммуникацию на себе;
• *Объединение тредов от одного пользователя и единая история коммуникации с ним. Пункт со звездочкой, т. к. не всегда технически возможно, но в большей части кейсов — реализуемо.

Далее — стандартный старт любого проекта:

• Сформулировали план релизов, привязав их к функциональным требованиям;
• Декомпозировали продуктовые задачи на бекенд и клиент-сайд, провели оценку. Учитывая доступное время каждого участника команды — получилось около 6,5-7 месяцев;
• Дополнили роадмэп техническими подробностями, спроецировали на календарь;
• Договорились о базовой гигиене: выбрали простой таск-трекер, который поможет не терять задачи, но и не усложнять жизнь команды, проговорили процесс код-ревью, описали процесс тестирования.

Из других организационных аспектов: у каждого блока работы появился ответственный. Выбрали слот для еженедельных звонков.

Ещё оставался выбор — пойти альтернативным путем и уже на этом этапе запустить курсы успешных продакт-менеджеров или, как минимум, завести канал в Телеграме. Сделано это, конечно, не было, что, возможно, стало первой крупной ошибкой…

Далее — стандартный цикл разработки. Не без ошибок, но мы укладывались в роадмэп и делали релизы по плану.

Спустя 6 месяцев мы были близки к запуску. И по плану почти укладываемся, как классно! Но что-то моральный дух команды к этому моменту начал снижаться, слишком много времени прошло с начала работы над проектом. И начали выявляться проблемы на бекенде. Не камень в сторону разработчика, разумеется, мы все пропустили несколько блоков на этапе проектирования, но с этим нужно было разобраться.

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

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

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

«Парни, все круто, но мне бы еще вот такую фичу, а без нее чёт не». И так — несколько раз. Мы подумали, оценили доработки еще в пару месяцев, вздохнули и стало понятно, что продолжения не будет. Команда устала, горизонт релиза отодвинулся и перестал проглядываться, как мотивирующая близкая цель. Все посыпалось.

В чем, на мой взгляд, заключались основные ошибки:

• Усложнили продукт на старте: хотели выпустить стабильную версию с относительно широким функционалом, когда нужно было срезать углы (например, отказаться от ролевой системы);
• Потеряли фокус на главном: элементарная установка и заложенная архитектура под гибкое API. А через лендинг собирать почты пользователей, которым бы кликнул наш продукт и план развития;
• Слишком положились на знакомых: нужно было намного больше вкладываться в биздев (даже писать об этом неловко, ох);
• Затянули с разработкой: вовремя не осознали, как сильно связан моральный дух команды и сроки. В какой-то момент мотивация настолько упала, что команда оказалась уже не готова продолжать работать над проектом.

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

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

Ну и раз такое дело! Если хотите протестировать наше решение бесплатно, без СМС и регистрации — дайте знать. Оно готово, только сервера поднять, а нам — приятно.