Разбираем 4 принципа гибкого подхода к бизнесу на реальных примерах ИТ-компании

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

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

Skipp — сервис для разработки ИТ-продуктов. К нам обращаются клиенты с идеями или ТЗ, а мы подбираем команды исполнителей — проверенные студии дизайна или разработки.

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

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

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

У строительства большой системы много рисков. Во-первых, у основателя ещё нет оснований полагать, что она окупится: если вложить значительные средства сразу, их легко потерять. Во-вторых, на большую систему может уйти много времени. Это опасно: рынок может поменяться, и продукт не будет ему соответствовать; предприниматель не будет получать обратной связи от клиентов; компания не начнёт зарабатывать.

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

Вместо того чтобы сразу запускать полномасштабную разработку, выберите самую важную функцию для пользователя и выпустите её. Чем быстрее вы сможете запустить первую версию, тем лучше. Часто для этого даже не нужны ресурсы разработки: можно найти no-code решение. Соберите обратную связь и запланируйте следующий шаг.

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

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

Но первая версия — не значит плохая. Даже с лендингом и ручным подходом мы смогли успешно закрыть несколько проектов. В некоторых проектах экономика была на грани, но чаще мы выходили в небольшой плюс: в среднем с проекта зарабатывали 15%. Это было достаточным подтверждением жизнеспособности модели.

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

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

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

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

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

Важно, чтобы в гипотезе было конкретное предположение: как действие повлияет на продукт или компанию. Гипотеза состоит из двух частей: Если [сделать что-то], то [мы получим такое-то изменение в продукте или процессах].

Например:

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

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

Например, вот такая гипотеза показала положительный результат:

Если мы возьмём на себя предпроектную подготовку и подробно опишем технические требования, исполнители согласятся работать за фиксированную стоимость, и мы сможем повысить маржинальность до 30%.

Раньше мы сразу передавали командам ТЗ от клиентов, часто оно было несовершенным и оставляло много вопросов. Поэтому разработчики соглашались только на почасовую оплату. Когда мы сами начали проводить подготовку, помогали заказчику составить задание и готовили прототипы, исполнителям стало легче точно оценить проект на старте. Многие команды согласились работать по фиксированной ставке. Гипотеза помогла нам повысить маржинальность проектов с 15–20% до 30–35%.

Вот две гипотезы, которые не оправдались:

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

Гипотеза не сработала, потому что большинство клиентов сразу запрашивали подробную смету.

Если отдадим менеджмент на аутсорс, и не будем подключать продакта Skipp на каждый заказ, повысим маржинальность.

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

Движение через гипотезы — основа гибкости. Но как проверить их результативность?

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

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

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

Метрики помогают принимать решения. Например:

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

Например, можно разложить выручку на средний чек и количество клиентов. Количество клиентов — на конверсию и трафик на сайте. Получается, выручка зависит как минимум от трёх других показателей, каждым из которых бизнес может управлять. Если смотреть на одну выручку, то можно не заметить, что средний чек, например, растёт, а конверсия падает. И не понять, что отдел продаж работает хорошо, а маркетинг — хуже.

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

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

Один из показателей, которые для нас важны, — конверсия во второй заказ. Если проект прошёл хорошо, то выше вероятность, что клиент придёт к нам снова. В итоге мы заплатим за привлечение один раз, а заработаем несколько — вырастет LTV при неизменном CAC.

Ещё мы обращали внимание на количество полностью успешных проектов, то есть таких, в которых не возникало особых проблем с качеством и сроком. В самом начале их было около 60%. Мы видели, что проекты, в которых я участвую в качестве менеджера, чаще заканчиваются успехом, а когда менеджмент оставался на стороне исполнителя, сложности появлялись чаще.

Так мы решили ввести менеджера Skipp на все проекты. Он погружается в задачу клиента и полностью ведёт её, стыкует бизнес с разработкой, помогает принимать решения. После появления менеджеров по продукту процент успешно выполненных проектов вырос до 90% — из 50 проектов, которые мы сделали за последнее время, проблемы появились только в пяти.

Другая метрика, над которой мы работали, — стоимость привлечения клиента. Мы снова выдвинули несколько гипотез: сменили позиционирование, сделали конкретные нишевые офферы, расширили список каналов, в которых продвигаемся. Раньше общие расходы на привлечение клиента, включая оплату сейлзу, выходили в 150 000₽, сейчас — 85 000₽.

Итак, мы запустили первую версию, проверили серию гипотез, нащупали необходимые метрики, проект встал на стабильные рельсы. Как сохранять гибкость дальше?

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

На этом этапе гибкость переходит на более низкий уровень. Команда ищет способы оптимизировать работу, повысить эффективность, заработать больше. То есть, начинает искать узкие места в системе — бутылочные горлышки.

Например:

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

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

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

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

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

Решение. Мы внедрили стандарты компетенций для каждой роли. Например, составили списки хард и софт скиллов, которые должны быть у менеджеров по продукту в Skipp. Чтобы проверить, что кандидат владеет навыками, стандартизировали вопросы и задачи для собеседовений.

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

Гибкий подход помогает предпринимателю пройти путь от идеи до прибыльного бизнеса. Ключевые принципы подхода:

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

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

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