Все статьи
Сколько времени нужно, чтобы написать имя?
Дата: 29.07.2025
Игра, которая наглядно показывает, насколько плоха многозадачность и насколько легко она нас затягивает.
- Время: 30+ минут.
- Участники: 5-35 человек (по 5-7 человек в 1-5 командах).
- Уровень сложности: средний.
- Флипчарт.
- Листы А4.
- Маркеры.
- Фломастеры.
Меня, как коуча, постоянно поражает, насколько часто многозадачность встречается в большинстве компаний, с которыми я работал, и сколько потерь она приносит. Снова и снова я понимаю, что один из самых дешевых и быстрых способов значительно поднять производительность любой команды или человека — найти и уменьшить все источники многозадачности.
Долгое время я пытался найти упражнение, которое иллюстрирует эту проблему. Если картинка стоит тысячи слов, то практика стоит тысячи картинок. Я нашел несколько упражнений, как простых, так и сложных, но ни одно из них не демонстрировало проблему достаточно чистым, простым и легко воспроизводимым способом. Так что я позаимствовал лучшие идеи из других упражнений и сделал на их основе свою собственную игру. К моему удивлению, она отлично сработала с первого раза (многим участникам эта игра настолько понравилась, что они назвали ее лучшим упражнением из всего курса). Несколько лет я ее постоянно совершенствовал, и теперь она стала еще лучше.
Это упражнение стало очень популярным среди тренеров Lean и Agile. Даже Мэри Поппендик теперь часто его использует, хотя обычно она очень скептически относится к упражнениям и не проводит их. Но во время нашего совместного тренинга по Lean она так безудержно веселилась, что включила его в собственную программу тренинга. Мэри и другие тренеры часто рассказывают мне о том, насколько сильный эффект производит эта игра, особенно на менеджеров.
Содержание
Шаг 1: Оцените, сколько времени займет написание имени
Я пропускаю преамбулу и начинаю с простого вопроса: «Сколько времени нужно, чтобы написать имя?» Обычно у людей возникает замешательство, что я имею в виду. Я держу карточку с именем и говорю: «Например, вот это».
Сначала люди гадают с неохотой, пытаясь скрыть неявный ответ: «Это зависит от…» Я вытягиваю из них ответы, задавая вопросы:
- Вы действительно не можете дать оценку?
- То есть это может занять около года?
- Или меньше секунды?
Наконец, они начинают называть оценки, обычно около 4 секунд. Потом я спрашиваю у них, сколько времени уйдет, чтобы написать 5 имен. Обычно они называют 20 секунд (предыдущая оценка, умноженная на 5). Я записываю эти числа на флипчарте.
Шаг 2: Обсуждаем факторы, оказывающие влияние
Следующий вопрос:
- Какие факторы влияют на это время?
- Когда вы говорите «это зависит», что вы имеете в виду?
Аудитория начинает называть причины, а я их записываю. Обычно называют: длина имени, сложность, инструменты, ожидаемое качество, навыки письма и т.д.
Это ловушка. В большинстве случаев никто не называет «многозадачность» как один из факторов, влияющих на время. Именно поэтому я обычно не упоминаю многозадачность в названии упражнения, я хочу продемонстрировать, насколько мы склонны забывать о влиянии многозадачности.
Дальше я говорю: «Ладно, давайте узнаем правду».
Шаг 3: Сформируйте группы и опишите роль заказчика
Я прошу людей разделиться на группы по 5-7 человек, где один человек играет роль разработчика, а остальные — заказчики.
Единственный навык, необходимый разработчику — умение писать буквы фломастером на бумаге. Его инструмент — фломастер.
Вот что я говорю заказчикам:
«У каждого из вас есть чистая карточка. Все, чего вы хотите, чтобы вам написали ваше имя на этой карточке. Проблема в том, что вы не умеете писать буквы — именно поэтому вам нужен разработчик!
Более того, вы как заказчик хотите, чтобы ваше имя было написано как можно быстрее. Ваша работа следить за этим, поэтому как только ваше имя будет написано, вы запишете сколько времени на это ушло (да, вы умеете писать цифры). Чтобы помочь вам с этим, я (координатор упражнения) выведу на экран большой таймер.
Итак, процесс заказа выглядит следующим образом:
- Отдайте чистую карточку разработчику, назовите ему свое имя.
- Подождите, пока разработчик напишет ваше имя и вернет вам карточку.
- Посмотрите на таймер и запишите время готовности на карточке.
Если есть ошибка (такая как орфографическая), то не записывайте время. Вместо этого верните карточку разработчику для исправления. Работа не считается выполненной до тех пор, пока на карточке не будет написано правильное имя.
Вы можете разговаривать с разработчиком и отвечать на вопросы. Но вы не можете писать буквы».
Разумеется, бэйджи, визитки и все такое на время упражнения нужно убрать.
Шаг 4: Опишите поведение разработчика для первого раунда
Вот, что я говорю разработчикам: «Ваша задача как разработчиков — просто написать имена заказчиков. Однако, вам придется соблюдать корпоративные Правила! Наше корпоративное правило: никогда не заставляйте заказчика ждать, потому что это плохой бизнес. Мы можем потерять заказчика, которому приходится ждать. Более того, мы считаем, что чем раньше начнешь, тем раньше закончишь. Правильно?»
Здесь я останавливаюсь и тщательно слежу за тем, есть ли кто-нибудь, оспаривающий это утверждение. Обычно никто не возражает, потому что это звучит очевидно. Одна из целей этого упражнения — проиллюстрировать, насколько это утверждение лживо.
«Итак, для того, чтобы соблюдать корпоративную политику, вы как разработчик должны работать над всеми проектами одновременно! Когда я запущу таймер, все заказчики одновременно отдадут свои чистые карточки и назовут свои имена. Вы запишете первую букву первого заказчика, потом первую букву второго заказчика и так далее.
После того, как первые буквы всех заказчиков написаны, возвращайтесь назад и начинайте писать вторые буквы имени каждого заказчика. И так далее.
Как только имя написано полностью, отдайте эту карточку заказчику, чтобы он/она записал время готовности на карточке».
Вот и весь первый раунд. Я тщательно проверяю, что все поняли инструкции, что у всех есть ручки и у каждого заказчика есть чистая карточка.
После этого я запускаю таймер.
Шаг 5: Начните первый раунд
Во время первого раунда я наблюдаю за тем, чтобы разработчики соблюдали корпоративную политику. Обычно с этим не возникает проблем, если я хорошо ее объяснил.
Как правило, людям нравится то, что происходит, потому что все видят, насколько все плохо и большинство людей находят аналогии со своими проектами.
Участники общаются друг с другом и часто возникает недопонимание, так что разработчику приходится постоянно спрашивать у заказчиков их имена и (иногда) как они пишутся.
Иногда заказчик микроменеджерит разработчика, называя ему только одну следующую букву своего имени. Это нормально, я это позволяю, потому что все равно результат будет примерно тот же.
Я проверяю и (если необходимо) напоминаю заказчикам записывать время готовности, как только они получают карточку со своим именем. Когда все закончили, я останавливаю таймер.
Шаг 6: Соберите метрики первого раунда
Я прошу каждый стол назвать медиану времени готовности: «Если вы отсортируете карточки по времени готовности, какое число будет на средней карточке?». Я записываю медиану всех столов (то есть медиану медиан). Обычно получается около 50 секунд.
Еще я прошу каждый стол назвать общее время готовности, то есть сколько времени заняло написание всех 5 имен и записываю медиану этих чисел. Обычно около 60 секунд.
Настало время для небольшой веселой речи: «Вначале вы оценили, что написание одного слова займет около 4 секунд. Но это заняло более чем в 12 раз больше! Я знаю, что некоторые менеджеры проектов тайно умножают все оценки разработчиков на число «пи», но в вашем случае даже двойное умножение на «пи» не дало бы нам точную оценку!»
И затем вопрос-убийца: «А теперь просветите меня, пожалуйста. Какой из перечисленных влияющих факторов вызвал задержку?» — указывая на флипчарт:
- «У вас необычайно длинные имена?
- Ваши имена сложно пишутся?
- Ваши ручки не писали?
- Вы писали прекрасные каллиграфические буквы или высекали их на каменной табличке?
- Может у нас просто отстойные разработчики?»
После смеха и обсуждения произносится очевидное — проблема не имеет ничего общего с перечисленными факторами. В нашем списке нет самого существенного фактора — многозадачности! Я добавляю ее в список и подчеркиваю.
Все остальные влияющие факторы отдыхают.
Это был простейший проект — просто написать имя на кусочке бумаги! И тем не менее, многозадачность привела к тому, что время выполнения выросло на 1250%. И не только это, многозадачность еще и уменьшила нашу результативность в три раза по сравнению с ожидаемой. Мы рассчитывали, что напишем 5 имен за 20 секунд, а на самом деле это заняло 60!
Подошло время следующего раунда.
Если вы дочитали до этого места, значит, вам интересен полезный контент о современных методах управления. Чтобы узнавать про новые статьи, видео и бесплатные мероприятия, подписывайтесь на Telegram-канал ProAgile.
Шаг 7: Перемешайте разработчиков и объявите второй раунд
Я прошу каждого разработчика перейти к следующему столу, так что каждый стол получает нового, свежего разработчика. Я говорю им, что их приняли в новую компанию с другой корпоративной политикой.
Политика этой компании — ограничивать незавершенную работу WIP (Work In Process, работа в процессе). И текущее ограничение равно 1.
Это значит, что разработчик может работать только с одним заказчиком одновременно. Он не должен начинать писать имя Лизы до тех пор, пока не закончил с Дейвом. И бедной Марии придется ждать дольше всех, ее проект не начнется до тех пор, пока все предыдущие заказчики не будут обслужены.
Из этого правила есть очень важное следствие. Теперь разработчик контролирует входной поток! Именно разработчик решает, когда начинать проект (он «вытягивает» проект), а не заказчик (который до этого «заталкивал» проект).
Так что теперь у нас будет «вытягивающая» система (pull), а не «толкающая» (push).
Это добавляет новый шаг в начало процесса заказа.
Заказчику теперь нельзя сразу отдавать карточку разработчику. Вместо этого, разработчик сам решает, когда он готов начать следующий проект. Он протягивает руку заказчику и просит его отдать карточку и сделать заказ.
Теперь, поскольку все проекты больше не начинаются в одно и то же время, заказчику нужно записывать время начала и окончания своего проекта и считать длительность проекта, вычитая эти два значения. Так что он записывает и «время, когда работа была выполнена» и «сколько времени заняло выполнение моего проекта от начала до конца».
Теперь мы готовы начинать. Я еще раз убеждаюсь, что все понимают новые правила и что у каждого заказчика есть новая карточка (и старые карточки временно убраны).
Затем я запускаю таймер.
Шаг 8. Начните второй раунд
Наблюдайте и наслаждайтесь.
Шаг 9: Соберите метрики второго раунда
После того как все закончили, я останавливаю таймер и собираю ту же статистику, что и в первом раунде.
Отличие драматическое.
Я показываю на эти цифры и спрашиваю об отличиях между двумя раундами.
В этот раз мы выполнили каждый проект в 10 раз быстрее (5 секунд вместо 50). И поскольку общее время проекта сократилось наполовину (с 60 до 30 секунд), мы также удвоили производительность.
Вот насколько плоха многозадачность, даже для такого простого проекта как написание имени на карточке. Теперь представьте себе более сложную работу, такую как написание программы, где переключение контекста во много раз сложнее. Это вызывает еще большие задержки, проблемы с качеством и стресс. В реальном проекте время будет измеряться в неделях, а не в секундах, но пропорции остаются похожими.
Глядя на первоначальную оценку, мы можем видеть, что числа второго раунда намного ближе к тому, что мы ожидали вначале.
Еще я рисую этот график, показывающий очень типичный результат. Если позволяет время, я прошу каждый стол нарисовать свой собственный график.
Этот график отчетливо показывает, во что нам обходится многозадачность. Я спрашиваю аудиторию, совпадает ли мой график с их значениями, и обычно это так.
С этого момента я веду обсуждение. Вот некоторые примеры типичных вопросов, которые я задаю, и типичных ответов, которые получаю (или предлагаю сам).
Как вы себя чувствовали во время обоих раундов, будучи разработчиком или заказчиком?
- Первый раунд был напряженным и запутанным для обоих ролей, второй раунд был спокойным и сфокусированным.
- Во втором раунде заказчик чувствовал себя комфортно во время сосредоточенного разговора с разработчиком, пока тот работал над проектом. В первом раунде разработчик постоянно переспрашивал: «Еще раз, как вас зовут? Через какую букву пишется?»
Каково было последнему заказчику во втором раунде по сравнению с первым?
- Ожидание не напрягало, потому что я видел, что другие проекты делались очень быстро, и я понимал, сколько мне ждать в очереди. В первом раунде мой проект начался быстро, но я понятия не имел, когда он закончится.
Что вы думаете по поводу утверждения: «Если раньше начнем, то раньше закончим»?
- Опровергнуто. Упражнение доказывает противоположное. Во втором раунде каждый следующий проект (кроме первого) начался позже, но тем не менее каждый их них закончился раньше. Фактически, во втором раунде проекты заканчивались раньше из-за того, что они начинались позже. Странно, но это так.
Как это влияет на планирование релиза? Например, что мы знали спустя 10 секунд после начала первого раунда по сравнению со вторым?
- Через 10 секунд после начала первого раунда мы понятия не имели, когда все будет готово. Во втором раунде через 10 секунд мы полностью закончили 2 проекта, так что мы могли со значительной степенью уверенности оценить, когда следующие проекты будут готовы.
- В первом раунде оценка была бы попыткой угадать, даже если все другие факторы (длина имени и так далее) были бы известны заранее, потому что добавление каждого нового проекта вносит гигантскую неопределенность.
- Во втором раунде мы могли оценить общее время достаточно уверенно (в сравнении с первым раундом), даже если одно из имен длинное или сложное.
Что бы произошло, если бы разработчик переключался между задачами без потерь?
30-секундная потеря производительности возникла из-за переключения задач («потерянное» время переключения с одного проекта на другой). Но что, если бы переключение между задачами было мгновенным, то есть разработчик мог бы переключаться туда-сюда между проектами, не теряя ни капли времени?
Общее время завершения всех проектов осталось таким же — то есть никакой потери в производительности в данном случае. Но каждый конкретный проект по-прежнему длится в 5 раз дольше, когда мы переключаемся между задачами. Это подтверждает Закон Литтла, в котором по сути говорится, что если вы одновременно работаете над Х задачами, каждая из них займет в Х раз больше времени.
Поэтому, не фокусируйтесь на найме людей, хорошо выполняющих несколько действий одновременно. Вместо этого, нанимайте людей, которые терпеть не могут многозадачность и вместо этого концентрируются на создании условий, минимизирующих потребность в многозадачности: через политики ограничения WIP и т.д.
Как это влияет на качество продукта?
- Если разработчик неверно понял заказчика (например, ошибся в написании имени), то, чтобы обнаружить ошибку, потребуется 50 секунд в первом раунде, тогда как во втором раунде всего 5.
Знакома ли вам проблема многозадачности? Кто испытывает её прямо сейчас? Кто испытывал её раньше?
Практически все поднимают здесь руки…
Что заставляет нас так поступать? Почему проблема настолько часто встречается?
- Мы горим желанием угодить людям, и проще сказать новому заказчику «да», чем просить его подождать.
- Во втором раунде, во время нашей работы с заказчиком 1, когда в дверях появляется заказчик 3 и просит начать работу над его проектом, выглядит странным сказать ему: «Мы начнем работу над вашим проектом попозже, чтобы закончить его пораньше». Даже несмотря на то, что это правда.
- Мы слишком фокусируемся на запуске новых вещей, вместо того, чтобы закончить уже начатые. Например, назначая премии за привлечение новых клиентов, вместо выполнения обязательств перед существующими.
- Зачастую мы пытаемся «захватить» заказчика, начиная его проект пораньше, чтобы сократить риск потери клиента. Но такое предложение проигрышно для всех. Оно может сработать в краткосрочной перспективе, однако, если на рынке идет грамотная конкурентная борьба, такая стратегия выйдет боком в долгосрочной перспективе. Конкуренты рано или поздно узнают, что компания А делает проекты в 10 раз медленнее и вдвое дороже, чем компания Б.
Когда многозадачность хороша? Кто выигрывает в первом раунде?
- Многозадачность практически всегда плохая идея. Никто не выигрывает от нее в первом раунде.
- Ограниченная многозадачность может быть полезной в ситуациях, когда проект А не может быть продолжен, потому что ожидает чего-либо, поэтому в это время мы переключаемся на проект Б.
- Следует понимать, что несмотря на то, что ограничивать WIP важно, ограничение не всегда должно равняться 1. Любое ограничение все равно лучше, чем его отсутствие.
Вот пример команды, работающей над 4 проектами одновременно. Толстые области показывают когда же на самом деле люди выполняли работу над каждым из проектов.
Вот что происходит, когда мы ограничиваем WIP двумя проектами — один «главный», над котором мы работаем, и один «фоновый», над которым мы работаем только тогда, когда работа по главному проекту заблокирована. По главному проект у нас есть релиз-планы и обязательства, а по фоновому нет.
Что можно сделать, чтобы справиться с этой проблемой на своем рабочем месте?
Можно сделать много всего, независимо от вашей роли в организации.
- Визуализируйте проблему. Соберите метрики с текущих проектов, нарисуйте такой же график.
- Измерьте многозадачность. Спросите людей, над сколькими проектами они работают. Или повесьте клейкую бумажку на рабочем месте и рисуйте палочку всякий раз, как вы вынуждены переключить контекст. Просуммируйте эту цифру для всей команды и обсудите, как вы можете её уменьшить.
- Проиграйте многозадачную игру в имена со своими коллегами, менеджерами, заказчиками и т.д.
Помните, первый и самый важный шаг — убедить людей в том, что проблема действительно существует. Только после этого вы сможете её успешно решить. Надеюсь, эта статья вам поможет!
Масштабируем упражнение
Данное упражнение лучше всего работает в небольших группах (примерно 10-20 человек), сидящих за маленькими столами, так как это позволяет эффективно организовать обсуждение и разбор полетов. Однако, оно также хорошо работает и в группах из нескольких сотен человек. Если люди не могут разбиться на небольшие группы, сидящие вокруг столов (потому что столов не хватает или потому что слишком много людей), то вместо этого вы можете провести упражнение на сцене.
Например, пригласите на сцену 2 группы по 6 человек. Каждую группу посадите перед флипчартом. Вместо того, чтобы писать имена на маленьких карточках, разработчик пишет имена на флипчарте, а заказчик отмечает время окончания напротив своего имени. За исключением этого, упражнение идет точно так же.
Можно пригласить только одну группу, если есть только один флипчарт. Единственное неудобство будет в том, что вы не сможете так же легко переключать разработчиков.
Варианты
Это упражнение, без сомнения, может быть дополнено или приспособлено для иллюстрации других вещей. Например, что будет, если заказчик передумает посередине проекта или решит (после показа), что хочет имя, написанное полностью заглавными буквами или зеленым цветом? Что если мы добавим денежные потоки, например оплату после завершения или окупаемость проекта?
Я особо не экспериментировал с такими вещами, поскольку в упражнении я делаю основной упор на многозадачность.
Часто задаваемые вопросы
Во время первоначальной оценки не лучше ли записывать временной интервал (например, 4-6 секунд), вместо того, чтобы писать всего одно число?
Технически, да. Диапазон оценок лучше, потому что он отражает уровень неопределенности. Но все эти дополнительные числа усложняют упражнение и затрудняют чтение записей на флипчарте. Поэтому использование только одного числа — умышленное упрощение.
Почему мы используем только медиану во время подcчета результатов?
Раньше, я выписывал все результаты на доску, но это сбивало с толку. Обычно, примерно 10% участников показывают довольно странные результаты, например, потому что имеют чрезвычайно короткое имя, или потому что кто-то уронил ручку, или потому, что разработчик ошибся при написании имени и вынужден был переписать его, или потому что заказчик записал неправильное время. Медиана отражает самое существенное число.
Я также обнаружил, что любая дополнительная деталь на доске отвлекает от основной мысли, так как люди фокусируются больше на понимании цифр, а не обучении. Поэтому я не усложняю упражнение.
Я использую медиану, а не среднее значение, потому что медиану вычислить быстрее и не нужен калькулятор. Медиана в последовательности: 12, 20, 24, 25, 50 — 24. Среднее значение… эм… скукота.
Почему имена? Почему не фрукты, цвета или что-то еще?
Имена удобны, поскольку они есть у каждого заказчика (и мне не приходится их раздавать), и часто есть неочевидные требования (особенности написания и т.д.), которые служат отличным источником переговоров заказчик-разработчик и источником потенциальных ошибок. Имена также добавляют реалистичности, люди легче уставливают контакт с «кем-нибудь, кто бы мог написать для меня мое имя», чем с «кем-нибудь, кто мог бы написать название этого фрукта».
И, как положительный «побочный эффект», люди запоминают имена друг друга.
Бывали ли ситуации, когда упражнение давало обратный эффект?
Нет, не могу припомнить. Изредка попадаются участники, настаивающие что первый раунд представляет лучшую стратегию продаж, и что «фиксация» клиента отличная идея. Но обычно это вызывает протесты со стороны других участников, и оживленные дискуссии на тему краткосрочного и долгосрочного мышления, поэтому я бы не сказал, что такие ситуации дают обратный эффект.
Изредка одна из групп неправильно понимает инструкции и не следует корпоративной политике в первом раунде, что приводит к путанице в их статистике. Но в этом случае, я просто делаю упор на числа от других групп. Или делаю раунд заново.
Иногда попадается разработчик, который особенно хорош в многозадачности, и это может слегка «размыть» результаты. Но до сих пор это не было большой проблемой. Иногда заказчик подходит к задаче излишне увлеченно и начинает входить в роль «трудного заказчика», изменяя требования и чересчур придираясь к качеству. Если я это вижу, я вежливо прошу его играть помягче.
Иногда кто-нибудь жалуется, что упражнение все слишком упрощает, и что демонстрируемый отрицательный эффект от многозадачности не применим к «реальным» проектам. Остальные участники обычно приводят в ответ веские контраргументы, используя примеры из собственного опыта. Довольно весело за всем этим наблюдать.
В конце я напоминаю участникам, что это всего лишь симуляция, и она по определению искусственна. Каждый участник сам решает, что он может извлечь из этого упражнения и как применить полученные знания к своему собственному окружению.
