«Знал бы прикуп». Как непредвиденные факторы меняют проекты

Логотип компании
«Знал бы прикуп». Как непредвиденные факторы меняют проекты
Vectorium/shutterstock.com
Каждый проект — это не просто идея или концепция, а целый комплекс факторов, которые необходимо учитывать на всех этапах его реализации. Однако не всегда все получается так, как мы того хотим.
Антон Фокин, CEO QTIM, Co-founder Wombot, расскажет о трех проектах, в которых все пошло не по плану. Поведаем о причинах произошедшего и на каком этапе развития все сейчас и поделимся рекомендациями, как минимизировать риски и решать проблемы, похожие на те, с которыми столкнулся QTIM.

Кейс № 1

Wombot — это сервис-конструктор для создания Telegram-ботов, предназначенный для автоматизации онлайн-продаж и взаимодействия с клиентами. Он помогает пользователям продвигать и монетизировать онлайн-контент (обучающие курсы, подкасты, видео и изображения).

Изначально со всеми этими функциями стремились занять свое место в нише. При этом не учли несколько важных моментов:

  • Бизнес-план был недоработан, мы не понимали сроков окупаемости и не знали, как можем заработать на проекте.
  • Конкурентов тоже недооценили: они оказались сильнее нас. Поэтому стали искать уникальное торговое предложение (УТП), чтобы выделиться на их фоне.

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

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

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

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

Совсем недавно Wombot получил новое применение — запущен чат-бот, который помогает Фонду Хабенского. Для Qtim это очень значимое событие, а значит, все испытания были точно не зря. Верим, что это новый виток развития сервиса.

«Знал бы прикуп». Как непредвиденные факторы меняют проекты. Рис. 1

Много опыта было взято из этого проекта. Основной инсайт — не «перепрыгивайте» этап тщательной проработки бизнес-плана и понимания всех рисков, иначе можно потратить время и ресурсы впустую. И проводите custdev, чтобы собрать мнение других людей, а не опирайтесь только на собственное.

Кейс № 2

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

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

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

Кейс № 3

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

Ситуация усугубилась, когда спустя месяц изменились требования к верстке. Нужно было адаптировать сайт под «резиновый» дизайн, чтобы пользователи могли комфортно делать заказы на больших экранах, таких как 8K-телевизоры. Это требование не было озвучено изначально, что привело к необходимости переверстать значительную часть работы.

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

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

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

«Знал бы прикуп». Как непредвиденные факторы меняют проекты. Рис. 2

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

Чему мы научились

На примере наших собственных проектов мы выяснили, что нужно:

  1. Тщательно прорабатывать бизнес-план и custdev: это включает детальный анализ рынка, определение целевой аудитории и конкурентов, а также четкое формулирование целей и задач проекта. Выделяйте ключевые метрики успеха и риски, чтобы заранее иметь представление о возможных проблемах. Перед тем как приступать к разработке, стоит пообщаться с людьми, которые являются потенциальными пользователями, а не делать исключительно так, как видите сервис вы.
  2. Разрабатывать маркетинговую стратегию с самого начала: уделяйте время и ресурсы продвижению продукта, это не менее важно, чем его разработка. Работайте над формированием бренда и планами по привлечению клиентов еще до начала основных процессов.
  3. Создавать план B для каждого проекта. Наличие запасного плана позволяет быстро реагировать на изменения и непредвиденные обстоятельства. Это может включать привлечение дополнительных специалистов или перераспределение ресурсов в случае задержек или изменений в финансировании.

Что касается заказной разработки, то следует учитывать:

  1. Четкое понимание требований заказчика: поняли, что необходимо тщательно фиксировать все требования и ожидания клиента на начальном этапе. Это позволяет избежать недопонимания и корректировок в процессе разработки.
  2. Гибкость в подходах и готовность к изменениям: заказчики могут менять свои требования в процессе работы, поэтому важно быть готовыми адаптироваться и находить оптимальные решения. Наличие сильной и сплоченной команды помогает нам более уверенно справляться с такими ситуациями.

Опубликовано 19.12.2024

Похожие статьи