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

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

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

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

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

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

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

В качестве ограничения можно взять трудоёмкость проекта (это не вполне «правильное» использование, но это лучше, чем ничего). Тех, кто попробует сделать такую систему приоритетов, хочется сразу предостеречь:

Не нужно слишком усложнять, накручивать веса, брать десять параметров. Нам нужно как-то приоритизировать между собой проекты, чтобы стало лучше, чем никак. Если вы сделаете очень сложную формулу, она, вероятно, не станет от этого точнее и объективнее, но точно станет более сложной во внедрении и использовании.

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

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

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

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

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

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

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

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

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

01/ Ожидание и реальность [почитать]

02/ Неограниченные хотели и ограниченные возможности [почитать]

03/ Теория ограничений и проектное управление. Что не так со сроком задачи? [почитать]

04/ Почему мы продолжаем срывать сроки проектов? [посмотреть]

05/ А вам слабо сократить незавершенку? [посмотреть]

Мой телеграм-канал, где я оповещаю о новых заметках и делюсь короткими инсайтами и мыслями, которые не попадают сюда. Ещё там можно обсуждать идеи и смотреть на ТОС с разных сторон вместе с другими