QA опять тормозит релиз
Новая неделя — новый кейс.
——————————————————————
Вы менеджер команды, которая разрабатывает мобильное B2C-приложение. Команда небольшая: 3 бэкендера, 2 Flutter-разработчика и 1 QA. Дизайн — на аутсорсе.
Полгода назад вы пообещали регулярные релизы каждый спринт. Но до цели так и не добежали: в лучшем случае получается раз в месяц. Сценарий всегда один и тот же — две недели «всё идёт по плану», а ближе к концу спринта выясняется, что на тестирование снова нужно больше времени.
В чате уже мемы:
— QA, ну что там?
— Мы же отдали тебе вчера…
— Без релиза бизнес нас съест.
Вы зовёте тестировщика на разговор, чтобы по-честному понять, что ломается.
Версия QA:
Вы просите конкретику. QA открывает последние тикеты.
Тикет №1: «Сделать фильтр по статусам заказов».
В описании — две строчки.
Скрина нет. Поведения нет. Какие статусы? Какие комбинации? Что по умолчанию? Что показываем, если заказов нет? А если у пользователя нет прав?
QA комментирует:
Тикет №2: «Сделать как раньше, только лучше».
Вместо требований — ссылка на переписку на 120 сообщений, где решения перемешаны с мемами, и половина нюансов тонет между «давайте так» и «нет, не так».
QA резюмирует:
Вы выходите из разговора с ощущением, что где-то есть системный перекос.
С одной стороны — разработчики уверены, что отдали «готовое».
С другой — QA уверен, что «готового» в задаче не видно.
И итог каждый раз одинаковый: релиз разваливается в конце спринта — и вас это больше не устраивает.
Итак, что вы будете делать дальше?
#кейсы@teamleading
Новая неделя — новый кейс.
——————————————————————
Вы менеджер команды, которая разрабатывает мобильное B2C-приложение. Команда небольшая: 3 бэкендера, 2 Flutter-разработчика и 1 QA. Дизайн — на аутсорсе.
Полгода назад вы пообещали регулярные релизы каждый спринт. Но до цели так и не добежали: в лучшем случае получается раз в месяц. Сценарий всегда один и тот же — две недели «всё идёт по плану», а ближе к концу спринта выясняется, что на тестирование снова нужно больше времени.
В чате уже мемы:
— QA, ну что там?
— Мы же отдали тебе вчера…
— Без релиза бизнес нас съест.
Вы зовёте тестировщика на разговор, чтобы по-честному понять, что ломается.
Версия QA:
Я не торможу тестирование. Я помогаю избежать проблем после релиза.
Когда задача приходит ко мне, я сначала пытаюсь понять, что вообще считается готовым.
Потом — что из этого действительно сделано.
И только потом — тестирую.
Вы просите конкретику. QA открывает последние тикеты.
Тикет №1: «Сделать фильтр по статусам заказов».
В описании — две строчки.
Скрина нет. Поведения нет. Какие статусы? Какие комбинации? Что по умолчанию? Что показываем, если заказов нет? А если у пользователя нет прав?
QA комментирует:
Я пошёл в прод — посмотрел, как сейчас.
Сходил к фронту спросить как должно быть.
Потом к бэку — какие статусы вообще существуют.
Потом выяснилось, что дизайн ещё не финальный.
А в чате уже после передачи в тестирование написали: «ой, ещё надо чтобы работало в отчётах»
Тикет №2: «Сделать как раньше, только лучше».
Вместо требований — ссылка на переписку на 120 сообщений, где решения перемешаны с мемами, и половина нюансов тонет между «давайте так» и «нет, не так».
QA резюмирует:
Если я начну тестировать без понимания, что было и что должно получиться, то получится ерунда.
Поэтому я хожу и уточняю требования.
Вы выходите из разговора с ощущением, что где-то есть системный перекос.
С одной стороны — разработчики уверены, что отдали «готовое».
С другой — QA уверен, что «готового» в задаче не видно.
И итог каждый раз одинаковый: релиз разваливается в конце спринта — и вас это больше не устраивает.
Итак, что вы будете делать дальше?
#кейсы@teamleading
❤9🔥6
Ко мне в ноябре постучались ребята из cloud.ru и предложили поучаствовать в их проекте. Я сначала отказался, но они были настойчивы и аккуратно намекали, что я не пожалею.
Что ж. Не пожалел.
Ребята из Cloud.ru запустили необычный спецпроект в коллаборации с дизайнерской студией .solutions: сделали лимитированную коллекцию одежды к запуску платформы для работы с GenAI.
Мне досталась одна такая куртка — и я, честно, охренел от качества. Это не «мерч», а нормальная тёплая осенняя куртка, которую реально хочется носить (в Петербурге — особенно).
В своём блоге я часто разбираю кейсы про управление людьми, и вот такие подарки — отличный пример того, как выглядит поощрение в нематериальной форме.
К посту приложил рендер и фото на одном из «человечков». Надеюсь, когда-нибудь он тоже принесёт с работы что-нибудь настолько же заботливо сделанное.
P.S. Подарок пришёл в двух частях — про вторую расскажу чуть позже 🙂
Что ж. Не пожалел.
Ребята из Cloud.ru запустили необычный спецпроект в коллаборации с дизайнерской студией .solutions: сделали лимитированную коллекцию одежды к запуску платформы для работы с GenAI.
Мне досталась одна такая куртка — и я, честно, охренел от качества. Это не «мерч», а нормальная тёплая осенняя куртка, которую реально хочется носить (в Петербурге — особенно).
В своём блоге я часто разбираю кейсы про управление людьми, и вот такие подарки — отличный пример того, как выглядит поощрение в нематериальной форме.
К посту приложил рендер и фото на одном из «человечков». Надеюсь, когда-нибудь он тоже принесёт с работы что-нибудь настолько же заботливо сделанное.
P.S. Подарок пришёл в двух частях — про вторую расскажу чуть позже 🙂
☃13❤10😁2
QA опять тормозит релиз. Разбор
В этот раз в комментах получилось прям хорошо. Расскажу свою версию.
Я на 100% согласен с общим мнением из комментов: проблема здесь не в QA как в человеке, а в процессе. Вопрос только — в каком именно: в delivery или… в найме и онбординге. Да-да, пу-пу-пу, вторую сторону почти никто не упомянул.
Но это объяснимо. Чаще всего подобные истории действительно лечатся через изменение delivery. И идея, которая мне откликается больше всего, — shift left: вовлекать QA раньше, на этапах до разработки.
Если QA действительно так думает и так формулирует, это, кстати, профиль будущего менеджера: он не просто «проверяет», он восстанавливает картину проекта и ищет, где она ломается.
И да, тут очень много вопросов к менеджеру проекта. И к тому, справляется ли он вообще со своей частью работы. То есть к вам 😅
Варианты «давайте введём требования или чек-лист передачи задачи в тест» я допускаю, но честно — редко видел, чтобы это лечило первопричину. Чаще это превращается в бюрократию и усиливает расслоение: «это ваша зона», «нет, это ваша», и релизу, и команде от этого легче не становится.
В целом, про delivery и shift left в комментах уже написали много — не буду пересказывать.
Но давайте на секунду повернём камеру в другую сторону.
А QA вообще ок?
Я сейчас не про «он плохой человек», а про рабочую гипотезу: точно ли он справляется с ролью QA — и не маскирует ли этим объяснением свои провалы?
Например:
— после всех этих «приседаний с пониманием контекста» релизы всё равно выезжают с багами;
— QA нестабилен по дисциплине: пропускает стендапы, подключается через раз, с выключенной камерой и без вовлечённости;
— он не пытается улучшать процесс тестирования, а «ждёт идеальных требований».
И ещё одна неприятная деталь: разработчики ведь тоже как-то живут в мире тикетов «две строчки и погнали». Они ревьюят код друг друга, собирают фичи из разрозненных вводных — и, похоже, их это устраивает. Значит, либо они реально умеют восстанавливать контекст (и тогда странно, что QA не может), либо команда привыкла к хаосу и просто компенсирует его героизмом.
Короче: помимо процесса, есть шанс, что проблема — в конкретном исполнителе.
И если вы честно проверили гипотезы (delivery поправили, QA вовлекли раньше, ожидания проговорили), а в результате ничего не меняется — тогда да, вариант «QA не подходит по культуре или по скиллам» тоже возможен.
И тут, конечно, снова вопросы к вам как к менеджеру: а как вы нанимали и онбордили QA? Может быть, нужно чинить и этот процесс тоже.
В этот раз в комментах получилось прям хорошо. Расскажу свою версию.
Я на 100% согласен с общим мнением из комментов: проблема здесь не в QA как в человеке, а в процессе. Вопрос только — в каком именно: в delivery или… в найме и онбординге. Да-да, пу-пу-пу, вторую сторону почти никто не упомянул.
Но это объяснимо. Чаще всего подобные истории действительно лечатся через изменение delivery. И идея, которая мне откликается больше всего, — shift left: вовлекать QA раньше, на этапах до разработки.
Если QA действительно так думает и так формулирует, это, кстати, профиль будущего менеджера: он не просто «проверяет», он восстанавливает картину проекта и ищет, где она ломается.
И да, тут очень много вопросов к менеджеру проекта. И к тому, справляется ли он вообще со своей частью работы. То есть к вам 😅
Варианты «давайте введём требования или чек-лист передачи задачи в тест» я допускаю, но честно — редко видел, чтобы это лечило первопричину. Чаще это превращается в бюрократию и усиливает расслоение: «это ваша зона», «нет, это ваша», и релизу, и команде от этого легче не становится.
В целом, про delivery и shift left в комментах уже написали много — не буду пересказывать.
Но давайте на секунду повернём камеру в другую сторону.
А QA вообще ок?
Я сейчас не про «он плохой человек», а про рабочую гипотезу: точно ли он справляется с ролью QA — и не маскирует ли этим объяснением свои провалы?
Например:
— после всех этих «приседаний с пониманием контекста» релизы всё равно выезжают с багами;
— QA нестабилен по дисциплине: пропускает стендапы, подключается через раз, с выключенной камерой и без вовлечённости;
— он не пытается улучшать процесс тестирования, а «ждёт идеальных требований».
И ещё одна неприятная деталь: разработчики ведь тоже как-то живут в мире тикетов «две строчки и погнали». Они ревьюят код друг друга, собирают фичи из разрозненных вводных — и, похоже, их это устраивает. Значит, либо они реально умеют восстанавливать контекст (и тогда странно, что QA не может), либо команда привыкла к хаосу и просто компенсирует его героизмом.
Короче: помимо процесса, есть шанс, что проблема — в конкретном исполнителе.
И если вы честно проверили гипотезы (delivery поправили, QA вовлекли раньше, ожидания проговорили), а в результате ничего не меняется — тогда да, вариант «QA не подходит по культуре или по скиллам» тоже возможен.
И тут, конечно, снова вопросы к вам как к менеджеру: а как вы нанимали и онбордили QA? Может быть, нужно чинить и этот процесс тоже.
🔥7😱2
Книги 2025 и моя оценка.
Настало время подвести книжные итоги. В этом году я читал меньше, и в итоге остановился на числе 20.
1. Ким Скотт «Радикальная прямота. Как управлять людьми, не теряя человечности». 9/10
Книга про то как быть человекоцентричным управленцем. Писал несколько обзоров на запавшие мне мысли:
— как составить ИПР;
— выстраивание радикально откровенных отношений;
— получать отдавать и помогать;
— общаться каждый день;
— что мотивирует каждого члена команды.
2. Колин Брайар, Билл Карр «Стратегия Amazon. Инструменты бескомпромиссной работы на впечатляющий результат». 9/10
Книга про то как изнутри работает Amazon. Именно из неё поймал инсайд что любая аналитика должна быть в динамике, например. Удивительно, но я не написал разбора.
3. Михаил Шолохов «Тихий дон», 8/10
Книга о том, что такое война, и как при этом живут и думают люди. Читать такое в школе было бы скорее пыткой, а во взрослой жизни, и особенно в текущем моменте, крайне интересно
4. Иван Тургенев, «Му-Му». 6/10.
Барыня и Герасим. Книга о человеческой жестокости
5. Даниел Гоулман «Эмоциональный интеллект: Почему он может значит больше, чем IQ». 5/10.
Очень переоценённая книга, на мой взгляд. Преимущественно книга рассказывает о том как работают эмоции (и эмоциональный интеллект), а не что с ними делать.
6. Икигай «Смысл жизни по-японски». 6/10.
Занятно.
7. Марио Лохнер «Почему никто не рассказал мне этого о деньгах ранее». 4/10.
На всю книгу скорее полторы мысли об инвестициях. Что это не быстро, и что это надо делать.
8. Владимир Короленко «В дурном обществе». 7/10.
Книга о безнадёге, и о человечности.
9. Джон Дорр «Измеряйте самое важное». 9/10.
Как готовить OKR'ы. Делал обзор на эту книгу. Маст рид для тех кто пишет цели.
10. Ричард Фейнман «Вы, конечно, шутите, мистер Фейнман!». 9/10.
Совершенно шикарнейшая биография прекрасного ученого, показывающая, что даже там где по определению должно быть скучно можно жить с интересом
11. Лев Толстой «Кавказский пленник». 5/10.
Ещё одна книга про войну и желание жить.
12. Дженнифер Тидвелл «Разработка интерфейсов. Паттерны проектирования». 8/10.
Отличная книга для фронтендеров и дизайнеров. Обзор.
13. Братья Стругацкие «Понедельник начинается в субботу». 11/10.
Продолжаю читать каждый год
14. Егор Ганин «Как приготовить проект». 8/10.
Хорошая книга про менеджмент с практичными советами. Обзор книги и рассказ про выталкивающие таблицы
15. Ксуксла Красильникова «Не просто устала. Трудная правда о послеродовой депрессии». 6/10.
Хорошая книга для родителей. Обзор.
16. Павел Бажов «Каменный цветок». 3/10.
Не 1 только потому что я с Урала. Для сказок обычно важен вывод, а тут я вроде бы с интересом читал, а вывода просто нет — книга обрывается.
17. Алексей Пименов «Канбан Метод. Базовая практика». 9/10.
Отличная книга для тех кто хочет прокачать свои навыки менеджмента. Обзор ещё пишется
18. Барбара Оакли «Думай как математик». 10/10.
Эту книгу я поставлю на полочку книг, которые буду рекомендовать прочитать всем. Рассказывал про принцип фокуса и расфокуса, а также делал обзор.
19. Кевин Круз «15 секретов управления временем». 8/10.
Местами хорошо, а местами не зашло. Про что писал:
— как повысить шансы на закрепление привычки;
— улучшаем чтение;
— принцип Парето в реальной жизни;
— как учиться говорить «нет»;
и общий обзор книги.
20. Людмила Петрановская «Если с ребёнком трудно». 7/10.
Неплохая книга, есть пара мыслей (например про вопрос «Зачем?»), но показалось что очень длинное введение, а практическая часть наоборот скомкана.
Прошлогодние итоги тут. Делитесь своими списками и открытиями. А так же пишите про какую книгу хотите обзор?
p.s. Легенда:
10 — рекомендую, покупаю и дарю при случае, маст рид
8-9 — отличная книга, маст рид
6-7 — неплохая книга, рекомендую
4-5 — хорошее чтение, вряд ли прочитаю вновь
2-3 — не понравилось
1 — совсем не понравилось, не рекомендую
Настало время подвести книжные итоги. В этом году я читал меньше, и в итоге остановился на числе 20.
1. Ким Скотт «Радикальная прямота. Как управлять людьми, не теряя человечности». 9/10
Книга про то как быть человекоцентричным управленцем. Писал несколько обзоров на запавшие мне мысли:
— как составить ИПР;
— выстраивание радикально откровенных отношений;
— получать отдавать и помогать;
— общаться каждый день;
— что мотивирует каждого члена команды.
2. Колин Брайар, Билл Карр «Стратегия Amazon. Инструменты бескомпромиссной работы на впечатляющий результат». 9/10
Книга про то как изнутри работает Amazon. Именно из неё поймал инсайд что любая аналитика должна быть в динамике, например. Удивительно, но я не написал разбора.
3. Михаил Шолохов «Тихий дон», 8/10
Книга о том, что такое война, и как при этом живут и думают люди. Читать такое в школе было бы скорее пыткой, а во взрослой жизни, и особенно в текущем моменте, крайне интересно
4. Иван Тургенев, «Му-Му». 6/10.
Барыня и Герасим. Книга о человеческой жестокости
5. Даниел Гоулман «Эмоциональный интеллект: Почему он может значит больше, чем IQ». 5/10.
Очень переоценённая книга, на мой взгляд. Преимущественно книга рассказывает о том как работают эмоции (и эмоциональный интеллект), а не что с ними делать.
6. Икигай «Смысл жизни по-японски». 6/10.
Занятно.
7. Марио Лохнер «Почему никто не рассказал мне этого о деньгах ранее». 4/10.
На всю книгу скорее полторы мысли об инвестициях. Что это не быстро, и что это надо делать.
8. Владимир Короленко «В дурном обществе». 7/10.
Книга о безнадёге, и о человечности.
9. Джон Дорр «Измеряйте самое важное». 9/10.
Как готовить OKR'ы. Делал обзор на эту книгу. Маст рид для тех кто пишет цели.
10. Ричард Фейнман «Вы, конечно, шутите, мистер Фейнман!». 9/10.
Совершенно шикарнейшая биография прекрасного ученого, показывающая, что даже там где по определению должно быть скучно можно жить с интересом
11. Лев Толстой «Кавказский пленник». 5/10.
Ещё одна книга про войну и желание жить.
12. Дженнифер Тидвелл «Разработка интерфейсов. Паттерны проектирования». 8/10.
Отличная книга для фронтендеров и дизайнеров. Обзор.
13. Братья Стругацкие «Понедельник начинается в субботу». 11/10.
Продолжаю читать каждый год
14. Егор Ганин «Как приготовить проект». 8/10.
Хорошая книга про менеджмент с практичными советами. Обзор книги и рассказ про выталкивающие таблицы
15. Ксуксла Красильникова «Не просто устала. Трудная правда о послеродовой депрессии». 6/10.
Хорошая книга для родителей. Обзор.
16. Павел Бажов «Каменный цветок». 3/10.
Не 1 только потому что я с Урала. Для сказок обычно важен вывод, а тут я вроде бы с интересом читал, а вывода просто нет — книга обрывается.
17. Алексей Пименов «Канбан Метод. Базовая практика». 9/10.
Отличная книга для тех кто хочет прокачать свои навыки менеджмента. Обзор ещё пишется
18. Барбара Оакли «Думай как математик». 10/10.
Эту книгу я поставлю на полочку книг, которые буду рекомендовать прочитать всем. Рассказывал про принцип фокуса и расфокуса, а также делал обзор.
19. Кевин Круз «15 секретов управления временем». 8/10.
Местами хорошо, а местами не зашло. Про что писал:
— как повысить шансы на закрепление привычки;
— улучшаем чтение;
— принцип Парето в реальной жизни;
— как учиться говорить «нет»;
и общий обзор книги.
20. Людмила Петрановская «Если с ребёнком трудно». 7/10.
Неплохая книга, есть пара мыслей (например про вопрос «Зачем?»), но показалось что очень длинное введение, а практическая часть наоборот скомкана.
Прошлогодние итоги тут. Делитесь своими списками и открытиями. А так же пишите про какую книгу хотите обзор?
p.s. Легенда:
10 — рекомендую, покупаю и дарю при случае, маст рид
8-9 — отличная книга, маст рид
6-7 — неплохая книга, рекомендую
4-5 — хорошее чтение, вряд ли прочитаю вновь
2-3 — не понравилось
1 — совсем не понравилось, не рекомендую
❤13👍9🔥4👏1🎉1
Выбирайте себя
Вот и наступил последний день этого года. Для многих он был непростым. IT-отрасль (и не только) качало из стороны в сторону — и, кажется, в следующем году легче не станет.
Есть фраза, которую повторяют на каждом шагу: «сначала наденьте маску на себя, а потом на ребёнка». В этом году я наконец перестал воспринимать её как лозунг — а осознал и начал применять в своей жизни.
Я мог бы написать много слов про всю жесть и несправедливость, которые происходили вокруг меня. Но кому, кроме меня, это важно? В турбулентные периоды особенно важно смотреть на ситуацию под правильным углом и находить точки опоры.
Зато я точно знаю другое: этот год подарил мне кучу новых знакомств — с очень крутыми людьми, которые поддерживают в трудные минуты и, кстати, уже пишут поздравления..
А ещё я начал понимать что я по-настоящему люблю. Например, концерты и российскую рок-сцену. Пневмослон был в моём списке давно, а Гудтаймс стали открытием года. В следующем — уже в планах polnalyubvi, Астра, Tritia…
Желаю вам в новом году — что бы ни происходило — выбирать себя. И пусть у каждого будет свой способ «делать топчик».
С наступающим ❤️
Вот и наступил последний день этого года. Для многих он был непростым. IT-отрасль (и не только) качало из стороны в сторону — и, кажется, в следующем году легче не станет.
Есть фраза, которую повторяют на каждом шагу: «сначала наденьте маску на себя, а потом на ребёнка». В этом году я наконец перестал воспринимать её как лозунг — а осознал и начал применять в своей жизни.
Я мог бы написать много слов про всю жесть и несправедливость, которые происходили вокруг меня. Но кому, кроме меня, это важно? В турбулентные периоды особенно важно смотреть на ситуацию под правильным углом и находить точки опоры.
Зато я точно знаю другое: этот год подарил мне кучу новых знакомств — с очень крутыми людьми, которые поддерживают в трудные минуты и, кстати, уже пишут поздравления..
А ещё я начал понимать что я по-настоящему люблю. Например, концерты и российскую рок-сцену. Пневмослон был в моём списке давно, а Гудтаймс стали открытием года. В следующем — уже в планах polnalyubvi, Астра, Tritia…
Желаю вам в новом году — что бы ни происходило — выбирать себя. И пусть у каждого будет свой способ «делать топчик».
С наступающим ❤️
🔥34❤🔥15☃9❤1
Сказка «Морозко». Мачеха приказала главной героине — Настеньке — связать два носочка до крика первых петухов и выгнала её на улицу (мол, там прохладнее — лучше думается и вяжется). Настенька никак не успевала и обратилась сначала к петуху, а затем к самому солнцу — чтобы не всходило раньше времени. Солнце услышало… и Настенька уложилась в дедлайн.
Думаете, ей премию выдали? Может, хотя бы похвалили?
Нет. Обругали, насыпали новых задач и напутствовали в духе: «В другой раз я тебе потруднее работу дам».
Как же точно это отражает современность большинства с их целедостижениями 😃
А сказка, хоть и наивная, всё равно прекрасная (хотя бы благодаря легендарной Бабе-Яге Милляра). Ну и новогодняя — самое то.
Думаете, ей премию выдали? Может, хотя бы похвалили?
Нет. Обругали, насыпали новых задач и напутствовали в духе: «В другой раз я тебе потруднее работу дам».
Как же точно это отражает современность большинства с их целедостижениями 😃
А сказка, хоть и наивная, всё равно прекрасная (хотя бы благодаря легендарной Бабе-Яге Милляра). Ну и новогодняя — самое то.
😁25☃6❤3👍2
Сотрудник не вышел на работу
Начнём новый год и первую рабочую неделю с кейса. Сразу оговорюсь: все совпадения случайны.
Вы руководитель команды. Один из сотрудников попросился в отпуск на первую неделю января. Но вы отказали — потому что несколько человек уже «пристегнули» отпуск к новогодним, и вы не готовы отпустить ещё одного. Логика простая: людей мало, задач много.
Вчера, 11 января, этот сотрудник пишет:
«Меня не будет ближайшие три дня — заболел». У вас в компании разрешено до трех дней включительно болеть без больничного.
Но есть нюанс. По запреграмму вы знаете, что ещё вчера сотрудник был на Бали.
Что будете делать?
Ваша задача: подготовиться к разговору с сотрудником и бонусом подумать, как выстроить правила так, чтобы такие ситуации не повторялись.
#кейсы@teamleading
Начнём новый год и первую рабочую неделю с кейса. Сразу оговорюсь: все совпадения случайны.
Вы руководитель команды. Один из сотрудников попросился в отпуск на первую неделю января. Но вы отказали — потому что несколько человек уже «пристегнули» отпуск к новогодним, и вы не готовы отпустить ещё одного. Логика простая: людей мало, задач много.
Вчера, 11 января, этот сотрудник пишет:
«Меня не будет ближайшие три дня — заболел». У вас в компании разрешено до трех дней включительно болеть без больничного.
Но есть нюанс. По запреграмму вы знаете, что ещё вчера сотрудник был на Бали.
Что будете делать?
Ваша задача: подготовиться к разговору с сотрудником и бонусом подумать, как выстроить правила так, чтобы такие ситуации не повторялись.
#кейсы@teamleading
😁17❤2👍2🤯1
Сотрудник не вышел на работу. Мой разбор
Вчерашний кейс снова породил очень бурное обсуждение. Большинство сошлось во мнении, что нельзя опираться исключительно на текущую ситуацию, и отдельно многие осудили практику делать выводы по информации из личных соцсетей — это и глупо, и скользко. В общем, нужно больше контекста, прежде чем что-то делать.
С этим я согласен. И в большинстве случаев выход из ситуации — действительно ничего не делать. Занавес.
Но как же так — а если он и правда обманул?
Ну и что? Если сотрудник свою работу выполняет качественно, в срок и без нареканий, то дайте мне побольше таких «лжецов», пожалуйста 😊
Мне очень помогает мысль, которую Андрей Сумин ещё больше 10 лет назад сформулировал у себя в ЖЖ и которую, как мне кажется, легко докрутить и переложить на рабочие отношения.
Итак доверие человеку и реальность — это матрица из четырёх состояний:
— вам врут, и вы не доверяете — вы всё время ищете поводы, живёте на нервах, в итоге ловите человека, говорите «АГА, я знал», и всем становится хуже;
— вам не врут, а вы не доверяете — самый токсичный вариант: вы просто изводите человека постоянными проверками;
— вам врут, но вы доверяете — несколько лет хорошей работы, затем (возможно) человек где-то попадается, и дальше вопрос снова упирается в результат: если работает хорошо, то… ну и что?
— вам не врут и вы доверяете — win-win.
Отсюда простой вывод: сотрудникам стоит доверять — независимо от того, что вы там и где увидели. А оценивать — по результату и профессиональным скиллам.
И ещё важное. В здоровых рабочих отношениях, если человек реально заболел и при этом осознаёт ответственность, он сделает всё, чтобы либо передать свою часть работы, либо хотя бы минимально быть на связи и не подвести команду. А если смотреть шире, то в здоровых командах люди опираются не столько на формальные графики отпусков, сколько на здравый смысл и взаимную поддержку.
Так вот: если каждый больничный превращается в детектив, а каждые праздники половина команды ± пару дней отсутствует, то это уже не про одного сотрудника. Это про культуру, процессы и зрелость менеджмента.
Вчерашний кейс снова породил очень бурное обсуждение. Большинство сошлось во мнении, что нельзя опираться исключительно на текущую ситуацию, и отдельно многие осудили практику делать выводы по информации из личных соцсетей — это и глупо, и скользко. В общем, нужно больше контекста, прежде чем что-то делать.
С этим я согласен. И в большинстве случаев выход из ситуации — действительно ничего не делать. Занавес.
Но как же так — а если он и правда обманул?
Ну и что? Если сотрудник свою работу выполняет качественно, в срок и без нареканий, то дайте мне побольше таких «лжецов», пожалуйста 😊
Мне очень помогает мысль, которую Андрей Сумин ещё больше 10 лет назад сформулировал у себя в ЖЖ и которую, как мне кажется, легко докрутить и переложить на рабочие отношения.
Итак доверие человеку и реальность — это матрица из четырёх состояний:
— вам врут, и вы не доверяете — вы всё время ищете поводы, живёте на нервах, в итоге ловите человека, говорите «АГА, я знал», и всем становится хуже;
— вам не врут, а вы не доверяете — самый токсичный вариант: вы просто изводите человека постоянными проверками;
— вам врут, но вы доверяете — несколько лет хорошей работы, затем (возможно) человек где-то попадается, и дальше вопрос снова упирается в результат: если работает хорошо, то… ну и что?
— вам не врут и вы доверяете — win-win.
Отсюда простой вывод: сотрудникам стоит доверять — независимо от того, что вы там и где увидели. А оценивать — по результату и профессиональным скиллам.
И ещё важное. В здоровых рабочих отношениях, если человек реально заболел и при этом осознаёт ответственность, он сделает всё, чтобы либо передать свою часть работы, либо хотя бы минимально быть на связи и не подвести команду. А если смотреть шире, то в здоровых командах люди опираются не столько на формальные графики отпусков, сколько на здравый смысл и взаимную поддержку.
Так вот: если каждый больничный превращается в детектив, а каждые праздники половина команды ± пару дней отсутствует, то это уже не про одного сотрудника. Это про культуру, процессы и зрелость менеджмента.
🔥22❤8👍5😁2☃1
Когнитивная нагрузка как метрика здоровья команды
Любой менеджер создаёт вокруг себя деятельность: agile-ритуалы, встречи, статусы, чаты, задачи в трекере и даже банально «быстрые вопросы на минутку».
Опытные менеджеры многие такие вещи делают уже на автомате. А поскольку проще всего «быстро померить» только количество встреч и их длительность, ловушка, в которую можно затянуть команду, часто остается незаметна.
Проблема в том, что почти всё это потребляет внимание. А внимание — конечный ресурс. Если у команды постоянно растекается контекст, растёт количество переключений и появляется ощущение «весь день занят, а результата мало», то виноват в этом скорее всего менеджер (часто не со зла), потому что это он превратился в генератор когнитивной нагрузки.
Когнитивная нагрузка / mental workload — это объём ментальных усилий, которые люди тратят на процессы и коммуникации поверх самой работы. И это то, за чем менеджер обязан следить.
Что создаёт лишнюю нагрузку? Несколько ситуаций, где это не очевидно с ходу.
1️⃣ Бюрократия на входе
Вы хотите упорядочить задачи — и вводите форму из 10 полей перед созданием тикета. И внезапно задача из «перекрасить кнопку, вот макет» превращается в А4: описание, обоснование, риски, критерии, ссылки, согласования…
Вы сняли нагрузку с себя — но не подумали, что каждое поле — это поиск информации, сомнения «а правильно ли я заполнил», дополнительные уточнения и страх ошибиться.
2️⃣ Большие общие встречи «чтобы все были в курсе»
Команда выросла до 15 человек, а вы всё ещё ходите все вместе на созвоны, где половина людей просто слушает. Мотивация понятна: синхронизация, прозрачность, общий контекст.
Но цена — это не только часы синхронного времени, а ещё и «хвост» после встречи: осмыслить, разложить по полочкам, восстановить фокус. Довольно быстро это превращается в «все номинально на встрече, но слушают её как белый шум».
3️⃣ Коммуникация расползлась в сотню чатов
Раньше чатов было 5–10, все друг друга знали, важное легко находилось. Потом чатов стало 100+, часть заброшена, часть живёт своей жизнью — но вы всё равно утром скроллите, чтобы не пропустить важное.
Это постоянная тревога «а вдруг я что-то пропустил». По ощущениям — мелочь. По факту — ежедневный налог.
Все три ситуации не обязательно плохие. Возможно вашей команде норм. Но часто это те самые «на 99% бессмысленные вещи», которые аккуратно сжирают ресурс. Сигнал к этому, когда команда говорит что стало тяжело от потоков информации и что устаёшь ещё до начала работы.
А эпоха ИИ добавила новый слой: мы всё чаще «присутствуем» где-то номинально, а потом догоняем контекст пересказами — как в «глухих телефончиках», только с ростом искажений.
Что обязан делать менеджер?
Я бы сформулировал задачу менеджера так: быть бюджетодержателем внимания команды. Любой процесс, встреча или коммуникационный канал либо экономит когнитивную энергию, либо окупает её (ускоряет решение, уменьшает риски, снижает переделки).
Иначе это просто шум!
Самое простое — позвать людей на встречу «на всякий случай» или создать ещё один чат «для удобства». В такие моменты нужно одёргивать себя и думать, какую цену команда заплатит вниманием.
Менеджер, который следит за когнитивной нагрузкой команды, делает команду быстрее. Каждые три месяца менеджеру нужно проводить когнитивный чекап с команды, а после оптимизировать и резать всё ненужное.
А какие у вас есть советы на этот счёт, интересно послушать.
Любой менеджер создаёт вокруг себя деятельность: agile-ритуалы, встречи, статусы, чаты, задачи в трекере и даже банально «быстрые вопросы на минутку».
Опытные менеджеры многие такие вещи делают уже на автомате. А поскольку проще всего «быстро померить» только количество встреч и их длительность, ловушка, в которую можно затянуть команду, часто остается незаметна.
Проблема в том, что почти всё это потребляет внимание. А внимание — конечный ресурс. Если у команды постоянно растекается контекст, растёт количество переключений и появляется ощущение «весь день занят, а результата мало», то виноват в этом скорее всего менеджер (часто не со зла), потому что это он превратился в генератор когнитивной нагрузки.
Когнитивная нагрузка / mental workload — это объём ментальных усилий, которые люди тратят на процессы и коммуникации поверх самой работы. И это то, за чем менеджер обязан следить.
Что создаёт лишнюю нагрузку? Несколько ситуаций, где это не очевидно с ходу.
Вы хотите упорядочить задачи — и вводите форму из 10 полей перед созданием тикета. И внезапно задача из «перекрасить кнопку, вот макет» превращается в А4: описание, обоснование, риски, критерии, ссылки, согласования…
Вы сняли нагрузку с себя — но не подумали, что каждое поле — это поиск информации, сомнения «а правильно ли я заполнил», дополнительные уточнения и страх ошибиться.
Команда выросла до 15 человек, а вы всё ещё ходите все вместе на созвоны, где половина людей просто слушает. Мотивация понятна: синхронизация, прозрачность, общий контекст.
Но цена — это не только часы синхронного времени, а ещё и «хвост» после встречи: осмыслить, разложить по полочкам, восстановить фокус. Довольно быстро это превращается в «все номинально на встрече, но слушают её как белый шум».
Раньше чатов было 5–10, все друг друга знали, важное легко находилось. Потом чатов стало 100+, часть заброшена, часть живёт своей жизнью — но вы всё равно утром скроллите, чтобы не пропустить важное.
Это постоянная тревога «а вдруг я что-то пропустил». По ощущениям — мелочь. По факту — ежедневный налог.
Все три ситуации не обязательно плохие. Возможно вашей команде норм. Но часто это те самые «на 99% бессмысленные вещи», которые аккуратно сжирают ресурс. Сигнал к этому, когда команда говорит что стало тяжело от потоков информации и что устаёшь ещё до начала работы.
А эпоха ИИ добавила новый слой: мы всё чаще «присутствуем» где-то номинально, а потом догоняем контекст пересказами — как в «глухих телефончиках», только с ростом искажений.
Что обязан делать менеджер?
Я бы сформулировал задачу менеджера так: быть бюджетодержателем внимания команды. Любой процесс, встреча или коммуникационный канал либо экономит когнитивную энергию, либо окупает её (ускоряет решение, уменьшает риски, снижает переделки).
Иначе это просто шум!
Самое простое — позвать людей на встречу «на всякий случай» или создать ещё один чат «для удобства». В такие моменты нужно одёргивать себя и думать, какую цену команда заплатит вниманием.
Менеджер, который следит за когнитивной нагрузкой команды, делает команду быстрее. Каждые три месяца менеджеру нужно проводить когнитивный чекап с команды, а после оптимизировать и резать всё ненужное.
А какие у вас есть советы на этот счёт, интересно послушать.
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥19❤5
Как измерить когнитивную нагрузку команды?
Вчера я рассказывал про когнитивную нагрузку и про то, что менеджер является бюджетодержателем внимания команды. Но что вообще с этим делать и как это вообще «пощупать»?
Есть разные инструменты измерения рабочей нагрузки, я сегодня остановлюсь на NASA-TLX (Task Load indeX). Он не пытается дать «объективное число», но помогает разложить нагрузку по источникам: где давит время, где бесит процесс, где мозг «кипит».
В оригинале TLX это оценка по шести шкалам и аггрегация в общий индекс нагрузки. Шкалы такие:
— ментальная сложность (mental demand);
— физическая сложность (physical demand);
— давление по времени (temporal demand);
— производительность (performance);
— усилия (effort);
— уровень фрустрация (frustration level)
TLX придумали для оценки нагрузки при выполнении задач (в том числе в авиации/симуляциях), но его легко применять в менеджерской реальности, если считать «задачей» не полёт, а, например, рабочую неделю команды или итерацию или выполнение цели.
Как? Каждую итерацию (неделя, спринт) вы запускаете TLX-пульс. Каждый член команды отвечает по шкале 0–10. Сами вопросы тут вторичны и формулировки можно настраивать под себя, важна цель.
— Ментальная сложность: насколько «мозг кипел» от количества контекстов, правил, входящих, уточнений? Какой объем умственной деятельности потребовался (например, размышлений, принятий решений, расчетов, запоминаний, поиска и т.д.)?
— Физическая сложность: какая физическая активность требовалась (например, толкание, подтягивания, повороты, хождение и т.д.)?
Я понимаю что для многих кто работает в офисах это всё скорее не применимо, поэтому этот фактор можно опускать.
— Давление по времени: насколько давило время, срочность, дедлайны, «вчера надо»?
— Производителность: насколько ты НЕ доволен тем, что получилось сделать за неделю при текущей нагрузке?
— Усилия: на сколько сложной ты считаешь свою работу? На сколько сложно тебе далось удержание своей текущей работы в рамках требуемой производительности?
— Уровень фрустрации: насколько бесили процессы/коммуникации, было чувство стресса?
Дальше считаем среднее/медиану по людям и по шкалам. В оригинальном TLX есть ещё веса через попарные сравнения, но для начала обычно достаточно «raw TLX» (без весов.)
Как этим пользоваться?
— Смотрим динамику (сегодня vs месяц назад), и не сравниваем людей друг с другом.
— Смотрим не только общий индекс, но и конкретные ситуации, например:
— выросло давление по времени, значит перегрели срочностью, не хватает буфера/планирования
— вырос уровень фрустрации -> что-то произошло что процессы/коммуникации стали бесить, пора пересмотреть их
— выросла ментальная нагрузка при том же объёме задач -> возможно расползлись контексты (чаты, созвоны, согласования)
— упала производительность при росте усилий -> классический сигнал о том что «весь день занят, но результата нет»
И самое важное: TLX-пульс делает видимым то, что обычно ощущается, но плохо формализуется. Мы легко считаем количество встреч, но плохо замечаем изменение «налога на внимание». Этот инструмент помогает вовремя увидеть, что процессы ушли куда-то не туда — и вернуться в среду, где команде будет проще делать свою работу.
Вчера я рассказывал про когнитивную нагрузку и про то, что менеджер является бюджетодержателем внимания команды. Но что вообще с этим делать и как это вообще «пощупать»?
Есть разные инструменты измерения рабочей нагрузки, я сегодня остановлюсь на NASA-TLX (Task Load indeX). Он не пытается дать «объективное число», но помогает разложить нагрузку по источникам: где давит время, где бесит процесс, где мозг «кипит».
В оригинале TLX это оценка по шести шкалам и аггрегация в общий индекс нагрузки. Шкалы такие:
— ментальная сложность (mental demand);
— физическая сложность (physical demand);
— давление по времени (temporal demand);
— производительность (performance);
— усилия (effort);
— уровень фрустрация (frustration level)
TLX придумали для оценки нагрузки при выполнении задач (в том числе в авиации/симуляциях), но его легко применять в менеджерской реальности, если считать «задачей» не полёт, а, например, рабочую неделю команды или итерацию или выполнение цели.
Как? Каждую итерацию (неделя, спринт) вы запускаете TLX-пульс. Каждый член команды отвечает по шкале 0–10. Сами вопросы тут вторичны и формулировки можно настраивать под себя, важна цель.
— Ментальная сложность: насколько «мозг кипел» от количества контекстов, правил, входящих, уточнений? Какой объем умственной деятельности потребовался (например, размышлений, принятий решений, расчетов, запоминаний, поиска и т.д.)?
— Физическая сложность: какая физическая активность требовалась (например, толкание, подтягивания, повороты, хождение и т.д.)?
Я понимаю что для многих кто работает в офисах это всё скорее не применимо, поэтому этот фактор можно опускать.
— Давление по времени: насколько давило время, срочность, дедлайны, «вчера надо»?
— Производителность: насколько ты НЕ доволен тем, что получилось сделать за неделю при текущей нагрузке?
— Усилия: на сколько сложной ты считаешь свою работу? На сколько сложно тебе далось удержание своей текущей работы в рамках требуемой производительности?
— Уровень фрустрации: насколько бесили процессы/коммуникации, было чувство стресса?
Дальше считаем среднее/медиану по людям и по шкалам. В оригинальном TLX есть ещё веса через попарные сравнения, но для начала обычно достаточно «raw TLX» (без весов.)
Как этим пользоваться?
— Смотрим динамику (сегодня vs месяц назад), и не сравниваем людей друг с другом.
— Смотрим не только общий индекс, но и конкретные ситуации, например:
— выросло давление по времени, значит перегрели срочностью, не хватает буфера/планирования
— вырос уровень фрустрации -> что-то произошло что процессы/коммуникации стали бесить, пора пересмотреть их
— выросла ментальная нагрузка при том же объёме задач -> возможно расползлись контексты (чаты, созвоны, согласования)
— упала производительность при росте усилий -> классический сигнал о том что «весь день занят, но результата нет»
И самое важное: TLX-пульс делает видимым то, что обычно ощущается, но плохо формализуется. Мы легко считаем количество встреч, но плохо замечаем изменение «налога на внимание». Этот инструмент помогает вовремя увидеть, что процессы ушли куда-то не туда — и вернуться в среду, где команде будет проще делать свою работу.
🔥21
Затягивание сроков?
У вас многофункциональная продуктовая команда. Большинство ролей закрыто несколькими людьми, но есть одна уникальная роль — такая, где знания нельзя компенсировать просто почитав книжку, и где человек очень близко к delivery.
Чтобы было проще представить пусть это будет роль не из IT. Вы медицинский стартап, и в команде есть медик, который участвует в ключевых решениях и влияет на то, как команда двигает задачи.
До недавнего времени медик был один. По вашей оценке он уверенный мидл, и в ближайшее время вы планировали поднять его до мидл+.
Свои задачи он делает «по своим оценкам»: сроки обычно совпадают с тем, что он сам обещает.
Но недавно вы открыли ставку, а затем наняли второго медика (тоже мидла).
И внезапно выясняется, что новый медик:
— делает сопоставимые задачи примерно в 2 раза быстрее,
— оставляет больше артефактов (документация, заметки, протоколы, решения),
— из-за этого команде разработки местами стало даже проще делать свою работу.
Вопрос традиционный: что будете делать?
#кейсы@teamleading
У вас многофункциональная продуктовая команда. Большинство ролей закрыто несколькими людьми, но есть одна уникальная роль — такая, где знания нельзя компенсировать просто почитав книжку, и где человек очень близко к delivery.
Чтобы было проще представить пусть это будет роль не из IT. Вы медицинский стартап, и в команде есть медик, который участвует в ключевых решениях и влияет на то, как команда двигает задачи.
До недавнего времени медик был один. По вашей оценке он уверенный мидл, и в ближайшее время вы планировали поднять его до мидл+.
Свои задачи он делает «по своим оценкам»: сроки обычно совпадают с тем, что он сам обещает.
Но недавно вы открыли ставку, а затем наняли второго медика (тоже мидла).
И внезапно выясняется, что новый медик:
— делает сопоставимые задачи примерно в 2 раза быстрее,
— оставляет больше артефактов (документация, заметки, протоколы, решения),
— из-за этого команде разработки местами стало даже проще делать свою работу.
Вопрос традиционный: что будете делать?
#кейсы@teamleading
😁5🔥4