Решение проблемы плохого WiFi
Пост не совсем про продуктовую разработку, но очень хочу поделиться.
На каждой работе у меня был коллега_с_хреновым_интернетом.
Кажется, это мелочь и его личная проблема. В конце концов, код пишется и дело делается, так что можно и потерпеть.
Но на самом деле плохой интернет сказывается на эффективности встреч, отношении к человеку и, как следствие, его карьерном росте.
Работать с таким человеком просто неприятно: размытая картинка, пропадающий голос, непонятно, услышал он тебя или нет. А ещё постоянные вылеты со встреч.
Привет, последние полтора года это я 😅
Я борюсь за интернет с соседями.
На прошлой неделе наконец-то победил!
Живу в многоквартирном доме, где ноут видит 20+ WiFi сетей. Ethernet розеток нет, а вход для роутера закладывался в одном месте во всех квартирах. Поэтому все роутеры соседей стоят в одном углу, а стены у нас тонкие.
Из-за этого WiFi нестабильный даже рядом с роутером.
И это люто бесит.
Расскажу, как боролся и как победил.
Помогло решение, к которому шел 1.5 года:
Ethernet over Powerline.
Устройство преобразует цифровой Ethernet в радио сигнал, и пуляет его в розетку, используя провода под напряжением как среду для передачи сигнала.
На другой стороне приёмник проделывает обратное преобразование: ловит радио сигнал из розетки и преобразует его в цифровой Ethernet.
Я слышал об этом еще лет 15 назад, но тогда подумал, что это какая-то хрень и работать нормально не будет.
А тут уже перепробовал все варианты и терять было нечего, поэтому заказал.
Как же я охренел, когда это завелось.
Просто воткнул девайс в розетку, а Ethernet кабель в роутер и в ноут. И теперь ноут думает, что он напрямую подключен в роутер.
Да, обещанного 1ГБит не дало, но пинг до гугла 9мс и speedtest показал симметричные 170МБит.
Теперь это мой мастхэв для съемного жилья.
Потому что провод всегда стабильнее чем Wi-Fi!
———
Как пришел к этому решению?
Расскажу путь, чтобы вы могли его не повторять 🙂
1. Выбор канала WiFi.
В WiFi 2.4Ghz есть 100MHz и 11 каналов. При этом каждому каналу нужно минимум 20Mhz для модуляции сигнала. Получается, что каналы работают с перекрытием.
Поэтому по факту выбор стоит между 1, 6 и 11.
Если рядом стоят три и более роутера — они друг другу мешают.
Большинство роутеров используют автовыбор, но соседские сети не дают нормально работать даже при ручной настройке.
В MacOS есть встроенная утилита «Беспроводная диагностика» (в меню «Окно» -> «Сканирование»), которая помогает найти менее зашумленный канал.
Cначала мне показалось, что выбор правильного канала помог. Но потом какой-то из соседских роутеров решил, что этот канал ему тоже нравится, и стало опять плохо.
2. Смена роутера на WiFi 5GHz
Решил я попробовать современные технологии — WiFi 5GHz
Каналов больше, проблемы шумных соседей быть не должно.
Прекрасно, подумал я, и заказал новый роутер.
Но оказалось что до дальнего конца квартиры, где я работаю, WiFi 5 не долетает.
3. Провод
По квартире разведены телефонные розетки. Прекрасно, подумал я, и купил обжимку + 4-жильный телефонный кабель + горстку RJ45 и RJ11 коннекторов.
Я осознавал сразу, что это тупиковый путь, но всё равно решил попробовать Вот, пишу, можете не пробовать 🙂
Телефонные провода, даже 4-жильные, не подходят для передачи Ethernet сигнала. То ли изоляции нет и наводки слишком сильные, то ли кабель с большим сопротивлением.
В общем, устройства друг друга не видели.
Дальше думал уже ставить WiFi репитер, но идея использовать провод меня не отпускала.
———
Короче, если мучаетесь с WiFi — попробуйте Poweline Adapter!
Оно того стоит.
P.S. Поделитесь в комментах, какие еще есть варианты решения проблемы, которые я не попробовал?
Пост не совсем про продуктовую разработку, но очень хочу поделиться.
На каждой работе у меня был коллега_с_хреновым_интернетом.
Кажется, это мелочь и его личная проблема. В конце концов, код пишется и дело делается, так что можно и потерпеть.
Но на самом деле плохой интернет сказывается на эффективности встреч, отношении к человеку и, как следствие, его карьерном росте.
Работать с таким человеком просто неприятно: размытая картинка, пропадающий голос, непонятно, услышал он тебя или нет. А ещё постоянные вылеты со встреч.
Привет, последние полтора года это я 😅
Я борюсь за интернет с соседями.
На прошлой неделе наконец-то победил!
Живу в многоквартирном доме, где ноут видит 20+ WiFi сетей. Ethernet розеток нет, а вход для роутера закладывался в одном месте во всех квартирах. Поэтому все роутеры соседей стоят в одном углу, а стены у нас тонкие.
Из-за этого WiFi нестабильный даже рядом с роутером.
И это люто бесит.
Расскажу, как боролся и как победил.
Помогло решение, к которому шел 1.5 года:
Ethernet over Powerline.
Устройство преобразует цифровой Ethernet в радио сигнал, и пуляет его в розетку, используя провода под напряжением как среду для передачи сигнала.
На другой стороне приёмник проделывает обратное преобразование: ловит радио сигнал из розетки и преобразует его в цифровой Ethernet.
Я слышал об этом еще лет 15 назад, но тогда подумал, что это какая-то хрень и работать нормально не будет.
А тут уже перепробовал все варианты и терять было нечего, поэтому заказал.
Как же я охренел, когда это завелось.
Просто воткнул девайс в розетку, а Ethernet кабель в роутер и в ноут. И теперь ноут думает, что он напрямую подключен в роутер.
Да, обещанного 1ГБит не дало, но пинг до гугла 9мс и speedtest показал симметричные 170МБит.
Теперь это мой мастхэв для съемного жилья.
Потому что провод всегда стабильнее чем Wi-Fi!
———
Как пришел к этому решению?
Расскажу путь, чтобы вы могли его не повторять 🙂
1. Выбор канала WiFi.
В WiFi 2.4Ghz есть 100MHz и 11 каналов. При этом каждому каналу нужно минимум 20Mhz для модуляции сигнала. Получается, что каналы работают с перекрытием.
Поэтому по факту выбор стоит между 1, 6 и 11.
Если рядом стоят три и более роутера — они друг другу мешают.
Большинство роутеров используют автовыбор, но соседские сети не дают нормально работать даже при ручной настройке.
В MacOS есть встроенная утилита «Беспроводная диагностика» (в меню «Окно» -> «Сканирование»), которая помогает найти менее зашумленный канал.
Cначала мне показалось, что выбор правильного канала помог. Но потом какой-то из соседских роутеров решил, что этот канал ему тоже нравится, и стало опять плохо.
2. Смена роутера на WiFi 5GHz
Решил я попробовать современные технологии — WiFi 5GHz
Каналов больше, проблемы шумных соседей быть не должно.
Прекрасно, подумал я, и заказал новый роутер.
Но оказалось что до дальнего конца квартиры, где я работаю, WiFi 5 не долетает.
3. Провод
По квартире разведены телефонные розетки. Прекрасно, подумал я, и купил обжимку + 4-жильный телефонный кабель + горстку RJ45 и RJ11 коннекторов.
Я осознавал сразу, что это тупиковый путь, но всё равно решил попробовать Вот, пишу, можете не пробовать 🙂
Телефонные провода, даже 4-жильные, не подходят для передачи Ethernet сигнала. То ли изоляции нет и наводки слишком сильные, то ли кабель с большим сопротивлением.
В общем, устройства друг друга не видели.
Дальше думал уже ставить WiFi репитер, но идея использовать провод меня не отпускала.
———
Короче, если мучаетесь с WiFi — попробуйте Poweline Adapter!
Оно того стоит.
P.S. Поделитесь в комментах, какие еще есть варианты решения проблемы, которые я не попробовал?
🔥24👍12❤2
Талант vs системность и трудолюбие
Вася — молодец! За что ни возьмется — всё у него хорошо получается.
Быстро разбирается в новом проекте, проектирует идеальную архитектуру и пишет рабочий код с первого раза.
Если нанимает разработчика — тот обязательно окажется топ-перформером.
Запускает проекты в срок и качественно.
Процессы и метрики для Васи — это оверхед. Лишняя нагрузка, мешающая творить:
— Зачем измерять велосити? Срок назвали, попадаем, чего еще надо?
— Зачем составлять профиль кандидата? Не так много хороших людей на рынке, чтобы к ним какую-то линеечку прикладывать.
— Какой такой cycle time? Вам шашечки или ехать?
Если Вася преуспевает с таким подходом, то скорее всего ему помогает талант.
Проблема в том, что большинство людей — не Вася.
В этом сложно признаться. Я сам сейчас сижу и думаю: «Ну я-то точно талантливый» 😅.
Вернее, раньше мне так казалось. Но за последние годы что-то поменялось.
Может, появление ребенка заняло всё внимание. Может, бюрократия и обустройство жизни в эмиграции.
Но головы стало не хватать.
Если я буду делать всё, как Вася, — то у меня получится хреново.
Поэтому я включаю системность и трудолюбие. Перестаю плеваться от «оверхеда» и ищу в нём пользу:
— При найме составляю целевой портрет команды и профиль кандидата, чтобы самому лучше понять, кого ищу.
— Слежу за метриками, чтобы вовремя заметить: команда берёт в спринт в 2 раза больше работы, чем может сделать.
— Планирую агенду встреч и веду заметки, пишу follow-up чтобы потом не гадать, о чем договорились.
— Выписываю плюсы, минусы и риски перед сложными решениями. По рискам сразу пишу план митигации.
Это отнимает кучу времени. На реальные дела остаётся только 50%.
Но это помогает не обосраться.
Мораль простая:
Даже если ты талантлив и делаешь всё «по наитию, без лишней бюрократии», — настанет момент, когда места в голове на всё не хватит.
И если к тому моменту уже будет привычка систематизировать — будет легче жить.
Вася — молодец! За что ни возьмется — всё у него хорошо получается.
Быстро разбирается в новом проекте, проектирует идеальную архитектуру и пишет рабочий код с первого раза.
Если нанимает разработчика — тот обязательно окажется топ-перформером.
Запускает проекты в срок и качественно.
Процессы и метрики для Васи — это оверхед. Лишняя нагрузка, мешающая творить:
— Зачем измерять велосити? Срок назвали, попадаем, чего еще надо?
— Зачем составлять профиль кандидата? Не так много хороших людей на рынке, чтобы к ним какую-то линеечку прикладывать.
— Какой такой cycle time? Вам шашечки или ехать?
Если Вася преуспевает с таким подходом, то скорее всего ему помогает талант.
Проблема в том, что большинство людей — не Вася.
В этом сложно признаться. Я сам сейчас сижу и думаю: «Ну я-то точно талантливый» 😅.
Вернее, раньше мне так казалось. Но за последние годы что-то поменялось.
Может, появление ребенка заняло всё внимание. Может, бюрократия и обустройство жизни в эмиграции.
Но головы стало не хватать.
Если я буду делать всё, как Вася, — то у меня получится хреново.
Поэтому я включаю системность и трудолюбие. Перестаю плеваться от «оверхеда» и ищу в нём пользу:
— При найме составляю целевой портрет команды и профиль кандидата, чтобы самому лучше понять, кого ищу.
— Слежу за метриками, чтобы вовремя заметить: команда берёт в спринт в 2 раза больше работы, чем может сделать.
— Планирую агенду встреч и веду заметки, пишу follow-up чтобы потом не гадать, о чем договорились.
— Выписываю плюсы, минусы и риски перед сложными решениями. По рискам сразу пишу план митигации.
Это отнимает кучу времени. На реальные дела остаётся только 50%.
Но это помогает не обосраться.
Мораль простая:
Даже если ты талантлив и делаешь всё «по наитию, без лишней бюрократии», — настанет момент, когда места в голове на всё не хватит.
И если к тому моменту уже будет привычка систематизировать — будет легче жить.
💯50👍21❤18❤🔥3🔥1
Product Developer
Талант vs системность и трудолюбие Вася — молодец! За что ни возьмется — всё у него хорошо получается. Быстро разбирается в новом проекте, проектирует идеальную архитектуру и пишет рабочий код с первого раза. Если нанимает разработчика — тот обязательно окажется…
10 привычек растущих сотрудников
К слову о привычках.
Я вписался в 9-месячный курс от Стратоплана за дохрена денег. Проходной балл высокий: не достаточно заплатить, — нужно еще сделать тестовый кейс и пройти собеседование.
Стратоплан — господа уважаемые. Могут себе позволить, так сказать 🙂
В общем, кейс я решил и собес прошел, поэтому иногда буду писать свою рефлексию на тему материалов курса.
А пока — приношу бесплатную полезность: 2х-недельный марафон, который подойдет вообще всем: инженерам и тимлидам, аналитикам, продактам, СТО и фаундерам.
Начнется 13 января.
Спикерами и авторами будут команда тренеров Стратоплана, а также уважаемые товарищи по телеграм-каналам: Евгений Антонов («Тимлид очевидность»), Ольга Елисеева («Teamlead с места в career»), Александра Баптизманская («Нестыдная фасилитация»).
Каждый день будет либо эфир, либо лонгрид.
Вот некоторые привычки:
— Прояснять мотивы и потребности, ожидания других людей
— Регулярность и дисциплина
— Обращать внимание на мелкие детали
— Запрашивать и давать обратную связь
— Работать над личным брендом и своим визабилити
— Послать дела нахрен, чтобы успеть их вовремя
О каждой расскажут не только, почему она полезная, но и как её себе привить.
Участие бесплатное, доступ ко всем материалам останется навсегда.
Нужно только зарегистрироваться: https://stratoplan-school.com/habits/
13-25 января.
P.S. за этот пост мне не платили
К слову о привычках.
Я вписался в 9-месячный курс от Стратоплана за дохрена денег. Проходной балл высокий: не достаточно заплатить, — нужно еще сделать тестовый кейс и пройти собеседование.
Стратоплан — господа уважаемые. Могут себе позволить, так сказать 🙂
В общем, кейс я решил и собес прошел, поэтому иногда буду писать свою рефлексию на тему материалов курса.
А пока — приношу бесплатную полезность: 2х-недельный марафон, который подойдет вообще всем: инженерам и тимлидам, аналитикам, продактам, СТО и фаундерам.
Начнется 13 января.
Спикерами и авторами будут команда тренеров Стратоплана, а также уважаемые товарищи по телеграм-каналам: Евгений Антонов («Тимлид очевидность»), Ольга Елисеева («Teamlead с места в career»), Александра Баптизманская («Нестыдная фасилитация»).
Каждый день будет либо эфир, либо лонгрид.
Вот некоторые привычки:
— Прояснять мотивы и потребности, ожидания других людей
— Регулярность и дисциплина
— Обращать внимание на мелкие детали
— Запрашивать и давать обратную связь
— Работать над личным брендом и своим визабилити
— Послать дела нахрен, чтобы успеть их вовремя
О каждой расскажут не только, почему она полезная, но и как её себе привить.
Участие бесплатное, доступ ко всем материалам останется навсегда.
Нужно только зарегистрироваться: https://stratoplan-school.com/habits/
13-25 января.
P.S. за этот пост мне не платили
Stratoplan-School
Такой страницы не существует — Stratoplan
Вы попали на несуществующую страницу. Возможно, она была удалена или перенесена.
👍43🔥16❤10👎2
StarMap — карта компетенций команды
Шаблон
Забрать себе: File -> Make a copy
В двух словах — это экселька, где строки — компетенции, столбцы — ФИО, а значения в ячейках — степень владения компетенцией:
— 0 — нет навыка
— 1 — учится
— 2 — умеет самостоятельно
— 3 — может учить
А еще в этом шаблоне автоматически считается бас-фактор и риски.
Зачем вам стармап?
Для инженера:
— понять, какие навыки прокачивать, чтобы это было полезно команде
— увидеть, где можно выступить ментором
— сориентироваться, к кому идти за советом
Для тимлида:
— составить портрет команды «as is»
— увидеть бас-фактор и ботлнеки
— составить картинку «to be», целевой портрет
— проактивно пойти к разработчикам с запросом на прокачку конкретных навыков
— составить профиль кандидата для найма
———
4 года назад я уже писал пост про стармап — тогда это был способ продать его инженерам в моей команде с точки зрения пользы для них 🙂
С тех пор ни разу не заставил команду заполнять стармап, но сам как тимлид заполнил три стармапа для разных команд. По пути переосмыслил применимость инструмента.
Вот к чему я пришел:
1. Составлять стармап командой — дорого.
Не подумайте, я не отговариваю вас. Если команда сама хочет — буду только рад!
Но обычно разработчики не покупают это «менеджерское» упражнение. Приятнее фичу напилить 🙂
— Если инженер хочет что-то прокачивать и не знает что — проще прийти к тимлиду и спросить.
— Когда кого-то в команде нужно менторить — тимлид сам приходит к будущему ментору и договаривается.
— Если нужен онбординг, — выделенный бадди + хорошая дока будут эффективнее.
2. Составлять тимлидом — дешевле, и в большинстве случаев эффективнее
Во-первых, это оказался супер полезный инструмент для онбординга тимлида в новую команду.
Во-вторых, это способ систематизировать работу с командой. Каждый раз я открывал для себя какие-то неочевидные штуки, которые упустил бы, если бы не выложил «на бумагу».
Но есть минусы: без команды можно упустить компетенции. Поэтому так или иначе нужно собирать список с ребятами.
И тоже не всегда это упражнение оправдано:
— Если в команде 3 человека — скорее всего, компетенции можно удержать в голове.
— Если не планируется нового найма — то и профиль кандидата составлять не нужно.
— Если бэклог устаканился и очевидно, что все компетенции в команде есть.
Хотя повторюсь, без выписывания на бумагу есть риск что-то упустить. Даже в команде из 3 человек с устаканившимся бэклогом.
Поэтому если есть возможность и желание что-то систематизировать — со стармапом будет лучше.
———
Забирайте шаблон (File -> Make copy), составляйте стармапы, пишите комменты к посту 🙂
P.S. Шаблон — на самом деле реальный стармап одной из команд, в котором я поменял имена. Список компетенций может вас заинтересовать, но предостерегаю от прямого копирования.
Шаблон
Забрать себе: File -> Make a copy
В двух словах — это экселька, где строки — компетенции, столбцы — ФИО, а значения в ячейках — степень владения компетенцией:
— 0 — нет навыка
— 1 — учится
— 2 — умеет самостоятельно
— 3 — может учить
А еще в этом шаблоне автоматически считается бас-фактор и риски.
Зачем вам стармап?
Для инженера:
— понять, какие навыки прокачивать, чтобы это было полезно команде
— увидеть, где можно выступить ментором
— сориентироваться, к кому идти за советом
Для тимлида:
— составить портрет команды «as is»
— увидеть бас-фактор и ботлнеки
— составить картинку «to be», целевой портрет
— проактивно пойти к разработчикам с запросом на прокачку конкретных навыков
— составить профиль кандидата для найма
———
4 года назад я уже писал пост про стармап — тогда это был способ продать его инженерам в моей команде с точки зрения пользы для них 🙂
С тех пор ни разу не заставил команду заполнять стармап, но сам как тимлид заполнил три стармапа для разных команд. По пути переосмыслил применимость инструмента.
Вот к чему я пришел:
1. Составлять стармап командой — дорого.
Не подумайте, я не отговариваю вас. Если команда сама хочет — буду только рад!
Но обычно разработчики не покупают это «менеджерское» упражнение. Приятнее фичу напилить 🙂
— Если инженер хочет что-то прокачивать и не знает что — проще прийти к тимлиду и спросить.
— Когда кого-то в команде нужно менторить — тимлид сам приходит к будущему ментору и договаривается.
— Если нужен онбординг, — выделенный бадди + хорошая дока будут эффективнее.
2. Составлять тимлидом — дешевле, и в большинстве случаев эффективнее
Во-первых, это оказался супер полезный инструмент для онбординга тимлида в новую команду.
Во-вторых, это способ систематизировать работу с командой. Каждый раз я открывал для себя какие-то неочевидные штуки, которые упустил бы, если бы не выложил «на бумагу».
Но есть минусы: без команды можно упустить компетенции. Поэтому так или иначе нужно собирать список с ребятами.
И тоже не всегда это упражнение оправдано:
— Если в команде 3 человека — скорее всего, компетенции можно удержать в голове.
— Если не планируется нового найма — то и профиль кандидата составлять не нужно.
— Если бэклог устаканился и очевидно, что все компетенции в команде есть.
Хотя повторюсь, без выписывания на бумагу есть риск что-то упустить. Даже в команде из 3 человек с устаканившимся бэклогом.
Поэтому если есть возможность и желание что-то систематизировать — со стармапом будет лучше.
———
Забирайте шаблон (File -> Make copy), составляйте стармапы, пишите комменты к посту 🙂
P.S. Шаблон — на самом деле реальный стармап одной из команд, в котором я поменял имена. Список компетенций может вас заинтересовать, но предостерегаю от прямого копирования.
Google Docs
Product Developer StarMap Template
🔥29👍9
Систематизация vs бюрократия
Талантливые ребята обычно умеют систематизировать, даже если делают это интуитивно.
Здесь под словом «систематизация» я имею в виду создание логической структуры, чтобы любой процесс или информация стали понятными, воспроизводимыми и управляемыми.
И тут ключевое слово — управляемыми.
Потому что если ты не можешь управлять чем-то, ты либо оставляешь это на волю случая, либо начинаешь реагировать на пожар, а не предупреждать его.
Круто, когда ваша команда состоит сплошь из талантливых ребят. Они могут работать без процессов и делать дело, пока другие занимаются своими сторипоинтами и ретроспективами.
Но обычно люди в команде очень разные. И все они ошибаются.
И вот менеджер видит, что не все «достаточно талантливые», и начинает вводить процессы, чтобы подстраховать от ошибок.
Я не встречал менеджеров, которые вводят процессы, чтобы усложнить жизнь сотрудникам.
Обычно цель благая — сделать продукт лучше, несмотря на риски и человеческий фактор.
Пример: в пятницу вечером кто-то деплоит неработающий код. В выходные сайт лежит, пользователи страдают, а компания теряет деньги.
Чтобы от этого застраховаться мы вводим линтеры, код-ревью, автотесты, релизные часы, дежурства, мониторинг, алерты, …
И это как будто бы нормально. Редко кто против линтеров и код-ревью.
Но бывают процессы, которые приносят боль. У всех это разное: кому-то не нравится оценка задач в сторипоинтах, кого-то выворачивает от потребности планировать спринты на две недели и потом оправдываться за скоуп-дроп.
Системность легко превращается в избыточную бюрократию.
Если ваша команда тратит слишком много времени на процессы, задайте себе вопрос:
Вы действительно оптимизируете работу?
Или пытаетесь защититься от некомпетентных и неуправляемых сотрудников?
Точно ли нужно строить работу с некомпетентными сотрудниками через внедрение процессов?
А когда вы в последний раз пересматривали или отменяли какой-то процесс?
Талантливые ребята обычно умеют систематизировать, даже если делают это интуитивно.
Здесь под словом «систематизация» я имею в виду создание логической структуры, чтобы любой процесс или информация стали понятными, воспроизводимыми и управляемыми.
И тут ключевое слово — управляемыми.
Потому что если ты не можешь управлять чем-то, ты либо оставляешь это на волю случая, либо начинаешь реагировать на пожар, а не предупреждать его.
Круто, когда ваша команда состоит сплошь из талантливых ребят. Они могут работать без процессов и делать дело, пока другие занимаются своими сторипоинтами и ретроспективами.
Но обычно люди в команде очень разные. И все они ошибаются.
И вот менеджер видит, что не все «достаточно талантливые», и начинает вводить процессы, чтобы подстраховать от ошибок.
Я не встречал менеджеров, которые вводят процессы, чтобы усложнить жизнь сотрудникам.
Обычно цель благая — сделать продукт лучше, несмотря на риски и человеческий фактор.
Пример: в пятницу вечером кто-то деплоит неработающий код. В выходные сайт лежит, пользователи страдают, а компания теряет деньги.
Чтобы от этого застраховаться мы вводим линтеры, код-ревью, автотесты, релизные часы, дежурства, мониторинг, алерты, …
И это как будто бы нормально. Редко кто против линтеров и код-ревью.
Но бывают процессы, которые приносят боль. У всех это разное: кому-то не нравится оценка задач в сторипоинтах, кого-то выворачивает от потребности планировать спринты на две недели и потом оправдываться за скоуп-дроп.
Системность легко превращается в избыточную бюрократию.
Если ваша команда тратит слишком много времени на процессы, задайте себе вопрос:
Вы действительно оптимизируете работу?
Или пытаетесь защититься от некомпетентных и неуправляемых сотрудников?
Точно ли нужно строить работу с некомпетентными сотрудниками через внедрение процессов?
А когда вы в последний раз пересматривали или отменяли какой-то процесс?
👍28❤9💯6
Кеширование — это ответ!
…а какой был ваш вопрос?
Все любят кеши.
Упираетесь в БД по количеству запросов? Кеш!
Нужно быстрее отдавать данные? Кеш!
Но не все так просто.
В этом посте накидаю вопросов, на которые стоит ответить, если хотите добавить кеширующий слой.
1. Во-первых, кеш — это еще одна точка отказа.
Если кеш внешний, например Redis, то он вполне себе подвержен проблемам инфраструктурного характера: сеть, железки, «шумные соседи» на виртуалках, троттлинг отдельных компонентов по CPU.
А еще его нужно обслуживать: менять конфиги, обновлять с даунтаймом, …
Если ваше приложение уперлось в производительность БД, сможет ли оно выжить без кеша?
Как будете жить при недоступности Redis? Рейт-лимитер?
А насколько критично для потребителей получить отказ или задержку?
Если кеш in-memory, то как избежать повышенной нагрузки на БД при деплое?
Придется катить приложение очень медленно, канарейкой, поднимая новые поды пошагово.
Как гарантировать, что новый разработчик не задеплоит слишком быстро?
2. Во-вторых, кеш — это еще одно усложнение потоков данных.
Инвалидация кеша — одна из трёх главных проблем IT, после нейминга переменных и race condition.
Готово ли ваше приложение к eventual consistency?
В каких сценариях данные в БД меняются и когда инвалидировать кеш?
3. В-третьих, кеш — это доп. затраты на поддержку.
Допустим, через год появится ещё один сценарий изменения данных.
Как гарантировать, что новый разработчик не забудет инвалидировать кеш?
Опять же, сам редис и библиотеки надо обновлять.
4. В-четвёртых, кеш никогда не даёт 100% hit rate.
Придётся экспериментировать, какие данные кешировать, чтобы hit rate был хотя бы 80%+.
5. А точно ли кеш будет быстрее, чем в PgSQL?
Во всех современных БД есть встроенные механики кеширования, и умные люди долго их оттачивали.
Парочка пруфов: Can Postgres replace Redis as a cache? + Benchmark: Postgres as cache vs Redis
Наш пример:
— Есть PostgreSQL с 300 млн записей
— Есть хорошо оптимизированный запрос, который держит 2 млн RPM и отрабатывает за 8-10 мс в 99 перцентиле. Очевидно, это тайминги без похода на диск.
— Утилизация CPU на БД уже 60%+, поэтому вводим кеш для подстраховки от пиков
И что? Время ответа выросло до 20 мс!
————
К чему это я?
В большинстве случаев кеширование — очевидная, но не самая лучшая идея.
Это поможет как анастезия, но не решение корневой проблемы.
Более правильным решением будет расшивать БД:
— читать с реплики
— шардировать
— переезжать на другой тип СУБД, более подходящий под профиль нагрузки
Change my mind.
…а какой был ваш вопрос?
Все любят кеши.
Упираетесь в БД по количеству запросов? Кеш!
Нужно быстрее отдавать данные? Кеш!
Но не все так просто.
В этом посте накидаю вопросов, на которые стоит ответить, если хотите добавить кеширующий слой.
1. Во-первых, кеш — это еще одна точка отказа.
Если кеш внешний, например Redis, то он вполне себе подвержен проблемам инфраструктурного характера: сеть, железки, «шумные соседи» на виртуалках, троттлинг отдельных компонентов по CPU.
А еще его нужно обслуживать: менять конфиги, обновлять с даунтаймом, …
Если ваше приложение уперлось в производительность БД, сможет ли оно выжить без кеша?
Как будете жить при недоступности Redis? Рейт-лимитер?
А насколько критично для потребителей получить отказ или задержку?
Если кеш in-memory, то как избежать повышенной нагрузки на БД при деплое?
Придется катить приложение очень медленно, канарейкой, поднимая новые поды пошагово.
Как гарантировать, что новый разработчик не задеплоит слишком быстро?
2. Во-вторых, кеш — это еще одно усложнение потоков данных.
Инвалидация кеша — одна из трёх главных проблем IT, после нейминга переменных и race condition.
Готово ли ваше приложение к eventual consistency?
В каких сценариях данные в БД меняются и когда инвалидировать кеш?
3. В-третьих, кеш — это доп. затраты на поддержку.
Допустим, через год появится ещё один сценарий изменения данных.
Как гарантировать, что новый разработчик не забудет инвалидировать кеш?
Опять же, сам редис и библиотеки надо обновлять.
4. В-четвёртых, кеш никогда не даёт 100% hit rate.
Придётся экспериментировать, какие данные кешировать, чтобы hit rate был хотя бы 80%+.
5. А точно ли кеш будет быстрее, чем в PgSQL?
Во всех современных БД есть встроенные механики кеширования, и умные люди долго их оттачивали.
Парочка пруфов: Can Postgres replace Redis as a cache? + Benchmark: Postgres as cache vs Redis
Наш пример:
— Есть PostgreSQL с 300 млн записей
— Есть хорошо оптимизированный запрос, который держит 2 млн RPM и отрабатывает за 8-10 мс в 99 перцентиле. Очевидно, это тайминги без похода на диск.
— Утилизация CPU на БД уже 60%+, поэтому вводим кеш для подстраховки от пиков
И что? Время ответа выросло до 20 мс!
————
К чему это я?
В большинстве случаев кеширование — очевидная, но не самая лучшая идея.
Это поможет как анастезия, но не решение корневой проблемы.
Более правильным решением будет расшивать БД:
— читать с реплики
— шардировать
— переезжать на другой тип СУБД, более подходящий под профиль нагрузки
Change my mind.
Medium
Can Postgres replace Redis as a cache?
I wanted to understand: Is Postgres as a cache a really good idea? Can it indeed replace Redis? That’s what I want to find out today.
👍29🔥6❤2
🎉 Мой новый Live-канал: про жизнь, путешествия и удалёнку без розовых очков
…каждый успешный блогер должен завести лайв-канал 😄️️️️
В Product Developer я стараюсь держать высокий уровень постов:
✅ Максимум пользы, минимум воды
✅ Только по делу — без личного и бытовухи
✅ Тщательная подготовка (иногда до 16 часов на пост)
Но вот один-единственный личный пост про Digital Nomad в Испании внезапно зашёл на 11К просмотров, 300 репостов и 300 реакций. Видимо, тема жизни и работы в других странах кому-то интересна. А мне хочется делиться таким без редакции и строгих рамок.
Поэтому мы с женой завели @sharelocations!
🏝️ О чём пишем?
— Испания без маркетинговых брошюр: переезд, быт, счета, страховки, местные законы
— Удалёнка и workation: как совместить работу и поездки без потери продуктивности
— Путешествия: 30-дневный переезд на машине из Москвы в Валенсию, маршрут на автодоме, север и юг Испании, Мадрид и деревни
— Эмиграция без розовых очков: интеграция, разница культур, локальные праздники
Последний пост — про workation: 30 дней в пути на машине, всего 4 дня отпуска, остальное — полноценная работа. Это было сложнее, чем казалось изначально.
P.S. Испытываю эмоции, как 4 года назад, когда этот канал был еще совсем малыш. Очень приятное чувство нового начала.. Смесь энтузиазма и опасений, что ничего не получится, но вера и желание писать. 🙂
Если интересно — подписывайтесь: @sharelocations
…каждый успешный блогер должен завести лайв-канал 😄️️️️
В Product Developer я стараюсь держать высокий уровень постов:
✅ Максимум пользы, минимум воды
✅ Только по делу — без личного и бытовухи
✅ Тщательная подготовка (иногда до 16 часов на пост)
Но вот один-единственный личный пост про Digital Nomad в Испании внезапно зашёл на 11К просмотров, 300 репостов и 300 реакций. Видимо, тема жизни и работы в других странах кому-то интересна. А мне хочется делиться таким без редакции и строгих рамок.
Поэтому мы с женой завели @sharelocations!
🏝️ О чём пишем?
— Испания без маркетинговых брошюр: переезд, быт, счета, страховки, местные законы
— Удалёнка и workation: как совместить работу и поездки без потери продуктивности
— Путешествия: 30-дневный переезд на машине из Москвы в Валенсию, маршрут на автодоме, север и юг Испании, Мадрид и деревни
— Эмиграция без розовых очков: интеграция, разница культур, локальные праздники
Последний пост — про workation: 30 дней в пути на машине, всего 4 дня отпуска, остальное — полноценная работа. Это было сложнее, чем казалось изначально.
P.S. Испытываю эмоции, как 4 года назад, когда этот канал был еще совсем малыш. Очень приятное чувство нового начала.. Смесь энтузиазма и опасений, что ничего не получится, но вера и желание писать. 🙂
Если интересно — подписывайтесь: @sharelocations
Telegram
Расшарь локейшен
Workation: 30 дней в пути, работая full-time
Термин workation (work + vacation) я впервые услышал от своего руководителя. Короче, это как отпуск, только работаешь. 😄
Звучит классно. Все мы видели эти картинки: ноутбук, кокос, пляж. Рабочий чат на фоне заката.…
Термин workation (work + vacation) я впервые услышал от своего руководителя. Короче, это как отпуск, только работаешь. 😄
Звучит классно. Все мы видели эти картинки: ноутбук, кокос, пляж. Рабочий чат на фоне заката.…
❤6👍6🔥1
Shit tolerance — это софт скилл
Загадка: есть у джуна, нет у мидла, но нужно сеньору?
Нет, это не «стрессоустойчивость», не эмоциональный интеллект и не умение договариваться.
Это совершенно отдельный навык, «врожденный» у джуна, а затем падающий в нули у мидла по мере повышения насмотренности и осознания количества предложений на рынке.
Можно, конечно, попрыгать по нескольким компаниям. Даже получить лычку «сеньора» с точки зрения технических навыков. Но этот навык мидл должен прокачивать, чтобы реально стать сеньором и расти дальше в ведущего или перйти в тимлида.
Сеньор — это не просто «эксперт, который кодит». Это человек, который понимает, что хаос неизбежен, но вместо нытья думает, как его минимизировать.
О чем речь?
Shit tolerance — это способность сохранять продуктивность, когда процессы неидеальны, задачи не всегда чёткие, а идеальный мир существует только в фантазиях.
В любой работе есть неидеальность. Где-то это процессы (или их отсутствие). Например, кого-то шокирует отсутствие код-ревью. Где-то это техническая составляющая или стабильность сервисов. Кого-то может шокировать пожар на проде. Кого-то — потребность оценивать задачи и попадать в оценки.
А кому-то норм трекать время, потраченное на задачи, и заполнять таймшиты.
На любой shit есть три возможных варианта реакции:
1. Смириться
2. Уйти
3. Починить
Ну и распределение по грейдам примерно такое же:
1 — Джун
2 — Мидл
3 — Сеньор
Если нет код-ревью и видна потребность — сеньор предложит, продаст команде, и внедрит.
Если прод горит — сеньор спокойно пойдёт чинить.
Если надо выполнять задачи, взятые в спринт, — сеньор проанализирует причины и решит проблемы: улучшит процесс подготовки задач, договорится со смежниками, …
Как прокачать shit tolerance?
1️⃣ Переключиться с эмоций на действия. Вместо «это полный п#ц!» — «окей, как мы это разрулим?»
2️⃣ Отделять важное от неважного. Не все проблемы стоит решать. Нужно отличать:
— Рабочий шум, который можно фильтровать. Например, срочные задачи, которые всегда срочные.
— Системные проблемы, которые нужно решать. Например, бардак в процессах, мешающий работать.
3️⃣ Оставлять энергию на главные вещи. Иногда лучший ответ на хаос — работать спокойно и делать своё.
Но!
Shit tolerance — не значит терпеть любой беспредел.
Если каждый день вызывает боль и ощущение бессмысленности — это не про гибкость, а про выгорание.
И да, сеньоры и лиды тоже имеют право на выход. Главное — не потерять себя и не стать частью болота.
P.S. Картинку к посту я позаимствовал из твиттера Евгения Кота. Тред замечательный, рекомендую к прочтению.
Какой у вас уровень shit tolerance? 😏
Загадка: есть у джуна, нет у мидла, но нужно сеньору?
Нет, это не «стрессоустойчивость», не эмоциональный интеллект и не умение договариваться.
Это совершенно отдельный навык, «врожденный» у джуна, а затем падающий в нули у мидла по мере повышения насмотренности и осознания количества предложений на рынке.
Можно, конечно, попрыгать по нескольким компаниям. Даже получить лычку «сеньора» с точки зрения технических навыков. Но этот навык мидл должен прокачивать, чтобы реально стать сеньором и расти дальше в ведущего или перйти в тимлида.
Сеньор — это не просто «эксперт, который кодит». Это человек, который понимает, что хаос неизбежен, но вместо нытья думает, как его минимизировать.
О чем речь?
Shit tolerance — это способность сохранять продуктивность, когда процессы неидеальны, задачи не всегда чёткие, а идеальный мир существует только в фантазиях.
В любой работе есть неидеальность. Где-то это процессы (или их отсутствие). Например, кого-то шокирует отсутствие код-ревью. Где-то это техническая составляющая или стабильность сервисов. Кого-то может шокировать пожар на проде. Кого-то — потребность оценивать задачи и попадать в оценки.
А кому-то норм трекать время, потраченное на задачи, и заполнять таймшиты.
На любой shit есть три возможных варианта реакции:
1. Смириться
2. Уйти
3. Починить
Ну и распределение по грейдам примерно такое же:
1 — Джун
2 — Мидл
3 — Сеньор
Если нет код-ревью и видна потребность — сеньор предложит, продаст команде, и внедрит.
Если прод горит — сеньор спокойно пойдёт чинить.
Если надо выполнять задачи, взятые в спринт, — сеньор проанализирует причины и решит проблемы: улучшит процесс подготовки задач, договорится со смежниками, …
Как прокачать shit tolerance?
1️⃣ Переключиться с эмоций на действия. Вместо «это полный п#ц!» — «окей, как мы это разрулим?»
2️⃣ Отделять важное от неважного. Не все проблемы стоит решать. Нужно отличать:
— Рабочий шум, который можно фильтровать. Например, срочные задачи, которые всегда срочные.
— Системные проблемы, которые нужно решать. Например, бардак в процессах, мешающий работать.
3️⃣ Оставлять энергию на главные вещи. Иногда лучший ответ на хаос — работать спокойно и делать своё.
Но!
Shit tolerance — не значит терпеть любой беспредел.
Если каждый день вызывает боль и ощущение бессмысленности — это не про гибкость, а про выгорание.
И да, сеньоры и лиды тоже имеют право на выход. Главное — не потерять себя и не стать частью болота.
P.S. Картинку к посту я позаимствовал из твиттера Евгения Кота. Тред замечательный, рекомендую к прочтению.
Какой у вас уровень shit tolerance? 😏
👍55💯16❤🔥11❤3🔥3👎1
Софты нужны тем, у кого не всё в порядке с хардами
… Болтать — не мешки ворочать! Лучше б делом занялись.
В IT ты крутой эксперт, если глубоко разбираешься в технологиях: умеешь шардировать БД, оптимизировать SQL запросы, тушить пожары на проде.
А всё остальное, особенно те самые «софт-скиллы», многие считают чем-то второстепенным.
Ну, типа… харизма, характер, общительность, презентации… менеджерская фигня, короче.
У меня был знакомый тимлид, который думал именно так.
И вот как-то в его команде сеньор-инженер три месяца упорно трудился, пилил мегасложную фичу, но про статус работы особо никому не рассказывал. Тимлид тоже не любил лезть с «глупыми вопросами», он и так видел все коммиты и думал: «Всё под контролем, что может пойти не так?»
За пару дней до релиза оказалось, что сеньор прекрасно решил задачу. Но не ту, что просил бизнес. Да и архитектура была красивая, мощная и совершенно несовместимая с текущим продом.
Тимлид не растерялся и решил проблему единственно правильным способом:
Он лично сел и идеально переписал весь код за выходные, согласовал изменения с бизнесом, и даже потратил ещё несколько ночей на деплой и поддержку после релиза. Ну да, немножечко переработал, но зато всё идеально.
А что сеньор?
Сеньора уволили, а вместо него наняли другого.
Теперь уже такого, который умеет и требования согласовать, и статус по задачам регулярно давать, и риски озвучивать.
И тимлида потом тоже уволили, потому что он все пожары тушил сам и в итоге не справился. А вместо него наняли другого.
Который умеет управлять рисками, делегировать и доносить обратную связь.
Стоп. Это же были не софты, правда?
———
Это была затравочка из лонгрида, который я написал для очередного бесплатного марафона Стратоплана.
Всего будет 10 таких «вредных советов» — в формате лонгридов и 30-минутных вечерних эфиров.
Начинаем сегодня.
Примеры тем:
– делай всё сразу: кто сказал, что многозадачность неэффективна?
– кому надо, тот поймет. Никогда не давайте обратную связь
– планировать — это для средних умов, гении господствуют над хаосом
Вместе со мной будут тренеры Стратоплана и авторы тг-каналов: Евгений Антонов, Роман Ивлиев, Ольга Елисеева, и еще множество тех, кого вы, возможно, читаете.
p.s. Пару лет назад и представить себе не мог, что буду частью Стратоплана!
Регистрация тут. Бесплатно.
… Болтать — не мешки ворочать! Лучше б делом занялись.
В IT ты крутой эксперт, если глубоко разбираешься в технологиях: умеешь шардировать БД, оптимизировать SQL запросы, тушить пожары на проде.
А всё остальное, особенно те самые «софт-скиллы», многие считают чем-то второстепенным.
Ну, типа… харизма, характер, общительность, презентации… менеджерская фигня, короче.
У меня был знакомый тимлид, который думал именно так.
И вот как-то в его команде сеньор-инженер три месяца упорно трудился, пилил мегасложную фичу, но про статус работы особо никому не рассказывал. Тимлид тоже не любил лезть с «глупыми вопросами», он и так видел все коммиты и думал: «Всё под контролем, что может пойти не так?»
За пару дней до релиза оказалось, что сеньор прекрасно решил задачу. Но не ту, что просил бизнес. Да и архитектура была красивая, мощная и совершенно несовместимая с текущим продом.
Тимлид не растерялся и решил проблему единственно правильным способом:
Он лично сел и идеально переписал весь код за выходные, согласовал изменения с бизнесом, и даже потратил ещё несколько ночей на деплой и поддержку после релиза. Ну да, немножечко переработал, но зато всё идеально.
А что сеньор?
Сеньора уволили, а вместо него наняли другого.
Теперь уже такого, который умеет и требования согласовать, и статус по задачам регулярно давать, и риски озвучивать.
И тимлида потом тоже уволили, потому что он все пожары тушил сам и в итоге не справился. А вместо него наняли другого.
Который умеет управлять рисками, делегировать и доносить обратную связь.
Стоп. Это же были не софты, правда?
———
Это была затравочка из лонгрида, который я написал для очередного бесплатного марафона Стратоплана.
Всего будет 10 таких «вредных советов» — в формате лонгридов и 30-минутных вечерних эфиров.
Начинаем сегодня.
Примеры тем:
– делай всё сразу: кто сказал, что многозадачность неэффективна?
– кому надо, тот поймет. Никогда не давайте обратную связь
– планировать — это для средних умов, гении господствуют над хаосом
Вместе со мной будут тренеры Стратоплана и авторы тг-каналов: Евгений Антонов, Роман Ивлиев, Ольга Елисеева, и еще множество тех, кого вы, возможно, читаете.
p.s. Пару лет назад и представить себе не мог, что буду частью Стратоплана!
Регистрация тут. Бесплатно.
Stratoplan-School
Такой страницы не существует — Stratoplan
Вы попали на несуществующую страницу. Возможно, она была удалена или перенесена.
👍45❤🔥18❤18👎5🔥1
🎧 Сходил в подкаст Frontend Weekend к Андрею Смирнову!
Разговор получился глубокий, душевный и очень личный. Обсудили мой карьерный путь, переезд в Испанию, ведение телеграм-канала и даже немного про Digital Nomad и жизнь в Испании.
Отдельно хочу поделиться темой, которая для меня самого сейчас особенно актуальна:
Менеджер или индивидуальный контрибьютор?
Последние 2 года в Авито я руководил юнитом, а недавно стал руководителем кластера.
Работа менеджером мне действительно нравится, но я не считаю зазорным или странным снова вернуться в разработку.
Почему? Потому что, когда ты инженер, у тебя каждый день есть возможность получать удовольствие от быстрых и понятных результатов.
Вот ты написал код, отладил — работает! Сразу получил обратную связь и дофамин.
Чего-то не было — благодаря тебе теперь есть. Ты создал. Ты — созидатель.
Это мгновенная радость от понятного и ощутимого результата.
У менеджера всё не так. Результаты твоих решений и действий проявляются через месяцы, а иногда и полгода спустя.
И чтобы увидеть их и порадоваться, нужно прилагать отдельные усилия и специально рефлексировать.
Многие разработчики по инерции становятся тимлидами, не до конца понимая, что это совсем другая роль с другими правилами игры. Я очень рекомендую задуматься, подходит ли она вам, или вы просто следуете общепринятому карьерному росту.
Выбор «менеджер или инженер» — это не про статус, а про то, какую работу ты больше любишь делать и от чего получаешь удовольствие.
———
Ещё из интересного, что мы обсудили:
📍 Почему полезно поработать в разных компаниях: стартапах, аутсорсе и крупных корпорациях, и как это делает тебя сильнее.
📍 Как жить в Испании, а работать на московский часовой пояс (сложно).
📍 Зачем мне права на прицеп, и как выглядит путешествие на машине длиной в 30 дней из Москвы до Валенсии.
📍 Как европейская бюрократия оказалась человечнее и дружелюбнее, чем российский паспортный стол.
📍 Какие принципы ведения телеграм-канала я нарушаю в @product_developer.
И ещё много всего полезного и личного.
Ссылка на выпуск 👉 Frontend Weekend
Кстати, вдогонку можно подписаться на канал Андрея — он делает отличные интервью!
Разговор получился глубокий, душевный и очень личный. Обсудили мой карьерный путь, переезд в Испанию, ведение телеграм-канала и даже немного про Digital Nomad и жизнь в Испании.
Отдельно хочу поделиться темой, которая для меня самого сейчас особенно актуальна:
Менеджер или индивидуальный контрибьютор?
Последние 2 года в Авито я руководил юнитом, а недавно стал руководителем кластера.
Работа менеджером мне действительно нравится, но я не считаю зазорным или странным снова вернуться в разработку.
Почему? Потому что, когда ты инженер, у тебя каждый день есть возможность получать удовольствие от быстрых и понятных результатов.
Вот ты написал код, отладил — работает! Сразу получил обратную связь и дофамин.
Чего-то не было — благодаря тебе теперь есть. Ты создал. Ты — созидатель.
Это мгновенная радость от понятного и ощутимого результата.
У менеджера всё не так. Результаты твоих решений и действий проявляются через месяцы, а иногда и полгода спустя.
И чтобы увидеть их и порадоваться, нужно прилагать отдельные усилия и специально рефлексировать.
Многие разработчики по инерции становятся тимлидами, не до конца понимая, что это совсем другая роль с другими правилами игры. Я очень рекомендую задуматься, подходит ли она вам, или вы просто следуете общепринятому карьерному росту.
Выбор «менеджер или инженер» — это не про статус, а про то, какую работу ты больше любишь делать и от чего получаешь удовольствие.
———
Ещё из интересного, что мы обсудили:
📍 Почему полезно поработать в разных компаниях: стартапах, аутсорсе и крупных корпорациях, и как это делает тебя сильнее.
📍 Как жить в Испании, а работать на московский часовой пояс (сложно).
📍 Зачем мне права на прицеп, и как выглядит путешествие на машине длиной в 30 дней из Москвы до Валенсии.
📍 Как европейская бюрократия оказалась человечнее и дружелюбнее, чем российский паспортный стол.
📍 Какие принципы ведения телеграм-канала я нарушаю в @product_developer.
И ещё много всего полезного и личного.
Ссылка на выпуск 👉 Frontend Weekend
Кстати, вдогонку можно подписаться на канал Андрея — он делает отличные интервью!
Telegram
Андрей Смирнов | Викенд в IT
С Никитой Хромушкиным мы познакомились в программном комитете тимлидовской подлодки и успели сделать вместе пару сезонов. Но год назад Никита решил вместе с семьёй переехать на машине в Испанию – а я дождался, пока он там освоится и насоберёт интересных впечатлений…
👍16❤10🔥10
🐒 Обезьяний менеджмент
Ситуация: тимлид приходит на работу в отличном настроении, готовый спокойно разобраться с важными задачами.
Но тут к нему подходит разработчик и говорит:
— Есть одна проблема, нужна твоя помощь.
Тимлид отвечает:
— Ок, посмотрю позже.
Разработчик только что поставил тимлиду задачу, а он её положил в свой бесконечный бэклог.
Теперь ему придется её «приоритизировать» с другими такими же, а потом страдать, когда будет всё не успевать.
Представьте себе метафору: задача — обезьяна на плечах. Она перепрыгнула с разработчика на тимлида. К концу дня у него на плечах сидит целый зоопарк. Он занят чужой работой, а его сотрудники простаивают, потому что «ждут ответа».
📌 Коротко о проблеме:
1. Менеджер часто берёт чужие задачи, не замечая, как это происходит.
2. Сотрудники привыкают к тому, что менеджер всегда подстрахует.
3. В итоге:
- менеджер перегружен,
- у сотрудников снижается ответственность и автономность,
- задачи затягиваются, команда менее эффективна.
📌 Правила управления обезьянами:
1️⃣ Определить владельца обезьяны.
Каждая задача должна принадлежать конкретному человеку:
— Ты отлично понимаешь контекст и знаешь задачу. Давай ты предложишь решение, а я помогу его обсудить и доработать.
2️⃣ Определить следующий шаг.
У задачи всегда должна быть следующая конкретная дата и шаг.
— Давай ты на этой неделе подготовишь возможные решения.
3️⃣ Задачи должны быть заботой сотрудников, а не менеджера.
Сотрудник должен сам приходить и рассказывать о результате, а не ждать, когда тимлид спросит.
4️⃣ Назначать чёткое время и место для обсуждений.
Не «потом посмотрю», а «сможешь завтра на груминге показать, что получилось?».
Это дисциплинирует сотрудников и вас самих.
5️⃣ Использовать личное время для работы над личными задачами.
Не перерабатывайте. Не позволяйте чужим обезьянам съедать ваши вечера и выходные. Иначе вы будете выгорать, а команда — деградировать.
📌 Как применять эти правила? Пример:
Разработчик:
— Нужно придумать новую архитектуру, без твоего мнения не продвинемся.
❌ Неправильно:
— Ладно, я посмотрю, вернусь к тебе. (Обезьяна перепрыгнула)
✅ Правильно:
— Ты знаешь задачу лучше всех. Предложи 2-3 варианта решения и приноси завтра на груминг обсудить. Выберем лучший вместе. (Обезьяна осталась на сотруднике)
📌 Что получаем на выходе?
✅ Сотрудники учатся принимать решения и нести за них ответственность.
✅ Вы освобождаете своё время на стратегически важные задачи.
✅ Растёт автономность и мотивация команды.
———
🐵 Итог: не позволяйте чужим задачам прыгать к вам на плечи.
Каждая обезьяна должна иметь своего хозяина, а менеджер должен следить за зоопарком, а не кормить каждую зверюшку лично.
Пост написал по мотивам статьи 1974 года в Harvard Business Review.
Примерно тогда же (1970г) появилась концепция Servant Leadership.
И сначала я подумал, что это два противоположных стиля менеджмента:
Servant Leadership предполагает, что руководитель служит команде. Но как служить команде и не брать на себя задачи?
Давайте в комментах подискутируем: где граница между Servant Leadership и Обезьяньим менеджментом?
Ситуация: тимлид приходит на работу в отличном настроении, готовый спокойно разобраться с важными задачами.
Но тут к нему подходит разработчик и говорит:
— Есть одна проблема, нужна твоя помощь.
Тимлид отвечает:
— Ок, посмотрю позже.
Разработчик только что поставил тимлиду задачу, а он её положил в свой бесконечный бэклог.
Теперь ему придется её «приоритизировать» с другими такими же, а потом страдать, когда будет всё не успевать.
Представьте себе метафору: задача — обезьяна на плечах. Она перепрыгнула с разработчика на тимлида. К концу дня у него на плечах сидит целый зоопарк. Он занят чужой работой, а его сотрудники простаивают, потому что «ждут ответа».
📌 Коротко о проблеме:
1. Менеджер часто берёт чужие задачи, не замечая, как это происходит.
2. Сотрудники привыкают к тому, что менеджер всегда подстрахует.
3. В итоге:
- менеджер перегружен,
- у сотрудников снижается ответственность и автономность,
- задачи затягиваются, команда менее эффективна.
📌 Правила управления обезьянами:
1️⃣ Определить владельца обезьяны.
Каждая задача должна принадлежать конкретному человеку:
— Ты отлично понимаешь контекст и знаешь задачу. Давай ты предложишь решение, а я помогу его обсудить и доработать.
2️⃣ Определить следующий шаг.
У задачи всегда должна быть следующая конкретная дата и шаг.
— Давай ты на этой неделе подготовишь возможные решения.
3️⃣ Задачи должны быть заботой сотрудников, а не менеджера.
Сотрудник должен сам приходить и рассказывать о результате, а не ждать, когда тимлид спросит.
4️⃣ Назначать чёткое время и место для обсуждений.
Не «потом посмотрю», а «сможешь завтра на груминге показать, что получилось?».
Это дисциплинирует сотрудников и вас самих.
5️⃣ Использовать личное время для работы над личными задачами.
Не перерабатывайте. Не позволяйте чужим обезьянам съедать ваши вечера и выходные. Иначе вы будете выгорать, а команда — деградировать.
📌 Как применять эти правила? Пример:
Разработчик:
— Нужно придумать новую архитектуру, без твоего мнения не продвинемся.
❌ Неправильно:
— Ладно, я посмотрю, вернусь к тебе. (Обезьяна перепрыгнула)
✅ Правильно:
— Ты знаешь задачу лучше всех. Предложи 2-3 варианта решения и приноси завтра на груминг обсудить. Выберем лучший вместе. (Обезьяна осталась на сотруднике)
📌 Что получаем на выходе?
✅ Сотрудники учатся принимать решения и нести за них ответственность.
✅ Вы освобождаете своё время на стратегически важные задачи.
✅ Растёт автономность и мотивация команды.
———
🐵 Итог: не позволяйте чужим задачам прыгать к вам на плечи.
Каждая обезьяна должна иметь своего хозяина, а менеджер должен следить за зоопарком, а не кормить каждую зверюшку лично.
Пост написал по мотивам статьи 1974 года в Harvard Business Review.
Примерно тогда же (1970г) появилась концепция Servant Leadership.
И сначала я подумал, что это два противоположных стиля менеджмента:
Servant Leadership предполагает, что руководитель служит команде. Но как служить команде и не брать на себя задачи?
Давайте в комментах подискутируем: где граница между Servant Leadership и Обезьяньим менеджментом?
👍68🔥25❤12🐳2🤣1
Product Developer
🐒 Обезьяний менеджмент Ситуация: тимлид приходит на работу в отличном настроении, готовый спокойно разобраться с важными задачами. Но тут к нему подходит разработчик и говорит: — Есть одна проблема, нужна твоя помощь. Тимлид отвечает: — Ок, посмотрю позже.…
Servant Leadership vs. Обезьяний менеджмент
В комментах к прошлому посту — пожар 🙂
Основной посыл:
- Задача должна оставаться у сотрудника.
- Менеджер консультирует, направляет, помогает ресурсами, но не делает работу за сотрудника.
- Как результат — автономные сотрудники и свободное время менеджера на стратегические задачи.
Остался неотвеченным вопрос: что делать, если сотрудник объективно не может выполнить задачу самостоятельно?
«Обезьяний менеджмент» призывает отказываться решать задачи сотрудников, возвращая ответственность обратно.
«Лидер-слуга» существует для того, чтобы помогать команде. Разве это не значит, что менеджер и должен брать на себя задачи?
Основной посыл Servant Leadership:
— Устранять препятствия, создавать условия для эффективной работы, чтобы сотрудники могли спокойно делать свою работу.
— Давать ресурсы, полномочия и поддержку.
Лидер создаёт среду, в которой сотрудники могут максимально раскрыть свой потенциал.
Лидер берёт на себя задачи, которые команда не может решить без него.
Но это не значит делать за сотрудников их работу.
✅ Правильно: вовремя предоставить необходимые ресурсы и снять административные блокеры.
❌ Неправильно: делать вместо сотрудника то, что он способен сделать сам (придумать решение, написать код, провести аналитику и т.д.).
📌 Конкретный пример
Команда А пилит фичу, затрагивающую чужие сервисы.
Разработчик приходит к тимлиду и говорит: «Команда Б затягивает кодревью».
🔹 Задача команды: качественно реализовать фичу.
🔸 Препятствие: внешнее ревью.
Тимлид идёт договариваться, чтобы выстроить процесс:
— Команда А будет заранее предупреждать о предстоящих изменениях
— Команда Б будет закладывать в спринт время на ревью
— Команда Б обязуется делать ревью за 1 рабочий день
Это не чужая обезьяна, а как раз то препятствие, которое лидер обязан устранить.
…
Другая ситуация — разработчик приходит и говорит: «Нужно придумать архитектуру для фичи».
Здесь оба подхода совпадают:
— Менеджер помогает обсуждением и наставничеством, но не забирает задачу.
— Решение остаётся за сотрудником, иначе падает автономность.
🛠️ Итог:
Servant Leadership и Обезьяний менеджмент — не противоположные подходы.
Это скорее два взгляда на одну и ту же проблему с разными акцентами:
Servant Leadership — это умение вовремя убрать барьеры, чтобы команда могла автономно двигаться вперёд.
Обезьяний менеджмент — это умение не брать на себя задачи, которые команда способна решить сама.
Что думаете?
В комментах к прошлому посту — пожар 🙂
Основной посыл:
- Задача должна оставаться у сотрудника.
- Менеджер консультирует, направляет, помогает ресурсами, но не делает работу за сотрудника.
- Как результат — автономные сотрудники и свободное время менеджера на стратегические задачи.
Остался неотвеченным вопрос: что делать, если сотрудник объективно не может выполнить задачу самостоятельно?
«Обезьяний менеджмент» призывает отказываться решать задачи сотрудников, возвращая ответственность обратно.
«Лидер-слуга» существует для того, чтобы помогать команде. Разве это не значит, что менеджер и должен брать на себя задачи?
Основной посыл Servant Leadership:
— Устранять препятствия, создавать условия для эффективной работы, чтобы сотрудники могли спокойно делать свою работу.
— Давать ресурсы, полномочия и поддержку.
Лидер создаёт среду, в которой сотрудники могут максимально раскрыть свой потенциал.
Лидер берёт на себя задачи, которые команда не может решить без него.
Но это не значит делать за сотрудников их работу.
✅ Правильно: вовремя предоставить необходимые ресурсы и снять административные блокеры.
❌ Неправильно: делать вместо сотрудника то, что он способен сделать сам (придумать решение, написать код, провести аналитику и т.д.).
📌 Конкретный пример
Команда А пилит фичу, затрагивающую чужие сервисы.
Разработчик приходит к тимлиду и говорит: «Команда Б затягивает кодревью».
🔹 Задача команды: качественно реализовать фичу.
🔸 Препятствие: внешнее ревью.
Тимлид идёт договариваться, чтобы выстроить процесс:
— Команда А будет заранее предупреждать о предстоящих изменениях
— Команда Б будет закладывать в спринт время на ревью
— Команда Б обязуется делать ревью за 1 рабочий день
Это не чужая обезьяна, а как раз то препятствие, которое лидер обязан устранить.
…
Другая ситуация — разработчик приходит и говорит: «Нужно придумать архитектуру для фичи».
Здесь оба подхода совпадают:
— Менеджер помогает обсуждением и наставничеством, но не забирает задачу.
— Решение остаётся за сотрудником, иначе падает автономность.
🛠️ Итог:
Servant Leadership и Обезьяний менеджмент — не противоположные подходы.
Это скорее два взгляда на одну и ту же проблему с разными акцентами:
Servant Leadership — это умение вовремя убрать барьеры, чтобы команда могла автономно двигаться вперёд.
Обезьяний менеджмент — это умение не брать на себя задачи, которые команда способна решить сама.
Что думаете?
Telegram
Nikita in Product Developer Chat
Очередной «умник» изобрел метафору с обезьянами и решил, что все проблемы в менеджменте — это лень сотрудников и перегрузка тимлида. Типичная ситуация: вместо того, чтобы помогать людям, теперь менеджер будет тупо скидывать задачи обратно на сотрудников под…
👍35💯4❤🔥3🔥1🤣1
Как управлять людьми, а не чужими задачами
В последних двух постах мы обсуждали, как лидеру управлять командой, а не таскать на своих плечах чужие задачи.
Monkey Management, Servant Leadership, автономия сотрудников — это всё звучит классно, но как это выглядит на практике?
Узнаем на PeopleSense 2025!
Конфа специально для тех, кто управляет людьми и командами. Организаторы — те же ребята, кто делает топовую ProductSense.
Если вы тимлид, менеджер или хотите им стать — это точно для вас!
Примеры докладов:
📍 Как растить лидеров-решал? — Дмитрий Павлов
Очень интересно сравнить концепцию с Servant Leadership и Monkey Management 🙂
📍 Менеджмент 18+: сотрудник — не ребенок, менеджер — не родитель — Антон Бевзюк
С Антоном мы вместе работали в Райфе, он построил там крутое скрам-сообщество, поэтому я ему доверяю и буду рад послушать доклад
📍 Как перейти от управления людьми к управлению работой — Алексей Пименов
Спикера и так все знают, чисто ради Алексея можно на конфы ходить
Всего будет 32 доклада и 20 мастер-классов
Даты: 19–20 мая, Москва
👉Подробности и расписание тут
В последних двух постах мы обсуждали, как лидеру управлять командой, а не таскать на своих плечах чужие задачи.
Monkey Management, Servant Leadership, автономия сотрудников — это всё звучит классно, но как это выглядит на практике?
Узнаем на PeopleSense 2025!
Конфа специально для тех, кто управляет людьми и командами. Организаторы — те же ребята, кто делает топовую ProductSense.
Если вы тимлид, менеджер или хотите им стать — это точно для вас!
Примеры докладов:
📍 Как растить лидеров-решал? — Дмитрий Павлов
Очень интересно сравнить концепцию с Servant Leadership и Monkey Management 🙂
📍 Менеджмент 18+: сотрудник — не ребенок, менеджер — не родитель — Антон Бевзюк
С Антоном мы вместе работали в Райфе, он построил там крутое скрам-сообщество, поэтому я ему доверяю и буду рад послушать доклад
📍 Как перейти от управления людьми к управлению работой — Алексей Пименов
Спикера и так все знают, чисто ради Алексея можно на конфы ходить
Всего будет 32 доклада и 20 мастер-классов
Даты: 19–20 мая, Москва
👉Подробности и расписание тут
👍6🔥6❤🔥2❤1
«Мы — молодцы, они — идиоты»
Наверняка вы встречали это на работе:
— Заказчики сами не понимают, чего хотят, ставят нереалистичные задачи и постоянно меняют требования.
— Продакты уверены, что разработчики усложняют ради «красивой архитектуры и постоянно факапят сроки.
— Команда фронта думает, что бэкенд тормозит работу, а бэкенд считает, что фронт не способен сформулировать задачу внятно.
Это явление называется ингрупповой фаворитизм — устаревшая прошивка нашего мозга, доставшаяся от предков.
Когда-то конкуренция между группами обеспечивала выживание:
— «Мы» — своё племя, источник еды, тепла и безопасности. Умные, компетентные, правильные.
— «Они» — чужие, соперники за ресурсы, от которых нужно защищаться. Ленивые, глупые, опасные.
Сегодня ресурсы стали доступнее, но мозг за 100 000 лет привык видеть мир через эту оптику:
— Подсознательно мы боимся потерять работу, статус и деньги — «стать бомжом и умереть под мостом от голода».
— Мы конкурируем за зарплату, повышение и статус.
— Проще сплотить команду, найдя «общего врага», чем честно признать свои ошибки или сложности.
Эксперимент «Летний лагерь» (1954 год):
Группу 11-летних мальчиков разделили на две команды в летнем лагере и устроили между ними соревнования.
Почти сразу между командами начались конфликты:
— Они обзывались, придумывали друг другу обидные прозвища.
— Начали портить вещи соперников и даже драться.
Главное открытие:
Это же часто происходит и на работе.
Почему это плохо?
Когда мы делим мир на «умные мы и глупые они»:
— Вместо решения задач, ищем виноватых.
— Исчезает взаимопонимание и падает продуктивность.
— Рабочая атмосфера становится токсичной.
— Мы перестаём учиться и развиваться, считая себя и так молодцами.
Старая прошивка мешает нам в современном мире.
Что делать?
Первая реакция на чужое действие обычно негативная, и мы редко задумываемся о позитивных намерениях других.
Но чаще всего за любыми действиями стоит позитивное намерение — важно научиться его видеть.
Попробуйте вместо обвинений задать себе вопросы:
✅ Какую позитивную цель преследуют эти люди?
✅ Что они знают такого, чего не знаем мы?
✅ А вдруг это мы в чём-то ошибаемся?
Смените прошивку. Допустите, что они — не идиоты.
Конкретный пример: как это помогает в карьере
Разработчик получает нечёткое описание задачи от продакта. Первая реакция (старая прошивка): «Продакт не умеет нормально ставить задачи».
Старая прошивка:
— Раздражение и конфликты.
— Тратит время на споры.
— Продакт считает разработчика проблемным и избегает давать интересные задачи.
Новая прошивка:
Разработчик искренне пытается понять цель задачи, задаёт уточняющие вопросы. Возможно, продакт действительно не учёл важные технические детали.
Итог:
— Отношения с продактом укрепляются.
— Разработчик становится «тем самым человеком», с которым удобно работать.
— В перспективе он получает более интересные задачи и становится заметным в команде, что ускоряет карьерный рост.
———
Попробуйте предположить, что «они» — не идиоты. В современном мире это даёт гораздо больше долгосрочных выгод, чем наша устаревшая прошивка.
Наверняка вы встречали это на работе:
— Заказчики сами не понимают, чего хотят, ставят нереалистичные задачи и постоянно меняют требования.
— Продакты уверены, что разработчики усложняют ради «красивой архитектуры и постоянно факапят сроки.
— Команда фронта думает, что бэкенд тормозит работу, а бэкенд считает, что фронт не способен сформулировать задачу внятно.
Это явление называется ингрупповой фаворитизм — устаревшая прошивка нашего мозга, доставшаяся от предков.
Когда-то конкуренция между группами обеспечивала выживание:
— «Мы» — своё племя, источник еды, тепла и безопасности. Умные, компетентные, правильные.
— «Они» — чужие, соперники за ресурсы, от которых нужно защищаться. Ленивые, глупые, опасные.
Сегодня ресурсы стали доступнее, но мозг за 100 000 лет привык видеть мир через эту оптику:
— Подсознательно мы боимся потерять работу, статус и деньги — «стать бомжом и умереть под мостом от голода».
— Мы конкурируем за зарплату, повышение и статус.
— Проще сплотить команду, найдя «общего врага», чем честно признать свои ошибки или сложности.
Эксперимент «Летний лагерь» (1954 год):
Группу 11-летних мальчиков разделили на две команды в летнем лагере и устроили между ними соревнования.
Почти сразу между командами начались конфликты:
— Они обзывались, придумывали друг другу обидные прозвища.
— Начали портить вещи соперников и даже драться.
Главное открытие:
Чтобы разгорелся конфликт, было достаточно, чтобы одна группа увидела другую как соперника. Никаких других поводов не требовалось.
Это же часто происходит и на работе.
Почему это плохо?
Когда мы делим мир на «умные мы и глупые они»:
— Вместо решения задач, ищем виноватых.
— Исчезает взаимопонимание и падает продуктивность.
— Рабочая атмосфера становится токсичной.
— Мы перестаём учиться и развиваться, считая себя и так молодцами.
Старая прошивка мешает нам в современном мире.
Что делать?
Первая реакция на чужое действие обычно негативная, и мы редко задумываемся о позитивных намерениях других.
Но чаще всего за любыми действиями стоит позитивное намерение — важно научиться его видеть.
Попробуйте вместо обвинений задать себе вопросы:
✅ Какую позитивную цель преследуют эти люди?
✅ Что они знают такого, чего не знаем мы?
✅ А вдруг это мы в чём-то ошибаемся?
Смените прошивку. Допустите, что они — не идиоты.
Конкретный пример: как это помогает в карьере
Разработчик получает нечёткое описание задачи от продакта. Первая реакция (старая прошивка): «Продакт не умеет нормально ставить задачи».
Старая прошивка:
— Раздражение и конфликты.
— Тратит время на споры.
— Продакт считает разработчика проблемным и избегает давать интересные задачи.
Новая прошивка:
Разработчик искренне пытается понять цель задачи, задаёт уточняющие вопросы. Возможно, продакт действительно не учёл важные технические детали.
Итог:
— Отношения с продактом укрепляются.
— Разработчик становится «тем самым человеком», с которым удобно работать.
— В перспективе он получает более интересные задачи и становится заметным в команде, что ускоряет карьерный рост.
———
Попробуйте предположить, что «они» — не идиоты. В современном мире это даёт гораздо больше долгосрочных выгод, чем наша устаревшая прошивка.
Wikipedia
Внутригрупповой фаворитизм
Внутригрупповой фаворитизм (от греч. favor — благосклонность) , также ингрупповой фаворитизм, групповой фаворитизм — социально-психологический феномен, выражающийся в тенденции каким-либо образом содействовать членам собственной группы в противовес членам…
💯26❤14👍13❤🔥7🔥4👎1
🎯 Пособеситься — это тоже навык
Disclaimer: это реклама бесплатной консультации от Карьерного цеха
Раз в год-два я хожу на рынок «пособеситься». Не чтобы уходить, а чтобы свериться с реальностью: чего я стою, как звучит мой опыт, какие сейчас ожидания у компаний.
Но в этот раз нарушил правило, 3 года не практиковался.
И когда решил снова — понял, что растерял навык:
1. Меня не зовут
2. Не понимаю, кто я сейчас для рынка
3. Разучился внятно рассказывать про свой опыт
4. Неясно, как за 3 года изменились зарплаты
И тут приходит простая, но неприятная мысль:
собеседование — это экзамен.
Не самый честный и не самый логичный, но экзамен.
А если ты давно не сдавал экзамены — можешь забыть, как это делается.
Чтобы понять, как вернуться в тонус, можно пойти на бесплатную консультацию в Карьерный Цех.
Карьерное сопровождение — это не волшебная таблетка. Просто нормальная, внятная точка входа, где помогут:
1. Разобраться, как вы выглядите для рынка сейчас.
2. Оценить навыки, сильные стороны и карьерные цели.
3. Понять, как упаковать опыт и где зарыты карьерные возможности.
Если дальше захотите сопровождение — можно будет вписаться. А если нет — просто уйдёте с пониманием, куда двигаться и как.
👉 Записаться на бесплатную консультацию
Реклама. ИП Федоров Е.П.
ИНН 532008901966
Disclaimer: это реклама бесплатной консультации от Карьерного цеха
Раз в год-два я хожу на рынок «пособеситься». Не чтобы уходить, а чтобы свериться с реальностью: чего я стою, как звучит мой опыт, какие сейчас ожидания у компаний.
Но в этот раз нарушил правило, 3 года не практиковался.
И когда решил снова — понял, что растерял навык:
1. Меня не зовут
2. Не понимаю, кто я сейчас для рынка
3. Разучился внятно рассказывать про свой опыт
4. Неясно, как за 3 года изменились зарплаты
И тут приходит простая, но неприятная мысль:
собеседование — это экзамен.
Не самый честный и не самый логичный, но экзамен.
А если ты давно не сдавал экзамены — можешь забыть, как это делается.
Чтобы понять, как вернуться в тонус, можно пойти на бесплатную консультацию в Карьерный Цех.
Карьерное сопровождение — это не волшебная таблетка. Просто нормальная, внятная точка входа, где помогут:
1. Разобраться, как вы выглядите для рынка сейчас.
2. Оценить навыки, сильные стороны и карьерные цели.
3. Понять, как упаковать опыт и где зарыты карьерные возможности.
Если дальше захотите сопровождение — можно будет вписаться. А если нет — просто уйдёте с пониманием, куда двигаться и как.
👉 Записаться на бесплатную консультацию
Реклама. ИП Федоров Е.П.
ИНН 532008901966
careerfactory.ru
Приведём за руку к новой работе с высокой зарплатой -- Карьерное сопровождение
Сопровождение для продактов, дизайнеров, продуктовых аналитиков, менеджеров проектов и маркетологов.
👍15❤2
5 Уровней автономности сотрудника
В прошлых постах я рассказывал, почему менеджеру не стоит забирать задачи сотрудников. Теперь рассмотрим этот вопрос с другой стороны:
Как сотруднику понять, с какими задачами идти к тимлиду, а какие решать самостоятельно?
Всё в той же статье HBR про «обезьяний менеджмент» выделяют 5 уровней автономности сотрудника.
Чем выше ваш уровень автономности, тем больше вам доверяют, тем интереснее задачи вы получаете и тем быстрее растёте карьерно.
1️⃣ Ждать указаний
— Вы не делаете ничего, пока менеджер не скажет конкретно, что и как делать.
— Инициатива и ответственность полностью на менеджере.
2️⃣ Спрашивать, как поступить
— У вас есть варианты решения, но вы ждёте, пока менеджер выберет один из них.
— Финальная ответственность на менеджере.
3️⃣ Консультироваться, затем действовать
— Вы самостоятельно придумываете решение, обсуждаете с менеджером и действуете, убедившись, что он не против.
— Ответственность уже ваша, менеджер только консультирует.
4️⃣ Действовать и сообщать о результате
— Вы самостоятельно принимаете решение, действуете, а менеджеру просто сообщаете, что именно сделали.
— Ответственность и инициатива полностью ваша, менеджер лишь информирован.
5️⃣ Действовать полностью автономно
— Вы полностью самостоятельны и берёте ответственность за задачи без обязательного уведомления менеджера.
— Обычно это область, где у вас максимальная экспертиза и полное доверие руководителя.
Пример:
Новая фича требует переделки архитектуры.
🔴 Уровень 1:
«Без тебя никак, скажи, что нам делать?»
🟠 Уровень 2:
«Есть два варианта, скажи, какой выбрать?»
⚪ Уровень 3:
«Подготовил пару решений, склоняюсь к первому. Хочу убедиться, что не упустил чего-то важного.»
🔵 Уровень 4:
«Мы обсудили и решили переделать архитектуру так-то и так-то. Работа уже идёт.»
🟢 Уровень 5:
«Переделали архитектуру, всё работает. Захочешь посмотреть — приходи.»
🛠️ Как применить модель на практике?
1. Обсудите с тимлидом текущий уровень автономности и комфортный для вас и команды следующий шаг.
2. Постепенно поднимайтесь: от «спрашивать, как поступить» до «действовать и сообщать» и далее.
3. Чем выше ваша автономность, тем больше свободы действий, интереснее задачи и заметнее вклад в общий результат.
Сотрудники с высоким уровнем автономности чаще получают продвижение, становятся ключевыми экспертами и делают карьеру быстрее.
📌 Важно помнить, что уровни автономности не фиксированы навсегда и зависят от конкретной задачи и вашего опыта в ней.
Поделитесь в комментариях, на каком уровне чаще всего вы работаете сейчас?
В прошлых постах я рассказывал, почему менеджеру не стоит забирать задачи сотрудников. Теперь рассмотрим этот вопрос с другой стороны:
Как сотруднику понять, с какими задачами идти к тимлиду, а какие решать самостоятельно?
Всё в той же статье HBR про «обезьяний менеджмент» выделяют 5 уровней автономности сотрудника.
Чем выше ваш уровень автономности, тем больше вам доверяют, тем интереснее задачи вы получаете и тем быстрее растёте карьерно.
1️⃣ Ждать указаний
— Вы не делаете ничего, пока менеджер не скажет конкретно, что и как делать.
— Инициатива и ответственность полностью на менеджере.
2️⃣ Спрашивать, как поступить
— У вас есть варианты решения, но вы ждёте, пока менеджер выберет один из них.
— Финальная ответственность на менеджере.
3️⃣ Консультироваться, затем действовать
— Вы самостоятельно придумываете решение, обсуждаете с менеджером и действуете, убедившись, что он не против.
— Ответственность уже ваша, менеджер только консультирует.
4️⃣ Действовать и сообщать о результате
— Вы самостоятельно принимаете решение, действуете, а менеджеру просто сообщаете, что именно сделали.
— Ответственность и инициатива полностью ваша, менеджер лишь информирован.
5️⃣ Действовать полностью автономно
— Вы полностью самостоятельны и берёте ответственность за задачи без обязательного уведомления менеджера.
— Обычно это область, где у вас максимальная экспертиза и полное доверие руководителя.
Пример:
Новая фича требует переделки архитектуры.
🔴 Уровень 1:
«Без тебя никак, скажи, что нам делать?»
🟠 Уровень 2:
«Есть два варианта, скажи, какой выбрать?»
⚪ Уровень 3:
«Подготовил пару решений, склоняюсь к первому. Хочу убедиться, что не упустил чего-то важного.»
🔵 Уровень 4:
«Мы обсудили и решили переделать архитектуру так-то и так-то. Работа уже идёт.»
🟢 Уровень 5:
«Переделали архитектуру, всё работает. Захочешь посмотреть — приходи.»
🛠️ Как применить модель на практике?
1. Обсудите с тимлидом текущий уровень автономности и комфортный для вас и команды следующий шаг.
2. Постепенно поднимайтесь: от «спрашивать, как поступить» до «действовать и сообщать» и далее.
3. Чем выше ваша автономность, тем больше свободы действий, интереснее задачи и заметнее вклад в общий результат.
Сотрудники с высоким уровнем автономности чаще получают продвижение, становятся ключевыми экспертами и делают карьеру быстрее.
📌 Важно помнить, что уровни автономности не фиксированы навсегда и зависят от конкретной задачи и вашего опыта в ней.
Поделитесь в комментариях, на каком уровне чаще всего вы работаете сейчас?
Telegram
Product Developer
🐒 Обезьяний менеджмент
Ситуация: тимлид приходит на работу в отличном настроении, готовый спокойно разобраться с важными задачами.
Но тут к нему подходит разработчик и говорит:
— Есть одна проблема, нужна твоя помощь.
Тимлид отвечает:
— Ок, посмотрю позже.…
Ситуация: тимлид приходит на работу в отличном настроении, готовый спокойно разобраться с важными задачами.
Но тут к нему подходит разработчик и говорит:
— Есть одна проблема, нужна твоя помощь.
Тимлид отвечает:
— Ок, посмотрю позже.…
👍35🔥10🌚4👎2❤1
Alexcouncil⚡
Календарь задач
Уже лет двести я использую календарь в работе над задачами.
Как это работает:
- есть список задач где-то в таблице, таск трекере, канбан доске, неважно
- список разбит на приоритеты и критичность
- задачи бьются на подзадачи
- ближайшие по времени подзадачи вносятся в календарь временными слотами
Далее ты миллион раз на день заходишь в календарь смотреть встречи и понимаешь, что у тебя "встреча" с какой-то подзадачей.
Почему к этому пришел
Потому что в любом случае тебе нужно время как ресурс. Его планирование происходит в одном месте - календаре. В это место ты часто возвращаешься и видишь, что надо сделать определенную штуку в определенный момент. Просто и понятно.
Уже лет двести я использую календарь в работе над задачами.
Как это работает:
- есть список задач где-то в таблице, таск трекере, канбан доске, неважно
- список разбит на приоритеты и критичность
- задачи бьются на подзадачи
- ближайшие по времени подзадачи вносятся в календарь временными слотами
Далее ты миллион раз на день заходишь в календарь смотреть встречи и понимаешь, что у тебя "встреча" с какой-то подзадачей.
Почему к этому пришел
Потому что в любом случае тебе нужно время как ресурс. Его планирование происходит в одном месте - календаре. В это место ты часто возвращаешься и видишь, что надо сделать определенную штуку в определенный момент. Просто и понятно.
———
📝Встреча с задачей📝
У меня есть боль: между встречами — разрывы по 30–60 минут, в которых вроде бы можно что-то сделать…
Но сил нет, фокус не включается, а к вечеру смотрю на список задач и думаю: «ну вот, снова ничего не успел».
Хотя список задач есть. Он даже приоритизирован. Но до него руки не доходят, пока задачи не становятся срочными. А если и доходят — уходит время на разогрев.
Недавно попробовал странно простую вещь: ставить задачи в календарь.
Прямо как встречи.
🔹 Так у задачи появляется конкретный слот времени — в него уже не влезет ещё один созвон.
🔹 Есть напоминалка за 15 минут до «встречи», помогает настроиться на задачу.
🔹 И, внезапно, появляется лёгкое чувство неловкости, если в этот слот делаешь не то.
Как будто прогуливаешь встречу с собой.
Инсайт этот не мой — наткнулся на пост Алексея Арефьева, автора канала @alexcouncil.
Суть простая:
Задачи — это тоже встречи. Только с собой.
Плюс — можно использовать цвета, чтобы понимать тип активности с первого взгляда:
🟢 регулярки, 🔴 разовые встречи, 🔵 задачи.
Я пока только начал пробовать — но кажется, это лучшее, что случалось с моим фокусом с начала года.
Давно читаю канал Алексея. Там еще и мемчики есть. Подписывайтесь 🙂
📝Встреча с задачей📝
У меня есть боль: между встречами — разрывы по 30–60 минут, в которых вроде бы можно что-то сделать…
Но сил нет, фокус не включается, а к вечеру смотрю на список задач и думаю: «ну вот, снова ничего не успел».
Хотя список задач есть. Он даже приоритизирован. Но до него руки не доходят, пока задачи не становятся срочными. А если и доходят — уходит время на разогрев.
Недавно попробовал странно простую вещь: ставить задачи в календарь.
Прямо как встречи.
🔹 Так у задачи появляется конкретный слот времени — в него уже не влезет ещё один созвон.
🔹 Есть напоминалка за 15 минут до «встречи», помогает настроиться на задачу.
🔹 И, внезапно, появляется лёгкое чувство неловкости, если в этот слот делаешь не то.
Как будто прогуливаешь встречу с собой.
Инсайт этот не мой — наткнулся на пост Алексея Арефьева, автора канала @alexcouncil.
Суть простая:
Задачи — это тоже встречи. Только с собой.
Плюс — можно использовать цвета, чтобы понимать тип активности с первого взгляда:
🟢 регулярки, 🔴 разовые встречи, 🔵 задачи.
Я пока только начал пробовать — но кажется, это лучшее, что случалось с моим фокусом с начала года.
Давно читаю канал Алексея. Там еще и мемчики есть. Подписывайтесь 🙂
👍27🔥12❤3
Почему люди не оправдывают наших ожиданий?
Когда коллега не делает задачу или делает её совсем не так, первая реакция обычно негативная:
На самом деле причин гораздо больше. И чаще всего дело не в равнодушии.
Каждый может накосячить и сделать всё не так, не то, не вовремя или не того качества.
При этом у самого «накосячившего» может быть ощущение, что он всё сделал как договаривались.
Есть 4 основные причины, почему кто-то не оправдал наших ожиданий:
1️⃣ Не понял (или понял по-своему)
Вы вроде бы всё объяснили, но человек услышал что-то другое и начал делать не то.
Почему это происходит:
— Недостаточно чётко сформулировали задачу.
— Не убедились, что поняли друг друга.
— Коллега постеснялся переспросить.
📌 Как проверить: попросите пересказать задачу своими словами и убедитесь, что поняли друг друга одинаково.
(Кстати, это полезно и в случаях сложного фидбека.)
2️⃣ Не умеет
Человек отлично понял, что от него требуется, но не знает, как это делать.
Что пошло не так:
— Задача оказалась новой для него.
— Он постеснялся признаться, что не умеет.
— Вы переоценили его опыт и знания.
📌 Как проверить: просто спросите, решал ли он похожие задачи раньше и как именно собирается действовать.
© Ваш Капитан Очевидность.
3️⃣ Не может
Коллега понял и умеет делать задачу, но у него физически нет такой возможности.
Например:
— Завален другими задачами и банально нет времени.
— Нет нужных доступов или инструментов.
— Задача заблокирована другими людьми или командами.
📌 Как проверить: уточните, есть ли у него всё необходимое и не блокирует ли его кто-то другой.
4️⃣ Не хочет
Самая редкая причина, хотя именно её чаще всего подозревают.
Почему человек может не хотеть делать задачу:
— Она кажется ему бессмысленной.
— Он не видит в ней личной выгоды или интереса.
— У него есть скрытый конфликт или негатив к вам, команде или компании.
📌 Как проверить: откровенно обсудите мотивацию и ценность задачи для него. Но это отдельная большая тема, и одним разговором не решить.
Почему важно разбираться в причинах?
Если сразу списывать всё на равнодушие и лень, отношения будут портиться, а задачи так и не начнут выполняться лучше.
Если же начнёте разбираться, то:
✅ Чаще реальность станет совпадать с ожиданиями.
✅ Лучше поймёте мотивы и трудности коллег.
✅ Научитесь чётче ставить задачи, что сделает всю команду сильнее.
В следующий раз, когда кто-то не оправдает ваших ожиданий, попробуйте этот фреймворк:
1. Не понял?
2. Не умеет?
3. Не может?
4. Не хочет?
———
Я сейчас прохожу 9-месячный курс Стратоплана, и этот пост навеян одной из их тем. Вот ссылка на статью с примерами.
Давайте обсудим в комментариях:
Какие были у вас самые кринжовые ситуации неоправданных ожиданий? 😅
Когда коллега не делает задачу или делает её совсем не так, первая реакция обычно негативная:
«Ну понятно, опять ему всё равно. Не старается, наплевательски относится».
На самом деле причин гораздо больше. И чаще всего дело не в равнодушии.
Каждый может накосячить и сделать всё не так, не то, не вовремя или не того качества.
При этом у самого «накосячившего» может быть ощущение, что он всё сделал как договаривались.
Есть 4 основные причины, почему кто-то не оправдал наших ожиданий:
1️⃣ Не понял (или понял по-своему)
Вы вроде бы всё объяснили, но человек услышал что-то другое и начал делать не то.
Почему это происходит:
— Недостаточно чётко сформулировали задачу.
— Не убедились, что поняли друг друга.
— Коллега постеснялся переспросить.
📌 Как проверить: попросите пересказать задачу своими словами и убедитесь, что поняли друг друга одинаково.
(Кстати, это полезно и в случаях сложного фидбека.)
2️⃣ Не умеет
Человек отлично понял, что от него требуется, но не знает, как это делать.
Что пошло не так:
— Задача оказалась новой для него.
— Он постеснялся признаться, что не умеет.
— Вы переоценили его опыт и знания.
📌 Как проверить: просто спросите, решал ли он похожие задачи раньше и как именно собирается действовать.
© Ваш Капитан Очевидность.
3️⃣ Не может
Коллега понял и умеет делать задачу, но у него физически нет такой возможности.
Например:
— Завален другими задачами и банально нет времени.
— Нет нужных доступов или инструментов.
— Задача заблокирована другими людьми или командами.
📌 Как проверить: уточните, есть ли у него всё необходимое и не блокирует ли его кто-то другой.
4️⃣ Не хочет
Самая редкая причина, хотя именно её чаще всего подозревают.
Почему человек может не хотеть делать задачу:
— Она кажется ему бессмысленной.
— Он не видит в ней личной выгоды или интереса.
— У него есть скрытый конфликт или негатив к вам, команде или компании.
📌 Как проверить: откровенно обсудите мотивацию и ценность задачи для него. Но это отдельная большая тема, и одним разговором не решить.
Почему важно разбираться в причинах?
Если сразу списывать всё на равнодушие и лень, отношения будут портиться, а задачи так и не начнут выполняться лучше.
Если же начнёте разбираться, то:
✅ Чаще реальность станет совпадать с ожиданиями.
✅ Лучше поймёте мотивы и трудности коллег.
✅ Научитесь чётче ставить задачи, что сделает всю команду сильнее.
В следующий раз, когда кто-то не оправдает ваших ожиданий, попробуйте этот фреймворк:
1. Не понял?
2. Не умеет?
3. Не может?
4. Не хочет?
———
Я сейчас прохожу 9-месячный курс Стратоплана, и этот пост навеян одной из их тем. Вот ссылка на статью с примерами.
Давайте обсудим в комментариях:
Какие были у вас самые кринжовые ситуации неоправданных ожиданий? 😅
👍51🔥19💯10❤3
Technical Product Manager — редкий зверь
Представьте, что вы — продакт, отвечающий за развитие… русского языка.
Какие у вас цели? Улучшить UX? Сократить технический долг? Убрать букву «ы»?
Как собрать фидбэк? Как мерить метрики?
Артём руководит продуктовым офисом в Яндексе и делает платформу для разработчиков.
Его команда решает похожие задачи — только не с алфавитом, а с языками программирования, процессами разработки и внутренними инструментами.
Я читаю его канал @badtechproject, потому что он пишет про сложные вещи без буллшита. Вот несколько постов, которые особенно зацепили:
🛠 Про систем-дизайн на собесах
Артём вводит систем-дизайн как обязательную часть интервью для project-менеджеров. И это логично: если ты управляешь командой, неплохо бы понимать, как устроена система. В посте — разминка «спроектируй Twitter», советы и книга, которую стоит прочитать, даже если ты не инженер.
💬 Про "интервью наоборот"
Хороший чеклист «О чем спросить работодателя». Артём так же считает, что хорошее собеседование — это разговор двух взрослых людей, а не экзамен. И умение задавать вопросы — это навык, который повышает шансы получить сильную команду, а не просто оффер.
🔥 Про выгорание — в формате вредных советов
Очень жизненно. Я нашёл там пару пунктов, по которым проходил лично. Формат ироничный, но содержательный: как раз для тех, кто не любит душных лекций про баланс и ресурсное состояние.
Если вы project, product или тимлид и хотите:
— лучше понимать технику,
— разбираться в процессе найма,
— не выгореть в попытке быть идеальным,
подписывайтесь на @badtechproject. Канал — живой, честный и с пользой.
Представьте, что вы — продакт, отвечающий за развитие… русского языка.
Какие у вас цели? Улучшить UX? Сократить технический долг? Убрать букву «ы»?
Как собрать фидбэк? Как мерить метрики?
Артём руководит продуктовым офисом в Яндексе и делает платформу для разработчиков.
Его команда решает похожие задачи — только не с алфавитом, а с языками программирования, процессами разработки и внутренними инструментами.
Я читаю его канал @badtechproject, потому что он пишет про сложные вещи без буллшита. Вот несколько постов, которые особенно зацепили:
🛠 Про систем-дизайн на собесах
Артём вводит систем-дизайн как обязательную часть интервью для project-менеджеров. И это логично: если ты управляешь командой, неплохо бы понимать, как устроена система. В посте — разминка «спроектируй Twitter», советы и книга, которую стоит прочитать, даже если ты не инженер.
💬 Про "интервью наоборот"
Хороший чеклист «О чем спросить работодателя». Артём так же считает, что хорошее собеседование — это разговор двух взрослых людей, а не экзамен. И умение задавать вопросы — это навык, который повышает шансы получить сильную команду, а не просто оффер.
🔥 Про выгорание — в формате вредных советов
Очень жизненно. Я нашёл там пару пунктов, по которым проходил лично. Формат ироничный, но содержательный: как раз для тех, кто не любит душных лекций про баланс и ресурсное состояние.
Если вы project, product или тимлид и хотите:
— лучше понимать технику,
— разбираться в процессе найма,
— не выгореть в попытке быть идеальным,
подписывайтесь на @badtechproject. Канал — живой, честный и с пользой.
Telegram
Плохой Project
🐦«Спроектируйте мне Twitter»
⚡️Project, работающий в ИТ организации должен разбираться в том, как проектировать системы.
Ага, именно так, «безапелляционно».
К примеру, нужно понимать, что любой Message Broker (IBM MQ, Kafka и прочее) используются в качестве…
⚡️Project, работающий в ИТ организации должен разбираться в том, как проектировать системы.
Ага, именно так, «безапелляционно».
К примеру, нужно понимать, что любой Message Broker (IBM MQ, Kafka и прочее) используются в качестве…
👍11❤4🤣3
Disagree and Commit
Disclaimer: тема спорная, мнение непопулярное, призываю к срачу в комментах 🙂
Ситуация:
На встрече обсуждают подход к сложной задаче.
Один из разработчиков считает, что идея плохая. Он аргументирует, предлагает альтернативы. Но команда (или руководитель) выбирает другой вариант.
Какие есть варианты поведения?
Вариант 1. Сделать «по кривому ТЗ», чтобы потом сказать: «Ну, я предупреждал»
На первый взгляд, выглядит логично: разработчик честно указал на проблему, а теперь просто делает работу как ему сказали.
Но на деле это превращается в психологическую игру по Эрику Берну — «А я же говорил»:
— Человек берёт задачу в работу без желания и делает минимально, без инициативы.
— Малейшие трудности и не предусмотренные при обсуждении проблемы он не решает, а использует как лишний аргумент против принятого решения.
— Подсознательно он ждёт неудачи, чтобы потом показать, что был прав («Ну что, кто теперь виноват?»).
В краткосрочной перспективе человек получает чувство превосходства и подтверждение своей правоты («психологическое поглаживание»).
Но доверие в команде портится, коллеги начинают воспринимать его как токсичного и несговорчивого.
Вариант 2. Продолжать спорить, пока не достигнут полного согласия
Звучит как зрелый подход: ведь все должны быть согласны, прежде чем двигаться дальше.
Но это часто ведет в «ловушку консенсуса»:
— Обсуждения становятся бесконечными, никто не хочет брать ответственность за финальное решение.
— В итоге команда договаривается о компромиссе, который никому не нравится до конца и даст хреновенький результат.
Вариант 3. Disagree and Commit — не согласен, но обязуюсь сделать
Amazon и другие компании используют подход Disagree and Commit, чтобы избежать первых двух проблем.
Подход простой:
1. Пока решение не принято — нужно спорить, задавать неудобные вопросы, предлагать альтернативы.
2. Когда решение принято — вся команда действует так, словно это решение было общим и наилучшим, даже если кто-то с ним не согласен:
«Я не согласен, но понимаю, почему выбрали этот вариант. Сделаю задачу максимально хорошо, как если бы сам был её сторонником».
Обе части критично важны:
Нужно открыто высказываться, спорить и аргументировать до принятия решения.
После принятия — брать ответственность за общий результат.
Подход не заработает, если в команде нет доверия и открытости (см пост про 5 пороков команды).
Профит:
🧠 Принимаем сильные решения, иногда непопулярные. Избегаем ловушки консенсуса и посредственных решений.
⏱️ Двигаемся вперёд, команда не буксует. Экономим время. Нет откатов и «давайте ещё подумаем».
🤝 Повышаем доверие. Умеем спорить — и умеем поддержать общее решение.
🔁 И главное: а вдруг ты не прав? Решение группы может оказаться лучше твоего. Это нормально.
Когда этот подход не работает?
— Если решения принимаются в стиле «я начальник — ты дурак».
— Если нет доверия, и люди боятся высказываться.
— Если ошибка критична и затрагивает безопасность, финансы или здоровье людей — в этом случае лучше спокойно эскалировать по фактам.
TL;DR:
— До принятия решения — спорим, аргументируем, ищем лучшее решение.
— После принятия — работаем как единая команда на общий результат.
— Не играем в «А я же говорил»: это портит отношения и разрушает доверие.
— Допускаем, что коллективное решение может быть лучше личного мнения одного человека.
Закидывайте в комменты свои истории из разряда «а я же говорил» 🙂
Disclaimer: тема спорная, мнение непопулярное, призываю к срачу в комментах 🙂
Ситуация:
На встрече обсуждают подход к сложной задаче.
Один из разработчиков считает, что идея плохая. Он аргументирует, предлагает альтернативы. Но команда (или руководитель) выбирает другой вариант.
Какие есть варианты поведения?
Вариант 1. Сделать «по кривому ТЗ», чтобы потом сказать: «Ну, я предупреждал»
На первый взгляд, выглядит логично: разработчик честно указал на проблему, а теперь просто делает работу как ему сказали.
Но на деле это превращается в психологическую игру по Эрику Берну — «А я же говорил»:
— Человек берёт задачу в работу без желания и делает минимально, без инициативы.
— Малейшие трудности и не предусмотренные при обсуждении проблемы он не решает, а использует как лишний аргумент против принятого решения.
— Подсознательно он ждёт неудачи, чтобы потом показать, что был прав («Ну что, кто теперь виноват?»).
В краткосрочной перспективе человек получает чувство превосходства и подтверждение своей правоты («психологическое поглаживание»).
Но доверие в команде портится, коллеги начинают воспринимать его как токсичного и несговорчивого.
Вариант 2. Продолжать спорить, пока не достигнут полного согласия
Звучит как зрелый подход: ведь все должны быть согласны, прежде чем двигаться дальше.
Но это часто ведет в «ловушку консенсуса»:
— Обсуждения становятся бесконечными, никто не хочет брать ответственность за финальное решение.
— В итоге команда договаривается о компромиссе, который никому не нравится до конца и даст хреновенький результат.
Вариант 3. Disagree and Commit — не согласен, но обязуюсь сделать
Amazon и другие компании используют подход Disagree and Commit, чтобы избежать первых двух проблем.
Подход простой:
1. Пока решение не принято — нужно спорить, задавать неудобные вопросы, предлагать альтернативы.
2. Когда решение принято — вся команда действует так, словно это решение было общим и наилучшим, даже если кто-то с ним не согласен:
«Я не согласен, но понимаю, почему выбрали этот вариант. Сделаю задачу максимально хорошо, как если бы сам был её сторонником».
Обе части критично важны:
Нужно открыто высказываться, спорить и аргументировать до принятия решения.
После принятия — брать ответственность за общий результат.
Подход не заработает, если в команде нет доверия и открытости (см пост про 5 пороков команды).
Профит:
🧠 Принимаем сильные решения, иногда непопулярные. Избегаем ловушки консенсуса и посредственных решений.
⏱️ Двигаемся вперёд, команда не буксует. Экономим время. Нет откатов и «давайте ещё подумаем».
🤝 Повышаем доверие. Умеем спорить — и умеем поддержать общее решение.
🔁 И главное: а вдруг ты не прав? Решение группы может оказаться лучше твоего. Это нормально.
Когда этот подход не работает?
— Если решения принимаются в стиле «я начальник — ты дурак».
— Если нет доверия, и люди боятся высказываться.
— Если ошибка критична и затрагивает безопасность, финансы или здоровье людей — в этом случае лучше спокойно эскалировать по фактам.
TL;DR:
— До принятия решения — спорим, аргументируем, ищем лучшее решение.
— После принятия — работаем как единая команда на общий результат.
— Не играем в «А я же говорил»: это портит отношения и разрушает доверие.
— Допускаем, что коллективное решение может быть лучше личного мнения одного человека.
Закидывайте в комменты свои истории из разряда «а я же говорил» 🙂
Telegram
Product Developer
Пять пороков команды
— это концепция пирамиды из книги Патрика Ленсиони Five Dysfunctions of a Team. Мне кажется, что cлово «порок» — не совсем корректная локализация, поэтому буду писать «дисфункция».
Пост получился объёмным, поэтому я его разделил на…
— это концепция пирамиды из книги Патрика Ленсиони Five Dysfunctions of a Team. Мне кажется, что cлово «порок» — не совсем корректная локализация, поэтому буду писать «дисфункция».
Пост получился объёмным, поэтому я его разделил на…
👍39❤19🔥10🤣2
🎭 Игры, в которые играют разработчики
В прошлом посте я привел пример игры «а я же говорил» — это одна из игр, описанных Эриком Берном в книге «Игры, в которые играют люди».
Когда читал, было странное чувство: как будто Берн писал не про абстрактную психотерапию, а про работу в команде разработчиков.
Это не игры ради веселья. Это поведенческие сценарии, в которых:
— есть знакомые роли (жертва, спасатель, агрессор),
— повторяются типовые ходы,
— а в финале всегда есть «выигрыш».
Что за «выигрыш»?
В русскоязычной литературе это называют «психологическим поглаживанием».
Мне больше нравится термин attention unit: единица внимания, подтверждающая наше существование.
Игры становятся способом стабильно зарабатывать поглаживания.
Примеры:
— «Я снова всех спас — значит, без меня не обойтись»
— «Я страдаю — значит, я важен»
— «Меня критикуют — значит, я всегда виноват»
То есть человек неосознанно воспроизводит игру, чтобы получить знакомое ощущение: вины, жалости, нужности, страха, контроля. Эмоционально это работает. Но для команды — разрушительно.
🧩 Распознавание этих игр и выход из них помогает в прокачке софт-скиллов:
— Рефлексия (заметить сценарий за собой)
— Эмпатия, эмоциональный интеллект (понять чувства под ролями, заметить игру со стороны)
— Ассертивность (выйти из позиции жертвы/героя)
— Фасилитация (увидеть и остановить игру)
Ниже — пример одной из самых частых игр в IT.
😩 Смотрите, как я страдаю
Сценарий:
Один человек делает всё сам. Не делится знаниями. Не просит помощи. Зашивается в задачах. Говорит: «так быстрее», «некому передать», «всё держится на мне».
Он не просит о помощи напрямую, а копит напряжение, чтобы потом предъявить. Иногда срывается на повышенных тонах, иногда — просто пассивно-агрессивно замолкает или уходит в обиду:
Выгода (поглаживание):
— Подтвердить, что он незаменим
— Получить сочувствие
— Манипулировать командой через вину
Как распознать:
— Никогда не просит о помощи — «сам всё сделаю»
— Делает больше, чем нужно, а потом обвиняет
— Может говорить: «Мне никто не помогает», хотя помощь предлагали
— Часто устал, но при этом демонстративно отказывается от отдыха
Как разорвать сценарий:
Коллегам и руководителю:
— Не подыгрывать чувству вины: «Я вижу, ты перегружен — но мы предлагали помощь»
— Сдвинуть в зону ответственности: «Что ты хочешь изменить?»
— Задать прямой вопрос: «Ты хочешь продолжать в этом ритме или распределим задачи?»
Игроку:
— Сказать: «Мне тяжело. Нужно перераспределить задачи»
— Написать доку, передать зону ответственности, уйти в отпуск
— Менторить коллег, делать задачи их руками
———
📚 У Берна десятки таких игр, некоторые пугающе узнаваемы. Книжка четко структурирована, одна игра занимает пару страниц. Поэтому читается легко и быстро. Рекомендасьон!
Если читали — напишите, какие еще наблюдали в работе?
Может быть, «Пни меня», «Теперь ты попался, сукин сын» или «Алкоголик»? 😄
В прошлом посте я привел пример игры «а я же говорил» — это одна из игр, описанных Эриком Берном в книге «Игры, в которые играют люди».
Когда читал, было странное чувство: как будто Берн писал не про абстрактную психотерапию, а про работу в команде разработчиков.
Это не игры ради веселья. Это поведенческие сценарии, в которых:
— есть знакомые роли (жертва, спасатель, агрессор),
— повторяются типовые ходы,
— а в финале всегда есть «выигрыш».
Что за «выигрыш»?
В русскоязычной литературе это называют «психологическим поглаживанием».
Мне больше нравится термин attention unit: единица внимания, подтверждающая наше существование.
В оригинале — strokes — единица социального/эмоционального признания:
“A stroke is a unit of recognition.”
Берн выбрал это слово, потому что исходно описывал физическое прикосновение (поглаживание) как форму признания младенца.
Отсюда и идея, что взрослые продолжают искать такие же «эмоциональные прикосновения» — в форме внимания, похвалы, критики, …
Игры становятся способом стабильно зарабатывать поглаживания.
Примеры:
— «Я снова всех спас — значит, без меня не обойтись»
— «Я страдаю — значит, я важен»
— «Меня критикуют — значит, я всегда виноват»
То есть человек неосознанно воспроизводит игру, чтобы получить знакомое ощущение: вины, жалости, нужности, страха, контроля. Эмоционально это работает. Но для команды — разрушительно.
🧩 Распознавание этих игр и выход из них помогает в прокачке софт-скиллов:
— Рефлексия (заметить сценарий за собой)
— Эмпатия, эмоциональный интеллект (понять чувства под ролями, заметить игру со стороны)
— Ассертивность (выйти из позиции жертвы/героя)
— Фасилитация (увидеть и остановить игру)
Ниже — пример одной из самых частых игр в IT.
😩 Смотрите, как я страдаю
Сценарий:
Один человек делает всё сам. Не делится знаниями. Не просит помощи. Зашивается в задачах. Говорит: «так быстрее», «некому передать», «всё держится на мне».
Он не просит о помощи напрямую, а копит напряжение, чтобы потом предъявить. Иногда срывается на повышенных тонах, иногда — просто пассивно-агрессивно замолкает или уходит в обиду:
«Я тут один всё делаю!»
«Вы даже не замечаете, сколько я вкладываю!»
«Разгребать, конечно, как всегда всё мне!»
Выгода (поглаживание):
— Подтвердить, что он незаменим
— Получить сочувствие
— Манипулировать командой через вину
Как распознать:
— Никогда не просит о помощи — «сам всё сделаю»
— Делает больше, чем нужно, а потом обвиняет
— Может говорить: «Мне никто не помогает», хотя помощь предлагали
— Часто устал, но при этом демонстративно отказывается от отдыха
Как разорвать сценарий:
Коллегам и руководителю:
— Не подыгрывать чувству вины: «Я вижу, ты перегружен — но мы предлагали помощь»
— Сдвинуть в зону ответственности: «Что ты хочешь изменить?»
— Задать прямой вопрос: «Ты хочешь продолжать в этом ритме или распределим задачи?»
Игроку:
— Сказать: «Мне тяжело. Нужно перераспределить задачи»
— Написать доку, передать зону ответственности, уйти в отпуск
— Менторить коллег, делать задачи их руками
———
📚 У Берна десятки таких игр, некоторые пугающе узнаваемы. Книжка четко структурирована, одна игра занимает пару страниц. Поэтому читается легко и быстро. Рекомендасьон!
Если читали — напишите, какие еще наблюдали в работе?
Может быть, «Пни меня», «Теперь ты попался, сукин сын» или «Алкоголик»? 😄
🔥25👍12❤7🌚2👎1