Архитектура Архитектуры. Шаг 7: Носом в пилотку

Продолжение. К предыдущим постам и карте цикла.

Знаете, что случается, когда и архитектура вроде получилась и команда подобралась нормальная? Приходит ПОЦ. Пилотная версия. Проверка боем. Да, вы уложились в сроки и даже прошли всё внутренние проверки и тестирование на стороне клиента (UAT, SIT, PPT, ETC), так что теперь вас ждёт всё более худшее – то, что не нашли. Потому что там точно что-то спрятали. Может и не вы, но в конце точно прозвучит: «доктор, это вам!».

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

Что же такое этот пробный запуск и в чём его отличие от прошлых и будущих версий? Возможно, уже ранее вам довелось что-то запустить в закрытом реалме вашего клиента. Но это было в стиле «одноразового продукта». Как латексные перчатки. Клиент их примерил, попытался покопаться глубоко в вашем тизере, а потом всё. Сняли и выкинули. Никаких отпечатков на теле предприятия. И только у вас осталось какое-то странное ощущение того, что это была нежная прелюдия.

От ощущения к осознанию.

То, что ставят в прод на этом этапе будет реально работать. Ну даже если большую часть времени работать не будет вообще. Всё равно следы оставит, пусть и из крошек. Вот этот мусор и есть наша проблема. Система будет генерировать документы, управлять станками или направлять средства. Чем бы там ваш клиент не занимался. Но это уже будет иметь физические и юридические последствия. Если в демке вы запускали конвейер, то он был в стороне от настоящего производства и всё изначально шло как тест на списание. Теперь ваш конвейер уже будет делать и полезную работу, и брак. И это будет проходить по всем отчётам. Их просто не «подправишь». А уж если у вас там интеграции с внешними системами и фискальный документооборот, то тут уж всё ясно. Данные, полученные на стадии пилота, уже никогда не покинут вашу систему. Это то, с чем вам придётся жить и уже на этом этапе необходимо продумать всю процедуру миграции от версии к версии и как приводить систему в равновесие с реальностью.

Если вам довелось проектировать распределённую систему, где каждая единица является частью целого, то тут возникает засада с накатом версий. Конечно, такие вещи продумывают заранее, но слишком часто плохо тестируют. Ну и сама идея профессионально игнорируется профессиональными менеджерами. То есть они не видят разницы между 1 рабочий офис и 20. Продолжают наивно полагать, что переустановка или обновление происходит в момент, и секунду назад всё было на версии 1.0, а потом щелчок пальцев и все на 1.1.15. Сюрпризом для неподготовленного проектировщика может стать не то, что необходимо продумать совместную работу версий 1.0 и 1.1 с хвостиком, а то, что разных версий в проде может стать много. Самый простой сценарий, который не раз уже попадался на моей практике – у клиента не все офисы одинаковые. Есть разные типы. И в них разный набор услуг или необходимого функционала. Представьте себе банк. У него есть маленькое отделение, где можно открыть счёт и вложить\снять деньги. Есть отделение побольше и там есть операции с иностранной валютой. И есть большие, центральные, где и ипотеку можно оформить и т.д. То есть 3 типовых набора функций. Клиент хочет тестировать и запускать эти 3 типа отдельно. Так как в организации, обычно, эти типы идут параллельно и управляются разными людьми. В какой-то момент они начнут накладываться и у вас будет 3 версии пилотов в проде. В каждом типе мультиверсионность (разные версии должны работать вместе). Ну а у вас на это еще накладываются бранчи с текущим релизом, будущие пару релизов и мастер под каждый тип. Нет, я не управленец и не моя болит голова по поводу количества проверочных стендов, версий в репозиториях, тестов и команд, которое растёт из-за параллельных релизов. А вот то, что изменения инфраструктуры расплываются на кучу веток и нужно помнить, что на какой стадии и где, а самое главное, как привести это в итоге к единой версии – это уже моё. Критичные вещи не будут ждать, пока очередной кусок получит даунмердж во все ветки. Надо было срочно пропатчить одну из вариаций пилота – это сделали и закинули в прод. И тут уж без конфликтов не обойдётся. И я не только про код.

Имплементация и корреляция.

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

Как результат такой политики – урезается влияние архитектора на проект, увеличивается бэклог и технический долг. И если вы не требовали и не проявляли инициативу, то код может сильно отличаться от того, что вы ожидали. Документация и диаграммы соответствуют дизайну, а вот имплементация уже утыкана костылями и может быть местами диаметрально противоположной техническим требованиям. Что страдает чаще всего – разграничение ответственностей и модульность. Где-то влили бизнес-логику в базу, где-то воспользовались одним и тем же контрактом для разных уровней, а где-то просто впихнули в один модуль функциональность трёх-четырёх. А бегать на костылях с непривычки крайне неудобно. Значит быстрые мелкие изменения, которые необходимы при запуске альфы, получаются глубокими или добавляют костылей. Доходит до глупостей. Клиент пожаловался на опечатку в тексте кнопки и саппорт радостно бежит в контрольную панель, поменять конфигурацию, но оказывается, что кнопку захардкодили. ATP и QA прошли без проблем, так как все проверяли действие при нажатии кнопки, а не то, что текст можно сменить. Тут бы помог код ревью, но в наше время эту практику избегают. Да и грамотно проверить весь пахнущий код занимает кучу времени. Поэтому предпочитают экономить время и оставить пахнущую кучу в коде. И вот либо опечатка будет висеть и бесить клиента пару месяцев до выхода следующего релиза (привязка к конфигурации затрагивает несколько модулей и будет иметь большую зону эффекта, а значит и риск), либо нужно раскидать хотфикс, где хардкодят нужный текст (такое изменение можно функционально и не тестить).

Две головы хуже.

Большие проекты делят на несколько подрядчиков. Аккуратными дорожками с помощью безмерной корпоративной кредитки. Прошлый блок был про вендор лок. Когда вы разрабатываете продукт, который не идёт в комплекте с закрытым железом, то приходится уповать на то, что ваша программа будет бежать в защищённой среде. Специалист по безопасности пишет вам харденинг. Вы, конечно, считаете, что это требование и предварительное условие. Но те другие компании из тендера, обслуживающие вашего клиента, видят в этом сопроводительное письмо с рекомендациями. У них свои проблемы и свои условия соглашения. Часто выясняется, что в реале всё не так должно быть. Доступ к системе есть у каждого прохожего, сертификат ставят везде один и тот же и вашим аппликациям дали администраторские права. Хуже всего, что ничего из этого на работоспособность вашего продукта не влияет, а значит все вроде, как и довольны происходящим. А вот когда приходит время каких то сертификаций, проверок, аудита или реальной кибер-атаки, то всё летит к бабушке гендиректора. Ну а если у вас вместо гена директора гены инженера, то стоит позаботиться об утилитах и скриптах для верификации тех самых требований к безопасности инфраструктуры. Естественно, что просто сделать проверку частью инсталяшек будет недостаточно. Сегодня всё ок, а завтра всё сломают. Необходимо регулярно мониторить. Желательно автоматом. Лучше с калибром 7.62.

Мотивация к отслеживанию чужих обязанностей простая как английский лук. Чтоб попасть своей стрелой в стрелу «партнеров». Как только случиться реальный инцидент, каждый вендор будет стараться скинуть с себя ответственность. Сначала это происходит на уровне компаний участников, а потом и внутри команды. То есть, если сольют в сети базу клиентов, то скорее всего адвокаты заказчика придут к вам. У вас же менеджеры расступятся как воды перед Моисеем открывая путь истцов прямо к вашему порогу. Архитектор координирует всех специалистов проекта. В том числе и безопастников. Доказать, что базу сняли не с живой системы, а со старых накопителей, которые не уничтожили по регламенту, а растащили по домам и на барахолку – задача не тривиальная. Особенно, если всё что у вас есть – это логи вашей системы. Помогло, что даты последних записей в базе совпали с точностью до нескольких минут с записью в журнале о прибытии техника на плановую замену диска. Так что в случае успеха ваше имя никто не узнает, а вот в случае проблем – вы знаменитость. Ну и помимо серьезных инцидентов, мелочи тоже будут кидать друг другу как горячий картофель. Необходимо доказать, что проблема не у вас, а допустим в железе или на стороне тех, кто отвечает за сеть или контроль доступа. Если ваша система перестала работать, то в первую очередь постучатся к вам, а не к тем, кто сегодня планово сменил драйвера или обновлял ось. Помните, что проблемы продукта вашей архитектуры влияют на имидж вашего клиента намного ощутимей, чем на ваш собственный (компании и личный).

Не все друзья – враги.

Но и не все друзья – друзья. В корпоративном сегменте всегда есть внутренняя конкуренция и сильное расслоение. Всё, что шло на ура в лабораториях и тестовых стендах не всегда принимается на ура в настоящей работе. Самым первым и простым объяснением таких расхождений ожиданий и реальности -те, кто заказывают музыку сами не танцуют. Требования приходят не от работников, а от эффективных менеджеров и экспертов-теоретиков. Особенно сложно, когда эксперты задают требования глобально. Граждане некоторых больших стран не всегда в курсе, что есть и другие места, культуры и стандарты. Иногда можно сразу ткнуть носом в кусок задания и спросить: «а кто у нас тут такой умный?». Вот, например, одна ритейл компания захотела, чтоб цену на продукт можно было менять «в один клик» по всей сети. Меняешь базовую цену (MSRP) и автоматом везде цена поменялась по какой-то простой формуле. На подобие «база + 3%» или «база + 1». И ты сидишь и смотришь на чудо из глав. офиса, которое тебе вещает это с умным видом по видеоконфе. И после драматической паузы начинаешь делать вступление и кидать наводящие вопросы. В стиле: «Я буду очень рад помочь такой большой компании в оптимизации бизнес процессов. Конечно, невозможно вручную контролировать все 15 000 торговых точек в 49 странах. Нам только надо обсудить технические мелочи. В какой валюте будет базовая цена, ведь почти в каждом регионе своя валюта, как будет идти расчёт для регионов с налогом, заложенным в цену, как будет округляться цена при минимальной деноминации отличной от 0.01?» И далее по списку, пока человек сам не осознает абсурдность или непродуманность задания. Что, кстати, случается далеко не всегда. Иногда звучит фраза: «Вы же тут технический специалист, вот и скажите, как сделать». Но иногда вещи не столь очевидны. Так можно получить вполне логичное требование «поднимать шлагбаум после того, как установленная на нём камера определила номер машины», а пилотку запустят в стране, где передние номера на машинах не обязательны. И потом будем «удивляться всем офисом».

По мимо оторванности от мира, часто мешает то, что клиент приходит к вам со своим видением решения, а не проблемой. Очень часто решение это основано не на логике или желании улучшить процесс, а на «так оно сейчас работает». То есть от новой системы хотят то же и так же, как делает старая. Создается ощущение, что в идеале, клиент хотел бы только обои поменять. Как бы родные грабли ближе к телу. По возможности пытайтесь избегать проектов на принципе «один в один». Все они всегда убыточные, ущербные и долгие. А такие проекты будут. Потому что заказчик боится. Те, кто пишут требования нюхали далеко не порох и поэтому всегда на измене: «вдруг что-то из старого понадобиться, а его нет». Или «понятие не имею что это, поэтому тоже добавлю». Получается, что мало кто вообще задумывает зачем это нужно и почему именно так. Стандартная ситуация – в автосалон пришёл богатый клиент, и ваш лучший продавец не позволил ему уйти без покупки. Несмотря на всю мою любовь к продажникам, иногда клиент получает лучший автомобиль за отличную цену. Вот прям всё честно и все довольны. Только потом, когда клиент в своём новом суперкаре, вместо старой лошадки, будет застревать на пашне, где он работает, он подумает, что, наверное, надо было купить трактор. Только в этом вы ему помочь никак не могли так как он изначально зашёл в магазин абсолютно другого сегмента. Давите на своих аналитиков, чтоб они искали проблемы, которые хочет решить заказчик, а не конспектировали решение, которое этот заказчик себе надумал. Иначе простой перевод в тех дизайн поведёт не так и не туда. Если это плохо дошло на ранних этапах, то во время proof of concept, обычно появляется пара хороших подтверждений данному тезису-казусу.

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

• Офис нашей компании в западной Европе начал терять клиентов и снизил уровень продаж. Это понятно – система у них старая (лет 10 отроду), все её уже знают и отсеивают по названию на первых этапах тендера. Конкурентов много и у них «модные-молодежные решения для вашего бизнеса». У нас же последняя стадия разработки (еще годик оставался) в другом регионе. И вот на этапе стратегического планирования (раз в год все представительства компании на общих заседаниях) им протягивают руку помощи. Берите наш как платформу, накидвайте свои кастомизации и через год у вас на руках тоже новый продукт. Год они изучали, требовали демки, документации, архитектуру, менторинг. Год минимизировали риски согласно принятым практикам. От конца к началу. То есть сначала решали проблему поддержки, развёртки, а лишь потом пришли к выводу, что чтобы успеть нужно было год назад нанять 2 команды разработчиков. Потом, вдруг, у них появилась новая версия их старого продукта, с какой-то до боли знакомой архитектурой и функциональностью. А наша платформа «слишком сырая» для их рынка. Так что мы им всё время только мешали, а они собственными силами и вопреки сделали вон какой рывок!

• Офис в восточной Европе. У них дела идут стабильно, но в новых тендерах появились новые требования. У них есть 3 модуля, а у нас недостающие 2. Мы же одна компания! Нам быстро обрисовывают необходимые для региона модификации. Они-то там местные и уже лет 15 на рынке. Так что всё знают. Мы быстро пилим. Они просят, чтоб полевые испытания были на нас, так как хоть модуля от нас 2, но они прям критичные, а местная команда их настолько не знает. Так что мы всё выкатываем и запускаем, а потом приходят аудиторы. Ну как бы опытные и местные «забыли» сказать, что нужна сертификация. Ну вот они там этими системами занимаются с декаду, но за несколько месяцев разработки и интеграции у них это как-то из голов повылетало. Ну и, конечно, «а вы же не спрашивали».

• Офис в Азии. Нас заваливают требованиями клиента с различными кастомизациями. Много всяких мелочей. Большинство заданий нелепые. Было лучше, но нужно сделать хуже. Например, действие можно было сделать за два клика, просят за 4. Можно выполнить операцию за пол секунды, но требуют за две и не больше 5 в минуту. Можно 6 вариантов действия, а нужно ограничить 3-мя. Наш продакт просит подтверждения от заказчика, но так как на ихнем никак, то вся корреспонденция через местный офис. И каждый раз приходит ответ, что «хозяин-барин». После полугода мы наконец выкатывем демо. И клиент, сообщает, что, пожалуй, дальше мы идём без вас.

Вам интересно почему? Потому, что контракт подписывает регион и прибыль ему. А разработка у нас – значит расходы наши. И да, если контракт разорван, то отдел продаж свои премиальные возвращать не будет. А с вашими расходами и неустойками о своих переработках можете и не заикаться. Я специально привёл примеры из разных точек, чтобы вы не посчитали это культурными обычаями или поведением какой-то конкретной команды.

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