Это вторая часть трилогии статей, посвящённой несоответствию между презентацией (pitch deck) и работоспособным продуктом, с которым сталкиваются все стартапы.

Если вы пропустили, вот первая часть.

В первой части статьи была задана общая картина и в общих чертах описан парадигма «Разделяй и властвуй».

Эта часть посвящена самостоятельным «лего»-блокам разного размера, которыми вы можете воспользоваться уже сегодня. Это технический практический материал, но он важен и, я уверен, стоит каждой потраченной минуты.

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

Definition of Done (DoD)

Примечание: я начинаю список с DoD, потому что другие примеры на него ссылаются, а не потому что он важнее остальных.

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

Мои DoD включают разделы по фронтенду, бэкенду, UI/UX и управлению проектами. Вы можете описать структуру файлов типичного React-компонента, используемую терминологию и привести пример. Часто я рекомендую плагины для IDE, которые помогают создавать необходимые папки и файлы с шаблонным содержимым на основе моего шаблона. Нажмите, чтобы создать каркас. Заполните пробелы.

Дайте знать, если вы хотите заглянуть в мой типичный DoD в Notion или Obsidian — с радостью поделюсь.

Управление корпоративными знаниями

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

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

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

Примечание: управление личными знаниями (PKM) — моя страсть. Если вы хотите навести порядок в знаниях — своих и вашей компании — я веду об этом рассылку.

Юридические и бухгалтерские материалы

Условия использования, политики cookies, NDA, трудовые договоры, шаблоны счетов и т.д. Если вы в инкубаторе или у вас есть сеть контактов — не изобретайте велосипед. Попросите шаблоны, по крайней мере на ранней стадии.

Разработка, ориентированная на компоненты (CDD)

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

Front-End

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

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

Одно из первых инструментов, которые я обычно представляю — это Storybook. Инструмент для фронтенд‑разработчиков, позволяющий создавать компоненты в изоляции. Постепенно формируется набор устойчивых, самодостаточных, «неубиваемых» компонентов. Внедрение Storybook на раннем этапе разработки сначала немного замедлит вас, но при наличии упорства вы преодолеете этот порог, и скорость последующей работы возрастёт экспоненциально.

Выделенный файл Storybook для каждого веб‑компонента — часть Definition of Done. Если элемент не работает в изоляции — он не считается «рабочим».

Back‑End

Другой устойчивый «лего‑блок» для облачных стартапов — Infrastructure as Code (IaC). Он описывает все строительные блоки безсерверной архитектуры в виде кода, который можно версионировать, совместно редактировать, размещать или удалять одной кнопкой.

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

Мои IaC реализованы в основном с помощью Amazon Web Services (AWS) CDK v2 на TypeScript. Я с радостью ими поделюсь, если хотите взглянуть. Свяжитесь со мной.

Прочее

Принципы CDD применимы и к пакетам npm, Inc., Ruby gems или Java beans. Их можно хранить открыто или в частных репозиториях артефактов. Это стоит внедрять.

Фреймворк и инструменты управления проектами

Вы можете определиться с инструментами и шаблонами для управления проектами заранее, описав будущие процессы в DoD.

Официальный сайт и шаблоны лендинг‑страниц

Вам нужен веб‑сайт. Многие эксперименты по типу Lean Startup Co. проводятся на лендинг‑страницах. Важно уметь создавать их быстро, не нагружая команду разработчиков. Желательно, чтобы они были интегрированы с CRM — например, HubSpot позволяет создавать лендинги, отслеживать вовлечённость и собирать лиды.

Для A/B‑тестирования гипотез подойдут Google Optimize или PostHog A/B Testing. Интеграция с React имеет нюансы, но это стоит усилий.

Свяжитесь со мной если хотите посмотреть мой пример реализации.

Система управления учётными записями пользователей

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

Без доступа к паролям будущие модификации пула потребуют больше усилий. Я настоятельно рекомендую как можно раньше найти баланс между безопасностью и удобством, ориентируясь на специфику вашего бизнеса.

Обработка платежей

Цель любого бизнеса — зарабатывать. Интеграция с платёжной системой не должна ждать. Изучите её документацию прямо сейчас и попробуйте внедрить даже в песочнице.

Это подскажет важные инженерные решения.

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

Великие художники воруют.

Блоки дизайн‑системы

Визуальная айдентика и тон звучания необходимы почти с первого дня. Это набор guardrails, которые сотрудники обязаны соблюдать. Цветовые палитры, типографика, иконография — всё это часть системы.

Современные инструменты позволяют управлять дизайн‑токенами в стиле CDD. Голос бренда можно стандартизировать с помощью Grammarly.

Настройте инструменты и сразу создайте несколько отдельных «проектов»: библиотеку глобальных дизайн‑токенов, UI‑kit, веб‑приложение, мобильное/десктоп‑приложение, pitch deck и материалы для соцсетей.

Фреймворки для тестирования

QA — странная область: все понимают её важность, но реальных ресурсов часто недостаточно. Без TDD у вас может даже не быть тест‑фреймворка.

Начальный setup и автоматизация части тестов требуют небольших усилий, особенно smoke‑ и snapshot‑тестов. Я реализую их как часть веб‑компонентов и IaC‑конструкций, запуская при каждом коммите через CI/CD. Это тоже часть DoD.

Автоматизация разработки

Сложно объяснить, почему приоритет «удобства разработчиков» важен не меньше пользовательских фич. Но это не выбор между чёрным и белым.

Чтобы быстро и качественно доставлять ценность, вам нужны инструменты: CI/CD, Git‑хуки, линтинг, форматирование, приватные репозитории и авто‑документация.

А что с вашим набором инструментов? Давайте обсудим в комментариях.

Блоки бизнес-анализа

Все пропускают эту важнейшую часть — для меня это один из первых deliverables, даже если наняли на что‑то другое. Если за это меня уволят — значит, я не в той компании.

Я использую корпоратные инструменты, такие как UML, чтобы моделировать бизнес и его части.

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

Дайте знать — может быть, вы знаете более современный и эстетичный способ моделирования. Я уже долго ищу.

Аналитика

Вам нужны глаза.

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

CRM и ERP

Вам нужно сердце.

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

Нетехнические сотрудники ожидают, что технические работают структурированно. Но это работает в обе стороны. Отчет вроде «было много интересных разговоров» — выглядит как шутка, и уважение к вам теряется.

Заключение

Этот список получился длинным, но всё ещё далеко не полным. Моя цель — поделиться с вами основами. Ваш путь может отличаться в зависимости от характера бизнеса.

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

Есть ли какие-то конкретные строительные блоки, о которых вы хотели бы узнать подробнее?

Особая благодарность

Эта статья во многом опиралась на внимательные замечания Lilian T. , Farouq Aldori, Teppo Hudsson, Jarek Owczarek, Nickolay Tsybulyanko, и Jason Collins.