Правило 19. Контролируйте только важное

В любой деятельности (и ИТ не стало исключением) рано или поздно возникает проблема контроля за изменениями. С этим сталкиваются не только большие корпорации, но даже маленькие и передовые стартапы.

Происходит это естественным образом, потому как бесконтрольные изменения в какой-то момент превращаются в хаос и неразбериху и начинают мешать делу двигаться вперёд, что хорошо описано в знаменитой басне Крылова - "Лебедь, рак, да щука".

Команды начинает лихорадить между двух крайностей:

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

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

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

Наглядный пример методология PM Book, которая заявляет, что является общей методологией для любых областей и любых проектов.
Я проходил этот курс мимоходом, слышал такие заявления, но так как проходил мимо, не сделал на этом акцента.

А вот мой друг и коллега видел себя как руководителя проектов, потому относился к этой идее серьезно и даже верил в её правдивость. Спустя много лет после окончания ВУЗ и работая архитектором, он, как и я, находит эту идею не просто бесполезной, но ещё и вредной. И это мнение подкреплено многолетней практикой наблюдений за различного рода менеджерами в ИТ, которые в лучшем случае выглядят комично и нелепо в своих действиях и высказываниях.

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

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

Для этого мы назначили первую рабочую встречу в формате брейншторма, небольшим кругом экспертов в архитектуре и методологии. РП одного из вверенных мне проектов устроила целую истерику в общем чате с нашим общем руководителем на тему того, что мы не командно поступили, не позвав её с собой на эту встречу, утаиваем информацию и так далее. Её присутствие на встрече было бы пустой тратой времени, так как она не разбирается в ИТ, архитектуре и методологии. Об этом я ей и сказал, в мягкой форме, тем самым вызвав ещё один поток "праведного гнева".

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

Вторая крайность возникает вследствие перегибов тотального контроля. Я не беру в расчёт стартапы и молодые команды, которые быстро бегут вперёд и не испытывают трудностей в контроле изменений не потому, что их мало. Тут как раз наоборот, изменений в таких командах в разы больше, чем у стабильного "энтерпрайза".

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

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

При этом рассказал, что другое "временное решение", придуманное мной и системным аналитиком за 15 минутный перерыва между большими совещаниями, продолжает успешно работать и ожидает, когда оно будет сломано и заменено, "хорошо продуманным" (уже полгода проектируемым) и целевым решением.

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

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

В итоге появляются лидеры-повстанцы, которые учатся обходить официальные процедуры и при этом добиваться огромного успеха, тем наглядно показывая бессмысленность и вредность бюрократии.

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

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

Важные вещи начинают выпадать из поля видимости, а ошибки "завтрашнего дня" накапливаются с новой силой.
Ключевая проблема заключается в том, что уже непонятно, что важно контролировать, а что нет?

Практика управления советует нам тут использовать матрицу Эйзенхауэра

Совет конечно хороший, осталось понять, что отнести к той или иной категории?

Как не удивительно, страдает самая важная категория = Важно, не срочно. Это как раз те задачи, на которые забивают больше всего, пока они не превращаются в Аааааа, всё пропало шеф! Почему мы не занялись этой проблемой, когда у нас было время?

Универсального ответа, что важно контролировать каждому архитектору дать невозможно, потому поделюсь своим личным опытом.

Как не парадоксально бы звучало, лучшие критерии контроля архитектуры я подчернул в ГосИТ:

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

Найти такие дубли бывает не просто, особенно когда нет единого описания предметной области.

Например, ведение реестра пользователей системы и учёт потребителей системы, очень легко порождают две СУБД и две команды их развивающие.

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

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

Вторым полезным инструментом будет наличие карты бизнес-процессов, описывающих цепочки взаимодействия между участниками процесса в привязке к объектам деятельности.
Очень полезным будет понимать язык владельцев бизнес-процессов, а так же понимать их зоны ответственности.
Справку 2НДФЛ вы, как правило, запрашиваете через HR портал, или даже у HR, но крайне полезно будет знать, что делает её бухгалтерия, которая работает в 1С.

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

Первая и самая простая проверка — это убедиться, что эта задача действительно попала в бэклог обеих команд, это кажется настолько очевидным, что меня можно смело назвать капитаном очевидность.
Однако, моя многолетняя практика, в том числе и в коммерческом секторе показывает, что это далеко не так. В текущем проекте, аудит ТЗ выявил расхождения в интеграционных взаимодействиях: некоторые команды просто вписали себе систему соседей, не поставив тех в известность.

Вторая, более сложная проверка — это согласованность во времени реализации. Первая проверка делается достаточно просто, нужно выписать все интеграции из системы А и сравнить наличие "хвостов" в системе Б. Но вот сроки реализации, как правило, оставляют на проектную команду.

И потом довольно часто выясняется, что команда Б предусмотрела нужный вам интерфейс, да только через 3 года после вашего релиза.Это, точки зрения коммерции, порождает срач, эскалацию, и может закончиться сдвигом сроков вашего проекта, а то и просто ничем.

С точки зрения государственных контрактов, означает его несдачу на приёмке и визит проверящих органов со всеми ранее озвучеными неприятными последствиями.

И, наконец, третий пункт. На первый взгляд кажется и совсем не про ИТ, но, как минимум, не про коммерцию, но это только на первый взгляд. Любая организация подчиняется законам страны, в которой она работает. Неважно, вы молодой стартап или крупная корпорация, при работе с персональным данными вам придётся следовать требованиям 152 Федерального закона.
Помимо внешних законов, если вы не совсем молодой стартап, существуют внутренние правила и регламенты: процедуры закупок, модель угроз, техническая политика и многое другое. Все они так или иначе накладывают ограничения на ИТ или предъявляют требования.

Набившая оскомину многим вендорам, интеграторам и органам государственного управления программа импортозамещения — ничто иное как единая техническая политика для всех органов государственной власти.

Я оставлю за скобками оценку критериев и правил, это не мешает понять общий принцип — любое решение, внедряемое в государстве, должно иметь сертификат ФСТЭК (другого органа сертификации) и входить в реестр отечественного ПО.

Тоже самое будет происходить и с технической политикой организации: допустимые языки программирования Java, C#, Python.

Можно ли написать код на Go, потому что он вам нравится, а потом удачно его встроить в ИТ-ландшафт? Ответ скорее всего будет отрицательный, а последствия для вас будут определены в других регламентирующих документах организации.

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