Transcription
Итак, мы начинаем. Сначала я представляю нашего спикера, главного сегодня Антона. Антон больше 20 лет в разработке ПО, поработал в компаниях самого разного размера и видел самые разные процессы и их нарушения. Он прошёл путь от разработчика до самого большого архитектора. Антон сторонник системного подхода и системного мышления, потому что архитектура и архитектура организации тоже — это выбор наименее плохого решения, обычно из нескольких плохих. Каждое из разрешений обычно вызывает свои проблемы.
Потом Антон много работал с очень сложными системами, как с технической точки зрения (на много, много тысяч микросервисов), так и с бизнесовой точки зрения. Вот. Ну, последние 5 лет Антон очень сильно специализировался на архитектуре и всём, что касается архитектуры внутри большой организации. А вот здесь вы можете прочитать подробнее. А это и интеграция, это и взаимодействие с бизнес-стейкхолдерами, и с другими стейкхолдерами, это управление техдолгом, это управление как вообще внедрять архитектурные практики, архитектурные процессы. Ну и, само собой, изменять саму архитектуру. Вот. Ну и, собственно говоря, обучение архитекторов тоже. Вот.
А что касается меня, то меня зовут Павел Рейник. Я сегодня помогаю Антону. У меня тоже большой опыт в IT. Ну вот на 2 года меньше, чем у Антона, если смотреть в абсолютном выражении. А вот я меньше специализируюсь в архитектуре, а больше, собственно, в разработке как таковой целиком. И последние несколько лет я занимаюсь вот проектом "Харсоки", с которым я обучаю опытных сеньоров по большей части, ну вот и архитекторов, и тимлидов тоже. Мы часто проводим всевозможные мероприятия, и такие как это, и других форматов. А чтобы их не пропустить, вступайте, пожалуйста, вот в наш коммьюнити. Думаю, что все, кто здесь, уже так или иначе в нём каким-то образом находятся.
Основная ценность тех курсов, которые мы делаем в Heals, — это мы не пересказываем книжки и статьи всякие умные, мы их не компилируем. Мы рассказываем про то, как происходит по-настоящему, потому что в книжках и статьях многие хвастаются и корректно пишут красивые вещи. Мы же рассказываем из своего опыта, из опыта тех, кто к нам приходил, про то, что по-настоящему. Вот.
А план у нас на час плюс вопросы. А, собственно говоря, представление. Антон, я закончил. Если хочешь, пожалуйста, что-нибудь добавь. И, собственно, расшаривай от себя и а-а такая.
>> Да, Паша, спасибо за такое шикарное интро. А я вас всех смею уверить, что у Павла на самом деле не менее шикарный архитектурный опыт. Э, вот, и он всё так же, так же, как и я, видел плохие процессы, может быть, так же, как и я, участвовал в нарушении процессов. Вот. Но на это всё был интересный опыт. И давайте начинать тогда. Э, Паша, ещё раз спасибо. Перехватываю шаринг тогда к себе.
А, скажите, экран видно?
>> Да, сейчас видны вопросы. На часть из этих вопросов мне удастся дать ответ по ходу моего рассказа. На оставшуюся часть потом отвечу сам или с помощью Паши. В общем, ответы точно будут даны.
А почему мы сегодня вообще собрались? Э история очень интересная. Э за последний месяц я из разных источников слышал один и тот же вопрос, чего раньше не происходило. Этот вопрос звучал: "А как вообще померить эффективность архитектора? Да? Как понять, что он вообще нужен проекту? Как понять, что он хорошо работает?" И вот всё вокруг этой мысли крутилось. И, э, простых ответов на этот вопрос не существует, а тем более в открытом доступе. И пришлось немножко поднапрячься, а, и покомпилировать там, а, весь опыт, э, да, и мысли на этот счёт.
Ну, естественно, оценивать работу архитектора невозможно, не понимая, чем он занимается. Поэтому, а, часть этого доклада будет посвящена, а, довольно сложному кейсу входа архитектора в проект. Возможны разные варианты. Я выбрал один из самых сложных. А вторая часть — непосредственно про измерение качества труда солюшен-архитектора.
Какие варианты в принципе-то возможны про архитектора? Ну, когда в компании уже есть один архитектор, его хотят заменить на другого, да, либо, например, отмасштабировать архитектурную функцию. Понятно, как собеседовать в ARHOPS, то есть процессы архитектурные уже выстроены, архитектор плавно, классно встроен в SDLC, цикл разработки программного обеспечения. В общем, все понимают, что это за роль и что с ней делать. А, а я буду рассматривать кейс, когда вот архитектора в проекте вообще не было, да, а и возникла необходимость в архитектурной экспертизе. Нужно что-то делать. И вот как вот нового человека в новой роли вводить в проект и чего от него можно ожидать и как это всё мониторить.
Доклад, естественно, не претендует на там академическую точность, полноту таксономии и так далее. Это вот, в большей части, наверное, основа, от которой вы сможете потом отталкиваться, да, и формулировать свои собственные там KPI, OKR и систему мотивации для архитекторов. Вот.
Ну, давайте тогда начнём с того, да, с простой мысли, что в любом проекте есть архитектура, начиная от дизайна кода, да, software architecture, так называемый. И даже там есть наборы метрик, которые, надеюсь, техлиды контролируют. Метрики типа там главная последовательность, абстрактность, афферентный дизайн-структур. В нём уже присутствует архитектура. Мы аналитики сегодня не будем рассматривать. Мы будем говорить про проект, который уже зарабатывает деньги, где есть много команд, где уже есть много кода, где уже можно что-то назвать Legacy. Проект, который сталкивается со сложностями. Но если архитектура есть, кто же её делает? Да, её, как правило, архитектурную функцию, архитектуру для проекта делают техлиды, либо лица, их заменяющие, да? Кто это может быть? Ну, наверное, какие-нибудь сеньоры-разработчики, может быть, там будет CTO. А, и все архитектурные вопросы складываются на эти позиции. Кроме того, что у них есть основная работа, они ещё и принимают архитектурные решения. А в чём особенность? Да, техлиды, как правило, сконцентрированы на потребностях одной своей команды, да? То есть они очень классно принимают локальные тактические решения. Это вот особенность.
А зачем делать архитектуру? В какой конфигурации? И первая, наверное, единственная причина, по которой им приходится этим заниматься, — это функционал, да, это потребность бизнеса в росте. Мы хотим пилить новые фичи. А, и, наверное, единственное нефункциональное, там, или неправильно сказал, бизнес-требование, бизнес-драйвер, который все слышат, — это Time to Market. Мы хотим делать много новых фич и делать их как можно быстрее. А забывают, забивают на при этом всё подряд, на самом деле, потому что представьте себе, что это был стартап. Вот стартапы должны очень быстро расти, да, расти, чтобы как раз удариться головой вот в технологический потолок в какой-то момент. Вопрос, хорошо ли техлиды делают архитектуру, в основе которой лежат функциональные требования? Я считаю, что хорошо они с этим справляются, особенно вот если смотреть на локальном уровне.
А, Паш, если ты хочешь где-то поправить, там подсказать, расширить, пожалуйста, не стесняйся. Вот. А и да, правило, там поднял руку, задал вопрос, оно актуально, не стесняйтесь. А вот и вот такая вот предыстория, да. Мм, вот такой проект, где есть такая конфигурация, такая оргструктура, а, и всё вот принято делать, э, как можно быстрее, а, ради фич продакшена. Ах, но случается то, что ждёт абсолютно всех. Да, я тут накидал некие предпосылки, которые будут толкать компанию к изменениям, да, будут говорить о том, что у нас точно идёт что-то не так, а нужно что-то менять. А, например, у нас, да, бизнес растёт, мы скейлимся по людям, скейлимся, стало много команд, нужно делать интеграцию между командами. Решения все супер, супер классные и локальные, но на уровне интеграции начинаются проблемы, да, начинаются конфликты. Техлиды не могут между собой договориться. Один говорит: "Это лучше", другой говорит: "Это лучше" и так далее. А сюда же к техлидам подключаются экспертиза DevOps, подключается экспертиза фронтендеров, отдельно бэкендеров, и всё превращается в кашу. Вообще у нас, значит, дальше зоопарк технологий, э, разные версии фреймворков, конфликты интерфейсов, постоянно что-то где-то отваливается, невозможно никак договориться. А возникает дублирование функционала, да, одна и та же маленькая функция прорастает в разных местах проекта, сделана по-разному разными людьми, а работает немножко по-разному, а поддерживает, соответственно, становится проблематично.
А важный поинт, прямо флаг такой вот стопроцентный, — это нету нефункциональных требований, да, nonfunctional requirements. Их просто нет, ими никто не занимается, никто не ходит к стейкхолдерам, не задаёт вопросы: "А что нам нужно делать с usability, с performance, security, с вот это вот, вот эта вот вся история с атрибутами качества?" А если даже и ходят, не могут задать правильный вопрос, потому что в ответ слышат. Ответ какой? Они слышат: "Должно быть как у всех, да? Должно быть быстро, должно быть классно", но это неизмеримые метрики. И вот этих техлидов не хватает опыта и знаний, чтобы задать правильные вопросы, чтобы собрать эти требования и потом заимплементировать их непосредственно в продукте. А нет документации, естественно, на всё это дело. Никто не знает, как всё устроено. Ну, я думаю, что все с этим сталкиваются, да, периодически. Возможно, даже наш стартап такой крутой стал, что нами заинтересовались регуляторы, от нас требуют соблюдения каких-то законов, нам нужно получать, проходить какие-то сертификации, а поскольку кто в лес, кто под дрова, сделать это, ну, практически невозможно становится. Никто не знает, даже с какой стороны к этому вопросу подступаться. А долгие релизы, да? А релизим очень, а, редко, стоим в очереди, постоянные конфликты, что-то отваливается. В продакшене постоянные инциденты. Искать концы очень сложно, потому что кто-то что-то логирует, кто-то что-то не логирует. Логирует по-разному. По системам брать невозможно. Короче, работа с инцидентами не клеится никак вообще. А бизнес растёт, у него появляются стратегические планы на год, на два, на три. Бизнес всё это видит, и он не верит просто, что эта команда вот с такими процессами, да, которая говорит, что мне, чтобы кнопочку перекрасить, мне нужно там в пять сервисов сходить. Мы не можем обновить версии, потому что везде разные, везде что-то отваливается постоянно. Бизнес не верит в то, что такая команда затащит бизнес-план, да? А это тоже крутой такой редфлаг. А, ну и, аэ, существует такое мнение по компании ходит, да, типа: "Всё плохо, ничего нельзя решить без CTO". CTO сваливается в техню, в операционку в такую. И, а, в общем, вот такой скоуп причин, предпосылок делает невозможным дальнейшее развитие бизнеса как такового. А я понимаю, что что-то нужно делать. Вокруг происходит некий хаос, вообще неконтролируемый хаос. И никто не знает, с чего начать, э, да, куда приложить усилия, чтобы там качественно изменить ситуацию. Никто даже не может описать всю эту историю, как-то ограничить границы, простите, невозможно становится. В общем, неуправляемый хаос происходит.
И, значит, возникают, как я тут это назвал, наивные ожидания, да? Наивные ожидания. Вот ребята эти собираются там, а, DevOps, техлиды там, все, все начальники собираются и думают: "А, ну, мы ж, мы ж в принципе-то умные ребята, да? Мы вот уже там сколько лет этот бизнес тащим. А у нас есть вот все мы у нас есть, да, и CTO классный, и всё классно, но всё не клеится. Может быть, нам кого-то не хватает". Ну, естественно, ум приходит, что не хватает именно архитектора в этой дружной команде. И архитектор представляется как какой-то человек с... Да, Никит, привет. Реакция твоя понятна. Я про это говорил уже. Да, ты знаешь. А мифический человек, который обладает невероятнейшей экспертизой, во всех доменах по 100 лет проработал, все нюансы бизнеса знает, стоит у истоков абсолютно каждой новой технологии. Этот архитектор, да, он прямо силой одной мысли понимает все проблемы, силой другой мысли решает все проблемы, и они сразу в продакшн выкатываются. Силой третьей мысли все инциденты сразу решает. Ему ничего объяснять, показывать не нужно. Он без документации всё и так поймёт. И, короче, нам нужен архитектор. Вот с такими мыслями, короче, эта компания думает, где же взять архитектора, да?
М, поскольку у них архитектора раньше никогда не было, у них есть, по сути-то, два варианта, да? Вариант там аутстафить, аутсорсить — я не рассматриваю, но, наверное, имеют место быть, не знаю. Первый вариант — это воспитать архитектурную функцию внутри себя, вырастить среди своих инженеров, техлидов. Вот это мой путь, кстати, был архитектора. Но вопрос: а если достойный кандидат? Да? Можно ли ему верить? Потянет ли он эту работу? Обосрётся, не обосрётся? Типа, получим результат или потеряем полгода? Непонятно. Это первый путь.
Второй путь, когда это уже кандидатов рассматриваем, да? Второй путь — это выйти на рынок да и поискать там человека. Мм, как оценить его архитектурную экспертизу, не имея экспертизы внутри? А, ну, вопрос сложный, скорее всего, на уровне там своих ощущений. Адекватный человек, неадекватный. Понимает проблематику какую-то, не понимает проблематику. Ну, как-то вот компания решает выходить на рынок и искать архитектора на рынке, потому что среди своих ребят никто не готов брать на себя новую роль и вот эту новую ответственность.
А дальше происходит стадия "всё новое". То есть было интервью, вот был офер, наняли человека, и вот он выходит. При этом-то на интервью ему никто не говорит, что происходит полный хаос. Да, никто не рассказывает, что проблема есть. Вот куда не ткни. Это, кстати, один из вопросов был типа: "А что делать, если приходишь на проект и видишь, что там полная жопа?" А это нормально, да? В таком состоянии там половина проектов точно пребывает. Главное не паниковать, да, вот и не убегать в первый рабочий день, потому что в стрессе пребывает не только архитектор, но и наниматель, компания, люди, продукт, но новый продукт, всё новое. Фаза называется "всё новое" для компании. У нас новый человек и новая непонятная роль, на которую возложены невероятные надежды по спасению бизнеса. Да. С одной стороны, с другой стороны, а, архитектор, для которого новый продукт, да, допустим, редко бывает, что ты успешно переходишь с одного домена в тот же самый домен, да? Ну, это, если честно, скучновато, хочется иногда ротировать доменные области. Короче, домен новый, продукт со своими особенностями новый. Невероятно шикарная корпоративная культура, про которую там легенды слагаются, но непонятно, она на деле такая же крутая или как обычно, да? А непонятные процессы, эта документация и вот это вот всё-всё-всё для архитектора тоже новое. Огромный скоуп вот этого хаоса падает на этого человека. Все находятся, пребывают в стрессе. А-а, и тут важно, что? Важно не пытаться всё сломать и всё изменить к лучшему, а системно оценить ситуацию и понять, собственно, есть ли у тебя, а, знания, сила, возможности поменять, а, изменить, да, картину мира и хочешь ли ты это делать. Вот для этого, в общем-то, существует там испытательный период, чтобы ты, собственно, определился, по силам тебе это, сможешь ли ты тут быть полезным. А да. А хочешь ли ты это делать или стоит поискать другую жопу? Ну, короче, оттенки серого, они все примерно везде одинаковые окажутся. И вот уровень хаоса, а он тоже относителен, да. Всё зависит от того, что ты до этого видел, из какого проекта ты перешёл в новый проект. Может, в прошлом проекте было ещё хуже, а здесь уже, например, уже что-то хорошо, уже тебе легче будет, уже будет какая-то опора под ногами.
И, собственно, архитектор начинает копать, разбираться, разбираться, разбираться. И, собственно, я тут накидал, а, реальные ожидания, которые можно выяснить в процессе вот исследований, да, архитектурных. Скорее всего, вот этот набор он у всех точно будет. Будут ещё дополнительные пункты, но эти пункты будут точно везде. По классике, аа, фичи должны быстрее выходить на рынок. Это то, с чего начинал стартап, то, ради чего копился техдолг, то, из-за чего возник хаос. Это желание бизнеса, оно 100% будет прослеживаться буквально в каждой инициативе. А частые, быстрые релизы будут ожидать, да? Меньше командных зависимостей. Это всё взаимосвязано, на самом деле. И будут ожидать, что в архитектурных решениях не будет деградации SLO. Ну, во-первых, SLO появится, да, работа с анонимами появится, и мы будем только улучшать картинку. Мы не будем там нигде деградировать. А, ну или делать это супер осознанно, а, ввиду приоритетов других атрибутов качества. Так, зауно скажу. К примеру, возникают вот такие вот новые, новые серьёзные ожидания, на самом деле, уже вот формализованные в конкретные пункты. То есть из хаоса архитектор смог выделить какие-то вещи, которые можно померить, можно пощупать.
И, собственно, это начинается время новых, я назвал "новые договорённости", да? Поскольку уже новый архитектор, он знает, что придётся делать, и ему нужно свою роль, свою архитектурную функцию аккуратно, красиво вписать в существующую картину мира в компании, да, в существующие процессы. Делать можно по-разному. Я предлагаю вариант такой. Расписываем матрицу RACI без примера. Матрица RACI очень простая. А-а, на ней наносятся разные роли: там архитектор, техлид, DevOps, SRE, CEO, продукт, в общем, разные роли. А в строчках расписываются разные функции: например, сбор таких требований, анализ таких требований, там формирование решений, ревью решений. И вот такая матрица создаётся, и в каждой ячейке расписывается, какая роль в каком процессе, за что отвечает. Кто-то непосредственно делает какую-то работу, кто-то несёт ответственность за конечный результат. Кому-то нужно просто результат показать, это его устроит. Кто-то будет консультировать в каком-то процессе. И а вот я предлагаю для архитектора и да и не только для архитектора делать такую RACI-матрицу, в которой станет понятно, кто за что.
Секундочку. Мог бы ты аббревиатуру расшифровать?
>> Блин. А нет, забыл. Responsible, Accountable, Consulted, Informed, по-моему, так.
>> Да, да, вспомнил. Вот. А, альтернативно RACI-матрицы может там стрим-мапингом можно заниматься в табличном формате, расписывать артефакты, триггеры, функции. Можно делать обычную, э, как это называется? Вот в гостах есть документ, который вписывает его обязанности. Как он называется?
>> Должностная инструкция.
>> Да, да, точно. Должностную инструкцию можно писать на архитектора, но слишком формально. Я вот люблю RACI делать. Становится понятно визуально, кто за что отвечает, да, и чем будет заниматься архитектор. К RACI-матрице, должностная инструкция, полномочия. Да, Ринат, спасибо. К этой RACI-матрице нужно обязательно приложить некую легенду. Я вот назвал её "механики", да, это описать процесс перехода, да, как какая-то инициатива будет перемещаться между ролями, перемещаться между процессами и так далее. Как, собственно, использовать архитектора в рамках вот этой RACI-матрицы. И это, собственно, вот опорная вещь, с которой можно начинать понимать вообще, кто такой архитектор, за что он отвечает, что он делает и как контролировать вообще его работу, да? Вот делает он там AR, если должен, или не делает. Ну, такая простая, примитивная логика, булева буквально, да, но это уже что-то, с чего можно понять, типа, выполняет архитектор какие-то договорённости или не выполняет.
Я хочу обратить внимание всех. Видите, Антон рассказывает про начало работы архитектора. Это вообще не звучало ни слова про технологии, про там, не знаю, нагрузку или что-то ещё. Это коммуникации.
>> Да. А всё верно. А я так спешу пройти по материалу, чтобы оставить тебе немножко времени, что могу что-то забыть сказать. А, спасибо большое.
>> А, собственно, в этот момент можно подумать ещё про экстрамотивацию, которая посвящена вот вся нижняя часть доклада про конкретные метрики. Это мы говорим про UAR, OKR и вот то, что можно померить, да, не просто сделано, не сделано, а прямо в числах чётко, а, объективно оценить качество работы архитектора. А, и на этом я готов идти дальше. Если вы готовы, то давайте пойдём дальше.
>> Рука.
>> Можно вопрос? Привет. Я как раз из Риги, и моя позиция — это системный архитектор в домене финтеха. И вот то, что сейчас рассказывается, по факту — это изменение текущих процессов и культуры. И я приходил, вот всё то, что было выше — это то, куда я пришёл какое-то время назад. И всё упирается в то, что это изменение процессов, и без воли свыше, которая, собственно, и часто является причиной вот этого всего в списках предыдущих проблем. Мм, очень важно, чтобы вот эту RACI-матрицу написать-то можно и механики можно рассказать. Но если культура уже сложена, то это переламывать будет же крайне сложно.
>> Да, слушай, ты абсолютно прав. А вот организационный чейндж-менеджмент, особенно в части там сложившихся каких-то неформальных правил, это одна из самых неблагодарных работ в мире, наверное, ну, в айтишке, я бы так сказал.
>> А и мой вопрос: а почему это про солюшен-архитектора, а не про CTO?
>> А, да, слушай, всё, всё ж очевидно. А тебе нужно для решения бизнес-задач ввести в оргструктуру новую роль, новую, никому незнакомую роль. И этого-то все хотят, на самом деле. Вот я до этого рассказывал, что есть вот эти вот наивные ожидания, да, а, но их никто не может описать. Они там копируют из чужих вакансий требования, чем придётся заниматься, вот это вот всё, да, но по факту они не осознают, что за этим стоит, да? А когда появляешься ты, ты понимаешь чётко, о чём речь, да, что о чём вы говорили и что происходит на самом деле и как с этим можно быть, да, как ты можешь свою экспертизу аккуратненько вот с условиями того самого плавного чейндж-менеджмента интегрировать в существующую культуру, в существующие процессы так, чтобы не стать бутылочным горлышком, никаких сильных властей там не посягнуть, а достигнуть результата, ради которого тебя в компанию пригласили. Поэтому, когда ты пишешь RACI-матрицу, расписываешь механики, ты должен всё это учесть именно на плавную интеграцию. А ещё очень важно потом сделать презентацию этого дела, собрать вот всех этих вот стейкхолдеров, да, которые тебя очень хотели. И, э, почему RACI — очень простой инструмент, и он очень распространённый. Вот люди бизнеса с ним там с ним 100% знакомы. Системные аналитики, бизнес-аналитики с ним 100% знакомы, а инженеры очень быстро с ним познакомятся, это вообще не проблема. И на понятном, примитивном, детском языке им всем рассказать, что смотрите, а вот нужно это делать для этого. Чтобы это сделать, мне нужно вот это получить на вход, вот это на выходе отдать. При этом я не буду никого тут блокировать, и мы об этом ещё потом дальше поговорим о возможных последствиях.
>> Да, спасибо, не буду задерживать. Паш.
>> Да, спасибо за вопрос, Паша. Я хочу ответить чуть-чуть с другой стороны на тот вопрос вот который задал, сорри, забыл.
>> Максим.
>> Максим. А значит, Антон рассказывает эту ситуацию для кейса, когда архитектор пришёл и такой: "О, него все ждут, все хотят". Или он уволится до окончания испытательного срока, потому что капец, а или э или он это сделает. И вот без этого никак. На самом деле CTO в такой организации вырос из скорее всего инженера. И он думает, с одной стороны, или про партнёрство в бизнесе, с другой стороны, он думает про как будет ещё покодить по старой памяти. Вот CTO вообще про эти вещи не понимают. Их в компании просто нет человека, который может ставить разработку, а ещё сложнее архитектуру на scale. Ещё разработку может кто-то и поставить на scale, на масштаб. Архитектуру на процесс никто кроме архитектора не поставит, если он первый в компании. И вот для этого кейса Антон, собственно, описывает историю. Второй архитектор, тебе уже проще, но CTO, скорее всего, просто не знает, что в MLOps, ну, есть вот такие тактики, практики и так далее.
>> Во всём этом есть смысл. Спасибо за дополнение. Просто это ещё чуть-чуть, и архитектор уходит в менеджмент процессов. Вот. Но спасибо большое, не буду задерживать больше.
>> Так, а секундочку. А, да, а в менеджмент процессов нам уходить совсем не хочется, потому что если бы мы хотели быть менеджерами, мы бы, наверное, пошли бы в сторону CTO куда-то туда.
>> В том-то и дело.
>> А, да, но, к сожалению, это часть игры, да. Ты без процессов ты не сможешь быть эффективным 100%. А вот поэтому, если нужно где-то подкорректировать, э, и ты можешь объяснить, зачем это нужно, какие бенефиты получат продукт и компания, я думаю, что сопротивление будет минимальное. Опять-таки, есть там техники чейндж-менеджмента, и если пойти по учебнику, можно достигнуть ожидаемого результата. Системный подход, да, опять.
А, так мы закончили на экстрамотивации, и я предложил пойти дальше. Дальше начинается работа, да? Все потихоньку начинают пользоваться архитектурной функцией, и там разные варианты есть, что с этим можно делать. Архитектор каждый день, собственно, начинает получать обратную связь от людей, с которыми коммуницирует, да? Он понимает, хорошо он делает, плохо он делает, можно ли лучше, с теми людьми разговаривает, не с теми. В общем, он ежедневно может корректировать своё поведение, да, если обратная связь негативная, либо продолжает делать то, что хорошо получается. Ещё есть там утверждающая обратная связь, но мне кажется, эни хватит рассказать, как этим можно пользоваться. Это когда мы, а, корректируем, э, сегодняшнее своё поведение, исходя из того, что могло бы быть в будущем. Вот хит, хитрая хитрая история. Э зря я сюда написал, кстати. Ладно. А это ежедневная.
Рутина. И дальше мы переходим к, мм, уже непосредственно к метрикам. Да, я вот специально так зафреймил экран. Начнём с законов Гудхарда. Фундаментальная вещь вообще в работе с метриками. Закон Гудхарда по памяти звучит примерно так, что как только метрика становится целью, она перестаёт быть хорошей метрикой, да? Это означает, что, а, например, э, мы что-то меряем у какого-то человека и говорим, что ты за это будешь там получать экстра-экстра бонусы по этой метрике. Естественно, человек начнёт искать способ эту метрику похакать, да? Что значит похакать? Это значит, э, не искусственно, но в принципе будет происходить увеличение показателя по этой метрике за счёт негативного влияния на другие, не менее важные метрики. Может быть, даже для этого же человека, может быть, для других людей, может быть, для компании в целом, неважно. Короче, он пушит здесь, при этом падает где-то в другом месте. И поэтому вот Гудхард говорит, чтобы избежать такого перекоса, нам нужны так называемые балансирующие метрики или контрметрики. То есть, наблюдая за одной метрикой, по которой мы оцениваем работу человека, мы должны наблюдать ещё вторую метрику, чтобы понять, что не было негативного влияния и чувак не похакал свой KPI. Да, это, ещё раз повторю, фундаментальная вещь. Если вы этим не пользуетесь, начинайте пользоваться, возможно, вас ждут интересные открытия в своём продукте, в своём коллективе. Вот. А без этого я бы даже не думал ни про какие там исчислимые способы оценки труда людей.
А с этим всё. А следующий поинт, да, 360. Мм, да, всем известная история. Опять-таки, ровно как она проста, она такая же и сложная. И в моём опыте работы с опросниками, которые называется 360, оказывалась не очень эффективной. Да, я не знаю, как у вас, может быть, у вас всё классно, и то, что там пишется, оно там воплощается потом в жизнь, и эта обратная связь работает и показывает стороннюю картину мира. Но у меня с 360 сложилось, наверное, не очень хорошо. Вот, может быть, неправильно использовали, может быть, никто не считал нужным заполнять эти анкетки, тратить своё время и так далее. Но, а, в 360, что хорошо, мм, там, э, можно отследить софтовую часть, да, не хардовую, а софтовую. Вообще понятно, насколько человек хорошо коммуницирует, насколько он комфортен, насколько он там, а, лоялен, э, эмпатичен, и так далее. Вот это, да, это классно. Это очень распространённый инструмент для оценки. Я уверен, что в каждой компании его так или иначе используют. И не сказать о нём я просто не мог в силу вот его распространения и популярности. Аэ, да.
Дальше интересный пункт идёт, да, он называется связь с бизнес-драйверами. Этот пункт, наверное, не очень хорошо поддаётся там механизации какой-то, ну, в смысле, автоматическому подсчёту чего-то, но супер, на мой взгляд, суперважный. Что такое связь с бизнес-драйверами? Да, это история про то, что вся работа архитектора так или иначе направлена на достижение бизнес-целей, да, через инженерные практики. И когда у архитектора есть выбор реализовать какую-то функцию вот таким способом, таким или таким, у нас на сцену выходят ограничения, там допущения, атрибуты качества. И всё можно сделать по-разному. Одного и того же функционала можно добиться разными путями. А, но важно, что важно, чтобы реализация она соответствовала бизнес-целям, стратегическим бизнес-целям компании. А это важно и для реализации, и для приоритизации. Можно делать работу, которая, ну, просто звучит классно, но, например, бизнесу сейчас особо-то и не нужна. Можно делать не очень классную, не очень удобную, но суперважную для бизнеса работу. Если в ретроспективе архитектора, архитектор, как он может рассказать? Типа, вот мы будем делать таким образом, потому что, э, ну, потому что это крутая технология. Это плохой ответ. А если архитектор вам говорит про то, что у нас были разные варианты, и мы решили, а мы потому что нужно всё ревью, второе мнение всегда обязательно получить, мы решили, у нас есть там табличка, риски, вот всё там задокументировано, да, наша мотивация сделать вот так, потому что бизнес от этого получит это, это, и это будет положительно влиять на там, например, revenue, да, на acquisition клиента, там на пожизненную там пожизненную сумму денег с клиента, мы будем cost-effective и так далее. А и это приближает архитектора к бизнесу. И это как раз-таки то, что позволяет архитектору давать обратную связь в разработку. А потому что любое решение можно объяснить с точки зрения бизнес-мотивации. И любую конфликтную ситуацию, любые там подравнять ожидания стейкхолдеров, да, можно объяснить с точки зрения бизнес-мотивации. Иногда бывает так, что один техлид говорит: "Будем делать так, потому что мне так больше нравится". Другой говорит: "Мы будем делать так, потому что я уже так делал". А одно решение просто прикольное. Второе решение, оно классно укладывается там в бизнес-стратегию на двадцать пятый год. Вот. И когда ты вот вот эту фразу скажешь: "Слушай, ты молодец, но оно никуда не пробьётся, да, мы не сможем это объяснить". А это прямо вот укладывается в бизнес, в бизнес-драйвер в какой-то, и мы сможем потом ещё и презентовать офигенно это. А все техлиды сразу соглашаются. Ну, это история там про коммуникацию, про то, как добираться результатов через групповую динамику. А вот это важно. А если в общении с сетью, когда общаются с архитектором, не слышит привязки к бизнесу, э, ну, я бы попросил обратить на это внимание, да. Я бы попросил архитектора в своих речах, да, в своих выступлениях, в своих решениях начать привязываться к бизнес-домену. Вот даже, например, блин, сейчас по примеру много времени потрачу. К примеру, продакт-оунер выступает, презентует там результаты спринта и говорит: "Вот мы там спринт работали, и теперь у нас есть одна на фронте одна красная кнопка, типа, ну вот вот такая презентация". И, например, он говорит: "У нас есть одна красная кнопка вместо десяти кнопок, которые были раньше". В результате мы смогли улучшить там пользовательский опыт. А, во-первых, мы точно уверены, что это повлияло на на конверсии, да. Мы стали чуть-чуть больше денег зарабатывать. Мы просто ещё не оценили масштаб этого улучшения. Мы точно сняли там часть нагрузки с системы, потому что сейчас, ну, мы там одну ручку дёргаем вместо десяти. Я так утрирую, да, мы улучшили перформанс, мы улучшили юзабилити, мы высвободили ресурсы. И, например, мы сейчас даже, а, мы улучшили свои там SLA показатели перед клиентами, мы улучшили, да, и, соответственно, у нас в SLA в бюджете недоступности появился, а, появилась возможность, которой раньше не было. И мы сейчас можем либо придержать эту возможность, либо, например, мы можем улучшить там свои SLI перед клиентами, да? А улучшение SLI перед клиентами позволит нам соответствовать требованиям регулятора, не знаю, там, Восточной Европы, к примеру. А выход на на рынок Восточной Европы — это там супербизнес-цель на двадцать шестой год. И вот когда так продакт-оунер презентует, да, со связью с бизнес-метриками, с бизнес-драйверами, вот это же звучит капец как мощно, да? Одну кнопку поменяли, а такие возможности для компании открылись. А, так, короче, идём дальше. Да, у меня увлёкся.
А, па-пам-пам-пам. И давайте сейчас поговорим непосредственно про то, что можно посчитать. Мм, список вообще не полный, э, просто чтобы показать разброс возможностей. Классическая, классическая метрика, типа у нас какое количество архитектурных решений соответствует архитектурной стратегии. Я сюда не стал вписывать. У меня эта метрика почему-то никогда не работала, как следует. А, смотрим cost-effective, да, к примеру. Мм, что это такое? Это, э, цена одной транзакции. Под транзакцией понимается бизнес-транзакция, не транзакция в базе данных, а законченная какая-то, а, э, бизнес-экшн какой-то. Spend — это стоимость инфраструктуры, делённая на количество транзакций, да? Вот такая простая формула. Мы делим, например, 20.000 долларов в месяц на 1.000 транзакций. Получаем стоимость одной бизнес-транзакции 20 долларов, да? Фактическое то, что за в прошлый месяц было, и потенциальное. Вот это потенциальное — это интересно. А если архитектор в состоянии уменьшить стоимость транзакции, это выглядит именно как cost-effective. Например, мы внедряем какое-нибудь кэширование, да, какие-нибудь хитрые паттерны и говорим, что теперь мы на инфраструктуру тратим не 20.000 долларов, а 10.000 долларов. Вот. И этот cost-effective коэффициент, он вместо 20 долларов превращается в 10 долларов. Вот какая измеримая метрика на качество архитектурного решения.
А дальше идёт блок, связанный с НФАми, да, нефункциональные требования, которых никогда в проекте не было, они начали появляться. А здесь абсолютно неисчерпывающий их список. Полный список никто никогда не использует. Выбирают там топ-три-пять самых важных, которые помогают попадать к решению бизнес-стратегию. Но самые популярные, наверное, это availability, performance, error rate — это больше из scalability и reliability, наверное, то, что на слуху, то, что сложно померить и то, что теперь продукт начинает измерять, потому что архитектор пришёл и рассказал стейкхолдерам, как через нефункциональные требования через SLI, они все через по всем NFA мы строим индикаторы SLI и потом формируем, да, внутреннее такое внутреннее соглашение, по которому мы можем реагировать, делать трешхолды, строить observability и так далее. Всё это можно уже, когда в проде назвать слон, наверное, для такого общего понимания. И архитектор смог объяснить, как через SLI можно влиять на продуктовые метрики и на бизнес-метрики, да, как работая с перформансом и availability, можно конверсию улучшить, да, или стоимость привлечения клиента уменьшить. И возникает для бизнеса новая возможность не через продуктовые продуктовые инициативы зарабатывать больше денег. Вот. И бизнес начинает этим пользоваться. И, э, можно архитектору ставить цели, договориться, конечно, с архитектором на следующие цели. Например, мы начали мерить его какого-то там mission critical процесса, и он у нас там 95%. Мы осознаём, что мы хотим по availability поработать. И давай-ка мы там за портал попробуем, а, составить план, а, дореализовать его и там до 99% availability поднять. Всё это можно померить. А паттернов, тактик огромное количество. До трёх девяток, наверное, архитектор легко вообще доберётся. Что касается, то же самое касается всех остальных, э, нефункциональных требований. Всё, что можно померить, а всё, на что архитектор может повлиять через архитектуру. По изменению этих метрик можно судить о качестве архитектурной функции. А вот тем более все эти метрики очень круто между собой связаны, и архитектор может этим пользоваться. Например, неизбежное улучшение перформанса будет влиять на улучшение, например.
А тут долго я останавливаться не буду. И давайте пойдём вот к интересной методике, которую точно стоит замерять. TA, так называемый архитектурный lead time. Что это такое? Это время от того момента, когда появился запрос на архитектурное решение, да, либо на консультацию архитектора, а до некого артефакта, который архитектор даёт на выходе, да? То есть это по факту, сколько архитектор времени проработал над какой-то задачей. Просто так мерять всё подряд неинтересно. Поэтому можем мерить, например, медиану либо какие-то хвостовые перцентили. Ээ, задачи у нас бывают абсолютно разные, да, нельзя там, а, разного размера задачи, сваливать в одну кучу. Типа как класса обслуживания в в Kanban. А нужно, даже нужно строить некие когорты делать. Аэ, я вот, например, люблю по размеру инициативы. Если если инициатива бывает четырёх видов: задача, программа, проект и трансформация, соответственно, разного масштаба, разной сложности, то отдельно мерить, э, вот этот lead time, например, на девяносто пятом перцентиле по обычным задачам, по проектам и там по всему остальному. А контрметрики, да, по закону Гудхарда. Так, чей-то курсор здесь был. Паш, да. А по закону Гудхарда, а контрметрика для по сути lead time — это скорость, да, естественно, скорости будет противостоять качество работы. Если архитектор начнёт хакать метрику lead time, возможно, он это будет делать возможно за счёт качества, да? Мы должны убедиться, что качество при этом не страдает. А, например, что мы можем мерить в качестве контрметрики для lead time? Первый пример, вот как раз как слайд сформулировано, количество реворка за 30 дней. Да, приходилось ли архитектору потом возвращаться к работе, которую он уже отдал, к своему там ревью в течение там следующего месяца и что-то переделывать. Вот можно можно сделать это превратить прямо в списать количество реворка за 30 дней не должно превышать, например, там 20%. Ну или или как-то так. Или другая контрметрика, деградация SLO после внедрения, да? Если архитектор спешил, а он мог негативно повлиять на availability, на перформанс, на security, на что угодно. Если после внедрения решения мы увидели, что какие-то NFR, они же SLO, поплыли вниз, это говорит, возможно, будет говорить о том, что качество решения было недостаточно хорошее. Возможно, что-то не учли и похакали таким образом lead time. То есть метрики нужно эти оценивать в балансе вместе друг с другом.
Так, идём дальше. На что как архитектор, собственно, да, может повлиять на на свой этот самый lead time? Стандартизируем артефакты, да, то есть упрощаем вообще максимально всю эту историю. Максимально заранее резолвим все зависимости. Если мы знаем, что в каком-то модуле нам приходится придётся решение из локального сделать глобальным или другую команду какую-то работу отправить. Ну, можно эту работу туда отправить заранее, заранее для них сделать маленький модульный тест и в текущем модуле это уже не учитывать, да, это сократит количество работы в рамках одной инициативы у архитектора. Э, можно использовать техрадар, а можно использовать системные подходы, прямо обязательно нужно использовать системные подходы. Откуда берутся системные подходы? Они берутся из обучения. Вот один из вариантов обучения — это, да, skill, например, да.
А посмотрим следующую метрику, возможную для архитектора — FF Coverage. Это покрытие так называемой фитнес-функциями, функциями качества. Что можно мерить? Можно мерить долю компонентов, покрытыми под покрытых теми самыми фитнес-функциями. А если нужна справка, что такое фитнес-функция, даже книжка есть про это отдельная написанная. А погуглите, пожалуйста, самостоятельно. Но это в общем, в общем смысле и плане, это автоматизация э-э тестирования нефункциональных свойств решения, да, когда мы в CI/CD начинаем встраивать что-то, что тестирует архитектурные решения. Один из подходов, кстати, к архитектуре как коду. Что мы делаем? А, отбираем Mission Critical сервисы. А мерить всё подряд и замерять всё подряд бессмысленно. Есть сервисы важные, на самом деле. Есть условно никому не нужные. Упал, пускай через неделю это заметят, бизнес не пострадает. Для этого нужно, конечно, предварительно сервисы поклассифицировать. А есть разные системы классификации. Мне нравится, не помню, как называется. Четыре уровня критичности сервисов. В ней присутствует Mission Critical, Business Critical, Business Operational и Office Productivity. Я наизусть помню прямо. Соответственно, разные требования по-разному мы следим за этим, по-разному эксплуатируем и так далее. Самые крутые сервисы — это Mission Critical, сервисы, которые стоят на критическом пути пользователя. То есть то, что никогда никак ни в каких условиях не должно сломаться. Вот мы их выбрали. Мм, потом кодифицировали, собственно, правила и тесты, которые должны на CI запускаться. Настроили CI, а сюда же в кучу, да, дописал. Потом уже можно добавить и контрактное тестирование, если у вас его не было. Очень прикольная история. Помогает очень сильно управлять интеграциями и не выпускать в продакшн, а заглушенные решения. И всё. И меряем деградацию этих самых SLI. А сюда же можно напихать много всякой истории, но опять-таки тут же архитектура как код начинается. А важно, что важно, чтобы всё это опять-таки соответствовало бизнес-требованиям, а, да, и имело смысл. А контрметрики тут довольно тяжёлая ввиду вот того, что мы по сути тестируем качество. Соответственно, контрметрики для тестов качества должны быть основаны на проверке качества тех самых фитнес-функций. То есть мы должны проверять то, что Максим, секундочку. проверять то, что на самом деле имеет смысл проверять. Должны быть уверены, например, что если пайплайн зелёный, что он действительно не содержит в себе проблем, и мы в продакшн ничего не выпустим запрещённого. Да, Максим.
>> У меня вопрос на тему архитектурного надзора. Ведь всё вот это вот сказано в предыдущем блоке, оно так или иначе результат нашей деятельности. Но нам нужно убедиться, что разработчики делают то, что мы хотим и так, как мы хотим. А часто они такие: "Ну, у нас вот тут в соседнем там репозитории написано так: "Мы просто скопипастили".
>> Угу.
>> Погнали, да? Вот. И как вот этот архитектурный надзор в процесс впилить и так, чтобы ещё личная жизнь оставалась?
>> А, да, слушай, это классный вопрос. А вот ты прямо чувствуется, что боли свои транслируешь. А вот аа и дополнение про то, чтоб там э личная жизнь какая-то оставалась. Абсолютно точно. Это, кстати, вопросы governance тут не затрагиваются в в этом докладе, к сожалению или к счастью. Спасибо.
>> А, ну давай я всё-таки выскажу там коротенько своё отношение к этому вопросу. Абсолютно точно в современном мире. Вот если всё настроено, мы красиво, там CI/CD работает как надо, а там хорошо система распределена, observability настроена, incident management настроен, всё всё вот это вот, если работает, очевидно, продукт развивается, технический долг списывается там. Очевидно, что у тебя будет невероятное количество, а, решений, да, а, невероятное количество а деплоев кода в день. И абсолютно точно невероятно это всё вручную проверять, насколько каждое решение соответствует имплементация соответствует задуманному решению. И для меня тут единственный выход из ситуации, который, э, который имеет смысл на который имеет смысл тратить ресурс — это кодификация всей этой истории. То есть поднимать архитектурные репозитории, все решения кодифицировать, всё автоматизировать, всё это запихивать туда. Это если делать в масштабе. Точечно, конечно, суперважные инициативы ты, наверное, вручную сможешь проконтролировать, но но в потоке, на масштабе только автоматизация с поможет.
>> Ну, потом приходит волшебный time to market от бизнеса. Очень срочно для якорного клиента что-нибудь зарелизить, и всё идёт лесом.
>> Ну почему идёт лесом? Вот я, насколько я с людьми разговариваю и задаю вопрос, типа, а вы вот вообще бизнесу объясняли альтернативы? Типа, да, вот чем мы будем жертвовать ради вот этой вот хотелки якорного клиента? Какие у нас есть вообще опции и варианты? Сделали вы бизнес с участниками этих решений? Все говорят: "Нет, мы этому не говорили, мы боимся им это сказать". А потом поэтому бизнесы приходят и кочергу нам засовывают в одно место, потому что они они соучастники. Я коротенько скажу, я не боюсь сказать бизнесу, что будет, если они сделают так, как они именно хотят. А на что мне пришлось завести в борду риск IT-рисков и, ну, быть одним из инициаторов, чтобы она появилась. И там практически все риски, они от бизнеса приняты. Вот. И поэтому конкретно мой кейс. У других ребят в других сетапах, конечно, может быть по-другому, но так как governance не будет тут покрываться, то, ну, всё, я услышал ответ, спасибо. К сожалению, time to market — это та история, которая первое время работает на бизнес, потом начинает работать против бизнеса. И кажется, что архитектору прямо супер суперважно и необходимо эту концепцию очень понятными словами до бизнеса донести. Я прямо сейчас заплачу, как >> А давай, давай пойдём дальше.
Метрика из DORA, из DevOps, на самом деле. CFR, так называемый change failure rate — процент инноваций, то есть раскатки новых фич, приводящие к severity 1-2 инцидентам, hotfixам, отказам и так далее, то есть к серьёзным инцидентам в продакшене. А как мы можем вообще поработать как архитектор с этой историей? А опять-таки инициативы по контрактному тестированию, э, фитнес-функция, различные, там OP инструменты, Cool, всё, что можно в пайплайны встроить, э, чтобы избегать негатива в продакшене, внедрять патерны отказоустойчивости, маскировать проблемы, исключать отказы в обслуживании. И что интересно, контрметрика для этого — time to market. Вот. Потому что все усилия по сокращению ошибок, они будут влиять на Time to Market. И мастерство архитектора, ну, и не только архитектора, а всех причастных будет заключаться в том, чтобы всё это делать настолько, а, настолько просчитанно и аккуратно, чтобы никто не замечал никакого эффекта на time to market. А что ещё предлагаю рассмотреть? А, ну, собственно, метрика Time to Market. Мм, я не скажу, что она супер архитектурная, она скорее такая кумулятивная, да, то есть на time to market могут влиять эфорты многих людей и не только архитектора. От артефакта до продакшена, да, время, то есть включая разработку, тестирование, развёртывание и всё такое. Да, Алексей.
>> Артём, а можешь сразу подсветить вот для измерения time to market какие ты используешь утилиты, не знаю, или просто на коленках, как считаешь?
>> Как правило, для измерения time to market все пользуются встроенными метриками в трекеры задач, в Jira, например, и так далее. То есть, как только задача из одного статуса заходит, триггерится, заход в контрольный статус, начинается time to market. Вышла из какого-то статуса, остановили. Вот так. Ну, в моей практике все прям так считали.
>> Jira, понятно, это ты откуда снимаешь данные?
>> А я имел в виду телевизор, где ты показываешь их. В чём? Ну, в графике.
>> >> Всё, всё в Grafana. Всё в Grafana пихается.
>> >> А, в Grafana. Угу.
>> >> Да.
>> >> А дальше а от артефакта до продакшена. А как как архитектор э может э влиять? Да, к сожалению, влиять на это можно только введя какие-то э легковесные архитектурные операции вместо тяжёлых. Скорее всего будут страдать, э, будет страдать некоторое какое-то качество в процессах. Например, тот тот тот же самый governance придётся упрощать, да, быстрее доносить решение, упрощать решения, меньше контролировать, чтобы а время, которое тратит архитектор на Time to Market, вот этот вот кусочек его его вклад сокращалось. А то ещё использовать технологии в своих решениях, у которых там отличное кривое обучение, которую там, например, компании все прекрасно знают, которая там с минимальным фрикшеном внедряется и так далее. Упрощать, да, вот эти вот штуки, если есть выбор, э, выбирать что-то, что будет более понятно, проставлять проблем, использовать платформенное решение, либо там свою платформу собирать, либо там, а, например, поощрять cloud какие-то, э, миграции и так далее. Контрметрики для time to market. А, да, деградация SLO. Да. Аэ, посылок, я уже сказал, понимаю, тут в общем плане, а весь набор измеряемых нами SLI, безусловно, они, скорее всего, будут деградировать. Если к NFAм зачислить там нетайм атрибуты качества, такие как modifiability, то точно деградация неизбежна. А это значит, что мы создаём техдолг, по сути, если по-русски коротко сказать. Ну и CFR тот же самый может нам говорить о том, что в погоне за скоростью мы потеряли качество. Вот метрики в балансе смотрим.
Идём дальше. М, тоже метрика из DORA, если я правильно помню. А частота релизов, собственно, хорошо, когда часто релизим малые инкременты. Что для этого нужно делать? А нужно поработать CI/CD. А архитектор может повышать модульность, да, э, декомпозировать декомпозировать систему на маленькие кусочки, чтобы локализовать изменения в этих маленьких кусочках. А, но тут есть, э, триггер огромная опасность в координации изменений, которые будут выходить за рамки одного модуля. Начинаются истории классические с capture-темой, с pull request и так далее. В общем, любое дробление, оно возникает трение, вызывает трение в других местах. А снижение кросс-командных зависимостей, м да, один из способов увеличить частоту деплоев, не делать эти зависимости или, по крайней мере, делать так, чтобы они были легко координируемы. Те самые контрактные тесты, э, важный инструмент в распределённых системах. Какие могут быть контрметрики? Мм, всё тот же самый CFR, change failure rate. И, собственно, остальные контрметрики, ну, по крайней мере, которые я смог подобрать, они, а, смотрят на на то, была ли доставлена на самом деле ценность клиенту. Если мы начинаем релизить маленькие инкременты, то есть ли в них какой-то смысл? Вот если смысла нету, клиент ничем не пользуется, то как бы frequency, deployment frequency, метрика, считаю, похакалась. Сюда можно добавить нюансы и различные инструменты из процессных фреймворков, чтобы поискать ту самую ту самую ценность, да. А, но опять-таки это больше не про архитектора история тогда становится.
>> А, интересная метрика. Да, связанная с техдолгом, техпрейш, а, соотношение набранного, а, техдолга к погашенному техдолгу. Казалось бы, причём тут архитектор, а он тут как бы очень важный персонаж оказывается. А, хотя, если в этой формулировке техдолг заменить на архитектурный долг, всё тогда вообще классно срастётся. А так вот, что за дробь такая? А если эта дробь, э, выходит за единичку, становится больше единички, ну мы тогда растим долг, а меньше единички становится, мы техдолг отдаём. О, в Китае архитектурный долг, да? А как архитектор может работать с техдолгом, если коротко? С архитектурным долгом, э, история чуть-чуть другая будет, но, в принципе-то приоритизация работы, прозрачность, да, вот та самая история, как, ээ, делать бизнес с участниками создания техдолга, а потом это поможет вам выделить, э, капасити команды на устранение техдолга. Контрметрика. М, у Паши, я знаю, тут есть свой подход к вопросу техдолга. Он с моим немного не совпадает, а, но мы об этом говорим подробно на курсе про архитектуру. Контрметрики для техдолга, да, мм, та самая, то самое соотношение с продуктовой разработкой. Если вдруг ни с того ни с сего там 100% времени спринта дали на техдолг, ну, конечно, мы вот это вот метрику ratio, отношение мы его подправим. А, да. Но за счёт чего? За счёт того, что мы пропустили ни одной инновации.
А если это согласовано с бизнесом, хорошо. Если это хак метрики, ну такое, а нужно внимательно посмотреть на ситуацию. Похакать техдолг можно через незаметно для себя, ухудшив нефункциональные качества системы, либо замедлив time to market, да, когда мы вот начинаем, а, а, ну ладно, не буду, короче, тайм-маркет тоже нужно смотреть, когда работаем с техдолгом.
А так интересная история. Она больше не про измерения, а про то, что нужно найти баланс между лидирующими и так называемыми запаздывающими сигналами. А что такое лидирующие сигналы? Я уже подхожу к концу. А скоро Паше слово тебе отдам. Да. М. Лидирующие - это всё, что все архитектурные активности, инструменты, которые происходят до релиза продакшна, да? Это как он пишет документы, как он делает адары, как он коммуницирует. То, что оно автоматизирует в пайплайне развёртывание, это всё про это лидирующие сигналы, они происходят до релиза. Пайплайн упал, э, мы где-то что-то пропустили, значит, деплоить нельзя. Лидирующая метрика, ещё раз говорю, и потом опаздывающие метрики. То, что мы потом получаем уже в мониторинге, в обзервабилити, а через работу с инцидентами. В общем, всё, что выскакивает в продакшене.
И в чём суть баланса? В том, что всё, что лидирует, а оно должно оптимизировать то, что запаздывает, да? Если мы что-то мерим, но это на что-то ни на что не влияет, то и не надо это мерить. Смысл в этом и в этом-то и заключается встроенная контрметрика, что каждая сторона регулирует противоположную. Это больше история про баланс, наверное, а не про, а про то, как оценивать качество работы архитектора. Если архитектор про это задумывается, уже уже неплохо, да, неважно, что там с балансом, но если он с ним работает, уже уже как бы не зря. Вот.
А итого, да, уже к концу прямо так подбежали. Итого хорошо, когда снижается стоимость без деградации с дах обязательств даже перед самими собой, не говоря уже про SLO. И также хорошо, когда повышается качество через вот все эти инструменты, но и снижается скорость деливери. Вот если архитектор может балансировать между этими штуками, то я бы сказал, что он неплохо справляется со своей работой. И на этом моя часть официально а эта часть заканчивается. Сейчас мы быстренько пройдёмся по вопросикам и потом, Паш, тебе слово отдам. А вопросы у нас собрались, собрались вот такие вот.
Рука, Никита, >> мы не перешли к вопросам. Можно немножко от себя дополню. Я столкнулся ещё с такой вещью, как уровень зрелости компании, это влияет на те процессы, которые в ней происходят и вообще как не всё организовано. И вот про то, как у тебя здесь разложены методы, которые работают, ну, грубо говоря, там с незрелой компании, где нет никаких процессов, ситрица даст хороший буст и результат какой-то, а условно, не знаю, там вот наблюдение за ЦФРОм, ну, не сильно поможет, потому что до этого ещё далеко, до этого нужно дорасти. Ну, как не все инструменты на разном, все разные инструменты на разном уровне зрелости компании влияют по-разному. Да. Ты абсолютно ты абсолютно прав. Спасибо за за твоё важное замечание. А вот я вроде сказал, что это экстрамотивация, про которую мы поговорим позже. Ну о'кей. Да, спасибо.
Алексей, >> нет. Ну ладно. Мм, вопросы, которые поступили, э, >> а, сорри, я микрофон не включил. Э, хотел спросить по поводу метрик. Вот, допустим, ты измеряешь их, отображаешь, а результатом. Ну, как ты можешь влиять на эти метрики? Соответственно, задаёшь, ну, ты ставишь какие-то задачи, задачи должны выполняться. Что если бизнес, например, говорит, э, типа, извините, времени нету. Ну, то есть по сути получается, ты вроде бы измеряешь метрики, но влиять на на них можешь или не можешь, как в общем происходит на влияние на них?
>> А, ответ будет очень простой и быстрый. Значит, метрики, ээ, которые можно поправить через свои ежедневные рутинные операции. Архитектор вполне может поправить. Вот метрики, которые основаны на НФарах. А так или иначе с архитектором в компании неизбежно просто появится культура работы с нефункциональными требованиями. Это значит, что в каждой инициативе, в каждой задаче будут упоминаться НФары. А НФР - это неотъемлемое требование. Вот. И это требование будет согласовано с бизнесом, потому что архитектор объяснит бизнесу, почему важно это может быть важнее даже, чем функциональное требование. И оно, э, не менее важно к исполнению, чем функциональное. Его нужно будет проверить и протестировать. Поэтому вот огромная часть, которая связана с SLO, она автоматически в проекте появится и будет мониториться, контролироваться. Это будет часть требований. Бизнес не скажет типа, что нет, мы это не будем мерить, вы уже это меряете, вы уже сами это требуете. Это вот, да, искусство архитектора привить эту культуру бизнесу стейкхолдерам, работать с нефункциональными требованиями. Вот и всё. Бизнес не будет говорить нет. Ответ такой у меня. О'кей.
>> Да. Ээ я, может быть, ещё второй момент про техдолг. То, что ты говорил. Ээ есть техдолг, это понятно, но есть ещё архитектурный долг. Он закрывается ээ вообще больно и там либо синьорными ребятами. Ну то есть это как как выбить ресурс на вот закрытие вот этих задач? А ну опять-таки это а небольшое организационное в кавычках небольшое орг изменение, которое а в компании должно произойти. Это к продуктовому бэклогу должен добавиться некий технический, архитектурный, как хотите называйте бэклог. А вот и на этапе планирования работы эти бэклог должны мержиться. Архитектор, хороший архитектор, он сможет объяснить, почему техническая инициатива, а, важна к исполнению, почему она откроет путь, э, в какие-то бизнес-возможности без этой инициативы, типа бизнес что-то не получит. Вот умение продавать - это тоже один из скилов таких, которые нужно покачать. Вот. И поэтому, когда ты, э, нужные тебе истории по архитектурному долгу закладываешь там клинический roadmap, а вот, и на планировании всё это сливается с продуктовым, у тебя будут ресурсы. Вот если этого не происходит, а, ну, компания, видимо, ещё не готова, а, работать над качеством своего продукта. Вот. Хотя, если они уже пришли за архитектором, скорее всего, они уже пару раз в продакшене что-то отловили такое, что ощутимо потеряли денег. Это вот ещё один такой флажок. Ну, про него обычно сразу тебе не расскажут, что у нас там неделю типа там что-то лежало из-за маленького просчёта. Но если такие инциденты были, то шансы есть на такое довольно позитивную коммуникацию в этом направлении. Вот.
Да, давайте к вопросам вернёмся. Первая карточка. Измеримые параметры работы архитектора. А я про это рассказал. Ну, по крайней мере, дверь эту приоткрыл. А, да, Никита правильно подметил, что многие метрики будут актуальны с ростом культуры компании. Повышать видимость через метрики. Да, собственно. А следующий вопрос. Что начинает делать арх при вступлении новой работы? Типичные проблемы и решения. Ну вот, собственно, скорее всего, речь идёт будет идти про то, что нужно будет поработать вот с этими предпосылками, да? Понятно, что сама по себе архитектурная функция по принятию архитектурных решений будет за архитектором. Но вот это вот вот с этим придётся поработать и сделать это очень аккуратно, а чтобы не вызвать много негатива в свой адрес, чтобы не быть той новой метлой, которая в чужом монастыре взяла и всё подмела внезапно и встретилась с огромным уровнем э сопротивления. А дальше м что архитектору делать, когда он пришёл на проект, а там полная Ну везде. А вот, э, собственно, не паниковать системно начинать, э, работать и смотреть, потянешь, не потянешь. Не потянешь. Лучше сменить проект, чем обмануть чьи-то задания. Вот если ты знаешь, как решать проблемы, аэ, коммуницируй, а вот заручайся поддержкой людей, у которых есть власть, делай эти проблемы осязаемыми для них, чтобы они прониклись этой болью, связывая это с бизнес-драйверами. и похогрибайти по ним. А дальше вопрос по теме. А как понять, что архитектор сделал своё дело и может уходить? Ну кажется, что если в проекте не происходит никаких изменений, да, а то можно уходить. Фичи новые не делятся, продукт не развивается, никто не хочет сократить расходы, никто не хочет поработать с НФарами. Ну, можно, можно уходить. Вот так, наверное. Вот. Я, кстати, был в одном проекте, где был пул архитекторов, э, там не проект, там огромная корпорация с множеством продуктов была. И был общий пул архитекторов, и никто даже толком там не знал, как что работать, потому что никто ни за кем не был закреплён. И архитекторов выписывали из этого пула для точечного решения там проблем. То есть команда сама там с помощью техледа делала свою архитектуру, потом попадала в неприятную ситуацию. Чаще всего это были там проблемы там с перфомансом или с масштабированием. И тогда вызывали архитектора, который там за неделю, за две разбирался в нюансах, тушил пожар и уходил. И всех это устраивало. Вот, собственно, пришёл, ушёл по запросам. Такое тоже бывает.
Так. Видел в двух проектах DWH одинаковую ситуацию. Реализация в обоих согласовывалась через архитектуру. Архитектура становилась узким горлышком. Да. А есть есть вот эта вот история про то, что если прямо всё подряд тащить через архитектуру, да, архитектура она сложно масштабируется, а то это будет bottleneck, single point of failure, особенно когда архитектор один придёт. И поэтому всё через литературу тащить, наверное, смысла а не имеет. Ну а читаем дальше. Принималось решение не согласовывать реализацию с архитектурой, да? То есть э архитектура не успевала, эха решили делать сами без архитектуры. Хорошо. Архитекторы переставали понимать, как устроен текущий, но люди здесь не нужны. Как решать такую проблему? А в чём проблема-то? Ну, DWH, там, не знаю, кто там, лид, какой-то DWH преисполнился с архитектурной функцией, видимо, эффективно решает бизнес задачи. Архитектура не нужна. Молодец. Я вот как раз-таки на последнем наборе обратную ситуацию набирал, наблюдал, когда прямо всё зашло в тупик в какой-то момент и прямо очень требовалась архитектурная функция профессиональная. А или я не понял проблему. Вот. Ну, кажется, что всё хорошо. Избавились от bottleneck, быстро принимают решение. Молодцы.
>> Можно я чучуть прокомментирую? Конечно. >> Архитектуру узким горлышком. Я, ну, видел такое в больших компаниях, когда куча вещей техледов приносилась на согласование пяти архитекторам, которые по два месяца согласовывали, не могли согласовать и потом забили. И ситуация, ну, возможно, тот, кто задавал вопрос, имел в виду нечто подобное. И в результате архитектора отрывались настолько от того, что происходит. Это было в масштабах компаний, что они там вообще не знали или знали свою высшую часть. Техлидеры, инженеры делали что-то себе, и в результате всё вот так расползалось, как как желе. А вот, ну, ответ - это практики архитектурных процессов, это governance, это шаблоны и правила, по которым нужно делать архитектуру и поддержание высокоуровневой архитектуры. Как раз то, что будет Антон рассказывать на курсе. Но трагедия вот той компании, где я был, она была оказалась в том, что архитекторы вообще не знали, а вот подобных архитектурных подходах. И в результате вот каждый делал что-то о себе, фантазируя иногда о нефункциональных требованиях. >> Я закончил. Спасибо. Всё.
>> Да, Павел, спасибо. Вот ты напомнил про шаблоны. Да, очевидно же есть там референсные архитектуры, которые там очень часто могут довольно красиво закрыть много потребностей. Про это часто забывают. Да, Максим, у тебя рука.
>> Я хотел прокомментировать про это же историю, про DWH кейс. А мы у себя в компании, у нас там несколько архитекторов, а мы с бизнес-аналитиками, департаментами выработали, а поинты, при которых обязательно должны привлекаться архитекторы. говорит DWH не придёт просто разработчик и скажет: "Давайте построим DWH. Будет какая-то инициатива и, скорее всего, бизнес-инициатива. Нам нужна отчёта, нам нужен PowerBI, что-нибудь такое. И если по каким-то причинам проект идёт мимо нас, потому что мы действительно бутылочное горлышко и стоим недёшево, то мы предупреждаем и пробили это у бизнеса, что если бизнес начинает какой-то проект и вообще никак не привлекает нас, то должны быть чётко описаны все бизнес-требования с фарми и с НФАми для того, чтобы мы могли хотя бы потом наверстать, что ж там. И мы не несём ответственности за то, как сделает этот DWH. Если он долбанётся со всем набором данных и вся бизнес-аналитика встанет, то у нас типа, а мы не при делах, у нас лабки. Ну тут как бы никак, потому что если они такую дичь делают, то надо как бы себя защищать в первую очередь. Спасибо. Слушай, я сразу мне показалось, что я понимаю, о чём ты говоришь, а потом потом показалось, что ты говоришь о том, что вы как бы сняли с себя ответственность за последствия таких решений.
>> Мы продали когда включается, когда должно привлекаться архитекторы, и это запросили те. После они идут мимо архитекторов, они берут на себя ответственность за то, что этот бизнес-функционал ляжет. >> А, да, >> хорошо, хорошо. А на самом деле, а ты напомнил мне одну историю. Я не помню, как она так по-научному называется. что-то типа архитектурного гейтвея или фильтра, когда а можно создать некий чек-лист, а, да, в котором будет понятно, типа, есть ли в задаче признаки чего-то архитектурно важного с какими-то рисками. Если ты вот один из пунктов этого чек-листа своей задаче метил, то как бы нужно даблчекнуть, типа, будут ли у тебя потом проблемы или лучше сходить за пруфом где-то.
>> Да, вот мы так и сделали. Ну, интуитивно, но мы так и сделали. >> Да, хороший вариант. А, спасибо, Никита. Давай, давай твой крайний вопрос, потом вопрос на карточке и слово Паша, а то я уже давно ему обещал и никак не скажу слова.
>> Угу. Даё скайк первой ситуации, что, ну, решение понятно, почему понятно и что, ну, вот как это и закрыться от этого дела. Но всегда закрадывается вопрос, что если вы пришли к этому решению, его приняли, то где-то что-то потеряли, где-то что-то не доработали, потому что такого быть не должно. То есть если бизнес идёт в в обход архитектуры, то, ну, где-то недоработка с обоих сторон. Вот, давайте оставим эту тему, а то мы здесь потратим ещё часа два. А, да, может быть, DWH не поняли, как правильно использовать архитектора. Может быть, нужно было, ну, короче, можно придумать очень много чего, что будет оправдывать DWH или оправдывать архитектуру, но факт остаётся фактом. Бизнес, кажется, там страдает немножко в конечном счёте. И последний вопрос, который был задан, вопрос по обучению. Как это работа скилы на позицию арха? А если я в компании middle Plus, как понять, что я могу уже позиционировать себя как архитектор перед компанией или заказчиком? И Паш, можно я попрошу тебя ответить на этот вопрос? Как вообще там локомотив вопросов обучения у нас?
>> А, окей, хорошо. А если именно в ком, если я в компании Midleп, любой рост, это вообще не только в архитектуре и не только в IT, начинается с того, что человек берёт на себя больше скоупа ответственности. А то есть сначала э берёт там кулсон, делает его очень хорошо, так что на него все могут положиться, ему дают больше задач, скоуп ответственности растёт больше, больше, больше. В этом вот больше, больше, больше. А возникает дополнительные коммуникации, которые нужно хорошо делать, возникает проектирование уже каких-то больших кусков ранг приложения и возникает больше ответственности. В конце концов, человек становится полноценным сниором. Дальше должен происходить немножко, ну, тоже увеличение скоупа, но за счёт увеличения коммуникации. И здесь уже человек начинает отвечать за кусок, который сделан не полностью на 100% им вот своими руками, а им плюс ещё кто-то. Им плюс мидл, им плюс два мидла, им саним плюс там три синьора. И человек становится таким, он проектирует вот этот вот кусок, который реализует уже там два человека, три человека, больше. А, и вот это уже начало к тому, чтобы стать архитектором. Чтобы дорастить до такого уровня, как Антон, нужно сначала по познать техническую боль, а потом организационную. Познать техническую боль мира означает, что нужно получить очень широкий кругозор в тех решениях технических, которые существуют, и грамотно их поприменять. То есть, грубо говоря, научиться для начала нормально строить systemдизайн для более-менее порных систем. А в процессе этого роста тебя замечают, тебе начинают даваться более сложные задачи и внезапно оказывают, что ты проектируешь до всей команды, стал внепким тех, став инженером, как как бы это не называлось, ты растёшь дальше и внезапно ты проектируешь какие-то сложные фичи, которые вовлекают несколько команд. есть уже такой полноценный жёсткий стах-инженер, а, который, ну, обладает очень хорошо систем дизайном и техническим прозором и пониманием этого. И тут начинается погружение в организацию и в бизнес. И когда вот это вот а-а погружение происходит, собственно говоря, рождается solution архитектор. То есть от медла первый уровень растить свои разработческие, ну, границы, увеличивать их, потом познать кругозора технический, потом познать организационные всякие штуки и бизнесовые. И вот тогда получится сращивать технические знания с организационными потребностями. Тогда возникнут вопросы, которые вот Антон сегодня раскрывал. И, собственно, вот такой рост. В этом помогает в том числе и тот курс, который вот сейчас я буду презентовать, и другие курсы Hearts of Skills, куча книг, куча, ну, в общем, этому посвящено достаточно много материалов, потому что сложность этой истории большая. Это история на годы, я бы сказал, вот midle плюс, я думаю, достающий архитектора, ну, не меньше, чем, ну, лет пять. Это при такой жёстком, при жёстком развитии, при вот постоянном преодолении всего на свете. А вот такой мой ответ. Аа и сейчас я перехвачу у Антона аа презентацию. Так, где? Ладно, там хочу. Вот. И расскажу про курс по союной архитектуре, который ведёт как раз Антон. Антон это самое, как настоящий профессионал, достаточно скромный, поэтому курс презентую я, чтобы, а то Антон не дохвалит себя. А вот, значит, курс - это вторая ступенька а роста от синьора к солюшн архитектору. А эта ступенька больше посвящена вот той самой организационной боли, процессам организации, а-а, бизнесу, про который Антон сегодня очень много говорил. А мы начинаем курс с достаточно, ну, такой вот книжной информацией, что описано вот в красивых книгах, в в курсах классических по архитектуре. Бизнесорхитектура, stakeholder management, стейкхолдеры, вот та самая Россия матрикс, ещё там PowerT матрица и так далее, и так далее. Value стримы, само собой. Как? Что это такое вообще? Требования фары, фары, утилитит и и так далее. Это всё вот как описано в красивых книгах по архитектуре. Там архитектура интеграции, стратегия roadmap, примеры архитектуры, то есть блокприняты. После этого мы переходим к коммуникациям сю архитектора. Это то, что позволяет архитектору выживать, обосновывать свои решения, доказывать, что именно его решения нужны. Вот примеры Антон сегодня приводил, как убедить там бизнес, что нам нужны вот нам нужно отдать этот долг или там нам нужно там ещё что-то. Это и про управление ожиданиями, и про культуру, и про вот своё место и путь в организации, и доверие, и процесс, ну вот и приселы для серверных для сервисных компаний. Это вторая часть. Она ближе к реальности в книгах. Её описываю достаточно редко и сложным языком, потому что это очень некоторые вещи здесь весьма такие неполиткорректные. Вот потому что бывает всякое. Ещё одна вещь - это кейсы из а-а из нашего с Антоном опыта. А что бывает? Ну вот здесь вот интересное перечисление на проклятой роли. То есть, когда архитектор меняется там одним за одним, такое то, ну или или там Тимлик или ещё кто-то, такое тоже бывает, потому что оргструктура накопила к этой роли столько требований, часто противоречащих, что никто не может ээ это задача для целого отдела, а не для одного человека, например. и про некомпетентность архитектора, и про разработчиков, которые первые пришли вообще в проект 10 лет назад и до сих пор там работают, остаются на уровне такого нормального сеньора, и на их суждения влияют вообще там на все решения компании и и так далее. Как с этим быть, как это преодолевать? Что вообще бывает в мире? Это уже совсем не политкорректные вещи, которые, тем не менее очень хорошо отображают реальность. Вот, как Антон сегодня сказал, вот когда в архитектуре - это норма минимум в половине проекта. Вот ты приходишь на проект и вот вперёд. Вот. И, конечно, тренды в архитектуре, которые сейчас существуют, AI здесь тоже говорит своё слово, оно ещё слабее, чем в разработке, но тем времене его не учитывать нельзя, потому что за хайпом идут все ведутся на него. Вот. Ну и, конечная история всей всего этого курса - это как мне, как архитектору, развиваться в организации. А особенность курса, собственно, его название - это Solution Architect Change the Wild, архитектор в дикой природе. А есть красивая теория, которую мы тоже даём, но есть практика, которая, собственно, про жизнь. И важно то, как мы эту теорию приземляем в практику в конкретной организации. далее, чем сегодня. А у меня на консультации был технический директор, у которой жаловался на то, что коммуникации в организации происходят не менее чем в пяти разных мессенджерах. Аа значит и о какой-то унификации, стандартизации уже документации речь идти, к сожалению, не может. При этом это достаточно успешный бизнес. Но транзакционные издержки у них вот в таких ситуациях ему приходится там как-то выстраивать архитектурный процесс. Вот. А такое тоже бывает. Аа преподаватель Антон. Антона я сегодня уже представлял. Часть кейсов буду рассказывать я из моей богатой биографии. А вот а значит вот это лендинг. Ээ, ссылка на описание курса более подробное там с программой и и со всем остальным. А при регистрации до конца этой недели тем, кто зарегистрируется, скидочка 5%. Э вот, а, собственно говоря, э на этом я наше представление завершаю. А-а, я надеюсь, вам очень понравилось то, что вам рассказывал Антон. А-а, приходите к Антону на курс. Вот.
>> Да. Паш, тебе спасибо. Всем присутствующим, активным участникам отдельное спасибо. Да, было приятно. Да, на этой неделе мы будем делать с Антоном ещё одно мероприятие, посвящённое именно solution архитектуре, а про рост и развитие архитектора в среду на сайте HS of Skills в сообществе оно, в общем, объявлено. Пожалуйста, тоже приходите. Антон будет рассказывать интересные вещи. И Паша тоже.
>> И я, короче, вот. Всем спасибо большое. Хорошего всем вечера.