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

Ограничьте контур MVP только ключевой ценностью

Потратьте время, но поймите лучше основной сегмент ЦА, того кто будет первым пользователем:

1. Запускайте продукт для лояльных пользователей, клиентов или сотрудников. Нет смысла запускать на всех потенциальных пользователей, выберете самую лояльную группу или важный сегмент
2. Проверьте что у них есть настоящая проблема и они это осознают. Как это сделать:
   — они активно ищут решение
   — они как-то сами пытаются решать её
   — у них есть возможность платить за решение
3. Зафиксируйте контур продукта: проставьте приоритеты сценарии своего ключевого сегмента ЦА
4. Не обсуждайте функциональные возможности продукта. Говорите сначала про задачи, ключевые действия и ценности, а только потом трансформируйте это в решение. Грубо говоря, пользователю не нужен личный кабинет, ему нужно список избранного видеть.

Отделите срок запуска продукта от срока разработки продукта

1. Если продукт сложный и первые версии MVP — это кожа и кости, не запускайте его на клиента
2. Следуйте стратегии, презентуйте версии продукта выкладывая ценностные фичи частями на ограниченную аудиторию. Например, в таком порядке:
   1. Проектная команда и бизнес-заказчик\клиент\инвестор
   2. Ключевой сегмент из прошлого совета
   3. Рынок

Синхронизируйте бизнес и разработку

1. Никогда не планируйте маркетинговые активности: рекламу, посевы, блогеров и конференции впритык к окончанию разработки, которое уже вот-вот, буквально через неделю.
2. Если бизнес и разработка существовали после первого релиза продукта, они должны знать друг про друга «до».

Перейдите к коротким интеграциям разработки

Почему это важно и хорошо работает:

• Сможете управлять приоритетами (а ими придется управлять)
• Не потратите драгоценные месяцы на аналитику
• Не будете придумывать реализацию того, что изменится за следующие 3-4 месяца
• Это самый простой способ уменьшить вероятность «обосраться» в два раза (где-то до 50%)

Избавьтесь от лишнего

Сложный функционал портит продукты, откажитесь на старте от всего, что не укладывается в ключевой сценарий основного сегмента:

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

Начинайте с узких мест

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

Вместо вывода

Не забывайте: пока мы что-то делаем на дев-серверах, пользователи и бизнес ждут перемен!

P.S.: Кстати, я иногда выступаю на конференциях.

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

Делюсь опытом на темы:

• заказная разработка
• разработка и развитие продуктов
• управление веб-проектами
• отношения с клиентами в сервисном бизнесе

С отдельным удовольствием приеду в Ульяновск или Самару.

Прошедшие

1. MVP как стратегия, Мастерская маркетинга Андва, 2023
2. MVP как стратегия, IT Summer Camp, 2022
3. Ничего нового про коммуникацию, Прожектор, 2019
4. Экономика проектов в заказной разработке, Прожектор, 2018
5. Давайте поговорим о проектах на примере сайта «АСПЭК-Авто», What the FAQ is WEB-design, 2014
6. Ирония судьбы или удаленная работа, IzhDevCom, 2012

Вопросы и предложения

• Telegram: loshenov
• Эл. почта: ivan@loshenov.ru

Со временем любой глаз замыливается, подход в принятии решений встаёт на рельсы и становится рафинированным.

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

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

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

Сообщение от партнера, который узнал про ситуацию на проекте

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

Обычно собственники и руководители компаний понимают, чего хотят от инвестиции в ИТ-проект. Они видят в нем ценность и хотят, чтобы вложения в него окупились. С ними легко говорить на языке бизнеса, они формулируют конкретные задачи — например, увеличить объем продаж в X раз.

Иногда заказчику трудно сразу обозначить свои цели и четко сформулировать их. Тогда мы помогаем ему — задаем наводящие вопросы.

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

В таких случаях мы стараемся сэкономить ресурсы заказчика и время нашей команды: просим контакты собственников бизнеса и выясняем истинные цели проекта. Этот принцип мы выработали в процессе коммуникации с компанией «Витязь-Аэро».

Почему важна роль бизнес-заказчика в ИТ-проекте

«Витязь-Аэро» — это авиакомпания, которая выполняет пассажирские рейсы на вертолетах в отдаленные населенные пункты Камчатки. У них два ИТ-продукта: сайт и автоматизированная информационная система (АИС) для регистрации пассажиров, багажа, грузов. Первый — для клиентов, второй — для внутреннего пользования сотрудниками.

В компании АИС ввели в 2017 году. Изначально ее создавал местный разработчик, сотрудники которого построили систему за полгода и далее осуществляли ее техподдержку. Позже количество человек в его команде сократилось, и работа по продукту замедлилась. АИС для аэропорта перестала стабильно работать и быстро адаптироваться под новые запросы пользователей.

Кроме того, в системе изначально было много проблем в функционале: например, плохое изначальное проектирование и невыстроенная система тестирования и модификации кода. Со временем АИС перестала отвечать растущим потребностям компании.

В конце 2019 года «Витязь-Аэро» захотели увеличить темпы разработки. Дополнительно нужно было развить функционал системы, ускорить трек поддержки и увеличить скорость реакции для исправления критичных дефектов. Чтобы закрыть эти потребности, в «Витязь-Аэро» решили сменить подрядчика и обратились к нам.

Проблемы в коммуникации с клиентом

Не надо так

Коммуникация с клиентом складывалась непросто: на разницу в местонахождении и часовом поясе (+8 часов) накладывались и другие сложности. Например, с начала сотрудничества у нас не было прямого контакта с бизнес-заказчиками — собственниками, которые хорошо представляют цели разработки и желаемый результат. Мы связывались с ними через руководителя проекта. Это был сотрудник компании, который не мог знать столько же, сколько бизнес-заказчики, несмотря на проактивную позицию в работе. Из-за этого в нашей коммуникации появилось несколько проблем:

* Менялись приоритеты, о чем мы поздно узнавали. Например, нам приходила задача, которую надо было выполнить срочно. Мы тратили на нее время, а по готовности оказывалось, что она уже не нужна.
* Возникали недопонимания при постановке задач. Оказалось, что обсуждать задачу без прямого контакта с бизнес-заказчиком — сложно. Это было похоже на игру в «глухие телефоны»: собственник давал нам задание через руководителя проекта, а мы получали его искаженным или неполным. При этом не было возможности быстро уточнить, что значительно увеличивало сроки исполнения. В итоге при релизе демоверсии получалось, что с продуктом все не так — результат не совпадал с ожиданием бизнес-заказчика.

***

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

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

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

Момент оказался поворотным — мы решили организовать переговоры с непосредственными руководителями «Витязь-Аэро».

Переговоры и изменения в порядке работы

Из-за возникшей коллизии мы встретились с бизнес-заказчиками. В ходе переговоров мы:

1. Воссоздали моменты нашей коммуникации с самого начала, чтобы проверить, кто какой информацией владеет.
2. Обозначили проекты, которые мы ведем: поддержка и развитие АИС, поддержка существующего сайта «Витязь-Аэро» и разработка нового.
3. Познакомили с нашей командой и рассказали об объеме задач у каждого сотрудника — чтобы клиент понимал, что в проекты вовлечено много человек.
4. Презентовали результаты работы за последние 6 месяцев.
5. Рассказали, на каких стадиях находятся поставленные задачи.
6. Наметили будущие приоритеты и проблемы, из-за которых могут сдвинуться сроки.

Колесо проектного взаимопонимания

Также мы проанализировали коммуникацию с «Витязь-Аэро» и предложили варианты, как предотвратить проблемы в будущем. Самым важным было подключить бизнес-заказчика к ключевым процессам разработки. Договорились о следующем:

• Внедрили ежемесячные демо. Подключали руководителей и заинтересованных участников со стороны заказчика, чтобы совместно продемонстрировать и принять новый функционал в дев-окружении. Сбор обратной связи здесь и сейчас упрощал коммуникацию с двух сторон и позволил учитывать ожидания заказчика. Также это погрузило руководителей в процесс разработки и дало понимание, почему готовы или нет те или иные инструменты;
• Договорились о стратегических совещаниях раз в 3—6 месяцев. Это помогло увидеть горизонт работы и определить приоритетные задачи в следующие 6—12 месяцев. Выделили несколько направлений: развитие и поддержка продукта, а также фиксация проблем в автоматизированной системе.

Выстроенная коммуникация позволила сохранить сотрудничество и быстрее выполнять задачи клиента. Объем работ многократно вырос, а time-to-market, время за которое идеи реализовывались и становились доступными для пользователей, сократилось в 2 раза.

Где участие бизнес-заказчика обязательно

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

Это позволило синхронизировать бизнес и разработку

Теперь мы обязательно привлекаем к прямому обсуждению бизнес-заказчиков. Особенно на следующих итерациях проекта:

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

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

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

Планёрка в Nutnet

Без розовых очков

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

Часть клиентов приходит к нам с призрачной идеей и горящими глазами. Они верят, что проект «полетит» и оправдывают космические расходы времени, денег и энергии. В основном, это не прорывные идеи: ещё один profi.ru со своей специализацией или мобильное приложение с геолокацией — чат для тех, «кто рядом». Смотрю на это, как на еще один запрос из тысячи.

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

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

«Бэк-офис — это 70% успеха»

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

Все успешные и провальные проекты зависят не от сайта, а от команды. Красивый, современный сайт — это 30% успеха, остальные 70% зависят от работы бэк-офиса. Это владелец, операционные-менеджеры, менеджеры по работе с клиентами — люди, которые обеспечивают внутренние процессы. Мы можем разработать очень удобный сервис, но если менеджер вовремя не ответит или нагрубит клиенту, все напрасно.

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

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

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

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

MVP

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

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

Условная разработка стоит 2 миллиона рублей. А запустить страницу на тильде, рекламу на узкий сегмент и протестировать спрос — 100 тыс рублей. Нужно собирать информацию от потенциальных клиентов, а не от вымышленных персонажей или друзей. Позвоните потенциальным клиентам, поговорите с представителями рынка — развейте фантазии до старта.

Хороший пример — Фиксби. Мы работали в партнерстве с MVPLab. Ребята проработали идею, мы занялись технической стороной. Первую версию запустили за месяц и занялись итерационным развитием: доработали интеграции, систему управления, протестировали разные варианты страницы услуг. Сработали на отлично.

Поддержка и развитие

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

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

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

Контроль окружения проекта

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

Например, вы заказали разработку у фрилансера. Через 3 месяца он перестал выходить на связь, а доступов не оставил. Наработки, время, деньги и надежды на скорый запуск пропали. Весь бизнес под угрозой, если отсутствует контроль активов проекта.

Чтобы такого не произошло, вся техническая и юридическая часть проекта должна принадлежать клиенту и храниться на стороне клиента. Так легче контролировать подрядчиков и обеспечивать безопасность.

Выводы

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