Как бы идеально ни был выстроен процесс долгосрочного планирования, к сожалению, не удастся избежать ситуации, когда постоянно появляется новый контекст:
🆕 появляется новые задачи от соседних команд
🚨 что-то ломается
🤖 появляется запросы от руководства
👨💻 коллеги приходят с рабочими просьбами
📅 появляется новые встречи в рабочем календаре
Даже если число таких запросов относительно невелико, они могут оказывать существенное влияние на продуктивность команды и добавлять серьезную когнитивную нагрузку руководителю:
😖 Теряется фокус с приоритетных задач
🐞Увеличивается число ошибок
⚡️Увеличивается напряженность
🤒Снижается эффективность и производительность
Есть много причин, по которым мы говорим «да» любому запросу, не задумываясь, нужно ли это делать и каких ресурсов нам это будет стоить.
К основным причинам можно отнести, что «да» - социально одобряемая форма ответа, а любая форма «нет» - подразумевает скореее всего непринятие со стороны оппонента и конфликты с ним.
Можно ли снизить число таких запросов или хотя бы минимизировать негативное влияние от них?
Правило 3-х гвоздей
Много лет назад, когда я пришел с запросом на реализацию фичи в одну из соседних команд, тимлид этой команды в шутку рассказал мне о советском «правиле 3-х гвоздей».
Суть этого правил состоит в следующей методике обработки запросов: как только приходит первый запрос или распоряжение - записываете запрос на бумажке и вешаете на 1-й гвоздь. Когда человек приходит и интересуется статусом запроса - перемещаете запрос на 2-й гвоздь. Как только запросом интересуются 2-й раз, нужно переместить его на 3-й гвоздь и только после этого взять в работу.
Конечно же, если в реальности придерживаться такого правила, то ни чем хорошим для руководителя это не закончится. Тем не менее, из этого правила можно взять основную идею - все входящие запросы нужно уметь фильтровать и, не пропускать часть запросов дальше.
Когда вам приходит запрос, а вы не можете взять задачу в ближайшей перспективе, вместо того, чтобы повесить задачу на гвоздь (положить ее в бэклог), стоит провести ее краткий анализ и обсудить с автором задачи следующие моменты:
💪 реально ли взять эту задачу и от чего придется отказаться ради нее?
🤞 что будет, если задача не будет решена? Какие негативные последствия будут от этого? Исходя из этого обсуждения возможно нужно будет пересмотреть приоритет выполнения задачи в бэклоге
⚖️ В каком объеме нужно решить задачу? Если ресурсов на решение задачи в полном объёме нет, возможно заказчика устоит, к примеру 80% решения задачи (тут может работать пресловутый принцип Паретто, по которому для решения 80% задачи нужно потратить 20% усилий)
🗺 Возможно ли решить задачу другим путем? Возможно, вы сможете подсказать другое решение или можно воспользоваться помощью другой команды, у которой сейчас есть ресурсы
⌛️ В случае, если задачу все же необходимо выполнить, но для быстрого решения ее альтернативных способов нет, нужно понимать, будет ли она актуальна в тот момент, когда вы сможете ее взять в работу
В итоге получается:
❌ часть входящих запросов становятся неактуальными и их можно не делать
🔒 вы укрепляете профессиональные границы
🤝 заказчик понимает приоритет этой задачи у вас и примерные сроки, когда вы сможете взяться за ее решение. Это позволит снизить число вопросов вида: «что там со сроками по задаче?»
🔥команда занимается действительно нужными задачами, которые актуальны в моменте
Умение говорить "нет" - важный навык, позволяющий снизить когнитивную нагрузку, сохранить фокус, ресурсы и энергию для ключевых задач. При этом важно уметь обосновывать отказ, приводя доводы и предлагая альтернативные варианты решения запроса.