Смена контекстов

zabivator — 16.02.2010 Самая ужасная казнь программиста, которую только можно придумать - это смена контекстов.
Причём она бывает двух видов:

1. Кратковременная (5-10-30 минут)
Примеры:
* Коллега по работе отвлёк вопросом по поводу использования библиотеки либо твоего кода
* Менеджер пришёл с Важным Вопросом (который действительно может быть важным)
* Кто-то подошел к коллеге и громко что-то обсуждают (напомнил alexott)
2. Долгосрочная (несколько часов, дней)
Примеры:
* Ошибка, требующая безотлагательного исправления либо более приоритетная срочная задача в другом приложении, модуле проекта
* Несколько проектов, ведущихся параллельно, требующих постоянного переключения между ними.

В случае ситуации (1) "вернутся" мыслями к задаче удается спустя 15-20 минут (порог вхождения в задачу).
Что при этом происходит? Ты "вспоминаешь":
* постановку задачи или проблемы, которой ты занимаешься (чем занимаешься)
* критерии её успешного завершения (что нужно)
* план действий по реализации, состоящих из небольших шагов (как делать)
* окружение, от которого эти шаги зависят (что влияет)
* шаг, на котором ты остановился (прогресс задачи)
* конкретные действия по предпринятию шага (реализация)

Кратковременный отрыв мелким вопрос "сбрасывает кеш", кратковременную память разработчика.
После отвлечения на 5 минут, 15-20 минут может понадобиться просто для "загрузки".

В случае ситуации (2) "вернутся" к задаче удаётся спустя несколько часов, а иногда дней.
Что при этом происходит?
Ты "вспоминаешь":
* состояние проекта и твою роль в нём (кто здесь? где я?)
* задачи, которыми ты занимаешься (чем я занимался?)
* приоритет задач и их зависимости (что была главным?)
* влияние твоих задач на задачи других разработчиков и в обратную сторону (с кем я был связан?)
Тебе приходится уточнять:
* состояние задач , которые зависят от твоих либо от которых зависят твои (что со связями?)
* текущий список приоритетов (а что сейчас важнее всего?)

Во время работы над одним проектом, это информация накапливается "незаметно", она аккумулируется в процессе работы, и постоянно корректируется общением с коллегами и менеджером группы, проекта.
Переключение на другой проект или задачу просто уничтожает либо делает неактуальной (что ещё хуже) накопленные знания.

С проблемой номер (1) бороться можно введением личных кабинетов для сотрудников, поощрением электронной почты как основного средства коммуникации, пропогандой "сделай сам" и "пользуйся гуглем". Обратная сторона - ухудшение коммуникации. Нужен баланс.

Также проблема номер (1) сильно уменьшается в случае опытных разработчиков - т.к. умение кратковременно переключать контексты тренируется и развивается практикой.

Проблема номер (2) очень серьёзна, и я не знаю никаких эффективных мер борьбы с нею.
Менеджменту нужно учитывать аспекты "погружения" в проект, административными мерами обеспечивать перекрытие 90% рабочего времени сотрудников на работе (свободный график - хорошо, жёсткий - плохо, но всё хорошо в меру), и аккуратней планировать задачи и риски (с целью снизить издержки на постоянное переключение) и постараться создать условия, в которых человек не пойдёт заниматься "халтурой" или разработкой just for fun.
Достичь этого можно рыночной оплатой труда (укрощаем халтуры) и поощрением инноваций (энергию атома в мирных целях - хочет erlang? а если приемлимо - почему бы и нет?).
Да, инновации это высокие риски. Однако без инноваций вы рискуете:
1) оказаться на обочине через пару лет
2) утечка хороших кадров в более динамичные компании
3) демотивацию сотрудников.
От всех рисков не защитишься. Чем больше рисков ты упреждаешь - тем более снижаешь эффективность сотрудников. Аналогично с коммуникациями.

Мораль пусть выводят читатели.

Оставить комментарий

Популярные посты: