Пять лет назад завершилась моя работа в одном из самых амбициозных, но не завершившихся IT-проектов в истории пассажирских перевозок. Проект для РЖД, который по масштабу и связности экосистемы должен был встать в один ряд со Сбером и обогнать всё, что существовало у мировых перевозчиков. Его убила не кривая архитектура, а пандемия и тектонические сдвиги подковерной борьбы.
Более 15 лет в b2b-разработке приучили меня держать подобные кейсы за контуром публичности. Но сегодня юридические ограничения сняты, и я готов сорвать покровы.
Этот материал – не стандартный кейс формата «мы запилили продукт, хвала нам». Это двухтомный производственный триллер о том, как построить цифровой космолет внутри панциря Левиафана. Как обеспечить безопасность команды, выстроить железобетонную стену по периметру и не поехать при этом «кукухой». Когда ты помещаешь живую инновацию в жернова госкорпорации, ты либо становишься жертвой системы, либо учишься управлять гравитацией.
Серия первая: Архитектура маскировки. Жесткий процессуальный хардкор, анатомия схемы взаимодействия и готовая методичка с Карточками компонентов, которые спасали наши задницы от бесконечных правок.
Серия вторая: Продуктовое мясо и хроники интеграционного ада. Детальный разбор самого цифрового космолета, погружение под капот легаси-экосистемы, курьезные истории из жизни нашего «прода» в жанре «пиу-пиу». И в завершение 10 наших железных правил выживания с госами.
Добро пожаловать на борт. Физика процесса изменена, но внешне мы стоим на ногах.
Все события реальны (почти), имена изменены, а выводы сделаны исключительно с целью поделиться инженерным и управленческим опытом. Ни одно должностное лицо в ходе написания статьи не пострадало (надеюсь).
Дисклаймер
Данный материал является публицистическим очерком, основанным на субъективном опыте автора в области IT-консалтинга пятилетней давности (2019-2020 гг.). Все упоминания брендов и структур (включая ОАО «РЖД» и ДОСС) приводятся в оценочных и информационных целях (ст. 1274 ГК РФ). Все приведенные графические и текстовые артефакты прошли процедуру глубокого обезличивания: оригинальные товарные знаки удалены, персональные данные вымараны, технические параметры и шифры систем изменены или сфальсифицированы с целью соблюдения b2b-этики и защиты коммерческой тайны. Автор выражает частное мнение (ст. 29 Конституции РФ), которое не направлено на умаление чьей-либо деловой репутации.
Оглавление
Завязка. Как все началось?
2019 год, пандемия ещё не началась. Думаю, многие помнят этот небольшой островок какой-то экономической стабильности. Прямо затишье перед бурей. Тогда, устав от своего марафонского спринта в разработке, когда мы пилили продукты без передышки уже порядка 10 лет, я решил взять небольшую паузу и попробовать себя «в консалтинг». Кроме того, у моей команды было пару b2b-проектов, с которыми можно было «поиграть в венчур». Так я придумал для себя небольшой «полезный отпуск». Решил примерить на себя другую шкуру и повариться в VC-индустрии.
Как раз в этой сфере я познакомился с одним своим коллегой по цеху. Он, назовем его «К», работал в структуре, которая делала аналитику и много других вещей для РОСНАНО. Также, как «ооошник», он брался за несложные подряды на разработку программных компонентов для «госов» и «энтерпрайза». В тот период у него был тесный контакт с интегратором, обслуживающим ДОСС – подразделение РЖД, в ведомстве которого находились, да и сейчас находятся, скоростные составы. На тот момент это был «Сапсан», «Аллегро» и «Ласточки».
Неожиданно звонок от «К»:
Дима, тут такое дело… РЖД хочет сделать приложение. Не просто билеты, а чтобы пассажир вообще из смартфона не вылезал. У тебя есть опыт работы в мобильной разработке? Ты можешь быстро собрать команду под масштабный проект?
На оба вопроса я дал утвердительный ответ. Признаться, на тот момент никаких сложных разработок под «мобайл» у нас не было – только небольшие сборки для ECOM и все. Зато продуктов в области автоматизации бизнес-процессов со сложными внедрениями в корпоративное «легаси» было хоть отбавляй. На самом деле именно это больше всего и пригодилось. Но не будем забегать вперед.
Внедрение инноваций в РЖД. Внутрянка – верхний слой.
РЖД, хоть это и АО, но по своей структуре это скорее группа компаний, находящихся под «единой крышей». Каждое такое подразделение обслуживается отдельным независимым подрядчиком-интегратором. Такая структура позволяет бороться с коррупцией на местах, а также дает относительную свободу – в любой момент можно сменить интегратора, если он не справляется. И подобная «рокировка» не приведет к каким-то катастрофическим последствиям. Хотя, конечно, она не будет совсем бесшовной и некоторые шероховатости и даже мелкий саботаж вполне могут иметь место. Но это все легко купировать и свести к минимуму имиджевые потери.
Так вот, по факту, РЖД, на момент описываемых событий, не имела собственных подразделений для развития цифровой экосистемы. Вся она (их экосистема) сшита, как лоскутное одеяло из разных компонентов. А за то, чтобы все «лоскуты» крепко были сшиты между собой и соответствовали определенным стандартам, отвечает отдельное подразделение – ВНИИЖТ. Это НИИ, который занимается разработкой отраслевых стандартов и сертифицирует внедряемые технологии. Возможно, как-то сложнее, но мы не будем углубляться в детали, которые не имеют прямого отношения к моей истории. А ещё у головной компании есть отдел маркетинга и стратегического планирования – он отвечает за разработку «верхних» директив, связанных с внедрением инноваций. В том числе и в рамках развития пользовательских сервисов. Именно там и была разработана концепция «От дивана до дивана», в рамках которой и планировалось разрабатывать это новое эпическое приложение. Но о приложении я расскажу позже, сейчас я хочу раскрыть вам «внутрянку» работы РЖД и с самим РЖД. И «подсветить» слепые зоны и неочевидные нюансы.
Значит так, у РЖД была некая концепция «сделать пассажиру хорошо». В рамках этой концепции планировалось создать единое приложение для работы со всеми мыслимыми и немыслимыми сервисами компании, включая те, которые только ещё задумывались. Сверху от дирекции компании Интегратору спускают «концепт» в виде презентации с фундаментальным описанием идеи. Интегратор на своей стороне должен «придумать» формат конечной реализации этой идеи в рамках контролируемого им фрагмента инфраструктуры. А затем представить четко сформулированное коммерческое предложение (КП). И если предложенная уже «приземленная» идея «зашла», то начинается беготня в дирекцию для согласования и конечного утверждения проекта. Так Интегратор в этой схеме становится технологическим драйвером. После утверждения проекта и его сроков, начинается запуск всех процессов.
Тут я должен дать вам парочку немаловажных деталей. Первая – ни у кого из интеграторов, как правило, нет квалифицированных кадров для реализации подобных, и даже менее эпичных продуктов. Все его айтишники с утра до вечера занимаются «тушениями пожаров», чтобы обеспечить работоспособность этого монструозного «легаси-колосса». И все это они делают за зарплату, которая, нередко, находится значительно «ниже рынка». Поэтому Интегратор вынужден искать надежного субподрядчика для реализации проекта подобного масштаба на стороне.
Вторая, не менее важная деталь – именно Интегратор оплачивает разработку. А РЖД потом выкупает готовый продукт. Идеальная и абсолютно безопасная схема для РЖД, но не для Интегратора. Что бы ни случилось, любой форс-мажор – риски ложатся на него.
Но в конце его ждет «суперприз» – маржа между тем, что Интегратор заплатит суботрядчикам, т.е. нам, и оговоренной с дирекцией РЖД финальной стоимостью продукта. Который протестирован и готов к введению в эксплуатацию.
Важное допущение. Предполагаю, что реальная схема взаиморасчетов могла работать как-то иначе и быть сложнее. Лично я, как и вся собранная мною команда, были полностью изолированы от РЖД, ДОСС и ВНИИЖТ. Между нами было два промежуточных звена – Интегратор и ООО моего партнера «К». И, понятное дело, по бухгалтерии мне никто из них не отчитывался. Так что «за что купил, за то и продаю». И сейчас, спустя годы, я допускаю, что Интегратор мог намеренно исказить какие-то факты, дать полуправду о схеме финансирования. К примеру, чтобы продавить нас по цене, представив нам своё «крайне незавидное» положение. И, может быть, РЖД все же финансировала проект поэтапно, но с каким-то отставанием. Или по факту представления им действующего компонента решения.
Схематоз. Или как я прикрывал задницу себе и своей команде.
Ещё в середине нулевых я осознанно отказался от работы с «госкорпорациями» и особо крупным «энтерпрайзом» по причине очень частых мутных дел, царящих в этом секторе. Сейчас думаю, что зря, мог бы заработать в разы больше. Так как умение пробрасывать «мосты» между разными фрагментами «легаси» – редкий востребованный опыт. А именно это всегда было сильной стороной моей команды. Ну, да ладно. Возвращаемся к вопросам личной «гигиены». И здесь моя позиция понятна – я не хотел ни под каким предлогом участвовать в любых проектах, где мог быть даже намек на какие-то непонятные мне схемы.
В текущем проекте я видел для себя и своей команды ряд рисков, и мне нужно было продумать, как их минимизировать.
Первая проблема. Личная ответсвенность по «самое не балуйся».
Здесь я должен вам рассказать о своей роли в проекте, давайте её разберем в подробностях. Что мне предстояло взвалить на себя, и какова была зона моей ответственности в проекте?
Так вот, сначала совместно с «К» нам требовалось провести аудит инфраструктуры заказчика. Конечно, все это под NDA. Затем нам нужно было разработать подробное ЧТЗ, опираясь на информацию, полученную от Интегратора – полный набор скриншотов экранов планируемого приложения, текстовые и голосовые заметки и т.д. После этого уже только я должен был составить подробную смету и «дорожную карту» проекта. После чего сначала согласовать это все с «К», а он отнести «на ковер» к заказчику и утвердить её. После этого я со своими техническими консультантами должен был сформировать требования к модернизации фрагментов экосистемы РЖД. Здесь примерно 80% всех доработок были связаны с форматом данных и RestAPI. Со всей этой предпроектной подготовкой никаких проблем не было – я мог выступать в роли консультанта по договору ГПХ или, как ИП. Здесь никаких опасений у меня не возникало.
Дальше мне нужно было собрать две относительно независимые команды «под мобайл» – сначала команду под iOS разработку, через полгода вторую команду под Android. Весь проект мы планировали реализовать за 1,5 года, плюс полгода на мелкие доработки и улучшения. Итого 2 года. В приоритете было приложение под «яблочную платформу», так как у всех «топов» в те годы был именно iPhone. Команда под Android должна была идти по проторенному пути – когда данные уже «причесаны», все стыковочные узлы проработаны, RestAPI доработано и функционирует без сбоев. Рассчитывалось, что темпы разработки у второй команды будут выше. Цифровую экосистему РЖД (вернее нужный её фрагмент), контролировал Интегратор и его команда. Нас к бэкенду не пускали, даже с учетом подписанного NDA. Мы могли только посмотреть, как отрабатывает «фронтенд», поговорить с разрабами на местах, запросить спецификацию и т.д. К примеру, доступ к API мы получили только в ходе разработки. Никакой спецификации – только веб-морда Swagger 2.0. Думаю, что многие помнят несовершенность этого инструмента до внедрения стандарта OpenAPI.
Кроме команд под мобильную разработку нам ещё требовались «верхние» архитекторы и технические консультанты. Их задачей была корректная постановка задач по модернизации «бэкенда» на стороне заказчика, а также взаимодействие с другими субподрядчиками и поставщиками сторонних услуг, которых было в проекте предостаточно. Многие технические моменты нам приходилось буквально додумывать и реконструировать в формате «реверс-инжиниринга».
Весь этот колоссальный объем работы с уровнем ответственности «через край» ложился на мои плечи, так как «К» разбирался в технологиях только на уровне «венчурного аудитора». Зато он был великолепным GR-ом – умел «во все это» с правильными ритуалами и танцами. Как раз то, что я особо ненавижу… А ещё, имея огромный опыт работы «с госами» и «для госов», он умел писать такие витиеватые договоры, в которых даже самые лютый аудитор не смог бы разобраться – кто, кому, зачем, в какие сроки, по каким требованиям и т.д. и т.п. Вообще ничего не понятно и засыпаешь на каждой строчке. Это прям талант!
И тут возвращаемся к проблеме, которая не давала мне спать спокойно по ночам – как же «рулить» всем этим, оставаясь в стороне от всех опасных зон. Ответ пришел сам собою. Я сказал «К»:
Слушай, я готов под этим всем подписаться. Меня ты знаешь – я гиперответственный чел, внимательный к деталям и въедливый до боли. Никакого ADHD, только суровое OCD… А давай юридически в проекте я так и останусь консультантом на почасовке?
И, вот неожиданность, «К» согласился. Уж не знаю, что продиктовало ему такое решение – страх перед тем, что без меня он не сдюжит или слепая вера в меня, как в какого-то супергероя. Не знаю!
Так или иначе, но с первой проблемой было покончено. Идем дальше…
Вторая проблема. Что делать, если заказчику нужен «водопад»?
Не побоюсь сказать, что мы давно живем в мире, где «Waterfall» считается архаичным и неэффективным методом ведения разработки. Особенно если говорить о технологически и технически сложном проекте, который должен быть интегрирован в уже существующую legacy-инфраструктуру, которая ещё и находится под контролем у другой организации. Уже этого достаточно для понимания уровня абсурда. А если ещё вспомнить, что решение необходимо «задружить» с несколькими third-party сервисами… То это уже игра на уровне «Impossible». Бред, не правда ли? Но «госам» всегда нужен только «водопад». Что же делать?
Да, сегодня многие скажут – «гибрид»! Ну, не совсем… И не забывайте, что на дворе стоит 2019 год, и про «гибрид» я тогда точно ничего не слышал. Поэтому я придумал собственную его версию. В чем же она заключалась?
Ещё на этапе составления сметы и планирования этапов разработки, я понял, что необходимо чередовать сложные элементы решения с более простыми. Так появляется дополнительное «окно». Это даст возможность «подчищать хвосты» между этапами. И вы создадите себе страховку от форс-мажора. И если вы ещё и хорошо «перезаложились» по времени, а все знают, что на проект всегда нужно, как минимум в два раза больше времени, чем кажется в самом начале, то все будет тип-топ.
Благодаря этому подходу, внутри команды мы могли спокойно работать по «Agile». Но с оглядкой на сроки сдачи компонентов в рамках утвержденной «Roadmap». По сути, «прописанной» в нашем приложении к договору в виде этапов разработки.
Мы использовали ещё один трюк. Те из вас, кто занимался разработкой «под мобайл», скорее всего, тоже хорошо с ним знакомы. Если у вас горят сроки, то можно в ускоренном темпе временно «слепить» компонент с использованием «WebView» и показать в таком виде клиенту. Никто даже этого не заметит. А потом вы можете вернуться и спокойно сделать все по-человечески. Если, конечно, этого требует система или это четко прописано в ТЗ. А то можно и просто «забить», если это банальный вывод какой-то информации, к примеру, новостной ленты или статичных информационных разделов.
Конечно, для эффективного применения такого метода вам потребуются дополнительные рабочие руки. Причем эти «руки» должны хорошо ориентироваться в проекте, но это уже проблема, которую значительно проще решить. У меня всегда в команде было пару универсалов, которые могли бы справиться с подобной задачей. И поверьте, это, как минимум, два раза спасало нас только в рамках этого проекта! Вот такой лайфхак.
С этим разобрались, разруливаем дальше!
Третья проблема. Разночтения в третьем чтении… или как избежать проблем при сдаче компонента решения?
Я уверен, что каждый разработчик сталкивался, как с проблемами при сдаче проекта, так и с откровенным невежеством «принимающей стороны». Когда: «Почему это не так работает? Мы хотели по-другому! Почему кнопка красная?» Да что угодно!
Когда-то, во времена начала моей карьеры в IT, у нас, разработчиков, была прекрасная формулировка: «Возможности языка не позволяют…» Все мы здесь прекрасно понимаем, что это откровенная демагогия и подмена понятий, но фраза работала безотказно.
Сейчас времена другие, и клиент чаще «галлюцинирует», слепо веря, что реализовать можно любую блажь. К примеру, как вам такой запрос: «Приложение должно самостоятельно находить сеть Wi-Fi и автоматически подключаться к ней…» Фига себе, какие полномочия должны быть у приложения, да!? Это бред! И поверьте, подобным бредом изобиловали первоначальные требования. И это не фантазии «топов» из РЖД, это галлюцинации «специалистов» на стороне Интегратора. Хотя, именно CTO Интегратора рассказал моим ребятам одну забавную историю. Его команде требовалось реализовать какую-то подобную «хотелку». Сделать точь-в-точь, как хотел заказчик, было невозможно. Команда предложила два альтернативных решения – можно «так» или «сяк». Но топы не поняли, что эти решения были конкурирующими и они такие: «Да! Хотим так!» Причем такой ответ был дан на оба варианта. Ну, вы знаете, разрабы не всегда могут четко донести мысль до «бизнеса». Так из-за недостатка харизмы у кого-то из руководителей со стороны разработки ребятам пришлось каким-то фантастическим способом реализовать оба варианта. Облегчили себе задачу называется… Вот со мною такие варианты не прокатывают, возможно, поэтому меня и не любят «госы» и «топы». Я всегда доношу мысль без разночтений!
Так вот. Что мы с командой придумали, чтобы иметь возможность «выскакивать» из подобных ситуаций?
Когда-то мне попадался «манифест» или вернее методология «Getting Real» от создателей RoR – студии «37 signals». Ещё до распространения его в русскоязычном сегменте. Я уже не помню всех подробностей их философии, но прекрасно помню, что одна из их основополагающих идей вызвала у меня особое негодование. Я говорю о подходе писать код исключительно под те элементы, которые отображены на скриншотах заказчика. И не нужна никакая спецификация… Тогда мне казалось это полным бредом. Почему? Да просто потому, что их подход был неприемлем для моего «продакшена». Мы с командой предпочитали не ломать и выбрасывать продукт на каждом из эволюционных витков, а сразу закладывать архитектурную возможность развития продукта в разных направлениях. Структура данных и связи – первичны, код – вторичен. Да, в некоторых проектах такого непросто добиться. Но моё становление, как архитектора было во времена, когда клиент мог за ночь кардинально изменить требования. И чтобы выживать в таких условиях мне приходилось предвосхищать его «хотелки». Да, такой подход избыточен, если вы не проектируете сложные экосистемы или не встраиваете новые фрагменты в уже существующее «легаси». Но это мой выбор и подход любой команды, которую я собирал. Я всегда выбираю людей, разделяющих мои взгляды и методы.
Так, теперь, чтобы немного приглушить «холивары» в комментариях, хочу развернуть мысль, почему подход «Getting Real» работает в RoR. Далеко не все адепты этого фреймворка знают, почему Ruby on Rails назвали именно «рельсами». Дело в том, что там изначально заложена жесткая колея – Convention over Configuration. Как бы команда ни наговняла в коде, фреймворк удержит структуру проекта. Новый разработчик придет, поплюется, но разберется. Но вы попробуйте повторить этот фокус на Python, Node.js и тем более «Пыхе» – вы гарантированно получите архитектурный коллапс уже через пару-тройку месяцев.
Ну да ладно, давайте вернемся к РЖД и тому, как мы взяли на вооружение именно этот неприемлемый для меня ранее концепт. Мы с моим архитектором и технологическим консультантом подумали:
А почему бы нам не применить такой подход в текущем проекте? Скриншоты есть, бюрократия и техническая некомпетентность тоже есть! А может быть ребята из ‘37 signals’ выработали такой подход, в том числе для защиты от меняющихся требований и некомпетентности заказчика!? Ну, тогда они просто красавчики!
Так мы ввели артефакт «Карточка компонента». Это небольшая анкета, в которой выведен скриншот экрана приложения и кратко описана механика того, что на этом экране происходит. Без дополнительных деталей «как это происходит». Никакой лишней информации. Так «Карточка компонента» стала стандартом для акта приёма-передачи во время формального завершения работы над компонентом. Такой подход позволил нам полностью сбросить с себя все вопросы: «А почему не так?», «А мы хотели по-другому…» и т.д.
RoR-овцам этот подход позволял быстро «клепать» MVP, а не скатываться в «говнокод» им обеспечивала «рельсовость» их языка, точнее, фреймворка. Для нас же это был щит от «галлюцинаций» со стороны заказчика.
Итак. С проблемами разобрались. Я, де-юре, всего лишь консультант по архитектуре продукта. Моя команда может практически без особых нервяков работать в комфортных условиях «гибких методик разработки». Риски каких-то эпических бесплатных переделок максимально снижены благодаря «Карточкам компонентов». Можно делать продукт.
Фиксируем результаты. Если вы собираетесь работать с госсектором или крупным «энтерпрайз», то наш опыт поможет вам найти точки опоры. Теперь у вас есть наш набор инструментов, которые работают. Вы можете использовать их «AS IS» или модифицировать с учетом нюансов вашей задачи или ситуации.
Продолжение – во второй части. Обещаю вам там подробности про «эпическую задачу», команду и процесс разработки, то, чем все закончилось и почему. Будет много продуктовых скриншотов. А ещё дам 10 правил работы с «госкомпаниями», которые мы выработали для себя. Не переключайтесь.
ссылка на оригинал статьи https://habr.com/ru/articles/1057106/