Е. Гетманенко

Не секрет, что любой начальник страстно желает, чтобы на его просьбы откликались молниеносным «Понял, сдеалаю». Но это ситуация для страны зазеркалья.

На практике, дело далеко не всегда обстоит так радужно и возможны две вещи:

1. Что тебя не поймут с одного прискока без дополнительных вопросов.
2. Ты (начальник) не всегда можешь прервать исполнителя в тот момент, когда ты ставишь задачу, чтобы её объяснить — ибо исполнитель может быть занят другой твоей же самой-важной-на-свете задачей.

Вернее, пункт 2 — это описание желательного поведения и его можно было бы нарушать. Но в чем проблема? Представим, что мы управляем промышленным заводом. Так вот, если ваш завод может выпускать два продукта на одной производственной линии, то как правило переключение с одного на другой продукт сопровождается технологическими потерями материала, плюс простоем оборудования в связи с переналадкой его на выпуск иного продукта.

Из чего следует, что чем больше прерываний, тем больше потери на ожидание, а не на производство. Значит, меньшее количество произведенного продукта или результата.

Аналогично с IT — чем чаще вы дергаете исполнителя, а в особенности программиста, тем больше времени ему нужно, чтобы обратно погрузиться в ту задачу, которой он занимался. Многозадачность довольно болезненная вещь, где по долгу службы требуется концентрация. Отмечу еще раз, тут ключевое — не специализация исполнителя, а характер работы.

Поэтому хорошей практикой было бы ставить задачи асинхронно:

Постановщик вносит запись с достаточным на его взгляд описанием проблемы и путём или методом её решения.

Исполнитель в удобное для него время — я имею в виду не в тот момент, когда он приступит к задаче, а когда он закончил текущую и готов переключиться на другую — просматривает список задач, находит непрочитанные, проверяет и подтверждает, что вопросов по задаче нет. Если вопросы есть — футболист таск на уточнение постановщику.

В таком режиме можно работать с большим количеством задач с меньшими потерями на переключение.