❤6🔥3🙏2🍌1
Очень часто говорю о том, что в первую очередь нужно вкладываться в базу и стараться быть инженером, а уже потом — разработчиком на React/Vue/чём-то-ещё. Вот выжимка хорошей статьи от "старины" Фаулера.
!!!Важно!!! хорошая база не исключает специализацию в каких-то областях, а скорее помогает вам быстрее погружаться в эту область и растить там экспертность, если это требуется.
!!!Важно!!! хорошая база не исключает специализацию в каких-то областях, а скорее помогает вам быстрее погружаться в эту область и растить там экспертность, если это требуется.
🔥19❤2
Forwarded from Dev News от Максима Соснова
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
Статья в блоге Мартина Фаулера про 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
martinfowler.com
Expert Generalists
Being an Expert Generalist should be treated as a first-class skill, one that can be assessed and taught.
👍20🔥6❤3
ТОП - Тёма о программировани
Здарова, работяги! В выходные было два стрима. Не часто я выхожу в таком формате, но мне понравился. Серьезно задумался о лайвкодинге в формате стримов. Выходной день, кофеек, чиловая музыка и пет-проект... Ммм... Красота! Что думаете, было бы вам интересно?…
#тимлидство
Здарова, работяги!
Накопилось довольно много материала по прошлому модулю обучения, так что спешу традиционно поделиться кратким обзором — что интересного мы прошли за это время. Как обычно, подробный разбор каждой темы будет отдельными постами, когда разберусь в деталях и попробую всё на практике.
Темы последних занятий:
1. GRPI — модель построения эффективной команды: как держать баланс между целями, ролями, процессами и человеческими отношениями.
2. Идеальный командный игрок (по Ленсиони) — почему одного “перформанса” мало и почему так важны сочетание скромности, голода до результата и социального интеллекта.
3. Управление вовлечённостью — как реально создавать среду, где людям хочется работать вместе и включаться на максимум, а не просто “отсиживать часы”.
4. Командная идентичность и ритуалы — что помогает почувствовать себя не просто “сотрудником”, а частью настоящей команды (символы, тотемы, ценности, традиции и даже свои ритуалы).
5. Модели Белбина и Адизеса — что такое роли в команде, зачем “мотиваторы”, “стратеги” и “артефакты”, и почему просто собрать сильных специалистов недостаточно.
6. Лидерство и стили управления — зачем лидеру быть не только “вождём”, но и хранителем командных ритуалов, и как каждый стиль влияет на динамику.
7. Работа c low/high performers — как справляться с теми, кто “тащит” процесс или наоборот "буксует", и почему важно замечать “слепые зоны” в команде.
Материала очень много и разобраться сразу во всем сложно. Благо изучали мы его не только в теории, но и на практике: групповые задания, ролевые кейсы и куча обсуждений. Иногда решение кейса кажется элементарным — пока не услышишь, как по-другому на ту же ситуацию смотрят твои коллеги.
Основные инсайты:
- Даже если в команде много профи, без чётких ролей и честного обсуждения проблем всё буксует. А самое главное - лид не должен закрывать собой недостатки ролей, а осознано распределять роли среди членов команды, а также если требуется уходить в найм, если какие-то роли не получается покрыть в нужной степени.
Как обычно, подробнее по каждой из этих тем буду писать отдельными постами — как только опробую всё это в реальной жизни.
Ну и вопрос к вам: с чем из этого сталкивались в своей работе? Какие приёмы или фишки реально работали на практике, а что оказалось теорией? Пишите ваши истории и советы 👇
Здарова, работяги!
Накопилось довольно много материала по прошлому модулю обучения, так что спешу традиционно поделиться кратким обзором — что интересного мы прошли за это время. Как обычно, подробный разбор каждой темы будет отдельными постами, когда разберусь в деталях и попробую всё на практике.
Темы последних занятий:
1. GRPI — модель построения эффективной команды: как держать баланс между целями, ролями, процессами и человеческими отношениями.
2. Идеальный командный игрок (по Ленсиони) — почему одного “перформанса” мало и почему так важны сочетание скромности, голода до результата и социального интеллекта.
3. Управление вовлечённостью — как реально создавать среду, где людям хочется работать вместе и включаться на максимум, а не просто “отсиживать часы”.
4. Командная идентичность и ритуалы — что помогает почувствовать себя не просто “сотрудником”, а частью настоящей команды (символы, тотемы, ценности, традиции и даже свои ритуалы).
5. Модели Белбина и Адизеса — что такое роли в команде, зачем “мотиваторы”, “стратеги” и “артефакты”, и почему просто собрать сильных специалистов недостаточно.
6. Лидерство и стили управления — зачем лидеру быть не только “вождём”, но и хранителем командных ритуалов, и как каждый стиль влияет на динамику.
7. Работа c low/high performers — как справляться с теми, кто “тащит” процесс или наоборот "буксует", и почему важно замечать “слепые зоны” в команде.
Материала очень много и разобраться сразу во всем сложно. Благо изучали мы его не только в теории, но и на практике: групповые задания, ролевые кейсы и куча обсуждений. Иногда решение кейса кажется элементарным — пока не услышишь, как по-другому на ту же ситуацию смотрят твои коллеги.
Основные инсайты:
- Даже если в команде много профи, без чётких ролей и честного обсуждения проблем всё буксует. А самое главное - лид не должен закрывать собой недостатки ролей, а осознано распределять роли среди членов команды, а также если требуется уходить в найм, если какие-то роли не получается покрыть в нужной степени.
Как обычно, подробнее по каждой из этих тем буду писать отдельными постами — как только опробую всё это в реальной жизни.
Ну и вопрос к вам: с чем из этого сталкивались в своей работе? Какие приёмы или фишки реально работали на практике, а что оказалось теорией? Пишите ваши истории и советы 👇
🔥26👍16❤9
ТОП - Тёма о программировани
#тимлидство Здарова, работяги! Накопилось довольно много материала по прошлому модулю обучения, так что спешу традиционно поделиться кратким обзором — что интересного мы прошли за это время. Как обычно, подробный разбор каждой темы будет отдельными постами…
Роли Белбина PDF.pdf
9.4 MB
Роли по Белбину
В продолжение к прошлому посту.
Мне сильно понравилась идея модели Белбина и я решил подробне разобраться. Делюсь с вами презентацией, которую я подготовил. Пользуйтесь)
В продолжение к прошлому посту.
Мне сильно понравилась идея модели Белбина и я решил подробне разобраться. Делюсь с вами презентацией, которую я подготовил. Пользуйтесь)
🔥19
Режим агента
Здарова, работяги!
Думаю, что выпускать пост на тему необходимости использовать ИИ-тулзы в работе с кодом уже поздно, о чем и говорит опрос выше. Уже используют и те, кто признаются в этом, и те, кто нет)
Плохо ли это? Смотря как использовать. Давайте разберемся.
Вы стажер, только начинаете свой путь, у вас еще мало опыта и код вы пишете плохо.
Чтобы не выглядеть лоуперформером в глазах коллег, вы активно используете агенты для написания кода.
Хорошо ли это? Мое мнение — нет.
Для стажера я считаю крайне важно набираться опыта в написании кода, обязательно нужно сперва самостоятельно придумывать решения и расти в этом, в первую очередь самостоятельно пробовать себя в проектировании маленьких фич и набираться опыта.
Где в кейсе стажера(джуна) может помочь ИИ?
1. Помощь в понимании чужого кода. Вы стараетесь самостоятельно разобраться в коде, с которым предстоит работать. После того как вы разобрались, тыкаете агент и сверяете то, как вы поняли, с тем, что выдает он. Таким образом вы как бы сможете обсудить то, как поняли вы, с виртуальным собеседником.
2. Помощь в придумывании/проектировании решения. Вы сами придумываете решение, описываете его понятным языком(это очень полезный навык). Заранее предусматриваете в нем обработку корнер-кейсов и т. д. После чего скармливаете его в иишку. В таком варианте вы опять же сможете как бы обсудить свое решение, попробовать его почеленджить.
3. Помощь в реализации решения. После написания решения вы можете попросить агента пошатать то, что вы написали, поискать проблемы, неоптимальности и т. д. В идеале попросите объяснить, почему он предлагает те или иные улучшения. После обсуждения поправьте их самостоятельно.
Думаю, смысл вы поняли. Сперва сам, а ИИ помогает вам получать больше опыта, учиться эффективнее. Я уже вижу как ускоряется рост стажеров и джунов, которые используют такой подход.
Когда написание кода c ии оправдано.
Мой кейс. Я уже какое-то время перебираю разные курсоры, рукоды и т. д. Сейчас на пет-проектах тестирую плагинчик Explyt от выходцев из Jetbrains, поэтому давайте рассмотрим кейс с ним.
Как я уже говорил ранее, я начинал с джавы и какое-то время работал именно бэкенд (позже уже фулстек) разработчиком. На протяжении всей карьеры я пишу разные пет-проекты и сам ими пользуюсь(апка для учета финансов и т. д.). Конечно, я писал для себя и бекенды на джаве. Сейчас я уже давно не джава-разработчик, поэтому язык я подзабываю, за всеми новинками не слежу. Следовательно поддерживать старые бекенды сложнее, желание лезть туда меньше.
Но! Есть агенты, например, такой режим есть в Explyt. Благодаря ему я могу рефачить, добавлять что-то новое в проект, какие-то тесты дописывать(да, даже в пет-проекте, т. к. мне нравится делать петы точно по книгам из идеального мира). Приятность этой тулзы еще и в том, что после месяца бесплатного триала ее можно оплатить ру-картой. Также, если у вас не пет-проект и всё строго с безопасностью, то у них есть решение для таких кейсов. Но советую начать с пет-проектов.
Почему в таком случае оправдано такое использование?
1. В таких кейсах у меня не стоит цель прокачать свои скилы в написании кода/проектировании/и т. д. (а для новичка это цель номер один на первые n месяцев), мне нужно быстро реализовать фичу.
2. Я знаю этот язык(подзабыл просто), знаю, как выглядит хороший оптимальный код, понимаю, какие решения я хочу видеть, понимаю, как бы я это реализовал. Поэтому я не апрувлю всё, что предлагает агент, а просто провожу ревью, где-то дописываю сам, подхватываю новые возможности языка и т. д. В итоге я быстро получаю то решение, которое мне нужно, без вспоминания и гуглежки.
Резюмируя, не стоит бояться новых технологий, используйте их себе на пользу, усиливайте ими свои скилы, свои умственные способности, ускоряйте обучение и т. д. Но! Не нужно ограничиваться себя инструментами и становиться их заложниками.
Здарова, работяги!
Думаю, что выпускать пост на тему необходимости использовать ИИ-тулзы в работе с кодом уже поздно, о чем и говорит опрос выше. Уже используют и те, кто признаются в этом, и те, кто нет)
Плохо ли это? Смотря как использовать. Давайте разберемся.
Вы стажер, только начинаете свой путь, у вас еще мало опыта и код вы пишете плохо.
Чтобы не выглядеть лоуперформером в глазах коллег, вы активно используете агенты для написания кода.
Хорошо ли это? Мое мнение — нет.
Для стажера я считаю крайне важно набираться опыта в написании кода, обязательно нужно сперва самостоятельно придумывать решения и расти в этом, в первую очередь самостоятельно пробовать себя в проектировании маленьких фич и набираться опыта.
Где в кейсе стажера(джуна) может помочь ИИ?
1. Помощь в понимании чужого кода. Вы стараетесь самостоятельно разобраться в коде, с которым предстоит работать. После того как вы разобрались, тыкаете агент и сверяете то, как вы поняли, с тем, что выдает он. Таким образом вы как бы сможете обсудить то, как поняли вы, с виртуальным собеседником.
2. Помощь в придумывании/проектировании решения. Вы сами придумываете решение, описываете его понятным языком(это очень полезный навык). Заранее предусматриваете в нем обработку корнер-кейсов и т. д. После чего скармливаете его в иишку. В таком варианте вы опять же сможете как бы обсудить свое решение, попробовать его почеленджить.
3. Помощь в реализации решения. После написания решения вы можете попросить агента пошатать то, что вы написали, поискать проблемы, неоптимальности и т. д. В идеале попросите объяснить, почему он предлагает те или иные улучшения. После обсуждения поправьте их самостоятельно.
Думаю, смысл вы поняли. Сперва сам, а ИИ помогает вам получать больше опыта, учиться эффективнее. Я уже вижу как ускоряется рост стажеров и джунов, которые используют такой подход.
Когда написание кода c ии оправдано.
Мой кейс. Я уже какое-то время перебираю разные курсоры, рукоды и т. д. Сейчас на пет-проектах тестирую плагинчик Explyt от выходцев из Jetbrains, поэтому давайте рассмотрим кейс с ним.
Как я уже говорил ранее, я начинал с джавы и какое-то время работал именно бэкенд (позже уже фулстек) разработчиком. На протяжении всей карьеры я пишу разные пет-проекты и сам ими пользуюсь(апка для учета финансов и т. д.). Конечно, я писал для себя и бекенды на джаве. Сейчас я уже давно не джава-разработчик, поэтому язык я подзабываю, за всеми новинками не слежу. Следовательно поддерживать старые бекенды сложнее, желание лезть туда меньше.
Но! Есть агенты, например, такой режим есть в Explyt. Благодаря ему я могу рефачить, добавлять что-то новое в проект, какие-то тесты дописывать(да, даже в пет-проекте, т. к. мне нравится делать петы точно по книгам из идеального мира). Приятность этой тулзы еще и в том, что после месяца бесплатного триала ее можно оплатить ру-картой. Также, если у вас не пет-проект и всё строго с безопасностью, то у них есть решение для таких кейсов. Но советую начать с пет-проектов.
Почему в таком случае оправдано такое использование?
1. В таких кейсах у меня не стоит цель прокачать свои скилы в написании кода/проектировании/и т. д. (а для новичка это цель номер один на первые n месяцев), мне нужно быстро реализовать фичу.
2. Я знаю этот язык(подзабыл просто), знаю, как выглядит хороший оптимальный код, понимаю, какие решения я хочу видеть, понимаю, как бы я это реализовал. Поэтому я не апрувлю всё, что предлагает агент, а просто провожу ревью, где-то дописываю сам, подхватываю новые возможности языка и т. д. В итоге я быстро получаю то решение, которое мне нужно, без вспоминания и гуглежки.
Резюмируя, не стоит бояться новых технологий, используйте их себе на пользу, усиливайте ими свои скилы, свои умственные способности, ускоряйте обучение и т. д. Но! Не нужно ограничиваться себя инструментами и становиться их заложниками.
explyt.ai
Explyt — your intelligent AI teammate for coding, testing, debugging
Your teammate for coding, testing, and debugging.
5🔥41👍13❤7💯4👏3😎1
#тимлидство
Здарова, работяги! 👋
Накопилось много материала по последнему интенсиву про продукт и инженерку, делюсь кратким обзором — что прошли и что утащил в рабочий арсенал. Как обычно, подробные разборы разложу по отдельным постам, когда покручу всё в проде и на грабли тоже наступлю.
Темы последних занятий📚:
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), а что осталось теорией? Делитесь кейсами и граблями 👇
Здарова, работяги! 👋
Накопилось много материала по последнему интенсиву про продукт и инженерку, делюсь кратким обзором — что прошли и что утащил в рабочий арсенал. Как обычно, подробные разборы разложу по отдельным постам, когда покручу всё в проде и на грабли тоже наступлю.
Темы последних занятий📚:
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), а что осталось теорией? Делитесь кейсами и граблями 👇
Школа менеджмента STRATOPLAN
Стратоплан - Команда. Инструменты управления
Практическая онлайн-программа обучения тимлидов и руководителей команд
🔥22❤16👍15
Нужен ли System Design фронтендеру?
Anonymous Poll
85%
Да, поэтому пили посты 👨💻
15%
Нет, мне и фронтового зоопарка хватает 😱
Здарово, работяги! 💪
В прошлом посте я начал разговор про System Design, давайте продолжим.
Представим ситуацию. Солнечный денёк, ветер за окном треплет листья деревьев... 🍃☀️ Вы сидите, себе работаете, попиваете кофеёк ☕️... У вас интересные задачки... Вы можете сконцентрироваться на работе... Представили? Тогда идём дальше. Сидите, работаете, никого не трогаете...
И тут вам прилетает сообщение, сообщение от коллеги из саппорта 😈... В письме он говорит, что у них за час/день/другой промежуток времени накопилось большое количество обращений от пользователей, которые жалуются, что не могут использовать какую‑то функциональность вашего приложения. Вы начинаете судорожно вспоминать, когда был последний релиз, и понимаете, что совсем не 5 минут назад... И тут вашу концентрацию, великолепный настрой и всё хорошее просто сметает к чёртям, заменяя холодным потом и кучей тревог 😰, да ещё и кофе перестал быть вкусным, а приобрёл вкус страданий — если ещё не пили такой, то попробуйте, считаю его самым бодрящим.
Знакома ли вам такая ситуация? Мне — да. И, к сожалению, в моей памяти количество таких эпизодов не равно одному... Бррр, как вспомню — аж передёргивает...
Что же делать, чтобы в такой ситуации не оказаться? Писать хороший код, скажете вы. Хорошее решение!) Конечно, нужно стараться, но ошибки действительно случаются, случаются баги и т. д. И в таких ситуациях самое главное — скорость детекта проблемы и скорость восстановления ⏱️.
Сегодня начнём с первого — скорость детекта. И главным решением тут является хорошо настроенная система мониторинга, которая позволит вам узнавать о проблемах не когда количество обращений пользователей стало критичным и ваша компания стремительно теряет деньги, а намного раньше.
Если вы никогда не сталкивались с таким, то у вас, скорее всего, возникнет вопрос: с чего начать? Что мониторить? ❓
Вариантов большое количество, но совершенно точно я предложил бы начать именно с ошибок. Таким образом вы сможете понять следующее:
- Вы сможете увидеть текущий фон - какие ошибки уже возникают у ваших пользователей и выстроить процесс постепенного снижения фона;
- Отслеживать появление новых ошибок.
- Отслеживать тренды — рост и падение 📈📉. Важно! Падение тоже очень важно, т. к. неожиданное падение может тоже быть сигналом о проблеме.
Также не забывайте, что для разбора важно логировать информацию не только о названии ошибки, но и контекст - версия/релиз, окружение, браузер/ОС, stacktrace и другую подобную информацию, которая позволит вам быстрее разобраться с ошибкой и ускорит время восстановления.
Следующим шагом может стать настройка алёртов(автоматическое оповещение, при возникновении определеныых условий) — они позволят вам узнавать о проблемах быстро и не сидеть, гипнотизируя графики, весь день.🚨 Реакцию на них добавьте в рутину вашего дежурного (On call)
Для организации мониторинга ошибок есть множество решений. Скорее всего вы слышали про Sentry, Raygun, Bugsnag и прочее. Но вы, может быть, уже заметили, что я в последнее время часто пишу про открытые отечественные решения, т. к. у многих из вас могут быть проблемы с использованием зарубежных решений. Тут тоже задался вопросом, а что такого на рынке есть, и нашёл — Хоук. Потыкал его какое‑то время на своих пет‑проектах и могу вам его посоветовать.
Основные фичи(критичные для меня):
- Реалтайм мониторинг ошибок
- Возможность логировать не только название ошибки, но и контекс - stack trace, релиз, коммит, окружение и тд
- Алерты
- Поддержка Source Maps
- Настройка доступов
- Open source SDK(полезно посмотреть как устроен инструмент, котрый вы используете)
Также, как я и говорил выше, ПО отечественное, поэтому:
- Серверы в РФ, а для многих это сейчас критично;
- Можно оплачивать RU‑картой (для меня это супер‑критерий, т. к. я очень не люблю всю бумажную, банковскую волокиту). 💳
Резюмируя: мониторинг — это маст‑хэв. Начинайте с мониторинга ошибок, следите за трендами ошибок, настройте алерты и выстраивайте процесс постепенного уменьшения уровня ошибок. Ну и ссылочка на Хоук — хороший кандидат для старта.
В прошлом посте я начал разговор про System Design, давайте продолжим.
Представим ситуацию. Солнечный денёк, ветер за окном треплет листья деревьев... 🍃☀️ Вы сидите, себе работаете, попиваете кофеёк ☕️... У вас интересные задачки... Вы можете сконцентрироваться на работе... Представили? Тогда идём дальше. Сидите, работаете, никого не трогаете...
И тут вам прилетает сообщение, сообщение от коллеги из саппорта 😈... В письме он говорит, что у них за час/день/другой промежуток времени накопилось большое количество обращений от пользователей, которые жалуются, что не могут использовать какую‑то функциональность вашего приложения. Вы начинаете судорожно вспоминать, когда был последний релиз, и понимаете, что совсем не 5 минут назад... И тут вашу концентрацию, великолепный настрой и всё хорошее просто сметает к чёртям, заменяя холодным потом и кучей тревог 😰, да ещё и кофе перестал быть вкусным, а приобрёл вкус страданий — если ещё не пили такой, то попробуйте, считаю его самым бодрящим.
Знакома ли вам такая ситуация? Мне — да. И, к сожалению, в моей памяти количество таких эпизодов не равно одному... Бррр, как вспомню — аж передёргивает...
Что же делать, чтобы в такой ситуации не оказаться? Писать хороший код, скажете вы. Хорошее решение!) Конечно, нужно стараться, но ошибки действительно случаются, случаются баги и т. д. И в таких ситуациях самое главное — скорость детекта проблемы и скорость восстановления ⏱️.
Сегодня начнём с первого — скорость детекта. И главным решением тут является хорошо настроенная система мониторинга, которая позволит вам узнавать о проблемах не когда количество обращений пользователей стало критичным и ваша компания стремительно теряет деньги, а намного раньше.
Если вы никогда не сталкивались с таким, то у вас, скорее всего, возникнет вопрос: с чего начать? Что мониторить? ❓
Вариантов большое количество, но совершенно точно я предложил бы начать именно с ошибок. Таким образом вы сможете понять следующее:
- Вы сможете увидеть текущий фон - какие ошибки уже возникают у ваших пользователей и выстроить процесс постепенного снижения фона;
- Отслеживать появление новых ошибок.
- Отслеживать тренды — рост и падение 📈📉. Важно! Падение тоже очень важно, т. к. неожиданное падение может тоже быть сигналом о проблеме.
Также не забывайте, что для разбора важно логировать информацию не только о названии ошибки, но и контекст - версия/релиз, окружение, браузер/ОС, stacktrace и другую подобную информацию, которая позволит вам быстрее разобраться с ошибкой и ускорит время восстановления.
Следующим шагом может стать настройка алёртов(автоматическое оповещение, при возникновении определеныых условий) — они позволят вам узнавать о проблемах быстро и не сидеть, гипнотизируя графики, весь день.🚨 Реакцию на них добавьте в рутину вашего дежурного (On call)
Для организации мониторинга ошибок есть множество решений. Скорее всего вы слышали про Sentry, Raygun, Bugsnag и прочее. Но вы, может быть, уже заметили, что я в последнее время часто пишу про открытые отечественные решения, т. к. у многих из вас могут быть проблемы с использованием зарубежных решений. Тут тоже задался вопросом, а что такого на рынке есть, и нашёл — Хоук. Потыкал его какое‑то время на своих пет‑проектах и могу вам его посоветовать.
Основные фичи(критичные для меня):
- Реалтайм мониторинг ошибок
- Возможность логировать не только название ошибки, но и контекс - stack trace, релиз, коммит, окружение и тд
- Алерты
- Поддержка Source Maps
- Настройка доступов
- Open source SDK(полезно посмотреть как устроен инструмент, котрый вы используете)
Также, как я и говорил выше, ПО отечественное, поэтому:
- Серверы в РФ, а для многих это сейчас критично;
- Можно оплачивать RU‑картой (для меня это супер‑критерий, т. к. я очень не люблю всю бумажную, банковскую волокиту). 💳
Резюмируя: мониторинг — это маст‑хэв. Начинайте с мониторинга ошибок, следите за трендами ошибок, настройте алерты и выстраивайте процесс постепенного уменьшения уровня ошибок. Ну и ссылочка на Хоук — хороший кандидат для старта.
hawk-tracker.ru
Хоук — российский трекер ошибок
Мониторинг ошибок в ПО с серверами в России и открытым исходным кодом
🔥16👍10❤6🤡5💯2✍1🏆1
Здарова, работяги!
Я уже достаточно давно подписан на Никиту и со многими его постами согласен - например с этим.
Плюсом к посту хотел с вами поделиться небольшой подборкой книг по прокачке таких навыков:
Критическое мышление. Анализируй, сомневайся, формируй свое мнение. Том Чатфилд
Думай как математик: Как решать любые задачи быстрее и эффективнее. Барбара Оакли
Думай медленно… Решай быстро. Даниэль Канеман
Джедайские техники и Путь джедая. Максим Дорофеев
Эссенциализм. Путь к простоте. МакКеон Грег
Программист-прагматик. Путь от подмастерья к мастеру. Томас Дэвид, Хант Эндрю
Атомные привычки. Джеймс Клир
Я уже достаточно давно подписан на Никиту и со многими его постами согласен - например с этим.
Плюсом к посту хотел с вами поделиться небольшой подборкой книг по прокачке таких навыков:
Критическое мышление. Анализируй, сомневайся, формируй свое мнение. Том Чатфилд
Думай как математик: Как решать любые задачи быстрее и эффективнее. Барбара Оакли
Думай медленно… Решай быстро. Даниэль Канеман
Джедайские техники и Путь джедая. Максим Дорофеев
Эссенциализм. Путь к простоте. МакКеон Грег
Программист-прагматик. Путь от подмастерья к мастеру. Томас Дэвид, Хант Эндрю
Атомные привычки. Джеймс Клир
🔥19
Forwarded from Никита Ульшин про IT (Nikita Ulshin)
Навык, который ускоряет прокачку любых других
Как много в нашей работе всего интересного, что хочется изучить и разобрать! Практически любой инженер является счастливым автором бэклога «штук, которые неплохо бы потыкать» и «штук, про которые неплохо бы почитать». Штук этих обычно гораздо больше, чем свободного времени. Поэтому бэклоги испытывают back pressure – набиваются быстрее, чем опустошаются.
Своё драгоценное время всегда хочется вложить максимально выгодно, получив как можно бОльшую отдачу на затраченные усилия. К счастью, для этого есть отличное направление – метанавыки.
⭐️ Что такое метанавыки
Метанавыки – это универсальные, широкие навыки, которые позволяют затем проще и быстрее осваивать более узкие, точечные умения. Их особенность заключается в переносимости между сферами жизни – один метанавык зачастую можно применять во множестве разных контекстов.
Примерами таких навыков являются умение учиться, критический анализ, осознанность, переговоры, умение решать сложные задачи, системное мышление и многие другие.
⭐️ За что хвататься?
Метанавыки круты тем, что при их изучении сразу же открываются огромные возможности для применения. Возьмём, к примеру, тему когнитивных искажений: в жизни полно ситуаций, где знание искажений и умение их обходить может принести огромную пользу (я лично постоянно замечаю confirmation bias и стараюсь ему не поддаваться).
Метанавыки настолько интересны, что мне лично хочется изучать их все, сразу и побольше. Но проблема ограниченных времени и сил никуда не делась, поэтому выбирать всё же приходится.
Один метанавык я искренне считаю королём всех метанавыков. И этот метанавык – умение учиться.
⭐️ Не знаешь, чему учиться? Учись учиться.
Грустный факт: выходя из образовательной системы, мы в среднем не умеем учиться. Мало кому из нас на жизненном пути попадались хорошие преподаватели, которые учили бы разбираться в проблеме и докапываться до истины, а не просто зазубривать информацию. Поэтому большинство из нас после учёбы умеют запоминать информацию, но не умеют её нормально анализировать и применять.
Само по себе слово «научиться» имеет глубокий и сложный контекст. Что вообще значит «учиться»? Как понять, что я чему-то научился (особенно если это не физический навык, а какая-то более тонкая материя)? Готовых ответов на эти вопросы у меня нет.
Я уже довольно долго занимаюсь разными изысканиями в области прикладного самообразования для жизни. Проще говоря, учусь учиться так, чтобы это влияло на мою жизнь, а не просто развивало эрудицию и позволяло жонглировать словами (я даже серию постов по теме написал). Но одно я могу сказать точно: несмотря на все трудности и неудачи, я не жалею ни об одной секунде, потраченной на то, чтобы учиться лучше.
Умение учиться открывает дорогу к более быстрому и качественному самообразованию в любой другой области. В том числе оно позволяет осваивать другие интересные метанавыки (которые, в свою очередь, могут прокачивать процесс обучения).
// А какие метанавыки вы считаете самыми важными?
Как много в нашей работе всего интересного, что хочется изучить и разобрать! Практически любой инженер является счастливым автором бэклога «штук, которые неплохо бы потыкать» и «штук, про которые неплохо бы почитать». Штук этих обычно гораздо больше, чем свободного времени. Поэтому бэклоги испытывают back pressure – набиваются быстрее, чем опустошаются.
Своё драгоценное время всегда хочется вложить максимально выгодно, получив как можно бОльшую отдачу на затраченные усилия. К счастью, для этого есть отличное направление – метанавыки.
Метанавыки – это универсальные, широкие навыки, которые позволяют затем проще и быстрее осваивать более узкие, точечные умения. Их особенность заключается в переносимости между сферами жизни – один метанавык зачастую можно применять во множестве разных контекстов.
Примерами таких навыков являются умение учиться, критический анализ, осознанность, переговоры, умение решать сложные задачи, системное мышление и многие другие.
Метанавыки круты тем, что при их изучении сразу же открываются огромные возможности для применения. Возьмём, к примеру, тему когнитивных искажений: в жизни полно ситуаций, где знание искажений и умение их обходить может принести огромную пользу (я лично постоянно замечаю confirmation bias и стараюсь ему не поддаваться).
Метанавыки настолько интересны, что мне лично хочется изучать их все, сразу и побольше. Но проблема ограниченных времени и сил никуда не делась, поэтому выбирать всё же приходится.
Один метанавык я искренне считаю королём всех метанавыков. И этот метанавык – умение учиться.
Грустный факт: выходя из образовательной системы, мы в среднем не умеем учиться. Мало кому из нас на жизненном пути попадались хорошие преподаватели, которые учили бы разбираться в проблеме и докапываться до истины, а не просто зазубривать информацию. Поэтому большинство из нас после учёбы умеют запоминать информацию, но не умеют её нормально анализировать и применять.
Само по себе слово «научиться» имеет глубокий и сложный контекст. Что вообще значит «учиться»? Как понять, что я чему-то научился (особенно если это не физический навык, а какая-то более тонкая материя)? Готовых ответов на эти вопросы у меня нет.
Я уже довольно долго занимаюсь разными изысканиями в области прикладного самообразования для жизни. Проще говоря, учусь учиться так, чтобы это влияло на мою жизнь, а не просто развивало эрудицию и позволяло жонглировать словами (я даже серию постов по теме написал). Но одно я могу сказать точно: несмотря на все трудности и неудачи, я не жалею ни об одной секунде, потраченной на то, чтобы учиться лучше.
Умение учиться открывает дорогу к более быстрому и качественному самообразованию в любой другой области. В том числе оно позволяет осваивать другие интересные метанавыки (которые, в свою очередь, могут прокачивать процесс обучения).
// А какие метанавыки вы считаете самыми важными?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12❤3💊3👏2💩1
Когда-то давно я запускал подобную голосовалку, прошло уже много времени.
Интересно, как поменялись ваши интересы за это время. Сейчас налаживаю канал, и это сильно поможет мне приоритезировать идеи и делать действительно полезный для вас контент.
Интересно, как поменялись ваши интересы за это время. Сейчас налаживаю канал, и это сильно поможет мне приоритезировать идеи и делать действительно полезный для вас контент.
Anonymous Poll
62%
60%
76%
🏛 Архитектура и проектирование
30%
23%
29%
1%
Cohesion и Coupling 🧩🔗
Здарова, работяги!
Если очень коротко: хорошая архитектура — это высокая связность внутри модулей (cohesion) и низкая связанность между ними (coupling). Эти два термина отлично объясняют, почему код либо живёт годами, либо рассыпается от каждого чиха.
В оригинале различить их достаточно просто, но вот в переводе… связанность и связность… Если у вас есть дефекты речи или вы просто устали к концу дня, то готовьтесь к сумбуру. Поэтому я обычно использую другой перевод:
— Cohesion — Связность
— Coupling — Сцепленность
Связность (Cohesion) 🧲
— Насколько сильно и «по делу» связаны части внутри модуля/компонента.
— Высокая связность = модуль делает одну понятную вещь.
— Сигнал проблемы: описываете модуль через «и-и-и» — «карточка товара грузит, форматирует цену, читает локаль и отправляет аналитику».
Сцепленность (Coupling) 🔗
— Насколько сильно модуль зависит от других.
— Низкая сцепленность = модуль знает только минимально необходимое о внешнем мире.
— Сигнал проблемы: изменение структуры store/API ломает полприложения.
Пример 🍿
Плохо: низкая связность + высокая сцепленность
— Компонент делает всё: загрузка, форматирование, аналитика, работа со storage, UI.
— Жёсткая привязка к fetch, analytics, localStorage, Intl и структуре product.
— Любое внешнее изменение тянет правки сюда.
Хорошо: высокая связность + низкая сцепленность
— ProductCard оркестрирует UI конкретной карточки (высокая связность).
— Зависимости приходят снаружи: api, formatPrice, currency (низкая сцепленность).
— Легко подменять реализации.
Опасные виды сцепленности на фронте 🛑
— Компонент знает «внутренности» ответа бэкенда и лезет в deeply.nested.a.b.c.
— Временная: функция/эффект B должна вызываться строго после функции/эффекта A (завязка на порядок эффектов).
— Прямое использование window, document, localStorage прямо в компоненте.
— Зависимость от окружения: компонент «знает», что он в проде/тесте.
Как снижать coupling и повышать cohesion 🛠
— Интерфейсы и адаптеры: компоненту нужен api.getById, а не fetch/axios.
— DI через props/context: прокидывайте зависимости сверху.
— Разделяйте UI и данные: View без побочек, отдельные сервисы для данных и бизнес-логики.
— Избегайте «utils.ts на 1000 строк»: маленькие тематические модули (price/strings/date).
Здарова, работяги!
Если очень коротко: хорошая архитектура — это высокая связность внутри модулей (cohesion) и низкая связанность между ними (coupling). Эти два термина отлично объясняют, почему код либо живёт годами, либо рассыпается от каждого чиха.
В оригинале различить их достаточно просто, но вот в переводе… связанность и связность… Если у вас есть дефекты речи или вы просто устали к концу дня, то готовьтесь к сумбуру. Поэтому я обычно использую другой перевод:
— Cohesion — Связность
— Coupling — Сцепленность
Связность (Cohesion) 🧲
— Насколько сильно и «по делу» связаны части внутри модуля/компонента.
— Высокая связность = модуль делает одну понятную вещь.
— Сигнал проблемы: описываете модуль через «и-и-и» — «карточка товара грузит, форматирует цену, читает локаль и отправляет аналитику».
Сцепленность (Coupling) 🔗
— Насколько сильно модуль зависит от других.
— Низкая сцепленность = модуль знает только минимально необходимое о внешнем мире.
— Сигнал проблемы: изменение структуры store/API ломает полприложения.
Пример 🍿
Плохо: низкая связность + высокая сцепленность
function ProductCard({ id }: { id: string }) {
const [product, setProduct] = React.useState<any>(null);
React.useEffect(() => {
fetch(`/api/products/${id}`)
.then(r => r.json())
.then(setProduct);
window.analytics.track('view_product', { id });
}, [id]);
if (!product) return <>Loading...</>;
const currency = localStorage.getItem('currency') || 'USD';
const priceText = new Intl.NumberFormat('en', { style: 'currency', currency })
.format(product.price);
return (
<div>
<img src={product.image} />
<div>{product.name}</div>
<div>{priceText}</div>
</div>
);
}
— Компонент делает всё: загрузка, форматирование, аналитика, работа со storage, UI.
— Жёсткая привязка к fetch, analytics, localStorage, Intl и структуре product.
— Любое внешнее изменение тянет правки сюда.
Хорошо: высокая связность + низкая сцепленность
type Product = { id: string; name: string; image: string; price: number };
type ProductApi = { getById(id: string): Promise<Product> };
type CurrencyFormatter = (currency: string, amount: number) => string;
function ProductCardView({ product, priceText }: { product: Product; priceText: string }) {
return (
<div>
<img src={product.image} />
<div>{product.name}</div>
<div>{priceText}</div>
</div>
);
}
type Props = {
id: string; api: ProductApi; currency: string; formatPrice: CurrencyFormatter;
}
function ProductCard({ id, api, currency, formatPrice }: Props) {
const product = useProduct(id, api);
if (!product) return <>Loading...</>;
const priceText = formatPrice(currency, product.price);
return <ProductCardView product={product} priceText={priceText} />;
}
— ProductCard оркестрирует UI конкретной карточки (высокая связность).
— Зависимости приходят снаружи: api, formatPrice, currency (низкая сцепленность).
— Легко подменять реализации.
Опасные виды сцепленности на фронте 🛑
— Компонент знает «внутренности» ответа бэкенда и лезет в deeply.nested.a.b.c.
— Временная: функция/эффект B должна вызываться строго после функции/эффекта A (завязка на порядок эффектов).
— Прямое использование window, document, localStorage прямо в компоненте.
— Зависимость от окружения: компонент «знает», что он в проде/тесте.
Как снижать coupling и повышать cohesion 🛠
— Интерфейсы и адаптеры: компоненту нужен api.getById, а не fetch/axios.
— DI через props/context: прокидывайте зависимости сверху.
— Разделяйте UI и данные: View без побочек, отдельные сервисы для данных и бизнес-логики.
— Избегайте «utils.ts на 1000 строк»: маленькие тематические модули (price/strings/date).
🔥32❤17❤🔥2👍2
...продолжение
Как понять, что связность низкая? 🔍
— Трудно назвать модуль одним коротким предложением.
— Слишком много зависимостей «на всякий случай».
— Тесты громоздкие: чтобы проверить одну вещь — поднимаете полприложения.
Как понять, что сцепленность высокая? ⚠️
— Изменение структуры ответа API ломает десяток компонентов.
— Нельзя протестировать без реального network/localStorage.
— Переезд на другую библиотеку (http, стейт) требует массовых правок.
Мне очень нравится идея Ларри Константина: «Попытка разбиения на части модуля, обладающего связностью, приведёт лишь к увеличению степени связанности кода и снизит его удобочитаемость».
Итого 🧾
— Высокая связность = модуль делает одну вещь и делает её хорошо.
— Низкая сцепленность = модуль знает минимум о внешнем мире и легко заменяет зависимости.
Хорошое решение для снижения coupling - Dependency Injection. Интересно ли вам почитать про DI?
Как понять, что связность низкая? 🔍
— Трудно назвать модуль одним коротким предложением.
— Слишком много зависимостей «на всякий случай».
— Тесты громоздкие: чтобы проверить одну вещь — поднимаете полприложения.
Как понять, что сцепленность высокая? ⚠️
— Изменение структуры ответа API ломает десяток компонентов.
— Нельзя протестировать без реального network/localStorage.
— Переезд на другую библиотеку (http, стейт) требует массовых правок.
Мне очень нравится идея Ларри Константина: «Попытка разбиения на части модуля, обладающего связностью, приведёт лишь к увеличению степени связанности кода и снизит его удобочитаемость».
Итого 🧾
— Высокая связность = модуль делает одну вещь и делает её хорошо.
— Низкая сцепленность = модуль знает минимум о внешнем мире и легко заменяет зависимости.
Хорошое решение для снижения coupling - Dependency Injection. Интересно ли вам почитать про DI?
❤35🔥26👍17🤯2
Зачем разработчику комьюнити, если есть книги и YouTube? 🧠🤝
Когда я начинал, думал: все знания — из книг, статей и, в крайнем случае, с YouTube. На старте это правда: базу, язык, фундамент и метанавыки удобнее всего качать именно так - много проверенной информации, которую ты можешь быстро достать.
Но у этого пути есть предел — актуальность. Для фундаментальных вещей книги — мой топ-1. А вот для новых технологий, библиотек, подходов и каких-то «затычек» в решениях, исследованиях лучший источник оказался другой — общение с людьми. Комьюнити, митапы, конференции, кулуарные разговоры после докладов. Самые яркие инсайты за последний год-два я получал именно там.
Плюсы комьюнити:
— Актуальные практики «как делают сейчас», а не год назад - книги пишутся не один день
— Контекст решений: почему сработало и какие компромиссы приняли - часто в статьях упускают важные для вашего кейса детали
— Быструю обратную связь и проверку гипотез
— Контакты, которые помогают с карьерой и проектами - сейчас всё чаще слышу про этот плюс
Может показаться, что чтобы начать погружаться в сообщество необходимо покупать дорогущий билет на крутую конфу (тоже хороший вариант, там еще и доклады интересные😏), но начать можно с ваших локальных сообществ, митапов, либо с формата, который организуют ребята из mindbox — Frontend Speed Dating.
7 октября ребята проводят вечер коротких онлайн-знакомств для фронтенд разработчиков - формат позволяет найти единомышленников, которые решают такие же проблемы, как и вы, познакомиться и после уже продолжить общаться, обсуждать решения и делиться опытом.
📅 Когда: 7 октября
⏰ Во сколько: 19:00–20:30 по мск
📍 Где: Zoom (ссылку пришлём после регистрации)
Зарегистрироваться
Когда я начинал, думал: все знания — из книг, статей и, в крайнем случае, с YouTube. На старте это правда: базу, язык, фундамент и метанавыки удобнее всего качать именно так - много проверенной информации, которую ты можешь быстро достать.
Но у этого пути есть предел — актуальность. Для фундаментальных вещей книги — мой топ-1. А вот для новых технологий, библиотек, подходов и каких-то «затычек» в решениях, исследованиях лучший источник оказался другой — общение с людьми. Комьюнити, митапы, конференции, кулуарные разговоры после докладов. Самые яркие инсайты за последний год-два я получал именно там.
Плюсы комьюнити:
— Актуальные практики «как делают сейчас», а не год назад - книги пишутся не один день
— Контекст решений: почему сработало и какие компромиссы приняли - часто в статьях упускают важные для вашего кейса детали
— Быструю обратную связь и проверку гипотез
— Контакты, которые помогают с карьерой и проектами - сейчас всё чаще слышу про этот плюс
Может показаться, что чтобы начать погружаться в сообщество необходимо покупать дорогущий билет на крутую конфу (тоже хороший вариант, там еще и доклады интересные😏), но начать можно с ваших локальных сообществ, митапов, либо с формата, который организуют ребята из mindbox — Frontend Speed Dating.
7 октября ребята проводят вечер коротких онлайн-знакомств для фронтенд разработчиков - формат позволяет найти единомышленников, которые решают такие же проблемы, как и вы, познакомиться и после уже продолжить общаться, обсуждать решения и делиться опытом.
📅 Когда: 7 октября
⏰ Во сколько: 19:00–20:30 по мск
📍 Где: Zoom (ссылку пришлём после регистрации)
Зарегистрироваться
👍9✍5❤2👀2
Здарова, работяги!
Помню как еще в свой первый год работы в Яндексе учавствовал в создании задач для Yandex Cup. Очень рад, что соревнование не просто продолжает проводиться, а с каждом годом становится все масштабнее и масштабнее. В этом году пройдет уже восьмой международный чемпионат по программированию
Общий призовой фонд в этом году составит 12 миллионов рублей!
Этапы Yandex Cup 2025:
• 20-29 октября — пробный тур для знакомства с платформой и задачами
• 2 ноября — квалификация, где будут определены 180 финалистов
• 5-7 декабря — финал и церемония награждения в Стамбуле
Призы в направлении Фронтенд:
1 место — 500 000 ₽
2 место — 400 000 ₽
3 место — 300 000 ₽
4 место — 200 000 ₽
5 место — 100 000 ₽
Лучшие участники направления смогут по упрощенной схеме пройти собес в компанию и получить офер
Регистрация открыта до 29 октября: тык👈
Помню как еще в свой первый год работы в Яндексе учавствовал в создании задач для Yandex Cup. Очень рад, что соревнование не просто продолжает проводиться, а с каждом годом становится все масштабнее и масштабнее. В этом году пройдет уже восьмой международный чемпионат по программированию
Общий призовой фонд в этом году составит 12 миллионов рублей!
Этапы Yandex Cup 2025:
• 20-29 октября — пробный тур для знакомства с платформой и задачами
• 2 ноября — квалификация, где будут определены 180 финалистов
• 5-7 декабря — финал и церемония награждения в Стамбуле
Призы в направлении Фронтенд:
1 место — 500 000 ₽
2 место — 400 000 ₽
3 место — 300 000 ₽
4 место — 200 000 ₽
5 место — 100 000 ₽
Лучшие участники направления смогут по упрощенной схеме пройти собес в компанию и получить офер
Регистрация открыта до 29 октября: тык👈
Yandex Cup — чемпионат по программированию
Попробуйте свои силы в решении нестандартных задач
👍14🔥3
<Activity></Activity>
Здарова, работяги!
Наконец-то я добрался до докладов с React Conf 2025.
Писать про React Foundation и т. д. я не буду, тк не гадалка. Поживем увидим, к чему это приведет. А вот с фичами давайте разберемся.
Начнем с компонента Activity.
В чем его суть: позволяет скрывать и восстанавливать кусочек интерфейса (компонент со всеми его дочерними), сохраняя внутреннее состояние и «останавливая» срабатывание эффектов, предварительно вызвав cleanup.
Что это нам даёт?
Возможность скрывать элементы без потери состояния — самый базовый кейс. Актуально для вкладок, сайдбаров и подобного. Доклад, да и док, пестрит подобными примерами. Суть в том, что в отличие от условного рендеринга стейт при таком скрытии сбрасываться не будет, поэтому при повторном показе пользователь сможет продолжить с того места, где он остановился.
Возможность заранее рендерить кусочек интерфейса — уже более интересный кейс. Если компонент Activity скрыт во время первоначальной отрисовки, его дочерние элементы не будут видны на странице. Но! Самое важное! Они всё равно будут рендериться. У меня было тут два основных опасения: влияние на перф и фоновые эффекты. Но эти моменты продумали: приоритет рендеринга у таких элементов ниже, чем у видимых, а эффекты в них не будут срабатывать.
Сегментация для выборочной гидрации — пожалуй, самое интересное. Selective Hydration позволяет сократить ожидание интерактивности интерфейса — пользователь может быстрее жать на нужные кнопочки. Раньше для разделения дерева на независимые части вы, скорее всего, использовали Suspense, но его использование только для селективной гидрации будет порождать моргания плейсхолдера. Activity лишен этого косяка, но также позволяет выделить независимые части, гидрацию которых можно либо отложить, либо ускорить.
Но! Есть и подводные камни.
Всё, что вы не очистили в cleanup (таймер, интервал, видос, аудио, iframe и т. д., и т. п.) после скрытия может продолжать жить «в фоне» — ждите проблем. Так, например, интервал, обновляющий локальный стейт, продолжит это делать и в скрытом состоянии, а после показа элемента вы увидите последствия его скрытой работы, т. к. стейт при скрытии/показе не сбрасывается.
Может возникнуть вопрос: «А почему не использовать для скрытия css???»
Жизненный цикл и эффекты
- CSS: компонент остаётся смонтирован, эффекты продолжают работать.
- Activity: перед скрытием выполняется cleanup; эффекты «спят», пока поддерево скрыто.
Рендер/перформанс
- CSS: скрытая часть конкурирует за ресурсы как обычно; планировщик React это не учитывает.
- Activity: скрытому поддереву назначается низкий приоритет; можно безопасно пререндерить его в фоне, не мешая видимому UI.
Гидрация/SSR
- CSS: не даёт границы для выборочной гидрации — гидрируется всё как обычно.
- Activity: формирует сегменты для Selective Hydration — можно откладывать/ускорять гидрацию скрытых частей.
Итого: штука интересная, кейсов применения много, посмотрим, как будет использоваться.
Здарова, работяги!
Наконец-то я добрался до докладов с React Conf 2025.
Писать про React Foundation и т. д. я не буду, тк не гадалка. Поживем увидим, к чему это приведет. А вот с фичами давайте разберемся.
Начнем с компонента Activity.
В чем его суть: позволяет скрывать и восстанавливать кусочек интерфейса (компонент со всеми его дочерними), сохраняя внутреннее состояние и «останавливая» срабатывание эффектов, предварительно вызвав cleanup.
Что это нам даёт?
Возможность скрывать элементы без потери состояния — самый базовый кейс. Актуально для вкладок, сайдбаров и подобного. Доклад, да и док, пестрит подобными примерами. Суть в том, что в отличие от условного рендеринга стейт при таком скрытии сбрасываться не будет, поэтому при повторном показе пользователь сможет продолжить с того места, где он остановился.
Возможность заранее рендерить кусочек интерфейса — уже более интересный кейс. Если компонент Activity скрыт во время первоначальной отрисовки, его дочерние элементы не будут видны на странице. Но! Самое важное! Они всё равно будут рендериться. У меня было тут два основных опасения: влияние на перф и фоновые эффекты. Но эти моменты продумали: приоритет рендеринга у таких элементов ниже, чем у видимых, а эффекты в них не будут срабатывать.
Сегментация для выборочной гидрации — пожалуй, самое интересное. Selective Hydration позволяет сократить ожидание интерактивности интерфейса — пользователь может быстрее жать на нужные кнопочки. Раньше для разделения дерева на независимые части вы, скорее всего, использовали Suspense, но его использование только для селективной гидрации будет порождать моргания плейсхолдера. Activity лишен этого косяка, но также позволяет выделить независимые части, гидрацию которых можно либо отложить, либо ускорить.
Но! Есть и подводные камни.
Всё, что вы не очистили в cleanup (таймер, интервал, видос, аудио, iframe и т. д., и т. п.) после скрытия может продолжать жить «в фоне» — ждите проблем. Так, например, интервал, обновляющий локальный стейт, продолжит это делать и в скрытом состоянии, а после показа элемента вы увидите последствия его скрытой работы, т. к. стейт при скрытии/показе не сбрасывается.
Может возникнуть вопрос: «А почему не использовать для скрытия css???»
Жизненный цикл и эффекты
- CSS: компонент остаётся смонтирован, эффекты продолжают работать.
- Activity: перед скрытием выполняется cleanup; эффекты «спят», пока поддерево скрыто.
Рендер/перформанс
- CSS: скрытая часть конкурирует за ресурсы как обычно; планировщик React это не учитывает.
- Activity: скрытому поддереву назначается низкий приоритет; можно безопасно пререндерить его в фоне, не мешая видимому UI.
Гидрация/SSR
- CSS: не даёт границы для выборочной гидрации — гидрируется всё как обычно.
- Activity: формирует сегменты для Selective Hydration — можно откладывать/ускорять гидрацию скрытых частей.
Итого: штука интересная, кейсов применения много, посмотрим, как будет использоваться.
1🔥25❤13👍7👏3
На секциях решаем задачи, которые не встречаются в работе!!!
Здарова, работяги!
Я частенько тут пишу про базовые навыки, SD и т. д. Также периодически публикую вакансии в свои/смежные команды. Не редко под этими постами возникают дискуссии о корректности секций, о важности проверки базы, задачках на алгоритмы и т. д., и т. п. И мои посты в тг не единственное место, где разворачиваются такие обсуждения — они есть и в других каналах, статьях, чатах и т. д., везде, где хоть как-то затрагиваются собесы.
Ииии я к вам с анонсом на эту тему😏
В Яндексе обновляется процесс найма разработчиков.
Основные изменения:
Единый процесс для всех 90+ сервисов - теперь мы нанимаем «профессию в Яндекс», а не в конкретный сервис. Процесс найма в разные сервисы будет одинаковый.
Результаты секций действуют два года - результаты успешного прохождения технических секций действуют два года. Если кандидат их успешно прошёл в одном сервисе Яндекса, но на финале не случился мэтч с конкретной командой, при последующих рассмотрениях на похожую роль в любом из 90+ сервисов кандидату зачтут предыдущее прохождение секций и предложат только финалы с руководителями.
Повышаем прозрачность - теперь большинство кандидатов уже на старте процесса будут знать максимальное количество и содержание предстоящих этапов. А уже совсем скоро запустится личный кабинет для кандидатов, в котором можно будет видеть всю необходимую информацию и управлять процессом: на каком этапе собеседований кандидат находится, как прошёл предыдущие секции, какие предстоят секции и как к ним подготовиться, возможность самостоятельно выбирать удобные слоты под секции, выбирать вакансии. До выхода кабинета часть его функциональности будет доступна в боте.
Всесторонняя оценка компетенций - к задачам на базовые навыки добавятся задачи на специфические знания конкретного стека и языков программирования, а «дубли» секций на алгоритмы пропадут из процесса. Большинство задач будет приближено к реальным рабочим.
Зачем я принес этот анонс?
Очень просто - для многих собесы в Яндекс были какой-то страшилкой, блокером и т.д., и эти изменения могут развеять их страх, и они наконец решатся подать резюме и получат работу, о которой мечтали. Буду рад увидеться в офисе👨💻
Здарова, работяги!
Я частенько тут пишу про базовые навыки, SD и т. д. Также периодически публикую вакансии в свои/смежные команды. Не редко под этими постами возникают дискуссии о корректности секций, о важности проверки базы, задачках на алгоритмы и т. д., и т. п. И мои посты в тг не единственное место, где разворачиваются такие обсуждения — они есть и в других каналах, статьях, чатах и т. д., везде, где хоть как-то затрагиваются собесы.
Ииии я к вам с анонсом на эту тему😏
В Яндексе обновляется процесс найма разработчиков.
Основные изменения:
Единый процесс для всех 90+ сервисов - теперь мы нанимаем «профессию в Яндекс», а не в конкретный сервис. Процесс найма в разные сервисы будет одинаковый.
Результаты секций действуют два года - результаты успешного прохождения технических секций действуют два года. Если кандидат их успешно прошёл в одном сервисе Яндекса, но на финале не случился мэтч с конкретной командой, при последующих рассмотрениях на похожую роль в любом из 90+ сервисов кандидату зачтут предыдущее прохождение секций и предложат только финалы с руководителями.
Повышаем прозрачность - теперь большинство кандидатов уже на старте процесса будут знать максимальное количество и содержание предстоящих этапов. А уже совсем скоро запустится личный кабинет для кандидатов, в котором можно будет видеть всю необходимую информацию и управлять процессом: на каком этапе собеседований кандидат находится, как прошёл предыдущие секции, какие предстоят секции и как к ним подготовиться, возможность самостоятельно выбирать удобные слоты под секции, выбирать вакансии. До выхода кабинета часть его функциональности будет доступна в боте.
Всесторонняя оценка компетенций - к задачам на базовые навыки добавятся задачи на специфические знания конкретного стека и языков программирования, а «дубли» секций на алгоритмы пропадут из процесса. Большинство задач будет приближено к реальным рабочим.
Зачем я принес этот анонс?
Очень просто - для многих собесы в Яндекс были какой-то страшилкой, блокером и т.д., и эти изменения могут развеять их страх, и они наконец решатся подать резюме и получат работу, о которой мечтали. Буду рад увидеться в офисе
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21👍12❤2😁2👏1
#тимлидство
Здарова, работяги!
Вот и прошел ещё один модуль обучения - накопилось много материалов и инсайтов по управлению изменениями. По традиции, делюсь коротким обзором: что нового пройдено, какие идеи показались самыми полезными, а с чем еще предстоит разобраться.
Темы модуля:
1. Модели и подходы к управлению изменениями:
Модель Джона Коттера, ADKAR, Липитт-Кностер - разобрали разные схемы, как запускать и закреплять перемены в команде. ADKAR даже уже попробовал на практике - штука рабочая. Также на TeamLeadConf (отдельный пост напишу) обсуждал эти модели с лидами из других компаний - многие активно применяют, поэтому советую обратить внимание на эти модели, если еще не знакомы.
2. Иммунитет к изменениям:
Почему опытные команды иногда саботируют даже здравые решения, какие глубинные убеждения включают "внутреннего луддита", и как это раскрывать через честные диалоги и спецтехники. Важный инсайд - в каждом из нас живёт свой маленький "хранитель стабильности", важно научиться распознавать, когда он беспокоится по делу, а когда просто - "Раньше было лучше!".
3. Культура открытости и Growth Mindset:
Фиксированное мышление vs Мышление роста - почему мышление роста - это не модный термин, а прямой драйвер для внедрения инноваций. Про осознанность, честный фидбек, безопасную среду, где можно ошибаться, учиться и цепляться за новые возможности.
4. Стратегические и тактические изменения:
Осваивали подходы от малых изменений (incremental), которые делают развитие постоянным процессом, до "больших шагов" и трансформирующих поворотов - когда нужно не просто подкрутить процессы, а серьезно заняться "краксом" (узловой проблемой) (об этом много написано у Ричарда Румельта).
5. Работа с сопротивлением:
Практики работы с группами и стейкхолдерами: как выявлять скрытые страхи, строить коалиции и находить быстрые победы, чтобы команда шла за тобой.
Практика
Особое внимание уделили практике моделей ADKAR и Коттера, что очень помогло быстро начать использовать их в своей работе.
В сухом остатке:
- ADKAR и Коттер действительно рабочие вещи, а не просто сказки седого старца - поэтому обязательно изучаем.
- Ритуалы, артефакты, честная коммуникация, быстрая обратная связь и маленькие победы - must have для любой трансформации.
- И не будьте луддитом, старайтесь быть открытым новому, но не забывайте про критическое мышление - тут важен баланс. Особенно это актуально в текущее время, чтобы балансировать между фанатиками и старообрядцами и внедрять действительно полезные улучшения в области ai.
А теперь вопрос вам: какие перемены реально запускали у себя, где было самое сильное сопротивление, и что реально помогло? Делитесь инсайтами, рецептами и фейлами 👇
Здарова, работяги!
Вот и прошел ещё один модуль обучения - накопилось много материалов и инсайтов по управлению изменениями. По традиции, делюсь коротким обзором: что нового пройдено, какие идеи показались самыми полезными, а с чем еще предстоит разобраться.
Темы модуля:
1. Модели и подходы к управлению изменениями:
Модель Джона Коттера, ADKAR, Липитт-Кностер - разобрали разные схемы, как запускать и закреплять перемены в команде. ADKAR даже уже попробовал на практике - штука рабочая. Также на TeamLeadConf (отдельный пост напишу) обсуждал эти модели с лидами из других компаний - многие активно применяют, поэтому советую обратить внимание на эти модели, если еще не знакомы.
2. Иммунитет к изменениям:
Почему опытные команды иногда саботируют даже здравые решения, какие глубинные убеждения включают "внутреннего луддита", и как это раскрывать через честные диалоги и спецтехники. Важный инсайд - в каждом из нас живёт свой маленький "хранитель стабильности", важно научиться распознавать, когда он беспокоится по делу, а когда просто - "Раньше было лучше!".
3. Культура открытости и Growth Mindset:
Фиксированное мышление vs Мышление роста - почему мышление роста - это не модный термин, а прямой драйвер для внедрения инноваций. Про осознанность, честный фидбек, безопасную среду, где можно ошибаться, учиться и цепляться за новые возможности.
4. Стратегические и тактические изменения:
Осваивали подходы от малых изменений (incremental), которые делают развитие постоянным процессом, до "больших шагов" и трансформирующих поворотов - когда нужно не просто подкрутить процессы, а серьезно заняться "краксом" (узловой проблемой) (об этом много написано у Ричарда Румельта).
5. Работа с сопротивлением:
Практики работы с группами и стейкхолдерами: как выявлять скрытые страхи, строить коалиции и находить быстрые победы, чтобы команда шла за тобой.
Практика
Особое внимание уделили практике моделей ADKAR и Коттера, что очень помогло быстро начать использовать их в своей работе.
В сухом остатке:
- ADKAR и Коттер действительно рабочие вещи, а не просто сказки седого старца - поэтому обязательно изучаем.
- Ритуалы, артефакты, честная коммуникация, быстрая обратная связь и маленькие победы - must have для любой трансформации.
- И не будьте луддитом, старайтесь быть открытым новому, но не забывайте про критическое мышление - тут важен баланс. Особенно это актуально в текущее время, чтобы балансировать между фанатиками и старообрядцами и внедрять действительно полезные улучшения в области ai.
А теперь вопрос вам: какие перемены реально запускали у себя, где было самое сильное сопротивление, и что реально помогло? Делитесь инсайтами, рецептами и фейлами 👇
1🔥15👍10❤6