М:  Как это увязать именно с внутренними процессами команды. То есть то, что произошло в редизайне. Я в принципе, на своем уровне поняла. Только там надо на скринах побольше показать, вот, а вот с теми тезисами, которые ты рассказывал, что это тоже у вас перечислено в ноушене.

А: Я сейчас постараюсь просто это объяснить. Монолитная архитектура создает созависимую систему и это считается устаревшим подходом. Поэтому для внедрения любого изменения тебе нужен процесс каскадной разработки. То есть, сначала ТЗ, потом смотришь в какие куски системы надо внести изменения, затем команда берет это в разработку. И если по ходу ты что-то забыл, то возвращаемся к пункту №1 и дорабатываем ТЗ, цикл начинается заново.

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

Стартап это всегда более динамическая среда. Так, как ты ищешь новые подходы к решению старой проблемы. Это то, что мы делали, когда мы говорим увязка реинженеринга, изменение процессов, ее суть заключается в этом, то есть отказ от монолитной архитектуры. Изначально она была такой потому, что проектировали систему (первую версию системы) спроектировали для промышленных крупных предприятий. И вся система была под это.  И в 22 году случился перевод. То есть, мы сказали, что наш основной клиент будет не промышленное большое сложное предприятие (например Oracle), которое мы будем интегрировать. А клиенты будут микро и малый бизнес.

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

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

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

Так это ответ на твой первый вопрос.

М: Да так, но вообще хочется глубже, ты сейчас чуть-чуть это начал раскрывать, Но вот вместе с архитектурой меняется процесс. Тут Прям хочется. Знаешь, типа 1, 2, 3, 4 5…

А: Как меняется процесс? На самом деле, если взять 22 год, то он а-ля Карго, с неким налетом Карго эффекта был. То есть были проходили стендапы, ребята говорили, кто что делает, было планирование. были какие-то ретроспективы, но это не работало, так как оно задумано в Agile. То есть смысл основной: стрим прошел — результат получен. Конкретный, измеримый, ощутимый результат для пользователя — этого не происходило. И в первом приближении стало быстро понятно почему так не происходит, почему сроки постоянно едут. Потому что архитектура проекта не позволяла это сделать. Она не позволяла двигаться быстрее, каждый раз в какое-то узкое горло утыкались. Если про ядро системы говорить, то это Frame akson и CQRS есть такая технология обмена данных, но это лучше предварительно загуглить и вернуться с уточняющими вопросами. Был неверный выбор бизнес гипотезы, что продукт делается продукт создается для большого интерпрайза и внедрение таких.

М: Понятно, что ты сказал, что архитектура не дает двигаться быстрее, старая и дальше. Я погуглю еще то, что сказал. Ну пока мне непонятно, что вот, как более подробно сказать, потому что… Почему? и вот тут тоже хотелось бы несколько вариантов.

А: Потому что, если по определению смотреть, то как выглядит монолитная какая-то система и микросервисная система это принципиальное отличие. Это как я сказал, созависимость решений и независимость решений. То есть микросервис он внутри, не зависит от других сервисов — внутри можно что-то поменять и у него есть концы наружу (буквально их так называют), которые можно использовать и в других сервисах. Либо наоборот использовать для того, чтобы затащить в этот сервис какие-то данные. И это как условно лего конструктор становится. То есть ты можешь отдельно написать сервис и потом подключить его к уже большой системе. И это хорошо, встраивается.

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

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

И вот отсюда разница возможность независимо работать над какими-то модулями дорабатывать их, или невозможно это делать.

М: А вот тут какой-нибудь пример было бы классно именно связать с бизнесовыми функциями. То есть не знаешь, Какую ветку будешь развивать и тут. Ну например, хочу отказывались

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

Про время на адаптацию. И быстрое введение новичков

М: Так еще было про то, что новички быстрее адаптируются дают результаты. Это тоже связано с тем, что их можно точечно на что-то поставить. Они точечно в это вникнут?

А: Да, не нужно в генеральный план архитектуры погружаться. Например, не надо для того, чтобы сделать ремонт в какой-то комнате изучать сначала генеральный план, потом инженерные коммуникации. Тебе меньше нужно въезжать как это устроено. Потому что ты понимаешь, что это Независимый сервис. Он не рухнет, То есть тебе не нужно такой глубины погружения, и это существенно начинает сокращать время на адаптацию.