Организованное программирование

Andrei Rebrov (02:23.589)
Да, что мы делаем сейчас? На самом деле сейчас мы делаем много всякого разного, поэтому давай буду по полочкам раскладывать, чтобы сложилась в итоге цельная картина. Основная, наверное, штука, которая нам приносит сейчас больше всего денег, это подписка на духи. В чем суть? Что духи стоят достаточно дорого. Хорошие дизайнерские духи стоят в среднем 100 долларов. Я буду оперировать местными американскими ценами, потому что они мне...

более известные на текущий момент. Соответственно, верх планка не то чтобы не ограничена, 200, 300, 400, 500 долларов за бутылочку с там 100 миллилитров духов вполне реально дать. Самые дорогие духи, которые я по -моему видел в магазине, были что -то в районе там трех тысяч. Соответственно, не все не всегда готовы столько денег за это отдавать. Мы когда начинали, нам в время написала даму, которая есть 500 долларов

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

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

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

Andrei Rebrov (04:46.021)
такие пахнущие баночки с палочками для комнаты. Потом мы подумали, а что если мы попробуем пойти в косметику? А что если мы попробуем делать свои собственные духи? Тогда маржинальность будет больше. В какой -то момент и выручка и аппетиты выросли. Мы купили другой подписочный бизнес под названием Drift. Эти ребята делают... И теперь мы делаем классный свежитель воздуха для машин. Тоже супер классный бизнес, который сейчас тоже классно попер. Вот. И

вопрос который тут встает а причем тут технологии как бы казалось бы сейчас мы живем в таком в такое время когда оно пошел в интернет зарегистрировался на условном шапифа и все дело сделан технории не нужны и программисты не нужны и вот этот вот ноукод лоукод все все очень здорово как обычно есть нюанс во первых когда мы начинали 11 10 лет назад была другая ситуация во вторых мы такие ребята креативные мы столько всего

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

Kirill Mac (06:06.446)
Да, сейчас мы с тобой об этом поговорим, это будет вообще основная тема нашего разговора, как технические подробности, грязные устройства вашей компании. А вот для того, чтобы масштаб был понятен, скажи, пожалуйста, что -нибудь в цифрах, объемы продаваемых клиентов.

Andrei Rebrov (06:21.925)
что -нибудь в цифрах. Соответственно, Сенбёрде сейчас 700 тысяч активных подписчиков на сегодняшний день. И суммарно мы сейчас отправляем около миллиона посылок в месяц, потому что есть Сенбёрд, есть Дрифт, есть всякие разные коммерс -посылки. С точки зрения выручки в том году мы дотронулись до 150 миллионов.

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

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

Kirill Mac (07:39.854)
Знаешь, я всегда в этом плане завидую с ас бизнесом, потому что на очень небольшое количество людей у тебя приходится, ну, на каждого человека довольно высокий объем денег, который компания обрабатывает, потому что, например, это тех, это операционный бизнес, и у тебя там как в аутсорсе, тебе нужны просто тысячи людей, держать выручку, ну, сильно меньше, чем у вас, и это, такая… Я как бы рад за вас, но не до конца, да?

Andrei Rebrov (07:48.677)
Да.

Andrei Rebrov (08:04.808)
Нет, слушай, я прекрасно понимаю, что в САСе всё совсем по -другому, потому что как только ты вступаешь в физическую... На самом деле даже в САСе ты всё равно в физическом мире находишься, потому что есть сервера, есть люди, есть вот эти все моменты. Но когда ты торгуешь физическим продуктом, актуальность закона Мёрфи возрастает просто в разы, потому что...

буквально все что может пойти не так оно все в какой -то момент пойдет не так это не вопрос если это действительно вопрос когда

Kirill Mac (08:35.918)
Да -да -да, ты еще, я помню, рассказывал по поводу того, что вас там своя, по сути, логистическая история. Не уверен, что мы это зацепим, но это тоже интересно, что у вас не просто сервис, который там

Andrei Rebrov (08:43.685)
Угу.

Andrei Rebrov (08:47.397)
У нас сейчас свой склад площадью 7 500 квадратных метров, который у нас сейчас там заканчивается стройка. И как только стройка закончена, еще туда будем пихать всякую разную автоматизацию. Не факт, что прям роботов -роботов человекоподобных, которых делает Илон Маск сейчас, но всякие такие мобильные роботы, которые возят туда -сюда коробки с товарами, такое скорее всего появится.

Kirill Mac (09:18.181)
Окей, давай попробуем перейдем к технологиям. Скажи, сколько у вас… Сначала такой общий вопрос. Сколько у вас получается разработчиков и какие технологии вы

Andrei Rebrov (09:27.653)
У нас сейчас 40 человек в разработке, не включая меня, потому что я все -таки больше в менеджменте, чем в разработке. Технологии. У нас есть две основные ветки. Меньшая ветка — это как раз -таки Shopify. Там всего вывлечено два человека, которые разрабатывают пять наших Shopify сайтов. А вот разработка Сенбёрда — это все остальные 38 человек. Соответственно там...

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

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

есть ветка связанная с соответственно с SRE потому что все это нужно как -то поддерживать все это должно не ломаться все это должно скелиться все это должно мониториться тут тоже достаточно стандарт на самом деле stack это графана это open telemetry это Prometheus это что еще такого ну как бы это нарастальные такие вещи внутри gitlab github

Кубернетизм, который я уже сказал и так далее. Есть ветка связанная с мобильной разработкой, потому что у есть свои мобильные приложения. Это мобильный, нативный Android, нативный iOS. И что еще? И это, наверное, такие основными большими мазками, что у нас есть. Дальше начинаются всякие разные...

Andrei Rebrov (11:44.037)
нюансики связанные с тем, как мы делаем тестирование. То есть есть тестирование функциональное, тут у нас Playwright, есть тестирование нагрузочное, тут у нас K6, есть тестирование на продакшене, тут у нас чекли. Мы можем пойти там глубже в, не знаю, в наши всякие интересные интеграционные вещи, потому что мы не все разрабатываем сами, это было бы невозможно, мы интегрируемся со всякими разными внешними ERP -системами.

Там у нас может быть и Dell Boomi в качестве Integration Hub. Мы сейчас делаем систему управления заказами. Тут мы прикручиваем команду для того, чтобы все это могло управляться без разработки в идеале. У нас есть всякие разные дебезии для того, чтобы работали поиски, все подцеплялись к новой клиенте. Много всего интересного. И, наверное, основная вещь, которой мы стараемся...

поддерживать, но опять же это не как самоцель от того, чтобы это все действительно было хорошее. Мы используем свежие, но уже проверенные технологии, потому что нам это и самим интересно. Это позволяет нам привлекать людей из рынка, которые такие, о, вас там Java не восьмая, а 22 -я, последняя, о, расскажите, как у вас там идет работа с виртуальными трэдами. Это нас был отдельный достаточно эпический переход, это вот оно стоило того,

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

Kirill Mac (13:22.67)
Кстати знаешь, кажется что я вот понимаю то что внутри там же очень много там и маркетингу нужно что -то делать да и визуальную часть менять и действительно ERP, CRM система интеграции сервисов и так далее и так далее и знаешь когда ты мне говоришь что у вас на такой объем клиентов а посещаемость понятно там еще больше и на ту сложность которая есть 40 человек вообще -то выглядит очень эффективно ты сам как ощущаешь

Andrei Rebrov (13:49.893)
зависит от того кого ты спросишь, CTO или CEO? На самом деле вопрос хороший, и это одна из тех метрик, и тут как бы такой небольшой шаг в сторону от инженерки больше в инженерный менеджмент, что одна из моих задач как CTO это управление бюджетами, и вопрос, который вполне себе насущный, особенно в последние несколько лет, когда мы огромное количество layoffs, а какое количество денег

Kirill Mac (13:50.382)
Или ты бы такой

Andrei Rebrov (14:19.429)
нормально тратить на технологии. И тут на самом деле какого -то правильного ответа нет. Потому что очень много всяких вариаций, но к чему мы по крайней мере внутри себя пришли, это следующее, когда речь идет не про технологическую компанию, не про Docker, не про Red Hat, не про, не знаю, AWS, а про то, что называется technology enabled, компания, которая

более эффективно занимается бизнесом за счет технологий, как бы и мы говорим конкретно про e -commerce и D2C, то общавшиеся с людьми, которые посмотрели на вещи чуть побольше, я, там люди с опытом 15 -20 -25 лет, они говорят то, что нормально считается в нашей индустрии 2 -4 % выручки отправлять на технологический

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

Kirill Mac (15:45.23)
Да, это правда. Я знаешь, сейчас что подумал. Я когда -то говорил про цифры, то что вы, понятно, взрослая компания, которой есть бюджет экономика, пиэнели, да, понятно, вы там просто четко понимаете, сколько денег вы на это можете потратить, относительно этого прыгаете. Я, честно говоря, думал, ты выше цифру назовешь, а потом знаешь, что я что подумал и понял, а ведь правда, вы же занимаетесь, по сути, не просто комом, у вас офлайн

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

Andrei Rebrov (16:28.837)
Конечно.

Kirill Mac (16:38.382)
Это интересно, прикольно, прикольно. И получается, что, смотри, ты сказал, у вас есть фронтендеры, остальные ребята в основном это джаовые ребята все,

Andrei Rebrov (16:46.213)
Это Java ребята, да. Основной объем ребят -инженеров это Java backend. В случае внутренней системы это full stack, то есть сами же ребята делают frontend на ангуляре, потому что она позволяет нам быстрее... Ну, условно тяп -ляп и погнали. Плюс во многих случаях frontend может не так сильно меняться. И основной интересной вещей происходит

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

Kirill Mac (17:37.678)
Давай попробуем, знаешь, зайти с какой стороны. Немножко с исторической точки зрения, потому что интересно, как и менялось. мы про Naim тоже поговорим. Я могу тебе напомнить, когда ты только собирался переезжать, ты тогда мне написал, говоришь, типа «Кирилл, по технологиям чё и как», и я помню, с тобой обсуждали тогда Grails, то есть рельсу, Grails и так далее.

Andrei Rebrov (17:45.061)
Угу.

Andrei Rebrov (17:57.317)
Угу.

Kirill Mac (18:00.43)
Я не знаю, какой ты выбрал в итоге решение, но по -моему, тогда в Грейлс и выбрал. То есть вы 100 % начинали с него, да? Тогда это было нормально, груви, все дела. Но сейчас я услышал, что там спрингбуд, то есть очевидно, вы куда -то съезжали, то есть расскажи, пожалуйста, эволюцию и почему, в какой момент вы поняли, что что -то там мешает и почему

Andrei Rebrov (18:14.949)
Угу.

Andrei Rebrov (18:19.141)
Да, эволюция на самом деле это... Как бы так описать? Мы всегда, когда обсуждали технологии, для нас основным критерием выбора технологий было, как быстро мы сможем приносить цены с бизнесу. С учетом выбранных технологий, насколько это в принципе долгосрочная...

долгострочной стратегии. есть когда мы начинали, и в принципе, когда ты начинаешь какой -то новый стартап, что для тебя важно? Тебя важно построить какой -нибудь MVP, прототипчик и отдать его людям. Поэтому, на самом деле, самая первая технология, был PHP с там купленный template, который заливался на сервер с помощью FTP, FileZilla, по -моему. Что -то было такое. Быстро, с jQuery на Frontend, и все здорово, все проверяли.

Потом уже началась нормальная разработка, и тот действительно выбор пал на Groovy Grails. Почему? Потому что я сам по себе джавашник, и долгое время предстояло именно мне заниматься всей разработкой, поэтому я хотел писать на том языке, который я смог бы эффективно поддерживать в продакшене и быстро на нем, если что, делать какие -то хаки. Но весь предыдущий опыт джава, который у меня был, это Enterprise 'ное джава.

То есть, так как я работал в олдсорсерах, я работал на всяких ребят типа UBS Bank, и там это Java, это EGB, это GSP, это там Apache Strats, что -то такое прям ого -го, где ты долго -долго -долго пишешь много XML, и потом у тебя появляется какой -то фронтент. Очень больно, очень сурово, очень enterprise -ненько. Вот. А когда я из enterprise ушел,

я тыкался -мыкался в разные стороны и в какой -то момент попробовал Rails. И мне так понравилась возможность быстро создавать веб -приложение, что это было круто. Я такой вот думал, вот как здорово, люди живут, а вот в Java такого нету. И, собственно, в какой -то момент я сначала узнал про Groovy. И самое забавное, что про Groovy я узнал из курсов по тестированию. То

Andrei Rebrov (20:38.021)
так как меня интересовала в принципе вся инженерка и я изучал разные направления и в том числе я изучал автоматизацию тестирования и попался мне замечательный курс боюсь соврать фамилии автора курса это российский комитер селениума не помню как его не барановский его всегда можно найти вот

И он все свои примеры писал на Groovy. Я такой думаю, о, какой классный язык, похожий на Java, но без этого всего лишнего там, мусора, эти точки -запятые, скобочки, короче. Классно. Раз -раз -раз, все написал, все заработало, в консоли запустил, топ. Вот бы был у него еще web framework. И оказалось то, что web framework на самом деле есть, это был Grails. Который делали, разрабатывали ребята из OCI, американской конторы, и соответственно вот на нем -то и пошла

И вместе с Grails прожили мы достаточно долго То есть это мы начали писать в 2014 году И по -моему с Grails мы жили вплоть до того момента пока Grails не стал умирать То есть это мы начали сам с Grails 2 .3 по -моему Он долго -долго менялся, ребята долго обещали что сейчас выйдет третья версия Сейчас -то мы заживём

Она вышла, но после выхода Grails 3 начали отпадать разработчики Grails. есть один из ведущих разработчиков Grails на тот момент, Грейм Рош, он ушел из OCI в Oracle и начал пилить потихонечку фреймворк под названием Micronaut. Но фреймворк -то джавашный. И постепенно люди из команды OCI, люди, которые писали Grails, начали распадаться. Кто -то ушел в Google, кто -то еще куда -то ушел.

И стало ясно, что такими темпами мы скоро получим достаточно мёртвый фреймворк, который не развивается. И было принято решение, давайте -ка мы пойдём на то, что мы все хорошо знаем, на то, что доказал свою стабильность, тем более, что она улучшилась. И это стало в Spring. То есть это был Spring... Какой там? Spring framework версии 2 .7, на которой мы всё перемигрировали, все наши Groovy Grails проекты. На самом деле не все.

Andrei Rebrov (22:56.645)
Я тут немножко укавлю, у нас до сих пор в продакшене есть три микросервиса на Groovy, которые я надеюсь мы в ближайшее время полностью уберем. вот по иронии мы сегодня записываемся, вот именно сегодня я в эти проекты лазил, какие правки делал. есть оно все еще там потихонечку дышит, но дышит уже наладом.

Kirill Mac (23:19.63)
Извини, это еще не спрингбут, то есть вы на спринг пошли, а спрингбута, наверное, тогда не было. А,

Andrei Rebrov (23:23.909)
Спрингбут, не спринг, а именно спрингбут, да. Тем более, что на спрингбут в этот момент он стал более -менее адекватным, и у Шва необходимо списать огромное количество ХМЛ, что все всегда терпеть не могли, но как это, ежики кололись, но продолжали есть кактус. Вот мы, как джаву -программисты, как те ежики, продолжали писать ХМЛ, пока язык не стал более декоративным, аннотация, это все. Проблема спрингбута, то что он большой.

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

то это у так тормозит. Оказывается, там гигантские совершенно запросы, совершенно неоптимизированные, но зато HyperNet за нас все это сделал. Мы не мучились с поддержкой SQL -записи. Вот. Поэтому мы на все это смотрели, смотрели, смотрели и поняли, что так какое -то время можно пожить, но это совсем не здорово. Вот. И мы начали потихоньку думать, куда отходить от Spring, от Spring Boot.

Вот, и на тот момент микронавт начал из себя уже что -то начинать представлять. Мы на него долго -долго смотрели, пока он не стал production -ready. Мы в это время делали другие переходы. То например, от Hibernate мы ушли в Juke. То есть у нас контролируемые запросы в базу. Мы... Одна из преимуществ, которые

пячивают фанаты Hibernate, вы с легкостью можете перейти с одной базы на другой. У вас есть Postgres, вы можете перейти на Org database и все, у вас будет здорово. Давайте будем честны, такие переходы случаются крайне редко, и только ради этого иметь Hibernate, но это сомнительное удовольствие. Поэтому мы перешли на джук, что нам позволило уже более эффективно делать запросы. И в какой -то момент начали миграцию на микронавт. То есть у нас...

Andrei Rebrov (25:42.085)
На тот момент было около 20 микросервисов и вместе с Migration Micronaut мы начали наши макросервисы переписывать во что -то более похожее на нормальные микросервисы, которые легко стартуют, которые легко запускаются, которые действительно single responsibility и вот все у них хорошо.

Kirill Mac (26:01.39)
Извини, а тебя спрошу передиом. Да, просто... тут переход очень интересный. В принципе, то, что вы выбрали, наверное, Hibernate, это, может быть, была более ранней историей, потому что сейчас от JPEG Data, да, там часто попроще уже. В принципе, если ты выбираешь, у тебя уже таких проблем особо нет. Но я не совсем понял вот этот вот момент. То есть вы перешли на него, а какие проблемы прям настолько стали для вас проблемы, что вы пошли дальше? Потому что, в принципе, если ты говоришь конкретно про базу, то это решаемый вопрос.

Andrei Rebrov (26:13.221)
Ну да.

Kirill Mac (26:29.198)
А что еще такого было настолько критично, что вы даже с Spring Boot 'а пошли дальше? Почему я это говорю? Потому что Spring Boot все -таки используют... Многие, если кто Java 'ей владеет... Ну, типа Spring Boot – это классический микрофреймворк, но, огромной обвязкой, там куча всяких возможностей. И него большинство бектехн, российского, они тебе скажут, что «а мы Spring Boot 'ы используем». И, в общем -то, у них -то большие системы. Что такого стало прям критического, что такие «нет, Spring Boot вообще никак».

Andrei Rebrov (26:34.469)
Угу.

Andrei Rebrov (26:40.421)
Угу. Да.

Andrei Rebrov (26:50.949)
Угу.

Andrei Rebrov (26:57.957)
есть три вещи, которые я могу назвать сходу, которые в Spring Boot не устраивают. Первое — это долгое время старта. Казалось бы, а что тут такого? Это все выливается в то, что сейчас модно называть developer productivity. Когда у тебя много микросервисов, и ты начинаешь заниматься запуском твоих интеграционных тестов, пока ты дождешься, пока они все запустятся.

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

Поэтому это первое, что не устраивало в Spring Boot 'е. Что он очень долгий. И как бы его можно попилить. Вот. Но тогда это уже не Spring Boot. Получается, ты там что -то побрезал и короче. Начинаются какие -то поделки, которые ты уже сам становишься ответственным. Как их поддерживать? Хочешь все -таки иметь framework.

Kirill Mac (28:17.806)
А я... Ага, слушай, а вот эта история с тем, что у тебя Gradle там в беке его стартует и переиспользует, она не

Andrei Rebrov (28:27.237)
Все это помогает. То есть и Gradle, и Gradle Cache, и тест контейнеры, и многое всяких разных историй. Но в какой -то момент ты все равно упираешься, ты не можешь пойти дальше. вот... Оно все равно в какой -то момент ты не можешь его ускорить. Когда хотя ты видишь, что переход на микронавт той же самой кодовой базы, просто с банальностью вот быстрее. Тебе нам много вещей не нужны, которые есть в SpringBloot. ты, опять же, Петрович, ты можешь их ручками...

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

Ты такой, ребят, а почему у нас вдруг столько всего мы потратили на наш амазонский счет? И ты начинаешь разбираться, ага, вот тут мы начали скелиться, вот тут мы были вынуждены отдать столько -то там машин. Давайте разберемся, а почему нам нужны такие машины с таким бешеным использованием Java? Как бы Java славится тем, что она жрет ламедь. Она любит

оперативной памяти да побольше да пожалуйста давайте мы там сейчас настроим 16 гигабайта дадим и джави будет хорошо хочется все -таки это как -то уменьшать хочется микросервисы были микросервисы это втором третий вен который в го сейчас хода приходит это на самом деле наша головная боль последнего времени это контекст

который начинает портиться и ломаться, когда ты делаешь всякие моковые бины и запускаешь интеграционные тесты. Это известный баг в Spring Boot. Тем, что у тебя в контексте подмешиваются разные моки, и они начинают друг другу, как бы они начинают друг другу тесты ломать. Вот.

Andrei Rebrov (30:43.269)
на GitHub -е ишью заведено, бог знает когда, но вот пока никак. В Микронапте это решено как бы по -другому сделано в принципе весь контекст, по -другому выставлен процесс интеграционных тестов и там этого не возникает. То есть мы у себя ведь как бы нам пришлось действительно у себя прийти к тому, что у нас есть restart тестов для того, чтобы убрать эти тесты, которые в Flaky, которые то проходят, то не проходят. И это опять же увлечает время билда.

мы переводим тот же самый микросервис с той же самой кодовой базой, со Spring Boot 'а на Micronaut, все тесты больше не падают. Это как бы та штука, которая была нашей головной болью последнее время, и вот оно такое есть. Дальше уже начинаются вопросы производительности, сколько мы там можем обработать запросов в единицу времени, и тут опять же...

Kirill Mac (31:17.006)
Я понял.

Andrei Rebrov (31:35.461)
микронавты поддерживают хорошие, дают хорошие результаты. А, есть еще один момент, что микронавт это штука, которая нативно переводится в ГральВМ. И это опять же все к вопросу о том, как быстро запускаются микросервисы. Еще один момент, когда тебе нужно, чтобы твои микросервисы запускались быстро, это когда к тебе пришел трафик, тебе нужно заскелиться. Это на самом деле тоже одна из специфик нашего бизнеса, что

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

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

Kirill Mac (32:52.654)
Похоже на новостники, В новостниках такое, когда у тебя трафик растет просто очень быстро и надо скелиться. У вас, куб этим занимаются или вы сами там что -то выстраиваете?

Andrei Rebrov (33:00.677)
У нас этим занимается Куб, но с новостями другая. Как бы, в чем разница новостников и e -commerce? Новостники могут это отдавать как статический контент. То есть, они статью сделали. Да, там понятно, что есть какие -то виджеты, связанные с рекламой, там котировки и прочее -прочее. Но если надо, они отдали это как статику. А у нас e -commerce, у людей есть их существующая корзина.

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

Kirill Mac (33:38.158)
я понял. Я бы, знаешь, повернул, то есть я понимаю, что у сейчас есть развилка, и джавовая специфика, все -таки слишком специфично, потому что мы могли бы тобой там поговорить про особенности фреймворков, но мы понимаешь, да, уйдем туда, куда интерес только джавистам. Давай попробуем повернем в сторону микросервисов, потому что ты уже много про это говорил, и мне кажется это офигенно, потому что про микросервисы не со всеми хочется разговаривать, знаешь почему? Потому что очень часто это

Andrei Rebrov (33:52.421)
Угу.

Andrei Rebrov (33:58.821)
Угу.

Kirill Mac (34:07.886)
типа, мы это делаем, потому что надо делать микросервисы без понимания. У вас очень сильная связь с бизнесом, я уверен, что вы очень адекватно подходите к выбору того, почему и в какой момент это внедрять. Давай немножко назад откатимся и вспомним тот момент, когда у вас, скажем, еще был монолит. И опять же, мы же не говорим про микросервисы, мы говорим просто про проблемы, которые стали возникать, и дальше что -то вы начали с ними делать. Вот расскажи момент, в котором вы поняли, что тот монолит, который у вас есть, вас по какой -то причине не

Andrei Rebrov (34:23.013)
Угу.

Andrei Rebrov (34:36.357)
Да, смотри, первый Monolith был ясным приложением с сайтом Sunvert. Больше ничего не было. Но как только тебя появляется сайт, тебя появляется бизнес, тебя появляются клиенты, клиентам нужно как -то помогать. У них возникают вопросы, а что, как, куда. У меня тут, пожалуйста, отменить платеж, мне, пожалуйста, поменяйте, что меня в посылке лежит, и ты начинаешь заниматься CRM -системой. Customer Relationship Management.

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

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

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

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

Kirill Mac (36:40.334)
Игорь, а вот, извини, я да, я тебе буду прерывать иногда, потому что тут нужно доуточнить. Смотри, несколько моментов. Первое, блиц быстрый. То есть, момент, вы это все сделали вместе, какой размер уже был бизнеса? Просто интересно в том плане, что, типа, это уже было что -то серьезное или еще только -только начиналось?

Andrei Rebrov (37:00.165)
Это было...

Наверное, в районе 20 тысяч клиентов уже на тот момент у нас было.

Kirill Mac (37:11.954)
20 тысяч — это довольно серьезно на самом деле, то есть это уже вполне себе, вполне себе, да.

Andrei Rebrov (37:16.357)
Это вполне себе. То есть это было уже три программистов на бэкэнде, включая меня, и один фронтендер, потому что мы выделили фронтенд на сайте в отдельную сущность, потому что ну как бы я очень плохой фронтендер, очень плохой. Вот, моя попытка перевести это на реак. Я закончил перевод на реак, но это была, самая худшая имплементация фронтенда на реакте у максимальной топорды. И мы налили человека, который сделал это нормально.

в соответствии с тем как описан без практикс для реакции на тот момент времени. Вот поэтому вот три бэкендера и один

Kirill Mac (37:54.094)
И получается, что вы приняли решение Serenq делать сами по каким -то своим причинам, и может быть вы даже об этом жалеете, потому что у нас Serenq точно не своя, а может быть не жалеете, не знаю. Но в любом случае, в общем, идея была в том, что это два независимых То есть очень важно, что это никакими словами микросервиса это не называется, да, то есть это просто два сервиса, вы хотели разделить. Потому что по факту, на самом деле, два разных проекта, ну так -то с визуальной точки зрения. У меня тогда вопрос.

Andrei Rebrov (37:58.757)
Угу.

Andrei Rebrov (38:13.413)
Вообще нет. Два приложения.

Andrei Rebrov (38:20.101)
Да. Да.

Kirill Mac (38:23.694)
под кором, просто когда сначала сказал кор, я думал, вы сделаете как? Это два проекта, но одна база данных, и вы, например, делаете модули в смысле библиотеки общие, в которых хранится логика, а вы именно решили сделать, что у вас есть некие общие, типа кор, просто опишка универсальная, и к нему два фронтэнда, можно сказать, один админский, второй для людей.

Andrei Rebrov (38:43.429)
Мы на самом деле все сделали максимально неправильно. есть у нас были и... Например, сущности были шаренной меблиотекой. А какая -то логика была в виде API, которая работала уже с базы данных. То есть у нас была единая база данных. Единая база данных оставалась очень долго. И даже сейчас есть отголоски этого. То есть ряд сервисов ходят в одну и ту же базу.

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

Kirill Mac (39:27.502)
И вообще библиотека с моделями, конечно, это всегда приводит к последствиям. И вы пошли в эту сторону.

Andrei Rebrov (39:35.429)
Ну, cnvertdomain .jar и погнали. Стандартно. Тоже Java -C -Dot.

Kirill Mac (39:40.27)
Я знаю, что я сейчас услышу, что ты сейчас расскажешь. Хорошо, давай дальше. Так, это сделали, да? То есть это не… получилось?

Andrei Rebrov (39:49.413)
Да, мы это сделали. вот как бы... Тут такой момент,

Andrei Rebrov (39:59.109)
Наверное, даже еще кому везет те еще в университете слышат про правильные подходы к построению системы, к архитектуре, что в базе у нас должна быть нормальная форма, что у нас должно быть правильное деление на сервисы, у каждого сервиса своя база данных, все там хорошо описано, пиа и все, раздельно, все здорово. Потом можно прийти в какой -нибудь

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

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

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

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

Andrei Rebrov (42:18.757)
Сейчас у них вообще нет базы, там вынесены кусочек логики. Все это здорово. Но сейчас и другая команда, сейчас и другая реальность, сейчас другие требования на все это. Вот, поэтому это такая классная тема подискутировать. Вот, особенно там, не знаю, после какой -нибудь конференции посидеть, поговорить за кружечкой кофе, кто как у себя строит архитектуры, почему так. Вот, но всегда нужно понимать,

Andrei Rebrov (42:48.709)
В каждый момент времени от бизнеса приходят разные требования и поэтому надо как -то подстраиваться.

Kirill Mac (42:54.638)
Я хочу сделать небольшое отвлечение на эту тему. Вот то, что ты сказал, просто добавить. Потому что слушают ребята, я периодически пытаюсь это доносить и как -то развивать эту тему. Она связана с чем? Что вот ты, например, работаешь в компании, где у тебя не только разработка, да, ты видишь там маркетологов всех подряд. Большинство разработчиков же этого не видит, ну или видит просто как. Ну какие -то отделы, что -то от них хотят. И вот когда ты наблюдаешь работу разных вот этих подразделений, ты понимаешь такую вещь про программистов одну.

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

Andrei Rebrov (43:41.925)
Угу.

Kirill Mac (43:47.502)
и у тебя нет шансов сказать о том, кто был из них прав и кто из них лучше, потому что это так сильно контекстно зависимо, что конкретное решение было нужно. Поэтому всегда, когда какой -то человек в программировании говорит про то, как правильно, ты никогда не можешь делать вывод, что он молодец, потому что, может быть, он и делает это в той ситуации, когда так делать нельзя ни в коем случае, и в итоге топит бизнес. Но никто этом сказать не может в компании.

Andrei Rebrov (43:54.181)
Угу.

Andrei Rebrov (44:10.757)
Все так. И на самом деле одна из самых сложных проблем и задач в работе — это построение системы Медрик и КПА, которые покажут, как команда разработки успешно влияет на бизнес. Я могу как бы... Что здесь легко сделать — это траты. Траты посчитать легко. Как бы они фактически... Это факт, который существует. Сколько мы потратили на сервера, сколько мы потратили на зарплату и так далее.

А вот как посчитать, связать между собой скорость разработки, сколько story points мы сделали, сколько денег мы заработали, невозможно. Это физически невозможно. Поэтому всегда мы начинаем думать, окей, ребята, вот есть сфера нашего влияния. Это наши сферы, и они должны работать.

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

Вот у нас есть сайт, у него тоже есть свой SLA, SLO. Он должен работать. Понятно, что есть внешние платежные сервисы, которые могут отвалиться, Cloudflare, который всегда может отвалиться и обрушить половину интернета и так далее. Но есть вещи, которые мы влияем. Давайте мы будем бизнесу говорить то, что, ребята, в этом месяце у нас не было негативного влияния от нас самих на наши вот эти собственные показатели. И это уже будет хорошо. И бизнесу как бы это...

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

Andrei Rebrov (46:28.517)
видео, тексты и картинки, которые они придумали, тоже не прошло. Поэтому стараешься говорить какими -то фактами, стараешься сужать область влияния на то, что ты мог испортить. Вот, это вещи, которых проще как -то померить, насколько хорошо ты делаешь свою работу.

Kirill Mac (46:47.726)
Во многом это сводится по сути к вере. Разработка чем отличается от остальных вещей? Для меня, когда я вижу, что происходит, ты должен взять руководителя такого уровня, которому ты просто можешь верить. что он никогда не предоставит тебе доказательства о том, что все эффективно, классно и здорово. есть так, к сожалению, не работает. И мы тоже ищем, пытаемся найти. Все пытаются, там грейды, все что угодно. Но как -то оно работает скорее на

больше, чем на всём остальном.

Andrei Rebrov (47:19.077)
Ты можешь быть эффективнее только самого себя месяц назад. Вот и всё. Это знаешь, тоже такой немножко отличённый пример. Я вот занимаюсь кроссфитом, и это отдельно большая тема, почему, зачем и прочее -прочее. Все говорят, ты что, пойдёшь на стадион кем соревноваться? Я нет, я соревнуюсь чисто самим собой. Что одно и то же упражнение я сегодняшнее могу сделать лучше, я его делал год

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

Kirill Mac (48:00.11)
Ребят, кто нас слушает, вы с нами не согласны или согласны, пишите обязательно комментарии, что вы об этом думаете, потому что это очень интересно в плане того, как оценивать разработку, надо ли вообще оценивать и какое все это отношение имеет к бизнесу. Возвращаясь к нашим микросервисам, ты сказал про этот переход, который

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

Вот очень классно теперь смотреть на эту... Вот вы сделали эту систему, и вас было при этом примерно пять человек, и какие начались проблемы, то есть где вы начали ловить.

Andrei Rebrov (48:58.181)
Где мы начали ловить?

Andrei Rebrov (49:04.005)
кто -то где -то не обдавил библиотеку. то есть у Сонн, говорю, вот у тебя есть библиотека, которая... На самом деле, мне кажется, классический такой пример. Вот ты обновил сущности. Шарина библиотека. В Либе, да. И ты потом обновил только сайт. И у тебя такой админка такая, о -о, а что это тут за какие -то новые...

Kirill Mac (49:17.166)
В Либе, в Либе,

Andrei Rebrov (49:28.485)
как бы, а я не ожидать, что такие данные придут в рамках этой колонки. И ты начинаешь такой, так, мне нужно домен теперь отделять от миграции. В принципе, вопрос миграции база данных начинает вставать большим момент. Давайте сделаем процесс, как мы это накатываем, как мы это обновляем, как мы делаем сеть библиотеки. Первая, наверное, встает на сущность. Потом ты такой, так, у меня

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

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

это отправить email клиенту, что пожалуйста, обновите у вас платежный метод и так далее. У тебя появляется вот эта вот background -ная часть работы. И ты понимаешь, что иметь ее в том, как бы, это и не core, это и не site, и ты создаешь еще один сервис. И таким образом количество сущностей у тебя увеличивается, и это добавляет сам в себя головняк. А дальше начинаются штуки, которые ты должен запускать, как то, что называется, джабы.

например, нужно перечитать.

Andrei Rebrov (51:29.733)
А, не так. Ежедневно в 6 утра склад получает список заказов на отправку. Что это такое? Это регулярная джаба, которая запустилась в 5 утра, чтобы дать этот список клиентов. Или тебе нужно на ежедневной основе посчитать, получить список клиентов, которые должны получить конкретную письму. Тогда нас еще email -маркетинг был полностью завязан на разработку. И тебя появляется модуль jobs. И опять же, для того чтобы его никаким образом не задевало дипломентами, ты его тоже...

выносишь в отдельный микросервис, потому что его желательно не трогать, вот он работает и ты его там деплоешь, только когда все джебы выключены и так далее. Увеличивается количество сущностей. А какие из этих сущностей тоже начинает между собой логику шарить, и ты такой, так, что делать? Мне делать Либу или мне делать еще один сервис? Либы делать не очень хочется, потому что опять же, стоит вопрос, как эти Либы обновлять? Ты такой,

сделаю микросерс, как бы я один микросерс обновил, один API, все, сразу логика везде подхватила, все здорово.

Да, но нет, опять же, с API -ем какой момент, что... Как ты делаешь это API? Ты даешь какой -то SDK, что с этим работает, или у тебя еще какие -то зависимости. Например, сейчас у нас все взывается по gRPC, соответственно, у есть gRPC -интерфейс, тебя есть gRPC -либо, который ты всем раскидал, всем отдал, все это использует. Или ты просто ходишь голым курлом. Как бы мы так никогда не делали, но такие варианты тоже видел.

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

Andrei Rebrov (53:34.469)
Не то чтобы разрезать тем, появляется совершенно новая логика, которую нужно в разные сервисы добавить, разные сервисы внести и совершенно новое что -то концептуальное сделать. Например, тебе требуется новая интеграция. Удеально новая интеграция это тоже микросервис, который себе логику работы с этой внешней зависимостью поддерживает. Например, интеграция с сервисом проверки адресов. Потому что для того, чтобы люди не вводили всякого прокадабра на сайте, тебе это нужно вылидировать.

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

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

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

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

Andrei Rebrov (56:00.197)
Опять же, наш любимый корневой модуль, мы начинаем замечать то, что у него есть разные куски. Есть работа с пользователями, есть работа с платежами, есть работа еще с чем -нибудь, с посылками, с продуктами и так далее. Ты начинаешь каждое из этих модуль уделить. А потом ты видишь, что в рамках работы с платежами есть вещи, которые запрашиваются чаще, есть вещи, которые запрашиваются реже. В идеале тебе бы их по -разному скелить.

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

Kirill Mac (56:53.07)
Да, там еще и распределенные транзакции, трекинг, всего этого, доброта, много всякого интересного, Но знаешь, я хотел что спросить, где здесь был переход именно к пониманию, что вы конкретно строите микросервисную архитектуру? Потому что я вначале понял, то есть вот мы сервисы сделали, потом сервисы начали дробиться, но микросервис это же не просто размер, это еще некий способ деления, да, и еще какие -то моменты. Вот, можешь сказать, в какой момент вы такие, так...

Andrei Rebrov (56:58.437)
Да.

Kirill Mac (57:19.31)
Стоп, пора остановиться, пора переосмыслить то, как мы разделяем и предменять какой -то другой подход и давайте типа, о, это и есть микросервисная архитектура, все делим по -другому.

Andrei Rebrov (57:29.765)
Наверное, вот с переходом на микронавт мы поняли, что ребята, так делить сервисы вообще не оленя. Давайте посмотрим, действительно разберемся, как работает framework, научимся им правильно пользоваться и будем делить вещи уже с осознанием того, как мы это хотим делать.

Andrei Rebrov (57:53.221)
Потому что очень много всяких разных стала технологий. И уже нельзя бездумно применять кэши. Где -то они в плюс, где -то они в минус. Где -то нам нужна база, где -то она совсем не нужна. Где -то у нас будет коммуникация через ивенты, где -то нас будет коммуникация... Где -то у синхрончено, где -то у нас асинхрончено. И так далее.

Это был момент и качественного роста бизнеса, и это был момент качественного роста разработки, когда мы начали действительно сначала думать над архитектурой, смотреть какие есть варианты, пробовать смотреть, что если вот этот вот трафик внезапно вырастет, а как быть с данными, как нам не допустить потерю целостности данных. вот сколько, наверное, года два с половиной назад мы это начали делать? Два.

два -два с половиной назад. вот сейчас это нам позволяет более аккуратно заниматься развитием всей

Kirill Mac (58:58.83)
Ну а сам принцип определения, то есть как вы для себя это определили, то есть по каким -то микрозадачам, по домену, какой -то

Andrei Rebrov (59:08.197)
Наверное, это все -таки большей степени домен. есть домен очень часто завязан на задачу, которую он решает. Просто мы начали на домен смотреть более атомарно, что ли. То есть условно, например, сейчас какой возник вопрос? То, что мы сейчас растем в Европу. И возник острый вопрос GDPR, возник острый вопрос, как это правильно называется,

Andrei Rebrov (59:41.253)
хранение данных в нужном регионе и в принципе раз уж мы затрагиваем данные клиентов давайте нормально пересмотрим вопрос а как мы секьюрно данные храним так чтобы нам не было безумно больно потому что в свое время был нас дейтабридж к сожалению в 20 году повторений очень бы не хотелось и вот этот момент когда ты смотришь максимально атомарно вот есть пользователей вот есть его адрес

Вот есть его платежные данные. Имеет ли смысл в рамках тех процессов и тех...

Andrei Rebrov (01:00:21.061)
потоков данных, которые у нас есть и которые мы прогнозируем делить это максимально тамарно. Есть ответ, да, мы делим. Если нет, мы смотрим, окей, какая максимально минимальная группа функций должна быть объединена в единый модуль, чтобы он жил вот так. То есть имеет ли смысл в принципе хранение адреса отделять или мы храним одном месте у нас и работа с адресом и интеграция, например, с валидатором или нет. И вот сейчас этот вопрос,

Час...

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

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

Мы можем сейчас этим заниматься, потому что бизнес стал большой и, вероятно, сцена ошибки сильно

Kirill Mac (01:01:56.751)
Скажи пожалуйста, вот если общие какие -то вещи, вас релизный цикл какой примерно? есть как часто вы деплоитесь и как быстро вы вносите изменения? Каждый день. Но при этом это может быть абсолютно все что угодно, любой сервис, любой подсервис. Просто каждый

Andrei Rebrov (01:02:03.012)
Ну каждый день. Задача доплывается каждый день.

Andrei Rebrov (01:02:09.572)
Да, это что угодно. есть если смотреть... Опять же, спуская сверху вниз, вот у нас есть стратегическое планирование. Мы на год планируем 5 -6 больших проектов, действительно больших проектов, которые идут по 6 -9 месяцев, и над ними работает вся организация. Волюченные финансы, и склад, и маркетинг, и бизнес -девелп, все -все -все над ним работают, поэтому это большой проект. Это не только разработка, идет так много времени.

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

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

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

Kirill Mac (01:04:04.078)
Давай от сервисов перейдем к этой истории. То, как у вас девелкнет устроен, про разные процедуры, которые внутри него есть. Например, расскажи про релизы. Это может делать любой человек, что при этом присутствует, если CD, CIF, вот это все. В двух словах расскажи, будет

Andrei Rebrov (01:04:28.316)
Угу. Хорошо. На самом деле, в силу того, что много разных продуктов, много разных приложений, у них у всех свои циклы. То есть, например, классическое, традиционное мобильное приложение. Раз в две недели что -то у выкатывается, чаще делать можем, но не хотим, потому что каждый раз это работа с Apple Store, с Google Store, поэтому...

Два релиза вместе, за это прям вот то, что мы выдаем, то, нормально, то, что мы можем выдавать какие -то действительно действительные куски. Там стандартные... Заделиви... Там. Накодили, протестировали все, отправили на проверку в Apple Store. Там, там своя атмосфера. Самое интересное, наверное, здесь будет сайт. Потому что на сайте происходит больше всякого разного движника. Вот. Здесь как раз таки Continuous Delivery. Как все это строится?

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

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

если что -то хочет поменять команды, связанные с Backoffice, она это меняет, создает PR, команда сайта это проверяет. То есть это опять же то, что называется, пародия, но скопирована идея с RACI Matrix. То есть есть такой подход в менеджменте, как сделать так, чтобы никто не чувствовал себя ущемленным и все были в курсе. То есть ты делаешь всех людей на четыре группы. Есть Responsible, есть Accountable.

Andrei Rebrov (01:06:50.681)
Есть Informed, C не помню за что отвечают. То тебя есть группа людей, которые должны быть оповещены о том, что ты где -то делаешь изменения в микросервисе. Есть люди, которые это делают по факту. Есть люди, которые должны проверить твою работу. Вот. Ну, себя примерно что -то такое, говорилось, в рамках наших микросервисов, потому что их сильно больше, чем людей команд. Вот. Поэтому по -другому было нельзя. Хорошо. Вот мы изменения сделаны.

в рамках как бы изменений делаются через PR, а сделая изменения запускается сборка в GitLab, которая проверяет, что ни сервис, в котором ты делаешь изменения, ни сервиса, которые как -то от него зависят, не упали, что там проходят все юнитесты, там проходят интеграционные тесты, сейчас мы добиваем наконец -то, что там еще запустятся функциональные тесты, которые пишут QA.

в рамках твоей же ветки, мы обратную связь получим гораздо раньше. Вот это то, к чему... Да, да, да. То мы наконец -то к этому... На TypeScript 'е, Вот. И туда как бы пишут эти тесты, умеют писать все EQA и frontend и backend. На самом деле, мы выбрали единый фреймворк на функциональный тест. Хорошо, ветка зеленая.

Kirill Mac (01:07:49.294)
Ну то, что ты говорил про Playwright, да? То есть у вас на Playwright пишут. Но Джесси,

Andrei Rebrov (01:08:10.853)
прошла код review. Это код review это отдельная тема, которая вызывает массовое горение в различных чатиках. Мы у себя делаем код review, потому что во многих местах как бы best practices более -менее все настроили, есть различные сервисы, которые приводят к кодлинтеры и вот эти все штуки, которые приводят к механику. Код review зачастую вопрос, что люди задали... Там поднимается вопрос, а почему -то сделать таким образом.

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

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

Потом рано утром запускаются тесты функциональные EQA и FrontEnders. И в специальный чат TechReleases, в слайке все эти результаты выливаются. Если там все хорошо, здорово, у нас есть pipeline в GitLab, который зеленый, который гарантированно проверенный, из него мы заливаемся. И там просто дежурная на этой неделе команда проходит, нажимает везде Deploy to Production.

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

Andrei Rebrov (01:10:36.261)
Это тоже что мы еще пока не решили, но мы об этом помним. Ряд сервисов, соответственно, большинство микросервисов выливается просто rolling update, потихонечку все плоды в Kubernetes заменились. Ряд критических сервисов, связанных с продуктами, связанных с оплатой, связанных

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

В рамках команды есть два бэкэндера, которые вот и занимаются нажиманием

Kirill Mac (01:11:34.702)
Я не услышал про staging, правильно я понимаю, что вас фактически вся эта сборка приводит сразу к тому, что вы в продакшн катите?

Andrei Rebrov (01:11:41.445)
Да, как только замерзненная ветка, выливается в Вот вылил staging, там запустились функциональные тесты. Еще одна вещь, которой мы сейчас работаем, это разделение, чтобы был def, куда заливается все по мержу, чтобы был stage, куда мы заливаем контролировано под контролем. Это то, что мы считаем стабильным, потому что нужны команды, которым нужен стабильный stage. Это команды мобильной разработки.

Им очень не нравится, когда там что -то на стейже шатается, и не могут заниматься своей заработкой. И на самом деле бизнес -юзерам тоже нужна такая безопасная гава, где они могут проверить, что созданные скидки работают нормально, что созданные продукты работают нормально и так далее. Потому что, опять же, мы пришли к тому, что называется Compostable Commerce. Тоже такой горячий базвор сейчас в индустрии коммерса, что...

Ам

Andrei Rebrov (01:12:43.28)
Зайду издалека. Я давно хожу на индустриальные конференции, связанные именно с ритейлом и электронной коммерцией, чтобы узнать, куда все это движется дальше, чтобы понять, какие технологии будут нужны. И в какой -то момент меня стало забавлять, что вот на эти конференции, куда приходят, не знаю, маркетологи, куда приходят без ДФ, куда приходят, не знаю,

не разработчики в первую очередь. Там стоят стойки, на которых написаны крупными буквами

Я такой думаю, там есть ряд аутсорвисеров, которые приходят и говорят, что вот это правильное направление развития e -commerce, а уход в микросервисы. И соответственно у людей всегда возникал когнитивный дизнанс, вот я сижу на Shopify, какие микросервисы, вы о чем? Индустрия пришла к тому, что для e -commerce давно уже был перестал...

И e -commerce давно перестал быть просто набором статических страниц продуктами, парокаталогов и страниц оплаты. e -commerce стал сервисом, где в рамках сайта ты можешь и развлекаться, посмотреть какие -то лайфстримы, можешь там пройти какие -то квизы, можешь много всего поделать. У тебя есть клиентская поддержка, у тебя есть... И я обязательно сейчас стал модный и так далее. Вот. И...

как раз -таки вот эта сложность, эта необходимость быть гибким, добавлятием вещи привела к тому, что в бизнесовом мире тоже появились свои микросервисы, которые называли Composability. То есть мы вместо того, чтобы использовать одну платформу, не знаю, Salesforce Cloud, Oracle e -commerce Cloud, Shopify, давайте мы возьмем ряд кирпичиков, их между собой соединим. Как

Andrei Rebrov (01:14:40.069)
Все уже придумано до вас. есть микросервисы, это есть макросервисы. Вот,

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

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

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

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

Kirill Mac (01:16:33.87)
Ох, это, конечно, понятный путь, но, конечно, это может очень сильно замедлить, да? Все процессы тут надо быть гибким очень, очень аккуратно.

Andrei Rebrov (01:16:40.133)
Да, Тут поэтому вот вопрос с жесткой дисциплиной, что мы не тормозим и продолжаем ежедневно всю эту деплоедь. И пока мы этого не решили, мы не возвращаемся к пелению задач, это прям супер важный аспект. эта вот жесткая дисциплина, она должна быть.

Kirill Mac (01:17:02.19)
Я бы, знаешь, если бы для себя что -то подобное делал, мне -то повезло, нас… Как повезло? У нас не будет никогда таких объемов просто, да, и поэтому мне всё это не нужно. если бы я шёл в эту сторону, я бы пробовал, конечно, стараться всё -таки избежать стейджинга, вводя там больше фич и флагов, ещё какие -то другие механики использую, потому что я всю свою жизнь работаю вот где -то, я просто видел,

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

Andrei Rebrov (01:17:54.245)
Да, да, да,

Andrei Rebrov (01:17:59.077)
К сожалению, сейчас в той фазе, когда ребята работают на своем, мы рассматриваем различные варианты, как нам выстроить процесс, что мы можем лэптоп людям отгрузить, что мы можем его обратно в себя принять. Тут масса внутренней бюрократии возникает, нас она тоже есть. Есть, опять же, с разным background, то есть есть классические чары, есть различные там...

Есть я, который там топит за одно, есть финансы, которые топят за другое, поэтому это не очень быстро решается, вот, и пока так.

Kirill Mac (01:18:37.998)
Мы много лет назад перешли на удаленную разработку на удаленных тачках. Тогда это еще была проблема, когда докер на маке еле работал, и там постоянные проблемы были. В итоге мы сделали это и получилось довольно прикольно. Особенно учитывая сейчас развитие уровень технологий, там еще умеют, редакторы умеют коннектиться к удаленным вещам. Я вообще на ВИМИТа принципе зашел на сервак и мне хорошо.

Andrei Rebrov (01:19:04.677)
И погнал, да.

Kirill Mac (01:19:04.942)
Но в любом случае, да, мы когда -то перешли и довольно неплохо себя в этом режиме чувствуем. Хорошо, мы поговорили с про процессы, а вот про процессы, скажем уже, менеджмент людей. Типа, как у вас устроены процессы именно с точки зрения производства вообще? То есть вы там Scrum используете, не Scrum, что -то свое, расскажи про

Andrei Rebrov (01:19:25.797)
Угу.

Andrei Rebrov (01:19:31.973)
Тут нас наверное такое...

Ну, не древнегреческая драма,

Andrei Rebrov (01:19:46.201)
многосерийное кино, когда мы прошли несколько фаз. Соответственно, опять же, важно понимать, что я пришел в Сенбёрд из agile -коучинговой компании, на под названием Scrum Track. Я был тем человеком, которым приходил в большие в том числе организации, не даряло им Scrum, если они хотели, Kanban, если они его хотели. И как -то это помогало им завести, чтобы оно не падало без меня. Соответственно, придя в нашу компанию, такой, ребят, у нас Kanban.

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

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

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

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

Andrei Rebrov (01:22:01.349)
там тоже подготовить свою рекламу, кем -то, какими -то партнерами пообщаться, выделить бюджеты, то, чтобы эту рекламу запускать. Это завязано на склад. На склад должны приехать все товары, этот склад должен, возможно, свои процессы перестроить. Это завязано финансов, потому что в конце года финансовый аудит, должны все это правильно пройти, никто не должен там поволочь налоговую за то, что мы что -то неправильно читали и так далее. И список -то продолжается. Вот.

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

того или иначе, ну там, фреймворка или метода. нас и не CommandMethod, у нас и не ScrumFramework. У нас процесс, который позволяет регулярно выдавать работающий продукт. Он вовлекает в этот процесс разные команды. И это на самом деле тот случай, когда я увидел, насколько важны не только ProductManager, но и ProjectManager. То есть весь мой предыдущий опыт

показывала, что Project Manager это такие жуткие бюрократы. Я видел восстановление в свое время проектного офиса в Сбертехе. Это для меня было, наверное, самым таким, наверное, ужасным примером, что такое Project Management, когда там за людьми бегают с ганчартами, и просят их заполнить секс -селес, и там, насколько процентов готова ваша джирозадача и так далее. То есть, я видел в разных компаниях разной степени глупости.

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

Andrei Rebrov (01:24:21.317)
Проджект менеджмент завелся. И сейчас вот наш процесс развивается для того, чтобы развивается и пересматривается с учетом негласного держания в голове в таких моментов, что продукт должен делаться регулярно, люди должны быть в курсе, над чем мы работаем, они должны понимать, зачем мы это делаем, должны людей стать известны, если что -то

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

Kirill Mac (01:25:15.662)
Про продуктов хотел тебе сказать одну такую вещь. Знаешь, же для себя относительно недавно это наконец -то осознал, что тебя люди, которые имеют в названии слово «продукт», вообще не должны никем управлять, и у них совершенно другие задачи. Это исследование, вообще, то есть параллельно. Любая операционка, любой менеджмент, любое подчинение это не про них. Это должны быть просто… Все остальные в компании являются сервисами для них, которыми они

Вот это такой тоже вывод, который я для себя когда -то сделал. Знаешь что -нибудь?

Andrei Rebrov (01:25:48.485)
Ну тут на самом деле я прерву как бы, все время забываю название этого закона, что структура компании отражает ее архитектуру и сервисов. Вот так и есть, что если у тебя выстроены микросервисы, то тебя и компания тоже снится микросервисной, если у тебя там оно должно иметь скеллитсы, оно должно выделяться функцией и так далее.

Kirill Mac (01:26:10.03)
Знаешь, что хотел спросить? У вас же компания такого размера и такой сложности, которую вполне возможно вписываются аналитики? А ты вот ничего не сказал про это. Они у вас есть в процессе или нет?

Andrei Rebrov (01:26:17.957)
Аналитики супер важные люди, то есть они работают... Это такой же сервис, как бы, продаже предыдущей аналогии, которым ходят все в компании, вот вообще все. А аналитики уже ходят в Data Warehousing, то есть мы у себя наконец -то там сейчас опять же начинаем обучаться правильной терминологии, после долгого времени, что команда аналитики на самом деле... Это две команды. Есть команда,

обеспечивать, чтобы данные были, а вторая команда этим данным продает смысл.

Kirill Mac (01:26:52.078)
Ой, прости, я понял, что я тебя немножко запутал. Я не имел в виду команду аналитики, это очевидно, что у вас там есть инженеры, дата аналитики. Нет, я имел в виду другое. Мы просто говорили с тобой про менеджмент, и я имел в виду именно системных и бизнес аналитиков, потому что это часто сопровождается сложными продуктами либо корпоративными историями, когда у тебя большие корпорации. И поэтому я хотел узнать, у вас это есть или вот таких аналитиков все -таки нет? Вы как разработчики сами разбираетесь.

Andrei Rebrov (01:27:14.181)
У нас...

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

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

отдать подрядчику, который это имплементирует, и проверить, что все это будет сделано. При этом, опять же, так как компания «Живой организм» и даже наш склад – это «Живой организм», который регулярно строит гипотезы о том, как им перекроить свой собственный процесс, чтобы начать работать лучше, быстрее и дешевле с новым видом заказов, это все тоже точно так же сидят люди на складе, отвечающие за склад, за людей в конвертной линии.

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

Kirill Mac (01:28:58.734)
Ну, смысл в том, что они есть и на тех местах, вот надо корпотливо, сложно с внешними системами, потому что иначе куча времени на это уходит.

Andrei Rebrov (01:29:03.141)
Да.

Andrei Rebrov (01:29:07.429)
Хуча времени. И на самом деле еще один момент внешних систем, это то, что, как правило, они настолько специфичны, что тебе нужны специфичные люди, которые тебе сделают с ними интеграцию. То есть тут, наверное, любимый -нелюбимый пример — это Oracle NetSuite ERP -система, супер известная в Штатах, супер свой мир в плане того, как она развивается, и чтобы с ней сантегрироваться...

И чтобы ее админить, нужно быть туда погруженным на полный размен. есть аналог, 1S. Вот такое 1S предприятие даже больше. вот там, так как это внешний подрядчик, вот как хорошо ты опишешь требования, вот так так хорошо твоя система будет работать. Что -то ты где -то не сказал, извините, новое требование. Что -то ты где -то не описал в рамках use -case и test -case, извините, новые требования.

Извините, система не может это сделать, извините, а вы нам не сказали, что у вас такие перформансы, вы сказали количество заказов, а как быстрее загружать вы не сказали. Поэтому тут как раз -таки дотошность, наше все.

Kirill Mac (01:30:18.67)
У меня для тебя есть следующий вопрос. Мы с тобой, знаешь, так блоками проходим по всем аспектам, которые у вас есть, не сильно погружаясь, но вот так получилось. И мы, знаешь, переходим, наверное, постепенно уже к людям, то есть через процессы уже конкретно к программистам. И вот это тоже интересная история, потому что вы 100 % при росте, да, у вас там более сложная структура, скорее всего какие -то ошибки найма, у тебя есть какое -то понимание того, кого как вас обидите, какие -то грейды, все что угодно, да. Давай про это поговорим, потому что со мной

Andrei Rebrov (01:30:21.893)
Угу.

Andrei Rebrov (01:30:46.757)
Угу.

Kirill Mac (01:30:48.142)
напрямую связано, да, я учу программистов и вообще занимаюсь помощью в найме, трудоустройстве и так далее. Давай вот об этом поговорим. Расскажи вообще, кто у вас, то есть вот есть программисты, да, у тебя хоть есть свое представление, то есть кто, кого ты набираешь себе в команду, что это за люди?

Andrei Rebrov (01:31:05.957)
В двух словах не получится, но основной момент заключается в следующем, что когда ты работаешь на удалёнке, супер важным навыком является умение грамотно формулировать свои мысли.

так чтобы тебя поняли однозначно и понимание, которое есть у людей, совпало с твоим собственным пониманием. И это касается, наверное, большинства людей, которые тебе нужно нанять. Иногда ты нанимаешь ради специфичного навыка инженерного, например, machine learning или data science или AI, как сейчас все нанимают, когда тебе нужно нанять человека, который умеет, не знаю, построить

языковой модели ты готов с какими -то вещами мириться, потому что у неё есть крутой hard skill. Для нас основное и это умение общаться, умение себя изъяснять, умение задавать вопросы, потому что опять же ожидание, которое есть, что команда

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

Мы проверяем, и что проверяют HR -агентства, с которыми мы работаем, это вот адекватность относительно soft skills. И часто люди срезаются именно на этом этапе. Потому что опять же нужно понимать, что далёная разработка не для всех. То есть есть те люди, которым умеют это делать, есть те люди, которые не умеют. Есть ещё один такой важный момент, котором часто не говорят, что начинать свою карьеру

Andrei Rebrov (01:33:18.821)
в любой индустрии, чисто на доленке, безумно сложно и, скорее всего, не получится, потому что в рамках начала своей карьеры важно с кем -то быть бок о бок, чтобы ты впитал, не знаю, как это еще описать, правильную культуру, правильные ментальные установки, правильный подход к общению. И только когда ты уже поработал в коллективе с хорошей культурой, с хорошими процессами...

с хорошими людьми, посмотрел по бы в разных ситуациях, вот тогда ты уже можешь в себе это поддерживать независимо. есть ты зажег свой факел от других и дальше уже можешь его стабильно нести. Вот это, что касается soft skills и уровня людей, то есть как мы по этому нанимаем middle и как правило senior людей, который умеет хорошо... И опять же, я расскажу, что такое для меня senior.

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

разобранных багов, потому что очень часто дело сводится именно на умение понимать, где подстели соломки, это влияет на то, архитектург ты сделаешь. Поэтому мы нанимаем таких тренированных людей, которые хорошо умеют общаться, которые хорошо умеют изъясняться, задавать вопросы, и которые хорошо умеют разрабатывать. Что значит хорошо разрабатывать? Они исследуют определенные логики,

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

Andrei Rebrov (01:35:45.637)
То есть и опять же, человек не должен иметь подготовленный ответ сразу. Мы хотим понять, а как он будет подходить к решению этой задачи. Потому что в этом и заключается работа программистов на доленке. Вот ты с кем -то пообщался, а потом ты предоставлен сам себе, и ты сидишь и сам собой обсуждаешь, окей, вот, а что если так? А если вот сюда? А какие бывают ситуации? И вот мы хотим понять, как ты в этой ситуации, когда ты остался сам собой и...

Вот как примерно выстроен наш процесс с подбору людей с точки зрения их общих каких -то софт и частичных арт

Kirill Mac (01:36:26.542)
не могу не спросить вот тот момент про софт -скелы, когда ты говоришь о том, что мы проверяем, ну, понятные вещи, да, это все хотят, да, что человек умеет задавать вопросы, правильно анализировать и много -много чего еще. У меня вопрос такой. Это какой -то обычно, часто, особенно в русскоязычном мире, да, у нас принято, что это как -то фоном немножко идет, да, то есть мы как бы на протяжении всего собеседования фоном отмечаем, как человек что -то делает.

Andrei Rebrov (01:36:54.245)
Угу.

Kirill Mac (01:36:54.542)
В американских собеседованиях это тебя вообще прям секция отдельно, под которую надо готовиться и так далее. У вас какая модель? Я просто почему еще спрашиваю, потому что мы все прекрасно знаем, что вот эта американская модель, которая и в Европе тоже распространена, она на самом деле очень легко хакается. есть фактически тебя просто ждут правильных ответов. Я сомневаюсь, что ты так проводишь собеседование. Да?

Andrei Rebrov (01:37:17.351)
Собеседование проводят разные люди. Первый этап это проводят рекрутёры. Внешне даже это не собственные. С которыми мы работаем много лет, в виде кого мы нанимаем, кто в остановке остается долго, кого мы увольняем, кто уходит сам, они примерно понимают, кто представляет пласт людей, который нам нужны.

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

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

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

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

Andrei Rebrov (01:39:31.653)
что ему важно в компании, в которую он приходит. есть каких -то прям таких, как это тоже. Этот вопрос задавали на собеседование в КГБ в 80 -м году. Какая девочка является хозяйкой данного котика? Нет, вот никакой такой дичи или там про шарики в школьный автобус я не спрашиваю. Вот. Мне важно то, как человек... Во -первых, я всегда начинаю интервью с того, что я даю человеку возможность задать вопрос про компанию.

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

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

Kirill Mac (01:40:49.358)
Я правильно понимаю, что всего 4 собеседования

Ну, довольно это растянуто по времени. А у тебя статистика есть по неуспешным наймам? То есть, человек, которые к вам прошли, в конечном итоге не прошли испытательный срок в процентном

Andrei Rebrov (01:41:06.149)
Испытательный срок проходили все. Вопрос дальше, то, называется, retention. То есть, насколько долго люди оставались. Тут есть два

Andrei Rebrov (01:41:20.997)
Два примера. Есть люди, который... Человек, который у нас сейчас, чиф -архитект, он к нам пришел в 15 -м году. И он и сфор с нами. У нас есть прям ряд старичков, которые с нами очень давно. И они классно крутые. А был кейс, когда в 21 -м году, когда зарплату доленчиков резко пошли вверх, у нас ушло две третьи команды. Одной. Они все вместе за ручку встали и ушли в криптобежу. Вот, это другой пример.

соответственно и то и то для меня является уроком вот какого -то знаешь прям такой вот вот этот вот теперь я должен спросу спрашивать вот этот вопрос на собеседование нет мне такого не появилось то есть это знаешь на уровне

Andrei Rebrov (01:42:10.117)
химических процессов, как я ощущаю этого процесса. есть мне, этого человека, мне сложно это сформулировать, вот, но как правило, когда собеседование закончено, у меня есть, как бы, после десяти лет найма, у меня есть понимание, как бы, хочется нам этого человека иметь или не хочется, или есть кто -то лучше, с которым стоит дальше продолжать работать.

Kirill Mac (01:42:31.95)
Знаешь, это для меня такая больная тема, потому что я же тоже наймом очень давно занимаюсь и очень разнообразным. То есть там от преподавателей к нам в колледж заканчивая, маркетологами, дизайнерами, кем угодно. И знаешь, чем дальше проходит, тем больше я понимаю, что нифига не работает моя насмотренность. Я очень часто лажаю, когда ты ждешь, что люди будут перформить. И у меня знаешь, в какой -то момент сложится это ощущение, что типа есть

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

Andrei Rebrov (01:43:03.045)
Ну да.

Andrei Rebrov (01:43:23.749)
А вот топовые люди, это дайм топовых людей, это отдельная прям тема. Вот, потому что, как бы, сейчас для меня это актуально, потому что я нанимаю директора офф инжиниринг. Мы себе директоров product, которые нам понравился, наверное, нанимали кода 4, CMO, который нам понравился, мы нанимали лет 5. То есть там были кандидаты, которые уходили, которые нам не нравились. Вот.

С -левел всегда умеет хорошо говорить. Вот.

Kirill Mac (01:43:55.15)
Вот ровно то же самое. Ты берешь человека вообще никак. Берешь человека вообще никак. И ты думаешь, черт побери, я два года потратил на наим какого -то человека, тут я потратил полжизни. И такой думаешь, ну как же так? Как же так? То есть там нужно, конечно, очень серьезно подходить к отбору. Очень серьезно.

Andrei Rebrov (01:44:09.285)
Стоимость ведения бизнеса. Стоимость ведения бизнеса. Потому что, опять же, на уровне программиста ты очень быстро получаешь обратную связь о его результатах. А на уровне, не знаю, директора по маркетингу, ну слушай, тебе тут зачастую нужно год подождать, прямо, чтобы увидеть, может ли человек перевернуть какие -то вещи, может ли он что -то улучшить. А если при этом на рынке были еще какие -то потрясения, условно...

Вот нанимаешь ты себе директор по маркетингу в феврале 21 года. И вроде все нормально. А потом раз и у тебя Facebook с iOS входит в конфликт, и у тебя маркетинг весь вообще летит. И вот ты не знаешь, этот человек плохой или у всех все плохо, и меня в том числе человек делает максимально полезный результат. И ты ждешь. И время идет.

Kirill Mac (01:45:06.542)
Да, но это мы уже зашли в другую область, за пределами разработки. Скажи, какую вещь? Примерно понятно по поводу роста внутри. Когда у тебя уже ребята есть, и скажем, же есть следы, может быть не всегда позиции открытые есть, у вас не 200 человек, 300 работают, где всегда есть позиции, но все же чего -то ждешь от ребят. Во -первых, берете ли вы ледов снаружи или это вы внутри выращиваете, в основном стараетесь, и плюс

Andrei Rebrov (01:45:09.317)
Да -да -да.

Andrei Rebrov (01:45:35.461)
Угу.

Kirill Mac (01:45:36.814)
Что ты ждешь от них, как они растут? Есть ли грейды или это чуйка? Расскажи про

Andrei Rebrov (01:45:40.037)
Угу.

Andrei Rebrov (01:45:44.14)
Смотри, у нас есть две разных ветки. Есть то, что называется IC, individual contributor. Это разработчики junior, middle, senior, staff, principal. Есть manager ветка. Это... ...тим лиды. И я. Раньше было, сейчас, блин, еще директор of product. Плюс у нас есть тех лиды. Люди, отвечающие... Они сидят между... Они больше в individual contributors. Это principal инженеры. Они отвечают за то, как развивается наш front -end.

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

Andrei Rebrov (01:46:28.613)
С исключением ряда людей я знаю, что люди через 3 -4 года уйдут, потому что нас закончится интересная задача для них. Потому что вариативность задач конечна. Вариативность команд конечна.

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

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

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

либо самостоятельно, либо при помощи меня, как их непосредственным руководителям. С точки зрения, опять же, льда, роста не супер много. То есть, опять же, команда, ограниченная размером. Команда, ограниченная, не знаю, специфика того, что не решает. И, наверное, с точки зрения роста, что для I .C., что для менеджера, основной рост заключается в том, как...

Andrei Rebrov (01:48:42.981)
меняется бизнес и как в этом изменяющемся бизнесе меняется процесс их команды разработки и во всем бизнесе в целом. Поэтому опять же, то что происходит у нас, оно не для всех. Кому -то интересно оставаться исключительно в технологической среде. У нас одно из требований это понимать, что происходит с бизнесом, почему так, и что дальше, и как ко всему этому построиться, перестроиться.

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

Kirill Mac (01:49:31.502)
А в этом присутствуют какие -то формальные что ли процедуры? То есть, например, там, перформанс -ревью или еще что -то. Или им говорят о том, что вам надо знать, если вы в принципе целитесь в какую -то такую

Andrei Rebrov (01:49:43.845)
У нас есть формальный performance review, то есть у нас есть система KPI и Goals для разработки, это все -таки больше цели. То есть с точки зрения KPI, за которую мы смотрим, это с SLA, SLO, performance site, время недоступности и...

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

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

И у команды сайта появляется задача, ребята, должны перейти у себя на интернационализацию. Не за хардкожные лейблы и тексты, а какое -нибудь I18N framework, желательное асаасное решение, чтобы маркетологи тыц -тыц зашли и поменяли тексты. И это появляется цель на команду. Дальше темлит этой команды, как -то внутри себя это делит. Кто -то обязан, не знаю, потом в Q1 в первом квартале

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

Andrei Rebrov (01:52:06.213)
где -то продумывать это больше, чем было продумано твоим тем ледом, тогда... и делаешь это на регулярной основе, тогда это фактор перевести тебя на следующий уровень, если есть куда переходить.

Andrei Rebrov (01:52:20.709)
соответственно переход на следующий уровень увеличивается твоя зарплата если ты в принципе хорошо работаешь цели своих достигаешь где -то что -то делаешь лучше увеличивается размер твоего бонуса а так да ожидания для всех формулированы то есть если ты для существующих сотрудников это цели которые формулируются которые добавляются которые могут меня в течение года для новых сотрудников это документ 30 60 90 который

описывает ожидания от нового человека на продвижении трех месяцев. Прошел, это испытательный срок по большому счету. Дальше прошел, дальше тебе появляются твои индивидуальные цели от твоего непосредственного менеджера.

Kirill Mac (01:53:03.182)
А перформанс -то при этом у вас формальный? То есть есть какие -то критерии, люди это знают или это скорее просто так, как бы на основе коммуникации там с его этим ледом

Andrei Rebrov (01:53:11.909)
Это на основе коммуникации. То есть... Есть

Andrei Rebrov (01:53:22.725)
это

Есть аж... У нас есть система upgrade 'ов, и к ним привязано ожидание того или иного уровня. То есть, условно говоря, вот есть синий разработчик, что ты как синий разработчик должен делать по там, рядам направлений, случае, сожалению, кода, работы с другими, там, mentorship и так далее, тому подобное. Вот. Если кто -то начинает косячить, это, как правило, видно. Это видно либо Team Redo, то есть, например, человек, там, стоит появляться вовремя, у него все время какие -то отмазки, что он где -то что -то не делал.

он там, не знаю, неправильно делает обновления в базе данных, неправильно их накатывает, неправильно пишет скрипты, не думает про перформансы и так далее и так далее, это все всплывает. И дальше задача Team Lead 'а, все эти вещи замечать и человеку коммуницировать. И дальше начинается как раз таки работа Team Lead 'а. Если Team Lead тебе делает замечание, и ты над ним исправляешь, и у тебя это не появляется, все здорово. Если ты постоянно

то тогда уже мы начинаем разговор о том, чтобы тебя заменить. Тут тоже такой... Тут все честно. То есть когда люди... Как правило, если людей увольняют, люди вокруг понимают, почему это

Kirill Mac (01:54:42.637)
У вас довольно интересный микс между... То есть вы еще не совсем Big Tech, но вы уже не совсем маленькая компания, и получается, что на 40 человек вы уже постепенно начинаете применять эти правила. У вас там грейды, какие -то механики, но вы, опять же, не то что вы пытаетесь все формализовать на 100%, вы пытаетесь применять только то, что нужно применять в вашем случае.

Andrei Rebrov (01:55:06.245)
Да, потому что большинство этих механик, там те же самые гриды, они нужны зачастую самим людям, понимать, ага, что я должен делать, чтобы получить определенное вознаграждение. И ты вводишь такую механику, и все по ней живут, и всем понятно, как достичь дальше. Те же самые Performance Review у нас

Лет 6 -7 лет 6 назад с того момента она раз 5 уже переделывалась вот вот вот сейчас мы переделали это еще еще раз там поменяли что как происходит когда какие мы делаем его движение что отвязывается что привязывается к премии вот поэтому это тоже процесс который живет вместе с

Kirill Mac (01:55:47.502)
Я знаю, что понял. Мы как раз занимаемся подобными вопросами, ну, по крайней мере, думаем в эту сторону. У нас, конечно, команда небольшая, там разработки шесть человек, но мы постепенно, знаешь, какие -то полезные практики все равно -то, как иначе, пытаемся применить, так что я к тебе точно придумаю, с тобой об этом поболтаем. И, в общем -то, я уже услышал несколько интересных идей, думаю, что -то мы сможем взять от вас. Вопрос такой, блиц, вы нанимаете прямо сейчас

Andrei Rebrov (01:56:13.613)
Да, мы нанимаем прямо сейчас

Kirill Mac (01:56:15.79)
Супер. Ты мне тогда дашь ссылочки, а я все это приложу, и мы ребят позовем. Смотри, такой важный момент. Они как бы принципиально, что они внутри России не должны находиться или нет? Принципиально.

Andrei Rebrov (01:56:27.333)
Принципиально. К сожалению, принципиально, что ребята не должны находиться внутри России и внутри Украины. Ну и опять же внутри тех стран, против которых существует американский сенс. Потому что мы, как американское юрлицо, мы законопослушны.

Kirill Mac (01:56:38.926)
Ну понятно,

Kirill Mac (01:56:43.726)
Да, все понятно. Андрей, тебе большое спасибо, что ты пришел, рассказал, поделился. Да, будем распространять, так сказать, культуру. Потому что… И прикольный, да, переход, то, что у вас были такой, знаешь, ты там в Agile занимался, потом в своей собственной компании, ты такой понимаешь, черт побери, это немножко по -другому, это очень классно все.

Andrei Rebrov (01:56:48.645)
Тебе спасибо, что позвал.

Andrei Rebrov (01:57:04.773)
Всё так.

Kirill Mac (01:57:05.71)
Да, все, спасибо, всем пока. Подписывайтесь на канал, ставьте лайки, дизлайки, всего от вас ждем, мы и ваших комментариев тоже. Пока.

Прости, что немножко резко, потому что меня уже семья ломится, я понимаю, я не могу, да, я не могу дольше продолжать, потому что меня скоро убьют. Слушай, большое спасибо, жду, когда ты приедешь, мы с тобой обязательно встретимся и поболтаем. Вот, все, давай хорошего дня, пока.

Andrei Rebrov (01:57:19.621)
Да, я так и понял.

Andrei Rebrov (01:57:30.725)
Обязательно встретимся, да. Все, на связи. Пока -пока.

Kirill Mac (01:57:36.91)
Ты показать не включай, но там закачается. Единственное, можно. Да, вроде так можно, да.

Andrei Rebrov (01:57:38.917)
Ага, ну я просто лифт нажимаю, да, наверное?