3.1. Организация
Проект реализовывали отнюдь не юнцы: как со стороны банка, так и со стороны GlowByte были опытные специалисты, за плечами которых – сотни проектов всех калибров и мастей. Но задача была все равно необычной: требовалось смиксовать этапный подход интегратора с большими вехами и работу внутренней гибридной банковской команды по SCRUM (которая, к слову, продолжала выполнять свои непосредственные обязанности, и спринты приоритизировались согласно бизнес-логике).
В этом и крылась проблема номер один: никто не придумал на старте, как подружить две сформировавшиеся, привычные для банка и для GlowByte парадигмы работы. Команда GlowByte очень хороша в больших проектах “под ключ”, эта бизнес модель не раз показывала свою эффективность. Но банк был уверен в своих силах и предложил модель партнерства, когда из двух компаний собирается лучший опыт и формируется гибридная суперкоманда.
Но, в связи с удаленной работой и тем, что детали взаимодействия рождались по ходу пьесы, разделение между командами все равно имело место. В итоге это привело к рассинхрону на этапе разработки, запаздыванию по ревью идей решения задачи, неверной оценке банком сроков на тестирование и бизнес-тестирование фич, проблемам с разной трактовкой функциональных и нефункциональных требований, о которой расскажу ниже, и, как итог, к сдвигу общих сроков.
Решение было очевидным, но пришло не сразу: ввести несколько раз в неделю совместные статусы, дать возможность разработчикам общаться напрямую без менеджеров, фиксировать формирующиеся на ходу правила (как можно, а как нельзя), плюс статусы, технические и бизнес-ретро, демонстрации прототипов и гибкое перераспределение задач за счет взаимного роста экспертизы и команды.
3.2. Репозитории и релизы
Одной из главных, так и не решенных проблем оказался репозиторий. В связи с политикой безопасности и переходным периодом в выборе стека в банке не удалось организовать единое пространство для написания кода. Выглядело все примерно так: разработка велась GlowByte в своем репозитории, банком – в его репозитории. При завершении вехи GlowByte вливала все свои доработки в репозиторий руками, дальше одним commit это раскатывалось на стенды тестирования, уже потом формировался релиз. Ревью и осмысление кода, подготовка к сборке занимали так много времени, что порой превосходили саму разработку. Исправления вносились с новыми кусками функционала. Все это приводило к потере связанности задач на доске с коммитами, сложности при слиянии кода и путанице с релизами на прод.
Но постепенно команды начали уменьшать ветви разработки, насколько это возможно облегчать и параллелить работу над разными элементами. После сборки ядра системы и начала промышленной эксплуатации основных модулей проблема понемногу стала уходить.
Однако честным будет уточнение, что подготовка и запуск первых версий за обозначенный срок предполагали большой объем изначального кода, поэтому отчасти описанные проблемы были неизбежны безотносительно к репозиторию и релизам.
3.3. Трактовка терминов
Бывает так, что терминология воспринимается как универсальная и общепринятая, но практика показывает: всегда лучше договариваться о ней заранее. Например, термин “монолит” и его противоположность “микросервис” могут ощущаться по-разному у разных архитекторов. Различия могут быть в деталях или в мелочах, но в масштабах громадной системы это может выливаться в принципиальные элементы, которые возвращают архитектуру на начальный этап проектирования.
Другим подобным примером может быть достаточность или избыточность отказоустойчивости, защиты от нестандартных сценариев использования или поведения, трактовка стандартов составления кода или использования шины. Решение настолько же простое, насколько и утопичное: общаться, обсуждать, спрашивать и договариваться. Команды проекта для себя нашли формулу в том, чтобы двигаться меньшими, но частыми шагами, почаще показывать промежуточные состояния, не бояться спорить, искать компромиссы и баланс.
3.4. SARS-CoV-2
Он пришел в нашу страну под звуки самоизоляции как раз в тот момент, когда завершился этап архитектурного проектирования системы и первичный этап системного анализа, и проект должен был переходить в стадию разработки. Изначально затевались общекомандные “дейли”, коллаборация, обмен знаниями в едином пространстве – работа в единой мотивации, когда ребята из команды GlowByte проникались бы духом работы целевого маркетинга банка, воочию бы наблюдали за проблемами, победами, рутиной и авралом, процессом генерации идей и общекомандным обсуждением результата. Это, безусловно, должно было сблизить и наполнить радостным предчувствием весь коллектив проекта. Но ровно в тот момент, когда банк определился со схемой рассадки, растолкав соседей по этажу, приоритеты резко изменились…
Руководство банка за две недели вывело практически весь свой штат сотрудников на удаленную работу, придумав решение такого формата (до событий марта 2020 удаленно, да и просто с ноутбука могли работать очень немногие). Точно так же пришлось импровизировать и с доступами для внешних подрядчиков. Все было успешно организовано, но проект потерял в скорости и своем запале. Многое из проблем взаимодействия стало следствием того, что команды работали “вслепую”, так ни разу и не увидев друг друга в полном составе очно.
3.5. Внутренние трансформации и целеполагание
Так совпало, что проект пережил вместе с его участниками несколько организационных изменений, связанных со структурой Retail. Это и переход CVM под крыло другого домена, и смена принципов выстраивания приоритетов, и реорганизация и децентрализация платформ и сервисов всего блока. В связи с этим договоренности по участию смежных команд, которые отвечали за доработку интерфейсов взаимодействия системы с каналами доставки и конвейерами, менялись в неочевидную для проекта сторону, да и план проекта вкупе с его фокусами претерпел изменения десятки раз. Порой было непросто найти общий язык и прийти к общему знаменателю с другими владельцами продуктов. Какие-то из элементов оптимальнее оказывалось вообще не делать, какие-то делать самим, а какие-то переосмыслять архитектурно. Но гибкость, к которой пришли к этому моменту в проектной команде, играла на их стороне – система вышла на заданную орбиту.
4. Что получилось в итоге
Настоящее и будущее платформы
Эта статья была задумана в январе 2022 года как рассказ об очень большом, технологически красивом и обращенном в будущее решении. Но в феврале случилось то, что случилось. Как итог – большие вендоры, решения которых были компонентами платформы, частично или полностью ушли с российского рынка. В заключении я планировал рассказать про метрики, скоростные инкременты и планы по дальнейшему развитию, но все-таки завершу некоторыми размышлениями о том, что было бы без этого решения в подобной ситуации, и том, что потенциально может его ждать.
Взяв курс на собственную разработку и восприятие коробочных решений как отдельных кубиков в архитектуре, банк здорово снизил стресс от того, что какой-то из этих элементов может превратиться в тыкву. По большому счету, внедрение любого другого средства генерации персональных предложений сводится к соблюдению интерфейсных соглашений и возможному переписыванию интеграционных модулей. При этом почти полностью сохраняется логическая модель, сценарии и механизмы управления, ведь все создавалось под бизнес-процессы компании, а не подстраивалось под возможности трендовых решений.
Идея заключается еще и в том, что инструментов генерации предложений может быть не два и не три одновременно. Все самые детальные данные порождаются и хранятся в платформе, а значит и отчетность сохранится и не даст потерять контроль над эффективностью целевого маркетинга. Это позволяет внедрять новое решение при сохранении работы старого, пока лицензии еще активны.
Реальность, скорее всего, скорректирует этот радужный прогноз, и любые существенные изменения компонентов могут обернуться “сюрпризом”. Много инженерных проблем будет ждать своих решений. Но сейчас кажется, что банк сделал удачный выбор.
Архитектурные принципы, заложенные в систему, позволяют гибко ее расширять как под новый функционал, так и под большие нагрузки. Платформу можно и нужно кластеризировать – то, что в числе прочего было нещадно схлопнуто MVP. В угоду срокам проекта были упрощены интеграции с некоторыми каналами, не внедрены все фичи и упрощены интерфейсы.
С интересом можно наблюдать за тем, как идея пройдет испытание в обстоятельствах, где роль и ключевые приоритеты CRM меняются, инфраструктура находится в бурном непрерывном преобразовании, прогнозы работают слабо, ведь тот мир, в котором мы сейчас живем, никогда не был таким ранее. Участие же в этом проекте стало для всех его участников ярким событием в профессиональной карьере и позволило на практике проверить представления о прекрасном.