“Быстрее проверяйте гипотезы” – гласят заголовки статей, книг и видео. В веб-разработке способ создания продуктов через MVP прижился достаточно прочно. И не случайно, ведь веб-продукты очень гибкие по своей натуре, что позволяет их быстро трансформировать под потребности рынка. Отличный способ защитить себя от лишних трудозатрат, потери времени и денег – это создать минимальную ценность продукта и попробовать его продать. Ведь лучше понять как можно раньше, что делаешь не то, и изменить план действий, чем получить никому не нужный продукт спустя годы разработки. 

Во всех пособиях сказано: 

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

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

MVP готов, что дальше?

После релиза MVP вы все еще не знаете, “выстрелит” ваш сервис или нет. Поэтому не понимаете, стоит ли привлекать дополнительные силы. ”Команда” остается прежней  —  половина разработчика.

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

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

Непредвиденная ситуация и сложный выбор

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

Вы приходите к разработчику, он предлагает вам руками обнулить баланс клиента в базе на проде. Устроит ли вас такое решение? Надеюсь, нет. Вы просите разработчика сделать форму обнуления баланса. Что он вам ответит? “У меня сейчас по плану фича X для клиента. Я могу её отложить”. В этот момент в вашей системе приоритизации возникнет деление “внутренние” и “внешние” фичи. А еще становится понятно, что кому-то придется подождать: либо вам, либо клиентам.

Обсуждая логику работы функции обнуления баланса, разработчик говорит, что “может” сделать так, чтобы она работала как простое обнуление руками. По-другому сделать “нельзя”. А вам нужно не просто обнулять, вам нужно сделать историческую запись об обнулении, отображать её юзеру.

В кавычках эти ключевые слова не просто так: “можно”  —  это можно сделать просто и быстро, “нельзя”  —  это возможно сделать, но делать долго и нецелесообразно с точки зрения разработчика. В этом месте выясняется (или вспоминается), что ваш биллинг  —  это не бухгалтерия с двойной записью и логированием, а простое поле user_balance в таблице users базы данных. Разработчик считает переработку биллинга нецелесообразной: во-первых, это займет много времени, во-вторых, он точно не знает, как сделать биллинг правильно, в-третьих страшно менять базовые сущности в рабочей системе  —  ведь у вас уже 20 платящих клиентов!

В этом месте у вас родился тип задач с именем “техдолг”. Эти задачи тоже должны быть в бэклоге и участвовать в приоритезации.

Теперь у вас выбор: сделать жесткое обнуление баланса руками в базе и потратить время на разработку фич для клиентов, либо начать переделывать биллинг и делать форму обнуления баланса. Сервис молодой и критически важно, чтобы клиенты остались с вами, поэтому вы, конечно, предпочтете делать фичи для клиентов, чем разбираться с техдолгом. Так значение баланса клиента будет обнулено руками в базе, и проблема будет забыта до следующего случая. Примечательно то, что на текущий момент причина: “нам критически важно сохранить нашу небольшую базу клиентов и привлечь новых таких же”, а через год причина примет другую формулировку: “у нас десять тысяч клиентов и мы должны срочно сделать фичу, они все ждут, фича еще позволит и заработать больше” или такую: “у нас десять тысяч клиентов, мы не трогаем биллинг, чтобы ВСЁ не сломалось!”.

Расширение команды, которое не помогло

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

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

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

Скорость разработки увеличилась совсем незначительно, но вы надеетесь, что джуниор раскачается.

Со временем вы начинаете замечать, что ваш сервис стал тормозить. Клиенты тоже это заметили и уже написали вам в личку (вы ведь первых клиентов знаете хорошо, верно?). Первая гипотеза у вас, что это косяки джуниора. Но ваш старший разработчик называет реальную причину  —  фичи пилят “на коленке по-быстрому!”. Чтобы они работали быстрее, надо заниматься оптимизацией, что увеличивает время разработки в два раза. К тому же, ваша накрученная аналитика увеличила объем данных, замедлила работу сервиса. В этом месте закрадывается мысль, что у вас и с базой данных не все в порядке.

Неожиданный доход

Однажды, изучая метрики, вы падаете со стула: обычно каждый день ваш сервис имеет доход 100$, но сегодня был 10 000$!

Очень быстро выясняется, что за день было зарегистрировано тысяча аккаунтов, в каждом аккаунте было множество попыток оплаты с разными реквизитами. Вы попали под скам-атаку, об вас проверяли тысячи реквизитов платежных карт. Часть попыток были успешными, в итоге фейковые аккаунты пополнили баланс на 10 000$.

Становится ясно, что безопасность продукта на нуле. Логично, ведь в процессе проектирования вы не уделяли этим вопросам никакого внимания. 

Осознание большой проблемы

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

Вы встряли, и ваш сервис находится под угрозой. У вас есть следующие пути развития:

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

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

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

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

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

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

TL;DR:

Делая MVP, вы значительно обрезаете объем продукта, сильно упрощаете все его аспекты.

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

Чему вам придется уделить много внимания после релиза MVP и подтверждения гипотезы:

• Структура БД

• Архитектура проекта (речь не только о кодовой базе, но и о серверной части)

• Вопросы безопасности

• Оптимизации

• Веб — аналитика

• Тесты

• Документация