Плавающий результат. Разбор
Прошло достаточно времени, чтобы написать мой разбор кейса недельной давности.
Первое, что важно осознать: фраза «в следующий раз буду внимательнее» — не является решением. Это не конкретный план, а лишь обещание что может быть что-то исправится.
Поэтому дальше я бы шёл так.
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