Самый распространенный вопрос, который мы получаем от других основателей, касается не ценообразования или выхода на рынок. Это тихое, немного подозрительное сообщение: Как команде вашего размера удается поддерживать 150 модулей и при этом все это не рухнет? Честный ответ: мы не поддерживаем 150 модулей. Мы поддерживаем одну платформу и очень тонкий слой поверх нее. Хитрость заключается в безжалостности относительно того, к какому слою принадлежит данное произведение.
Математика, которая пугает людей.
Если представить 150 модулей как 150 маленьких приложений — каждое со своей моделью данных, своими разрешениями, своим биллингом, своими уведомлениями — то 22 человека — это явное безумие. Это шесть модулей на одного инженера, каждый из которых представляет собой отдельный продукт. Ни одна команда этого не выдержит. Опасения верны для этой архитектуры.
Но дело не в архитектуре. CRM, инструмент для выставления счетов и служба поддержки выглядят для пользователя как три разных продукта. В основе лежит та же горстка примитивов: записи, отношения, временная шкала событий, роли и разрешения, деньги, документы и шина уведомлений. Различия в основном заключаются в словарном запасе и компоновке, а не в механизмах.
Мы не создаем 150 отличных продуктов. Мы создаем небольшое количество хорошо построенных примитивов, настроенных 150 способами.
Разделение ядра/модуля.
Все жесткое живет в ядре и создается один раз: идентификация, разрешения, уровень реляционных данных, платежи, хранилище файлов, поиск, журнал аудита, система уведомлений, механизм экспорта. Это те части, которые действительно сложны и искренне разделены. Исправленная здесь ошибка исправлена для всех 150 модулей одновременно. Добавленная здесь возможность — скажем, электронные подписи — мгновенно становится доступной каждому модулю, который этого хочет.
Таким образом, модуль намеренно делается тонким. Это схема данных, набор представлений, один или два рабочих процесса и словарь для одной задачи. «CRM» — это конфигурация, в которой говорится: эти типы записей — это лиды и сделки, это представление конвейера, это этапы, вот что означает конверсия. Он полностью опирается на ядро. Новый модуль — это в основном декларация, а не код.
Жесткое правило: зарабатывайте свою уникальность.
Дисциплина, которая удерживает это от гниения, — это единственное правило, соблюдаемое при проверке: модуль не может быть особенным, если он действительно этого не заслужил. Каждый раз, когда модулю нужна собственная модель разрешений, собственный формат одноразовых уведомлений, собственный способ хранения даты — ответ по умолчанию — нет. Вставьте это в ядро как общую возможность или не делайте этого.
Это раздражает в данный момент и имеет решающее значение на протяжении многих лет. Большинство запросов типа «нам нужно что-то особенное» на самом деле сводятся к следующему: «мы недостаточно хорошо подумали об общем случае». Когда вы форсируете общий случай, ядро становится богаче, каждый модуль получает преимущества, а площадь поверхности, которую вам приходится поддерживать, остается примерно одинаковой, даже если количество модулей увеличивается.
От чего мы отказались.
У этого подхода есть реальная цена, и мы должны ее назвать. Лучший в своем классе точечный инструмент, созданный командой, одержимой одной задачей, превзойдет наш аналогичный модуль в этой единственной работе. Самая глубокая почтовая платформа имеет автоматизацию, которой нет у нас. Самый глубокий инструмент проекта имеет представления, которых нет у нас. Мы не претендуем на обратное.
То, ради чего мы жертвуем этой глубиной, — это согласованность — модули, которые используют одну модель данных, один логин, один счет, один экспорт и один уровень уведомлений. Для команды из 5–50 человек такая согласованность стоит больше, чем последние 20% глубины в любой отдельной категории. Для команды, весь бизнес которой относится к этой категории, это не так. Мы точно знаем, для кого мы, и благодаря архитектуре мы можем обслуживать их с помощью 22 человек.