Добро пожаловать обратно, друзья. Если вы читали первую часть, то знаете, как мы выстраивали периметр, прикрывали тылы и готовились к штурму. Теперь переходим к самому интересному — к продукту. К тому самому «цифровому космолету», который должен был перевернуть рынок пассажирских перевозок.
Но как это часто бывает в больших проектах, эпичный концепт столкнулся с не менее эпичной реальностью. Легаси‑инфраструктура с которой мы столкнулись и на которой нам предстояло строить этот самый «космолет», в реале оказалась сложнее и неповоротливей, чем мы могли себе представить. Распределённая архитектура, множество стыковочных узлов, кривые сторонние сервисы, языковые и культурные барьеры внутри команд, а главное — жёсткие рамки Waterfall. Всё это требовало не просто инженерной смекалки, а умения балансировать между интересами разных игроков, не теряя фокуса на конечном пользователе.
В этой части я проведу вас через наш интеграционный лабиринт. Расскажу, как мы собирали команду, выстраивали процессы, договаривались со стороной интегратора и проектировали идеальное API. Какой путь мы успели пробежать за 8 месяцев хардкора. И как я впервые столкнулся с «обстоятельствами непреодолимой силы». В финале я дам вам 10 правил работы с госами, которые мы вынесли из этого опыта и могут оказаться полезными, если вы окажетесь в подобной ситуации.
Если вы не читали первую часть — рекомендую вернуться. Там о том, как мы выстраивали юридическую защиту и внедряли практически полноценный Agile под маской Waterfall. Это не просто «история», это набор инструментов, который помогал нам не сойти с ума. Но если вам ближе продуктовое мясо и детали реализации — добро пожаловать прямо сюда. Читать мою историю можно в любом порядке.
Приготовьтесь, отправляемся. Следующая станция — «прод».
Дисклаймер
Данный материал является публицистическим очерком, основанным на субъективном опыте автора в области IT‑консалтинга пятилетней давности (2019–2020 гг.). Все упоминания брендов и структур (включая ОАО «РЖД» и ДОСС) приводятся в оценочных и информационных целях (ст. 1274 ГК РФ). Все приведенные графические и текстовые артефакты прошли процедуру глубокого обезличивания: оригинальные товарные знаки удалены, персональные данные вымараны, технические параметры и шифры систем изменены или сфальсифицированы с целью соблюдения b2b‑этики и защиты коммерческой тайны. Автор выражает частное мнение (ст. 29 Конституции РФ), которое не направлено на умаление чьей‑либо деловой репутации.
Оглавление
Продукт. Что же было в «проде»?
Давайте вернемся к моему телефонному разговору с «К» (так мы обозачили моего партнера по проекту в первой части статьи). Честно скажу, когда я услышал только предварительное перечисление компонентов, я прям охренел, и сейчас вы поймёте почему. Что входило в состав решения? Развлекательный центр — фильмы, сериалы, аудиокниги, музыка. Библиотека — книги в текстовом формате и партнерский контент. Букинг билетов с 3D‑турами по вагонам — ткнул пальцем в понравившееся кресло на экране и оплатил. Заказ еды из вагона‑ресторана с «пушами» на кухню. Маркетплейс с товарами от партнеров и возможностью доставки прямо к перрону или в гостиницу — мы даже с трудом представляли, как это работать будет с точки зрения логистики. А ещё карта движения поезда в реальном времени. Аудиогид. Внутренняя рекламная платформа. Личный кабинет с программой лояльности. Справочный центр РЖД. И конечно требовалась верификация пассажиров при подключении к «бортовому серверу» через «Экспресс-3».
А все это нужно было реализовать под «единой крышей». Понимаете моё состояние — я был просто ошеломлен! Я тогда подумал, что такого масштабного продукта на рынке пассажирских перевозок ещё нет. И я не ошибся. Анализ цифровых продуктов от мировых лидеров этого рынка полностью подтвердил мою гипотезу (сравнение продуктов будет ближе к концу статьи). Кроме этого, мы открыли для себя много нового. К примеру, педантичные немцы делали акцент не на развлекательных сервисах для пассажиров, а на логистике. Там доминировали приложения, позволяющие построить маршрут из точки А в точку Б с использованием N‑типов транспорта и так, чтобы нигде не опоздать. И все это в два клика. Но выделялась только Германия, у остальных всё было «по классике» — букинг и развлечения. Но это все «лирика» и не самый важный этап подготовительных работ, хотя и очень интересный. К тому же весь концепт был уже детально проработан на стороне Интегратора. Нас же намного больше волновало, с чем нам предстоит работать. Мы подписали NDA и приступили к анализу цифровой инфраструктуры. Именно с этого я и хочу начать свой рассказ. Конечно, без глубоких технических деталей, чтобы не раскрывать коммерческую тайну и не навредить компании. Ну, погнали!
Экосистема. А что у вас под капотом?
Развлекательный портал «Попутчик»
Не буду лукавить, у РЖД уже был браузерный «прототип» фрагмента описанной мною системы. Это веб‑приложение, скорее даже портал, существует и по сей день. И думаю, что сейчас все это выглядит поприличней, чем в том уже далеком 2019 году. Называется это решение — «Попутчик». На момент запуска нашего проекта «Попутчик» состоял из развлекательного центра — те же фильмы и сериалы, меню вагона‑ресторана (онлайн‑заказа на тот момент не было), карты движения состава и аудиогида. Как раз мой «К» начал своё сотрудничество с ДОСС и Интегратором с разработки именно этого компонента — аудиогида. Что такое «аудиогид»? Все предельно просто. Во время движения поезда система отслеживает GPS‑координаты и если в ближайшей локации есть какая‑то «достопримечательность», приятный голос вам о ней расскажет. Сделано это было под «Сапсан». Объекты выбраны были вручную, согласованы, временные отрезки строго вымерены, чтобы ничего нигде не наслаивалось. Начитка тоже была живой, а не роботизированной. Этот вполне завершенный качественный «микросервис» был вшит, как веб‑компонент. Но, сами понимаете, по сложности реализации все это было очень далеко от описанной мною системы. И собрать такого «Попутчика» значительно проще, чем реализовать полноценную экосистему с пользовательским интерфейсом в виде мобильного приложения под две платформы. Не говоря уже о том, что непосредственно публичная часть продукта, то есть сам «портал» работал на… Ну, кто работал с «легаси» от «госов» уже бубнит про себя: «Сто пудов это пыха…» Да‑да, всё это великолепие работало на PHP.
Необходимо отметить, что «Попутчик» не был «монолитом». Его архитектура представляла собой распределенную систему, разделенную на «бортовой» и «береговой» сервера. На «бортовом» крутилась «веб‑морда» и статика. Этот «холодный» сервер с минимальной нагрузкой был вотчиной интегратора. Я хоть и смотрел на этот весь «колхоз» с некоторым недоумением, но не считал использование PHP каким‑то грехом. Его использование для этого фрагмента решения было вполне ожидаемо и даже обосновано. Что же касается бизнес‑логики, которая находилась на «береговом сервере», то там совсем другая история. Это был полноценный корпоративный хардкор на Java, который (если не ошибаюсь) «писала» эстонская команда, имевшая за плечами опыт работы с «Люфтганза». Там была система управления настройками системы, генератор JSON и конструктор для создания контейнеров с контентом. Эдакий специализированный CMS.
Как вы понимаете, эти части решения могли существовать независимо друг от друга. Синхронизация данных происходила в период, когда поезда проходили «экипировку». Конечно, не каждый раз, а только при наличии обновлений. В составах использовался обычный мобильный интернет с лимитированными тарифами. Мне всегда было интересно, как происходила эта покупка симок. Ребята «от интегратора» называли процесс замены симок «Перезарядить Интернет». Забавно! Независимость программных компонентов или «слоев» позволяла добавлять промежуточные решения и «костыли» для дополнительных манипуляций с контентом. Вот, к примеру, «дирекция» захотела свой «фирменный» плейлист в аудиоплеере. Такого модуля в эстонском CMS не было. Но, так как все данные статичны, написать микросервис для генерации списка композиций не сложно. Это и плюс, и минус. С одной стороны — все прекрасно, и можно быстро решать любые задачи без привлечения дорого субподрядчика из зарубежья. Но есть и «темная сторона» — с каждым эволюционным витком «костылей» становится все больше и больше. И в определенный момент можно утонуть в этом море… Сами подберите политкорректное слово! К тому же, я очень сомневаюсь, что все эти решения были нормально спроектированы и реализованы. И что где‑то хранятся «спеки» к ним.
Обмен данными. А что с «апи»?
У «Попутчика» также уже существовало RestAPI. С большой вероятностью клиентская «веб‑морда» унаследовала его от эстонской разработки, лежащей в основе «берегового сервера». «Апи», которое нам представили, затрагивало исключительно Развлекательный центр. Для версии «Попутчика», которая существовала на тот момент, этих данных было достаточно, но для «Приложения», которое нам предстояло создать, это был всего лишь куцый фрагмент. Тот же Развлекательный центр в своей новой ревизии должен был состоять из большего количества компонентов со сложной механикой. Рекомендательная система и персонализация ленты — значит нужно писать логи просмотров контента по каждому пользователю. Возможность автономной работы вне состава и без Интернета — а это значит требуется предиктивное кэширование. Конечно, речь шла о работоспособности Приложения без доступа к просмотру контента — это возможно только на борту. И, понятное дело, существующее RestAPI не обладало всем этим функционалом. Стоял вопрос о его серьезной модернизации.
Задачку по проектированию совершенно нового RestAPI “подкинули” нам сразу же после аудита экосистемы. Проект эпический, и мы понимали, что от нас ждали в буквальном смысле чудес. И я сразу же привлек одного из своих самых сильных архитекторов.
Важная ремарка. Несмотря на то, что все мы подписали NDA, Интегратор очень осторожничал, и мы получали информацию о том, как по факту работает экосистема РЖД маленькими порциями. Во время аудита нам буквально приходилось многое додумывать, реконструировать и задавать уйму вопросов. Ответы же, порою, были весьма туманными. В итоге мы просто сели и спроектировали API с нуля таким, каким хотели его реализовать сами, опираясь на «хотелки» заказчика. Как вы могли заметить, для реализации некоторых уже озвученных функций требовалась двусторонняя связь. Конечно, глобально перерабатывать фрагмент данных, связанный с Развлекательным центром, мы не стали. Не хотели портить отношения с командой Интегратора, ведь именно на неё свалилась бы эта задача со стороны реализации «бэк‑энда». Там мы только немного доработали «контейнер» и добавили одну дополнительную секцию. Да, многие сейчас скажут: «Что вы творите? У вас же холодный сервер на борту…». А те, кто уже «женился с госами» воспрянут: «Ха! Так вот именно тогда они об этом и узнали!» И будут совершенно правы! Именно тогда мы и узнали реальную конфигурацию серверов в составе. Тем не менее, «хотелки» были уже «проданы» высшему менеджменту ДОСС, их никто не отменял, их нужно было как‑то делать. И мы решили, что схема будет работать так: сначала Приложение накапливает данные и только потом отправляет их на сервер, но только не на «бортовой», а уже «береговой». Конечно, для этого необходим дополнительный «бэк» на стороне «берегового» сервера. Но, извините, «персонализацию контента» не мы предложили внедрить, наоборот — мы продумывали API, опираясь на этот требуемый функционал. И именно из‑за этого закладывали двустороннюю связь. Так что это была уже не «наша» проблема, а наша общая с Интегратором задача. И хорошо, что все подобные навороты мы предусмотрительно сдвинули в самый конец нашей «дорожной карты». Её я вам тоже покажу, но немного позже, кому невтерпеж — вот она.
А что ещё? Third‑party services
Кроме «берегового» и «бортового» серверов требовалась интеграция нашего Приложения ещё с несколькими «стыковочными» узлами. И если «маркетплейс» и «вагон‑ресторан» находились в нашей с Интегратором «юрисдикции», то было ещё, как минимум три компонента, которые были за его пределами. Таким дополнительным геморроем для нас был «букинг», «3D‑просмотр» вагона и авторизация пользователей на борту.
Для покупки билетов у РЖД уже было приложение, и оно отлично работало. Но почему‑то Интегратор требовал, чтобы мы подключили наше приложение к другому API и другому юрлицу, ссылаясь на антимонопольный комитет, с которым были какие‑то трения по вопросу монополизации рынка ж/д билетов. Ну, наше дело малое — мы субподрядчики, что просят — то и делам. Вот только это «левое» API в буквальном смысле было «левым», опять какая‑то «пыха» и передача данных методом GET со всеми вытекающими... Ну, вы представляете наш шок! Это был какой‑то мелкий субподрядчик, и мои ребята начали «бодаться» на тему полной переработки кода на стороне поставщика этих услуг или полного отказа от работы с ним. И какое счастье, что мы могли сослаться на общие требования к безопасности ПО, разработанное ВНИИЖТ. Так что эта проблема для нас либо полностью снялась, либо отсрочилась. Интегратор пошел сам разбираться с этим вопросом.
Вызов «3D‑просмотра» вагона должен был стать органичной частью процесса «букинга». Понятное дело, что с «2D‑видом» никаких проблем не было. Конечно, его реализовать — кропотливая работа, но она прозрачна и понятна с технической точки зрения. А вот интерактивный «3D‑вид» — дело другое. Этот компонент был реализован сторонней командой (другим субподрядчиком) как SPA‑приложение. Которое подкинуло нам настоящий «квест». Как «ловить» данные о выборе места из «WebView» в Приложении? Ситуация осложнялась тем, что это было классическое веб‑приложение, и при выборе места страница не перезагружалась. Менялся только хеш в URL, на что стандартные методы делегата WKWebView попросту не реагировали. Интегратор со своей стороны лишь разводил руками: «В браузере всё кликается, остальное — ваши проблемы». В какой‑то момент, не найдя с ходу готового рецепта, мы в отчаянии даже начали присматривать легкие игровые движки, чтобы собрать вагоны «на своей стороне». Конечно, это была полная утопия, но мы были в отчаянии.
В итоге мы вместе с архитектором закопались в Apple Developer Documentation. Нужно было найти способ «зацепиться» за динамическое изменение URL в реальном времени. Решение нашлось на стыке технологий. Мы использовали механизм Key‑Value Observing (KVO) для наблюдения за свойством URL‑адреса. Это позволило приложению мгновенно «слышать» изменения в адресной строке «WebView» и «ловить» ID выбранного кресла.
С этим разобрались. Теперь про авторизацию и безопасность. Согласно протоколам безопасности «бортовой» сервер не должен хранить никаких персональных данных пассажира. Поэтому при идентификации бортовой сервер играет роль Gateway‑шлюза. При подключении пользователь должен пройти идентификацию. Он вводит фрагмент своих персональных данных, если не ошибаюсь, то тогда это были Фамилия + последние 4 цифры номера документа. Данные отправляются для сверки на сервер «Экспресс-3». Сервер возвращает «флаг». При положительном результате пользователь получает доступ к сети. При отрицательном — данные запрашиваются повторно. Все достаточно просто. По крайней мере, такая схема была в 2019 году. Но, так как клиентский запрос звучал, как «бесшовный вход», то эти данные необходимо хранить непосредственно в Приложении. Технически это означало, что наше приложение из «простого клиента» превращалось в хранилище персональных данных. А это тянуло за собой целый ворох проблем, с которыми нам предстояло разбираться на финальных стадиях разработки. Но об этом позже, а сейчас про команду.
Команда, процесс и множество компромиссов или как мы пытались катить Agile по рельсам Waterfall‑а
Как я уже упоминал, команду нужно было собирать «с нуля». На самом деле, это одно из самых увлекательных занятий для меня. Я люблю заниматься «скаутингом» и собирать «команды мечты». Да, это адский труд и подобности этого кропотливого процесса достойны отдельной статьи, особенно, если рассказывать про мою методику. Здесь же я вкратце расскажу вам о своём организационном методе, так как это непосредственно связано с работой над проектом и может быть кому‑то полезно.
Я всегда предпочитал работать в формате, который сейчас называют «проектный офис». Что это? Это команда, собираемая под отдельно взятый проект или задачу. В чем особенность? Как правило, это распределенные команды, которые работают «на удаленке». Концепт этот существует давно. Но до пандемии это была скорее редкость или вотчина фрилансеров, нежели отраслевой стандарт. Отдельно хочу отметить, что фриланс — это не просто модель заработка, это стиль жизни, отношение к работе и личному пространству. Вернее даже попытка добиться какого‑то баланса между всем этим. Да, далеко не каждый фрилансер командный игрок, и ещё меньше из этих командных игроков ответственно подходит к дэдлайнам и бережно относится к остальным участникам команды. Собрать таких непросто! Поэтому за годы я наработал небольшую базу людей, которые по комплексу софтскиллс/хардскиллс мне подходят и, в принципе, совместимы между собой. Также я научился определять подходящих мне специалистов практически с первого взгляда. Ну, с минимальной погрешностью, так это назовем.;‑) В этих командах могут быть разработчики всех рангов — от «джунов» до «тимлидов». И, конечно, чем выше ранг, тем ответственней задача и больше моя личная ответственность за человека. Во всех проектах задачи «верхнего уровня» я всегда решаю коллегиально со «своими» архитекторами. Все крутые архитекторы всегда заняты — будь то найм или какие‑то частные подряды. Заполучить их чертовски сложно. Поэтому я работаю уже долгие годы с одними и теми же людьми, оплачивая им «повременку». Для них — это возможность иметь дополнительный доход, не отвлекаясь от своей основной деятельности. Для меня — получать высокое качество решения сложных задач без раздувания бюджета. Всем выгодно, всем комфортно! Конечно, такие отношения возможны только при очень высокой степени доверия. Но это уже издержки!
Наверное, подробный рассказ о том, как я собираю команды и управляю ими, достоин отдельной статьи. Если вам интересна эта тема — напишите об этом в комментариях.
Проект с РЖД не был исключением. Я собрал команду согласно этой своей «золотой формуле». Чтобы дополнительно подстраховаться мы с «К» решили официально «втащить» всех ключевых игроков в его «ооошку». Оформляли их на полставки, чтобы они не беспокоились, что теперь они «в найме». Самые дотошные попросили оформить их на ¼ ставки. Да без проблем! С подрядчиками, которые нужны нам были разово или на очень короткую дистанцию разбирался я. Вот такие юридические взаимоотношения мы построили с нашей командой.
Модель рабочих взаимодействий с клиентом была такая: «К» общался со стороной заказчика лично, а нам поступали уже протоколы решений. Если мы с чем‑то были не согласны — мы направляли официальную «депешу» и инициировали диалог с командой разработчиков Интегратора. Весь проект «жил» в GitLab на стороне Интегратора. А мы, будучи адептами здоровой паранойи, «зеркалили» всё у себя и бережно коллекционировали скриншоты.
Работали короткими недельными спринтами, классические «Daily» не проводили принципиально — только «Refinement» и то два‑три раза в неделю. Не буду говорить, что все шло идеально — проблем было выше крыши. Мы с «К» постоянно находились «в нерве» и были заняты какой‑то рутиной бумажной работой. Поэтому нередки были ситуации, когда «рефайменты» сводились к созвону Тимлида мобильной разработки с Архитектором, который контролировал разработку всей экосистемы и ставил задачи через GitLab команде Интегратора. Самое веселое начиналось после созвонов. Если сессия не задалась, оба участника по очереди перезванивали мне, чтобы пожаловаться друг на друга. Причем, каждый был по‑своему прав. Если ситуация оказывалась сложной, нам с «К» приходилось все бросать и «разруливать». Эдакая медиация…
Было непросто. Иногда дело доходило до абсурда. Я помню одну ситуацию, когда у Тимлида была претензия к Архитектору по поводу того, что тот якобы некорректно поставил задачу команде Интегратора. И теперь часть функций сместилась на приложение. В двух словах. На стороне приложения необходимо было на лету производить некоторую декомпозицию. Задача, в принципе, не сложная. Но это, понимаете ли, «не элегантно». Даже прозвучала достаточно обидная фраза:
«Он, наверное, API впервые разрабатывает…»
Это про Архитектора… В чем был его грех для Тимлида? Он «разрешил» разработчикам Интегратора скидывать нам свой «фирменный» плейлист «Сапсана» практически в формате «AS IS». Чем вызвал просто бурю негодования со стороны нашей команды Приложения. Архитектор молча стерпел эту волну эмоций и ответил:
«Если я поставлю ИМ задачу сделать как надо, то сколько мы будем ждать? Это не день‑два, это минимум неделя, а то и больше! Я считаю, что проще модифицировать данные на нашей стороне, чем рисковать сроками сдачи компонента.»
Все, больше вопросов у Тимлида не было.
Работа должна была идти в несколько этапов. Каждый должен был заканчиваться актом приема‑передачи. Через полгода появлялся второй параллельный поток — разработка под Android. Снаружи для заказчика процесс должен был выглядеть, как Waterfall, а внутри для нашей команды, как Agile. Но об этом я уже вам рассказал в первой части, здесь просто напоминаю. А вот «дорожную карту» я вам покажу, как и обещал ранее, но сначала напомню порядок работ.
Итак, первым этапом был масштабный «аудит», далее расчет сметы проекта и подготовка ЧТЗ. Затем проектирование «волшебного API» — опять аналитическая работа. И только после этого начиналась разработка. В первую очередь нужно было реализовать интерактивный прототип с конечными экранами Приложения. Это «демо», где какой‑то «верхний» функционал работал, а где‑то были просто наспех собранные экраны под WebView или даже просто скриншоты конечных экранов. Отдельно хочу обратить ваше внимание на это. Сборка подобного прототипа — это уже устоявшаяся практика работы с госсектором. Да, наверное, уже и не только с ним. И, если кому‑то это снимет головную боль и добавит «траста» выбранному субподрядчику, то почему бы и нет? Главное, чтобы часы были оплачены. И только после этого начиналась «настоящая» разработка самого Приложения. Сначала под платформу iOS, а через 6 месяцев — параллельный запуск разработки под Android. К этому моменту все вопросы по API на стороне Интегратора должны были быть закрыты. Все «заковыристые» моменты уже пройдены первой командой. Ожидалось, что разработка под вторую платформу будет идти в ускоренных темпах. Но мы этого так и не узнали…
Конечно, все основные этапы работ были разделены, как по времени, так и юридически. Многое изменялось и корректировалось прямо в процессе и шло доп. соглашениями. Это касается и отдельно взятых фич, и сроков и нюансов взаимодействия со всеми привлекаемыми со стороны контрагентами. Из‑за чего нам приходилось все документировать и отражать на собственной доске в Трелло. Не могу сказать, что это не раздражало команду, но это был единственный способ удержать контроль.
Эпический финал. Что успели реализовать до заморозки проекта?
Врать не буду, разбираться в архиве проекта, чтобы вспомнить детали было достаточно долгим и болезненным занятием. Но неожиданно для себя, вместо горечи за резко свернутый проект, на меня нахлынули приятные воспоминания. Как же это все было круто, и какая классная и интересная команда тогда собрались. Думаю, многим знакомы подобные чувства… Ну, да ладно, к делу.
Мы двигались бодрым темпом несмотря на то, что команда была небольшой. Я принципиально не люблю большие команды. Считаю, что у каждого проекта есть порог, где линейное увеличение штата не приводит к соизмеримому увеличению скорости разработки. Скорее, даже наоборот. В таких случаях лучше дробить задачи и распределять их между небольшими относительно независимыми командами.
На момент «временной приостановки» работы над проектом, которая состоялась примерно в разгар первой волны пандемии, мы проработали уже почти 8 месяцев. Все подготовительные работы и «демо» были позади. Мы успешно прошли болезненный фрагмент совместной доработки API и уже не отвлекались на утомительные согласования. «Развлекательный центр» был полностью реализован. Прошли все тесты на борту. Полностью собрали клиентскую часть «букинга» в Приложении, придумали, как «ловить» выбранное место в 3D‑просмотре, провели все локальные тесты по данному компоненту. Подключили «витрину» вагона‑ресторана, но пока в формате WebView. Наметили архитектуру «Маркетплейса». Собрали «Личный кабинет» (с РЖД‑Бонус), но пока без авторизации, и внедрили примитивный прототип рекламной платформы — можно было управлять баннерами на «Главном экране» Приложения.
Из‑за сложности экосистемы, нескольких подключений к Third‑Party‑Services, а также жонглированием — «тестовый сервер», «береговой сервер», «бортовой сервер» и прочие неоднозначные вещи с точки зрения аудита по безопасности со стороны AppStore, мы вынуждены были отказаться от распространения «беты» через «песочницу» Apple. Конечно, можно было списаться с поддержкой AppStore, представить копии всех договоров (всю цепочку) и объяснить кто, кому, что и как… И, быть может, тогда наше приложение «пропустили». Но это был «не вариант» — времени на этот путь у нас не было, да, и гарантий, что Apple пойдет навстречу — тоже. И мы выбрали другой путь. Мы воспользовались «партизанскими», вернее «народными» средствами дистрибуции нашей «беты» среди узкого круга. Мы использовали Diawi.com — сервис для ad‑hoc распространения. Конечно, собрать UDID с «топов» тоже был тот ещё «квест», но в итоге мы, конечно, справились и с этим.
Уверен, что многие из вас могли с большим скепсисом отнестись к моему громкому заявлению о том, что подобного продукта на тот момент не существовало. Поэтому, чтобы развеять ваши сомнения я хочу представить фрагмент нашего аудита, предшествующего разработке. Это сравнительная таблица ключевых компонентов решений от авиаперевозчиков, существующих на тот момент.
Все это касается «клиента», то есть непосредственно Приложения. Но у команды были и другие непростые задачи. К примеру, предиктивное кэширование. Конечно, сегодня идея «собери плейлист дома — запсти его в пути» не звучит революционно. Но это сейчас, а не в 2019. К тому же, мы закладывали куда более глубокий сквозной сценарий, который я до сих пор не вижу даже в решениях авиаперевозчиков. Напомню, что концепция «От дивана до дивана» подразумевала максимально «бесшовный» переход для пользователя между «берегом» и «бортом». На берегу ему должен был доступен весь контент, но с определенными ограничениями. Пользователь мог просматривать все «карточки» объектов Развлекательного центра и добавлять понравившиеся объекты в Избранное. Конечно, возможность проигрывания медиафайлов и просмотра электронных книг у него появлялась только «на борту». Кроме того, он мог ознакомиться с меню вагона‑ресторана, читать новости, изучать регламент предоставления услуг РЖД, бронировать билеты и так далее. Все это должно было работать «дома на диване». И при этом Приложение не должно было «высаживать» батарею гаджета. Требовалась экономия расхода батареи. И чтобы это все привести к единому знаменателю требовались эксперименты. Этим занималась отдельно выделенная небольшая команда. Да, совсем забыл про внедрение мультиязычности — закрыли и эту задачу, подключив английскую и китайскую локали. Мы реально гордились тем, что и как мы это сделали. И сейчас мне особо больно от того, что довести наш Продукт до финального релиза нам не позволили обстоятельства «непреодолимой силы». Так первый раз в своей практике я столкнулся с этой формулировкой живьем. Да, COVID-19 был именно таким обстоятельством с юридической точки зрения.
Итак, начало конца. Первая, самая мощная волна пандемии, вероятно, привела к резкому изменению курса и перераспределения бюджета РЖД. Я это понимаю, зачем вкладывать немалые деньги в разработку такого масштаба, да ещё и платить поставщикам контента, когда пандемия парализовала всю транспортную систему!? Так проект сначала был «заморожен», а потом и вовсе закрыт. Грустно, обидно, но такова жизнь.
Эпилог. 10 правил выживания в интеграционном аду
Я постарался вам максимально подробно описать те проблемы, с которыми мы столкнулись, а также показать решения, к котором пришли. Теперь пришло время свести все важные момент в список правил, которые мы выработали для себя в процессе этого непростого взаимодействия. Надеюсь, что они вам тоже пригодятся. Ловите!
Смиритесь со сложной схемой, состоящей из нескольких юрлиц, где не сразу понятно что, зачем, почему и как. На месте придется разбираться, кто и как отвечает за определенный фрагмент инфраструктуры — сначала все очень неочевидно.
Если у вас есть возможность снизить свою ответственность юридически — делайте это любыми способами. В моём случае я продолжал оставаться консультантом даже когда по факту возглавлял весь «прод».
Внедряйте в процедуру приёма‑передачи дополнительные инструменты для «фиксации» результата, на который можно сослаться. И это должно быть что‑то визуальное, а не какой‑то «мутный» фрагмент текста. У нас это были те самые «Карточки компонента».
Будьте готовы к «гибриду» (Waterfall/Agile) и к постоянно меняющимся требованиям или ситуациям, когда вам сразу чего‑то «не досказали»… Со злым умыслом или просто об этом никто не знал или банально не подумал предупредить.
Проектируя «дорожную карту» никогда не ставьте два тяжелых, рискованных фрагмента разработки друг за другом. Обязательно закладывайте «пространство» для маневра, чередуя сложные участки c относительно простыми. В случае форс‑мажора вы сможете «съесть» время простого этапа, не поломав весь график работ в рамках «водопада».
Будьте готовы столкнуться с самыми «кринжовыми» решениями и лютым «легаси». И что все, что можно замели «под ковер», чтобы не мешало и не лезло в глаза. И именно вам это оттуда выковыривать и приводить в рабочее состояние.
Готовьтесь, что «система» (здесь я говорю о людях на местах) будет всячески препятствовать вам в работе и стараться «вернуться к исходному состоянию». Вы можете столкнуться с серьезным противостоянием, а иногда даже и с откровенным саботажем со стороны заказчика или других контрагентов.
Всегда готовьте «три варианта» чего бы то ни было — будь то смета или решение какой‑то проблемы/задачи. Поверьте, эта вариативность позволяла нам выкрутиться в любой ситуации. Заказчик будет радостно раздувать щеки и думать, что вы постарались. В то время, как такой подход даст вам возможность «перескочить» с одного варианта на другой. А то и вовсе «продавить» какой‑то четвертый или пятый.
Всегда логируйте все действия, особенно «внешние прерывания» со стороны заказчика. Это ваша страховка от внезапного понадобившейся новой функции для «дирекции» или несвоевременной сдачи своей части работ со стороны команды Интегратора. У вас всегда заранее должен быть подготовлен «пакет» контраргументов даже при малейшем сдвиге сроков.
Никогда не верьте ничьим обещаниям на многостороннем брифинге — требуйте официального подтверждения принятие задач с закреплением ответственного лица в «таск менеджере» или среде ведения проекта. Если это невозможно — фиксируйте это в email‑переписке и не забываете ставить в копию менеджмент заказчика.
Работа с «госсектором» — это не прогулка по Agile‑методичкам и не увлекательное приключение, как в стартап‑разработке. Это тяжелая работа на истощение. И это всегда гибрид, где на одном фланге ты выписываешь филигранные «депеши», на другом — работаешь психологом для своей команды. На третьем — зеркалишь репозитории в режиме параноика.
Можно ли было сделать всё «по науке»? Это вряд ли. Так что не так важно, проводите ли вы «Daily», если ваши «рефайменты» и «Карточки компонентов» реально сшивают разваливающуюся систему. А ещё наш тандем с «К» доказал, что компетенции и сферы ответственности всегда лучше разделять. Где слабость одного — там сила другого. Не так важно, насколько глубоко менеджер «шарит» в коде, если он готов быть твоим щитом. И не всегда «глава прода» должен лично таскаться на бесконечные митапы с заказчиком, где 90% времени в буквальном смысле переливают из пустого в порожнее.
В конечном счете, любая сложная интеграция — это история не про софт, а про людей и их умение договариваться. Мы свой путь прошли, оставив на память гигабайты логов и пару прядей седых волос. А может и не пару… Надеюсь, мой опыт и эти 10 правил помогут вам выйти из вашего «интеграционного ада» не просто выжившими, а победителями.
Было непросто. Но, черт возьми, это было весело! Очень жаль, что COVID-19 убил такой крутой проект. Искренне желаю, чтобы все ваши начинания избежали подобной участи. И не забывайте предохраняться! Ну вы поняли…
