Правило 1. «Документируйте свои решения, особенно временные»

C 2011 по 2013 год я принимал участие в мегапроекте по внедрению CRM-системы в крупную телеком компанию и мне повезло в разное время отвечать за различные части этой самой системы. Надо сказать, уроков я вынес очень много, однако, был наиболее примечательный случай, речь о котором и пойдёт в этой главе.

В какой-то момент я отвечал за дизайн и внедрение процесса технической поддержки клиентов. Компания была очень крупной и только недавно прошла первую стадию реорганизации, формально став единой компанией, а в реальности состояла из нескольких локальных “княжеств”. У каждого “княжества” было своё руководство, видение, свой IT ландшафт, набор лучших практик, локальный бюджет и чувство острой непереносимости корпоративного центра и всех, кто с ним связан, в данном случае нас.

Перед нами была поставлена задача — создать единую систему управления через внедрение IT решения.

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

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

Сложность процесса технической поддержки состояла в том, что технические подразделения имели географическую привязку и потому работали в чётко определённой области: например, не по всей Москве, а только в районе Фили или Очаково. При этом в городах-миллионниках это означало, что на одной и той же улице могут работать два разных подразделения. Например, дома с номерами от 1 до 50 обслуживает подразделение А, дома с номерами 51–100 обслуживает подразделение Б, при этом подразделения, работающие по определённому адресу, могли иметь разную специализацию. При этом, колл- центр, принимавший звонки клиентов, мог находиться в другом регионе и обслуживать несколько филиалов.

Вишенкой на торте стало то, что технические подразделения не работали в CRM, а работали в локальных системах, заявки в которые нужно было отправлять через API, реализованные нами на шине.

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

Преодолеть такой уровень сложности сразу казалось непосильным, поэтому мы стали проектировать решение параллельно с его внедрением, постепенно создавая нужные структуры и механизмы.

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

Ещё через 3 месяца мы закончили проектирование и были готовы подключать следующий филиал – Сибирь. Полного тестового контура не было, и системы, заявки в которые должны были уходить из CRM, были только «боевые» и тестировать интеграции пришлось сразу на боевой среде. CRM в сибирском филиале был уже запущен ранее, но с ограниченным функционалом информационного справочного обслуживания: никаких заявок технической поддержки там не было. Следовательно, для них это было расширение уже существующей функциональности.

Дело было так: создали мы заявку в CRM под роли оператора Сибирского колл-центра, сохранили, а в целевую систему она не попадает. Ещё раз — опять то же самое… В общем, завели баг и стали искать. Проверили код в CRM — заявка создаётся нормально, попадает в очередь на отправку, где в сторону шины происходит вызов, но не появляется в целевой системе.

Стали грешить на шину! Пришли к её команде — те тоже всё проверили: вызов системы происходит, выдает логи, а в них все нормально.

Затем двинулись трясти команду внешней системы, а они говорят, мол, не было у нас вызова API.

Идём обратно к ребятам из шины, а они уже злые как черти! Всё проверили, отдельно протестировали, заново накатили обновления, в логах вызов происходит. Только вот филиал указан Дальневосточный, а, значит, и API вызывают системы Дальневосточного филиала! Проверили на внешней стороне и, в самом деле, заявки наши лежат в системе технического блока Дальневосточного филиала. Стали выяснять у команды шины, почему они неправильную привязку сделали, а у них идентификатор филиала приходит со стороны CRM, по нему и вызывают API. В итоге — поменяли разработчиков на CRM, посадили опытного сеньора, тот все проверил и переписал часть кода: все равно заявка уходит на Дальний Восток.

Тогда-то наш технический менеджер собрал всех в одной переговорке и организовал совместную сквозную проверку кода для выяснения причины ошибки.

Сидим, разбираем код шаг за шагом, рисуем на доске последовательность. Тут очередь доходит до системного аналитика, который отвечал за разработку адаптера от CRM к шине. Он говорит, что у него все правильно — из CRM вызов он принимает, берет код филиала из запроса и на шине дёргает нужный API. Открывает свой код, показывает в подтверждение своих слов, что, в самом деле, берет параметр из CRM, обрабатывает его по всем правилам, определяет вызываемую систему и передаёт константу с ID филиала…. Как вы, наверное, догадались, константа подставляет значение Дальневосточного филиала.

Надо ли говорить, что ребята из команды шины его чуть на месте не поколотили. Стали выяснять: зачем же он такую диверсию сделал? Оказалось, никакого злого умысла. Помните, в самом начале я упоминал, что механизм определения филиала мы сразу сделать не могли? А запустить Дальний Восток было нужно. Потому, наш системный аналитик, подготовил структуру для приёма ID филиала из CRM, но из-за того, что в продуктиве был только один филиал – он сделал константу, до того дня, когда будет реализован полноценный механизм. Вот только не стал этого нигде описывать, да и сам, как оказалось, забыл по прошествии времени.

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