Автор: Лера Фимина

7 лет в управлении

Привет! Меня зовут Лера, я в управлении проектами уже 7 лет. Реализовывала проекты на стыке AR/VR/ML-технологий в сервисной компании. Сейчас работаю в EdTech и параллельно занимаюсь менторством начинающих проджектов и руководителей.

Прежде чем мы перейдем к основной части статьи, ответьте, пожалуйста, на несколько вопросов:

• Вы руководите командой и часто работаете в состоянии авралов и «тушите» пожары?

• Вам приходится регулярно жонглировать задачами и менять их приоритеты?

• Ваша команда делает все не так и приходится объяснять задачу по несколько раз?

• Вы считаете, что проще сделать самому, чем объяснить, что нужно?

Сколько раз вы ответили «да»? Если почти на все, то у вас явно есть проблемы с делегированием, которые, скорее всего, вытекают из проблем с постановкой задач своей команде. И, значит, эта статья будет полезна для вас.

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

Почему начинающим?

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

Как же понять, можно делегировать задачу команде или нет? Тут-то нам и понадобится метод SMART, о котором пойдет речь.

Метод SMART

Плохая постановка задачи/цели = плохой результат.

SMART может помочь донести до команды образ нужного результата. Этот метод предоставляет структурированный подход к постановке целей и задач и позволяет убедиться, что они ясны, измеримы, достижимы, релевантны и ограничены по времени.

S - specific - конкретность

Задача должна быть четко и конкретно сформулирована. Вместо общих и неопределенных формулировок, она должна содержать ясность и конкретику для всех участников.

Вопрос-помощник: что вообще нужно сделать?

M - measurable - измеримость

Задача должна быть измеримой. Это означает, что должны быть критерии успеха, которые позволяют объективно оценить ее достижение или промежуточные результаты. Критерии выполнения могут быть качественными или количественными.

Вопрос-помощник: есть ли у нас в описании задачи показатель, по которому можно отследить прогресс?

A - achievable - достижимость

Задача должна быть достижимой. Это означает, что она должна быть реалистичной, учитывая доступные ресурсы, время и способности. Тут можно дополнительно установить ограничение на использование каких-то ресурсов, времени и т.д.

Вопросы-помощники: какие есть ограничения для достижения задачи/цели? Что нужно использовать, чтобы реализовать задачу?

R - reasonable - релевантность

Задача должна быть обоснованной или соответствовать общим целям и стратегии компании, продукта или проекта. Она должна иметь значение и важность для команды или компании.

Вопросы-помощники: почему эта задача важна? Какое обоснование задачи объяснит коллеге приоритетность этой задачи относительно тех, что уже есть?

T - time-bound - ограниченность по времени

Задача должна иметь определенный срок завершения. Установка конкретного дедлайна помогает понять приоритетность и срочность этой задачи, благодаря чему коллега сможет организовать работу для достижения задачи в определенный срок.

Вопрос-помощник: когда нужен результат или его промежуточная версия?

Также стоит отметить, что SMART – это не волшебная таблетка и может произойти такое, что даже если вы поставите цель или задачу по SMART, команда может выполнить ее не точно, не в срок, не с тем качеством.

Примеры

Не SMART:

Оптимизировать затраты на производство продукта

Комментарий:

Цель конкретна: оптимизировать затраты на производство продукта.

Цель достижима: допустим, что в компании раньше процессы не оптимизировали и там есть, чем заняться.

Обоснована: так как оптимизация затрат = увеличение прибыли, при этом, если кто-то в команде не знает зависимости метрик, то стоит это дополнительно прописать.

Цель не ограничена во времени = непонятны сроки.

Цель неизмерима = непонятны сроки.

За 2 месяца увеличить метрику bookings продукта

Цель конкретна: увеличить количество bookings продукта.

Цель ограничена во времени: 2 месяца.

Цель достижима: допустим, в команду вышел новый лид в маркетинг, который знает, как реализовывать такого рода цели.

Цель обоснована: увеличение этой метрики позволит больше зарабатывать.

Цель не измерима: непонятно, на сколько нужно увеличить эту метрику.

Увеличить количество активных пользователей сайта 

Цель конкретна: рост количества активных пользователей.

Достижима: допустим, на это есть ресурс в компании.

Обоснована: от количества активных пользователей зависит количество продаж.

Не измерима: на сколько нужно увеличить?

Цель не ограничена во времени: не определен дедлайн, за который нужно ее достигнуть.

SMART

Оптимизировать затраты на производство продукта на 7% за Q4’23 за счет пересмотра процессов логистики, чтобы увеличить его прибыльность.

За 2 месяца увеличить количество bookings продукта на 9%.

Увеличить количество активных пользователей сайта на 20% за Q4’23.

Вроде бы все понятно, но возникает вопрос, почему этим инструментом не так часто пользуются? Многие про него слышали, но не используют на практике?

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

Или иногда бывает так, что если коллега в контексте проекта/ситуации, хочет продумать план решения задачи, можно опустить такой параметр, как достижимость. Часто его специально не используют, чтобы посмотреть, насколько коллега самоходен, компетентен и может показать себя. Или же бывают коллеги, которые не любят получать точные указания, так как любят решать задачи самостоятельно.

Также иногда можно не использовать критерий релевантности/обоснованности. Например, когда у вас горит проект и вы быстро раскидываете задачи, чтобы успеть в срок. Тут важнее скооперироваться всей командой и выполнить проект в срок, чем обсуждать, насколько эта задача обоснована и т.д.

Давайте рассмотрим пример:

Представим, что вы руководите командой продукта. Продакт-лид поставил вам задачу:

«Оптимизировать себестоимость производства продукта. Дедлайн — конец этой недели».

Чего не хватает во вводных?

Критерии, которые нам всегда нужны для постановки задачи — это Конкретность и Измеримость. Эти критерии важны для получения образа результата. Без синхронизации по конечному результату есть большая вероятность сделать не то, что нужно, и в итоге переделывать работу несколько раз.

Также стоит уточнить у лида, на какой процент необходимо оптимизировать себестоимость?

Также важно всегда использовать критерий Ограниченности по времени.

В нашем примере есть дедлайн — «конец этой недели». Но он точно не реалистичен, поэтому важно узнать, почему руководитель назвал такой дедлайн? Какой реальный срок?

В идеале, конечно, если мы говорим о такой большой стратегической задаче, взять паузу, подумать самому, обсудить запрос с командой и назвать свои сроки лиду, объяснить, почему на реализацию необходимо столько времени и согласовать его.

В нашем примере не раскрыт критерий Достижимость. Возможно, эта задача будет для вас и команды новой, поэтому можно уточнить, какие есть мысли по реализации этой задачи? Может быть, кто-то проводил похожую оптимизацию в смежных продуктах? Или лучше начать с какого-то определенного этапа производства продукта?

Также в нашем примере опущен критерий Обоснованность. Тут зависит от того, насколько задача действительно авральная, что мы с вами доуточнили на несколько шагов выше. Если есть веские причины реализовать ее как можно скорее, то стоит изменить приоритеты команды и взять ее в работу. Другое дело, если «горящие» задачи прилетают регулярно – тут уже стоит менять сам процесс.

Давайте переделаем этот пример в задачу по SMART:

S — Нужно оптимизировать себестоимость производства нашего продукта

M — На 8% процентов

A — Для консультации к вам подключится продакт менеджер из смежного продукта, который проводил похожую оптимизацию  в прошлом квартале. Судя по нашим метрикам, стоит обратить внимание на процесс работы отдела логистики

R — Оптимизация себестоимости продукта — один из главных приоритетов компании на Q4’2023

T — Промежуточный результат важно демонстрировать каждый месяц, завершить задачу нужно к концу Q4’2023

А всегда ли нужен SMART?

Не стоит использовать инструмент ради его использования. Бывают ситуации, когда это не нужно, например:

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

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

• rnd или креативные задачи. Тут мы не всегда можем сформулировать образ результата и поэтому мы скорее прописываем ограничения и примерные варианты развития событий в рамках задачи. В таких случаях формулирование задач происходит по другому флоу.

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

То есть у нас получается 3 этапа:

1. Формулировка задачи по SMART. Об этом я рассказывала выше.

2. Обсуждение процесса реализации задачи. Не стоит просто отправить команде задачу по SMART и ждать результата. Лучше всего убедиться, а правильно ли вас поняли? На этом этапе необходимо ответить на уточняющие вопросы по задаче, обсудить ожидаемый результат, уточнить верхнеуровнево план реализации, что нужно для выполнения задачи от руководителя, какие доп. ресурсы нужны и т.д.

3. Фиксация промежуточных итогов. На этом этапе стоит определить «вехи» и даты их демонстрации, по которым вы будете синхронизироваться с командой, что выполнение задачи идет в верном направлении и обсуждать проблемы, которые могут возникать в ходе выполнения задачи. А также сам дедлайн итоговой демонстрации задачи. Об этом стоит договориться заранее, чтобы потом не было недопонимания и вопросов по статусам

Надеюсь, у меня получилось объяснить вам важность постановки SMART задач и это поможет вам в вашей работе!

А тем руководителям и тимлидам, которым актуально погружение в более высокоуровневые, стратегические задачи, рекомендую обратить внимание на открытые уроки в OTUS:

• Стратегическая сессия как основа для формирования целей ИТ-компании, 9 ноября

• Управление сопротивлением изменениям при реализации стратегии, 23 ноября