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? 😏
Софты нужны тем, у кого не всё в порядке с хардами
… Болтать — не мешки ворочать! Лучше б делом занялись.
В IT ты крутой эксперт, если глубоко разбираешься в технологиях: умеешь шардировать БД, оптимизировать SQL запросы, тушить пожары на проде.
А всё остальное, особенно те самые «софт-скиллы», многие считают чем-то второстепенным.
Ну, типа… харизма, характер, общительность, презентации… менеджерская фигня, короче.
У меня был знакомый тимлид, который думал именно так.
И вот как-то в его команде сеньор-инженер три месяца упорно трудился, пилил мегасложную фичу, но про статус работы особо никому не рассказывал. Тимлид тоже не любил лезть с «глупыми вопросами», он и так видел все коммиты и думал: «Всё под контролем, что может пойти не так?»
За пару дней до релиза оказалось, что сеньор прекрасно решил задачу. Но не ту, что просил бизнес. Да и архитектура была красивая, мощная и совершенно несовместимая с текущим продом.
Тимлид не растерялся и решил проблему единственно правильным способом:
Он лично сел и идеально переписал весь код за выходные, согласовал изменения с бизнесом, и даже потратил ещё несколько ночей на деплой и поддержку после релиза. Ну да, немножечко переработал, но зато всё идеально.
А что сеньор?
Сеньора уволили, а вместо него наняли другого.
Теперь уже такого, который умеет и требования согласовать, и статус по задачам регулярно давать, и риски озвучивать.
И тимлида потом тоже уволили, потому что он все пожары тушил сам и в итоге не справился. А вместо него наняли другого.
Который умеет управлять рисками, делегировать и доносить обратную связь.
Стоп. Это же были не софты, правда?
———
Это была затравочка из лонгрида, который я написал для очередного бесплатного марафона Стратоплана.
Всего будет 10 таких «вредных советов» — в формате лонгридов и 30-минутных вечерних эфиров.
Начинаем сегодня.
Примеры тем:
– делай всё сразу: кто сказал, что многозадачность неэффективна?
– кому надо, тот поймет. Никогда не давайте обратную связь
– планировать — это для средних умов, гении господствуют над хаосом
Вместе со мной будут тренеры Стратоплана и авторы тг-каналов: Евгений Антонов, Роман Ивлиев, Ольга Елисеева, и еще множество тех, кого вы, возможно, читаете.
p.s. Пару лет назад и представить себе не мог, что буду частью Стратоплана!
Регистрация тут. Бесплатно.
… Болтать — не мешки ворочать! Лучше б делом занялись.
В IT ты крутой эксперт, если глубоко разбираешься в технологиях: умеешь шардировать БД, оптимизировать SQL запросы, тушить пожары на проде.
А всё остальное, особенно те самые «софт-скиллы», многие считают чем-то второстепенным.
Ну, типа… харизма, характер, общительность, презентации… менеджерская фигня, короче.
У меня был знакомый тимлид, который думал именно так.
И вот как-то в его команде сеньор-инженер три месяца упорно трудился, пилил мегасложную фичу, но про статус работы особо никому не рассказывал. Тимлид тоже не любил лезть с «глупыми вопросами», он и так видел все коммиты и думал: «Всё под контролем, что может пойти не так?»
За пару дней до релиза оказалось, что сеньор прекрасно решил задачу. Но не ту, что просил бизнес. Да и архитектура была красивая, мощная и совершенно несовместимая с текущим продом.
Тимлид не растерялся и решил проблему единственно правильным способом:
Он лично сел и идеально переписал весь код за выходные, согласовал изменения с бизнесом, и даже потратил ещё несколько ночей на деплой и поддержку после релиза. Ну да, немножечко переработал, но зато всё идеально.
А что сеньор?
Сеньора уволили, а вместо него наняли другого.
Теперь уже такого, который умеет и требования согласовать, и статус по задачам регулярно давать, и риски озвучивать.
И тимлида потом тоже уволили, потому что он все пожары тушил сам и в итоге не справился. А вместо него наняли другого.
Который умеет управлять рисками, делегировать и доносить обратную связь.
Стоп. Это же были не софты, правда?
———
Это была затравочка из лонгрида, который я написал для очередного бесплатного марафона Стратоплана.
Всего будет 10 таких «вредных советов» — в формате лонгридов и 30-минутных вечерних эфиров.
Начинаем сегодня.
Примеры тем:
– делай всё сразу: кто сказал, что многозадачность неэффективна?
– кому надо, тот поймет. Никогда не давайте обратную связь
– планировать — это для средних умов, гении господствуют над хаосом
Вместе со мной будут тренеры Стратоплана и авторы тг-каналов: Евгений Антонов, Роман Ивлиев, Ольга Елисеева, и еще множество тех, кого вы, возможно, читаете.
p.s. Пару лет назад и представить себе не мог, что буду частью Стратоплана!
Регистрация тут. Бесплатно.
Школа менеджмента STRATOPLAN
Вредные привычки, мешающие вашей карьере - Открытый марафон
10 привычек, тормозящих ваш карьерный и личностный рост
🎧 Сходил в подкаст Frontend Weekend к Андрею Смирнову!
Разговор получился глубокий, душевный и очень личный. Обсудили мой карьерный путь, переезд в Испанию, ведение телеграм-канала и даже немного про Digital Nomad и жизнь в Испании.
Отдельно хочу поделиться темой, которая для меня самого сейчас особенно актуальна:
Менеджер или индивидуальный контрибьютор?
Последние 2 года в Авито я руководил юнитом, а недавно стал руководителем кластера.
Работа менеджером мне действительно нравится, но я не считаю зазорным или странным снова вернуться в разработку.
Почему? Потому что, когда ты инженер, у тебя каждый день есть возможность получать удовольствие от быстрых и понятных результатов.
Вот ты написал код, отладил — работает! Сразу получил обратную связь и дофамин.
Чего-то не было — благодаря тебе теперь есть. Ты создал. Ты — созидатель.
Это мгновенная радость от понятного и ощутимого результата.
У менеджера всё не так. Результаты твоих решений и действий проявляются через месяцы, а иногда и полгода спустя.
И чтобы увидеть их и порадоваться, нужно прилагать отдельные усилия и специально рефлексировать.
Многие разработчики по инерции становятся тимлидами, не до конца понимая, что это совсем другая роль с другими правилами игры. Я очень рекомендую задуматься, подходит ли она вам, или вы просто следуете общепринятому карьерному росту.
Выбор «менеджер или инженер» — это не про статус, а про то, какую работу ты больше любишь делать и от чего получаешь удовольствие.
———
Ещё из интересного, что мы обсудили:
📍 Почему полезно поработать в разных компаниях: стартапах, аутсорсе и крупных корпорациях, и как это делает тебя сильнее.
📍 Как жить в Испании, а работать на московский часовой пояс (сложно).
📍 Зачем мне права на прицеп, и как выглядит путешествие на машине длиной в 30 дней из Москвы до Валенсии.
📍 Как европейская бюрократия оказалась человечнее и дружелюбнее, чем российский паспортный стол.
📍 Какие принципы ведения телеграм-канала я нарушаю в @product_developer.
И ещё много всего полезного и личного.
Ссылка на выпуск 👉 Frontend Weekend
Кстати, вдогонку можно подписаться на канал Андрея — он делает отличные интервью!
Разговор получился глубокий, душевный и очень личный. Обсудили мой карьерный путь, переезд в Испанию, ведение телеграм-канала и даже немного про Digital Nomad и жизнь в Испании.
Отдельно хочу поделиться темой, которая для меня самого сейчас особенно актуальна:
Менеджер или индивидуальный контрибьютор?
Последние 2 года в Авито я руководил юнитом, а недавно стал руководителем кластера.
Работа менеджером мне действительно нравится, но я не считаю зазорным или странным снова вернуться в разработку.
Почему? Потому что, когда ты инженер, у тебя каждый день есть возможность получать удовольствие от быстрых и понятных результатов.
Вот ты написал код, отладил — работает! Сразу получил обратную связь и дофамин.
Чего-то не было — благодаря тебе теперь есть. Ты создал. Ты — созидатель.
Это мгновенная радость от понятного и ощутимого результата.
У менеджера всё не так. Результаты твоих решений и действий проявляются через месяцы, а иногда и полгода спустя.
И чтобы увидеть их и порадоваться, нужно прилагать отдельные усилия и специально рефлексировать.
Многие разработчики по инерции становятся тимлидами, не до конца понимая, что это совсем другая роль с другими правилами игры. Я очень рекомендую задуматься, подходит ли она вам, или вы просто следуете общепринятому карьерному росту.
Выбор «менеджер или инженер» — это не про статус, а про то, какую работу ты больше любишь делать и от чего получаешь удовольствие.
———
Ещё из интересного, что мы обсудили:
📍 Почему полезно поработать в разных компаниях: стартапах, аутсорсе и крупных корпорациях, и как это делает тебя сильнее.
📍 Как жить в Испании, а работать на московский часовой пояс (сложно).
📍 Зачем мне права на прицеп, и как выглядит путешествие на машине длиной в 30 дней из Москвы до Валенсии.
📍 Как европейская бюрократия оказалась человечнее и дружелюбнее, чем российский паспортный стол.
📍 Какие принципы ведения телеграм-канала я нарушаю в @product_developer.
И ещё много всего полезного и личного.
Ссылка на выпуск 👉 Frontend Weekend
Кстати, вдогонку можно подписаться на канал Андрея — он делает отличные интервью!
Telegram
Андрей Смирнов | Викенд в IT
С Никитой Хромушкиным мы познакомились в программном комитете тимлидовской подлодки и успели сделать вместе пару сезонов. Но год назад Никита решил вместе с семьёй переехать на машине в Испанию – а я дождался, пока он там освоится и насоберёт интересных впечатлений…
🐒 Обезьяний менеджмент
Ситуация: тимлид приходит на работу в отличном настроении, готовый спокойно разобраться с важными задачами.
Но тут к нему подходит разработчик и говорит:
— Есть одна проблема, нужна твоя помощь.
Тимлид отвечает:
— Ок, посмотрю позже.
Разработчик только что поставил тимлиду задачу, а он её положил в свой бесконечный бэклог.
Теперь ему придется её «приоритизировать» с другими такими же, а потом страдать, когда будет всё не успевать.
Представьте себе метафору: задача — обезьяна на плечах. Она перепрыгнула с разработчика на тимлида. К концу дня у него на плечах сидит целый зоопарк. Он занят чужой работой, а его сотрудники простаивают, потому что «ждут ответа».
📌 Коротко о проблеме:
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 и Обезьяньим менеджментом?
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
Очередной «умник» изобрел метафору с обезьянами и решил, что все проблемы в менеджменте — это лень сотрудников и перегрузка тимлида. Типичная ситуация: вместо того, чтобы помогать людям, теперь менеджер будет тупо скидывать задачи обратно на сотрудников под…
Как управлять людьми, а не чужими задачами
В последних двух постах мы обсуждали, как лидеру управлять командой, а не таскать на своих плечах чужие задачи.
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 мая, Москва
👉Подробности и расписание тут
Please open Telegram to view this post
VIEW IN TELEGRAM
🎯 Пособеситься — это тоже навык
Disclaimer: это реклама бесплатной консультации от Карьерного цеха
Раз в год-два я хожу на рынок «пособеситься». Не чтобы уходить, а чтобы свериться с реальностью: чего я стою, как звучит мой опыт, какие сейчас ожидания у компаний.
Но в этот раз нарушил правило, 3 года не практиковался.
И когда решил снова — понял, что растерял навык:
1. Меня не зовут
2. Не понимаю, кто я сейчас для рынка
3. Разучился внятно рассказывать про свой опыт
4. Неясно, как за 3 года изменились зарплаты
И тут приходит простая, но неприятная мысль:
собеседование — это экзамен.
Не самый честный и не самый логичный, но экзамен.
А если ты давно не сдавал экзамены — можешь забыть, как это делается.
Чтобы понять, как вернуться в тонус, можно пойти на бесплатную консультацию в Карьерный Цех.
Карьерное сопровождение — это не волшебная таблетка. Просто нормальная, внятная точка входа, где помогут:
1. Разобраться, как вы выглядите для рынка сейчас.
2. Оценить навыки, сильные стороны и карьерные цели.
3. Понять, как упаковать опыт и где зарыты карьерные возможности.
Если дальше захотите сопровождение — можно будет вписаться. А если нет — просто уйдёте с пониманием, куда двигаться и как.
👉 Записаться на бесплатную консультацию
Реклама. ИП Федоров Е.П.
ИНН 532008901966
Disclaimer: это реклама бесплатной консультации от Карьерного цеха
Раз в год-два я хожу на рынок «пособеситься». Не чтобы уходить, а чтобы свериться с реальностью: чего я стою, как звучит мой опыт, какие сейчас ожидания у компаний.
Но в этот раз нарушил правило, 3 года не практиковался.
И когда решил снова — понял, что растерял навык:
1. Меня не зовут
2. Не понимаю, кто я сейчас для рынка
3. Разучился внятно рассказывать про свой опыт
4. Неясно, как за 3 года изменились зарплаты
И тут приходит простая, но неприятная мысль:
собеседование — это экзамен.
Не самый честный и не самый логичный, но экзамен.
А если ты давно не сдавал экзамены — можешь забыть, как это делается.
Чтобы понять, как вернуться в тонус, можно пойти на бесплатную консультацию в Карьерный Цех.
Карьерное сопровождение — это не волшебная таблетка. Просто нормальная, внятная точка входа, где помогут:
1. Разобраться, как вы выглядите для рынка сейчас.
2. Оценить навыки, сильные стороны и карьерные цели.
3. Понять, как упаковать опыт и где зарыты карьерные возможности.
Если дальше захотите сопровождение — можно будет вписаться. А если нет — просто уйдёте с пониманием, куда двигаться и как.
👉 Записаться на бесплатную консультацию
Реклама. ИП Федоров Е.П.
ИНН 532008901966
careerfactory.ru
Приведём за руку к новой работе с высокой зарплатой -- Карьерное сопровождение
Сопровождение для продактов, дизайнеров, продуктовых аналитиков, менеджеров проектов и маркетологов.
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
🐒 Обезьяний менеджмент
Ситуация: тимлид приходит на работу в отличном настроении, готовый спокойно разобраться с важными задачами.
Но тут к нему подходит разработчик и говорит:
— Есть одна проблема, нужна твоя помощь.
Тимлид отвечает:
— Ок, посмотрю позже.…
Ситуация: тимлид приходит на работу в отличном настроении, готовый спокойно разобраться с важными задачами.
Но тут к нему подходит разработчик и говорит:
— Есть одна проблема, нужна твоя помощь.
Тимлид отвечает:
— Ок, посмотрю позже.…
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
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 и прочее) используются в качестве…
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лово «порок» — не совсем корректная локализация, поэтому буду писать «дисфункция».
Пост получился объёмным, поэтому я его разделил на…
Please open Telegram to view this post
VIEW IN TELEGRAM
Не становись тимлидом, не совершай ошибку
Обычно, когда разработчик становится тимлидом, про него говорят «вырос».
Но я не считаю это ростом. Мне больше нравится слово «переход».
Сейчас объясню, почему.
К грейдам разработчиков все привыкли: джун, мидл, сеньор.
Почему никто не говорит про грейды тимлидов? Ведь бывают начинающие тимлиды, уверенные и бывалые.
Да-да, тимлид тоже бывает джун, а бывает сеньор.
❓ Как думаете, когда сеньор-разработчик «вырастает в тимлиды», каким тимлидом он становится?
Правильно, джуном.
Снова появляется гамма ощущений издетства джунства:
— 😰 Сталкиваешься с неизвестной тебе проблемой и даже не знаешь, куда копать. Только рядом нет сеньора, которого можно было бы спросить.
— 🚨 Боишься накосячить. Только теперь цена ошибки гораздо выше: раздрай в команде, увольнения, сорванные сроки по проекту.
— 😕 Вокруг происходят непонятные тебе вещи, взрослые дяди говорят на взрослом языке, и ты вроде понимаешь, что это важно, а поучаствовать в разговоре не можешь.
Рост ли это?
Сомнительно.
Много ли от этого удовольствия?
Меньше, чем от разработки.
…
📌 Есть и другие неприятные моменты работы тимлидом:
— 😩 Постоянное нытьё. Когда ты внутри команды, это не заметно. Но у каждого есть свои проблемы, и ты как тимлид становишься той самой жилеткой. Ты будешь в контексте всего, что происходит у 9 человек. У тебя теперь в 9 раз больше личных и рабочих проблем. При этом ты не сможешь помочь всем и каждому. И от этого можно сойти с ума.
— 🤬 Люди косячат, и ты должен доносить им корректирующую обратную связь. Им неприятно. Тебе неприятно. А в какой-то момент ты должен будешь кого-то уволить. Может быть не в первый год, но этот момент точно наступит.
— 📑 Бюрократия и бесконечные отчёты. Даже в компаниях «без бюрократии», ты поймешь, что количество бумажной рутины выросло.
— 🎭 Окунание в корпоративные политические игры. Даже в «бирюзовых организациях» есть политика. Просто её сложнее будет увидеть.
— 📲 Встречи. Календарь превращается в сплошную портянку митингов.
— 💬 Контексты, контексты, контексты. Постоянное переключение между задачами, темами и людьми. Для разработчика это неприемлемо. Для тимлида — это норма.
— 🤥 Ответственность. Не всегда и не все ошибки команды можно и нужно предотвращать. Команде нужно давать возможность учиться на ошибках. Но отвечать за них всё равно тимлиду.
…
Потом потихоньку адаптируешься, начинаешь понимать, что происходит. Становишься тимлидом-мидлом.
Только удовольствие от работы почему-то не возвращается.
Когда ты был разработчиком, ты каждый день что-то созидал: утром не было какой-то фичи, ты её написал, и вечером она уже в проде. Ты — созидатель. Это даёт дофамин каждый день.
У каждого своё соотношение задач приятных и не очень.
🎯 Для меня лично, когда был разработчиком, соотношение задач было около 80% / 20% приятных / нейтральных или неприятных.
Если меньше — надо что-то менять.
Когда стал менеджером, понял, что минимально комфортное соотношение упало до 30% / 70 %.
Скажете — мало? А больше на рынке тупо нет. Везде работа тимлидом — это напряги, стресс и рутина.
Но менеджерский кайф есть. Он другой. Отложенный и трудно уловимый, но совершенно другого уровня.
Вот ты хочешь что-то поменять в процессах, решить какую-то боль.
Сначала потратишь не один день, чтобы придумать, как именно.
Потом будешь 2 недели преодолевать сопротивление изменениям в команде.
Потом месяц будешь наблюдать за тем, стало ли лучше.
И вот спустя 3 месяца тебе надо будет остановиться, посмотреть назад, увидеть «было/стало», и как следует от этого кайфануть.
В одиночестве.
И никому особо не похвастаешься: как было хреново, уже не помнят. Как хорошо стало — не видят: для команды это новая «нормальность» и в ней есть проблемы.
Готовы ли вы ждать месяцы ради такого призрачного кайфа?
Подумайте хорошенько, прежде чем идти в тимлиды.
Обычно, когда разработчик становится тимлидом, про него говорят «вырос».
Но я не считаю это ростом. Мне больше нравится слово «переход».
Сейчас объясню, почему.
К грейдам разработчиков все привыкли: джун, мидл, сеньор.
Почему никто не говорит про грейды тимлидов? Ведь бывают начинающие тимлиды, уверенные и бывалые.
Да-да, тимлид тоже бывает джун, а бывает сеньор.
❓ Как думаете, когда сеньор-разработчик «вырастает в тимлиды», каким тимлидом он становится?
Правильно, джуном.
Снова появляется гамма ощущений из
— 😰 Сталкиваешься с неизвестной тебе проблемой и даже не знаешь, куда копать. Только рядом нет сеньора, которого можно было бы спросить.
— 🚨 Боишься накосячить. Только теперь цена ошибки гораздо выше: раздрай в команде, увольнения, сорванные сроки по проекту.
— 😕 Вокруг происходят непонятные тебе вещи, взрослые дяди говорят на взрослом языке, и ты вроде понимаешь, что это важно, а поучаствовать в разговоре не можешь.
Рост ли это?
Сомнительно.
Много ли от этого удовольствия?
Меньше, чем от разработки.
…
📌 Есть и другие неприятные моменты работы тимлидом:
— 😩 Постоянное нытьё. Когда ты внутри команды, это не заметно. Но у каждого есть свои проблемы, и ты как тимлид становишься той самой жилеткой. Ты будешь в контексте всего, что происходит у 9 человек. У тебя теперь в 9 раз больше личных и рабочих проблем. При этом ты не сможешь помочь всем и каждому. И от этого можно сойти с ума.
— 🤬 Люди косячат, и ты должен доносить им корректирующую обратную связь. Им неприятно. Тебе неприятно. А в какой-то момент ты должен будешь кого-то уволить. Может быть не в первый год, но этот момент точно наступит.
— 📑 Бюрократия и бесконечные отчёты. Даже в компаниях «без бюрократии», ты поймешь, что количество бумажной рутины выросло.
— 🎭 Окунание в корпоративные политические игры. Даже в «бирюзовых организациях» есть политика. Просто её сложнее будет увидеть.
— 📲 Встречи. Календарь превращается в сплошную портянку митингов.
— 💬 Контексты, контексты, контексты. Постоянное переключение между задачами, темами и людьми. Для разработчика это неприемлемо. Для тимлида — это норма.
— 🤥 Ответственность. Не всегда и не все ошибки команды можно и нужно предотвращать. Команде нужно давать возможность учиться на ошибках. Но отвечать за них всё равно тимлиду.
…
Потом потихоньку адаптируешься, начинаешь понимать, что происходит. Становишься тимлидом-мидлом.
Только удовольствие от работы почему-то не возвращается.
Когда ты был разработчиком, ты каждый день что-то созидал: утром не было какой-то фичи, ты её написал, и вечером она уже в проде. Ты — созидатель. Это даёт дофамин каждый день.
У каждого своё соотношение задач приятных и не очень.
🎯 Для меня лично, когда был разработчиком, соотношение задач было около 80% / 20% приятных / нейтральных или неприятных.
Если меньше — надо что-то менять.
Когда стал менеджером, понял, что минимально комфортное соотношение упало до 30% / 70 %.
Скажете — мало? А больше на рынке тупо нет. Везде работа тимлидом — это напряги, стресс и рутина.
Но менеджерский кайф есть. Он другой. Отложенный и трудно уловимый, но совершенно другого уровня.
Вот ты хочешь что-то поменять в процессах, решить какую-то боль.
Сначала потратишь не один день, чтобы придумать, как именно.
Потом будешь 2 недели преодолевать сопротивление изменениям в команде.
Потом месяц будешь наблюдать за тем, стало ли лучше.
И вот спустя 3 месяца тебе надо будет остановиться, посмотреть назад, увидеть «было/стало», и как следует от этого кайфануть.
В одиночестве.
И никому особо не похвастаешься: как было хреново, уже не помнят. Как хорошо стало — не видят: для команды это новая «нормальность» и в ней есть проблемы.
Готовы ли вы ждать месяцы ради такого призрачного кайфа?
Подумайте хорошенько, прежде чем идти в тимлиды.
Неудобные разговоры — неприятная работа тимлида
Знаете ощущение перед таким разговором, когда придется говорить неприятные собеседнику вещи?
— Когда заказчик просит невозможного. Или хуже — когда заказчику уже продали невозможное.
— Когда кто-то накосячил и нужно донести обратную связь
— Когда сотрудник просит роста, но не особо перформит.
— Когда сверху прилетают неудобные ограничения, разнарядки и задачи, которые нужно донести команде, сохранив и авторитет компании, и свой собственный.
Ощущение такое..
«сейчас я испорчу себе карму и меня будут считать говнюком».
Опытный тимлид решает такие задачи честно и прямо. Да, кто-то останется недовольным. Но правильный подход позволяет донести позицию так, чтобы не остаться тем самым говнюком и не испортить карму.
А вот неопытный или неуверенный тимлид в таких ситуациях начинает извиваться как уж на сковородке: пытается быть «хорошим» для всех, но в итоге не решает проблему и теряет уважение команды.
Главная беда в том, что никто не рождается с навыком вести неудобные разговоры. Этому учатся — обычно через ошибки и боль.
4 июня в 20:00 (мск) Soft Skills Lab проводит бесплатный вебинар как раз на эту тему:
Как вести неудобные разговоры с командой и стейкхолдерами
Разберём на реальных кейсах:
— Как переводить эмоции в конструктив
— Как говорить неприятные вещи, не теряя контакт
— Как сохранять авторитет и держать лицо, когда на тебя давят
Ведёт Нелли Григорьева — преподаватель переговоров в ВШЭ, консультант техкомпаний, бывший маркетинг-директор международных стартапов.
📌 Zoom, можно прийти со своими вопросами.
📌 Бесплатно. Запустите бота, чтобы получить ссылку
Если вы тоже ловили себя на желании «извернуться» и сгладить углы вместо того, чтобы вести неудобный разговор прямо, — возможно, будет полезно.
Я пойду.
Реклама. ИП Клименко А.А. ИНН 772077460576 erid: 2Vtzqw59Feu
Знаете ощущение перед таким разговором, когда придется говорить неприятные собеседнику вещи?
— Когда заказчик просит невозможного. Или хуже — когда заказчику уже продали невозможное.
— Когда кто-то накосячил и нужно донести обратную связь
— Когда сотрудник просит роста, но не особо перформит.
— Когда сверху прилетают неудобные ограничения, разнарядки и задачи, которые нужно донести команде, сохранив и авторитет компании, и свой собственный.
Ощущение такое..
«сейчас я испорчу себе карму и меня будут считать говнюком».
Опытный тимлид решает такие задачи честно и прямо. Да, кто-то останется недовольным. Но правильный подход позволяет донести позицию так, чтобы не остаться тем самым говнюком и не испортить карму.
А вот неопытный или неуверенный тимлид в таких ситуациях начинает извиваться как уж на сковородке: пытается быть «хорошим» для всех, но в итоге не решает проблему и теряет уважение команды.
Главная беда в том, что никто не рождается с навыком вести неудобные разговоры. Этому учатся — обычно через ошибки и боль.
4 июня в 20:00 (мск) Soft Skills Lab проводит бесплатный вебинар как раз на эту тему:
Как вести неудобные разговоры с командой и стейкхолдерами
Разберём на реальных кейсах:
— Как переводить эмоции в конструктив
— Как говорить неприятные вещи, не теряя контакт
— Как сохранять авторитет и держать лицо, когда на тебя давят
Ведёт Нелли Григорьева — преподаватель переговоров в ВШЭ, консультант техкомпаний, бывший маркетинг-директор международных стартапов.
📌 Zoom, можно прийти со своими вопросами.
📌 Бесплатно. Запустите бота, чтобы получить ссылку
Если вы тоже ловили себя на желании «извернуться» и сгладить углы вместо того, чтобы вести неудобный разговор прямо, — возможно, будет полезно.
Я пойду.
Реклама. ИП Клименко А.А. ИНН 772077460576 erid: 2Vtzqw59Feu
Telegram
Soft Skills Lab bot
Бот для организации мероприятий школы коммуникации Soft Skills Lab
Стратегия. Чеклист, как отличить плохую от хорошей.
Большинство «стратегий», которые я видел — это просто набор пафосных лозунгов:
— Увеличить вовлеченность
— Быть лидерами на рынке
— Повысить инновационность
Я и сам такое писал. И даже гордился.
Сейчас делаю очередной подход к составлению стратегии и на этот раз решил подойти к вопросу осознанно.
Прочитал книгу Ричарда Румельта Good Strategy / Bad Strategy и посмотрел модуль про стратегию от Стратоплана.
Теперь понимаю, что предыдущие мои стратегии — самые настоящие «Bad strategy».
Они не решали реальных проблем.
В них не было чёткой диагностики, не было фокуса, не было руководящих принципов.
Они были про "куда хотим", но не про "что мешает" и "как будем справляться".
🎯 Что такое настоящая стратегия?
По Румельту, стратегия — это не список целей. Это ответ на проблему. Она начинается с того, что:
📍 Определяет текущую точку А — где мы находимся и что за проблема перед нами.
🎯 Показывает точку Б — куда мы хотим прийти.
➡️ Рисует стрелочку — путь от А к Б.
И вот внутри этой стрелочки должны быть трудности.
Стратегия — это план, как эти трудности преодолеть.
План должен быть понятным и конкретным, чтоб его можно было объяснить за 1 минуту.
Пример: стратегия Netflix
В 2007 году Netflix занимался доставкой DVD по почте. Компания поняла: оффлайн модель отмирает, нужно идти в онлайн.
Этот переход был невероятно сложным:
1. Пользователи не понимали, чем новый формат лучше DVD. Чтобы их переучить, Netflix сделал ставку на качество: HD-стриминг, понятный интерфейс и годный контент. А еще обеспечили UX одним кликом — сейчас на каждом пульте есть кнопка Netflix :)
2. HD стриминг требовал мощной инфраструктуры, а существующие CDN в 2007 году были дорогими и нестабильными. Тогда Netflix пошёл ва-банк и создал свою собственную CDN — Open Connect, с серверами прямо у провайдеров.
3. Студии не верили в стриминг, не хотели давать контент и требовали огромные роялти. Тогда Netflix сам стал студией — запустил оригинальные сериалы вроде House of Cards и раздавал их эксклюзивно через себя.
Это и была настоящая стратегия: они увидели, куда надо идти, честно признали, какие на пути будут проблемы — и построили конкретный план, как через них пройти.
✅ Чеклист Good Strategy:
1. Diagnosis — чётко названа реальная проблема
2. Guiding Policy — понятный принцип, как действуем
3. Coherent Action — шаги согласованы и усиливают друг друга
4. Focus — сделан выбор, на чём концентрируемся
5. Tackle the challenge — есть план, как преодолеем ключевые трудности. Не просто путь из А в Б, а план, как пройти через все узкие места по пути.
🧩 Чеклист Bad Strategy:
1. Dog’s Dinner Objectives — мешанина несвязанных хотелок
2. Blue-Sky Objectives — мечты без связи с реальностью
3. Fluff — пафосные слова вместо смысла
4. Failure to Face the Problem — игнор настоящей проблемы
5. Mistaking Goals for Strategy — цели выдают за стратегию
6. Template-Style Strategy — шаблон ради галочки
7. Avoiding the Hard Work — нет выбора, нет отказа, нет боли
Итог.
Теперь я дофига знаю о том, как должна выглядеть хорошая стратегия, поэтому свою еще не написал 😄
Сложно:
- найти настоящую проблему, а не просто её симптомы;
- сфокусироваться на одной вещи, отбросив всё лишнее;
- придумать руководящие политики, которые реально помогают сдвинуться с места;
…
В чем польза поста?
Если вы разработчик — теперь вы можете челленджить булшит-стратегии, которые выглядят как презентация для инвестора. Спрашивайте: «в чём проблема?», «как мы её решаем?», «что конкретно поменяется?»
Если вы менеджер — прям советую книжку Good Strategy / Bad Strategy.
Если уже читали, давайте обсудим в комментах.
Большинство «стратегий», которые я видел — это просто набор пафосных лозунгов:
— Увеличить вовлеченность
— Быть лидерами на рынке
— Повысить инновационность
Я и сам такое писал. И даже гордился.
Сейчас делаю очередной подход к составлению стратегии и на этот раз решил подойти к вопросу осознанно.
Прочитал книгу Ричарда Румельта Good Strategy / Bad Strategy и посмотрел модуль про стратегию от Стратоплана.
Теперь понимаю, что предыдущие мои стратегии — самые настоящие «Bad strategy».
Они не решали реальных проблем.
В них не было чёткой диагностики, не было фокуса, не было руководящих принципов.
Они были про "куда хотим", но не про "что мешает" и "как будем справляться".
🎯 Что такое настоящая стратегия?
По Румельту, стратегия — это не список целей. Это ответ на проблему. Она начинается с того, что:
📍 Определяет текущую точку А — где мы находимся и что за проблема перед нами.
🎯 Показывает точку Б — куда мы хотим прийти.
➡️ Рисует стрелочку — путь от А к Б.
И вот внутри этой стрелочки должны быть трудности.
Стратегия — это план, как эти трудности преодолеть.
План должен быть понятным и конкретным, чтоб его можно было объяснить за 1 минуту.
Пример: стратегия Netflix
В 2007 году Netflix занимался доставкой DVD по почте. Компания поняла: оффлайн модель отмирает, нужно идти в онлайн.
Этот переход был невероятно сложным:
1. Пользователи не понимали, чем новый формат лучше DVD. Чтобы их переучить, Netflix сделал ставку на качество: HD-стриминг, понятный интерфейс и годный контент. А еще обеспечили UX одним кликом — сейчас на каждом пульте есть кнопка Netflix :)
2. HD стриминг требовал мощной инфраструктуры, а существующие CDN в 2007 году были дорогими и нестабильными. Тогда Netflix пошёл ва-банк и создал свою собственную CDN — Open Connect, с серверами прямо у провайдеров.
3. Студии не верили в стриминг, не хотели давать контент и требовали огромные роялти. Тогда Netflix сам стал студией — запустил оригинальные сериалы вроде House of Cards и раздавал их эксклюзивно через себя.
Это и была настоящая стратегия: они увидели, куда надо идти, честно признали, какие на пути будут проблемы — и построили конкретный план, как через них пройти.
✅ Чеклист Good Strategy:
1. Diagnosis — чётко названа реальная проблема
2. Guiding Policy — понятный принцип, как действуем
3. Coherent Action — шаги согласованы и усиливают друг друга
4. Focus — сделан выбор, на чём концентрируемся
5. Tackle the challenge — есть план, как преодолеем ключевые трудности. Не просто путь из А в Б, а план, как пройти через все узкие места по пути.
🧩 Чеклист Bad Strategy:
1. Dog’s Dinner Objectives — мешанина несвязанных хотелок
2. Blue-Sky Objectives — мечты без связи с реальностью
3. Fluff — пафосные слова вместо смысла
4. Failure to Face the Problem — игнор настоящей проблемы
5. Mistaking Goals for Strategy — цели выдают за стратегию
6. Template-Style Strategy — шаблон ради галочки
7. Avoiding the Hard Work — нет выбора, нет отказа, нет боли
Итог.
Теперь я дофига знаю о том, как должна выглядеть хорошая стратегия, поэтому свою еще не написал 😄
Сложно:
- найти настоящую проблему, а не просто её симптомы;
- сфокусироваться на одной вещи, отбросив всё лишнее;
- придумать руководящие политики, которые реально помогают сдвинуться с места;
…
В чем польза поста?
Если вы разработчик — теперь вы можете челленджить булшит-стратегии, которые выглядят как презентация для инвестора. Спрашивайте: «в чём проблема?», «как мы её решаем?», «что конкретно поменяется?»
Если вы менеджер — прям советую книжку Good Strategy / Bad Strategy.
Если уже читали, давайте обсудим в комментах.
Авито — топовая школа менеджмента
Короче, мы тут стали работодателем №1 для продактов по результатам исследования DevCrowd 🎉
DevCrowd несколько лет проводят опросы — их уже все видели и многие проходили. Например, я постил в этот канал опрос про тимлидов.
Результаты всегда интересно смотреть. Особенно потому, что ребята оформляют их красиво: понятные лендосы, инфографика, всё по делу.
Ну и потому что там про денежки, конечно же 🙂
По итогам — я с результатами полностью согласен.
Авито действительно крутая школа для менеджеров.
Есть, где разгуляться:
— Тебе доверяют продукт, метрики. Можно не просто «пилить фичи», а формировать видение будущего и целенаправленно двигаться к нему
— Можно катить АБ-тесты на миллионы пользователей и быстро видеть статзначимые результаты
— У каждого продакта есть своя команда разработки
— Ну и просто приятно делать то, чем пользуются твои друзья и знакомые
Но и требования высокие. От продакта ожидают продуманности каждого шага, уверенности в принятии решений, и того самого видения.
В общем, результаты опроса приятные.
Потому что знаю, что это не заказуха, а реальные результаты реального опроса 800 продактов. 🧡
Короче, мы тут стали работодателем №1 для продактов по результатам исследования DevCrowd 🎉
DevCrowd несколько лет проводят опросы — их уже все видели и многие проходили. Например, я постил в этот канал опрос про тимлидов.
Результаты всегда интересно смотреть. Особенно потому, что ребята оформляют их красиво: понятные лендосы, инфографика, всё по делу.
Ну и потому что там про денежки, конечно же 🙂
По итогам — я с результатами полностью согласен.
Авито действительно крутая школа для менеджеров.
Есть, где разгуляться:
— Тебе доверяют продукт, метрики. Можно не просто «пилить фичи», а формировать видение будущего и целенаправленно двигаться к нему
— Можно катить АБ-тесты на миллионы пользователей и быстро видеть статзначимые результаты
— У каждого продакта есть своя команда разработки
— Ну и просто приятно делать то, чем пользуются твои друзья и знакомые
Но и требования высокие. От продакта ожидают продуманности каждого шага, уверенности в принятии решений, и того самого видения.
В общем, результаты опроса приятные.
Потому что знаю, что это не заказуха, а реальные результаты реального опроса 800 продактов. 🧡
Гибкость vs прогнозируемость
Всегда хочется одновременно:
— Быстро реагировать на изменения.
— Чётко планировать спринты и попадать в срок.
Но это взаимоисключающие настройки:
1. Подкручиваешь гибкость — снижается прогнозируемость, больше шанс что у сырой задачи что-то вскроется в процессе и сроки поедут.
2. Тюнишь прогнозируемость — добавляешь пункты в Definition of Ready и начинаешь сопротивляться непроработанным задачам.
Когда-то давно у моей команды был максимально гибкий процесс: продакт приносил задачки прямо на планирование и мы весь понедельник с ними разобирались.
С одной стороны, супер-гибко: пришла идея — сразу пошла в работу.
С другой — неэффективно и без гарантий сроков: целый день улетал на то, чтобы договориться о деталях, но чаще всего цель спринта не успевали и доделывали в следующем.
Как итог — накапливался снежный ком «доделок с прошлого спринта».
Минимальная глубина прогрумленности бэклога
Если задачи проработаны заранее, — планирование становится простым и быстрым.
Для этого верхушка бэклога должна быть проработана и готова к взятию в работу.
Но встает вопрос: верхушка — это сколько?
Мы экспериментировали с разными вариантами и пришли к оптимальному значению — 2 спринта.
Почему именно 2?
Так у команды появляется запасной план на случай, если продакт вдруг решит отложить какую-то задачу или попросит больше времени на дополнительное дискавери.
Больше — есть шанс, что время на проработку будет потрачено впустую, а задачи никогда не пойдут в работу.
Меньше — есть риск потратить весь день на планирование, если проработанные задачи попросят поставить на паузу.
Как измеряем 2 спринта
1. Берём задачи, проработанные не позднее 90 дней назад. Если задача более старая — скорее всего, что-то уже поменялось и её надо заново прорабатывать.
2. Считаем медианное velocity команды за последние 3 месяца.
3. Делим сумму оценок готовых задач на медианное velocity.
———
В итоге, можно сказать что наш ползунок «гибкость <—> прогнозируемость» стоит где-то посередине.
Что не идеально — в итоге гибкость ограничена по сути выбором из двух наборов задач.
А прогнозируемость гарантируем в пределах двух спринтов.
Но это не хорошо и не плохо — это наш выбор.
А у вас как?
Всегда хочется одновременно:
— Быстро реагировать на изменения.
— Чётко планировать спринты и попадать в срок.
Но это взаимоисключающие настройки:
1. Подкручиваешь гибкость — снижается прогнозируемость, больше шанс что у сырой задачи что-то вскроется в процессе и сроки поедут.
2. Тюнишь прогнозируемость — добавляешь пункты в Definition of Ready и начинаешь сопротивляться непроработанным задачам.
Когда-то давно у моей команды был максимально гибкий процесс: продакт приносил задачки прямо на планирование и мы весь понедельник с ними разобирались.
С одной стороны, супер-гибко: пришла идея — сразу пошла в работу.
С другой — неэффективно и без гарантий сроков: целый день улетал на то, чтобы договориться о деталях, но чаще всего цель спринта не успевали и доделывали в следующем.
Как итог — накапливался снежный ком «доделок с прошлого спринта».
Минимальная глубина прогрумленности бэклога
Если задачи проработаны заранее, — планирование становится простым и быстрым.
Для этого верхушка бэклога должна быть проработана и готова к взятию в работу.
Но встает вопрос: верхушка — это сколько?
Мы экспериментировали с разными вариантами и пришли к оптимальному значению — 2 спринта.
Почему именно 2?
Так у команды появляется запасной план на случай, если продакт вдруг решит отложить какую-то задачу или попросит больше времени на дополнительное дискавери.
Больше — есть шанс, что время на проработку будет потрачено впустую, а задачи никогда не пойдут в работу.
Меньше — есть риск потратить весь день на планирование, если проработанные задачи попросят поставить на паузу.
Как измеряем 2 спринта
1. Берём задачи, проработанные не позднее 90 дней назад. Если задача более старая — скорее всего, что-то уже поменялось и её надо заново прорабатывать.
2. Считаем медианное velocity команды за последние 3 месяца.
3. Делим сумму оценок готовых задач на медианное velocity.
———
В итоге, можно сказать что наш ползунок «гибкость <—> прогнозируемость» стоит где-то посередине.
Что не идеально — в итоге гибкость ограничена по сути выбором из двух наборов задач.
А прогнозируемость гарантируем в пределах двух спринтов.
Но это не хорошо и не плохо — это наш выбор.
А у вас как?
This media is not supported in your browser
VIEW IN TELEGRAM
Dream → Teamlead
Бесплатная конференция для тимлидов, на которую иду сам, в оффлайне.
Можно сказать, лечу раз в год в Москву ради этой конфы 🙂 Буду рад повидаться!
В программном комитете — уважаемые товарищи Евгений Антонов (Тимлид Очевидность) и Артём Арюткин (Плохой Project). Обоих знаю лично, ребята фигни не сделают.
Будут сильные спикеры, которые не нуждаются в представлении: Максим Дорофеев, Алексей Пименов, Александр Ложечкин.
Еще не менее топовые спикеры — мои коллеги, с которыми мы уже делали выступления:
— Анатолий Панов — рассказывал на подлодке доклад про онбординг тимлида в новой компании и цели на ИС.
На митапе Толя расскажет про саморазвитие как преимущество в карьере.
— Евгений Рейх — проводил публичное интервью тимлида, а еще рассказывал про ожидания от тимлида с разных сторон.
На митапе будет прожарка тимлидов, разбор кейсов участников.
Короче, уровень топовой тимлидской конфы, но бесплатно.
Что есть необычного в программе:
📌 1,5-2 часовые мастер-классы вместо 30-минутных докладов про «как мы успешно внедрили успех».
📌 Консультации 1-1 со спикерами. Нужно будет заранее записаться и максимально подробно описать свой запрос.
19 июля, Москва. Бесплатно, но нужна регистрация.
Будет трансляция из главного зала.
👉 Регистрация и программа
Бесплатная конференция для тимлидов, на которую иду сам, в оффлайне.
Можно сказать, лечу раз в год в Москву ради этой конфы 🙂 Буду рад повидаться!
В программном комитете — уважаемые товарищи Евгений Антонов (Тимлид Очевидность) и Артём Арюткин (Плохой Project). Обоих знаю лично, ребята фигни не сделают.
Будут сильные спикеры, которые не нуждаются в представлении: Максим Дорофеев, Алексей Пименов, Александр Ложечкин.
Еще не менее топовые спикеры — мои коллеги, с которыми мы уже делали выступления:
— Анатолий Панов — рассказывал на подлодке доклад про онбординг тимлида в новой компании и цели на ИС.
На митапе Толя расскажет про саморазвитие как преимущество в карьере.
— Евгений Рейх — проводил публичное интервью тимлида, а еще рассказывал про ожидания от тимлида с разных сторон.
На митапе будет прожарка тимлидов, разбор кейсов участников.
Короче, уровень топовой тимлидской конфы, но бесплатно.
Что есть необычного в программе:
📌 1,5-2 часовые мастер-классы вместо 30-минутных докладов про «как мы успешно внедрили успех».
📌 Консультации 1-1 со спикерами. Нужно будет заранее записаться и максимально подробно описать свой запрос.
19 июля, Москва. Бесплатно, но нужна регистрация.
Будет трансляция из главного зала.
👉 Регистрация и программа