Как уже ясно из заголовка, речь пойдет об особенностях проектирования стартапов. Но не о тех стартапов, которые создаются, ведутся или курируются компаниями и «серьезными дядьками из министерств». Там четкая финмодель, бюджеты, сроки, должности, статистики и прочие прелести. Их тоже называют стартапами, но там все проще — по крайней мере, стабильнее и понятнее.
В этой статье я расскажу об «индюшатине» («инди», «independent» — термин пошел от инди-игр; это такие проекты, в которых финансирование довольно ограничено, со всеми вытекающими). Классические стартапы — это когда 5 человек на 15 позициях, 20 тысяч баксов бюджета, пылающие адским пламенем зенки и во-о-от такая вот вера в собственные силы. Потом, когда база пользователей перевалила за 100k, а инвесторы кружат вокруг плотоядными коршунами, начинается совсем другая история.
Этот пост — о технических особенностях проектирования именно таких стартапов, «индюшатины». Конечно, все мои выводы рождены не на пустом месте, каждый из них подтвержден отдельным факапом (и о них я тоже расскажу).
Изначально этот пост был докладом на очередном собрании Гильдии вольных проектировщиков. Там его довольно тепло встретили — и это подтолкнуло меня на оформление его в виде статьи.
Роль проектировщика в стартапе
Чтобы определить, какой именно технический бэкграунд требуется от проектировщика в стартапе, стоит сперва определить круг его обязанностей, какую часть рабочего процесса он берет на себя. Собственно, само проектирование кардинально не отличается от привычного всем нам — хотя отличия, все же, есть. Главное, что необходимо понимать: проектировщик в стартапе — это почти технический директор. А в ряде случаев вообще — продюсер.
Во-первых, чаще всего технического директора как явления попросту нет — и его обязанности распределяются между наиболее опытными участниками. Согласен, это не лучшая практика, но реальности чаще всего плевать на эти наши каноны.
Во-вторых, тут имеет место гиперболизация еще одной функции проектировщика — ведения проекта. Во многих компаниях проектировщик ведет проект от начала и до конца (и я глубоко убежден, что это крайне полезное занятие). Так вот в стартапах эта его функция просто необходима. Только проектировщик знает продукт по-настоящему досконально. Очень часто даже CEO не владеет информацией во всей полноте: максимум, ядро функциональности.
И насколько бы подробной не была проектная документация — в стартапе она недолго остается актуальной. Стартап должен быть пластичным — а значит, тот прототип, который вы подготовили в январе, к марту, скорее всего, уже устареет. Порой возникает ситуация, при которой нужно быстренько додумать какую-нибудь функциональность, когда полпроекта уже написано.
Факап
Однажды меня пригласили в стартап, который к тому времени разрабатывался уже почти год. Ребята собрали все грабли, которые могли — плюс выдумали пару своих, и тоже на них наступили. К моменту моего погружения в проект у каждого участника было по персональной такой, любимой, шишке на лбу. Как и везде, тут были свои Царь-грабли — их роль выполнял «синдром преждевременной геймификации». Дело даже не в том, что они на ходу выдумывали фичи, не допилив основную функциональность — главная проблема крылась в том, что абсолютно никто не понимал, что вообще происходит и где конец этого ада. Ачивки и другие писькомерки погребли под собой всю структуру приложения: как информационную, так и техническую.
У меня неделя ушла на вычленение ядра — и еще почти месяц, чтобы создать базовую документацию, причесать трекер и вообще наладить процесс. Да, это не работа проектировщика — налаживание процесса и разбор тасок в трекере. Но без этого было невозможно продолжить ведение проекта. Все равно что продумывать эргономику трюмного люка на тонущем корабле.
Уточнение технических направлений
Представьте: вам нужно спроектировать сервис, который…
- будет опрашивать три внешних агрегатора;
- получать у них данные, объединять полученное;
- сохранять результат в виде отдельных графиков;
- отправлять отчеты пользователям в мобильное приложение с пушами;
- распознавать фотографии таблиц и формировать на их основе отдельные документы.
Вроде, все понятно, и вы влегкую пилите прототип, команда приступает — но в процессе разработки вдруг выясняется, что:
- изменить интерфейс распознавания документов нельзя, потому что для удешевления взяли готовый SDK — а значит, нужно проектировать дополнительный экран;
- данные с агрегаторов собираются не так, как вы думали — и объединение происходит уже на клиенте, а значит, о плавной анимации, которой вы так гордились, можно забыть;
- в пуш-уведомления нельзя встроить экшены, потому что по соображениям экономии решено было не использовать сторонний сервис, а взять готовый модуль с прежнего проекта.
И все в таком духе.
Виноваты программисты? Нет.
Думаю, вы уже поняли суть. Проект был задуман и спроектирован в отрыве от реальных возможностей стартапа — и привело это к тому, что интерфейсное взаимодействие накрылось медным тазом.
Что же делать? Все просто — общайтесь с командой, если она есть. Уточняйте у них все спорные моменты еще на этапе создания информационной структуры и первых сценариев. Узнайте, на каких технологиях планируется разворачивать инфраструктуру, какие у них есть ограничения. Гуглите и снова уточняйте. Со временем гуглежа станет меньше.
Хуже, когда команды (или даже намека на нее) пока нет — тогда вся ответственность за решения ложится на вас. Тут без хотя бы поверхностного технического бэкграунда не обойтись. Копайте, спрашивайте у товарищей по цеху, гуглите. Но ни в коем случае не бросайте эту историю на самотек — велика вероятность, что вы гробите еще даже не рожденный проект.
Новые технологии
Этот пункт напрямую не связан с привычным большинству пониманием проектирования, но вытекает из предыдущих, так как вы в любом случае окажетесь втянутыми в обсуждение технических средств реализации. Помните, мы говорили, что проектировщик — почти техдир? Так вот этим и отличается кошерный проектировщик в стартапе — он курит технологии.
Стартапы принято ассоциировать с передовыми разработками, самыми крутыми DevOps и так далее. Типа «на острие прогресса».
Забудьте об этом. Если стартап сам по себе не создает новую технологию, то в разработке лучше использовать проверенные средства, пусть они и будут чуть постарше. Подсказка: если у версии фреймворка, плагина или компонента стоит приставка «beta» — бегите.
По возможности старайтесь использовать средства и технологии, известные команде — то, с чем ваши ребята уже работали. Это касается не только языка программирования — но и конкретных фреймворков. Иначе потребуется куча времени на их изучение.
Почему все это так важно? Хотя бы потому, что в середине разработки у вас начнут вылезать баги, выяснить причину которых будет крайне сложно, а пофиксить — так вообще только велокостылями. Или очередное обновление с беты на релиз сломает API.
Вроде, несложно. Но в реальности вы будете встречать ряд проблем с этим пунктом. Взять хотя бы программистов: эти ребята тоже делятся на несколько типов. Самые талантливые, как правило, самые дорогие — а в стартапе денег нет. Но без них, на одних «середнячках», стартап далеко не уедет. Так вот заманить этих загадочных ребят можно, в числе прочего, этими самыми новыми технологиями. Дилемма получается, да? Посоветовать тут нечего — лавируйте. В любом случае: «предупрежден, значит вооружен».
Ну и не пренебрегайте лицензиями — изучите хотя бы базовые (MIT, GPLv2, BSD, MPL CCA и тп). Помните, что вы — почти техдир? И если вы посоветуете кодерам заюзать проприетарную либу, они будут только рады. А клиент (после того, как ему прилетит иск) — нет.
Факап
Делали гибридное приложение на Apache Cordova. В приложении пять экранов с картой. Конечно, взяли Google Maps. Вот только стандартная кордововская карта нещадно тормозит при любом действии сложнее пинча. Решили попробовать встроить нативную карту — она такая плавная, приятная на ощупь. Разумеется, она только-только вышла из беты, а в команде ее никто еще не юзал. Лучше бы от руки нарисовали, чесслово. Без преувеличения; 50% времени одного из разработчиков сожрала именно она. Остальные 50% слопал чат, который мы почему-то решили делать на реактивной базе данных.
В итоге — полный фейл, один из прогеров был полностью потрачен. На все время разработки.
Масштабируемость и развитие
При проектировании стартапа важно помнить, что вы создаете только ядро продукта. Стартап должен быть гибким, масштабируемым — иначе он не сможет приспособиться к меняющимся условиям рынка (даже если он уже определен). Это в принципе справедливо для большинства проектов — но в стартапе масштабируемость особенно важна. Как правило, рынок до конца не исследован — и бизнес-модель может кардинально поменяться (я к этому еще вернусь).
Ваш проект должен быть готов развиваться в любом направлении — как вертикально, так и горизонтально. Нужно предусмотреть оба варианта.
Как это влияет на работу проектировщика? Непосредственно. Если вы создаете дашборд, то должны учесть, что на нем могут выводиться не только 2-3 ключевых показателя, но и десяток второстепенных, о которых вы пока даже не знаете. Если вы создаете список пользователей для модераторов, нужно быть готовым, что за два дня их станет больше в 40 раз (у меня такое было однажды) — и модераторы окажутся к такому попросту не готовы. Более того, техническая реализация интерфейса в тот раз оказалась в еще большем профаке — при обновлении списка в реальном времени все разлеталось и интерфейс становился похож на китайский интернет-магазин.
Факап
Давным-давно, еще на заре своего погружения в IT, я работал в молодой компании (не стану называть ее имени). Ребята в самом начале создавали «готовый» продукт. Они считали, что бизнес-модель у них четкая, как новый экран айфона. И когда бизнес стал требовать масштабирования продукта, они оказались не готовы — и потеряли динамику. В итоге сервис закрылся, так не и выйдя на самоокупаемость — хотя идея была мегакрутая.
Ребятам при проектировании такого продукта стоило закладывать как наращивание фич в угоду корпоративным клиентам, так и возможность быстрой серверной кластеризации при взрывном росте количества юзеров. Иначе все тлен.
Факап 2, бонусный
Еще один факап: в одном из стартапов была необходимость интегрировать модуль автогенерации документов. Выбрали, провели интеграцию. А когда вдруг выяснилось, что текущей его функциональности недостаточно и нужно расширяться — оказалось, что он умеет принимать данные только в одном, неизменяемом, виде, и допилить его нереально. Пришлось писать свой аналог, что отняло кучу времени и денег.
Пластичная бизнес-модель
Этот пункт тоже отчасти вытекает из предыдущего, но на нем я хотел бы остановиться поподробнее.
Нет ничего более зыбкого, чем бизнес-модель стартапа. Средства монетизации и привлечения пользователей могут измениться в самый неожиданный момент. Выход на рынок нового конкурента, получение результатов исследований — все что угодно. Спросите у любого матерого инвестора, как он относится к вылизанным финмоделям, которые ему пачками несут юные стартаперы.
При работе над стартапом проектируйте интерфейсы и техническую составляющую так, чтобы в любой момент можно было с минимальными усилиями перепрыгнуть на другую «тропинку». Ни одна ключевая функция не должна быть завязанной на способе привлечения юзеров или получения от них бабла.
Факап (на самом деле нет)
Это не совсем факап, но очень показательный пример. Однажды мы усиленно ваяли одно мобильное приложение. Сложное мобильное приложение. Многокомпонентное, с разделением ролей, кучей внешних интеграций, с огромной вариативностью и так далее. Монетизация изначально строилась на обычных разовых In-App Purchase. Подписную модель тоже рассматривали, но отказались по ряду причин. Так вот на середине разработки бизнес сменил позицию, и эти причины просто перестали учитываться (да, так бывает). Решено было перейти на автообновляемые подписки. А так как в приложении вся функциональность одной из ролей полностью завязана на оплату — это могло бы обернуться приличным факапом. Но не обернулось, потому что я умный.
Напоследок
Ну и напоследок — пара нюансов, которые очень часто вообще не закладываются или закладываются избыточно на этапе проектирования стартапа.
Аналитика
Этот пункт оправдан для любого проекта, но для стартапов — особенно. Аналитика для стартапа — важнейшая составляющая развития, которую нужно продумывать заранее. Очень часто рынка попросту пока нет (есть спрос, но он — не весь рынок), и исследовать практически нечего. Да и ничто не заменит реальных данных, никакие гипотезы не будут ценнее, чем данные, которые мы получаем, наблюдая за поведением настоящих пользователей.
Если у вас не банальный веб-сервис, то очень часто одним GTM не обойтись — нужно объединять несколько систем аналитики. Не продумаете аналитику сначала — будете потом терять какие-то показатели, потому что для них не готова серверная часть или связка попросту не реализуема.
Определите ключевые показатели, поймите, каким образом вы будете собирать эти данные и как их хранить. Если не знаете как — гуглите, учитесь. Пренебрегать этим нельзя.
Например, связка Amplitude+Branch требует определенной пляски с бубном, если вы хотите сэкономить на оплате (а этого все хотят, особенно в стартапах).
Администрирование
Тоже важная часть, при всей своей неочевидности. Если коротко: не вкладывайтесь.
Делайте админку минимальной — только с той функциональностью, которая нужна на старте. Всю аналитику выносите вовне. Если нужно раз в месяц что-то вносить в базу данных — делайте это через консоль или GUI самой БД, максимум — пусть программисты напишут маленький скрипт, который будет выполняться руками.
Например, очень часто при тестировании БД засоряется тестовыми данными: аккаунтами, айдишниками файлов и так далее. Иногда ее нужно очищать. Однажды основатель стартапа предложил мне сделать для этого специальную кнопку в админке. Понимаете весь потенциальный фейл, да? Я не говорю о совершенно лишних усилиях, которые будут затрачены на реализацию одной-единственной кнопки. Я говорю вот о чем: тестировщики такие тестят регистрацию, заходит CEO и очищает БД. В трекер немедленно начинают валиться баги, которые программисты просто не смогут разобрать, потому что условие их возникновения — тупая очистка БД во время прохождения основного сценария. Разумеется, я не дал этой кнопке появиться на свет.
Не тратьте ресурсы. В стартапе все меняется.
Самое главное
Ну и последний совет, самый главный. Именно на него у меня ушло и продолжает уходить больше всего моральных усилий. Не перфекционируйте.
