Стартуем стрим

Здарова, работяги!

В выходные было два стрима. Не часто я выхожу в таком формате, но мне понравился. Серьезно задумался о лайвкодинге в формате стримов. Выходной день, кофеек, чиловая музыка и пет-проект... Ммм... Красота! Что думаете, было бы вам интересно?

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

Еще перед зимними праздниками я писал о том, что решил пойти учиться тимлидству/менеджерству. Долго я выбирал, читал отзывы, сравнивал программы и спрашивал у своих знакомых, которые уже преисполнились в этой роли. После долгих выборов определился. Решил, что пойду на курс «Команда. Инструменты управления» от Стратоплана.

Уверен, что для многих тема выбора дальнейшего пути развития актуальна. Кто-то в итоге пойдет в ветку IC(individual contributor), а кто-то, как и я сейчас, попробует себя в роли тимлида. Поэтому я решил, что периодически буду делиться тем, что я узнал из курса, какими-то открытиями, тем, что мне нравится, что не нравится и т.д., и т.п.. Надеюсь, информация вам будет интересна и поможет в вашем развитии.

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

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

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

Всем продуктивной недели!

Всем привет!

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

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

Темы:
- DISC
- Работа с ожиданиями
- Модель PAEI
- Жизненый цикл компании и его связь с PAEI
- Психологическая безопасность в команде
- Доверие и прозрачность
- BHAG
- Обратная связь

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

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

На курсе практика устроена так. Все студенты поделены на группы по 6-7 человек. В начале каждого занятия(1ч) в группе распределяются роли:
- модератор - управляет дискуссией
- гейт-кипер - следит, чтобы в обсуждении не ушли не в ту сторону
- тайм-кипер - следит за временем, чтобы группа успела выполнить задание
- писарь(я его так называю) - ведет лог встречи

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

На час времени дается кейс. Что такое кейс? Ближайший аналог — задачки с собесов только для тимлидов и других менеджеров. Выглядит как описание некой проблемной ситуации и набор вопросов к ней.

Пример: вы стали тимлидом команды, где все поругались, а еще план не выполняется. Сотрудники выглядят так-то и так-то. Какие ваши первые шаги? Почему? Что нужно сделать, чтобы решить конфликты? Как успеть план?

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

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

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

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

Всем привет!

Закончился мой трехнедельный отпуск, пора возвращаться к делам. Уже совсем скоро стартует ШРИ 2025. И, конечно же, там будут лекции по реакту. И, конечно же, мы снова внесли в них много изменений. Первая, как обычно, будет базовой, а вот вторая и третья будут посвящены архитектуре приложения, в котором используется реакт.

Я в этом году сфокусирован именно на второй и третьей лекции. Хочется, чтобы лекция не была сферическим конем в вакууме, а действительно была полезной и решала боли реальных проектов. Поэтому хотел бы узнать у вас: какие вопросы в рамках темы «архитектура приложения с реактом» / «построение приложения с реактом» вас волнуют? Какие проблемы есть у вас в этой области?

Пишите в комменты к сообщению, а я постараюсь разобрать в лекции эти вопросы.

С датами самой лекции вернусь попозже)

Итоги второго модуля.
Всем привет!

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

Модуль называется «Тимлид и бизнес». Я бы его немного переименовал, чтобы лучше раскрыть вам суть этого модуля: «Конструктивное взаимодействие с командой и рук-лем». Это упрощенная формулировка, которая позволит нам сконцентрироваться на основных идеях.

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

Cовладельцы, СЕО — Стратегия

1. С помощью какой стратегии мы превратим инвестиции в прибыль?
2. Это на каком рынке и с помощью каких конкурентных преимуществ?
3. Как это позволит нам создать доходный и устойчивый в долгосроке бизнес?
4. Какие финансовые и другие показатели мы таким образом хотим достичь?

CTO, COO, CPO, СМО — С-level — Концепт. Верхнеуровнево.

1. Какой продукт/сервис мы для этого создадим и как будем доставлять
ценность-опыт клиенту? (верхнеуровнево)
2. Какая оргструктура, инфраструктура и специалисты нам для этого нужны?
3. Какие бизнес-процессы (верхнеуровнево) за какие деньги позволят нам
производить и доставлять клиенту ту ценность-опыт, которую мы хотим?

Рукли направления, рукля команд — Механика. Что именно и как мы делаем согласно концепта.

1. Как именно мы отстроим эти бизнес-процессы?
2. Как и что будут делать какие конкретно люди в какие моменты?
3. Какие планы найма сотрудников для этого?

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

Нужно ли это простому разработчику?

Если вы хотите расти, то точно да, т.к. разработчик — это не переводчик слов в код(с этим уже неплохо справляются инструменты разработки типа курсора и т.д.), а решать проблем, и чем лучше понимаете мотивы ваших «заказчиков» (обобщено), тем лучше вы сможете это сделать.

Если хотите еще глубже понять каждую роль, то советую вам почитать книгу «От разработчика до руководителя».

После того как мы разобрались с уровнями абстракции, давайте перейдем к конкретным практикам, которые вам помогут:

Конструктивная конфронтация. Штука полезная, для старта есть прям готовый алгоритм, который позволит вам начать практиковаться.

Принцип позитивного намерения. Супер принцип, понимание и применение которого позволяет вам не просто «собачиться» и «холиварить», а действительно конструктивно двигаться в разговоре. Ну и этот принцип отлично помогает экономить нервы. Я часто применяю его за рулем — а вдруг тот, кто вас подрезал, не злостный нарушитель, который хочет разбить вашу машину, а спешит в больницу? Может, не стоит на него злиться, а просто пропустить его, пусть спешит дальше.(без перегибов, конечно)

Принцип безоценочности. Это, пожалуй, самое сложное. Но стоит практиковаться.

Принцип аргументации через выгоды собеседника. Принцип до безумия прост, все про это знают, но в момент спора забывают.

Правило формирования устойчивой договоренности. В идеале по SMART.

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

(продолжение поста выше)
Как тренировать эти принципы?

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

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

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

Слои в клиентском приложении

‼️Идеального решения не существует. Руководствуйтесь здравым смыслом.

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

Начнем с вопроса «Зачем?»

🔹 1. Легче поддерживать код
Попробуйте сделать простое упражнение на вашем проекте — посчитайте количество задач на полностью новую функциональность и на доработки/развитие/"любое-другое-взаимодействие" с уже написанным кодом.
Предположу, что у большинства вторая группа будет больше. Деление на слои позволяет сделать поддержку сильно проще и сэкономит вам много нервных клеток.
- Если каждый слой отвечает только за свою задачу, менять что-то в бизнес-правилах, API или в UI можно независимо друг от друга.
- Меньше шансов «сломать что-то другое», когда вносятся доработки.

🔹 2. Проще тестировать
Тестируемость вашего кода — крайне важный критерий.
Чаще всего, если вам сложно тестировать код, то, скорее всего, вы где-то свернули не туда.
- Бизнес-логику можно тестировать отдельными юнит-тестами без запуска браузера и без реальных API.
- API-функции легко мокать, не мешая бизнес-функциям.
- UI можно тестировать отдельно, не беспокоясь о внутренней кухне данных.

🔹 3. Повышается переиспользуемость
Переиспользуемость кода — один из ключевых критериев хорошей архитектуры.
При верном разделении на слои вам будет проще переиспользовать ваши решения.
- Бизнес-логику можно легко переиспользовать: десктопный-веб, мобильный-веб, да даже другой проект.
- Более чистая логика проще адаптируется к изменениям, например, при смене API: в слое API меняются адреса/структуры, а бизнес-логика не трогается.

🔹 4. Уменьшается связанность компонентов
Тот самый coupling, о котором вы, скорее всего, услышите из любого рассказа про архитектуру.
Чем меньше связанность, тем проще поддерживать и изменять код, переиспользовать решения и т. д.
- Компоненты не знают, как именно приходят/сохраняются данные, они просто «получают props».
- Если меняется источник данных (например, из REST на GraphQL), UI не нужно переписывать вовсе.

🔹 5. Управляем сложностью
Многие концентрируются только на технической стороне вопроса, но объем когнитивной нагрузки на разработчика тоже очень важен.
Когда-то давно читал, что по когнитивной нагрузке разработчик ближе всего к нейрохирургу, так как оба работают с очень сложными системами.
А чем больше когнитивная нагрузка, тем быстрее вы устаете, повышается порог входа и т. д.
- Чем больше приложение, тем легче «потеряться» в взаимосвязях.
- Слои разбивают проект на удобные, изолированные части. Держать отдельную часть в голове проще, чем целый проект.
- Проще объяснить проект новичку: «здесь правила бизнеса, здесь — работа с API, здесь — хранилище, а вот UI». Следовать уменьшается проблема Bus Factor`а.

🔹 6. Облегчается командная разработка
Уверен, что все вы сталкивались с конфликтами при мердже, и у каждого был какой-то очень заковыристый конфликт, после которого, скорее всего, были багули и т. д.
Один, может быть, и воин, но не в разработке точно, поэтому крайне важно, чтобы над проектом УДОБНО И БЕЗОПАСНО МОГЛИ работать сразу несколько разработчиков.
Разделение на слои позволяет чаще взаимодействовать на уровне интерфейсов, а не реализаций, что позволяет реже конфликтовать с другими изменениями.
- Чёткое разделение зон ответственности.
- Комфортнее параллельная работа.
- Легче делать code review.
- Безопасность и независимость изменений.

🔹 7. Легче менять технологии
Никогда не говори никогда. Скорее всего, вы не часто меняете React на Vue и что-то подобное, но вот более маленькие библиотеки меняются чаще.
Уверен, что многие точно сталкивались с переходом с одного стейта-менеджера на другой и т. д. Деление на слои позволяет вам не переписывать весь проект при такой замене, а ограничиться только одним слоем (чаще всего).
- Хочется переписать UI на другую библиотеку — все бизнес-правила и API-клиенты уже вынесены и остаются прежними.

Конечно, это не все. Дальше обсудим подробнее.

Манипуляция vs. Вдохновение
#тимлидство

👋 Здарова, работяги!

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

Как и большинство вопросов в менеджменте, этот тоже многогранен и не имеет точного ответа 🤷‍♂️. И я бы мог ответить на него коротко:
«Руководствуйтесь здравым смыслом и ориентируйтесь по ситуации, а в идеале еще и не будьте мудаком» 😉

Но давайте все же постараемся добавить конкретики.

Когда я думаю над этим вопросом, вижу два пути, две дороги. И тут как в сказке — налево пойдёшь... Что же это за дороги?

1️⃣ Манипуляция
Уверен, что у большинства это слово ассоциируется с негативом. И вряд ли вы хотели бы, чтобы вами манипулировали. Но ведь нами манипулируют постоянно 💡

Яркий тому пример — реклама:
«Если вы не купите нашу пасту, то у вас будет кариес» 🦷

Да, это именно манипуляция. Если быть точнее, то манипуляция через страх 😨. И страх не единственный инструмент:

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

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

2️⃣ Вдохновение
Тут всё уже не так просто, как с манипуляцией. Здесь не получится просто напугать сотрудника дедлайнами, штрафами и увольнениями 🚫.

Тут нужно действовать иначе. Самое главное и самое основное, с чего вам стоит начать — вопрос «Зачем?» ❓

Тут уже нельзя просто сказать, ЧТО делать, придется объяснять. Скорее всего, это займет больше времени, больше сил. Зато именно так и рождается команда, которая готова следовать за лидом осознанно:

Отвечая на вопрос «Зачем?», вы:
✅ Собираете вокруг себя людей, которые разделяют ваше «Зачем?»
✅ Они следуют за вами добровольно 🤝
✅ Они чувствуют смысл, а не обязанность

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

На первый взгляд кажется, что:
- Манипуляция = зло 👿
- Вдохновение = добро 😇

Я с этим не согласен.

Иногда манипуляция уместна: например, если у вас форс-мажор, срочная таска или что-то подобное требующее максимальной мобилизации команды и выдачи быстрого результата. В таких случаях можно — и нужно — честно озвучить критичность, ограниченность сроков и сделать акцент на реальные последствия, если не успеем. Это манипуляция? Да. Можно ли “жить” на таком подходе всё время? По моему мнению, нет. Страх действительно мобилизует, но в долгую это плохой инструмент.

Это просто инструменты 🔧. Выбор инструмента зависит от многих факторов, как минимум от задачи, которую вы решаете.

Ну и давайте закончим тем, с чего начал:
«Руководствуйтесь здравым смыслом и ориентируйтесь по ситуации, а в идеале еще и не будьте мудаком» 😉

А как у вас — вы (или ваш лид) чаще используете манипуляцию или вдохновение? Делитесь в комментах 👇

🔥 Всем хорошего дня!

ШРИ 2025

Здарова, работяги!

Делюсь с вами записями своих лекций в ШРИ 2025, которые читал 17 и 18 июня:
1. Реакт. Построение приложения Ч1
2. Реакт. Построение приложения Ч2

Большая часть контента школ появляется в открытом доступе, найти инфу о лекциях можно в канале @Young_and_Yandex

Здарова, работяги!

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

Темы месяца:

1. Что такое команда? Чем отличается команда от просто коллектива.
2. Этапы развития команды (по Такману) и роль лидера на каждом этапе — что/где/как может делать руководитель, чтобы не тормозить прогресс, а сли нужно и ускорять его.
3. Пороки команды по Ленсиони — как их замечать и устранять.
4. Аудит команды: разобрали чёткий алгоритм, как оценивать состояние своей команды и находить точки роста.
5. Найм и увольнение: обсуждали, как нанимать имено тех, кто нужен команде/проекту и прощаться с сотрудниками бережно, честно и максимально корректно.
6. Конструктивная конфронтация «вниз»: как говорить с подчинёнными о сложных проблемах, чтобы не испортить отношения и при этом добиться результата.

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

Некоторые интересные идеи:

- Групповая динамика по Такману. Оказалось, мало знать про этапы развития команды — важно понимать, КАК вести себя лидеру во время каждого этапа. Например, в самом конфликтном этапе ("шторминг") нельзя затягивать конфликты или замалчивать их: задача лидера вскрыть все противоречия, найти решения и чётко зафиксировать договорённости. И очень важно — именно лидер должен стать гарантом выполнения этих договорённостей, контролировать процесс самому, не делегировать.

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

Что дальше?

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

Был ли у вас опыт увольнения сотрудника? Что для вас оказалось самым трудным и как вы справлялись со стрессом если испытывали его? Пишите в комменты 👇

Общаемся про прошедшие лекции, подключайтесь)

Очень часто говорю о том, что в первую очередь нужно вкладываться в базу и стараться быть инженером, а уже потом — разработчиком на React/Vue/чём-то-ещё. Вот выжимка хорошей статьи от "старины" Фаулера.

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

Expert Generalists

Статья в блоге Мартина Фаулера про T-shaped специалистов. Точнее, все текущие термины (T-shape, П-shape, и другие) плохо подходят, поэтому в статье вводится термин Expert-Generalist, который означает, что человек одновременно является и экспертом (в противовес generalist) и использует свою экспертизу во многих областях (в противовес эксперту в одной области).

В данном случае имеется в виду, что человек является экспертом в фундаментальных понятиях, которые позволяют ему быть успешным в областях, которые построены на этих понятиях. Классический пример из IT, это когда человек имеет опыт написания ПО на 3-4 языка программирования и ему после этого уже не так важно, на каком именно другом языке писать код, пока этот язык следует общим парадигмам (основан на том же фундаменте). Условно, человек, который писал на JS, PHP, JAVA, C++ с легкостью может войти в Go, Rust, Kotlin. Но, вероятно, столкнется с некоторыми проблемами при входе в Haskell. Но, скорее всего, сможет это сделать в короткие сроки.

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

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

В чем сила таких специалистов:

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

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

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

Ключевые качества экспертов-генералистов:
- Любознательность
- Умение сотрудничать
- Фокус на клиенте (бизнесовая направленность)
- Ставка на фундаментальные знания
- Широта знаний
- Способность понимать позицию смежных доменов (например, понимать проблемы SRE или DevOps)

Многие эксперты-генералисты вырастают в технических лидеров

Встает закономерны вопрос: "где брать таких специалистов?". Текущий найм устроен так, что мы скорее наймем ультра-эксперта в технологии, чем наймем человека, который любознателен и умеет погружаться в новые домены. В статье предлагается подход из двух решений:
- Перестать смотреть только на узкие хард-скилы. Вместо этого следует проверять человека на обучаемость, любознательность, создание условий для совместной работы
- Проводить внутренние тренинги и воркшопы, цель которых - погрузить специалистов в смежные области. В Thoughtworks есть 3 воркшопа, в которых специалисты делают решения из смежных областей. В рамках воркшопа они реализуют простые прототипы kafka, kubernetes, delta lake (штука для работы с данными). Создав прототип, люди начинают понимать базовые принципы, на которых основаны эти системы и начинают видеть рабочие ситуации с другой стороны

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

Для каждой ключевой компетенции в команде нужен 1-2 специалиста.

---

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



https://martinfowler.com/articles/expert-generalist.html

#managment #tshape #martinFowler

#тимлидство

Здарова, работяги!

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

Темы последних занятий:

1. GRPI — модель построения эффективной команды: как держать баланс между целями, ролями, процессами и человеческими отношениями.
2. Идеальный командный игрок (по Ленсиони) — почему одного “перформанса” мало и почему так важны сочетание скромности, голода до результата и социального интеллекта.
3. Управление вовлечённостью — как реально создавать среду, где людям хочется работать вместе и включаться на максимум, а не просто “отсиживать часы”.
4. Командная идентичность и ритуалы — что помогает почувствовать себя не просто “сотрудником”, а частью настоящей команды (символы, тотемы, ценности, традиции и даже свои ритуалы).
5. Модели Белбина и Адизеса — что такое роли в команде, зачем “мотиваторы”, “стратеги” и “артефакты”, и почему просто собрать сильных специалистов недостаточно.
6. Лидерство и стили управления — зачем лидеру быть не только “вождём”, но и хранителем командных ритуалов, и как каждый стиль влияет на динамику.
7. Работа c low/high performers — как справляться с теми, кто “тащит” процесс или наоборот "буксует", и почему важно замечать “слепые зоны” в команде.

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

Основные инсайты:

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

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

Ну и вопрос к вам: с чем из этого сталкивались в своей работе? Какие приёмы или фишки реально работали на практике, а что оказалось теорией? Пишите ваши истории и советы 👇

Роли по Белбину

В продолжение к прошлому посту.

Мне сильно понравилась идея модели Белбина и я решил подробне разобраться. Делюсь с вами презентацией, которую я подготовил. Пользуйтесь)

Режим агента

Здарова, работяги!

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

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

Где в кейсе стажера(джуна) может помочь ИИ?
1. Помощь в понимании чужого кода. Вы стараетесь самостоятельно разобраться в коде, с которым предстоит работать. После того как вы разобрались, тыкаете агент и сверяете то, как вы поняли, с тем, что выдает он. Таким образом вы как бы сможете обсудить то, как поняли вы, с виртуальным собеседником.

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

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

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

Когда написание кода c ии оправдано.
Мой кейс. Я уже какое-то время перебираю разные курсоры, рукоды и т. д. Сейчас на пет-проектах тестирую плагинчик Explyt от выходцев из Jetbrains, поэтому давайте рассмотрим кейс с ним.

Как я уже говорил ранее, я начинал с джавы и какое-то время работал именно бэкенд (позже уже фулстек) разработчиком. На протяжении всей карьеры я пишу разные пет-проекты и сам ими пользуюсь(апка для учета финансов и т. д.). Конечно, я писал для себя и бекенды на джаве. Сейчас я уже давно не джава-разработчик, поэтому язык я подзабываю, за всеми новинками не слежу. Следовательно поддерживать старые бекенды сложнее, желание лезть туда меньше.
Но! Есть агенты, например, такой режим есть в Explyt. Благодаря ему я могу рефачить, добавлять что-то новое в проект, какие-то тесты дописывать(да, даже в пет-проекте, т. к. мне нравится делать петы точно по книгам из идеального мира). Приятность этой тулзы еще и в том, что после месяца бесплатного триала ее можно оплатить ру-картой. Также, если у вас не пет-проект и всё строго с безопасностью, то у них есть решение для таких кейсов. Но советую начать с пет-проектов.

Почему в таком случае оправдано такое использование?
1. В таких кейсах у меня не стоит цель прокачать свои скилы в написании кода/проектировании/и т. д. (а для новичка это цель номер один на первые n месяцев), мне нужно быстро реализовать фичу.
2. Я знаю этот язык(подзабыл просто), знаю, как выглядит хороший оптимальный код, понимаю, какие решения я хочу видеть, понимаю, как бы я это реализовал. Поэтому я не апрувлю всё, что предлагает агент, а просто провожу ревью, где-то дописываю сам, подхватываю новые возможности языка и т. д. В итоге я быстро получаю то решение, которое мне нужно, без вспоминания и гуглежки.

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

#тимлидство

Здарова, работяги! 👋

Накопилось много материала по последнему интенсиву про продукт и инженерку, делюсь кратким обзором — что прошли и что утащил в рабочий арсенал. Как обычно, подробные разборы разложу по отдельным постам, когда покручу всё в проде и на грабли тоже наступлю.

Темы последних занятий📚:

1. Продакт vs инженерка: где конфликт и как его гасить ⚔️
- Скорость на рынок vs качество/техдолг
- Фичи vs масштабируемость/рефакторинг
- Квартальные KPI vs долгосрочная устойчивость

2. Lean/MVP и цикл Build–Measure–Learn 🚀
- Как проверять гипотезы быстро (видео-MVP, ручные процессы) и не закапываться в «полноценную разработку»

3. Метрики: общий язык для всех 📊
- North Star, продуктовые (DAU/MAU, Retention, NPS/CSAT), бизнес (ARR, LTV/CAC), инженерные (TTM, MTTR, Deploy Frequency)

4. Переводчик метрик 🔁
- Как превратить «p95 вырос на 300 мс» в «минус X $/день и −Y п.п. конверсии», чтобы нас понимали продакты и бизнес

5. Юнит-экономика 💸
- Как техрешения влияют на LTV/CAC и прибыльность «на единицу»: считать не «красиво», а «окупаемо»

6. OKR: совместные цели 🎯
- O — куда идём, KR — как поймём, что пришли. В одной связке бизнес+инженерия

7. Приоритизация без срачей 🧮
- MoSCoW для быстрой классификации и RICE для ранжирования внутри Must. Как учитывать ограничения инженерки в Impact/Confidence/Effort

8. Управление рисками и запуском 🛡️
- Фича-флаги, канареечные релизы, поэтапный раскат, SLO/SLA, go/no-go чек-листы и пороги отката

9. Scope creep: как жить 🧵
- Буфер 60-20-20, «Да, и…» вместо «Нет, потому что…», прототипы вместо мгновенных коммитов, явные trade-off’ы срок/объём/ресурсы

10. Инженерная операционка и продуктивность ⚙️
- DORA, SPACE, DX Core 4: что мерить, где утекает время (большие PR, ревью без SLA, долгие пайплайны, контекст-свитчинг) и как ускоряться

11. Технический долг: современная трактовка 🧰
- Долг — это всё, что замедляет доставку ценности, бьёт по метрикам или создаёт измеримые бизнес-риски. Не всё «техническое» надо чинить

12. Стейкхолдеры и отчётность 🤝
- Rhythm of Business: регулярные статусы, общие дашборды (бизнес+техника), прозрачные решения и эскалации

Основные мысли💡:
- Говорить в деньгах и пользовательском эффекте — универсальный ключ к приоритетам. «−2.3 с к p75 LCP = −7% конверсии = −$Х/день» работает лучше, чем «надо оптимизировать фронт».
- Совместные OKR выравнивают команды сильнее любых митов, кучи синков и прочего-прочего-прочего.
- RICE внутри Must экономит недели споров. Учитывать техограничения прямо в Impact/Confidence — честнее, чем «как-нибудь сделаем».
- Запуски без фича-флагов и порогов отката — лотерея. Канарейки и go/no-go спасают репутацию и нервы.
- Техдолг — не «стыд за некрасивый код», а денежные потери/риски. Чиним то, что бьёт по DORA/SLO/инцидентам и скорости поставки.
- «Нет» почти всегда звучит как «Да, и…»: делаем, и для этого сдвигаем X, урезаем Y, добавляем ресурсы Z, или идём через прототип/фазу пилота.

Также хочу отдельно остановиться на одной теме от которой у меня бомбит, сильно бомбит🤬:

Продакт дурак, ничего не понимает и ему важны только деньги, заставляет нас что-то делать и тд - оооочень часто слышу от знакомых разработчиков такое, скорее всего с его стороны вы выглядите аналогично - "кроме своего кода ничего не понимает, совсем не думает про то как мы будем дальше зарабатывать на весь этот техдолг и тд". Что с этим делать? Для начала хватит искать виноватого во всех бедах, а далее:
1. Учитесь общаться на одном языке и понимать мотивацию продакта(любого друго специалиста). Вы в первую очередь команда - дополняйте друг-друга, а не ругайтесь.
2. Метод «Грозовая туча». Полезная практика, впервые прочитал о нем у Элияху Голдрата.

Ну и к вам вопрос: где у вас чаще всего рвётся связка продукт↔инженерия — метрики, приоритизация, скоуп или релизы? Какие приёмы реально зашли (фича-флаги, RICE, OKR, Debt Day), а что осталось теорией? Делитесь кейсами и граблями 👇