Отказывать без «стыдно»​

Два дня назад обсуждали с другом его эмоциональное выгорание. Произошло оно вследствие комплекса обстоятельств, одно из важных — впихивание невпихуемого. Друг брал и продолжает брать в работу больше проектов и задач, чем может выполнить. Срывает обязательства, всячески себя само уничижает, работоспособность падает, срывает ещё больше сроков, испытывает чувство вины перед коллегами и руководством, берёт на себя ещё больше. Причина — стыдно отказывать. А когда «ты не очень» отказывать становится ещё более стыдно.

Друг работает в IT-компании дизайнером. Оформляет для внутренних заказчиков презентации, придумывает и заказывает мерч, рисует и согласует баннеры для внутренних и внешних мероприятий. Делает всё, что как-то связано с визуалом. Он относительно недавно работает в компании, до его появления сотрудники справлялись сами, а теперь все бегут к нему. Одна часть проектов направлена на системные изменения, которые упростят всем и ему самому работу в будущем. Другая часть — внезапные влёты, когда заказчик просит «здесь вот чуть-чуть срочно сделать».

Безумные, вредные или бессмысленные (они же вредные) проекты отметаются, но их не так много. Все условно полезные проекты берутся в работу сразу. Отказать даже рядовым сотрудникам сложно, а уж начальнику и начальнику начальника совсем стыдно. В тот момент, когда проект взят в работу, исполнитель начинает активно ждать его выполнения. В итоге проектов в моменте в работе больше десяти-пятнадцати.

Чем больше работы в работе, тем дольше каждая из них будет выполняться. Основная причина — переключения. Время выполнения проекта состоит из трудоёмкости и простоев (когда мы занимаемся другими проектами). Чем больше проектов в работе, тем дольше простои. Например, если в работе три похожих проекта, и я занимаюсь первым, вторым, третьим, потом снова первым и так далее, то простои в первом проекте — это трудоёмкость выполнения второго и третьего проекта. Если проектов 7, то и простоев в три раза больше. Каждый раз при переключении между проектами нужно сначала отключиться от текущего, а потом заново въехать в новый проект. В некоторых случаях при очередном подходе к задаче, возникает желание всё переделать. Чем больше времени прошло с предыдущего касания с проектом, тем дольше займёт въезжание, и тем выше вероятность «надо было делать по-другому». Получается, что чем больше проектов в работе, тем больше будет простоев, и тем больше выйдет фактическая трудоёмкость каждого из них. А это мы ещё не берём в расчёт вред от переключений, который периодически «доказывают» психологи.

Если мы специально не создадим систему приоритетов, она всё равно появится. Её создадут особенности культуры и особенности исполнителя. В нашем случае исполнитель хочет всем угодить, а заказчики проактивные и постоянно пушат свои задачи. Периодически они приходят и задают вопрос: «ну как там с моим проектом?». Наш бедный исполнитель покрывается испариной, бросает то, чем занимался, и начинает в панике воскрешать затянувшийся проект. И так несколько раз в день. В итоге система приоритетов такая – про какой проект спросили последним, тот и в приоритете. Чем более ответственные у нас заказчики, тем чаще будут случаться переключения.

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

В качестве ограничения можно взять трудоёмкость проекта (это не вполне «правильное» использование, но это лучше, чем ничего). Тех, кто попробует сделать такую систему приоритетов, хочется сразу предостеречь. «Лучше быть приблизительно правым, чем абсолютно точно ошибаться». Не нужно слишком усложнять, накручивать веса, брать десять параметров. Нам нужно как-то приоритизировать между собой проекты, чтобы стало лучше, чем никак. Если вы сделаете очень сложную формулу, она, вероятно, не станет от этого точнее и объективнее, но точно станет более сложной во внедрении и использовании.

В медицинской компании в качестве важных параметров мы брали влияние на среднее пребывание пациента в клинике (основное ограничение), влияние на прибыль, влияние на операционные затраты. Для HR-проектов в IT-компании выбрали влияние на текучку, влияние на скорость адаптации новых сотрудников, влияние на скорость поиска новых сотрудников. Дальше все проекты можно сравнить между собой и задать значение каждого параметра. Например, HR-проекты «внедрение процедуры онбординга» и «создание базы знаний» будут иметь высокую оценку по параметру скорость адаптации, но низкую по параметру скорость поиска, а проект «разработать реферальную систему рекрутинга» наоборот.

В итоге у нас получится некоторая оценка важности проекта в попугаях, которую нужно будет поделить на трудоёмкость проекта. Трудоёмкость так же нам нужна примерная. Допустим, первый проект обладает важностью десять, а второй важностью тридцать. Трудоёмкость первого проекта — одна неделя, второго – два месяца или 8 недель. Тогда приоритет первого проекта 10/1=10, второго 30/8=3,75. В первую очередь делаем первый, затем второй.

Ещё один необходимый шаг – ограничить количество проектов/задач, над которыми мы работаем одновременно. С нашим дизайнером мы решили взять за ограничение — три плановых проекта (шесть часов в день), и оставить два слота под срочные (два часа в день). Срочные задачи прилетают всегда. У кого-то чаще, у кого-то реже, но они прилетают. Хватит изображать наивность, пора их планировать. Если срочняки не случатся (ну а вдруг), то у нас просто будет возможность быстрее выполнить плановые проекты.

В итоге, когда приходит новый заказчик – мы оцениваем приоритет его проекта. Если лимит работы в работе заполнен, то ставим в очередь. Чаще всего, даже если важность проекта выше тех, что уже в работе, мы сначала завершаем работу над одним из проектов, а потом запускаем новый. Ограничение количества проектов приводит к уменьшению переключений, сокращению трудоёмкости и простоев. Проекты начинают выполняться заметно быстрее.

Сложно сказать: «у меня и так много работы», но намного проще сказать: «вот твой проект, у него такая-то важность для компании, поэтому я возьмусь за него после того, как сделаю это и это».

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

Ребята сделали систему приоритетов и ограничили количество проектов в работе. От этого стало легче, стало лучше с планированием и завершением проектов в срок, да и сроки выполнения проектов сократились. Тем не менее заказчик всё равно оставался недоволен, потому что некоторые заказы откладывались, и откладывались, и откладывались. Чтобы его осчастливить, для начала нам пришлось его ещё больше расстроить. Когда запросы заказчиков бесконечны, а ресурс ограничен, нужно научиться отказывать заказчикам. Лучше один раз расстроить отказом, чем бесконечно расстраивать откладыванием.

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

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

Мой канал с уведомлением о новых заметках и короткими заметками, которых здесь не будет

Александра Брызгалова