Правило 5. «99,9 % результата — это отсутствие результата»

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

Особенностью данной работы стало то, что все эти правила требовалось сводить в Excel в виде строки с множеством параметров для каждого правила и делать конкатенацию значений по шаблону, который был понятен системе потребителю. После чего файл передавался в подразделение заказчика, который загружал его в систему и там это файл проходил валидацию: сначала на целостность структуры правил, а затем коллеги с помощью скрипта создавали все типы заявок и проверяли, что оказались ли те в нужном подразделении и доступны ли пользователям, имеющим соответствующие права. При этом доступ к тестовому контуру нам не давали по каким-то «соображениям безопасности». Файл получился монструозно-огромным и обрабатывать его приходилось с помощью функций ВПР, скрипов и функции конкатенации.

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

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

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

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

Я был публично отшлёпан, а в риски проекта была добавлена высокая вероятность срыва его сроков по причине неготовности настроек системы. При том, что настройка всей остальной части системы и выполненная задача по миграции данных, описанная выше в главе «Ешьте слона по частям» в расчёт не принималась.

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

После этого моя команда проверила файл вдоль и поперёк, мы провели множество тестов средствами Excel, загрузили файл в Microsoft Access и провели там ряд тестов. Ошибка, представленная на «статусе», была единственной на несколько сотен тысяч строк. Исправив её, мы отдали файл на повторную загрузку. Недовольный начальник IT-подразделения, сказал, что, если опять будут найдены ошибки, то будет поставлен вопрос о штрафе всей команды.

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

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

Я же до сих пор считаю, что при работе с такими объёмами и без доступа к тестовой среде, мы сделали свою работу на «отлично». Все же, из этой ситуации я вынес правило: «99,9% процентов результата — это отсутствие результата». Чтобы вы не делали и как близко не подошли бы к успеху, всегда держите это правило в голове и доводите дело до 100%.