Я не добавляю поле в продукт только потому, что оно может пригодиться когда-нибудь
Я не добавляю поле в продукт только потому, что оно может пригодиться когда-нибудь. Такая фраза звучит безобидно, но за ней обычно стоит будущая работа: кто-то будет вводить значение, кто-то — проверять, кто-то — объяснять, почему оно пустое, а потом команда будет переносить это поле в интеграции и отчёты.
Поле похоже на полку в складе. Пустая полка сама по себе не мешает. Но если на неё можно положить что угодно, рано или поздно вокруг неё появляется спор: что здесь хранить, кто отвечает и почему в нужный момент ничего не находится.
У поля должна быть работа
Перед добавлением я стараюсь назвать решение, которое изменится благодаря этим данным. Не «нам полезно знать отрасль клиента», а «по отрасли меняется обязательная проверка договора» или «по отрасли руководитель выбирает сценарий запуска». Если решения нет, поле чаще всего будет жить пустым или случайным текстом.
Следующий вопрос — кто владелец значения. Если человек не понимает, зачем он отвечает на вопрос, он введёт первое удобное слово. Если владельца нет, никто не заметит, что список вариантов разросся до двадцати почти одинаковых формулировок.
Это особенно заметно в B2B-продуктах. У разных клиентов появляется просьба добавить «ещё один маленький реквизит». По отдельности каждая просьба разумна. Вместе они превращают карточку в анкету, где важная часть тонет среди полей на всякий случай.
Лишнее поле создаёт не только лишний экран
Данные редко остаются там, где их ввели. Поле попадает в экспорт, API, поиск, права доступа, уведомления, отчёты и резервные копии. Затем его начинают использовать так, как изначально не планировали. Один небрежный справочник становится причиной дублей, а свободный текст — причиной ручной сверки.
Поэтому я связываю добавление данных с архитектурным вопросом: где заканчивается ответственность этой системы? Когда интеграция начинает передавать всё подряд, она открывает партнёру больше, чем нужно для работы. В разборе границы данных в интеграции это видно на обменах, но правило начинается ещё раньше — в самой карточке продукта.
Три варианта вместо автоматического «да»
Когда появляется запрос на новое поле, я обычно рассматриваю не один, а три пути.
- Поле действительно нужно. Тогда определяем тип, владельца, обязательность, срок хранения и место в процессе.
- Нужно не поле, а правило. Например, вместо ручной отметки о просрочке лучше вычислять её по дате и статусу.
- Нужен редкий комментарий. Не стоит превращать единичное исключение в постоянную часть модели для всех пользователей.
Второй вариант встречается чаще, чем кажется. Команда просит «признак срочности», потому что люди по-разному понимают дедлайн. Но настоящая задача может быть в правилах приоритета и праве остановить работу, а не в очередном переключателе.
Пример без привязки к конкретной компании
Допустим, в сервисе хотят хранить «причину ручной корректировки». Идея правильная: важное изменение не должно исчезать бесследно. Но свободное поле даст десятки вариантов вроде «исправил», «ошибка», «по просьбе». Через месяц такой набор нельзя анализировать.
Лучше сначала определить несколько повторяющихся причин, добавить понятный выбор и оставить комментарий только для необычного случая. Так продукт получает и управляемые данные, и человеческое объяснение. Главное — не выдумывать список из пятидесяти причин заранее. Начать стоит с реальных повторяющихся ситуаций и пересматривать список по мере работы.
Как понять, что поле можно убрать
Я проверяю четыре сигнала: значение почти всегда пустое; пользователи вводят разные слова для одного смысла; отчёты не используют данные; изменение поля никому не принадлежит. Любого одного сигнала мало. Но если совпадают два-три, пора разбираться, а не ждать, пока это попадёт в следующую интеграцию.
Удаление тоже требует аккуратности. Сначала нужно выяснить, не питается ли полем старый отчёт или экспорт. Архитектурные решения хороши тем, что из них можно безопасно выйти: этот подход я подробно описывал на примере обратимости решений. Для данных это означает: предупредить, показать замену и дать время проверить последствия.
Короткая проверка перед добавлением
- Какое решение станет лучше благодаря значению?
- Кто и в какой момент его заполняет?
- Кто отвечает за качество?
- Нужны ли варианты выбора вместо свободного текста?
- Где поле окажется кроме карточки?
- Когда его можно перестать хранить?
Эти вопросы не замедляют продукт. Они защищают его от накопления случайных решений. Хорошая модель данных не та, в которой предусмотрено всё. Хорошая модель оставляет только то, что помогает человеку принять решение и объяснить его завтра.
Обязательное поле — это маленькое обещание
Как только поле становится обязательным, продукт обещает, что без него нельзя принять решение. Если это не так, пользователь ищет способ пройти дальше: ставит прочерк, копирует прошлое значение или выбирает первый пункт списка. На экране появляется заполненность, а в данных — ложная уверенность. Поэтому обязательность я проверяю отдельно от полезности: иногда значение хорошо бы знать, но оно не должно блокировать работу.
Есть и обратная ошибка: важное значение оставить свободным текстом, потому что так быстрее. Быстрее только первый раз. Потом отчёт не может собрать «доставку», «Доставка», «дост.» и пустую строку в один управляемый показатель. В таких случаях помогает не жёсткая анкета, а небольшой словарь с понятными вариантами и правом предложить новый. Так продукт не заставляет людей угадывать, но сохраняет общий язык.
У данных должен быть срок жизни
Вопрос «нужно ли хранить это всегда?» я считаю частью проектирования. Некоторые значения нужны только до закрытия задачи. Другие должны остаться в истории, потому что объясняют решение. Третьи требуют ограниченного доступа. Если срок жизни не назван, поле почти гарантированно попадёт во все будущие выгрузки и интеграции просто по инерции.
Это не призыв собирать меньше информации любой ценой. Это призыв собирать ровно то, за что продукт готов отвечать. Чем яснее у данных цель, владелец и конец жизни, тем легче развивать систему без случайных зависимостей.
Обсудим?