Второй продукт на том же фундаменте: что заложить в первый

Один продукт уже работает: приложение, личный кабинет, сервис. Появилась идея второго, и первая мысль - снова платить за то, что и так есть. Вход, права, уведомления, оплата, админка: всё это во втором продукте нужно ровно так же, как в первом. Вопрос в том, что именно удаётся перенести и как устроить первый продукт, чтобы второй не начинался с пустого места. Разбираем, как мы строим продукты с расчётом на следующий.

Когда второй продукт стоит делать на том же фундаменте?

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

Проверка простая. Представьте, что оба продукта уже готовы, и ответьте на три вопроса.

1. Одни и те же люди будут ими пользоваться? Если да, это общий вход и общий профиль.
2. Платить будут из одного места или разными способами? Если из одного, это общий биллинг.
3. Данные продуктов связаны? Заказы, заявки, история, каталог, переписка. Если человек в первом продукте что-то завёл, а во втором это видно, у вас общая модель данных.

Два «да» из трёх - фундамент общий. Три «нет» - это два независимых продукта, и связывать их силой не стоит.

Что такое фундамент продукта на практике?

Коротко: фундамент - это части, без которых продукт не работает и которые не про смысл вашего продукта. Пользователь их не замечает, зато второй продукт без них не собрать.

Слова «платформа» и «ядро» звучат тяжело, а на деле это короткий перечень.

• Вход и роли. Кто входит, как подтверждает себя, что ему можно, а что нельзя.
• Платежи и подписки. Приём оплаты, тарифы, счета, возвраты.
• Уведомления. Письма, СМС, сообщения в мессенджер: один механизм на все продукты.
• Админка. Место, где вы и сотрудники видите пользователей, заказы, платежи.
• Файлы и документы. Куда складываются и откуда отдаются картинки, сканы, выгрузки.
• Аналитика. Один способ считать события и показывать цифры.
• Данные и права доступа. Общая модель того, чем продукт владеет, и правила, кому это видно.
• Общие интеграции. Платежи, СМС, карты, бухгалтерия: подключаются один раз.

Что из этого берётся во второй продукт целиком, а что пишется заново, видно в таблице ниже.

Что переиспользуется, а что пишется заново?

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

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

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

Как проверить, готов ли первый продукт стать фундаментом?

Коротко: готовность зависит не от размера продукта. Всё решает то, насколько аккуратно он устроен. Проверки понятны и владельцу: входит ли в проект новый человек, разделены ли части, есть ли описание, меняется ли одна часть без поломки другой. Больше половины «нет» - сначала упорядочить первый продукт, иначе второй просто скопирует его беспорядок.

1. Новый человек запускает проект. Не только автор. Если проект поднимается у одного разработчика, переносить нечего: это единственная копия, живущая у одного человека.
2. Части разделены. Можно ли поменять оплату, не ломая каталог? Если любая правка тянет за собой весь продукт, второй продукт унаследует ту же связанность.
3. Есть описание. Схема продукта, где какие части и как связаны. Без неё переносить нечего.
4. Есть критерии приёмки. У рабочих частей записано, что считается сделанным. Тогда переносимую часть можно сдавать по записанному критерию.
5. Данные отделены от логики. В базе они лежат по понятным правилам, не разбросаны по коду. Это то, что переходит во второй продукт.

Если пункты проходят, фундамент переносится. Если нет, начинать второй продукт поверх первого - значит удвоить его проблемы. Мы в таких случаях сначала разбираем требования и записываем ограничения, и только потом трогаем код.

Что заложить в первый продукт, чтобы второй не начинать с нуля?

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

1. Границы частей. Вход, права, уведомления и файлы из списка выше собирают в отдельные части, к которым обращаются все остальные разделы. Именно они переносятся во второй продукт.
2. Контракты между частями. Записанные правила: как одна часть обращается к другой. Тогда часть можно заменить или вынести, не переписывая продукт.
3. Платежи через один шлюз. Даже если продукт пока платный по одной схеме, оплата идёт через один код обработки - второй продукт подключится к тому же месту.
4. Админка - с запасом под второй продукт. Место, куда раздел второго продукта можно добавить, не переделывая первый.
5. Аналитика с самого начала. События записываются с первого дня, иначе второй продукт начнётся без истории.
6. Записанные ограничения. Что система не делает и почему. Это спасает второй продукт от старых ошибок.

Так спроектировали wellness-приложение: следующий продукт студии не начинается с нуля. Тот же принцип - в маркетплейсе, который встаёт на фундамент первого продукта.

Когда общий фундамент мешает?

Коротко: когда продукты на самом деле разные или когда «фундамент» закладывают заранее, под гипотезы, которых может не быть. Общий вход ради одного пользователя и биллинг ради одного тарифа - это стоимость без пользы. Часто задача решается без общей надстройки, и это тоже результат: иногда выходит втрое дешевле.

Признаки, что не стоит.

• Пользователи разные и не пересекаются.
• Оплата у продуктов разная по природе: подписка против разовых заказов.
• Данные не связаны и не будут.
• Второй продукт - эксперимент, который может не пойти.
• Подрядчик предлагает «платформу» раньше, чем вы показали ему второй продукт.

Общая часть берёт на себя риск за все продукты сразу. Чем больше догадок вы в неё заложили, тем дороже каждая из них, когда догадка не сбудется. Фундамент под конкретный второй продукт - нормально. Другое дело - строить его под «когда-нибудь будет много продуктов»: так платят за то, чего может не быть.

Как оценивать работу и что спрашивать у подрядчика?

Коротко: следите, чтобы в смете переиспользование было видно по частям, отдельными строками, а не одной строкой «платформа». Спрашивайте, что уже есть в первом продукте, что переносится и что пишется заново. Ответ «берём всё как есть» без разбора частей - тревожный знак, как и «перепишем всё».

• Что в первом продукте уже можно взять целиком, а что придётся писать заново?
• Как вы проверили, что эти части переносятся, а не только называются общими?
• Что случится со вторым продуктом, если первый придётся серьёзно менять?
• Как вы оцениваете свою же работу: по частям или одной суммой?
• Что вы предлагаете вовсе убрать из второго продукта как лишнее?

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

Что записать в ТЗ и договор?

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

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

Критерий приёмки, записанный заранее, снимает спор «перенесли или скопировали». Про то, как заказывать разработку и договариваться об оплате, у нас есть отдельный разбор.

Частые ошибки

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

1. Закладывать общее ядро под гипотезы, которых ещё нет.
2. Начинать второй продукт поверх первого, не наведя в нём порядок.
3. Считать биллинг общей частью, хотя тарифы у продуктов разные.
4. Прятать переиспользование в смете одной строкой «платформа».
5. Не записывать контракты между частями - тогда переносить нечего.
6. Оформлять общий вход ради одного пользователя и одной оплаты.

Источники

• Мартин Фаулер, «Harvested Platform»: как общее ядро выносят из работающих продуктов: Harvested Platform
• Aha!, инженерный блог, «Embrace the monolith: adding a new product»: что переиспользовали при добавлении второго продукта: adding a new product to Aha!
• InfoQ, «How Much Architecture Is Enough: MVP vs MVA»: почему преждевременная архитектура удорожает: MVP vs MVA
• AWS re:Invent, слайды «SaaS architecture pitfalls: lessons from the field»: типовые ошибки общих сервисов: SaaS architecture pitfalls
• Kill Bill, «Multi-Tenancy and Authorization»: общий биллинг как отдельный слой: multi-tenancy and authorization
• TechTarget, «Understanding the modular monolith and its ideal use cases»: как разделять части, не дробя продукт: modular monolith

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