О, спорт, ты…?
Конец года — время подводить итоги. Поэтому ближайшие несколько постов будут рефлексией моих результатов за год. Первый — про то, как я приучил себя к спорту.
С детства у меня со спортом не задалось. Не то чтобы я им не занимался. Дзюдо, хоккей, футбол, шахматы, баскетбол, бассейн, триатлон… Моя мама (самая лучшая на свете, как и у вас, надеюсь) никогда не заставляла «терпеть через не могу». Не идёт — окей, попробуем другое. В итоге я мало где задерживался дольше года и так и не “впитал” в себя спортивную дисциплину.
После университета я сразу попал в хорошую компанию, где были отличные кофепойнты, изобилующие печеньками. Если бы не привычка быстро ходить, то, вероятно, я был бы ещё круглее к 30. Но в какой-то момент я поймал себя на одышке при подъёме по лестнице — и понял, что дальше так продолжаться не может.
Нет, окей, я и до 30 пытался ходить в спортзал. Начиналось обычно бодро: месяц, иногда два регулярных тренировок, иногда даже групповые. Но потом — первые результаты заканчиваются, наступает плато… и привет, демотивация.
Рефлексируя, я понимаю: это ключ к тому, почему я нигде надолго не задерживался. Любому из нас нужно ощущение, что становится лучше. А когда прогресса не видно, а тренер (или внутренний голос) говорит только «работай усерднее», мотивации не прибавляется. Наверное, поэтому в детстве тоже не сложилось: не было того самого «мотивирующего тренера», были в основном те, кто орал «быстрее, выше, сильнее!».
Эту проблему я стал решать от обратного — и начал брать индивидуальные тренировки. Тут и внимание тренера целиком твоё, и обратная связь, и ощущение, что ты не просто «что-то делаешь в зале», а двигаешься по понятному плану.
Тут же я открыл второй инсайт: чтобы втянуться, нужно какое время. Не верьте про то что привычку можно ввести за 21 день, исследования показывают что в среднем на это требуется 66 дней. Индивидуалки также помогают не только втянуться и заиметь план тренировок, но и освоиться с оборудованием, понять технику выполнения упражнений и вообще перестать чувствовать себя человеком, который случайно зашёл не в ту дверь. Плюс запись на персоналку отлично бьёт по прокрастинации: ты понимаешь, что подводишь конкретного человека. А для него твоя тренировка — это буквально его доход.
Тренер решает и ещё одну скрытую проблему — неловкость в зале, особенно если вы (как и я до недавних пор) подвержены синдрому «на меня все смотрят» (Эффект прожектора). Несмотря на то что исследования (да и личный опыт) чаще всего показывают, что всем всё равно, но мозгу это не объяснишь. А тут как бы получается что это не я маленький вес беру — это тренер так назначил.
Ну и последнее — видеть прогресс. Многие ведут записные книжки: там реально видно, что неделю назад ты делал 10 отжиманий, а сейчас — 12. Я лично использую приложение Fitness Online: оно хранит историю тренировок, и можно сравнить веса/подходы/повторы с прошлыми разами.
Приложение, кстати, решает и другую проблему — планирование тренировок. Ты выбираешь цель, и вот готовый план. Какое-то из упражнение не заходит, тяжело — можно выбрать другое. Это оказалось очень удобно, а годовая подписка на приложение стоит столько же сколько одна персоналка.
А что делать, если прогресса в цифрах нет? И тут неожиданно врывается Whoop (или любой health-трекер). Я купил Whoop совсем недавно, но он дал мне другое измерение прогресса: видимость того, как тренировки влияют на качество жизни.
Я потренировался -> и потом даже 6 часов сна могут быть качественными. А метрика HRV высокая.
Я выпил пару бокалов вина/пива -> сон рваный, и даже при 9 часов сна весь день сонный.
Подытоживая, вот мои инсайты, которые помогают мне оставаться в спорте:
1. Трекать прогресс — в приложении, или в записной книжке. Идеально если иметь оцифрованными не только тренировки, но и то как это влияет на сон и другие параметры жизни.
2. Персоналки на входе, чтобы привыкнуть к залу и втянуться.
3. Разгрузить мозг от вопроса «что я делаю сегодня» — снова персоналки или приложение с программой
Главный спортивный итог года — 109 тренировок.
А как у вас со спортом?
Конец года — время подводить итоги. Поэтому ближайшие несколько постов будут рефлексией моих результатов за год. Первый — про то, как я приучил себя к спорту.
С детства у меня со спортом не задалось. Не то чтобы я им не занимался. Дзюдо, хоккей, футбол, шахматы, баскетбол, бассейн, триатлон… Моя мама (самая лучшая на свете, как и у вас, надеюсь) никогда не заставляла «терпеть через не могу». Не идёт — окей, попробуем другое. В итоге я мало где задерживался дольше года и так и не “впитал” в себя спортивную дисциплину.
После университета я сразу попал в хорошую компанию, где были отличные кофепойнты, изобилующие печеньками. Если бы не привычка быстро ходить, то, вероятно, я был бы ещё круглее к 30. Но в какой-то момент я поймал себя на одышке при подъёме по лестнице — и понял, что дальше так продолжаться не может.
Нет, окей, я и до 30 пытался ходить в спортзал. Начиналось обычно бодро: месяц, иногда два регулярных тренировок, иногда даже групповые. Но потом — первые результаты заканчиваются, наступает плато… и привет, демотивация.
Рефлексируя, я понимаю: это ключ к тому, почему я нигде надолго не задерживался. Любому из нас нужно ощущение, что становится лучше. А когда прогресса не видно, а тренер (или внутренний голос) говорит только «работай усерднее», мотивации не прибавляется. Наверное, поэтому в детстве тоже не сложилось: не было того самого «мотивирующего тренера», были в основном те, кто орал «быстрее, выше, сильнее!».
Эту проблему я стал решать от обратного — и начал брать индивидуальные тренировки. Тут и внимание тренера целиком твоё, и обратная связь, и ощущение, что ты не просто «что-то делаешь в зале», а двигаешься по понятному плану.
Тут же я открыл второй инсайт: чтобы втянуться, нужно какое время. Не верьте про то что привычку можно ввести за 21 день, исследования показывают что в среднем на это требуется 66 дней. Индивидуалки также помогают не только втянуться и заиметь план тренировок, но и освоиться с оборудованием, понять технику выполнения упражнений и вообще перестать чувствовать себя человеком, который случайно зашёл не в ту дверь. Плюс запись на персоналку отлично бьёт по прокрастинации: ты понимаешь, что подводишь конкретного человека. А для него твоя тренировка — это буквально его доход.
Тренер решает и ещё одну скрытую проблему — неловкость в зале, особенно если вы (как и я до недавних пор) подвержены синдрому «на меня все смотрят» (Эффект прожектора). Несмотря на то что исследования (да и личный опыт) чаще всего показывают, что всем всё равно, но мозгу это не объяснишь. А тут как бы получается что это не я маленький вес беру — это тренер так назначил.
Ну и последнее — видеть прогресс. Многие ведут записные книжки: там реально видно, что неделю назад ты делал 10 отжиманий, а сейчас — 12. Я лично использую приложение Fitness Online: оно хранит историю тренировок, и можно сравнить веса/подходы/повторы с прошлыми разами.
Приложение, кстати, решает и другую проблему — планирование тренировок. Ты выбираешь цель, и вот готовый план. Какое-то из упражнение не заходит, тяжело — можно выбрать другое. Это оказалось очень удобно, а годовая подписка на приложение стоит столько же сколько одна персоналка.
А что делать, если прогресса в цифрах нет? И тут неожиданно врывается Whoop (или любой health-трекер). Я купил Whoop совсем недавно, но он дал мне другое измерение прогресса: видимость того, как тренировки влияют на качество жизни.
Я потренировался -> и потом даже 6 часов сна могут быть качественными. А метрика HRV высокая.
Я выпил пару бокалов вина/пива -> сон рваный, и даже при 9 часов сна весь день сонный.
Подытоживая, вот мои инсайты, которые помогают мне оставаться в спорте:
1. Трекать прогресс — в приложении, или в записной книжке. Идеально если иметь оцифрованными не только тренировки, но и то как это влияет на сон и другие параметры жизни.
2. Персоналки на входе, чтобы привыкнуть к залу и втянуться.
3. Разгрузить мозг от вопроса «что я делаю сегодня» — снова персоналки или приложение с программой
Главный спортивный итог года — 109 тренировок.
А как у вас со спортом?
🔥21👍4❤3
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❤1
Книги 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☃7❤3👍2
Сотрудник не вышел на работу
Начнём новый год и первую рабочую неделю с кейса. Сразу оговорюсь: все совпадения случайны.
Вы руководитель команды. Один из сотрудников попросился в отпуск на первую неделю января. Но вы отказали — потому что несколько человек уже «пристегнули» отпуск к новогодним, и вы не готовы отпустить ещё одного. Логика простая: людей мало, задач много.
Вчера, 11 января, этот сотрудник пишет:
«Меня не будет ближайшие три дня — заболел». У вас в компании разрешено до трех дней включительно болеть без больничного.
Но есть нюанс. По запреграмму вы знаете, что ещё вчера сотрудник был на Бали.
Что будете делать?
Ваша задача: подготовиться к разговору с сотрудником и бонусом подумать, как выстроить правила так, чтобы такие ситуации не повторялись.
#кейсы@teamleading
Начнём новый год и первую рабочую неделю с кейса. Сразу оговорюсь: все совпадения случайны.
Вы руководитель команды. Один из сотрудников попросился в отпуск на первую неделю января. Но вы отказали — потому что несколько человек уже «пристегнули» отпуск к новогодним, и вы не готовы отпустить ещё одного. Логика простая: людей мало, задач много.
Вчера, 11 января, этот сотрудник пишет:
«Меня не будет ближайшие три дня — заболел». У вас в компании разрешено до трех дней включительно болеть без больничного.
Но есть нюанс. По запреграмму вы знаете, что ещё вчера сотрудник был на Бали.
Что будете делать?
Ваша задача: подготовиться к разговору с сотрудником и бонусом подумать, как выстроить правила так, чтобы такие ситуации не повторялись.
#кейсы@teamleading
😁17❤2👍2🤯1
Сотрудник не вышел на работу. Мой разбор
Вчерашний кейс снова породил очень бурное обсуждение. Большинство сошлось во мнении, что нельзя опираться исключительно на текущую ситуацию, и отдельно многие осудили практику делать выводы по информации из личных соцсетей — это и глупо, и скользко. В общем, нужно больше контекста, прежде чем что-то делать.
С этим я согласен. И в большинстве случаев выход из ситуации — действительно ничего не делать. Занавес.
Но как же так — а если он и правда обманул?
Ну и что? Если сотрудник свою работу выполняет качественно, в срок и без нареканий, то дайте мне побольше таких «лжецов», пожалуйста 😊
Мне очень помогает мысль, которую Андрей Сумин ещё больше 10 лет назад сформулировал у себя в ЖЖ и которую, как мне кажется, легко докрутить и переложить на рабочие отношения.
Итак доверие человеку и реальность — это матрица из четырёх состояний:
— вам врут, и вы не доверяете — вы всё время ищете поводы, живёте на нервах, в итоге ловите человека, говорите «АГА, я знал», и всем становится хуже;
— вам не врут, а вы не доверяете — самый токсичный вариант: вы просто изводите человека постоянными проверками;
— вам врут, но вы доверяете — несколько лет хорошей работы, затем (возможно) человек где-то попадается, и дальше вопрос снова упирается в результат: если работает хорошо, то… ну и что?
— вам не врут и вы доверяете — win-win.
Отсюда простой вывод: сотрудникам стоит доверять — независимо от того, что вы там и где увидели. А оценивать — по результату и профессиональным скиллам.
И ещё важное. В здоровых рабочих отношениях, если человек реально заболел и при этом осознаёт ответственность, он сделает всё, чтобы либо передать свою часть работы, либо хотя бы минимально быть на связи и не подвести команду. А если смотреть шире, то в здоровых командах люди опираются не столько на формальные графики отпусков, сколько на здравый смысл и взаимную поддержку.
Так вот: если каждый больничный превращается в детектив, а каждые праздники половина команды ± пару дней отсутствует, то это уже не про одного сотрудника. Это про культуру, процессы и зрелость менеджмента.
Вчерашний кейс снова породил очень бурное обсуждение. Большинство сошлось во мнении, что нельзя опираться исключительно на текущую ситуацию, и отдельно многие осудили практику делать выводы по информации из личных соцсетей — это и глупо, и скользко. В общем, нужно больше контекста, прежде чем что-то делать.
С этим я согласен. И в большинстве случаев выход из ситуации — действительно ничего не делать. Занавес.
Но как же так — а если он и правда обманул?
Ну и что? Если сотрудник свою работу выполняет качественно, в срок и без нареканий, то дайте мне побольше таких «лжецов», пожалуйста 😊
Мне очень помогает мысль, которую Андрей Сумин ещё больше 10 лет назад сформулировал у себя в ЖЖ и которую, как мне кажется, легко докрутить и переложить на рабочие отношения.
Итак доверие человеку и реальность — это матрица из четырёх состояний:
— вам врут, и вы не доверяете — вы всё время ищете поводы, живёте на нервах, в итоге ловите человека, говорите «АГА, я знал», и всем становится хуже;
— вам не врут, а вы не доверяете — самый токсичный вариант: вы просто изводите человека постоянными проверками;
— вам врут, но вы доверяете — несколько лет хорошей работы, затем (возможно) человек где-то попадается, и дальше вопрос снова упирается в результат: если работает хорошо, то… ну и что?
— вам не врут и вы доверяете — win-win.
Отсюда простой вывод: сотрудникам стоит доверять — независимо от того, что вы там и где увидели. А оценивать — по результату и профессиональным скиллам.
И ещё важное. В здоровых рабочих отношениях, если человек реально заболел и при этом осознаёт ответственность, он сделает всё, чтобы либо передать свою часть работы, либо хотя бы минимально быть на связи и не подвести команду. А если смотреть шире, то в здоровых командах люди опираются не столько на формальные графики отпусков, сколько на здравый смысл и взаимную поддержку.
Так вот: если каждый больничный превращается в детектив, а каждые праздники половина команды ± пару дней отсутствует, то это уже не про одного сотрудника. Это про культуру, процессы и зрелость менеджмента.
🔥23❤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🔥20❤5👍1
Как измерить когнитивную нагрузку команды?
Вчера я рассказывал про когнитивную нагрузку и про то, что менеджер является бюджетодержателем внимания команды. Но что вообще с этим делать и как это вообще «пощупать»?
Есть разные инструменты измерения рабочей нагрузки, я сегодня остановлюсь на 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-пульс делает видимым то, что обычно ощущается, но плохо формализуется. Мы легко считаем количество встреч, но плохо замечаем изменение «налога на внимание». Этот инструмент помогает вовремя увидеть, что процессы ушли куда-то не туда — и вернуться в среду, где команде будет проще делать свою работу.
🔥25
Затягивание сроков?
У вас многофункциональная продуктовая команда. Большинство ролей закрыто несколькими людьми, но есть одна уникальная роль — такая, где знания нельзя компенсировать просто почитав книжку, и где человек очень близко к delivery.
Чтобы было проще представить пусть это будет роль не из IT. Вы медицинский стартап, и в команде есть медик, который участвует в ключевых решениях и влияет на то, как команда двигает задачи.
До недавнего времени медик был один. По вашей оценке он уверенный мидл, и в ближайшее время вы планировали поднять его до мидл+.
Свои задачи он делает «по своим оценкам»: сроки обычно совпадают с тем, что он сам обещает.
Но недавно вы открыли ставку, а затем наняли второго медика (тоже мидла).
И внезапно выясняется, что новый медик:
— делает сопоставимые задачи примерно в 2 раза быстрее,
— оставляет больше артефактов (документация, заметки, протоколы, решения),
— из-за этого команде разработки местами стало даже проще делать свою работу.
Вопрос традиционный: что будете делать?
#кейсы@teamleading
У вас многофункциональная продуктовая команда. Большинство ролей закрыто несколькими людьми, но есть одна уникальная роль — такая, где знания нельзя компенсировать просто почитав книжку, и где человек очень близко к delivery.
Чтобы было проще представить пусть это будет роль не из IT. Вы медицинский стартап, и в команде есть медик, который участвует в ключевых решениях и влияет на то, как команда двигает задачи.
До недавнего времени медик был один. По вашей оценке он уверенный мидл, и в ближайшее время вы планировали поднять его до мидл+.
Свои задачи он делает «по своим оценкам»: сроки обычно совпадают с тем, что он сам обещает.
Но недавно вы открыли ставку, а затем наняли второго медика (тоже мидла).
И внезапно выясняется, что новый медик:
— делает сопоставимые задачи примерно в 2 раза быстрее,
— оставляет больше артефактов (документация, заметки, протоколы, решения),
— из-за этого команде разработки местами стало даже проще делать свою работу.
Вопрос традиционный: что будете делать?
#кейсы@teamleading
😁8🔥6
Кейс «Затягивание сроков?» — разбор
Да, я тоже немного подзатянул с разбором: неделя была ударная, времени — впритык. Но кейс слишком хороший, чтобы его пропустить.
Итак, это история не про то чтобы сравнить двух мидлов и вывести кто лучше, а кто идёт на улицу, это история про калибровку ожиданий, уровни (грейды) и то, как система переваривает сильных.
Я бы разложил кейс на два вопроса:
— что делать с новичком?
— что делать со «старичком»
1️⃣ Что делать с новичком
Новичок делает задачи примерно в 2 раза быстрее человека того же грейда. Это факт.
Тут легко сделать неправильный вывод «старичок слабее». Надо проверить гипотезы.
Гипотеза А: мы недооценили новичка на входе
Вполне нормальная ситуация. Интервью это всё-таки шумный инструмент, плюс первый месяц часто идёт на «дофамине новой работы».
Если тренд устойчивый, то через некоторое время (и если ваша система мотивации в компании это позволяет) просто поднимаем новичку уровень и компенсацию.
Чтобы подкрепить тренд даём новичку задачи уровнем выше / с неопределённостью и ответственностью — и смотрим, держит ли он качество, коммуникацию и решения, а не только скорость.
Гипотеза Б: сравнение «нечестное»
Новичок мог получать более «чистые» задачи (ещё очень часто их называют «задачи на испытательный срок» для вкатывания), а старичок тащит то, что не видно: кучу контекстов, согласований, тушение пожаров, сложных стейкхолдеров и легаси в конце концов.
Тут путают output (видимый результат) и impact (реальная польза для продукта/команды).
Тут надо честно взглянуть на наборы задач и постараться выровнять их. То есть догрузить новичка и снять задачи со старичка.
Вне зависимости от того какую гипотезу вы считаете более правдоподной важно ещё и проговорить риски бездействия.
Если оставить всё как есть, то с высокой вероятностью «система откатит новичка до среднего», то есть локальная эффективность потонет в системных ограничениях. А сам новичок либо замедлится, либо выгорит и/или уйдёт туда, где среда поддерживает темп.
Сам факт того что такое случилось — это сигнал о том что нужно включать прозрачность, но не про людей, а про ожидания:
— то есть что значит «мидл» в этой уникальной роли,
— какие артефакты считаются стандартом,
— что должно появиться, чтобы уровень стал выше.
И это ваша работа.
2️⃣ Что делать со «старичком»?
Допустим что все же вы склонны к варианту, что «старичок» заскучал, расслабился, привык. Увольнять? Почти никогда такие увольнения не бывают верным решением — особенно если роль уникальная и человек носит критичный контекст.
Но и делать вид, что ничего не произошло, тоже нельзя. Нужно соотнести ожидания от уровня с фактической работой.
Важно: «мы планировали повысить» ≠ «обязаны повысить».
Повышение — это подтверждение соответствия ожиданиям следующего уровня, а не награда за стаж или уникальность.
Что тут надо сделать:
— выровнять уровень задач у новичка и старичка и посмотреть как летит хотя бы 2–4 недели (а вдруг потянет)
— зафиксировать стандарт артефактов для роли (то есть скорее всего расширить его и явно объяснить «старичку» что у нас поменялись требования)
— разгрузить старичка от шума, когда он был один в роли и все потоки коммуникации шли в него.
— сделать индивидуальный план развития старичка с конкретными ожиданиями
— пересмотреть (если вообще есть) модель компетенций для этой роли (часто это сигнал что она описана плохо)
— если политика позволяет — иногда можно подтянуть компенсацию без изменения формального уровня
Главный вывод тут такой, что приход сильного новичка привел вас к ситуации, когда можно поменять систему и/или признать ошибку найма, или не делать ничего и пустить на самотёк... В общем поймите вы будете подтягивать систему под сильного или сильного под систему?
Да, я тоже немного подзатянул с разбором: неделя была ударная, времени — впритык. Но кейс слишком хороший, чтобы его пропустить.
Итак, это история не про то чтобы сравнить двух мидлов и вывести кто лучше, а кто идёт на улицу, это история про калибровку ожиданий, уровни (грейды) и то, как система переваривает сильных.
Я бы разложил кейс на два вопроса:
— что делать с новичком?
— что делать со «старичком»
Новичок делает задачи примерно в 2 раза быстрее человека того же грейда. Это факт.
Тут легко сделать неправильный вывод «старичок слабее». Надо проверить гипотезы.
Гипотеза А: мы недооценили новичка на входе
Вполне нормальная ситуация. Интервью это всё-таки шумный инструмент, плюс первый месяц часто идёт на «дофамине новой работы».
Если тренд устойчивый, то через некоторое время (и если ваша система мотивации в компании это позволяет) просто поднимаем новичку уровень и компенсацию.
Чтобы подкрепить тренд даём новичку задачи уровнем выше / с неопределённостью и ответственностью — и смотрим, держит ли он качество, коммуникацию и решения, а не только скорость.
Гипотеза Б: сравнение «нечестное»
Новичок мог получать более «чистые» задачи (ещё очень часто их называют «задачи на испытательный срок» для вкатывания), а старичок тащит то, что не видно: кучу контекстов, согласований, тушение пожаров, сложных стейкхолдеров и легаси в конце концов.
Тут путают output (видимый результат) и impact (реальная польза для продукта/команды).
Тут надо честно взглянуть на наборы задач и постараться выровнять их. То есть догрузить новичка и снять задачи со старичка.
Вне зависимости от того какую гипотезу вы считаете более правдоподной важно ещё и проговорить риски бездействия.
Если оставить всё как есть, то с высокой вероятностью «система откатит новичка до среднего», то есть локальная эффективность потонет в системных ограничениях. А сам новичок либо замедлится, либо выгорит и/или уйдёт туда, где среда поддерживает темп.
Сам факт того что такое случилось — это сигнал о том что нужно включать прозрачность, но не про людей, а про ожидания:
— то есть что значит «мидл» в этой уникальной роли,
— какие артефакты считаются стандартом,
— что должно появиться, чтобы уровень стал выше.
И это ваша работа.
Допустим что все же вы склонны к варианту, что «старичок» заскучал, расслабился, привык. Увольнять? Почти никогда такие увольнения не бывают верным решением — особенно если роль уникальная и человек носит критичный контекст.
Но и делать вид, что ничего не произошло, тоже нельзя. Нужно соотнести ожидания от уровня с фактической работой.
Важно: «мы планировали повысить» ≠ «обязаны повысить».
Повышение — это подтверждение соответствия ожиданиям следующего уровня, а не награда за стаж или уникальность.
Что тут надо сделать:
— выровнять уровень задач у новичка и старичка и посмотреть как летит хотя бы 2–4 недели (а вдруг потянет)
— зафиксировать стандарт артефактов для роли (то есть скорее всего расширить его и явно объяснить «старичку» что у нас поменялись требования)
— разгрузить старичка от шума, когда он был один в роли и все потоки коммуникации шли в него.
— сделать индивидуальный план развития старичка с конкретными ожиданиями
— пересмотреть (если вообще есть) модель компетенций для этой роли (часто это сигнал что она описана плохо)
— если политика позволяет — иногда можно подтянуть компенсацию без изменения формального уровня
Главный вывод тут такой, что приход сильного новичка привел вас к ситуации, когда можно поменять систему и/или признать ошибку найма, или не делать ничего и пустить на самотёк... В общем поймите вы будете подтягивать систему под сильного или сильного под систему?
Please open Telegram to view this post
VIEW IN TELEGRAM
6🔥16❤13
Тимлид не тимлид?
Вы — новый PM/проджект в продуктовой команде разработки.
9 месяцев назад из команды ушёл тимлид. Официально роль так и не закрыли. Часть функций тимлида взял на себя старший разработчик: он принимает технические решения, управляет бэклогом и приоритизацией, а так же отвечает за деливери, то есть работает с релизами и синхронизацией со смежниками.
Вы начинаете изучать что есть, проводите: 1:1 с ключевыми людьми, общий разговор с командой, смотрите какие артефакты имеются. Картина вырисовывается такая.
Старший разработчик говорит:
— «Я де-факто тимлид. Без меня команда бы развалилась».
— «За эти месяцы всё стало лучше: меньше хаоса, больше предсказуемости, релизы идут по плану».
— «От тебя нужно в основном одно — нормально формировать и приоритизировать бэклог».
Команда говорит другое:
— «Процессы развалены и держатся на одном человеке».
— «Этот человек непрозрачен в решениях: почему делаем так — непонятно, обсуждений нет».
— «Многое делается медленно».
Один из разработчиков признаётся, что думает уходить, потому что устал от неэффективности.
Вопрос: что и как будете делать?
#кейсы@teamleading
Вы — новый PM/проджект в продуктовой команде разработки.
9 месяцев назад из команды ушёл тимлид. Официально роль так и не закрыли. Часть функций тимлида взял на себя старший разработчик: он принимает технические решения, управляет бэклогом и приоритизацией, а так же отвечает за деливери, то есть работает с релизами и синхронизацией со смежниками.
Вы начинаете изучать что есть, проводите: 1:1 с ключевыми людьми, общий разговор с командой, смотрите какие артефакты имеются. Картина вырисовывается такая.
Старший разработчик говорит:
— «Я де-факто тимлид. Без меня команда бы развалилась».
— «За эти месяцы всё стало лучше: меньше хаоса, больше предсказуемости, релизы идут по плану».
— «От тебя нужно в основном одно — нормально формировать и приоритизировать бэклог».
Команда говорит другое:
— «Процессы развалены и держатся на одном человеке».
— «Этот человек непрозрачен в решениях: почему делаем так — непонятно, обсуждений нет».
— «Многое делается медленно».
Один из разработчиков признаётся, что думает уходить, потому что устал от неэффективности.
Вопрос: что и как будете делать?
#кейсы@teamleading
❤7🙏1
Тимлид не тимлид? Разбор
Этот кейс можно в некотором роде назвать классическим в среднем менеджменте. Каждый руководитель руководителей хоть раз должен пройти через ситуацию, когда талантливого разработчика/дизайнера/тестировщика/маркетолога/коголибоещё он повышает до тимлида, тот не тянет и нужно его дауншифтить.
В общем случае, с опытом приходит ровно одно осознание — повышать людей до лидов надо с испытательным сроком и четкими критериями успеха.
Но наш текущий случай не такой. В нём человек сам выделился, и стал тащить на себе лидские функции. Как мог. Как умел. И любая попытка с ходу сказать ему «слушай, ты не тянешь» — это не просто конфликт. Это почти гарантированная дорога к тому, что вы растите себе врага: человека, который будет ненавидеть и вас, и компанию, и саботировать изменения (иногда молча, но эффективно).
К сожалению, в этой ситуации есть два быстрых выхода и один медленный.
И да, «медленный» — это тот, про который многие написали, и его любят, потому что он выглядит гуманно.
1️⃣ Медленный путь: учим, растим, наблюдаем
То есть берём время на осмотреться, ничего не меняем и изучаем всё, возможно даём человеку курсы/ментора, короче постепенно растим в тимлида.
Проблема медленного пути — этот путь почти всегда проигрывает и по времени и по результату.
Пока вы будете растить лида, вы скорее всего потеряете человека, который уже думает уйти. Потом ещё одного. Потом вы внезапно уже чините не лидерство, а текучку.
Да, иногда этот путь срабатывает. Но чаще результат медленного пути такой: через несколько месяцев вы всё равно приходите к расставанию с тимлидом.
Не потому что он плохой. А потому что роль не его, а привычки уже закрепились.
Прежде чем обсуждать быстрые пути давайте поймем какую проблему мы решаем и какие у нас цели (Саша, привет 😉):
— не потерять delivery (пока вы всё чините)
— не потерять людей (у вас уже один на грани ухода)
Где у нас болит больше и что приоритетнее в моменте?
Следующий вопрос, на который вам нужно максимально быстро найти ответ: команда реально приносит результат?
Не через «кажется», а хоть как-то измеряемо: предсказуемость, скорость, качество, жалобы стейкхолдеров.
Если KPI/метрик нет — ок, берёте суррогаты типа: план/факт, переносы, время в ожидании, дефекты/переделки, количество «срочно» и «пожаров».
И далее будет понятно каким путём идти.
2️⃣ . Быстрый путь №1: убираем лида
Этот путь не про вышвырнуть человека на улицу, а про то чтобы развести роли. Главное у вас ведь был и есть сильный инженер / дизайнер / ктоонувастам, А проблемы лидства и процессов вы вполне можете на время закрыть сами.
Этот путь почти всегда правильнее, если:
— команда буксует по факту, а не «по ощущениям»
— нет прозрачности, делегирования тоже нет, bus factor = 1
— человек защищает монополию («без меня вы все утонете») и не готов менять модель управления и себя
— есть высокий риск ухода людей (и он уже проявился)
Ну и главное я уже написал. Скорее всего после этого при встрече в коридоре человек с вами даже здороваться не будет.
3️⃣ . Быстрый путь №2: верим лиду и перестраиваем команду под него
Да, это тоже рабочий вариант. Но только если есть основание верить не харизме человека, а фактам. В чём отличие от пути1️⃣ ? В том что окончательность решения вы сразу же проговариваете команде.
Когда это разумно:
— есть цифры и по ним команда хорошо идет
— стейкхолдеры довольны
Скорее всего проблема в том, что часть команды не тянет новый темп/стандарты и сопротивляется. Может быть в команде есть кто-то, кто видел себя лидом и подрывает изнутри мотивацию. Сам же тимлид вполне прозрачен, просто ещё не хватает опыта.
Тогда вы формализуете его роль (хотя бы временно), поддерживаете его как лидера — и как некоторый недостаток допускаете смену состава команды по дороге. Это неприятно, но иногда это единственный способ не утонуть в болоте.
И если в конце вы спросите меня что я бы сделал? То я бы убирал лида. Делал я такое не единожды, и каждый раз спустя время всё начинало ехать, а лиды (если обладают нормальной саморефлексией) потом ещё и спасибо говорят что освободил их от того что не их.
Этот кейс можно в некотором роде назвать классическим в среднем менеджменте. Каждый руководитель руководителей хоть раз должен пройти через ситуацию, когда талантливого разработчика/дизайнера/тестировщика/маркетолога/коголибоещё он повышает до тимлида, тот не тянет и нужно его дауншифтить.
В общем случае, с опытом приходит ровно одно осознание — повышать людей до лидов надо с испытательным сроком и четкими критериями успеха.
Но наш текущий случай не такой. В нём человек сам выделился, и стал тащить на себе лидские функции. Как мог. Как умел. И любая попытка с ходу сказать ему «слушай, ты не тянешь» — это не просто конфликт. Это почти гарантированная дорога к тому, что вы растите себе врага: человека, который будет ненавидеть и вас, и компанию, и саботировать изменения (иногда молча, но эффективно).
К сожалению, в этой ситуации есть два быстрых выхода и один медленный.
И да, «медленный» — это тот, про который многие написали, и его любят, потому что он выглядит гуманно.
То есть берём время на осмотреться, ничего не меняем и изучаем всё, возможно даём человеку курсы/ментора, короче постепенно растим в тимлида.
Проблема медленного пути — этот путь почти всегда проигрывает и по времени и по результату.
Пока вы будете растить лида, вы скорее всего потеряете человека, который уже думает уйти. Потом ещё одного. Потом вы внезапно уже чините не лидерство, а текучку.
Да, иногда этот путь срабатывает. Но чаще результат медленного пути такой: через несколько месяцев вы всё равно приходите к расставанию с тимлидом.
Не потому что он плохой. А потому что роль не его, а привычки уже закрепились.
Прежде чем обсуждать быстрые пути давайте поймем какую проблему мы решаем и какие у нас цели (Саша, привет 😉):
— не потерять delivery (пока вы всё чините)
— не потерять людей (у вас уже один на грани ухода)
Где у нас болит больше и что приоритетнее в моменте?
Следующий вопрос, на который вам нужно максимально быстро найти ответ: команда реально приносит результат?
Не через «кажется», а хоть как-то измеряемо: предсказуемость, скорость, качество, жалобы стейкхолдеров.
Если KPI/метрик нет — ок, берёте суррогаты типа: план/факт, переносы, время в ожидании, дефекты/переделки, количество «срочно» и «пожаров».
И далее будет понятно каким путём идти.
Этот путь не про вышвырнуть человека на улицу, а про то чтобы развести роли. Главное у вас ведь был и есть сильный инженер / дизайнер / ктоонувастам, А проблемы лидства и процессов вы вполне можете на время закрыть сами.
Этот путь почти всегда правильнее, если:
— команда буксует по факту, а не «по ощущениям»
— нет прозрачности, делегирования тоже нет, bus factor = 1
— человек защищает монополию («без меня вы все утонете») и не готов менять модель управления и себя
— есть высокий риск ухода людей (и он уже проявился)
Ну и главное я уже написал. Скорее всего после этого при встрече в коридоре человек с вами даже здороваться не будет.
Да, это тоже рабочий вариант. Но только если есть основание верить не харизме человека, а фактам. В чём отличие от пути
Когда это разумно:
— есть цифры и по ним команда хорошо идет
— стейкхолдеры довольны
Скорее всего проблема в том, что часть команды не тянет новый темп/стандарты и сопротивляется. Может быть в команде есть кто-то, кто видел себя лидом и подрывает изнутри мотивацию. Сам же тимлид вполне прозрачен, просто ещё не хватает опыта.
Тогда вы формализуете его роль (хотя бы временно), поддерживаете его как лидера — и как некоторый недостаток допускаете смену состава команды по дороге. Это неприятно, но иногда это единственный способ не утонуть в болоте.
И если в конце вы спросите меня что я бы сделал? То я бы убирал лида. Делал я такое не единожды, и каждый раз спустя время всё начинало ехать, а лиды (если обладают нормальной саморефлексией) потом ещё и спасибо говорят что освободил их от того что не их.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍7
О багах-пятиминутках
или нужен ли вам идеальный продукт
Один из принципов, описанных в книге «15 секретов управления временем» гласит: если дело можно сделать за 5 минут, то его надо сделать, не складывая в инбокс или другие копилки.
Ровно такой же принцип работает и в продуктовой разработке. У каждого живущего продукта есть баги. И даже если вы осознанные, используете квоту на баги, а также все баги размечаете весами и приоритезируете, всё равно есть баги, до которых вы практически никогда не доберётесь — если не решите их сразу или у вас нет плана по их устранению. Это мелкие баги, которые слегка ухудшают жизнь: где-то отступ не тот, где-то, если ровно через 10 секунд нажать на кнопку, ничего не происходит, а где-то баг воспроизводится только в одном браузере и только при определённых условиях.
Любой обвешанный KPI продукт, скорее всего, проигнорирует эти баги. Более того — я знаю успешные примеры, когда баг может жить годами.
Например, в Duolingo нет проверки коннекта до серверов с аудио, поэтому иногда задания на аудирование там не проигрываются. Это не мешает сове быть популярной, а разработчикам — зарабатывать миллионы.
Или, например, ChatGPT начинает тормозить, когда в треде становится много сообщений. И проблема не в контексте (даже смешно, с учётом того что база знаний ChatGPT — это 70 триллионов токенов, то есть примерно 28 ТБ данных), а в том, что фронтендеры ChatGPT плодят DOM-элементы, и браузер (а точнее рендеринг) тупо тормозит от их количества (Зар за 10 минут навайбкодил решение).
Всё это ещё раз подтверждает правило: уникальным продуктом будут пользоваться даже при обилии багов. И это памятка всем начинающим продактам, кто изначально, на первых порах, не толерантен к багам. Большая их часть не помешает пользоваться продуктом, хоть и создаёт плохой UX. Сырой продукт сегодня — лучше идеального через несколько лет.
Но при этом я лично считаю, что важно эти баги периодически чинить. Либо брать какое-то количество в спринт, либо устраивать багатоны, либо ввести правило бага-пятиминутки (если там реально 5 минут на фикс) и без лишней бюрократии (типа «запланировать, описать, взять в спринт») фиксить их.
Во-первых, никогда не знаешь, когда плохой UX перевалит точку кипения (я, например, недавно удалил сову, потому что из-за одного бага потерял весь прогресс). Во-вторых, обычно именно про такие баги пишут пользователи, и написать им в ответ что-нибудь тёплое вместе с информацией о том, что их баг починили, — это способ нарастить и CSI, и NPS. Ну и, в-третьих, чаще всего чтобы пофиксить такие баги нужно реально немного времени, а при наличии современных LLM’ок ресёрч (и даже починку) можно отдать им.
Короче, почините баги :)
или нужен ли вам идеальный продукт
Один из принципов, описанных в книге «15 секретов управления временем» гласит: если дело можно сделать за 5 минут, то его надо сделать, не складывая в инбокс или другие копилки.
Ровно такой же принцип работает и в продуктовой разработке. У каждого живущего продукта есть баги. И даже если вы осознанные, используете квоту на баги, а также все баги размечаете весами и приоритезируете, всё равно есть баги, до которых вы практически никогда не доберётесь — если не решите их сразу или у вас нет плана по их устранению. Это мелкие баги, которые слегка ухудшают жизнь: где-то отступ не тот, где-то, если ровно через 10 секунд нажать на кнопку, ничего не происходит, а где-то баг воспроизводится только в одном браузере и только при определённых условиях.
Любой обвешанный KPI продукт, скорее всего, проигнорирует эти баги. Более того — я знаю успешные примеры, когда баг может жить годами.
Например, в Duolingo нет проверки коннекта до серверов с аудио, поэтому иногда задания на аудирование там не проигрываются. Это не мешает сове быть популярной, а разработчикам — зарабатывать миллионы.
Или, например, ChatGPT начинает тормозить, когда в треде становится много сообщений. И проблема не в контексте (даже смешно, с учётом того что база знаний ChatGPT — это 70 триллионов токенов, то есть примерно 28 ТБ данных), а в том, что фронтендеры ChatGPT плодят DOM-элементы, и браузер (а точнее рендеринг) тупо тормозит от их количества (Зар за 10 минут навайбкодил решение).
Всё это ещё раз подтверждает правило: уникальным продуктом будут пользоваться даже при обилии багов. И это памятка всем начинающим продактам, кто изначально, на первых порах, не толерантен к багам. Большая их часть не помешает пользоваться продуктом, хоть и создаёт плохой UX. Сырой продукт сегодня — лучше идеального через несколько лет.
Но при этом я лично считаю, что важно эти баги периодически чинить. Либо брать какое-то количество в спринт, либо устраивать багатоны, либо ввести правило бага-пятиминутки (если там реально 5 минут на фикс) и без лишней бюрократии (типа «запланировать, описать, взять в спринт») фиксить их.
Во-первых, никогда не знаешь, когда плохой UX перевалит точку кипения (я, например, недавно удалил сову, потому что из-за одного бага потерял весь прогресс). Во-вторых, обычно именно про такие баги пишут пользователи, и написать им в ответ что-нибудь тёплое вместе с информацией о том, что их баг починили, — это способ нарастить и CSI, и NPS. Ну и, в-третьих, чаще всего чтобы пофиксить такие баги нужно реально немного времени, а при наличии современных LLM’ок ресёрч (и даже починку) можно отдать им.
Короче, почините баги :)
❤16👍2
А ещё на следующей неделе будет DUMP Spb. Вся программа как нашей секции, так и других, уже опубликованы. Приходите, конечно же, на нашу, но и в других секциях есть что послушать 😉. Мой промокод
https://news.1rj.ru/str/dump_spb/254
MOKHOV на 15% скидку всё ещё действует. Короче, приходите, будем обниматься!https://news.1rj.ru/str/dump_spb/254
Telegram
DUMP Spb
Frontend на DUMP Spb 2026 — вскрываем по-честному
В секции Frontend мы устроим настоящий анатомический театр клиентских приложений. Без прикрас и маркетинга — разбираемся в самой сути того, что происходит под капотом современного фронтенда.
Поговорим про:…
В секции Frontend мы устроим настоящий анатомический театр клиентских приложений. Без прикрас и маркетинга — разбираемся в самой сути того, что происходит под капотом современного фронтенда.
Поговорим про:…
🔥5❤4
Никаких компромиссов. Беспроигрышные переговоры с экстремально высокими ставками. От топ-переговорщика ФБР
⭐️ О чём книга?
Это книга Криса Восса — бывшего переговорщика ФБР по кризисным ситуациям. В биографиях его часто описывают как человека, который вел переговоры с похитителями, грабителями банков и террористами
В книге рассказываются реальные истории переговоров: ошибки, которые допускали команды и которые не стоит повторять, и успехи, которых удавалось добиться. Приёмы легко перекладываются на бытовые и рабочие ситуации: от покупки машины до встреч со стейкхолдерами.
⭐ Мысли из книги
Эту книгу мне посоветовал Лёша Симоненко, когда мы обсуждали «прокачку навыков переговоров». Я забрал оттуда несколько штук и теперь использую их регулярно.
▫ . «Как я могу это сделать?» и «Всё правильно»
Пожалуй, две ключевые фразы, которые я вынес из книги.
«Как я могу это сделать?» — это вариация «нет» без слова «нет». В книге это называется калиброванные вопросы: они дают оппоненту ощущение контроля и заставляют его думать, как решить вашу проблему. У Восса эта формулировка прямо считается одной из самых сильных.
Например: вы хотите купить автомобиль за 4 млн, но у вас есть только 3.8 и кредит вы не хотите. Вместо «Я готов заплатить 3.8, по рукам?» или «Может дадите скидочку?». Вы говорите: «Цена чуть выше, чем я рассчитывал…» — и дальше ключевое: «Как я могу купить этот автомобиль?»
Вместо позиционной войны вы приглашаете человека искать решение.
«Всё правильно» — важный маркер. В оригинале это That’s right, и Восс противопоставляет его You’re right (“вы правы”), потому что “you’re right” нередко означает «да-да, ты прав, только отстань», а “that’s right” — «да, ты меня правильно понял». Поэтому цель переговоров — не «да», не кивки и не «вы правы», а ощущение у человека, что его действительно услышали.
Здесь я привожу английские варианты, потому что не уверен что «всё правильно» верный перевод, моё личное ощущение что в быту мы чаще говорим «всё верно»
▫ . К переговорам нужно всегда готовиться
Мысль не новая, но когда её говорит человек с таким опытом — она звучит убедительнее.
— соберите факты
— поймите, что важно другой стороне
— накиньте сценарий (план А → Б)
— и только потом идите в разговор
▫ . Ярлыки, зеркалирование, молчание
Ярлык (labeling) — словами назвать эмоцию/состояние оппонента:
«Похоже, для вас это важно», «Похоже, вас раздражает срок», «Кажется, вы переживаете за риски».
Если попали — получите «всё правильно». Если нет — человек часто сам уточнит, что на самом деле происходит.
Зеркалирование (mirroring) это про то, чтобы повторять последние 1–3 слова собеседника с любопытствующей интонацией, чтобы он продолжал говорить и раскрывал детали (тут грех не вспомнить ситуацию про активное слушание из ТБВ)
И да: лучшее, что вы можете делать в переговорах, — молчать и слушать. Этот навык полезен всем руководителям.
▫ . Чем сложнее переговоры, тем медленнее вы идёте к результату
Иногда переговоры выигрываются не аргументом, а тем, что вы выдержали темп.
Типовой пример из жизни: автосалон. Вас мурыжат, вы устаете, начинаете торопиться — и вот тут вы более управляемы. Воссовская мысль простая: качественный результат часто приходит там, где вы не ждёте быстро, и где оппонент видит, что его действительно слышат.
⭐ Мои впечатления
Книга крутая и по арсеналу приёмов, и потому что написана на реальных кейсах. Автор прошёл через очень жесткие переговоры, и то, что он делится опытом — действительно ценно.
Оценка книги: 9.5/10
Остальные обзоры книг доступны по тегу #книгобзор@teamleading
⭐️ О чём книга?
Это книга Криса Восса — бывшего переговорщика ФБР по кризисным ситуациям. В биографиях его часто описывают как человека, который вел переговоры с похитителями, грабителями банков и террористами
В книге рассказываются реальные истории переговоров: ошибки, которые допускали команды и которые не стоит повторять, и успехи, которых удавалось добиться. Приёмы легко перекладываются на бытовые и рабочие ситуации: от покупки машины до встреч со стейкхолдерами.
Эту книгу мне посоветовал Лёша Симоненко, когда мы обсуждали «прокачку навыков переговоров». Я забрал оттуда несколько штук и теперь использую их регулярно.
Пожалуй, две ключевые фразы, которые я вынес из книги.
«Как я могу это сделать?» — это вариация «нет» без слова «нет». В книге это называется калиброванные вопросы: они дают оппоненту ощущение контроля и заставляют его думать, как решить вашу проблему. У Восса эта формулировка прямо считается одной из самых сильных.
Например: вы хотите купить автомобиль за 4 млн, но у вас есть только 3.8 и кредит вы не хотите. Вместо «Я готов заплатить 3.8, по рукам?» или «Может дадите скидочку?». Вы говорите: «Цена чуть выше, чем я рассчитывал…» — и дальше ключевое: «Как я могу купить этот автомобиль?»
Вместо позиционной войны вы приглашаете человека искать решение.
«Всё правильно» — важный маркер. В оригинале это That’s right, и Восс противопоставляет его You’re right (“вы правы”), потому что “you’re right” нередко означает «да-да, ты прав, только отстань», а “that’s right” — «да, ты меня правильно понял». Поэтому цель переговоров — не «да», не кивки и не «вы правы», а ощущение у человека, что его действительно услышали.
Здесь я привожу английские варианты, потому что не уверен что «всё правильно» верный перевод, моё личное ощущение что в быту мы чаще говорим «всё верно»
Мысль не новая, но когда её говорит человек с таким опытом — она звучит убедительнее.
— соберите факты
— поймите, что важно другой стороне
— накиньте сценарий (план А → Б)
— и только потом идите в разговор
Ярлык (labeling) — словами назвать эмоцию/состояние оппонента:
«Похоже, для вас это важно», «Похоже, вас раздражает срок», «Кажется, вы переживаете за риски».
Если попали — получите «всё правильно». Если нет — человек часто сам уточнит, что на самом деле происходит.
Зеркалирование (mirroring) это про то, чтобы повторять последние 1–3 слова собеседника с любопытствующей интонацией, чтобы он продолжал говорить и раскрывал детали (тут грех не вспомнить ситуацию про активное слушание из ТБВ)
И да: лучшее, что вы можете делать в переговорах, — молчать и слушать. Этот навык полезен всем руководителям.
Иногда переговоры выигрываются не аргументом, а тем, что вы выдержали темп.
Типовой пример из жизни: автосалон. Вас мурыжат, вы устаете, начинаете торопиться — и вот тут вы более управляемы. Воссовская мысль простая: качественный результат часто приходит там, где вы не ждёте быстро, и где оппонент видит, что его действительно слышат.
Книга крутая и по арсеналу приёмов, и потому что написана на реальных кейсах. Автор прошёл через очень жесткие переговоры, и то, что он делится опытом — действительно ценно.
Оценка книги: 9.5/10
Остальные обзоры книг доступны по тегу #книгобзор@teamleading
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13👏3❤1👍1