Вавилонская Башня. Правила IT архитектора

Коммуникации в организации, да и в жизни являются краеугольным камнем успеха. Люди, которые умеют слышать собеседников, чётко доносить свои мысли и объясняться просто и понятно всегда добиваются большего успеха, чем те, кто этого не делает. На эту тему написано много бизнес книг и приведено множество способов как развить в себе эти качества. Я считаю, что архитектор, а особенно корпоративный архитектор должен владеть коммуникациями в совершенстве. Моё глубокое убеждение — архитектор — это не самый умный человек в комнате, а коммуникатор, который способен понимать как людей из бизнеса, так и технических специалистов и выстраивать мосты между ними...

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

Разбивать крупные задачи на мелкие, при этом не теряя видения — это целое искусство, речь о котором пойдёт в следующих главах. Большие задачи могут наводить просто животный ужас на людей, которые не просто откладывают их выполнение на все максимально далёкий срок, а даже не приступают к попыткам разделить слона на части. Одна из таких историй произошла со мной и моей командой в 2014 году. У нашего заказчика была старая система, которую внедрили более 10 лет назад, и за это время она успела крепко пустить корни в организации. Система не только была по самые уши обвязана интеграциями и кастомным...

В 2013-2014-ом годах почти сразу после внедрения CRM в крупном телеком-операторе, меня позвали на проект внедрения этой же системы, но с небольшими модификациями (также телеком). Изначально мне и моей команде отвели роль по настройке системы и сбору бизнес-параметров (сегменты клиентов, типы договоров, типы SLA и прочее). В отличие от предыдущего проекта, который мы делали по SCRUM, эта система внедрялась по Waterfall и все дизайны были написаны, а доработки согласованы. По факту оказалось, что не все так гладко и одной настройкой не обойтись - в итоге родились несколько сложных, интересных задач, а также новые полезные уроки...

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

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

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