Ловушка разрастания: как говорить «нет» функциям, которые звучат хорошо, но таковыми не являются
Вы создали то, что нравится пользователям. Теперь они просят функции, которые звучат разумно, но утянули бы приложение в десять разных сторон. Вот как решить, какие запросы выполнять, а от каких вежливо отказаться.
Вы выпустили приложение. Пользователи пришли. И теперь ваш ящик полон запросов на функции, которые все звучат как хорошие идеи.
«Можно добавить экспорт в Excel?» Разумно. «Можно, чтобы счета отправлялись автоматически?» Логично. «Можно интегрироваться со Stripe?» Вот где живут настоящие деньги. «Можно добавить мобильное приложение?» Об этом просят все. «Можно сделать white-label-версию для наших клиентов?» О, а вот тут уже бизнес-модель.
Каждый запрос по отдельности звучит толково. Вместе они звучат так, будто вы строите пять разных продуктов.
Это и есть разрастание функционала (scope creep), и оно убивает больше маленьких приложений на ИИ, чем технические проблемы когда-либо смогут. Не потому, что вы реализуете эти функции, — а потому, что у вас кончаются время, деньги или здравый рассудок в попытке их реализовать.
Как разрастание убивает работающее приложение
Вот что происходит. Вы говорите «да» первым трём запросам, потому что они кажутся разумными. Вы просите свой ИИ-конструктор их добавить. Уходит две недели вместо одной, потому что каждая новая функция натыкается на существующий код. Теперь у вас приложение, которое делает пять вещей: три из них хорошо, а две — так себе.
Затем приходит четвёртый запрос: «Можно сделать разные уровни доступа?» Внезапно вам нужно переосмыслить, кто что видит на каждом экране. Это не функция — это изменение архитектуры. Вы просите ИИ-конструктор это сделать. Оно затрагивает всё. Две недели становятся тремя. Приложение замедляется, потому что вы добавили логику в каждое представление.
К восьмому запросу вы перестали выпускать что-либо новое для своих первых пользователей, потому что слишком заняты тем, чтобы крутить машину запросов на функции. Люди, которые любили приложение три месяца назад, недовольны, потому что ничего из того, что они просили, не доделано. Люди, делающие новые запросы, недовольны, потому что функции делаются вечно.
Вы создали то, что работает. И сломали это, пытаясь быть всем сразу.
Система принятия решений
Вам нужен фильтр. Каждый запрос на функцию проходит через три вопроса:
Вопрос 1: место ли этому в этом приложении, или это отдельное приложение?
Ваше первое приложение делает одну работу действительно хорошо. Приложение для записи записывает на приём. Приложение для счетов выставляет счета. Это разные приложения. Если кто-то просит ваше приложение для записи ещё и выставлять счета, вы не добавляете функцию — вы просите приложение для записи заниматься бухгалтерией. Это другой продукт.
Хороший тест: «Если бы я взял эту функцию и выпустил её отдельно, захотели бы люди её купить?» Если да, ей, вероятно, место в отдельном приложении. Если ответ «нет, она имеет смысл только как часть большего целого», то вы строите правильный объём.
Вам будут приходить запросы вроде «интегрируйтесь с нашей CRM». На самом деле это означает «станьте сами себе CRM». Это другое приложение. Интегрироваться с CRM можно позже. А вот добавить функций на целую CRM, не превратившись в CRM, нельзя.
Вопрос 2: решает ли это проблему большинства ваших пользователей или только этого одного?
Один клиент обожает ваше приложение, и у него есть идея функции. Это реальная проблема, с которой он сталкивается. Это также реальная проблема, которая есть только у него.
Если у вас двадцать пользователей и один просит что-то, проверьте: ждут ли этого остальные девятнадцать, или этот человек просто сам до этого додумался? Можно спросить напрямую: «А вы, кроме себя, спрашивали кого-нибудь ещё, нужно ли им это?» Обычно ответ — нет.
Это опасный вопрос, потому что тот один клиент, что просит, может оказаться вашим самым важным клиентом. Возможно, вам нужно сохранить его расположение. Это бизнес-решение, а не продуктовое. Но действуйте с открытыми глазами: если вы строите что-то для одного клиента, вы не растите своё приложение, вы создаёте консалтинговую практику.
Вопрос 3: чего это стоит и какова цена для исходной идеи?
Всё чего-то стоит. Экспорт в Excel стоит вам инженерного времени. Стоит вашему приложению сложности. Стоит фокуса. Сделайте это вместо оптимизации производительности, на которую пользователи жалуются каждый день, — и вы сделали выбор.
Спросите конкретно: «Если я сделаю это, чего я не сделаю?» Если ответ «ничего, у нас бесконечное время», вы нечестны с собой. Времени не бесконечно. Время конечно.
Цена для исходной идеи часто незаметна. Когда вы по уши в запросах на функции, вы перестаёте поддерживать ту главную вещь, которую люди в вас полюбили. Ядро становится медленнее. Ядро становится глючнее. Ядро ощущается заброшенным. И в конце концов люди уходят, потому что приложение, которое прекрасно работало, теперь работает так себе и делает то, для чего никогда не предназначалось.
Реальный пример: форма приёма заявок
Кто-то сделал простую форму приёма заявок от клиентов. Клиенты её заполняют, коуч просматривает, они договариваются о встрече. Вот и всё приложение.
Запрос один: «Можно отмечать срочные заявки?» Да, это вариация основного процесса. Сделать.
Запрос два: «Можно экспортировать заявки в Excel для моих записей?» Это функция документооборота. Это не задача приложения. Заявки живут в приложении. Если нужен Excel, можно скопировать и вставить. Но ладно, экспорт, возможно, имеет смысл ради удобства. Сделать.
Запрос три: «Можно, чтобы заявки автоматически создавали события в календаре?» Теперь вы занимаетесь планированием встреч. Приложение было для приёма заявок, а не для расписания. Если кому-то нужно и то и другое, ему, вероятно, нужна настоящая система записи, а не костыль, приклеенный сбоку. Вежливо откажитесь.
Запрос четыре: «Могут ли коучи отправлять напоминания о заявках по SMS?» Теперь вы — система коммуникаций. Нет.
К третьему запросу вы упёрлись в границу. Приложение — это приём заявок. Всё остальное — другое приложение. Интегрироваться с этими приложениями можно позже. Добавить их, не превратившись в них, нельзя.
Как говорить «нет»
Самое трудное — действительно это сказать. Вам не хочется огорчать пользователей.
Будьте честны: «Отличная идея, но это другой продукт, не тот, что мы здесь строим. Мы строим [ваша одна работа]. Если мы возьмёмся ещё и за расписание, или счета, или CRM, мы будем во всём этом так себе и ни в чём не великолепны».
Часто клиент поймёт. Он спросил потому, что идея пришла ему в голову, а не потому, что испытывает вас.
Иногда он будет настаивать: «Но мне нужно и то и другое». Вот тогда вы рекомендуете: используйте настоящее приложение для записи. Используйте настоящее приложение для счетов. Используйте настоящую CRM. А это приложение используйте для того, что оно делает хорошо. Это честный ответ.
Искушение быть всем сразу
Самое трудное в создании маленького продукта — говорить «нет». «Нет» ощущается как оставленные на столе деньги. А вдруг тот клиент и правда заплатил бы за оба? А вдруг та функция сделала бы вас в десять раз больше?
Может быть. Но вы не станете в десять раз больше, если ничего не выпустите. Вы станете наполовину доделанным продуктом, который плохо делает пять вещей. Те, кто любил ядро, недовольны. Те, кто хотел новых функций, недовольны. И вы загнали себя в угол, где добавить что угодно новое означает сперва переделать пять старых вещей.
Продукты, которые растут, — это те, что делают одну работу действительно хорошо, а затем добавляют осторожно. Они не пытаются быть Salesforce с первого дня. Это приложение, к которому тянешься, когда нужно сделать ту самую одну вещь, и приложение, которому доверяешь быть быстрым и надёжным, когда это делаешь.
Говорите «нет». Берегите ядро. Сделайте это — и вы создадите то, чем люди действительно захотят пользоваться.