Разработка сервиса. Как избежать провала

Денис Гордиенко, генеральный директор Bright Mobile, о том, как избежать провала при разработке сервиса с интеграцией.

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

Только в прошлом году ко мне обратилось шесть человек, каждый из которых наступил на одни и те же грабли, что, в итоге, выливалось в достаточно серьёзные траты – от 400 тысяч до полутора миллионов. Деньги существенные, терять их не хочется, а ошибку, пусть она и не лежит на поверхности, избежать можно, и сейчас я расскажу, как.

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

Как такой проект делают обычно:

Первое – это составление ТЗ. Это понятно, ведь нужно ясно сформулировать все требования, от чего-то в первой версии придётся отказаться, что-то добавить позже – короче говоря, разобраться, вникнуть в идею и прописать задание для программистов так, чтобы они его поняли.

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

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

Четвёртый этап – вёрстка. Дизайн превращается в кликабельные html-страницы

Пятый – программирование, непосредственная реализация сайта/приложения (наш пример единого окна формально был веб-решением со сложной архитектурой), а также программирование внутренней кухни

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

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

Вот что рассказали мне те основатели, что столкнулись с одинаковой проблемой:

ТЗ всем написали круто: возможно, какие-то моменты им, как людям, далёким от IT, показались непонятными, но в целом с логикой всё было ок. Прототипы сделали тоже хорошо, согласовали и дизайн – иногда не с первого раза, но в итоге внешний вид всем понравился.

Реализовали и вёрстку: кнопочки тыкались, поля вводились: функционально это дело ещё не работало, но выглядело уже совсем как готовое приложение. Сделали программирование: сервис стал работать в рамках своего контура без интеграции – как отдельный проект. Наличие пары-тройки ошибок – не критично, дело поправимое. А потом начался этап интеграции, и вот тогда-то всё пошло наперекосяк. Почему так вышло?

Проблема в том, что при формировании ТЗ API интеграции толком не изучается. Техзадание пишется с упором на внутренний контур – то есть на то, что должна сделать внутренняя команда. Что в итоге не стыкуется с API сервиса. Когда мы занимались разработкой единого окна, мы подошли к задаче с другой стороны, поэтому сразу увидели, что у всех маркетплейсов совершенно разные категории товаров.

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

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

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

Второй – доплатить разработчикам, которые говорят, что за изучение API они денег не брали. Понимаю, что такое может быть на самом деле, но услышать это в конце проекта, мягко говоря, очень неприятно. Что мешало изучить это API раньше? Он же за три-четыре месяца разработки не менялся. У одного из основателей подобная доплата вышла аж в половину разработки, так что в итоге он заплатил х1,5 раза больше, чем оговаривалось изначально.

Резюмируя выше сказанное: проблема в том, что команда откладывает самое сложное напоследок. А интеграция – это всегда самое сложное, ведь при ней ты не управляешь всем процессом в целом внутри контура своей студии, а работаешь со сторонним софтом. Нельзя сказать Озону, чтобы он поправил свой API, нельзя заставить Вайлдберис принимать картинки.

Чтобы не попасть на подобные грабли, проект нужно делать «от обратного».

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

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

Итак, в случае примера нам нужно начать с интеграции. Но возникает вопрос: а что интегрировать-то, если ещё ничего не сделано? Даже прототипов нет. Здесь нужно создавать то, что я называю «пред-MVP» — ещё не конечный продукт, но заглушку, позволяющую интегрироваться. Для того же единого окна делалась база данных, в которой размещено условных десять товаров, и мы эти товары по API пытаемся залить в Озон, Вайлдберис, Яндекс и смотрим, чтобы происходили обновления остатков, падали заказы. По сути, на своей стороне мы поднимаем только небольшую базу данных да небольшой контроллер для обработки заказов – просто чтобы нам на страничку выводилось «заказ принят».

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

А уже дальше идёт стандартная история с прототипами, дизайном и всем прочим. Этап интеграции уже будет пройден, и всё, что останется – это внедрить готовые процессы в собственный софт. Проблем на прочих стадиях обычно не бывает Если студия нормальная, 99% вероятности, что вас доведут нормально – но стоит заранее узнать, какие могут возникнуть проблемы. Выделяете всё самое сложное в отдельное задание и заказываете «пред-MVP».

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

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

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

А если прогресса нет, ничего на промежуточных этапах компания вам показать не может – скорее всего, пора расставаться и забирать деньги, полностью или хотя бы частично. Даже заплатив за второй договор вы сэкономите больше, чем в случае, если бы проблемы возникли позже. Чаще всего интеграция требует 20% затрат от общих расходов, но это самые важные 20%, и от них зависит успех проекта.

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

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