В 2013-2014-ом годах почти сразу после внедрения CRM в крупном телеком-операторе, меня позвали на проект внедрения этой же системы, но с небольшими модификациями (также телеком). Изначально мне и моей команде отвели роль по настройке системы и сбору бизнес-параметров (сегменты клиентов, типы договоров, типы SLA и прочее). В отличие от предыдущего проекта, который мы делали по SCRUM, эта система внедрялась по Waterfall и все дизайны были написаны, а доработки согласованы. По факту оказалось, что не все так гладко и одной настройкой не обойтись - в итоге родились несколько сложных, интересных задач, а также новые полезные уроки. Об одном из самых ярких, название которого я вынес в заголовок, я и хочу рассказать.
После того, как клиент понял, что мы можем не только собирать бизнес-параметры, но ещё и проектировать систему, нас быстро засосало в водоворот проектной и корпоративной деятельности. Писем и встреч стало так много, что приходилось настраивать фильтры и, конечно же, расставлять приоритеты. Некоторые письма и встречи приходилось игнорировать, что, собственно, и привело к получению этого урока.
У нашего заказчика были разные сегменты клиентов: от физических лиц до государственных органов. Для работы с государственными органами были выделены отдельные специалисты и даже телефонные линии. По понятным причинам, телефонные номера колл-центра для государственных органов не афишировались, а, значит, всегда были те государственные представители, которые не находили выделенный номер телефона и звонили со своим запросом по общей линии, опубликованной на сайте. Обычным операторам категорически запрещалось работать с такими клиентами и даже просматривать информацию о них: при поступлении такого звонка, они должны были максимально оперативно перевести его на специализированную линию.
Для того, чтобы оператор случайно не начал обслуживать такого клиента, заказчик решил разместить баннер, который сразу показывал бы оператору, что работать с этим клиентом нельзя. С этого и начались вопросы и обсуждения: «что это за баннер?», «какого он должен быть размера?», «куда в системе его можно поместить?». К дискуссии были подключены поставщик CRM, дизайнеры, менеджеры клиента, аналитики и многие другие. В конечном итоге, оно свелось к обсуждению двуглавых орлов, флагов России, орлов на фоне флага, изображений Белого дома, и так далее. Примерно через 3 недели терпение у всех закончилось и было принято решение собрать большую очную встречу, чтобы окончательно принять решение по баннеру.
На эту же встречу пригласили и меня.
Я, как обычно, был занят и потому читал почту и сообщения, параллельно прислушиваясь к разгорающемуся скандалу вокруг. В какой-то момент все горящие задачи кончились, я закрыл крышку ноута и поднял голову. Представитель заказчика уже раздражённым тоном объясняла важность размещения максимально большого баннера в CRM и сетовала на то, что такая дорогая и крутая система не может поддержать увеличение блока до нужных им размеров.
В этот момент я решил вклиниться в разговор:
Я: «А в чем суть этого баннера? Если позвонил клиент из государственных органов, оператор может его по каким-то вопросам консультировать или всегда переводит на менеджера?»
Заказчик: «Нет, обслуживание категорически запрещено, он даже не имеет права смотреть данные клиента. Мы потому и просим сделать баннер таким большим, чтобы он его точно заметил и сразу предложил перевести клиента»
Я: «А у этих клиентов есть явный признак того, что они относятся к государству?»
Заказчик: «Да, конечно, все такие клиенты имеют чёткий сегмент – государство и эта информация всегда присутствует на профиле клиента. Собственно, по наличию этого признака мы и хотим выводить баннер»
Я: «Вадим (архитектор поставщика CRM), я же правильно помню, что мы можем привязать ролевую модель доступа к любому признаку на карточке в системе?»
Вадим: «Да, конечно, ролевая матрица может быть завязана на любой бизнес-параметр»
Я: «А почему тогда не привязать просмотр карточки к ролевой модели? Если обратился клиент с признаком «государство», то мы проверяем наличие на роль оператора права на работу с государственным сегментом. Если такого права нет, то экран просмотра данных клиента блокируется всплывающим окном, на которое мы выводим сообщение «Внимание! Клиент относится к сегменту государство, обслуживание категорически запрещено. Предупредите клиента и переведите на линию обслуживания клиентов государственного сегмента». Выводим телефон персонального менеджера, который привязан к этому клиенту и общий номер линии, который мы всё равно храним в профиле каждого сотрудника».
Наступила тишина… Спустя полминуты представитель заказчика, повернулся к Вадиму и спросил: «Вадим, а что, так можно сделать?»
- «Да, без проблем, все данные уже есть, нужно только немного доработать систему и реализовать всплывающее окно. За неделю сделаем, но не в этот раз, потому что текущий релиз уже согласован и отправлен в работу.»
Из этой ситуации я сделал для себя вывод, что, если бы я сразу включился и проанализировал, что требуется заказчику, а не впал в столь комфортную модель транзакции – нужен баннер, нужен и хорошо, скажите какой. Мы могли не тратить этот месяц на пустую переписку, не тратить ресурс кучи людей, часть работы которых точно пойдёт в стол – я обо всех эскизах дизайнеров. Мы могли сразу описать это решение и даже реализовать в ближайшей итерации, а не откладывать такую нужную и простую доработку на 2 месяца.
Конечно, я оправдывал себя, что задач было слишком много и до этой я добрался только тогда, когда появилось время: у меня были другие приоритеты, а у заказчика - аналитики, которые тоже должны были думать. Правда состоит в том, что я не стал вникать и поддался искушению затеряться в большом коллективе в ожидании, что проблема решится сама, и в глубине души надеясь, что меня в обсуждение этой задачи включили просто «до кучи».
Правильным, конечно же, было бы не участвовать в коллективном прожигании времени, а выяснить суть запроса, определить приоритет для проработки и отказать в участии в работе над этой задачей.
Тогда у заказчика появилась бы возможность определить для себя, насколько эта задача важна для него здесь и сейчас, обратиться к менеджеру проекта и запросить перераспределение задач моей команды. В том случае, если эта задача оказалась бы в самом деле критичной, я смог бы переключить на неё внимание, а менее срочные задачи отнести в бэклог.
Позже я не раз убеждался, что пассивное присутствие без действий приводит к печальным последствиям. Лучше отказать в решении проблемы и поработать с возражениями, чем делать вид, что ты пассивно участвуешь в её решении.