Вопросы фаундера об архитектуре, чтобы проверить, подходит ли она бизнесу сейчас

Почему это вообще происходит

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

Доход растёт или падает. Меняются цены. Продажи начинают искать более крупных клиентов. Поддержка получает новый тип запросов. И какое-то время кажется, что ничего не сломалось. Команда по-прежнему выпускает обновления. Сделки по-прежнему закрываются. Поэтому никто не останавливается и не спрашивает, подходят ли подключение, поддержка и правила продукта тому, как компания теперь зарабатывает.

Изменение цен — частый триггер. Компания может начать продавать более крупные контракты, но по-прежнему подключать клиентов вручную, как это делали для маленьких self-service аккаунтов. Или, наоборот, снизить цены, чтобы продавать больше, но оставить модель поддержки, которая работала только тогда, когда каждому клиенту помогали лично. Цифры меняются быстрее, чем операционная модель.

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

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

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

Что спросить до разбора систем

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

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

Начните с последних 12 месяцев. Изменились ли цены? Двинулась ли команда в сторону более крупных клиентов? Стали ли клиенты просить больше согласований, проверок безопасности или индивидуального подключения? Старая архитектура часто тихо ломается тогда, когда бизнес начинает продавать по-другому.

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

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

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

Именно так часто Олег Sotnikov начинает разбор на oleg.is, прежде чем переходить к техническим деталям. Фаундер может думать, что приложение просто медленное или беспорядочное, но более глубокая проблема часто проще: компания изменила способ продаж, а система за этим не успела.

Если на эти вопросы четыре человека отвечают четырьмя разными способами, на этом и остановитесь. Первая проблема не в техстеке. Бизнес-правила больше не настолько ясны, чтобы строить вокруг них систему.

Вопросы о смене цен

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

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

Чтобы разговор был предметным, задайте четыре простых вопроса:

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

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

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

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

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

Вопросы о подключении клиента

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

Попросите показать реальный путь с реальными людьми. Кто трогает аккаунт после закрытия сделки: продажи, поддержка, customer success, инженер, фаундер или сам клиент? Когда кто-то говорит «команда всё делает», продолжайте спрашивать, пока у каждого перехода не появится имя.

Обычно три вопроса показывают большую часть проблем:

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

Ответы показывают, где начинает появляться несоответствие. Если крупным клиентам нужен security review или индивидуальное подключение, это может быть нормально. Если даже пробным пользователям нужна ручная помощь, прежде чем они увидят пользу, продукт слишком сильно зависит от людей.

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

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

Простое сравнение делает это заметным. Возьмите одну недавнюю пробную регистрацию, один аккаунт малого бизнеса и одну enterprise-сделку. Если одна из них запускается за 15 минут, а другая требует двух недель переписки туда-обратно, решите, у вас один продукт с понятными уровнями сервиса или три разных продукта, которые притворяются одним.

Вопросы о расползании продукта

Вопросы о расползании продукта часто самые неприятные. Они заставляют посмотреть на функции, настройки и исключения, которые когда-то помогли закрыть сделку, а теперь тормозят весь продукт.

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

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

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

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

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

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

Как провести проверку шаг за шагом

Лучшие проверки начинаются с реального клиента, а не с теории. Возьмите одну недавнюю сделку: клиента, который быстро подписался, выбил скидку, потребовал индивидуальное подключение или создал дополнительную нагрузку на поддержку в первый месяц. Одна сделка даёт факты. Мнения подождут.

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

Простой первый проход выглядит так:

1. Запишите исходную цену и любую скидку или особое условие.
2. Добавьте обещание, которое сделали продажи, включая всё, что говорили по звонкам или в письмах.
3. Отметьте каждый шаг подключения, ответственного, согласование и время ожидания.
4. Отметьте все обращения в поддержку за первые 30 дней.
5. Обведите всё, что случилось только потому, что эта сделка не вписывалась в обычный путь.

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

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

Заканчивайте на маленьком и проверяемом выводе. Не выходите из встречи с шестью проблемами и длинным списком пожеланий. Уйдите с одним несоответствием, которое команда может проверить уже в этом месяце. Например: «Мы продаём тариф, который выглядит как self-service, но каждому новому клиенту всё равно нужно ручное согласование на подключение». Это даёт понятный следующий шаг и то, что можно измерить.

Простой пример

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

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

Чтобы закрывать эти сделки быстрее, продажи начинают обещать индивидуальное подключение. Один клиент хочет специальный импорт. Другой — дополнительные звонки по безопасности. Третий просит вручную проверить данные перед запуском. Ни одна из этих просьб сама по себе не выглядит огромной, поэтому команда соглашается.

Через несколько месяцев работа накапливается. Операционная команда теперь вручную проверяет данные в таблицах, готовит выгрузки, ходит на стартовые звонки и ведёт исключения по каждому аккаунту отдельно. Поддержка тратит больше времени на помощь новым enterprise-клиентам. Инженеры добавляют одноразовые настройки и внутренние инструменты только для того, чтобы процесс подключения не встал.

Доход от нового тарифа на бумаге выглядит хорошо, но каждая команда чувствует, что стала работать медленнее. Маленькие клиенты дольше ждут помощи. Работа над продуктом буксует, потому что инженеры постоянно чинят крайние случаи подключения. Продажи продолжают продавать обещание, и очередь растёт.

Именно здесь помогают правильные вопросы. Если завтра продажи перестанут предлагать индивидуальное подключение, сколько enterprise-сделок всё равно закроется? Какие шаги подключения происходят для каждого крупного клиента, а какие существуют только потому, что один менеджер это пообещал? Сколько людей трогают один аккаунт, прежде чем клиент сможет начать пользоваться продуктом? Покрывает ли enterprise-цена дополнительный труд, или компания прячет сервисную работу внутри выручки от софта?

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

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

Ошибки, которые скрывают настоящую проблему

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

Один громкий клиент тоже может исказить весь разговор. Один enterprise-покупатель может попросить индивидуальное подключение, особый биллинг или дополнительный процесс. Это не значит, что этого хочет весь рынок. Если один клиент попросил кастомный контрактный процесс, а 47 клиентов подписались без него, кастомный процесс — исключение, а не правило.

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

Типичный пример выглядит так: одному крупному потенциальному клиенту нужно собранное вручную подключение, поэтому команда добавляет звонки, согласования и ручной импорт. Через шесть месяцев каждый новый клиент идёт по тому же медленному пути, даже если self-service был бы вполне достаточен.

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

Слишком общие вопросы тоже скрывают правду. «Подключение слишком сложное?» — обычно даёт расплывчатый ответ. «Покажите мне последние три подключения клиентов и где именно они замедлились» — уже даёт реальные факты. То же самое с ценами. «Цена всё ещё работает?» — слабый вопрос. «Что произошло в последних пяти сделках после запуска новых цен?» — уже то, что можно проверить.

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

Быстрые проверки перед завершением

Перед тем как закончить встречу, проверьте, может ли команда описать бизнес ясно, без слайдов и длинных объяснений. Именно здесь быстро видно размытое мышление.

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

Используйте короткий финальный чек-лист:

• Попросите одного человека объяснить предложение в одном предложении. Если ему нужно пять, клиентам, скорее всего, тоже всё не так понятно.
• Спросите, может ли новый клиент получить первую ценность по обычному пути. Если каждая вторая сделка требует особого маршрута, подключение делает работу за продажи, которую не должно делать.
• Спросите поддержку, как они отвечают на самый частый вопрос новичка. Если для обычных ответов всё ещё нужен инженер, продукт слишком сложно понять со стороны.
• Попросите команду назвать одну функцию, которую они бы заморозили, объединили или убрали в этом квартале. Если никто не может выбрать, разрастание продукта уже стало политическим вопросом.
• Спросите, какое одно изменение цены или подключения они могут протестировать в ближайшие 30 дней. Если ответ — «сначала нам нужен полный редизайн», значит, бизнес двигается медленнее, чем должен.

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

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

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

Что делать после разговора

Хорошая проверка всё равно может ни к чему не привести, если никто не превратит её в маленькое и понятное исправление. Заканчивайте одним решением, а не кучей идей. Выберите несоответствие, которое прямо сейчас стоит больше всего времени, маржи или доверия клиентов.

Первый вопрос часто оказывается менее драматичным, чем ожидают люди. Команда может поменять цены, но оставить ту же ручную работу по подключению каждого нового аккаунта. Продажи закрывают сделки поменьше, а операционная команда всё равно относится к каждому клиенту как к индивидуальному проекту. Этот разрыв быстро съедает прибыль.

Перед тем как все разойдутся, запишите четыре вещи:

• одно несоответствие, которое нужно исправить первым
• цену, если оставить всё как есть
• одного ответственного
• один срок для первого изменения

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

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

Иногда разрыв глубже. Вы можете увидеть, что цены, поставка, структура команды и объём продукта тянут в разные стороны. Когда это происходит, перестаньте добавлять заплатки. Возьмите короткую внешнюю проверку у Fractional CTO или стартап-советника, прежде чем делать ещё больше изменений.

Именно здесь опытный советник может помочь. Oleg Sotnikov через oleg.is работает со стартапами и небольшими компаниями как раз над такими проблемами архитектуры, процессов и соответствия продукта бизнесу. Иногда короткая внешняя проверка обходится дешевле, чем ещё один месяц внутренних споров.

Если встреча закончилась одной названной проблемой, одним ответственным и одной датой, значит, она сработала.