Ненастоящий архитектор | Кирилл Егоркин

Антидрайверы В контексте мотивации сотрудников чаще речь идет о позитивной её стороне: драйверы роста и развития, результаты работы и удовлетворение от неё. Реже люди обсуждают антидрайверы — то, что нас демотивирует. Хотя, по моему мнению, это не менее важная часть работы. Добавьте побольше драйверов, и все у вас будет хорошо. На самом деле нет, антидрайверы могут полностью убивать мотивацию. Одно не перекрывает другое, это не шкала универсального измерения. Недавно я задумался, а что меня тормозит в работе? Что бесит? Что не нравится? Думаю, у всех есть задачи, за которые легко сесть, они делаются в потоке и с кайфом. А есть другие, которые прокрастинируются, откладываются до дедлайна, делаются долго и нудно, на них нужно настроиться. У меня тоже есть набор рутинных задач, которые мне не очень нравятся. И, в противовес к ним, творческие задачи со свободой и полетом мысли. Одно из ключевых отличий между ними — ограничения. Если честно, я их ненавижу😠 . Ограничений много и мы воспринимаем их как норму: сроки, деньги, технологии и т.д. – Надо было сделать вчера? Давайте постараемся - Нет денег, чтобы сделать нормально? Давайте сделаем, как получится - Не можем купить лицензию на что-то подходящее? Давайте делать на том, что есть Меня дико тормозит, злит и бесит такой подход. Он не позволяет сделать нормально, качественно. Хочется возразить: Ну и зачем тогда делать вообще? Да, это мой личный взгляд, личная позиция. Но для того, чтобы организовать свою работу комфортно, нужно очень хорошо понимать свои драйверы и антидрайверы. Расскажите, что тормозит, ограничивает и бесит в работе вас

Краткая заметка про ИИ Тема, если честно, скользкая. Часто встречаю как восторженные отзывы, так и осуждение ИИ в жизни и в интернетах. Себя к фанатам не отношу, но стараюсь погружаться в тему хотя бы на базовом уровне. Слишком уж сильно она форсируется. Поэтому поделюсь парочкой мыслей. Внедрение ИИ в личную работу — одно дело. В нем есть хороший потенциал для развития. Главное, не говорите своим безопасникам, какому ИИ вы сливаете корпоративные данные. А вот корпоративное использование ИИ — история совсем другая. После его обсуждения на втором SystemConf у меня возникла интересная мысль. Сразу скажу, я одобряю только полноценное качественное внедрение с отдельным планом, бюджетом и в долгосрок. Так оно действительно улучшит работу, а не доставит всем лишней головной боли только ради строчки в отчете “Мы используем ИИ” 🐱. К сожалению, чаще я вижу обратную ситуацию, когда нужно вчера, бесплатно и чтобы сократить штат в 2 раза за счет ИИ. Напоминает “А давайте автоматизируем, так и процессы нормальными станут”. А как я уже писал в посте про автоматизацию, она требует хорошего исходного процесса. Если у вас хреново сделан исходный процесс, таким же будет и автоматизированный. На размышления меня натолкнуло предложение прикрутить ИИ к Docs as Code. Его абсолютно точно нельзя использовать на плохо выстроенной документации, потому что этот подход — не волшебная таблетка. Как и искусственный интеллект. Как и любой другой инструмент, он является продолжением ваших текущих процессов. Поэтому поверхностное некачественное скрещивание этих инструментов скорее даст плачевный результат и кучу времени на разгребание последствий, чем нормальный выхлоп. Может быть, у кого-то из вас есть действительно успешные кейсы внедрения корпоративного ИИ на уровне команд, которое улучшило процессы? Или успешные внедрения в бизнес решения? С удовольствием послушаю вас в комментариях 🙂

Давайте делать плохо! Такой фразы я ни разу не слышал от менеджеров. Зато слышал другие: А можно упростить? А давайте побыстрее? Нужно все тоже самое, но бюджет в два раза меньше. Но никто не задумывается, что в итоге это все равно будет означать «Давайте сделаем плохо». Все упрощения, вся экономия, вся спешка, все «надо вчера и бесплатно» явно или негласно означают, что мы чем-то пожертвуем. Обычно это качество готовой системы. По-честному качеством жертвовать никто не хочет, вот и получается эта игра: давайте что-то придумаем, найдем волшебную таблетку. Разработчики, архитекторы, аналитики и другие тех. специалисты чаще видят потенциальные проблемы и негативные последствия, но не могут доказать это бизнесу на понятном ему языке — языке денег. Я уже сталкивался с ситуациями, к счастью, чужими, когда ко мне в руки попадала либо нежизнеспособная система, либо уже практически умершая. Ровно по этой причине: когда-то пожалели денег, сил и средств, чтобы сделать нормально. Обычно переписывание таких систем преподносится под эгидой обновления и развития. Но, глобально, это исправление ошибок прошлого втридорога. А зачем было экономить вначале? Если мы понимали, что рано или поздно оно выстрелит, а суммы на исправление будут многократно выше. Понимаю, вопрос риторический. Так устроена наша сфера: с экономией, эффективностью и вынужденными мерами. Возможно, так не везде, и кто-то относится внимательно и предупреждает проблемы заранее. Для себя я понял одно: надо говорить честно, когда от вас ждут удобной лжи. Быстрее? Значит хуже. Дешевле? Окей, потом потратим в два раза больше сэкономленного на исправление. Что думаете? Буду ждать ваши истории 😇

Могучая кучка, 2026 г 😁 Именно так мы себя называем, потому что впятером организовали аналитический клуб для системных аналитиков Очень горжусь, что являюсь организатором этого клуба 🤩 Каждый из нас - активен в медийке системного анализа, с большим багажем знаний, опыта и достижений. Кто-то силен в сложных интеграциях, архитектуре высоконагруженных систем, миграции данных или даже банально легко умеет докапаться до сути. Мы как пазлы смогли усилить друг друга - кто-то проводит воркшоп, а кто-то пишет анонс или предлагает новые идеи Проводим офлайн митапы в Москве. Если вы еще не видели, то ссылка клуба тут: @analystclubru Так что, кто в Москве - будем рады:)

Согласен с каждым словом! Очень ждём всех на наших мероприятиях)

🎙 Вышел новый выпуск подкаста «Аналитик за кулисами» Тема выпуска — архитектура систем Про то, как на самом деле рождаются IT-системы: от бизнес-идеи и Vision до требований, архитектурных решений, MVP и пилота В гостях — Кирилл Егоркин, архитектор решений В выпуске обсудили: — зачем проекту Vision и кто его формирует; — где заканчивается зона ответственности аналитика и начинается зона архитектора; — какие артефакты нужны до разработки; — почему бизнес часто приходит не с проблемой, а с уже готовым решением; — когда выбирать монолит, а когда микросервисы; — как системному аналитику начать мыслить архитектурно Этот выпуск особенно хорошо зайдёт тем, кто хочет лучше понимать, почему системы проектируются именно так, а не просто запоминать термины вроде DDD, микросервисов, брокеров и C4 🆘А для тех, кто хочет системно разобраться в архитектуре, — в ближайшие дни расскажем про обновлённые программы наших курсов Будет два уровня обучения, чтобы каждый мог выбрать подходящий формат под свой опыт и задачи А пока выпуск можно посмотреть и послушать здесь: 📱 VK Видео 📱 YouTube 📱 Apple Podcasts 📱 Яндекс Музыка

Друзья, у Оли вышел подкаст со мной! Все бегом смотреть, очень много интересного обсуждали!

Рабство цифровых процессов 🐱 Недавно наткнулся на (страшно сказать) шортс с сюжетом, как у парня не принимали паспорт, а требовали показать госуслуги. Не уверен в его правдивости, но эта ситуация напомнила мне об одном интересном феномене, который долго формировался в моей голове. Мы цифровизуем процессы бизнеса. Коллеги из консалтинга поймут, о чем речь. Всегда есть реальный физический процесс, прообраз. В чистом виде их уже почти не осталось, только на уровне мифов и легенд. Чем меньше цифры, тем больше гибкости. Ручная обработка, принятие решений, отхождение от правил и регламентов, адаптация под разные ситуации — все это атрибутика таких старых процессов. В цифровых процессах эта гибкость улетучивается: процесс регламентирован и машина полностью определяет, что можно, а что нельзя. У меня недавно случилась забавная ситуация. Я хотел переприкрепиться к поликлинике. В Москве такие вещи обычно делаются просто: онлайн через мос.ру. Но тут алгоритм просто выбивал меня и не давал сделать заявку. Оказалось, нужно идти и ручками писать заявление в поликлинику, чтобы тебя прикрепили. Для меня это было шоком. Бумажное заявление (его не будет на мос.ру!), которое где-то рассмотрят, примут решение, а потом даже не известят о результате. Мне сказали «Ну, в приложении посмотрите, если будет другой список врачей к выбору, значит, вы переприкрепились» 🤔 Это сильно ломает привычный ритм: мы привыкли к жесткости и четкости цифровых процессов, но при этом явно теряем в гибкости. Возвращаясь к исходному шортсу, если честно, я верю, что такая ситуация вполне возможна в ближайшем цифровизированном будущем. Нас ждет реальность строжайше регламентированных, негибких процессов без специфической обработки нестандартных ситуаций. Для нас, как аналитиков и архитекторов, это значит одно: мы должны как можно глубже и подробнее прорабатывать с бизнесом процессы, кейсы, входные данные и возможные исходы. 📢 Что думаете? Сталкивались с подобными проблемами цифры в жизни?

Хочется верить, что вы заметили мое долгое отсутствие. Причина этому — не аврал или перегрузка, а выгорание, отсутствие моральных сил 😬 Выгорание оказалось очень скрытной и коварной вещью. Оно началось не месяц и не год назад. Подкрадывается оно незаметно: сначала чуть больше устаешь от стандартных задач, чаще что-то откладываешь, меньше удовлетворения. А потом обнаруживаешь себя в точке, где уже невозможно закрывать глаза на свое состояние. Пытаешься судорожно найти какую-то информацию, помочь себе, но волшебная таблетка не находится. Я сейчас в отпуске. И только на десятый день из 16-ти у меня только-только появились моральные силы и желание что-то сделать. Оказывается, когда ты много-много лет выгораешь, две недели — просто пшик. Но как говорится, кто сдох, тот лох, поэтому продолжаем. Будьте внимательны к себе😽

Кстати, ещё немного про ЛАФ! Если вы все ещё раздумываете, ехать или нет, то этот знак для вас! Все желающие запрыгнуть в последний вагон могут получить промокод на скидку в 15% 🔥 Оставляйте комментарий "хочу промокод" под постом или пишите в личку @akmanovaliza. Не упустите свой шанс!

Ну что, друзья, увидимся на ЛАФ ?☺️

Какими бывают наставники? Что обычно имеют ввиду под словом наставник? От места к месту в это слово закладывают совершенно разные смыслы и часто недооценивают. Иногда это человек, который помогает адаптироваться. Или коллега, который изредка подсказывает, куда бежать и что делать. Бывает, что наставник полностью ведет обучение. А где-то это надзиратель, который только контролирует. Давайте углубимся и порассуждаем, кто такой наставник. Если бы его задачи сводились к передаче знаний, то, наверное, наставников бы называли учителями. Для меня наставник — это тот, кто отвечает за рабочий и даже отчасти личностный рост своего падавана. Он должен передать знания и опыт, показать свои личные качества, мышление и подход к работе, помочь человеку вырасти. Мой путь наставника начался с переходом в архитекторы. Формально и неформально я всегда помогал развиваться молодым аналитикам. Люди приходили за советами и помощью - я с радостью откликался. Наставничество уникально в каждой рабочей паре: с кем-то приходилось быть жестче, с кем-то мягче, иногда больше формальностей и планов, а порой это больше похоже на дружеские посиделки с обсуждениями. Работа двух людей в тандеме всегда обтесывается под индивидуальные особенности. Здорово, если наставничество — это часть работы и закреплено официально. Тогда у вас есть выделенное время, единый контекст, общая предметная область и пересекающиеся задачи. Это сильно помогает именно в профессиональном развитии. Но есть ещё более интересный и сложный кейс: наставничество без прямой связи по рабочим задачам. Работать в более теоретической плоскости, подбирать универсальные примеры, погружаться в контекст падавана — это вызов. Но и я тоже не ссыкло 😄. Эмоциональной отдачи от такого взаимодействия не меньше. Это невероятное чувство, когда человек рассказывает о взятых вершинах, которые казались недостижимыми, и вы оба понимаете, что это плоды совместного труда. 📢Расскажите, предусмотрено ли наставничество на вашем месте работы и в каком формате? Вы бы решились на внешнее менторство?

🚀 Таблицы растут как Вселенная — остановить нельзя, но можно организовать. На Analyst Days 21 в своём докладе Кирилл Егоркин разрушил миф, что партиционирование — это панацея от всех проблем с производительностью. Он наглядно показал: партиции помогают выполнять запросы быстрее, потому что база сканирует не всю гигантскую таблицу, а только нужный «островок» данных. Но выбирать тип партицирования нужно с умом: range — для временных рядов, list — для чётких категорий, hash — для равномерной нагрузки без точечных запросов. Ключевой инсайт: партиции спасают, когда таблица перевалила за сотни гигабайт, а запросы всегда содержат ключ партиции. А вот на маленьких таблицах или при частых кросс-партиционных обновлениях они принесут только головную боль. «Большой взрыв на проде» случается не от партиций, а от их отсутствия, когда вы уже не можете ни удалить старые данные, ни перестроить индекс. Главный совет от Кирилла: смотрите на свои запросы, а не на моду, и тестируйте на реальной нагрузке. Сохраните себе — пригодится, когда ваша таблица достигнет размера сверхновой 🌌 Смотреть видео: https://vkvideo.ru/video-137540756_456239627

А вот и доклад с предыдущего Analyst days подъехал!

Предметная область: как глубоко нужно погружаться? За последние 2 года я сменил 2 места работы с абсолютно новыми предметками и каждый раз приходилось погружаться с нуля. В процессе всегда возникает вопрос: а можно ли не разбираться досконально? Спойлер: можно. 😨 Но обо всем по порядку. 📌Что дает глубокое понимание предметной области? - Меньше времени и сил на исследование контекста для каждой новой задачи - Знание подводных камней - Возможность обучать других - Проектировать проще, потому что можно заранее определить направления развития Почему я говорю, что можно строить систему без глубокого понимания предметной области? Потому что оно в любом случае появится в процессе работы. Можно проектировать систему на основании задач и контекста, постепенно углубляясь в процессы. Обычно при выходе на новое место есть 2-4 недели на раскачку. Можно спокойно разбираться, читать документы, ходить на встречи. Дают задачи на погружение с большими сроками. Но в среднем через месяц появляются реальные задачи, в которых от тебя начинают требовать немалых результатов, особенно если ты архитектор) 😬 Но за месяц нельзя полностью изучить предметную область. А ещё задача осложняется отсутствием материалов. Нет одного большого сборника, который бы позволил сесть и разобраться. Хорошо, если на проекте грамотно ведется документация и есть статьи или обучающие ролики. Но на практике бывает и такое, что знания добываются только из людей. Поэтому знания мы собираем по крупицам от стейкхолдеров, при выполнении задач и решении проблем. По моим ощущениям, без специализированной программы обучения первое глубокое понимание появляется в среднем через 6-8 месяцев. А что делать в первые пол года, чтобы не просто выжить, но и укрепиться на новом месте? 📎Мои рекомендации: определять границы процесса, искать ответственных и как можно больше копать и расспрашивать. Но здесь важно не попасть в ловушку погружения: когда выяснил один вопрос, но обнаружил три новых. Сразу хочется разобраться во всем. Для изучения предметной области это полезно, но для конкретной задачи — избыточно. Решения в рамках ограниченного контекста могут быть не идеальными, но на старте этого и не нужно. Я часто возвращаюсь к своим прошлым решениям и смотрю на них с высоты наработанного опыта. Думаю ли я, что сейчас сделал бы по-другому? В 90% случаев да, как минимум в деталях. Жалею ли я, что все сделал не так? Нет, такого не было ни разу. 📢 Поделитесь, сколько времени вам нужно, чтобы почувствовать себя уверенно в новой предметной области? И что помогает?

Четвертое февраля… 😨 Больше месяца не было статей в канале. Не то чтобы я забыл, забил или намеренно игнорировал. В голове постоянно крутилась мысль «вот сейчас одно-другое-третье доделаю, освобожусь и запишу пост». А потом бац, и прошел целый месяц, а я вообще не понял, куда это время делось. Откладывание — коварная ловушка, потому что планируя дело на потом, «в долгий ящик», мы чаще всего в нем его и бросаем. Как в том анекдоте: «Ну что ты каждый день спрашиваешь о долге, сказал же, завтра отдам!». И каждый раз нужно приложить колоссальные усилия, чтобы попытаться реализовать это будущее в настоящем. Рассказать вам, сколько я уже планирую выучить язык программирования Go? Если честно, эти мысли впервые пришли ко мне примерно в 20-21 году. А дальше все как обычно: ждал удачного момента, уменьшения нагрузки, или что материалы какие-нибудь сами попадутся. За пять лет так и не попался ни удачный момент, ни курс, ни книжка, волшебного пинка тоже не случилось. Получается, если я не сделаю над собой усилие, я никогда этим не займусь? Не совсем. В спасении из ловушки откладывания главное даже не усилия. Усилия — это костыль. Главное — системность и планирование. Именно они помогут выстроить вехи, дедлайны и крючки, которые будут постепенно двигать задачи. Самое базовое — делить сложные дела на маленькие кусочки. «Выучить язык программирования» — громоздкая необъятная цель, не понятно, как вообще к ней подступиться, и в каком случае она будет исполнена. Когда я получу грейд сеньора? А вот «поставить среду разработки» или «посмотреть вводный урок» — уже вполне понятно, измеримо и выполнимо в реальные сроки. Дальше все эти маленькие шаги планируем на конкретные даты. Например, ставлю ide в воскресенье на следующей неделе. И усилие воли нужно только на то, чтобы эту договоренность с собой соблюсти. Да и силы не улетают впустую на сокрушения «вроде хочется, но никак не дойдут руки». И если эту систему не саботировать, планы имеют четкие тайминги и вполне осязаемый результат. 📌 А вы часто откладываете дела? Как справляетесь с этим? Может, смогли разработать уникальную индивидуальную систему? 🐱

Всем привет! Настало время познакомиться поближе📍 Давайте устроим небольшую перекличку. Выбирайте в опросах свою роль и что вам интереснее всего читать в этом канале🙂