Статья лонгрид и занимает около 15 страниц А4, что в переводе на время может занять у вас 15-20 минут. Потому если вы решите её осилить, придётся запастись временем.
Для удобства чтения добавлено оглавление с возможностью перехода по ссылкам. Приятного чтения.
Оглавление:
Вступление
Правило 1. «Документируйте свои решения, особенно временные»
Правило 2. «Любые временные решения – зло»
Правило 3. «Не будь пассивным участником»
Правило 4. «Ешьте слона по частям: люди боятся больших задач»
Правило 5. «99,9 % результата — это отсутствие результата»
Вступление
Вавилонская башня - известный всему миру пример великого замысла, который провалился.
Причина провала - внешнее вмешательство бога, который заставил людей говорить на разных языках, и те просто не смогли продолжить совместную работу над проектом.
В современном мире отсутствие общего языка, типовых инструментов и хорошо специфицированных требований приводит к провалу множества IT-проектов и без воздействия извне.
К счастью, у некоторых IT-проектов, есть люди, которые могут помочь исполнить задуманное - это IT-архитекторы.
Эти профессионалы призваны решать целый спектр проблем и вопросов, принимать решения различной степени сложности, а порой и менять первоначальные замыслы. И всё это ради того, чтобы достичь результата по его духу, а не по формальному описанию.
И конечно, каждый такой специалист накапливает свой багаж знаний, получает свои уникальные умения и выносит свои выводы и суждения.
Ведь башня огромная, и каждый смотрит на неё со своего угла, компетенций и яруса, на котором он работал.
Здесь я хочу описать свой опыт строительства башни, рассказать о своих ошибках и правилах ведения архитектуры.
Если вдруг вы окажетесь на моей стороне башни, возможно, эти советы будут вам полезны и спасут от досадных ошибок, потраченных нервов и необходимости начинать если не с нуля, то с пары шагов назад.
Правило 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, но из-за того, что в продуктиве был только один филиал – он сделал константу, до того дня, когда будет реализован полноценный механизм. Вот только не стал этого нигде описывать, да и сам, как оказалось, забыл по прошествии времени.
С тех пор у меня из камня высечено правило – документируйте свои решения, особенно когда они временные или носят костыльный характер. Ведь даже вы можете забыть об этих костылях и наступить на них с наскока: хорошо, если отделаетесь шишкой и небольшим позором, а не сотрясением мозга и долгой реабилитацией.
Правило 2. «Любые временные решения – зло»
В предыдущей главе я призывал вас документировать свои «особенно временные» решения. Они требуют особого внимания, ведь, когда вы реализуете решение «по-быстрому» и потом его не исправляете, то оно становится постоянным. Это значит, что вокруг этого костыля начинает развиваться и все остальное решение, и чем больше оно развивается, тем более тяжёлыми становятся попытки его исправления, и тем больше проблем вы поимеете в будущем. Потому я давно склонился к мысли, что все временные решения - зло, а зло должно быть наказано в самые короткие сроки, иначе оно непременно разрастётся и поглотит все добро вокруг него.
На том же проекте по внедрению CRM (см. предыдущую главу), перед нами встала задача фиксировать проблематику, с которой обращаются клиенты, а также результат обработки проблемы со стороны технических служб.
Поскольку технический блок работать в CRM не собирался и оставался в своих локальных системах, то и причины обращений клиентов они предлагали брать из своих справочников. Темы обращений типа «нет зуммера в трубке», «короткое на линии» или «не резолвится домен» были понятны техническому блоку, но абсолютно чужды коммерческому, который, собственно, и принимал обращения клиентов. Неудивительно, что почти ни один клиент не мог и близко сформулировать свою проблему технически верным языком.
Было сломано множество копий, однако, силы коммерческого и технического блоков оказались равны и потому победить никто не смог.
Мы, как системный интегратор, предложили решение: использовать CRM как мастер-систему по фиксации причин обращения в формулировках понятных специалисту колл-центра. Например, «не работает интернет, лампочка Link горит» или «не работает интернет, лапочка link мигает» и прочее. В справочнике технические специалисты могли бы указывать «результат диагностики» и свои технические коды.
Решение более-менее устроило все стороны, но дорабатывать системы технического блока никто не спешил, потому было принято временное решение использовать “маппинг” тематик CRM на тематики систем технического блока. При том, что тот реализовывался на CRM, под соусом того, что «это же единая система», а в реальности только потому, что на нас эту работу смогли спихнуть - в тот момент нашего влияния на технический блок оказалось недостаточно.
Немало копий было сломано и тут, несмотря на то что изначально у нас был только один филиал и не более 150 значений для “маппинга”. Постепенно стали добавляться новые филиалы, каждый из которых привносил свои новые значения справочников, которые, ну, никак не соответствовали значениям справочников других филиалов!
Причины были как объективные, например, наличие в конкретном филиале технологий, которые не использовались другими, так и субъективные (коих оказалось большинство): «не такая детальная диагностика», «у нас суть проблемы описана, а там только симптомы», «мы по этому справочнику отчёты руководству представляем» и так далее.
В то же время вокруг нашего справочника начал развиваться аналитический функционал. Коммерческий блок обозвал его «инструментом воздействия» на технический блок. По этой причине они анализировали: с какой тематикой открывается заявка, как именно она меняется в техническом блоке и с каким результатом обработки закрывается. Дальше мы собирали обратную связь от клиента и, если проблема не решалась, долбили технический блок претензиями.
Технический блок, в свою очередь, начал анализировать свои тематики, убирать дубли, добавлять новые тематики и убирать те, что не использовались ранее. Все эти процессы шли параллельно добавлению новых филиалов, которые ещё не приступали к такому анализу, а потому просто требовали добавить все их тематики в “маппинг”.
За все эти изменения была ответственна наша команда. Тысячи значений в “маппинге”, их постоянные изменения и завязки механизмов интеграции на тематики. Помните, я писал в предыдущей главе, что разные подразделения могли выполнять разную работу на одном и том же участке? Все это привело к тому, что управлять стало почти невозможно.
И вот, дойдя до края пропасти, мы собрались на трёхстороннюю встречу: мы (как системный интегратор), коммерческий и технический блоки заказчика. Немного поломав копья и “вдоволь надвигавшись труп” между нами, мы договорились:
1. Сделать CRM-мастера по причинам обращений клиентов: все локальные системы технического блока должны были получать эти тематики от нас без возможности редактирования.
2. Технический блок проведёт универсализацию результатов обработки заявок и реализует единый справочник во всех своих системах, запретит локальные тематики, если они не обусловлены технологическим ландшафтом.
3. Справочники будут обновляться только после совместной проработки коммерческого и технического блоков.
4. Обновление справочников проходит одновременно в CRM и системах технического блока.
После этих договорённостей жизнь у всех наладилась. Стоит отметить, что на принятие этого решения ушло больше года. А систему мы внедряли по методологии SCRUM и каждые две недели выкатывали доработки.
Таких примеров костылей я могу привести ещё множество - вспомните хотя бы решение с константой в предыдущей главе. Иногда временные решения носят такой разрушительный характер, что для их исправления требуется замена IT систем. Так, например, в одном банке, для повышения скорости запросов к процессинговому центру был реализован прямой доступ к базе. А запросы эти выводились в пользовательский интерфейс, который был доступен операторам колл-центра и офиса продаж. Другими словами, любой сотрудник банка мог получить любые сведения об операциях клиентов, банкоматов и POS-терминалов под служебным логином. Несмотря на обоснованные возражения блока безопасности, решение не просто существовало, а даже периодически развивалось. Потому для исправления ситуации требовалось существенно переработать IT ландшафт.
Я не идеалист и понимаю, что избежать временных решений и добиться блестящих результатов с первого раза невозможно, потому не призываю совсем отказываться от временных решений и полировать решение до блеска. Напротив, я призываю действовать, хоть и извилистыми тропами, но идти вперёд. Внедряя временные решения, делайте это с осознанием того, что они закрывают глаза на проблемы текущего дня и ограничивают ваши возможности в будущем. Потому каждый раз, когда вы делаете временное решение, сразу планируйте его переработку на целевое решение. Не откладывайте переделку в долгий ящик на неопределённый срок – закладывайте изначально рефакторинг системы в план её развития.
Чтобы вам ни говорили проектный менеджер или клиент, вы, как архитектор, должны настаивать на выделении стабилизационных итераций.
Помните: проявив малодушие в начале пути, в
конце вы окажетесь виновным в провале проекта! Всегда держите в голове тезис
«временные решения – зло», а зло должно быть наказано и как можно быстрее.
Правило 3. «Не будь пассивным участником»
В 2013-2014-ом годах почти сразу после внедрения CRM в крупном телеком-операторе, меня позвали на проект внедрения этой же системы, но с небольшими модификациями (также телеком). Изначально мне и моей команде отвели роль по настройке системы и сбору бизнес-параметров (сегменты клиентов, типы договоров, типы SLA и прочее). В отличие от предыдущего проекта, который мы делали по SCRUM, эта система внедрялась по Waterfall и все дизайны были написаны, а доработки согласованы. По факту оказалось, что не все так гладко и одной настройкой не обойтись - в итоге родились несколько сложных, интересных задач, а также новые полезные уроки. Об одном из самых ярких, название которого я вынес в заголовок, я и хочу рассказать.
После того, как клиент понял, что мы можем не только собирать бизнес-параметры, но ещё и проектировать систему, нас быстро засосало в водоворот проектной и корпоративной деятельности. Писем и встреч стало так много, что приходилось настраивать фильтры и, конечно же, расставлять приоритеты. Некоторые письма и встречи приходилось игнорировать, что, собственно, и привело к получению этого урока.
У нашего заказчика были разные сегменты клиентов: от физических лиц до государственных органов. Для работы с государственными органами были выделены отдельные специалисты и даже телефонные линии. По понятным причинам, телефонные номера колл-центра для государственных органов не афишировались, а, значит, всегда были те государственные представители, которые не находили выделенный номер телефона и звонили со своим запросом по общей линии, опубликованной на сайте. Обычным операторам категорически запрещалось работать с такими клиентами и даже просматривать информацию о них: при поступлении такого звонка, они должны были максимально оперативно перевести его на специализированную линию.
Для того, чтобы оператор случайно не начал обслуживать такого клиента, заказчик решил разместить баннер, который сразу показывал бы оператору, что работать с этим клиентом нельзя. С этого и начались вопросы и обсуждения: «что это за баннер?», «какого он должен быть размера?», «куда в системе его можно поместить?». К дискуссии были подключены поставщик CRM, дизайнеры, менеджеры клиента, аналитики и многие другие. В конечном итоге, оно свелось к обсуждению двуглавых орлов, флагов России, орлов на фоне флага, изображений Белого дома, и так далее. Примерно через 3 недели терпение у всех закончилось и было принято решение собрать большую очную встречу, чтобы окончательно принять решение по баннеру.
На эту же встречу пригласили и меня.
Я, как обычно, был занят и потому читал почту и сообщения, параллельно прислушиваясь к разгорающемуся скандалу вокруг. В какой-то момент все горящие задачи кончились, я закрыл крышку ноута и поднял голову. Представитель заказчика уже раздражённым тоном объясняла важность размещения максимально большого баннера в CRM и сетовала на то, что такая дорогая и крутая система не может поддержать увеличение блока до нужных им размеров.
В этот момент я решил вклиниться в разговор:
Я: «А в чем суть этого баннера? Если позвонил клиент из государственных органов, оператор может его по каким-то вопросам консультировать или всегда переводит на менеджера?»
Заказчик: «Нет, обслуживание категорически запрещено, он даже не имеет права смотреть данные клиента. Мы потому и просим сделать баннер таким большим, чтобы он его точно заметил и сразу предложил перевести клиента»
Я: «А у этих клиентов есть явный признак того, что они относятся к государству?»
Заказчик: «Да, конечно, все такие клиенты имеют чёткий сегмент – государство и эта информация всегда присутствует на профиле клиента. Собственно, по наличию этого признака мы и хотим выводить баннер»
Я: «Вадим (архитектор поставщика CRM), я же правильно помню, что мы можем привязать ролевую модель доступа к любому признаку на карточке в системе?»
Вадим: «Да, конечно, ролевая матрица может быть завязана на любой бизнес-параметр»
Я: «А почему тогда не привязать просмотр карточки к ролевой модели? Если обратился клиент с признаком «государство», то мы проверяем наличие на роль оператора права на работу с государственным сегментом. Если такого права нет, то экран просмотра данных клиента блокируется всплывающим окном, на которое мы выводим сообщение «Внимание! Клиент относится к сегменту государство, обслуживание категорически запрещено. Предупредите клиента и переведите на линию обслуживания клиентов государственного сегмента». Выводим телефон персонального менеджера, который привязан к этому клиенту и общий номер линии, который мы всё равно храним в профиле каждого сотрудника».
Наступила тишина… Спустя полминуты представитель заказчика, повернулся к Вадиму и спросил: «Вадим, а что, так можно сделать?»
- «Да, без проблем, все данные уже есть, нужно только немного доработать систему и реализовать всплывающее окно. За неделю сделаем, но не в этот раз, потому что текущий релиз уже согласован и отправлен в работу.»
Из этой ситуации я сделал для себя вывод, что, если бы я сразу включился и проанализировал, что требуется заказчику, а не впал в столь комфортную модель транзакции – нужен баннер, нужен и хорошо, скажите какой. Мы могли не тратить этот месяц на пустую переписку, не тратить ресурс кучи людей, часть работы которых точно пойдёт в стол – я обо всех эскизах дизайнеров. Мы могли сразу описать это решение и даже реализовать в ближайшей итерации, а не откладывать такую нужную и простую доработку на 2 месяца.
Конечно, я оправдывал себя, что задач было слишком много и до этой я добрался только тогда, когда появилось время: у меня были другие приоритеты, а у заказчика - аналитики, которые тоже должны были думать. Правда состоит в том, что я не стал вникать и поддался искушению затеряться в большом коллективе в ожидании, что проблема решится сама, и в глубине души надеясь, что меня в обсуждение этой задачи включили просто «до кучи».
Правильным, конечно же, было бы не участвовать в коллективном прожигании времени, а выяснить суть запроса, определить приоритет для проработки и отказать в участии в работе над этой задачей.
Тогда у заказчика появилась бы возможность определить для себя, насколько эта задача важна для него здесь и сейчас, обратиться к менеджеру проекта и запросить перераспределение задач моей команды. В том случае, если эта задача оказалась бы в самом деле критичной, я смог бы переключить на неё внимание, а менее срочные задачи отнести в бэклог.
Позже я не раз убеждался, что пассивное присутствие без действий приводит к печальным последствиям. Лучше отказать в решении проблемы и поработать с возражениями, чем делать вид, что ты пассивно участвуешь в её решении.
Правило 4. «Ешьте слона по частям: люди боятся больших задач»
Разбивать крупные задачи на мелкие, при этом не теряя видения — это целое искусство, речь о котором пойдёт в следующих главах. Большие задачи могут наводить просто животный ужас на людей, которые не просто откладывают их выполнение на все максимально далёкий срок, а даже не приступают к попыткам разделить слона на части.
Одна из таких историй произошла со мной и моей командой в 2014 году.
У нашего заказчика была старая система, которую внедрили более 10 лет назад, и за это время она успела крепко пустить корни в организации. Система не только была по самые уши обвязана интеграциями и кастомным кодом, который в некоторых местах оставил едва различимый хребет коробки, но также скопила в себе большое количество данных.
Далеко не все эти данные были ценны, потому целесообразность их миграции была крайне сомнительна, однако, для упрощения процесса, данные готовились к переезду без особого анализа. GiGo (Garbage In Garbage Out) был легализован руководством проекта во имя получения должной скорости реализации. Несмотря на это, один из типов данных оказался настолько огромным, что колоссальная стоимость его миграции все-таки заставила руководство заняться решением этой проблемы.
Это были данные типа «Notes» - текстовые заметки, привязанные к карточке клиента, в которых (по задумке поставщика системы) можно было хранить особую информацию о клиенте, которой не нашлось места в типовой модели данных. Записей было около 80 миллионов, и никто не горел желанием тащить их в новую IT-систему.
Заказчик долго откладывал выполнение этой задачи и, когда костёр дедлайна уже был отчётливо виден на горизонте, эту задачу просто спихнули на нас, под предлогом того, что это не миграция данных, а настройка будущей системы, и моя команда как раз отвечает за эту часть! Объёмы и сроки выполнения нас пугали не меньше, чем заказчика, но, несмотря на это, решать задачу всё равно было нужно, и мы решили съесть этого слона по частям.
Для того, чтобы понять, что хранится в этих заметках, мы попросили выгрузить нам случайные 100 тысяч записей. Проведя анализ этих записей, мы увидели несколько трендовых, часто встречающихся данных:
1. Паспортные данные клиентов
2. Информация о договоре клиента
3. Наименование дилера, продавшего контракт
4. Контактные данные персонального менеджера клиента
5. Служебные заметки (например, о возможности блокировки клиента по неоплате)
Описав данные тренды, мы попросили заказчика провести аналитику базы, по ключевым словам, чтобы понять, насколько часто подобные типы записей встречаются в БД.
Оказалось, что таких типов записей - миллионы. Мы объявили результаты своих исследований заказчику и предложили не перетаскивать эти данные, поскольку информация о клиентах была представлена в структурированном виде и это были просто копии, а сведения о заказах, менеджерах и дилерах имели риск устареть.
А дальше произошло то, что обычно происходит со всеми людьми, когда они решают провести генеральную уборку и выкинуть лишний хлам. Мне это нужно, подожди выбрасывать вдруг соседям пригодится, 10 лет лежало и не мешало, пусть ещё 10 лет полежит и так далее.
Как и в случае с генеральной уборкой, у нас начался торг.Сначала мы решили избавиться от совсем уж старья.
Ограничив срок создания записей временными рамками, мы смогли отсеять большой кусок базы, который был старше 5 лет, а затем повторяли эту процедуру ещё несколько раз: брали сотни тысяч записей, проводили анализ, готовили тренды и принимали совместные с заказчиком решения о судьбе этих записей, постепенно добавляя сутевые фильтры.
Выполняя эту работу, параллельно мы, все-таки, сужали критерии актуальности записей, которые не были приняты в первую итерацию. В итоге мы остановились на 15 миллионов записей к миграции. Дальнейшее исследование трендов приносило (в лучшем случае) десятки тысяч записей: анализ становился все более точечным и требовал больших аналитических затрат. Принцип Парето в действии – 20 % данных, начали требовать 80 % усилий.
Цифра в 15 миллионов уже устраивала всех, а тратить ресурс на дальнейший анализ было признано нецелесообразным, потому, остановившись на этом, мы сдали задачу и переключись на другие: в этом день мы стали героями и нас публично похвалил руководитель проекта.
Секрет нашего успеха зиждился на принципе, описанном в названии этой главы – «ешьте слона по частям». Большие задачи пугают своей массивностью и потому люди склонны не делать их, ожидая, что либо задача отвалится, либо найдётся тот, на кого её можно переложить.
Потому каждый раз сталкиваясь с огромной задачей, старайтесь найти небольшую ниточку, за которую можно потянуть, а потом ещё за одну, пока не распутаете весь клубок. Не бойтесь ошибиться: иногда ниточка оказывается канатом, тогда нужно оставить его в покое и искать другую зацепку.
Главное в этом деле - не поддаваться отчаянию, не убеждать себя, что задача должна быть выполнена за один раз, а иначе никак. Я ещё не видел больших задач, которые никаким образом нельзя было бы разделить на части. Да, бывают такое, что не каждая составная часть решения приносит понятный и ценный результат, но это история про видение далёкой цели, а никак не про декомпозицию.
Правило 5. «99,9 % результата — это отсутствие результата»
Все на том же проекте по замене CRM, перед моей командой встала задача настройки правил маршрутизации заявок по очень сложной схеме определения ответственного подразделения. Суть задачи была в том, что от первичного справочника тематик обращений на 10 тысяч строк зависели 2500 тысячи тематик классификации заявки. Те, в свою очередь, имели определённую схему маршрутизации по ответственным подразделениям, а вместе все это накрывалось ролевой моделью доступа к заявкам по заданным параметрам.
Особенностью данной работы стало то, что все эти правила требовалось сводить в Excel в виде строки с множеством параметров для каждого правила и делать конкатенацию значений по шаблону, который был понятен системе потребителю. После чего файл передавался в подразделение заказчика, который загружал его в систему и там это файл проходил валидацию: сначала на целостность структуры правил, а затем коллеги с помощью скрипта создавали все типы заявок и проверяли, что оказались ли те в нужном подразделении и доступны ли пользователям, имеющим соответствующие права. При этом доступ к тестовому контуру нам не давали по каким-то «соображениям безопасности». Файл получился монструозно-огромным и обрабатывать его приходилось с помощью функций ВПР, скрипов и функции конкатенации.
Представители заказчика были крайне недовольны возникающими ошибками и необходимостью чистить тестовую БД от ошибок. В итоге это недовольство вылилось в прямое распоряжение от руководителя проекта сделать файл в целевом виде и только после этого выдать на загрузку. Сложности ситуации добавляло и то, что в процессе настройки этой выгрузки представители бизнеса находились в процессе осознания зон ответственности и перенастройки маршрутизации под новые функциональные обязанности подразделений.
Менялись тематики обращений, ответственность подразделений и права доступа пользователей. Все это вынуждало нас менять файл с правилами, что воспринималось представителями IT как ошибки загрузки. В предоставлении нам доступа в тестовую среду для отработки всех замечаний и выдачи конечного результата в очередной раз было отказано.
В итоге, порезав слона по частям, мы организовали серию встреч с бизнесом, где проходились по части строк и выверяли правила маршрутизации. Спустя определённое количество итераций мы, наконец, закончили эту работу и файл был готов к загрузке. После напряжённых недель работы по 12 часов в сутки, мы отдали файл на загрузку и очень гордились нашей работой.
Файл был принят к загрузке, и мы приступили к другим горящим и сложным задачам. Уже через два дня на общей встрече я получил крайне негативный фидбэк по файлу от менеджера проекта, который звучал следующим образом – файл не был загружен по причине множества ошибок.
Я был публично отшлёпан, а в риски проекта была добавлена высокая вероятность срыва его сроков по причине неготовности настроек системы. При том, что настройка всей остальной части системы и выполненная задача по миграции данных, описанная выше в главе «Ешьте слона по частям» в расчёт не принималась.
На «статусе» проекта был приведён пример ошибки и больше никаких деталей представлено не было. Я отправился выяснять подробности к руководителю IT-службы, выполнявшего настройку вне рамок статуса проекта. Пообщавшись с ним, я узнал, что «пример» на самом деле оказался единственной ошибкой. Они получили ее в процессе загрузки примерно на середине файла и не стали продолжать, решив, что раз есть одна, то будут и другие. Вердикт был следующий: перепроверяйте файл и приносите без ошибок.
После этого моя команда проверила файл вдоль и поперёк, мы провели множество тестов средствами Excel, загрузили файл в Microsoft Access и провели там ряд тестов. Ошибка, представленная на «статусе», была единственной на несколько сотен тысяч строк. Исправив её, мы отдали файл на повторную загрузку. Недовольный начальник IT-подразделения, сказал, что, если опять будут найдены ошибки, то будет поставлен вопрос о штрафе всей команды.
На этот раз загрузка прошла чисто, мы выдохнули, передали файл в его подразделения и закрыли для себя данную задачу. Дальнейшее обновление этих параметров теперь должно было вести это подразделение.
Забегая вперёд, хочу сказать, что последующие обновления системы через этот файл привели к множеству ошибок и проблем: в итоге они привели к отказу от загрузки файлов и переходу на модель настройки и тестирования правил маршрутизации бизнес-пользователями системы.
Я же до сих пор считаю, что при работе с такими объёмами и без доступа к тестовой среде, мы сделали свою работу на «отлично». Все же, из этой ситуации я вынес правило: «99,9% процентов результата — это отсутствие результата». Чтобы вы не делали и как близко не подошли бы к успеху, всегда держите это правило в голове и доводите дело до 100%.
