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

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

Но, собственно, спустимся с небес общих тезисов к тем самым горшкам на которых мы обожглись. Итак, проект Carbox. Довольно высокотехнологичное начинание в сфере торговли автомобильными запчастями. Сайт предоставляет возможность подобрать комплект для технического обслуживания (ТО) большого количества автомобилей, основываясь на информации о модификации авто и его текущем пробеге.

На старте заказчик предоставил базы данных автомобилей, автодеталей к ним и регламентов ТО, плюс обрисовал бизнес-процессы. По представлению заказчика, базы содержали все необходимые данные, а процессы — весьма близки к тому, что и требуется. Команда взялась за реализацию — параллельно загружая данные в БД и прописывая код. К моменту, когда проект уже выходил казалось бы на финишную прямую, оказалось… оказалось, что и оказывается чаще всего — большой разрыв между мыслимым и реальностью. Исходные базы данных страдали существенной неполнотой и содержали массу некорректной информации, в процессах же по мере реализации заказчик увидел массу недостатков, которые требовалось исправлять и дополнять, что требовало не только дополнительного времени на реализацию, но и пересмотра самого концептуального фундамента приложения — моделей и базовых алгоритмов. Итогом этого этапа стало понимание, что потраченное время ушло в никуда — нет ни адекватной базы данных, ни кода. Приложение работало — не без огрех, конечно (это всё-таки была пре-альфа версия), но делало не то, что нужно было заказчику к тому моменту, когда он понял просчеты в своих первоначальных представлениях, не говоря уже о том, что выдавало это приложение некорректные результаты, так как в базу данных были загружены некорректные данные из исходников.

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

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

И это было бы смешно, если бы не было грустным.

Потому что — да: назвался Creative — изволь шевелить извилинами.

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

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

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

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

Эта фаза является, пожалуй, наиболее продолжительной, так как здесь и будут основные правки, когда выяснится, что данных не хватает и/или они неверны, а процессы — не совсем то, что хочется видеть в действительности. Фактически, эта фаза заменяет собой написание ТЗ для проектов, у которых есть основа в виде уже функционировавшего бизнеса заказчика, от которой можно отталкиваться как от прототипа. Для того же Carbox мы в результате собрали 5 версий БД, пока в финале, совместно с заказчиком, не добились полной адекватности БД. И нам пришлось процентов на 80% переписать код сайта — учитывая правки и пожелания заказчика.

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

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

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

Это и есть сигнал к релизу!

Дочитавшему до сюда — слава! А теперь представь, мой терпеливый читатель, что всё это надо аккуратно изложить заказчику, окрыленному идеей стартапа, который видит своё детище уже практически во плоти, а тут какие-то риски, какие-то фазы… Надеюсь, кстати, что ты и есть наш будущий заказчик, я и здорово сэкономил время нашей компании на объяснения: а почему вместо 6 месяцев сайт разрабатывается год?

 

Автор: Андрей Евдошенко