Срочная задача прилетела? Не трогай! Сначала заверши предыдущую
"Задачка прилетела!" – знакомая фраза? Задумывались, почему задачи “прилетают”? Не “я придумал задачу”, она не поступила, она не следующая по очереди, а именно прилетела. Задача пришла в голову кому-то, а прилетела — вам. И обычно она — ооочень срочная. Каждый раз, когда к вам “прилетает” новая срочная задача, пройдите по простому алгоритму, начиная с 3-го пункта.
- Пишите список/план с задачами на день. Банально? Да! Но даже это делают немногие. Зачем план? Так удобнее распределить нагрузку и время.
- Разбейте крупные задачи на мелкие. Зачем? Так легче их выполнять, проще вносить изменения в план, больше эндорфинов от чувства выполненной работы.
- Не отвлекайтесь на всё то, что прилетает к вам в течение дня. Не приступайте к прилетевшей задаче, а добавьте в список/план, определите очерёдность (приоритет, важность, срочность, ясность).
- Доделайте текущую задачу. Не оставляйте незавершёнку!
- Только затем приступайте к следующей задаче. Возможно, ей окажется та самая новая важная, а может и нет.
Все новые задачи должны сравниваться с уже существующими в вашем списке дел. В Скраме этот подход звучит так:
Product Backlog — это упорядоченный и постоянно обновляемый список того, что необходимо для улучшения продукта. Это единственный источник работы, выполняемой Scrum Team.
Слышу вопрос:
Ага, а если новая задача настолько срочная и важная, что нет времени на завершение текущей задачи?
Во-первых, помните, что в п.2 вы разделили задачи на небольшие? Поэтому на завершение текущей подзадачи много времени не потребуется.
Важное vs срочное
Во-вторых, важное редко бывает срочным. Если задача такая очень-очень важная, то почему вы или кто-то другой вспомнили о ней случайно, а не запланировали заранее?.. Окей, такое может случаться, всякое happens, но редко. Если такие задачи появляются часто, то нужно что-то менять либо в процессе планирования, либо в критериях определения срочности и важности, либо в взаимодействии с коллегами.
Волшебный принцип разделения на подзадачи
В-третьих, старайтесь делить задачи на
- небольшие логически завершенные полезные подзадачи,
- каждая из которых будет приводить к ценному применимому результату.
Если ваши подзадачи будут небольшими, то, "словив" срочную задачу, вы сможете довольно быстро завершить текущую, а уже потом разбираться с тем, что там прилетело.
Для примера возьмём задачу: "Подготовить презентация для клиента." Разделим её на 3 подзадачи сначала вот так:
- сделать 3 слайда о проблемах;
- сделать 3 слайда о решении;
- сделать 3 слайда о выгодах.
К сожалению, ни одна из этих подзадач не приведёт к ценному результату — такую презентацию нельзя будет отправить клиенту, пока не будут выполнены все 3 из 3 подзадач. Если (а точнее не “если”, а “когда”) какая-то из подзадач займёт больше времени, подоспеет deadline или вам нужно будет прерваться, то у вас на руках не окажется ничего готового. Если понадобится переключиться на другие задачи надолго, то созданные наработки будут просто лежать и тухнуть (относится к потерям в Lean).
Попробуем эту же подготовку презентации разделить на подзадачи по-другому:
- сделать 3 оч. коротких слайда: проблемы, решения, выгоды;
- добавить 1–2 слайда о проблемах;
- добавить 1–2 слайда о решении;
- добавить 1–2 слайда о выгодах.
При таком разделении уже после завершения первой подзадачи у вас на руках будет презентация, которую можно отправить клиенту. И результатом каждой следующей задачи будет готовая презентация. Такой подход в разработке ПО называется инкрементальным.
Подытожим:
Чек-лист
1. Создайте список задач на день.
2. Крупные задачи разделите на мелкие так, чтобы после каждой получался готовый результат.
3. Прилетело что-то новенькое? Добавьте в список, определите очерёдность (важность, срочность).
4. Доделайте текущую подзадачу — не оставляйте незавершёнку.
5. Приступайте к следующей по списку.
Пробовали действовать по такому простому алгоритму? Получается? Если нет, то почему?