В предыдущей статье я призывал вас документировать свои «особенно временные» решения. Они требуют особого внимания, ведь, когда вы реализуете решение «по-быстрому» и потом его не исправляете, то оно становится постоянным. Это значит, что вокруг этого костыля начинает развиваться и все остальное решение, и чем больше оно развивается, тем более тяжёлыми становятся попытки его исправления, и тем больше проблем вы поимеете в будущем. Потому я давно склонился к мысли, что все временные решения — зло, а зло должно быть наказано в самые короткие сроки, иначе оно непременно разрастётся и поглотит все добро вокруг него.
На том же проекте по внедрению CRM (см. предыдущую главу) , перед нами встала задача фиксировать проблематику, с которой обращаются клиенты, а также результат обработки проблемы со стороны технических служб.
Поскольку технический блок работать в CRM не собирался и оставался в своих локальных системах, то и причины обращений клиентов они предлагали брать из своих справочников. Темы обращений типа «нет зуммера в трубке», «короткое на линии» или «не резолвится домен» были понятны техническому блоку, но абсолютно чужды коммерческому, который, собственно, и принимал обращения клиентов. Неудивительно, что почти ни один клиент не мог и близко сформулировать свою проблему технически верным языком.
Было сломано множество копий, однако, силы коммерческого и технического блоков оказались равны и потому победить никто не смог.
Мы, как системный интегратор, предложили решение: использовать CRM как мастер-систему по фиксации причин обращения в формулировках понятных специалисту колл-центра. Например, «не работает интернет, лампочка Link горит» или «не работает интернет, лапочка link мигает» и прочее. В справочнике технические специалисты могли бы указывать «результат диагностики» и свои технические коды.
Решение более-менее устроило все стороны, но дорабатывать системы технического блока никто не спешил, потому было принято временное решение использовать “маппинг” тематик CRM на тематики систем технического блока. При том, что тот реализовывался на CRM, под соусом того, что «это же единая система», а в реальности только потому, что на нас эту работу смогли спихнуть — в тот момент нашего влияния на технический блок оказалось недостаточно.
Немало копий было сломано и тут, несмотря на то что изначально у нас был только один филиал и не более 150 значений для “маппинга”. Постепенно стали добавляться новые филиалы, каждый из которых привносил свои новые значения справочников, которые, ну, никак не соответствовали значениям справочников других филиалов!
Причины были как объективные, например, наличие в конкретном филиале технологий, которые не использовались другими, так и субъективные (коих оказалось большинство) : «не такая детальная диагностика», «у нас суть проблемы описана, а там только симптомы», «мы по этому справочнику отчёты руководству представляем» и так далее.
В то же время вокруг нашего справочника начал развиваться аналитический функционал. Коммерческий блок обозвал его «инструментом воздействия» на технический блок. По этой причине они анализировали: с какой тематикой открывается заявка, как именно она меняется в техническом блоке и с каким результатом обработки закрывается. Дальше мы собирали обратную связь от клиента и, если проблема не решалась, долбили технический блок претензиями.
Технический блок, в свою очередь, начал анализировать свои тематики, убирать дубли, добавлять новые тематики и убирать те, что не использовались ранее. Все эти процессы шли параллельно добавлению новых филиалов, которые ещё не приступали к такому анализу, а потому просто требовали добавить все их тематики в “маппинг”.
За все эти изменения была ответственна наша команда. Тысячи значений в “маппинге”, их постоянные изменения и завязки механизмов интеграции на тематики. Помните, я писал в предыдущей главе, что разные подразделения могли выполнять разную работу на одном и том же участке? Все это привело к тому, что управлять стало почти невозможно.
И вот, дойдя до края пропасти, мы собрались на трёхстороннюю встречу: мы (как системный интегратор) , коммерческий и технический блоки заказчика. Немного поломав копья и “вдоволь надвигавшись труп” между нами, мы договорились:
1. Сделать CRM-мастера по причинам обращений клиентов: все локальные системы технического блока должны были получать эти тематики от нас без возможности редактирования.
2. Технический блок проведёт универсализацию результатов обработки заявок и реализует единый справочник во всех своих системах, запретит локальные тематики, если они не обусловлены технологическим ландшафтом.
3. Справочники будут обновляться только после совместной проработки коммерческого и технического блоков.
4. Обновление справочников проходит одновременно в CRM и системах технического блока.
После этих договорённостей жизнь у всех наладилась. Стоит отметить, что на принятие этого решения ушло больше года. А систему мы внедряли по методологии SCRUM и каждые две недели выкатывали доработки.
Таких примеров костылей я могу привести ещё множество — вспомните хотя бы решение с константой в предыдущей главе. Иногда временные решения носят такой разрушительный характер, что для их исправления требуется замена IT систем. Так, например, в одном банке, для повышения скорости запросов к процессинговому центру был реализован прямой доступ к базе. А запросы эти выводились в пользовательский интерфейс, который был доступен операторам колл-центра и офиса продаж. Другими словами, любой сотрудник банка мог получить любые сведения об операциях клиентов, банкоматов и POS-терминалов под служебным логином. Несмотря на обоснованные возражения блока безопасности, решение не просто существовало, а даже периодически развивалось. Потому для исправления ситуации требовалось существенно переработать IT ландшафт.
Я не идеалист и понимаю, что избежать временных решений и добиться блестящих результатов с первого раза невозможно, потому не призываю совсем отказываться от временных решений и полировать решение до блеска. Напротив, я призываю действовать, хоть и извилистыми тропами, но идти вперёд. Внедряя временные решения, делайте это с осознанием того, что они закрывают глаза на проблемы текущего дня и ограничивают ваши возможности в будущем. Потому каждый раз, когда вы делаете временное решение, сразу планируйте его переработку на целевое решение. Не откладывайте переделку в долгий ящик на неопределённый срок – закладывайте изначально рефакторинг системы в план её развития.
Чтобы вам ни говорили проектный менеджер или клиент, вы, как архитектор, должны настаивать на выделении стабилизационных итераций.
Помните: проявив малодушие в начале пути, в конце вы окажетесь виновным в провале проекта! Всегда держите в голове тезис «временные решения – зло», а зло должно быть наказано и как можно быстрее.