Технический дизайн 14-17 минут на прочтение

Особенности технического проектирования стартапов

Поделиться:

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

В этой статье я расскажу об «индюшатине» («инди», «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 и очищает БД. В трекер немедленно начинают валиться баги, которые программисты просто не смогут разобрать, потому что условие их возникновения — тупая очистка БД во время прохождения основного сценария. Разумеется, я не дал этой кнопке появиться на свет.

Не тратьте ресурсы. В стартапе все меняется.

§ Самое главное

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

5/5 (48 голосов)
, Ваша оценка:

Поделиться:

Павел Шерер
Павел Шерер

Продюсер, аналитик, продуктовый дизайнер IT-решений

Комментарии (3)

Ivan Tsarkov
Вообще, все верно написано. Но уж очень поверхностно, как мне показалось. Безусловно, в рамки одной статьи не уместить многолетний опыт, но на каких-то моментах можно было бы остановиться поподробнее.
Павел Шерер
Пост и так вышел объемным, не каждый осилит. Может быть, в следующий раз распишу каждый аспект в деталях. Если интересно что-то конкретное, могу тут, в комментах, рассказать.
Максим Бурлак
Интересно читать, спасибо!

Добавить комментарий

Чтобы оставить комментарий, войдите:
Нет соединения с сервером.Сервер получил неверные данные, попробуйте еще раз.

Похожие посты

Top