Дискуссия: новейшие подходы в создании эффективного конвейера разработки ПО

У нас потихонечку наша секция движется к завершению. И в качестве такого эпичного финала у нас по программе панельная дискуссия по теме «новейшие подходы в создании современного конвейера разработки программного обеспечения», модератором которой будет сегодня наш старый друг и партнёр Александр Сахаров, директор по работе с партнёрами, компания Diasoft. Саш, прошу. Всем, кто ещё живой на конференции, — это прекрасно. Хочу представить моих добрых партнёров и коллег, с которыми мы давно и много работаем. А коллеги, в общем-то, глубоко в бизнесе работают. Это мы тут IT-подрядчики, IT-венторы, да? А у ребят непростой и очень большой опыт в работе в крупнейших организациях. Кирилл Пехтовников, технический директор РТК ИТИ Ростлеком, просто в простонародьеи глава разработки Ростелеком. Так, можно сказать? >> Добрый день. >> Сергей Гаврилин Cioблока в банке ПСБ. Собственно, его основная роль заключается в общении с заказчиком, выстраивании отношений между заказчиком и то, чего там напрограммировали программисты. Поэтому сегодня поговорим о том вообще, как они с точки зрения внутренних процессов этих организаций, очень крупных, чувствуют себя в современных условиях. И предлагаю сесть. Да, у нас как… >> Да, добрый день, коллеги. >> Мы можем присесть, правильно, ведь? >> Да, конечно. >> Или можем стоять, >> да? Ну, ты можешь меня ещё представить. Так, Артём Гевланд, >> человек, с которым мы всегда обсуждаем любые платформенные истории и подходы к тому, как правильно в современном мире и какие правильные технологии использовать, какие лучше не надо. Спасибо большое. >> Спасибо.

>> Так, коллеги, всем привет. Ну, давайте поговорим, мы давно все знакомы, никого особо не удивим нашей откровенностью, поэтому в целом я сейчас задам некоторую идею разговора и на примерах предлагаю обсудить, как у вас в жизни с этими примерами всё происходит. Поэтому, ну вот я тоже в своём опыте руководил IT, и для меня всегда такой немножко страшный сон, когда есть какая-то большая задача. Обычно там большой бюджет. Вот у коллег там бюджеты всегда миллиардами измеряются. У кого-то десятками миллиардов, у кого-то госконтракты. Вот ТЗ пишут годами, ФТ пишут годами. Потом, значит, его нужно за полгода быстро слепить. Ну и, собственно, самый страшный сон, он заключается в следующем, что разработчики что-то разрабатывают, разрабатывают, как там ТЗ правильно интерпретирует, интерпретирует, потом приносит. И для меня это, в общем, чёрный ящик. Я не могу понять, как они запрограммировали, что они запрограммировали. Единственный способ проверить, что то, что они мне принесли, это похоже на то ТЗ, которое я написал, это, собственно, колоссальные усилия по тестированию. Причём тестирование оно на всех уровнях. Тестирование нагрузочное, тестирование информационной безопасности, а тестирование функциональное, интеграционное. А что такое тестирование? Тестирование — это вообще страх божий. Это заставить людей, которые занимаются другими вообще делами, вот отвлечь от работы и, собственно, заставить нажимать на кнопки в каком-то неведомом им софте, которую ТЗ они не писали. Ну, может быть, и писали там. А прошло уже много лет, они толком не помнят, почему оно выглядит именно так. А удовольствия от этого достаточно мало, потому что на кнопочку нажимаешь, не работает, падает. Вот.

Ну и дальше возникает следующий страшный сон, когда начинаются выявление ошибок, это стресс, это всегда, значит, там завтра запуск, у нас конец квартала, там надо закрыть там какое-нибудь распоряжение министра. Вот, естественно, ничего не работает. В опытно-промышленной эксплуатации запуститься не можем там, ну и так далее. Очень большой стресс для всех, кто работал в IT. Наверное, тут много не раскрою, да, секретов. Вот. Ну и в какой-то момент команда разработки встаёт и говорит: «Ребята, что-то мы устали. У нас тут оферы из Сбербанка. Там нам типа в два раза больше предложили денег. Ну и как бы до свидания». А тут мы, извините, у нас не очень хорошо получилось. Да, действительно, есть ошибки, но в целом вот их список. Можете их исправлять. Ну и дальше приходит другая команда, откуда-то не возьмись, вот её ещё нужно набрать, там как-то погрузить. Они приходят и примерно через месяца три говорят: «Слушайте, парни, ну если честно, мы посмотрели вот на то, что там написано. Ну и в целом в целом легче переписать». Вот. И в этот момент ты стоишь и понимаешь, что ты ничего как менеджер сделать не можешь. То есть у тебя нету ничего. И ты не можешь залезть сам в код, ты не можешь взять на себя вот это вот. Давайте я вам всем покажу, как это всё можно исправить. Там уже там десятки тысяч строк, сотни тысяч строк кода, непонятно, что написано на А и люди, которые тебя смотрят, говорят: «Ну, ты же понимаешь, что мы в этом не разберёмся и надо просто переписывать». Вот. Ну а параллельно заказчик вот как бы он уже вошёл во вкус, он уже, значит, разобрался, что работает, что не работает. Он знает, где слабые места. Он давит конкретно на и у него ещё возникает новый аппетит, новую функциональность. Это, это давайте это это. И в общем ситуация накаляется. Всё это приводит к достаточно плачебным последствиям. Я сейчас не буду называть, давайте сегодня без названий, чтобы никого не подставлять, да, вот не будем называть наших клиентов и наших там, но крупные организации, которые потратили там 2 млрд на разработку, вынуждены признать, что 2 млрд, к сожалению, не привели к результатам. И вот новая команда пришла, она просит 4 млрд. Ну, потому что новая команды там ещё, ну, короче, заново всё ТЗ надо переписать, потому что уже и заказчик по-новому смотрит. Ну, поэтому вот такой бюджет надо, давайте заново всё будем писать. К чему я эти все примеры рассказываю? К тому, что для меня вот как для менеджера это всегда была очень большой проблемой. И единственное, что в моей ситуации меня всегда более-менее хоть как-то спасало — это вот как раз построение современного конвейера по производству и внутри этого конвейера использование по максимуму разного рода платформных подходов. Вот, начиная с, ну, как бы с того, что происходит непосредственно в разработке, да, а в дивопсе, и на самом деле дальше слоями накладывается на это платформенный подход, в том числе и на проектирование системы, на проектирование бизнес-процессов, проектирование архитектуры там и так далее. Вот. И тогда, когда у меня, например, визуально отрисованы бизнес-процессы, я, по крайней мере, если разработчики уволятся, могу как-то справиться хотя бы командой аналитиков, который поймёт, что не так с процессами. Да, и заказчик может тоже посмотреть на картинку, увидеть свою картинку и начать как бы ситуацию исправлять. Вот.

Ну, в целом, я представляю компанию Diasoft, которая на этом как раз делает свой бизнес. Вот наша платформа Digital Co. Она как раз построена таким образом. То есть у неё все платформенные вот эти слои полностью разработаны и позволяют э очень сильно и просто быстро разрабатывать. А если кто-ты уволился и новый пришёл, быстро в этом разбираться, да, носить изменения. Но мне интересно, насколько вот у каждого свой взгляд на эту проблему. Можно даже как-то её сформулировать по-разному, да. Вот можно конвейер разработки, современные методы, можно платформенный подход и с чем его едят. Потому что в целом вот что Кирилл он больше на стороне, скажем так, разработки находится, да? А Сергей он больше на стороне, собственно, сдачи результатов работ разработчиков, больше работы с заказчиком, но всё равно в IT. Вот. Ну и, естественно, конечно, со стороны фланта тоже интересно и ваш взгляд понять, как вы смотрите вот на эту проблему. И мы живём сегодня не в 1997 году, когда в целом вот ээ мы ТЗ писали в Орде. Я помню вот >> хорошо, что отправляли там куда-то. Потом, значит, сейчас уже инструменты есть более современные, чем в 1997 году. И есть большая надежда, что мы живём в новом мире, в котором есть инструментарий помимо вайбко-кодинга, потому что там тоже свои проблемы, какие-то платформенные подходы, которые дают результат. Ну немножко я, э, болтаю, хотел слова передать. Кирилл, с тебя начнём. Серёж, >> да, Саш, если не возражаешь, возьму слово. Во-первых, спасибо, что представил. Э, я действительно в такой роли выступаю внутри моей организации где-то между бизнесом и IT. А, то есть в бизнесе я IT, в IT я бизнес. Ну, такой нахожусь в постоянном состоянии биполярного расстройства. Ну, собственно, сейчас весеннее обострение, поэтому, видимо, я здесь и оказался. Ну, а если, э-э, почему я такою, да, как бы вводную даю, потому что, ну, в принципе, на все, на вот процессы, э, производственные, на процессы разработки внедрения, э, мне действительно приходится смотреть с двух сторон, и со стороны бизнеса и со стороны IT, собственно говоря. А, ну давайте, наверное, как бы начнём э с того, что у нас как-то как раз как на всё это смотрит бизнес, как он в этом во всём участвует, как этот процесс выглядит. Но это ни для кого не секрет, и я уверен, что все см с этим э точно так же встречаются. То есть никакого секрета лишине здесь нет. Э с чего всё начинается? Где-то там в бизнесе там владелец продукта или владелец бизнеса говорит: «Мне нужно что-то поделать хорошее, какую-то автоматизацию процесса». А вот он с этой идеей приходит к бизнес-аналитикам, методологам и говорит: «Ребята, мне вот это нужно. Бизнес-аналитики лезут в какую-то документацию, смотрят о процесс-то не описан. А где он описан? Правильно, на внутренней нормативной документации. Вот они оттуда выписывают, долго пишут бизнес-требования, согласуют его с владельцем бизнеса, потом отдают на сторону там разработки. Ну, как правило, это некая подрядная организация. А ребята смотрят в это, пишут ТЗ, задают вопросы, им отвечают. Ну, дальше какой-то там процесс реализации, поставки кода, интеграционно-функционального тестирования. И о счастье функционал вытаскивается на бизнес. Но принимать-то его приходят не те люди, которые делали постановку, потому что они же там владельцы бизнеса, они как-то себе это видят по-другому. А приходят те люди, которые реально этим процессом пользуются. И о чудо оказывается, что процесс выглядит вообще по-другому. Ну, просто там в целом, да, но в тех деталях, которыми они там привыкли, да, то есть для них это ежедневный труд, ну, не клеится. В результате, что происходит? Начинаются долгие разборки с подрядчиком. А как же так получилось? И вообще, это бак или фича? И то начинается долгая вот эта разборка, что потом вдруг выясняется, что это фича, и начинается оценка этой стоимости. И пошёл цикл: «Да, отдайте денег». отдайте сроки. Ну и тут как бы всё, что как бы было вначале заложено с точки зрения там план графика какой-то реализации, внедрениние и ожидаемых результатов, возможно, даже заложенных даже маркетинговых компаний под это, там какой-то, допустим, новый продукт, всё это начинает двигаться вправо. И вот собственно этот цикл зачастую уходит в бесконечность. Ну как не то, чтобы прямо вот в столетие, да, но в года. как это исправить с помощью современных инструментов? Есть идеи?

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

>> Ну, то есть как бы если вот просто коротко, то есть в принципе у нас такой сейчас будет разговор. Я буду пытаться записывать, что должно быть и какие инструменты полезны, да. Во-первых, автодокументация, да? Ну, то есть если есть автодокументация, это уже хорошо. Ну, потому что как бы уже можно меньше документировать. У нас тут стать и помогает нам это делать там и так далее. А дальше, ну вот то, что я тоже приводил этот пример, это визуальный редактор бизнес-процессов. Это как в матрице, как в фильме хакеры. Я вспомнил, когда он там сидел и нам показывали, как он программирует. Она залетала камера в компьютер и там были такие, значит, красивые структуры, связанные между собой. Вот желательно, чтобы когда смотришь на код, были видны бизнес-процессы. Я визуальный редактор и визуальное, собственно, это представление. Правильно тебя понимаю?

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

>> Ну то есть меньше кодирования, больше визуального проектирования.

>> Всё верно. Всё верно. Кирилл, ээ, с твоей колокольней какие современные вообще что такое платформа, на твой взгляд? Во-первых, да, вот, >> да, это самый интересный вопрос. Аэ, что такое платформа? Мне всегда напоминает вопрос, что такое репозиторий. Вот те, кто в теме, понимают, что сколько людей спроси, столько ответов будет. Самое шикарное, что я слышал ответ- это было, что GitHub — это репозиторий репозиториев. То есть без ответов. А также, что такое платформа? Ну, платформа, на самом деле, это каждый поймёт своё. Вот мы сейчас Александр, от тебя слышали платформ именно на базе вашего решения, которое разрабатывает платформа это законченное решение, в котором можно создавать, модифицировать ещё какие-то решения, там, э, такой low cд, no cд подход. Э-э, с другой стороны, платформа вот, ну, так как я разработчик, так как у меня, в принципе, команда — это разработчики, а-э, для нас, я бы сказал, платформа, скорее, это не обязательно это должно быть единый инструмент, это может быть набор инструментов, но они должны быть собраны там, их должна быть сквозная методология работы между ними. у них должен быть идеально, если унифицированный интерфейс. Это как раз вот в случае, если один инструмент — это возможно, а в другом случае это должен быть одинаковый пользовательский опыт. Э, очень часто в ТЗ на различные крупные системы пишут, что, э, между инструментами и подсистемами, составляющими какую-либо информационную систему, должен быть одинаковый пользовательский опыт, а именно вызовы одинаковых действий либо нажать на одинаковые клавиши должны вызывать одинаковую реакцию. То есть вот это всё это создаёт именно в платформу. И поэтому платформа чисто технически вот это может быть набор инструментов, причём которые могут быть разных вендеров. Единственное, они должны показывать именно сквозной и законченный жизненный цикл чего-либо. внизу очень хорошая мне вот перед перед этой конференцией, перед тем, как наш круглый стол начался, я прошёлся по стендам, посмотрел, э, что очень хорошо видно вот по стендам фланта, как раз это то, что ребята делают платформу, у них появился функционал управления проектами и задачами, у них появился функционал гита, у них появился функционал управления секретами. Ну, то есть они делают платформу именно, то есть они взяли определённый процесс, и весь жизненный цикл этого процесса они покрывают своими инструментами вместе с методологией и с одинаковым пользовательским опытом. Поэтому я считаю, что, наверное, платформа это может быть как один инструмент, в котором полностью идёт разработка, так и набор инструментов, но они должны не противоречить друг другу, они должны реализовывать законченный жизненный цикл какого-либо процесса. И там же будет и документирование, и автодокументирование. То есть у нас начинается постановка задачи, затем управление требованиями, затем проектирование. Проектирование — это и отрисовка каких-то юзкейсов, это и макапы, это и там какое-то проектирование сценариев. Всё это ложится там. Дальше проектирование кладётся на модель C1, C3, дальше уходит на железо. Всё это сохраняется в каком-то там репозитории, репозитории модели, репозитории артефактов сетевой, типа там нетбоксы либо ещё что-либо. То есть, где можно потом посмотреть и уходить именно на полную автоматизацию, чтобы там была инфраструктура как код, документация как код. И, соответственно, дальше мы уходим. Это какие-либо платформы с переподпиской на ресурсы, это автоматизация тестирования и всё там управление требованиями. Там каждый тест непройденный должен создавать таск. Каждый secюurityге gate не пройденный должен создавать таск на исправление. автоматическое закрытие или нет, это не должно переходить руками в случае теста э-э создаём новую задачу. Нет, то есть это должно быть именно платформа. И любое событие должно иметь с собой создание какого-либо артефакта, отражённого либо в этом же инструменте, либо смежном инструменте. И тогда это получается именно платформа.

>> Вот смотри, я мм во всём этом тоже кручусь, как и ты. И а у меня такой вопрос. Я довольно часто слышу, что люди вот так же правильно понимают, да, говорят, а, но потом говорят: «Да, мы сами всё настроим». Вот. Ну, в целом в 2005 году, в 2005 году, ну, действительно, мы всё это делали сами. Там кто-то настраивал какие-то devopс процедуры, там кто-то какие-то сборки, кто-то настраивал там автотесты, но это было настолько ээ просто, если сегодняшней колоколь не посмотреть. Вот если сегодня меня спросить, сколько мне нужно времени, чтобы вот это всё настроить, ну, по мне так это суперколоссальное усилия. И к чему я веду? К тому, что целесообразно найти решения, в которых какие-то элементы уже собраны, да? Ну вот у ребят есть платформа, в которой они, а, немножко идут со стороны разработки, у нас есть, то есть мы друг друга можем дополнять. Вопрос такой вот ты работаешь в крупнейшей IT-компании России, да? Вот у тебя огромное количество ресурсов, ты в состоянии сам, в принципе, всё собрать. Для тебя вот самостоятельная сборка или поискать готовые инструменты? Как ты эту проблему решаешь? И что ты порекомендуешь компаниям, которые поменьше, чем ты?

>> Ну, сейчас, ээ, такой проблемы. Вот сейчас можно задать вопрос, так как ты его задал, а именно создаём своё либо выбираем. Если мы посмотрим на 4 года назад, двадцать второй год, когда резко большое количество инструментов исчезло, исчезise, исчезли GitLab E и так далее, то там выборов было гораздо меньше. Именно поэтому стали появляться Gitв, MOSHub и так далее, даже как замены Гитхаба. Сейчас, наверное, основной критерий — это TCO, то есть стоимость создания плюс стоимость владения. И вот от этого зависит, если что-то создать, скажем так, купить коробку и откастомизировать её и затем владеть будет дороже, чем сделать своё, то, естественно, надо тогда можешь оценить >> мо можно сделать своё. Единственное, да, я закончу маленький момент, но надо не забывать, каждый разработчик приходит в область, чтобы написать свой Facebook, >> да? Да. >> Поэтому это надо не забывать. Каждый считает, что вот как ты привёл пример, новая команда разработки, первые слова, которые делает, говорит любой разработчик, заглядывав в чужой код, какой чудак это писал. Да, >> я больше того скажу, я в свой код так заглядывал, тоже также. >> А это уже опыт. Вот интересно. А-а, вот если представить сегодня, что ты с нуля создаёшь вот такую платформу, в которой есть и автотесты, в которой есть и управление релизами, и управление, собственно, проектированием, и управление безопасностью, и управление там стандартами производства, вот команда людей, которые занимаются fullтайм только этим, это сколько человек? >> Команда, которая создаёт такую платформу, от 50 до 100. >> От 50 до 100. И если мы умножим на зарплату и умножим на дни, то есть это миллиарды рублей. Я к тому говорю, что не каждый может себе это позволить. Вот, допустим, я не знаю, зелёный банк, там синий банк, >> жёлтый, >> жёлтый банк. Вот, ээ, >> сколько цветов в радуге, >> да, они, наверное, могут позволить, там просто Телеком может позволить, но если компания размером там, скажем так, ну, у которой IT меньше чем 1.000 человек, ну, меньше чем 1.000 человек или меньше чем 2.000 человек, то, в общем-то, содержать свою команду отдельно, которой 50-100 человек только занятой платформой, ну, достаточно дорого. Вот поэтому, собственно, мы и вот с Артёмом уже, по-моему, третий или четвёртый раз встречаемся на эту тему и пытаемся донести мысль. Ребят, уже много современных российских платформ. Вот мы в это вкладываемся порядка 5 лет, коллеги в это вкладываются порядка 5 лет. Мы до друга дополняем на нашей стороне проектирование, автотесты, управление, собственно, созданием на их стороне, хранение кода. И мы там пересекаемся где-то, это наверняка. Но сегодня вот, собственно, и эта дискуссия посвящена тому, в том числе, что, конечно, а вот мы воспринимаем платформу как некий такой экзоскелет. То есть раньше можно было выкопать яму э лопатой, но сейчас можно надеть на себя некоторую такую штуковину или сесть в трактор и, собственно, ну, гораздо больше результата давать. У нас на нашем опыте уже команды там четыре-5ять человек из-под себя выпускают качественного кода столько же, сколько раньше команды выпускали по 15, потому что там и коды, генерация, и не надо париться на тему того, что такое infфобес. Там всё в платформе заложено и код полностью открытый и выпускается. Артём, тебе пару слов. Вот вы немножко с другой стороны заходите на это, но по отношению к нам, да, то есть мы с точки зрения вот мы, когда создавали эту платформу, мы шли вот по этому пути вот, который Сергей писал, нас очень сильно волновало, что люди пишут ТЗ в ворде и потом, значит, люди каким-то образом перекладывают это кто в Питон, а кто, значит, в Java. И разрыв происходит, да. Вот наша задача решить вот этот разрыв, да? А вы с другой стороны шли, со стороны дивопса шли больше, да? Вот вы куда пришли в результате и как вы на это смотрите?

>> Спасибо, Саша. Я, наверное, буду так отвечать сразу со многих углов. Э, во-первых, давайте сначала, да, новейшие подходы в создании эффективного конвейера разработки ПО. Мы сейчас вот так сфокусировались на платформе как, ну, важном инструменте как раз построения там эффективной среды разработки. И это так, это подтверждает статистика. подтверждается статистикой российской, подтверждает статистикой международной. Да, там может быть ээ нюанс, связанный с тем, что корреляция не означает наличие причин следственных факторов, но де-факто, если смотреть на метрики, те компании, которые поставляют лучше всего, которые разрабатывают лучше всего, как правило, являются пользователями платформ разработки разных. Те, которые они сами создали, те, которые они купили, там, кастомизировали, неважно. Вот есть такой любопытный факт. Второй любопытный факт, то что в России вот по данным там нашего опроса, который мы исследовали или там пятый год проводили, э порядка 47% респондентов сказали, что у них используется внутренняя платформа разработки. Тут надо понимать вот как раз а что такое внутренняя платформа разработки? Потому что у нас был пример проекта, когда нас пригласили ээ провести аудит некого набора шаблонов CD, используемых продуктовыми командами. э, в достаточно крупном холдинге, э-э, для того, чтобы мы как бы помогли их немножечко гармонизировать, устранили сопротивление команд, которые не хотели на эти шаблоны заезжать и так далее, но не суть. А когда у тебя есть шаблон? Шаблон — это нечто переиспользуемое, да? Вот у нас сегодня был классный доклад Антона Исанина, он рассказывал о том, как у них на платформе разработки эффективно используют шаблоны различных интеграций. Это может быть частично там пересекается с тем, о чём Сергей говорил, что хочется вот быстро

Как бы что-то, что забыли включить. А это уже платформа или это ещё не платформа? То есть у тебя есть нечто переиспользуемое. У тебя для этого переиспользуемо есть стандартный польский путь. Я согласен, это важно. А, но решается достаточно частная задача. Ну, быстро сделать из шаблона, э, конвейер.

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

Когда мы создавали нашу платформу разработки, мы пошли действительно скорее со стороны divса. Как создать среду, в которой можно ээ быстро э из шаблонов получать разное, в которую можно быстро разворачивать сервисы, в которых можно видеть состояние этих сервисов, в которых можно быстро автоматизировать ээ поставку под там новый стек, в который можно быстро отбороть людей. Это, кстати, тоже очень важный фактор, да, вот разработчики встали, ушли, да, вот новые зашли. Сколько сколько пройдёт времени между тем, как вот разработчик вышел на работу, сел своё рабочее место, условно получил доступа? Вот мы живём в идеальном мире. Он в первый рабочий день получил доступ. А сколько пройдёт времени, прежде чем он сделает свой первый коммит?

>> Первый коммит он быстро сделает какой-нибудь тестовый. Вот. Но бессмысленный.

>> Hello World.

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

То есть я вижу, что как бы, во-первых, чего чего мы все хотим, да, когда ведём разработку? Ну, по идее, мы хотим как можно быстрее поставлять ценность. Ну, вот я считаю, что это основная миссия там любой команды разработки. И правильно построенная платформа в этом, безусловно, помогает. Как её строить? Тут уже там мы можем с тобой дискутировать, какие тут подходы более как бы вызывают отклик на рынке, какие нет. Low-code, no-code, ээ, условно, каркас, либо какой-то предопределённый стек, потому что, ну, по сути, сейчас на рынке есть там все варианты реализации платформы. Чего должно быть важно? Единый поиск и опыт, востребованность и развитие, да? То есть платформа должна быть внутренним продуктом. Вообще по статистике ээ порядка 50% инициатив по внедрению внутренних платформ разработки проваливается. Ну или там не в полной мере достигает результата.

>> Хочется перебить, но ты подмени, когда можно. По поводу проваливается.

>> Вот поэтому есть как бы набор грабелей, которые люди собирают. Грабли известные. Вот их нужно уметь вовремя обнаруживать и как бы обходить. Ну,

>> если если не сложно, давай давай эту тему обговорим, потому что на самом деле я уже много раз пробовал разговаривать под платформы, и всегда в зале там процентов 30, а то может и 40 людей, которые примерно так реагируют. Слышали мы всё про ваши платформы. Это, короче говоря, вендорлок и, короче говоря, вот такая, значит, косоугольная яма, из которой не выбраться. Лучше мы сейчас сами всё запрограммируем, сами всё сделаем, и это будет быстрее. Вот. И в целом, наверное, опять же, в 2005, там шестом году, наверное, я бы тоже с ними согласился, потому что тогда, ну, такого широкого набора инструментов не было. Не было столько м опыта, который сегодня есть. Сегодня всё-таки мы уже живём в двадцать пятом, двадцать шестом году. И вот на мой взгляд, вот я вот убеждён, что без этого жить нельзя. То есть я я себе не представляю голый департамент разработки, не оснащённый вот этими вещами, которые мы сейчас.

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

>> это и Битрикс,

>> если их 15 человек, у них 1С и BТрикс.

>> Хочется спросить, а 1С — это платформа? В 1С есть, смотрите, DevOps есть. Интеграционный слой есть.

>> Платформа чего, Саша?

>> Ну вот платформа разработки. Можно её назвать платформой разработки? Ну то есть смотрите, она я как бы ну она обладает этими свойствами. DevOps есть.

>> Я вот тут, пожалуй, немножко по это тоже чутка с тобой не соглашусь насчёт дево. Пальцы девопс есть. Интеграционный слой есть. Слой по управлению данными есть. Говори. Нет. Есть слой по управлению данными, есть

>> слой по управлению процессами. Я скажу, что нет. Вот, чтобы было понятно. Но тем не менее, а когда вот мы с вами можем посмотреть сегодня, ну, не будем называть название, но всё-таки 1С раз то, что назвали, то мы видим, что как раз компании размером пять разработчиков способны на 1СЕ создавать решения, которые обслуживают заводы с большими оборотами. А это что означает? Но просто логически, что если есть подходящая платформа, то команда из пяти-десяти человек может из-под себя выпускать enterprise уровня софт. А а они же не 1С пишут, да? Они её дописывают. Ну, в том смысле, что они пишут кастомизации, необходимые для того, чтобы автоматизировать те бизнес-процессы, которые ситом заводит. Это не они, пять человек, прости меня, сили, и написали 1S ERP с нуля. Нет.

>> это не платформа разработки, а разработка на платформе 1С.

>> Во, спасибо.

>> Тут же важен объём э вот этих доработок, да, то есть кастомизации. Ну я про что сейчас? В идеале, да, 80%, ну, хотелось бы, чтобы так было, да, могло бы быть переиспользовано. То есть это и различные интеграционные слои, и объектная модель внутри, и модель справочников. И в идеале это как раз описать процесс и подцепить все нужные сущности в нужные этапы процесса. Вот это хотелось бы. От платформы как ну некого законченного, да, решения. Не то, как там платформу сделали, да, там взяли команду, сбоку прикрутили Keycloak, да, там и начали на и тоже и тоже назвали платформой, да,

>> вот и там ушли в кодирование там кучи микросервисов, да, на всём этом там на долгие годы. Я не о такой вот платформы именно, то есть 80% функционала готово, да? А 20 — это та кастомизация, которую нужно сделать. Вот давайте примеры поприводим. Вот мне интересно тоже. Я вот со своей колокольни сейчас маленький пример. Я был директором одного большого красного банка. Вот. И в какой-то момент я выяснил, что у меня справочников банкоматов 15. Там разные банкоматы, разные адреса. В зависимости от того, где вы находитесь, в интернет-банке или в мобильном банке или в каком вы находитесь браузере. Оказывается, разные показываются справочники с разными, значит, адресами, потому что, естественно, они все разъехались, про них все забыли уже, вот, и так далее. Мастердан,

>> да, и, ну, и так далее. Соответственно, вот наличие платформы, которые контролирует архитектуру, контролирует объекты. Ну, мне сильно лично помогло в тот момент, когда мы всё это вскрыли и стали унифицировать. Может, какие-то примеры вот похожие, которые в работе возникают, поприводите?

Ну, то, что ты сейчас сказал про справочники, вот абсолютно правильно, мастерданные, золотая запись, когда у вас много, как ты правильно сказал, интернет-банк, обычное обслуживание и так далее. У вас явно разные клиентские базы, и вам нужна где-то система, где будет храниться золотая запись, которая будет выравнивать всё это дело. Но смотри, мы сейчас вот во время дискуссии у нас чётко так вот разделяется, ну, где-то так, наверное, всё-таки посередине. А что платформа — это именно инструментарий конвейера разработки, и платформа — это конструктор для создания бизнес-приложений. Вот я бы вот так как раз мы так очень удачно сели и поддерживаем дискуссию. А-а где-то минут 10-12 назад ты сказал хорошую фразу. Я запомнил вопрос. А как раз дискуссия была о преимуществах именно вот таких конструкторов. Вопрос. И ты привёл пример как бы большого количества банков, крупных организаций, которые создают свои собственные конвейеры. Ну, именно конвейеры такого, да, там фиксация артефактов обязательных, шаблонов, требований, регламенты, там не пройдёшь на следующую стадию, если там не выполнено, то есть там блоки стоят именно на переход на следующие стадии. И почему вот как бы с того, что ты рассказывал, очень складывалось впечатление, что вот они куда-то, у них много денег, поэтому они туда идут, а могли бы вот взять вот какую-то платформу конструктора, всё было бы вообще в шоколаде. Вопрос: а что делать с Legacy? То есть когда у вас есть по компании, ну, где-нибудь 200 систем,

>> 2000,

>> которые Ну, подожди, я не пугаю аудиторию. А 200 систем, а развивающихся, там самая молодая, скажем, лет семь, а до самая старая лет 25 развивается исторически.

>> На каком на каком она языке написана?

>> Ну,

>> на Каболе, наверное.

>> Нет, на Дельфе, я думаю.

>> На Дельфе, что Дельфе.

>> А, соответственно, вот у нас есть такие системы. И в этот момент действительно это выглядит маркетингом, когда приходят и говорят: "Вот, вот конструктор, вы сделаете". Он говорит: "Прикольно, о, вообще супер. У меня вот есть вот там система старая". Вот эту фичубавьте.

>> Да. Не, вопрос очень правильный. Конечно же, во-первых, хорошо, что мы провели эту границу, потому что как раз мой основной тезис и вообще для чего мы тут собрались, и ровно таким образом я и подбирал вас, коллеги, вот мой основной тезис заключается в том, что пришло время соединить эту часть с той частью, и получится end to end решение, которое будет давать существенно больше результата, чем вот по отдельности. Мы тут ставим то, а там ставим это и как бы по-разному к этому подходим. Это раз. А второй момент, твой вопрос про Legacy, он правильный, оно никуда не девается, с ним надо обязательно как-то жить. А, и, естественно, всегда, в любой момент времени, вот когда ты срезаешь, там, смотришь на срез, у тебя в динамике что-то происходит. Что-то переехало на новое, где-то ты уже научился релизить раз в 2 недели, где-то ты научился релизить раз в месяц, а где-то до сих пор делаешь два релиза в год и молишься каждую пятницу тринадцатого, значит, что у тебя, э, чего-то не скроется. И поэтому, если ты посмотришь на свой ландшафт, он у тебя потихонечку, потихонечку, потихонечку улучшается, улучшается, улучшается. Тем не менее, какие-то Legacy в любом случае остаются. Тебе под них делают собственные конвейеры в любом случае. То есть, ну вот как бы я думаю, я ответил. Да,

>> да, я об этом и говорил.

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

>> Ну вот Сергей, сейчас я просто немножко в курсе ваших проектов. У вас сейчас, я так понимаю, активный период импортозамещения идёт.

>> Вот, собственно, в этом активном периоде как раз решается та самая проблема, которую Кирилл даёт. Старая Legacy переписывается на, по сути говоря, новый стек. Естественно, когда у тебя написано старое Legacy на Дельфе, ты его не будешь на Дельфе переписывать. Ты его будешь переписывать на современном стеке, сразу, ну, стараясь сделать его микросервисным. И, ну, вот в моём понимании как раз для этого это и нужна платформа. То есть есть старое Legacy и задача его переписать, переписывать его старым способом. Ну, по сути говоря, стрелять себя в ногу, да, надо переписывать новым способом. И вот этот новый способ как раз может быть на базе платформы. Вот у вас как с этим, Сергей, есть успех какой-нибудь?

>> Да, Саша, ну мы действительно, ну у нас нет шансов, да, с учётом того, что это постановление,

>> то есть, ну вот у банка, у них тоже порядка 400 систем, соответственно,

>> постановление, да, включая президента Российской Федерации, да, поэтому мы вольно или невольно, в том числе система, относящийся к КИИ, так или иначе там импортозаместили. Ну и, кстати, множество других, э, включая офисное ПО. А тут вопрос-то как раз в чём ещё по поводу тех, раз уж мы коснулись этой темы, да, там импортозамещения и вообще православного там тех, и больше того, к нам, как госкомпаниям, предъявляется ещё и то, что мы ПО, которое там так или иначе внедряем, я не знаю, будь то собственная разработка, будь то заказная разработка, сделанная там, я не знаю, какая-то написанная платформа, либо какое-то там коробочное решение. Вот они все должны быть как минимум реестровы и не иметь в себе компонентов, э, там open-source или ещё каких-то, э, которые, собственно говоря, не соответствуют, э, параметрам импортозамещения. Это как бы, ну, для нас это критичная история. Я понимаю, что она не всей страны сейчас ещё касается, но я уверен, что рано или поздно там, когда основные там госорганизации и системообразующие организации, извините, я перебью всё-таки. Вот если сравнить, вот у тебя на перед глазами есть проекты, где ребята переписывают как чёрный, ну как как BlackBox. Сидит подрядчик, пишет код, ты в него, в принципе, не видишь. А есть а платформенный подход, где вы используете. И ты можешь сравнить просто по где где где тебе спокойнее живётся, скажем так.

>> Да. Ну, э, Саша, вот смотри, я как бы начал, да, вроде так немножко шутейно, да, о том, как выстроен процесс. А по факту это же правда жизни. И ээ то, что там действительно приходится, вот когда мы делаем заказную разработку какой-то там платформы, когда при подрядчик приносит там какую-то кодовую базу, мы там её пытаемся сначала на своём уровне там развернуть на контурах, да, то есть она падает, не излетает и куча идёт разборок, с чем это связано, контура не те, не знаю, там, библиотеки не те, ещё что-то. А, и заканчивая тем, что, да, код написали, ошибка вылезла, даже пусть на функциональном тестировании ещё до ещё до бизнеса, да, не доходя до него. И вот этот разборка, а что же мы там такого накодили, а что у нас процесс блокируется? И другая ситуация, да, у нас есть там внедряемые там low-code платформы, да, в которых как раз, ну, может быть, не до конца красота, о которой мы там сейчас мечтаем, реализована, но тем не менее изменения-то вносятся значительно проще. Э, и там, когда мы нарастим компетенции по тем же там low-code платформам, э, нам не нужны будут там команды, э- там условно в классическом, да, как бы как варианте, когда у нас есть там системный аналитик, ээ, там frontend, backend, э, тестировщик, DevOps. Вот здесь, в принципе, всё дело ограничивается аналитиком, который же в этот же момент настройщик, и тестировщиком. Вот, собственно говоря, это как бы и фронт разработчиками это.

>> Ну а да, спасибо. И да, UX UI, как бы не надо забывать, да. Вот. Ну, наверное, так.

>> Ну, в целом вот у вас как у вас переписание старого LEG? Ну, у нас импортозамещение идёт точно так же, как у коллег. Мы госкорпорация, без вариантов. Мы переписываем информационные системы, российские операционки. Есть, ну, критерии, по которым мы отчитываемся. Ну, есть стратегия цифровой трансформации на

>> если если если если вот за скобками оставить, ну, поговорить только о прикладном софте, скажем так, да, не про операционные системы там, не про СУБД, а прикладной,

>> это вызов. Это, безусловно, вызов. Это мало. Ну, наверное, это, кстати, тоже про платформы. А-а в Ростелеком и в группе компаний огромная корпорация, десятки тысяч человек. Мы переходим, мы уходим с Windows и практически, э, полностью перешли на Alt Linux. Ну, то есть мы сменили платформу VTEL на платформу Alt на Intel или Alt там на

>> Ну вот если вспомнить там, не знаю, 2010 года там, да, ну, то есть до 2022, в принципе, ну, у людей не возникало вопросов, почему они выбирают, я не знаю, там, Axapta или Oracle E-Business Suite или там MS Dynamics, да, для того, чтобы решать прикладные задачи. Их, в принципе, не пугало то, что эта платформа, да, она может быть не очень хорошая, но зато мы можем быстро на ней что-нибудь сделать. Вот. Ээ

>> не соглашусь с тобой, извини. Крупные госкорпорации и те, которые компании государственные, для нас не в двадцать втором году началось импортозамещение. Ээ там первые KPI по импортозамещению, влияющие на там первых лиц организации, появились, по-моему, в году в 2017 даже. И то есть вот ключевые там объекты КИИ и всё прочее, оно начало и импорты замещаться ещё тогда. То есть всё, что критично, оно начало замещаться тогда. То, что ты говоришь, Axapta, всё прочее, но это наследие двухтысячных, то есть когда именно Enterprise жил по каким-то лекалам. В чём плюсы были коробок? И вот, в частности, там 1С. Ну, кто там в начале двухтысячных на 1С не пробовал писать? По-моему, все. Так же, как Delphi и 1С. Этот опыт прошли все. Ну вот как бы кто-то пробует там, может отметиться, что никогда в жизни не курил, но кто-то может сказать, что, наверное, не кодил на 1С. Но все, в принципе, 1С писали, что-то писали. Вот никогда не забуду там if then else, вот это всё только на русском языке. Ну это незабываемый опыт. А, соответственно, это всё идёт с тех времён. И вот тогда были 1С-конфигурация под такое-то предприятие, под такой-то тип бизнеса, под такое-то условие, ээ, именно там малый бизнес, ещё там мини-магазин, там чем он торгует. Вот под это всё были свои конфигурации. Вот в этом же как раз было и для больших корпораций AKAП, Oracle E-Business были SAP, тем более у SAP вообще без конфигурации под любой и под промышленность, и под управление всем. Это были готовые конфигурации, поэтому на них переходили, потому что ты получал сразу набор определённых методологий, отчётность МСФО готовая, ну, то есть всё, что требуется. И это было реально стоимость владения была ниже. Возвращаемся к TCO.

>> Угу.

>> Импортозамещение началось в госкорпорациях гораздо раньше, и мы критично начали замещать. Именно поэтому, наверное, для госкорпораций вот KPI по импортозамещению, они гораздо жёстче, чем для всех остальных. Ну, возвращаясь к нашей теме, вот почему мы пришли к импортозамещению, потому что на самом деле стоит задача по переписыванию старого Legacy. Его много и на системном уровне, и на прикладном уровне, и так далее. И, ну, мы вот видим, вот мы просто видим это по проектам, что, конечно, переписывать это всё без какого-то платформенного такого подхода, где стоят контроли на стандарты производства, на стандарты архитектуры, на переиспользование, на тот же вот визуальное проектирование бизнес-процессов, на горизонтальное масштабирование, на управление ролями доступа к безопасности, на DevOps. Раньше DevOps был вот как бы шесть букв и всё. Сейчас на него посмотришь, там это просто огромное количество процессов. И такое тестирование, и такое тестирование, и такое тестирование. Специальные нейросети настроены чисто на разные этапы DevOps там и так далее. Поэтому так немножко заканчивая, поскольку мы уже тут достаточно долго разговариваем, как бы как итог подвести. А, ну я со своей стороны скажу ещё раз, что мы вот мы видим, что два, ну, в современном мире платформа — это, по сути говоря, вот такой как бы экзоскелет Супермена, да? Так, без него ты просто ходишь, а с использованием платформы ты уже можешь выпускать из-под себя серьёзный софт. И у нас команды по четыре-пять человека, ну, работают, как раньше, команды по 15 человек, да, и это позволяет нам э реализовывать проекты по переписыванию Legacy там и так далее. Вот. И мы, кстати, очень сильно зависим от смежных частей. Допустим, у нас DevOps не сильно развит. Вот мы с коллегами работаем и Kubernetes их берём, и DevOps платформу их берём, потому что это всё соединяется в одно и получается end-to-end красивый процесс. А вот, ну вот, если подытожить, всё-таки первый вопрос. Можно ли сегодня купаться без одежды? Ну, то есть писать просто сегодня я бы не советовал погода плохая, да,

>> писать писать просто код, не используя какие-то.

>> А он не уточнил в какой стране.

>> Верно,

>> да. Можно ли

>> в каком городе?

>> Нет, это как читать ТЗ.

>> Можно ли сейчас купаться?

>> Вот так заказчик у тебя спросит, почему ты ему сдаёшь в Норильске, а не в Таиланде? Ну вот, ээ, имеет ли сегодня право на жизнь вот такой подход к заказной разработке, когда мы ТЗ получили, через 6 месяцев придём, тестируйте или всё-таки нужно, ну вот на ваш взгляд всё-таки немножко большее требование выставлять, заставлять разработчиков использовать определённые стандарты и лучше, когда эти стандарты контролируются не на бумаге, а вот именно с точки зрения платформы. Давайте вот пару слов вот на эту я можно быстро выскажусь. Вот, Саш, я считаю, что обязательно, особенно когда у тебя в основном разработка внешняя, да, делается подрядчиками. Обязательно нужно, чтобы эти стандарты были. Обязательно они должны как бы воплощаться, инфорситься технически. Ээ вот как бы если ты не хочешь, чтобы твоя кодовая база была абсолютно неуправляемая, чтобы ты мог менять подрядчиков относительно уверенно на разных стадиях проекта, обязательно надо.

>> Спасибо, коллеги. Вы как со стороны бизнеса реального,

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

>> 10 у на два

>> 10 площа не на два, на самом деле. А это dev, это test, это preprod. Ещё интеграционных слоёв,

>> да, это ещё n интеграционных. И вот, пожалуйста, мы сейчас насчитаем на 10 команд энное количество там с коэффициентом, ээ, со множителем пять, да, там или, не знаю, четыре, а количество инфраструктур необходимое. Ээ, вот с точки зрения платформы, инфраструктуры, да, мы же понимаем, что мы заложили инфраструктуру под платформу, и, собственно говоря, с этой инфраструктурой все команды, которые там работают по развитию платформы, они как бы находятся в рамках этой уже заведомо выделенной инфраструктуры. И мне надо больше, потому что, ну, мы уже как бы эту инфраструктуру туда положили. Это то, что касается стоимости. Ну и третье, понятное, ээ, там для бизнеса это, э, всё-таки там соблюдение SLA, выполнение, да, и, э, как раз вот здесь в платформе, да, которая, э, не собралась здесь и сейчас, да, по какому-то ТЗ, а где-то опробована, обкатана и стоит у большого количества там, например, заказчиков, да, там с вашей стороны, если смотреть на это всё, то и обновление к этой платформе, и какие-то новые функции к этой платформе, да, они, по сути, получаются автоматически в рамках договоров сопровождения. Вот чего, собственно говоря, лишена там разработка под заказ или собственная разработка. Ну и возвращаясь к скорости, да, я вот то, что первое, о чём проговорил, там сравнивая, ну, говоря о том, что платформа — это правильное движение, всё-таки вот я уже проговорил про это, да, 80% платформы готово и 20%, ну, это в идеальном случае, да, и 20% нужно кастомизировать. Это прямо реально та скорость, ну, хорошая скорость, да, которая позволяет не тратить время на создание вот этих вот базовых функций платформы, да, которые мы там имеем при заказной разработке. Э, ну и я сейчас не говорю о том, что как бы платформами едиными, да, там в моей жизни там был разный опыт, там и в другом банке я там как раз создавал микросервисную, да, как бы структуру большую.

>> Не, ну тут просто две платформы лучше, чем вообще ничего. Так и дальше. Вот, э-э, просто, да, ну, как бы всегда есть ещё здравый смысл, да. Вот. А поэтому, поэтому,

>> ну, хорошо. Кирилл, с твоей колокольни пару слов.

>> Ну, я хочу сказать, что

>> завершающих

>> завершающих как разработчику мне, естественно, ближе платформа именно как ээ набор инструментов с единой методологией, там законченный жизненный цикл, весь разработки, управления всем кодом. Но при этом я не могу не отметить, что за последние годы вот от традиционного подхода, когда была low-code платформа в виде какого-то исполняемого движка, который там и вендорлок, и потенциально там в случае нагрузки создаёт проблему, потому что там, ну, не там, условно говоря, извините, не подшаманить, потому что ты зависишь от разработчика этой платформы и пока он в ядре что-то там не отфиксит, ты будешь сидеть ждать, стали появляться платформы, которые именно дают набор исполняемого кода, которым, в принципе, ты можешь владеть. Вот. Это только можно приветствовать. Наверное, прививку от вендорлока в двадцать втором году все прошли достаточно жёсткую и больную. Но вот то, что стали появляться платформы, да, это действительно такой подход, как я сказал, это не вайб-кодинг, который, ну, очень сложно будет поддерживать, но это решение, которое можно будет использовать, в том числе где-то, может быть, при переписывании того же Legacy.

>> Спасибо, что пришли. Тема очень горячая. Мы это просто очень хорошо видим на сегодняшних проектах. У нас 95% проектов, ну, это, по сути говоря, все проекты, кроме одного, делаются на с использованием платформ. Просто мы видим, потому что это даёт результат. И мы видим, что у коллег ээ примерно такие же подходы и в крупных заказчиках. Спасибо за откровенный разговор. Будем ещё встречаться. На на носу у нас много конференций, если есть что добавить.

>> Нет, могу только присоединиться к вам благодарности. Спасибо, друзья, что пришли, поддержали. Саша, спасибо, что организовал. Друзья, спасибо, что были с нами во время этой панельной дискуссии.