Содержание 6
В прошлом посте мы рассказывали о самом масштабном обновлении ОФИС 21 за последние 5 лет. Тогда главной задачей было не трогать привычный интерфейс: на глобальные обновления решаются неохотно, поэтому всё — новая серверная часть, переписанная телефония, заново собранная почта, рефакторинг ядра — делалось так, чтобы снаружи было максимально незаметно. Мы осознанно не меняли интерфейс и фронт, насколько это можно сделать, накатывая накопленные за 5 лет обновления.
Но в удовольствии исправить старые баги и подчистить систему мы себе не отказали. И, конечно, наступили на старые грабли: если баг достаточно долго живёт в продакшене, он становится фичей. Пользователи адаптируются, выстраивают на нём свои процессы и начинают использовать систему именно так.
Топ-3 бага, которые стали фичами в нашей CRM. А ещё — выводы, которые мы сделали для будущих обновлений.
1. Картинки в описании контрагента
Осталось с тех времён, когда мы ставили rich-text редактор везде, где можно, — даже там, где хватало обычного текстового поля. Некоторые пользователи стали вставлять скриншоты переписки прямо в поле «Описание контрагента», что совершенно выглядит нелогично для авторов CRM.
После обновления поле стало исключительно текстовым: посмотреть старые скриншоты нельзя, поправить — тем более. Как следствие — ощущение, что «всё сломалось», и экстренный патч, который перевёл эти скриншоты в комментарии, доступные для просмотра.
Для пользователя это было не просто поле, а рабочая карточка клиента: в одном месте — имя, телефон, договорённости и переписка. Скриншот в описании казался самым быстрым способом сохранить контекст. Когда редактор убрали, вместе с форматированием исчез и этот сценарий.
Можно было объяснить, что хранить переписку в описании неправильно. Но данные уже стали частью работы, поэтому старые изображения мы перенесли в комментарии: они остались доступны, хотя привычное место изменилось. Главное правило здесь простое — сначала сохранить данные, потом менять интерфейс.
2. Поле «Текст заявки» на пол-экрана
При поступлении заявки с сайта в CRM загружался весь HTML, который передавал сайт. Поле раздувалось до огромных размеров, и часть пользователей стала использовать его для комментариев и ведения истории работы с контрагентом.
После обновления HTML из заявок исчез, поле стало нормального размера — и пользователям стало «неудобно»: раньше было на весь экран, а теперь только на часть.
Отдельное открытие ждало тех, кто заглянул дальше: у каждой сделки есть возможность добавлять комментарии. Они выстраиваются в хронологически верную историю, их удобно просматривать. Но пока поле было безразмерным, до этой возможности просто не доходили — работой со сделкой считали правку поля «Описание».
Менеджеру нужно было видеть контекст: откуда пришла заявка, что клиент написал и какие договорённости уже есть. Большое поле позволяло держать всё в одном месте, хотя для истории в CRM уже были комментарии.
Правильное место для истории — комментарии сделки. Но пока поле было безразмерным, до них просто не доходили. После обновления поле вернулось к своему смыслу, а привычку пришлось перестраивать. Вывод: если функция есть, но ей не пользуются, проблема не только в обучении. Интерфейс мог годами подсказывать неверный сценарий.
3. Лазейка в правах доступа
Мы переписали ролевую модель и закрыли часть лазеек. После этого несколько пользователей обратились в поддержку: потеряли доступ к карточкам клиента. При разборе деталей выяснилось, что доступа им никто и не давал. Ребята нашли хитрый путь: через задачу и связанную сделку попадали в карточку клиента и видели данные, которые им видеть не стоило. Считали это нормальным поведением — и, когда оно пропало, пришли жаловаться.
Это был побочный эффект старой ролевой модели: пользователи не взламывали систему, а шли по ссылкам, которые им разрешали открывать. Поэтому доступ и считали нормой.
После переписывания ролей этот маршрут закрылся. Для безопасности это правильно, для людей — неожиданно. Изменение прав нужно сопровождать объяснением, какие сценарии меняются, и проверкой, не осталось ли у сотрудников законных задач, которые раньше решались через лазейку.
Выводы: почему баг становится фичей
Во всех трёх случаях пользователи не спорили с разработчиками. Они работали в системе так, как она им разрешала. Баг становился фичей не потому, что его не замечали, а потому, что он закрывал реальную задачу.
Совместимость важнее чистоты
Чистая модель данных не стоит ничего, если вместе с ней исчезает доступ к рабочей информации. Перед удалением или упрощением поля нужно проверить, какие данные и процессы на него завязаны. Если данные нужны — их сохраняют и переносят, даже если новое место кажется очевидным.
Интерфейс формирует привычку
Пользователь редко читает документацию перед первым кликом. Он видит большое поле и начинает писать в него. Если правильный сценарий спрятан, а неправильный — на виду, система сама обучает неправильному поведению. Значит, дело не только в дисциплине сотрудников.
Безопасность ломает сценарии
Закрыть лазейку правильно. Но если через неё годами решали законную задачу, после закрытия люди останутся без доступа. Перед изменением прав стоит пройти по реальным маршрутам сотрудников и понять, какие из них были побочными, а какие — единственными.
Чек-лист: если баг стал фичей
Этот список мы держим в голове перед обновлениями, которые меняют привычное поведение системы.
- Проверить данные. Понять, что хранится в старом поле или сценарии и что будет с этим после изменения.
- Сохранить доступ. Перенести старые данные в новое место до того, как отключить старое поведение.
- Предупредить заранее. Объяснить не только что меняется, но и как теперь решать прежнюю задачу.
- Показать правильный путь. Подсказка, пустое состояние или пример работают лучше, чем статья в базе знаний.
- Проверить побочные маршруты. Особенно там, где права доступа пересекаются с задачами и связанными сделками.
Что дальше: обновление интерфейса CRM
Сейчас готовим второе большое обновление — оно затронет исключительно интерфейс и фронтенд. Надеемся, там будет меньше интересных находок, но будем честны: обновление будет действительно масштабным и сильно изменит привычное взаимодействие с CRM.
Если вы столкнулись с похожей ситуацией — старый сценарий изменился, а работа встала — напишите в поддержку. По описанию задачи мы быстрее поймём, что именно сломалось: баг это или привычка, которую нужно поддержать.
Внедрим CRM под ваши продажи
Настроим телефонию, e-mail и отчёты — заявки сами разложатся по воронке.
