- "Я менеджер, а не разработчик, зачем мне лезть в такие технические дебри?" - "Ой, это архитектурный вопрос, у меня для этого есть сеньоры, пусть они разбираются"   В разное время ловил такое настроение при обсуждении архитектурных вопросов как у коллег TPM-ов, так и у себя лично. Но что меня всегда отрезвляло и возвращало внимание на такие вопросы, так это понимание, что архитектурные дела сильно влияют на продукт - как на его функциональные возможности и потенциал, так и на нефункциональные особенности - надежность, быстродействие, стоимость владения и т.д. И иногда пару хороших нетехнических вопросов к свежему RFC могут сильно повлиять на итоговое решение - "ой, а что это тоже важно клиентам?". Конечно, в супер зрелых командах все такие вещи берут на себя супер зрелые тимлиды, архитекторы и вот такие ребята, но в реальности граней может быть намного больше:) И я тут не говорю, что технический менеджер обязан быть архитектором - нет, это, как правило, отдельные люди с особым складом ума, большим опытом и глубокими техническими навыками. Но понимать базовые темы в архитектуре ПО считаю менеджеру необходимым еще и потому, что оно помогает в общении с инженерами. Когда они говорят про eventual consistency, паттерн "сага" или хореографию, а вы думаете причем тут танцы — это чувствуется. Команде приходится упрощать объяснения, переводить технические нюансы на "менеджерский язык". Именно в этот момент неизбежно где-то пропадут важные детали, которые в итоге могут серьезно повлиять на пользовательский опыт или стоимость разработки. Как техническому менеджеру прокачивать навык архитектуры? 0. Надо было раньше прокачивать, сейчас уже надо пользоваться 1. Пилить свои pet-проекты Мало что может заменить реальную практику построения систем. И если в рабочей обстановке есть жесткие ограничения, то написать свой микро-продукт, развернуть его и попытаться его запустить на пользователей - это доступно почти каждому. За это время вв гарантированно узнаете много нового не только с технической стороны, но и с продуктовой. Правда, я тут чуть лукавлю т.к. в pet-проектах обычно нет большой нагрузки, а именно она является главным катализатором сложных архитектурных решений. 2. Читать, смотреть, слушать Тут никакого инсайта - читать книжки ("кабанчика", например), смотреть выступления, сидеть с блокнотиком вечером и анализировать разные концепты. Конечно, сейчас все это можно значительно ускорить, если вы будете общаться с ChatGPT и подобными ребятами, но из-за их галлюцинаций есть риск того, что вас введут в заблуждение. Зато намного меньше рисков, если ходить на вебинары к опытным людям. Кстати, 18 ноября в 12:00 будет один такой - "Архитектурные стили и паттерны ПО" от компании ЛИИС (Лаборатория Интеллектуальных Инженерных Систем). Там расскажут: - Что такое Clean Architecture на практике, - Как выбрать свой архитектурный стиль (и не пожалеть об этом). - Монолит, модульный монолит, EDA, SOA, MSA Onion, Hexagonal, Pipes & Filters и чем они все отличаются, кроме названий из Википедии Подходит для техлидов, тимлидов, разработчиков и аналитиков, у которых болит от архитектуры — и тех, кто просто хочет понять, почему она вообще болит. Участие бесплатное, а зарегистрироваться можно по ссылке.