Никаких компромиссов. Беспроигрышные переговоры с экстремально высокими ставками. От топ-переговорщика ФБР
⭐️ О чём книга?
Это книга Криса Восса — бывшего переговорщика ФБР по кризисным ситуациям. В биографиях его часто описывают как человека, который вел переговоры с похитителями, грабителями банков и террористами
В книге рассказываются реальные истории переговоров: ошибки, которые допускали команды и которые не стоит повторять, и успехи, которых удавалось добиться. Приёмы легко перекладываются на бытовые и рабочие ситуации: от покупки машины до встреч со стейкхолдерами.
⭐ Мысли из книги
Эту книгу мне посоветовал Лёша Симоненко, когда мы обсуждали «прокачку навыков переговоров». Я забрал оттуда несколько штук и теперь использую их регулярно.
▫ . «Как я могу это сделать?» и «Всё правильно»
Пожалуй, две ключевые фразы, которые я вынес из книги.
«Как я могу это сделать?» — это вариация «нет» без слова «нет». В книге это называется калиброванные вопросы: они дают оппоненту ощущение контроля и заставляют его думать, как решить вашу проблему. У Восса эта формулировка прямо считается одной из самых сильных.
Например: вы хотите купить автомобиль за 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
🔥19👏4❤3👍2
Forwarded from N айтишниц заходят в бар
До сих пор в выпусках рубрики #Типичный_айтишник у нас было не так много менеджеров. Мы исправляемся, и в этот раз у нас в гостях Олег – менеджер разработки, повелитель аджайлов, производственных метрик и других страшных слов.
Кто ты и что делаешь?
Меня зовут Олег Мохов. Я менеджер разработки в Контуре — это роль на стыке управления командой разработки и проектом. Моя работа заключается как в полном цикле тимлидства, так и в управлении циклом деливери
Как ты начал заниматься тем, что делаешь сейчас?
У меня достаточно программистский трек: в школе любил математику и информатику, потом поступил в лицей СУНЦ УрГУ на физ-мат, затем на мат-мех УрГУ, а после — около двух лет поработал в небольших IT-компаниях. Далее попал в Яндекс, где проработал 14 лет и вырос до руководителя отдела.
Если обобщить мой подход, то он такой: я почти всегда довольно чётко понимаю, куда хочу прийти — и дальше ищу возможности, которые к этому ведут. Хочу руководить — беру ответственность и пробую. Хочу свой проект — нахожу/создаю проект. Внутри Яндекса я менял команды несколько раз, и каждый переход был осознанным шагом в сторону следующего уровня.
Даже когда уходил из Яндекса, это было про интерес: посмотреть на жизнь за пределами «уютной экосистемы» и расширить картину мира.
Что самое интересное в работе?
Больше всего мне нравится раскрывать таланты людей и находить им правильное применение. Управление — это не столько регламенты и задачи, сколько человек напротив: со своими желаниями, мотивацией, страхами и амбициями.
Когда получается понять человека и собрать «мэтч» между сильными сторонами и задачами — это мотивирует сильнее любых формальных целей.
А что самое неприятное, сложное?
Бюрократию в любых проявлениях не люблю — и по возможности стараюсь её либо выкидывать, либо автоматизировать. Сейчас, с современными LLM, это стало в разы проще: много рутинных вещей можно перевести в полуавтоматический режим без потери качества.
Расскажи веселую историю с работы
Расскажу две — одну из Яндекса (но с «контурским» камео), и вторую уже из Контура.
Как-то раз главному разработчику Яндекс Такси позвонили ночью и спросили: не вижу вас, вы где стоите? Он подумал, что перепутали номер и положил трубку. Но спустя пару месяцев ситуация повторилась и не выглядела уже как случайность. Начали искать причину и спустя неделю ресерча всё поняли. Когда мы (фронтендеры) заводили домены, то сразу же завели домен .com впрок. Он был закрыт для доступа извне, и мы там тестировались. При какой-то из выкладок этот домен случайно стал доступен наружу. И вот пару раз люди просто руками вбивали этот урл, попадали на домен с тестингом, где в качестве телефона водителя был указан номер главного разработчика такси, ну ему и звонили, как водителю.
Уже работая в Контуре я обратил внимание, что перед офисом в Екатеринбурге есть лишь небольшая парковка для каршеринга. Написал своему знакомому из Ситидрайва (Лёша, привет) и спросил: почему так? Оказалось, что они посмотрели на старые панорамы и думали, что остальная парковка предназначена для сотрудников. В итоге, я уже в первый месяц сделал то что несколько лет жило по принципу «исторически сложилось», а именно — дал дал новые места для парковки на каршеринге сотрудникам.
Дашь совет «успешного успеха»?
Изучайте новое и делайте это регулярно. Долгое время я «перебивался» статьями и докладами, но в последние годы стал много читать книги — причём не только про управление.
Я нашёл рабочий способ встроить чтение в рутину. Со временем заметил: во многих рабочих ситуациях начинаешь узнавать паттерны и истории из книг — и принимать решения становится проще и спокойнее. Чем старше становишься, тем больше понимаешь смысл фразы «знания — сила».
Хочешь еще чем-нибудь поделиться с нашими читателями?
У вас очень живой и честный канал: нравится, что вы показываете разные стороны жизни без глянца и «идеальных историй». Продолжайте в том же духе 😉
Кто ты и что делаешь?
Меня зовут Олег Мохов. Я менеджер разработки в Контуре — это роль на стыке управления командой разработки и проектом. Моя работа заключается как в полном цикле тимлидства, так и в управлении циклом деливери
Как ты начал заниматься тем, что делаешь сейчас?
У меня достаточно программистский трек: в школе любил математику и информатику, потом поступил в лицей СУНЦ УрГУ на физ-мат, затем на мат-мех УрГУ, а после — около двух лет поработал в небольших IT-компаниях. Далее попал в Яндекс, где проработал 14 лет и вырос до руководителя отдела.
Если обобщить мой подход, то он такой: я почти всегда довольно чётко понимаю, куда хочу прийти — и дальше ищу возможности, которые к этому ведут. Хочу руководить — беру ответственность и пробую. Хочу свой проект — нахожу/создаю проект. Внутри Яндекса я менял команды несколько раз, и каждый переход был осознанным шагом в сторону следующего уровня.
Даже когда уходил из Яндекса, это было про интерес: посмотреть на жизнь за пределами «уютной экосистемы» и расширить картину мира.
Что самое интересное в работе?
Больше всего мне нравится раскрывать таланты людей и находить им правильное применение. Управление — это не столько регламенты и задачи, сколько человек напротив: со своими желаниями, мотивацией, страхами и амбициями.
Когда получается понять человека и собрать «мэтч» между сильными сторонами и задачами — это мотивирует сильнее любых формальных целей.
А что самое неприятное, сложное?
Бюрократию в любых проявлениях не люблю — и по возможности стараюсь её либо выкидывать, либо автоматизировать. Сейчас, с современными LLM, это стало в разы проще: много рутинных вещей можно перевести в полуавтоматический режим без потери качества.
Расскажи веселую историю с работы
Расскажу две — одну из Яндекса (но с «контурским» камео), и вторую уже из Контура.
Как-то раз главному разработчику Яндекс Такси позвонили ночью и спросили: не вижу вас, вы где стоите? Он подумал, что перепутали номер и положил трубку. Но спустя пару месяцев ситуация повторилась и не выглядела уже как случайность. Начали искать причину и спустя неделю ресерча всё поняли. Когда мы (фронтендеры) заводили домены, то сразу же завели домен .com впрок. Он был закрыт для доступа извне, и мы там тестировались. При какой-то из выкладок этот домен случайно стал доступен наружу. И вот пару раз люди просто руками вбивали этот урл, попадали на домен с тестингом, где в качестве телефона водителя был указан номер главного разработчика такси, ну ему и звонили, как водителю.
Уже работая в Контуре я обратил внимание, что перед офисом в Екатеринбурге есть лишь небольшая парковка для каршеринга. Написал своему знакомому из Ситидрайва (Лёша, привет) и спросил: почему так? Оказалось, что они посмотрели на старые панорамы и думали, что остальная парковка предназначена для сотрудников. В итоге, я уже в первый месяц сделал то что несколько лет жило по принципу «исторически сложилось», а именно — дал дал новые места для парковки на каршеринге сотрудникам.
Дашь совет «успешного успеха»?
Изучайте новое и делайте это регулярно. Долгое время я «перебивался» статьями и докладами, но в последние годы стал много читать книги — причём не только про управление.
Я нашёл рабочий способ встроить чтение в рутину. Со временем заметил: во многих рабочих ситуациях начинаешь узнавать паттерны и истории из книг — и принимать решения становится проще и спокойнее. Чем старше становишься, тем больше понимаешь смысл фразы «знания — сила».
Хочешь еще чем-нибудь поделиться с нашими читателями?
У вас очень живой и честный канал: нравится, что вы показываете разные стороны жизни без глянца и «идеальных историй». Продолжайте в том же духе 😉
1❤17👍10❤🔥6🔥4🥰3
Три типа когнитивной нагрузки
Продолжаю копать тему когнитивной нагрузки (CLT — Cognitive Load Theory) и наткнулся на статью Альтеа Камински на Learning Scientists. Она кратко пересказывает модель Свеллера о том какая бывает когнитивная нагрузка, а именно встроенная / внешняя / полезная.
Это удобная линза, чтобы понять, почему люди устают и где у команды «утекают мозги». Давайте же разберёмся с типами когнитивной нагрузки.
1️⃣ Встроенная (intrinsic)
Это нагрузка, которая вшита в задачу: количество «элементов» задачи, которые, нужно удерживать в голове одновременно и связывать между собой. В CLT это часто описывают через взаимозависимость элементов, чем больше таких кусочков, тем выше встроенная нагрузка.
Пример из статьи:
выучить 20 слов нового языка — обычно проще, чем решить уравнение, где нужно держать в голове несколько переменных и их связи.
Пример из разработки:
— переименовать поле — почти всегда низкая встроенная нагрузка.
— спроектировать миграцию + обратную совместимость + несколько интеграций — высокая.
Как уменьшать?
— резать задачу на подзадачи,
— давать примеры/шаблоны,
— снижать число зависимостей.
2️⃣ Внешняя (extraneous)
Это нагрузка не от задачи, а от того, как вам приходится её делать: окружение, форма подачи информации, знакомость. В CLT прямо говорится, что внешнюю нагрузку нужно снижать, потому что она съедает и так ограниченные ресурсы рабочей памяти и мешает учиться/работать.
Пример из статьи:
готовить ужин на своей кухне и на чужой — разные по когнитивной нагрузке задачи при схожей формулировке.
Примеры из разработки:
— требования к задаче размазаны по 5 чатам, нет единого источника правды;
— CI иногда падает;
— смена контекста каждые 10 минут,
— митинги ради митингов.
Это всё не добавляет ценности — только ест мозг. Поэтому с этой нагрузкой всегда надо искать пути уменьшения.
3️⃣ Полезная (germane)
Это нагрузка, которая уходит на построение схем/ментальных моделей. То есть когда мозг инвестирует усилия в понимание, обобщение, автоматизацию задач.
Например, не просто «сделать тикет», а понять систему так, чтобы мочь в следующий раз сделать задачу быстрее и/или качественнее, и/или проще, и/или... (ещё любая характеристика задачи, которую можно улучшить)
Ещё примеры:
— написать краткую доку «как это работает»,
— сделать чек-лист,
— вынести решение в ADR,
— покрыть тестами то, что постоянно ломается,
— разобрать инцидент так, чтобы он не повторился,
— купить ёмкости для круп и подписать их с помощью эмбоссера (а то что мы всё про работу)
Зачем всё это знать?
Наша рабочая память ограничена, и эти типы когнитивной нагрузки конкурируют за один ресурс — это ресурс мозга.
Поэтому практическое правило управления когнитивной нагрузкой можно сформулировать так:
Снижайте внешнюю, управляйте встроенной, и, главное, освобождённое место инвестируйте в полезную.
Это утверждение относится и к задачам на работе, и в целом к быту и другим частям жизни. А если вы менеджер, то возможно это знание может дать вам ещё одно направление для поиска причин, почему команда делает простые задачи медленно.
В конце я вернусь к книге Барбары Оакли и дам то что у меня хорошо работает в пункте3️⃣ : выходите иногда проветриться без наушников и просто гуляйте.
Продолжаю копать тему когнитивной нагрузки (CLT — Cognitive Load Theory) и наткнулся на статью Альтеа Камински на Learning Scientists. Она кратко пересказывает модель Свеллера о том какая бывает когнитивная нагрузка, а именно встроенная / внешняя / полезная.
Это удобная линза, чтобы понять, почему люди устают и где у команды «утекают мозги». Давайте же разберёмся с типами когнитивной нагрузки.
Это нагрузка, которая вшита в задачу: количество «элементов» задачи, которые, нужно удерживать в голове одновременно и связывать между собой. В CLT это часто описывают через взаимозависимость элементов, чем больше таких кусочков, тем выше встроенная нагрузка.
Пример из статьи:
выучить 20 слов нового языка — обычно проще, чем решить уравнение, где нужно держать в голове несколько переменных и их связи.
Пример из разработки:
— переименовать поле — почти всегда низкая встроенная нагрузка.
— спроектировать миграцию + обратную совместимость + несколько интеграций — высокая.
Как уменьшать?
— резать задачу на подзадачи,
— давать примеры/шаблоны,
— снижать число зависимостей.
Это нагрузка не от задачи, а от того, как вам приходится её делать: окружение, форма подачи информации, знакомость. В CLT прямо говорится, что внешнюю нагрузку нужно снижать, потому что она съедает и так ограниченные ресурсы рабочей памяти и мешает учиться/работать.
Пример из статьи:
готовить ужин на своей кухне и на чужой — разные по когнитивной нагрузке задачи при схожей формулировке.
Примеры из разработки:
— требования к задаче размазаны по 5 чатам, нет единого источника правды;
— CI иногда падает;
— смена контекста каждые 10 минут,
— митинги ради митингов.
Это всё не добавляет ценности — только ест мозг. Поэтому с этой нагрузкой всегда надо искать пути уменьшения.
Это нагрузка, которая уходит на построение схем/ментальных моделей. То есть когда мозг инвестирует усилия в понимание, обобщение, автоматизацию задач.
Например, не просто «сделать тикет», а понять систему так, чтобы мочь в следующий раз сделать задачу быстрее и/или качественнее, и/или проще, и/или... (ещё любая характеристика задачи, которую можно улучшить)
Ещё примеры:
— написать краткую доку «как это работает»,
— сделать чек-лист,
— вынести решение в ADR,
— покрыть тестами то, что постоянно ломается,
— разобрать инцидент так, чтобы он не повторился,
— купить ёмкости для круп и подписать их с помощью эмбоссера (а то что мы всё про работу)
Зачем всё это знать?
Наша рабочая память ограничена, и эти типы когнитивной нагрузки конкурируют за один ресурс — это ресурс мозга.
Поэтому практическое правило управления когнитивной нагрузкой можно сформулировать так:
Снижайте внешнюю, управляйте встроенной, и, главное, освобождённое место инвестируйте в полезную.
Это утверждение относится и к задачам на работе, и в целом к быту и другим частям жизни. А если вы менеджер, то возможно это знание может дать вам ещё одно направление для поиска причин, почему команда делает простые задачи медленно.
В конце я вернусь к книге Барбары Оакли и дам то что у меня хорошо работает в пункте
Please open Telegram to view this post
VIEW IN TELEGRAM
3🔥15❤11👌2
Плавающий результат
Вы тимлид команды. Хотя вообще неважно, как ваша роль называется: проджект, продакт, техлид, руководитель группы — суть та же.
У вас есть разработчик с непредсказуемым результатом.
Иногда он делает задачи быстро и красиво:
— прокапывает глубоко,
— оставляет хорошие артефакты,
— решение можно показывать как эталон,
— команда довольна.
А иногда всё разваливается:
— задача делается медленно,
— на тестах вылезает куча ошибок,
— багофиксы занимают ещё больше времени,
— сроки плывут,
— команда и вы раздражаетесь, так как планы команды едут.
Самое неприятное: заранее непонятно, какая версия человека придёт на задачу. Он то спасает спринт, то топит его.
Вы уже делали разбор по последним задачам. Разработчик сказал что-то в духе: «Да, понял. В следующий раз буду внимательнее».
Но через пару недель история повторилась.
Доп. вводные:
— по знаниям разработчик явно не слабый;
— это не «новичок на адаптации», человек в команде давно;
— команда начинает терять доверие и уже раздражена: «на него нельзя положиться«;
— вы чувствуете, что один разговор «будь внимательнее» проблему не решает.
Вопрос: что будете делать?
#кейсы@teamleading
Вы тимлид команды. Хотя вообще неважно, как ваша роль называется: проджект, продакт, техлид, руководитель группы — суть та же.
У вас есть разработчик с непредсказуемым результатом.
Иногда он делает задачи быстро и красиво:
— прокапывает глубоко,
— оставляет хорошие артефакты,
— решение можно показывать как эталон,
— команда довольна.
А иногда всё разваливается:
— задача делается медленно,
— на тестах вылезает куча ошибок,
— багофиксы занимают ещё больше времени,
— сроки плывут,
— команда и вы раздражаетесь, так как планы команды едут.
Самое неприятное: заранее непонятно, какая версия человека придёт на задачу. Он то спасает спринт, то топит его.
Вы уже делали разбор по последним задачам. Разработчик сказал что-то в духе: «Да, понял. В следующий раз буду внимательнее».
Но через пару недель история повторилась.
Доп. вводные:
— по знаниям разработчик явно не слабый;
— это не «новичок на адаптации», человек в команде давно;
— команда начинает терять доверие и уже раздражена: «на него нельзя положиться«;
— вы чувствуете, что один разговор «будь внимательнее» проблему не решает.
Вопрос: что будете делать?
#кейсы@teamleading
🤔7❤4🔥4
Плавающий результат. Разбор
Прошло достаточно времени, чтобы написать мой разбор кейса недельной давности.
Первое, что важно осознать: фраза «в следующий раз буду внимательнее» — не является решением. Это не конкретный план, а лишь обещание что может быть что-то исправится.
Поэтому дальше я бы шёл так.
1️⃣ Что-то реально поменялось в жизни человека.
Это самый простой вариант и очень часто причина плавающего результата не в «лени», а в том, что человек банально не вывозит текущий режим — из-за сна, здоровья, стресса, домашних историй.
И да: недосып реально рушит внимание, рабочую память и качество решений. Это не психология, это физиология.
Факт, который лично меня поразил: 17–19 часов бодрствования по эффекту на производительность сравнивают с заметным алкогольным опьянением.
Пример из комментов (очень жизненный): вышла новая игра — человек ночами рубится. И вот тут «ещё раз будь внимательнее» не работает. Работает только восстановление.
Что делать:
— мягко проговорить наблюдение;
— спросить напрямую: «что поменялось?» (без попытки угадать причину),
— предложить временную поддержку: отгул/перераспределение нагрузки/неделя с меньшим количеством задач,
— договориться о чётком горизонте: «давай две недели посмотрим на стабильность».
Если человек сопротивляется — окей, тогда коротко:
«Я не лезу в личное. Но по работе результат ниже ожиданий. Я готов помочь, если скажешь как»
2️⃣ Проверяем задачи
Тут популярная ошибка: сразу копать «мотивацию», хотя часто проблема проще:
— человек плавает не по времени, а по типу задач.
Например:
— задачи с понятными требованиями он делает хорошо,
— задачи с неопределённостью/согласованиями/мутным контекстом — тонет,
— задачи с высоким количеством связей — тоже чаще проваливает.
Что делаем:
— сравниваем «хорошие» и «плохие» задачи;
— смотрим, где именно сбоит: в дизайне решения, в тестировании, в коммуникации, в декомпозиции?
— добавляем формальности процесса: чек-лист перед PR / короткое дизайн-ревью до реализации / критерии готовности (DoD и DoR).
— не забываем про ситуационное лидерство, может быть мы в ситуации когда с человеком надо вообще за ручку немного походить.
3️⃣ . Оцениваем мотивацию
Что мотивирует человека вообще на работу? Материальная или нематериальная мотивация?
Материальная мотивация иногда реально может быть причиной (особенно если человек считает, что его «недооценили»). Если в жизни человека случилось что-то тяжёлое (болезнь родственника и т.п.), то деньги иногда помогают как «подушка», но ещё важны:
— гибкость,
— отгулы,
— явный сигнал «тебя не бросят».
В крупных компаниях бывают разовые выплаты/программы помощи — стоит помнить про этот инструмент. (И если он есть — подсветить человеку.)
Поиск нематериальной мотивации — штука медленная. Тут скорее работают длинные разговоры и раскопки в духе 5 почему, рефрейминга, техники проективного интервью... и т.п. Но это всегда инвестиция времени. Если у вас оно имеется, то вперёд...
4️⃣ План улучшения и его границы
Вот где обычно менеджеры недожимают: они «поговорили по душам», а дальше опять ждут чуда.
Я бы делал короткий ИПР (индивидуальный план развития, но если что без слова ИПР, если у вас токсичная культура вокруг него):
— фиксируем ожидания: что такое «норм»,
— договариваемся о 2–3 конкретных изменениях в процессе (например, дизайн-ревью до реализации, чек-лист, парное ревью),
— ставим срок: 2–4 недели,
— и чекпоинты раз в неделю: «что изменилось, где ещё надо поработать».
Это может повлиять на ваши отношения с человеком. Но тут уж скажите себе честно что вам важнее. В конце концов на работу мы приходим работать. Стабильность и предсказуемость результата — часть ожиданий от работника.
5️⃣ Самая неприятная ветка, которую стоит держать в голове
Если всё перепробовали, триггера нет, а провалы продолжаются — возможно, человек:
— не тянет текущий уровень задач,
— или ему нужна смена задач/роли,
— или вы просто получили сигнал, что «надо расставаться».
Неприятно, но это тоже часть управленческой работы.
Прошло достаточно времени, чтобы написать мой разбор кейса недельной давности.
Первое, что важно осознать: фраза «в следующий раз буду внимательнее» — не является решением. Это не конкретный план, а лишь обещание что может быть что-то исправится.
Поэтому дальше я бы шёл так.
Это самый простой вариант и очень часто причина плавающего результата не в «лени», а в том, что человек банально не вывозит текущий режим — из-за сна, здоровья, стресса, домашних историй.
И да: недосып реально рушит внимание, рабочую память и качество решений. Это не психология, это физиология.
Факт, который лично меня поразил: 17–19 часов бодрствования по эффекту на производительность сравнивают с заметным алкогольным опьянением.
Пример из комментов (очень жизненный): вышла новая игра — человек ночами рубится. И вот тут «ещё раз будь внимательнее» не работает. Работает только восстановление.
Что делать:
— мягко проговорить наблюдение;
— спросить напрямую: «что поменялось?» (без попытки угадать причину),
— предложить временную поддержку: отгул/перераспределение нагрузки/неделя с меньшим количеством задач,
— договориться о чётком горизонте: «давай две недели посмотрим на стабильность».
Если человек сопротивляется — окей, тогда коротко:
«Я не лезу в личное. Но по работе результат ниже ожиданий. Я готов помочь, если скажешь как»
Тут популярная ошибка: сразу копать «мотивацию», хотя часто проблема проще:
— человек плавает не по времени, а по типу задач.
Например:
— задачи с понятными требованиями он делает хорошо,
— задачи с неопределённостью/согласованиями/мутным контекстом — тонет,
— задачи с высоким количеством связей — тоже чаще проваливает.
Что делаем:
— сравниваем «хорошие» и «плохие» задачи;
— смотрим, где именно сбоит: в дизайне решения, в тестировании, в коммуникации, в декомпозиции?
— добавляем формальности процесса: чек-лист перед PR / короткое дизайн-ревью до реализации / критерии готовности (DoD и DoR).
— не забываем про ситуационное лидерство, может быть мы в ситуации когда с человеком надо вообще за ручку немного походить.
Что мотивирует человека вообще на работу? Материальная или нематериальная мотивация?
Материальная мотивация иногда реально может быть причиной (особенно если человек считает, что его «недооценили»). Если в жизни человека случилось что-то тяжёлое (болезнь родственника и т.п.), то деньги иногда помогают как «подушка», но ещё важны:
— гибкость,
— отгулы,
— явный сигнал «тебя не бросят».
В крупных компаниях бывают разовые выплаты/программы помощи — стоит помнить про этот инструмент. (И если он есть — подсветить человеку.)
Поиск нематериальной мотивации — штука медленная. Тут скорее работают длинные разговоры и раскопки в духе 5 почему, рефрейминга, техники проективного интервью... и т.п. Но это всегда инвестиция времени. Если у вас оно имеется, то вперёд...
Вот где обычно менеджеры недожимают: они «поговорили по душам», а дальше опять ждут чуда.
Я бы делал короткий ИПР (индивидуальный план развития, но если что без слова ИПР, если у вас токсичная культура вокруг него):
— фиксируем ожидания: что такое «норм»,
— договариваемся о 2–3 конкретных изменениях в процессе (например, дизайн-ревью до реализации, чек-лист, парное ревью),
— ставим срок: 2–4 недели,
— и чекпоинты раз в неделю: «что изменилось, где ещё надо поработать».
Это может повлиять на ваши отношения с человеком. Но тут уж скажите себе честно что вам важнее. В конце концов на работу мы приходим работать. Стабильность и предсказуемость результата — часть ожиданий от работника.
Если всё перепробовали, триггера нет, а провалы продолжаются — возможно, человек:
— не тянет текущий уровень задач,
— или ему нужна смена задач/роли,
— или вы просто получили сигнал, что «надо расставаться».
Неприятно, но это тоже часть управленческой работы.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12🕊3🔥1👏1💯1
Когнитивная нагрузка и индивидуальные различия
Продолжаю потихоньку копать теорию когнитивной нагрузки (CLT — Cognitive Load Theory) и сегодня расскажу про относительно свежую статью Джона Свеллера «Cognitive load theory and individual differences» (оригинал статьи можно найти в подборке)
В статье рассматривают индивидуальные различия в обучении и делают вывод, что большая часть различий в обучении (которые можно изменить) — это не «талант», а то, сколько полезных знаний человек успел сложить в долговременную память до того как пришел на ваше обучение.
Типы информации
Информация/навыки бывают биологически первичные и биологически вторичные.
Первичное «прилипает« почти само: речь, базовые социальные штуки и т.п.
Вторичное требует усилий и обучения: чтение, математика, профессиональные навыки.
И да: мы не эволюционировали в сторону того, чтобы чтение/письмо стали первичным навыком — поэтому это всё приходится учить.
Как мы учимся?
В CLT картина простая:
— новое знание сначала проходит через рабочую память (или «быстрый мозг» у Канеманна)
— если повезло (и вы не утонули и не забросили) — складывается в долговременную память
— и дальше это знание начинает работать как готовый блок, который можно доставать когда нужно
Ну то есть просто давайте просто складывать всё в долговременную память? Ха!
Ключевое у Свеллера (и вообще в CLT) — интерактивность элементов (element interactivity): насколько элементы задачи взаимозависимы и требуют удержания одновременно. Чем выше взаимосвязность — тем сильнее горит рабочая память. И тем сложнее сложить это в долговременную. Выучить новое слово в английском — низкая интерактивность. Что означает каждая буква в формуле — высокая.
Отсюда и «чуйка» у экспертов: у них в долговременной памяти лежит больше паттернов/схем, и они быстрее видят «куда копать». При этом, это даже не каждый раз рационализируемо. Узнаваемость паттернов это не всегда про то что ты уже видишь решение. То как в долговременной памяти осядет информация заранее не определено, но «чуйка» всё равно сработает и эксперты чаще именно поэтому точечно сразу же попадают в корень решения проблемы.
Ещё пример — шахматы.
Гроссмейстеры запоминают не «как ходить каждой фигурой», а чанки/паттерны разных партий, и хранят сотни тысяч таких чанков в долговременной памяти. Именно поэтому они быстрее делают верные ходы.
Эксперимент показал, что если на доске выставить случайную и заранее не известную комбинацию, то преимущество экспертов резко уменьшается — потому что «узнавать» нечего и нужно решать задачу рабочей памятью.
Если снизить интерактивность элемента на старте обучения (например, дать готовые примеры решений), то рабочей памяти станет легче, и новичок будет учиться быстрее.
Но (и это мне нравится) — Свеллер регулярно подчёркивает: одних примеров недостаточно, практика решения задач всё равно нужна, просто её надо давать в правильный момент и с правильной дозировкой.
В CLT обычно говорят так: долговременная память очень большая (практически не ограничена), а вот рабочая память ограничена и по объёму, и по тому, сколько взаимосвязей она может держать одновременно.
Окей, а мне-то (тимлиду/менеджеру) что с этого?
Вот какие выводы я для себя сформулировал:
1️⃣ . Давать людям время на оседание знаний в долговременной памяти.
То есть прогулки/проветриться — это не прихоть. Если цель — знания, то это способ дать мозгу переварить их, нежели продолжать добивать рабочую память. Кстати, у Лебедева есть похожий вывод про сон без наушников.
2️⃣ . ИИзация всего — только подключая память.
ИИ легко создаёт иллюзию «я знаю», хотя на самом деле «знает ИИ», а в долговременную память у вас почти ничего не легло. (Особенно на задачах с высокой взаимосвязанностью.)
Короче, обсуждайте задачи, даже если решили с помощью ИИ.
3️⃣ . Реальная ценность ИИ в обучении — не в «уникальном контенте», а в персонализации под вас.
Убирать шум/избыточность материала, подсунуть хорошие примеры и дозировать практику под ваш текущий уровень.
Эх. Осталось дожить до мира, где это нормально работает 🙂
Продолжаю потихоньку копать теорию когнитивной нагрузки (CLT — Cognitive Load Theory) и сегодня расскажу про относительно свежую статью Джона Свеллера «Cognitive load theory and individual differences» (оригинал статьи можно найти в подборке)
В статье рассматривают индивидуальные различия в обучении и делают вывод, что большая часть различий в обучении (которые можно изменить) — это не «талант», а то, сколько полезных знаний человек успел сложить в долговременную память до того как пришел на ваше обучение.
Типы информации
Информация/навыки бывают биологически первичные и биологически вторичные.
Первичное «прилипает« почти само: речь, базовые социальные штуки и т.п.
Вторичное требует усилий и обучения: чтение, математика, профессиональные навыки.
И да: мы не эволюционировали в сторону того, чтобы чтение/письмо стали первичным навыком — поэтому это всё приходится учить.
Как мы учимся?
В CLT картина простая:
— новое знание сначала проходит через рабочую память (или «быстрый мозг» у Канеманна)
— если повезло (и вы не утонули и не забросили) — складывается в долговременную память
— и дальше это знание начинает работать как готовый блок, который можно доставать когда нужно
Ну то есть просто давайте просто складывать всё в долговременную память? Ха!
Ключевое у Свеллера (и вообще в CLT) — интерактивность элементов (element interactivity): насколько элементы задачи взаимозависимы и требуют удержания одновременно. Чем выше взаимосвязность — тем сильнее горит рабочая память. И тем сложнее сложить это в долговременную. Выучить новое слово в английском — низкая интерактивность. Что означает каждая буква в формуле — высокая.
Отсюда и «чуйка» у экспертов: у них в долговременной памяти лежит больше паттернов/схем, и они быстрее видят «куда копать». При этом, это даже не каждый раз рационализируемо. Узнаваемость паттернов это не всегда про то что ты уже видишь решение. То как в долговременной памяти осядет информация заранее не определено, но «чуйка» всё равно сработает и эксперты чаще именно поэтому точечно сразу же попадают в корень решения проблемы.
Ещё пример — шахматы.
Гроссмейстеры запоминают не «как ходить каждой фигурой», а чанки/паттерны разных партий, и хранят сотни тысяч таких чанков в долговременной памяти. Именно поэтому они быстрее делают верные ходы.
Эксперимент показал, что если на доске выставить случайную и заранее не известную комбинацию, то преимущество экспертов резко уменьшается — потому что «узнавать» нечего и нужно решать задачу рабочей памятью.
Если снизить интерактивность элемента на старте обучения (например, дать готовые примеры решений), то рабочей памяти станет легче, и новичок будет учиться быстрее.
Но (и это мне нравится) — Свеллер регулярно подчёркивает: одних примеров недостаточно, практика решения задач всё равно нужна, просто её надо давать в правильный момент и с правильной дозировкой.
В CLT обычно говорят так: долговременная память очень большая (практически не ограничена), а вот рабочая память ограничена и по объёму, и по тому, сколько взаимосвязей она может держать одновременно.
Окей, а мне-то (тимлиду/менеджеру) что с этого?
Вот какие выводы я для себя сформулировал:
То есть прогулки/проветриться — это не прихоть. Если цель — знания, то это способ дать мозгу переварить их, нежели продолжать добивать рабочую память. Кстати, у Лебедева есть похожий вывод про сон без наушников.
ИИ легко создаёт иллюзию «я знаю», хотя на самом деле «знает ИИ», а в долговременную память у вас почти ничего не легло. (Особенно на задачах с высокой взаимосвязанностью.)
Короче, обсуждайте задачи, даже если решили с помощью ИИ.
Убирать шум/избыточность материала, подсунуть хорошие примеры и дозировать практику под ваш текущий уровень.
Эх. Осталось дожить до мира, где это нормально работает 🙂
Please open Telegram to view this post
VIEW IN TELEGRAM
2🔥13❤5👍2👏1🤔1
Смотрим и комментируем.
Всегда сложно начинать что-то новое, кучу вещей познаешь заново, и каждый шаг на новом пути дается через «а может ну это всё к чёрту?».
Этот подкаст я задумал ещё осенью. Но то времени не было, то я не был готов. В ноябре-декабре мы несколько раз переносили съёмку, но я твердо решил в конце года, что запишусь, посмотрю результат и отклик и далее подумаю стоит ли продолжать?
Идея не просто смотреть доклад с автором доклада, но по ходу останавливать видео и обсуждать его появилась не случайно. Мне лично тяжело с ходу отсмотреть доклад в 30-40 минут, а потом ещё и вспомнить что было по ходу и какие у меня были вопросы и мысли.
Так родился формат подкаста «Смотрим, комментируем». Когда можно не просто скопом посмотреть доклад, а небольшими сегментами, при этом в каждом из них задать нужные вопросы, которые в этот момент возникают.
Встречайте пилотный выпуск подкаста с Никитой Дубко (@mefody_dev) в которым мы смотрели и комментировали его доклад про игру со шрифтами, прочитанный на FrontendConf 2025.
📹 Смотреть на YouTube
🇷🇺 Смотреть на RUTUBE
📺 Смотреть в VK Видео
Жду ваши комментарии, а также идей чей следующий доклад будем смотреть и комментировать?
Всегда сложно начинать что-то новое, кучу вещей познаешь заново, и каждый шаг на новом пути дается через «а может ну это всё к чёрту?».
Этот подкаст я задумал ещё осенью. Но то времени не было, то я не был готов. В ноябре-декабре мы несколько раз переносили съёмку, но я твердо решил в конце года, что запишусь, посмотрю результат и отклик и далее подумаю стоит ли продолжать?
Идея не просто смотреть доклад с автором доклада, но по ходу останавливать видео и обсуждать его появилась не случайно. Мне лично тяжело с ходу отсмотреть доклад в 30-40 минут, а потом ещё и вспомнить что было по ходу и какие у меня были вопросы и мысли.
Так родился формат подкаста «Смотрим, комментируем». Когда можно не просто скопом посмотреть доклад, а небольшими сегментами, при этом в каждом из них задать нужные вопросы, которые в этот момент возникают.
Встречайте пилотный выпуск подкаста с Никитой Дубко (@mefody_dev) в которым мы смотрели и комментировали его доклад про игру со шрифтами, прочитанный на FrontendConf 2025.
Жду ваши комментарии, а также идей чей следующий доклад будем смотреть и комментировать?
Please open Telegram to view this post
VIEW IN TELEGRAM
4🔥19👏3❤2👍2⚡1❤🔥1🎉1
Лидерство через создание пространства
Недавно Мартин Фаулер написал
Очень прикольно, как в разных кругах постепенно идёт осознание того, что менеджмент может быть не только через прямое управление командой, но и через создание пространства для работы. Это выгоднее в долгосрок, потому что соответствует ещё одному известному правилу — руководитель должен руководить так чтобы стать не нужным. Сами концепции подхода, описанного Фаулером, очень похожи на принципы фасилитации.
Дополнить пост Мартина хочется тем, что нужно всегда держать руку на пульсе зрелости команды и грамотно миксовать фасилитацию команды с ситуационным лидерством, чтобы «вмешательства» были логичными, а не просто дёргание стоп-крана, когда что-то идёт не так.
Недавно Мартин Фаулер написал
Если вы давно крутитесь в agile-кругах, то наверняка слышали про служащее лидерство (или лидерство-служение): идею, что менеджер должен прежде всего обеспечивать команду — убирать препятствия, защищать её от корпоративной суеты и помогать работать спокойно. Мне эта концепция никогда не казалась до конца честной. И недавний разговор с Кентом Беком помог сформулировать почему: это похоже на газлайтинг. Менеджер говорит «я работаю на ваше благо», но по факту все всё понимают.
Мой коллега Джайлс Эдвардс-Александер предложил другой взгляд на лидерство — он встретил его в работе с практиками из сферы психического здоровья. В этой модели лидер — не служит на благо команды, а host, то есть хозяин / принимающая сторона. Он готовит пространство, приглашает людей, приносит идеи и проблемы, а потом отступает и не мешает команде делать своё дело. Он заботится о команде — как и в идеальной версии служащего лидерства, — но без притворства: если что-то пойдёт не так, он сохраняет право вмешаться.
Очень прикольно, как в разных кругах постепенно идёт осознание того, что менеджмент может быть не только через прямое управление командой, но и через создание пространства для работы. Это выгоднее в долгосрок, потому что соответствует ещё одному известному правилу — руководитель должен руководить так чтобы стать не нужным. Сами концепции подхода, описанного Фаулером, очень похожи на принципы фасилитации.
Дополнить пост Мартина хочется тем, что нужно всегда держать руку на пульсе зрелости команды и грамотно миксовать фасилитацию команды с ситуационным лидерством, чтобы «вмешательства» были логичными, а не просто дёргание стоп-крана, когда что-то идёт не так.
3❤10💯7👍5🔥2⚡1👏1
Разработчик сделал ровно то, что вы просили
Недавняя история про ИИ-агента, который удалил почтовый ящик директору по безопасности одной компании хоть и забавна, но тут даже не понятно с кого ответ держать.
Давайте попробуем поразмышлять над схожим кейсом.
Вы менеджер проекта (или продакт/тимлид — роль не важна).
Выдаёте объёмную задачу на 2 месяца разработчику (или дизайнеру/аналитику).
Специалист всё честно делает.
Ровно к дедлайну результат готов. Вы выкатываете в прод.
И… нужные метрики летят в тартарары.
Вы откатываете обратно, но есть проблема: платящие пользователи просели, восстановления не происходит даже через несколько месяцев, т.к доверие к продукту подорвано.
И вот вас зовут на совет директоров отвечать за ситуацию.
Вопросы:
1. Что вы будете делать прямо сейчас? Что скажете на совете директоров?
2. Есть ли вина специалиста, если он сделал ровно то, что вы просили — и формально всё «как в ТЗ»?
3. Где проходит граница ответственности между постановкой/валидацией/внедрением?
#кейсы@teamleading
Недавняя история про ИИ-агента, который удалил почтовый ящик директору по безопасности одной компании хоть и забавна, но тут даже не понятно с кого ответ держать.
Давайте попробуем поразмышлять над схожим кейсом.
Вы менеджер проекта (или продакт/тимлид — роль не важна).
Выдаёте объёмную задачу на 2 месяца разработчику (или дизайнеру/аналитику).
Специалист всё честно делает.
Ровно к дедлайну результат готов. Вы выкатываете в прод.
И… нужные метрики летят в тартарары.
Вы откатываете обратно, но есть проблема: платящие пользователи просели, восстановления не происходит даже через несколько месяцев, т.к доверие к продукту подорвано.
И вот вас зовут на совет директоров отвечать за ситуацию.
Вопросы:
1. Что вы будете делать прямо сейчас? Что скажете на совете директоров?
2. Есть ли вина специалиста, если он сделал ровно то, что вы просили — и формально всё «как в ТЗ»?
3. Где проходит граница ответственности между постановкой/валидацией/внедрением?
#кейсы@teamleading
2❤5🔥3❤🔥1⚡1🤔1🐳1
12 шагов к лучшему коду
В 2000 году Джоэл Спольски написал чеклист — The Joel Test: 12 простых вопросов про вашу разработку.
1, Используете ли вы VCS?
2. Можете ли вы собрать проект одной (консольной) командой?
3. Есть ли у вас ежедневные билды?
4. Есть ли у вас бэклог багов?
5. Фиксите ли вы баги до того, как писать новый код?
6. Есть ли у вас план релизов?
7. Есть ли у вас спеки?
8. Есть ли у программистов возможность работать в тишине?
9. Используете ли вы лучшие инструменты, которые можно купить за деньги?
10. Есть ли у вас тестировщики?
11. Пишут ли кандидаты код на интервью?
12. Делаете ли вы «коридорные» юзабилити-тесты?
Джоэл утверждал: если у вас 10 «да» или меньше то у вас проблемы (а если сильно меньше — то проблемы системные).
Прошло 26 лет, и формулировки большинства пунктов устарели. Но сам подход — смотреть на разработку под разными углами, чтобы понять, почему и что «не летит» (и почему вы внезапно не можете нанимать сильных), — до сих пор актуален.
Например:
— «Ежедневные билды» сегодня — это не «ночью собираем артефакт», а нормальный CI/CD pipeline: тесты, статический анализ, сборка, деплой (хотя бы в staging), дэши и быстрый фидбек когда что-то идёт не так.
— «Лучшие инструменты за деньги» сегодня — это не «купите IDE и Claude», а DX в широком смысле:
— понятный и измеряемый lead time,
— низкая когнитивная нагрузка (я писал про это тут)
— разные окружения, A/B тесты, нормальные логи/трейсы,
— и главное — чтобы команда не страдала от инструментов (страдать должны только от сложных задач, но это уже другая история).
Если бы я писал Joel Test сегодня, я бы, наверное, добавил ещё несколько вопросов:
— Есть ли автоматические тесты?
— Есть ли code review как привычка?
— Можно ли катить маленькими порциями (feature flags, canary)?
— Есть ли observability и инцидентный процесс?
Но глобально Joel Test всё ещё отличный «детектор дыма». Берёте список, прикладываете к команде — и быстро становится видно, где болит и почему.
А что бы вы добавили в Joel Test 2026?
В 2000 году Джоэл Спольски написал чеклист — The Joel Test: 12 простых вопросов про вашу разработку.
1, Используете ли вы VCS?
2. Можете ли вы собрать проект одной (консольной) командой?
3. Есть ли у вас ежедневные билды?
4. Есть ли у вас бэклог багов?
5. Фиксите ли вы баги до того, как писать новый код?
6. Есть ли у вас план релизов?
7. Есть ли у вас спеки?
8. Есть ли у программистов возможность работать в тишине?
9. Используете ли вы лучшие инструменты, которые можно купить за деньги?
10. Есть ли у вас тестировщики?
11. Пишут ли кандидаты код на интервью?
12. Делаете ли вы «коридорные» юзабилити-тесты?
Джоэл утверждал: если у вас 10 «да» или меньше то у вас проблемы (а если сильно меньше — то проблемы системные).
Прошло 26 лет, и формулировки большинства пунктов устарели. Но сам подход — смотреть на разработку под разными углами, чтобы понять, почему и что «не летит» (и почему вы внезапно не можете нанимать сильных), — до сих пор актуален.
Например:
— «Ежедневные билды» сегодня — это не «ночью собираем артефакт», а нормальный CI/CD pipeline: тесты, статический анализ, сборка, деплой (хотя бы в staging), дэши и быстрый фидбек когда что-то идёт не так.
— «Лучшие инструменты за деньги» сегодня — это не «купите IDE и Claude», а DX в широком смысле:
— понятный и измеряемый lead time,
— низкая когнитивная нагрузка (я писал про это тут)
— разные окружения, A/B тесты, нормальные логи/трейсы,
— и главное — чтобы команда не страдала от инструментов (страдать должны только от сложных задач, но это уже другая история).
Если бы я писал Joel Test сегодня, я бы, наверное, добавил ещё несколько вопросов:
— Есть ли автоматические тесты?
— Есть ли code review как привычка?
— Можно ли катить маленькими порциями (feature flags, canary)?
— Есть ли observability и инцидентный процесс?
Но глобально Joel Test всё ещё отличный «детектор дыма». Берёте список, прикладываете к команде — и быстро становится видно, где болит и почему.
А что бы вы добавили в Joel Test 2026?
3🔥10❤2⚡1❤🔥1🤔1
Тест Рэндса
В книге «Как управлять интеллектуалами» (про саму книгу будет ещё несколько постов) Майкл Лопп — известный в узких кругах также как Рэндс— в подражание теста Джоэла предложил свой вариант чеклиста. Только он уже касается не кода, а управления командой и охватывает не только технарей, но и продуктовую организацию в целом.
1. Проводятся ли у вас совещания тет-а-тет?
2. Проводятся ли у вас командные совещание?
3. Есть ли у вас отчёты по статусу проекта?
4. Можете ли вы сказать своему боссу «нет»?
5. Можете ли вы объяснить стратегию вашей компании незнакомцу?
6. Можете ли вы рассказать о текущем состоянии дел в вашей компании?
7. Ваши руководители регулярно выступают перед всеми сотрудниками и рассказывают о том, что они думают? Вы «ведётесь» на это?
8. Вы знаете, что хотите делать дальше? А ваш босс знает?
9. У вас есть время на стратегическую деятельность?
10. Вы активно боретесь с сарафанным радио?
Дальше в книге Рэндс подробно разбирает каждый пункт и объясняет, какие ожидания за ним стоят.
Например, по первому же пункту он пишет то, что я очень часто пытаюсь донести: транслирование статуса проекта НЕ является целью тет-а-тета.
Цель тет-а-тета — говорить о сути работы и состоянии команды, а не просто обмениваться статусами.
В целом этот список вопросов нужен для того, чтобы проверить систему управления.
Является ли управление командой и распространение информации внутри неё осознанным процессом, или всё происходит хаотично.
И даже если формально процессы есть, полезно задать себе следующий вопрос:
не работает ли какая-нибудь «правильная» практика на самом деле против команды?
Например, если у вас есть еженедельные письменные статусы. То Рэндс говорит, что на бумаге это прозрачность, а на практике — лишняя нагрузка.
В книге «Как управлять интеллектуалами» (про саму книгу будет ещё несколько постов) Майкл Лопп — известный в узких кругах также как Рэндс— в подражание теста Джоэла предложил свой вариант чеклиста. Только он уже касается не кода, а управления командой и охватывает не только технарей, но и продуктовую организацию в целом.
1. Проводятся ли у вас совещания тет-а-тет?
2. Проводятся ли у вас командные совещание?
3. Есть ли у вас отчёты по статусу проекта?
4. Можете ли вы сказать своему боссу «нет»?
5. Можете ли вы объяснить стратегию вашей компании незнакомцу?
6. Можете ли вы рассказать о текущем состоянии дел в вашей компании?
7. Ваши руководители регулярно выступают перед всеми сотрудниками и рассказывают о том, что они думают? Вы «ведётесь» на это?
8. Вы знаете, что хотите делать дальше? А ваш босс знает?
9. У вас есть время на стратегическую деятельность?
10. Вы активно боретесь с сарафанным радио?
Дальше в книге Рэндс подробно разбирает каждый пункт и объясняет, какие ожидания за ним стоят.
Например, по первому же пункту он пишет то, что я очень часто пытаюсь донести: транслирование статуса проекта НЕ является целью тет-а-тета.
Цель тет-а-тета — говорить о сути работы и состоянии команды, а не просто обмениваться статусами.
В целом этот список вопросов нужен для того, чтобы проверить систему управления.
Является ли управление командой и распространение информации внутри неё осознанным процессом, или всё происходит хаотично.
И даже если формально процессы есть, полезно задать себе следующий вопрос:
не работает ли какая-нибудь «правильная» практика на самом деле против команды?
Например, если у вас есть еженедельные письменные статусы. То Рэндс говорит, что на бумаге это прозрачность, а на практике — лишняя нагрузка.
3❤11🔥4⚡1👍1🐳1
Мы в Яндекс Практикуме сделали инструмент оценки кодовых навыков фронтенд-разработчиков
— кандидат решает реалистичную задачу
— работает в IDE (среде разработки) как на реальном проекте
— вы получаете отчёт с оценкой навыков и уровня разработчика
— проверять кандидатов перед интервью
— оценить уровень своих разработчиков
— попробовать инструмент до публичного запуска
Если вы нанимаете фронтенд-разработчиков или руководите командой — будем рады вашему участию
Принять участие
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
7🔥4👍2⚡1❤🔥1😁1🕊1