Матрица «Сложно-важно» – как управлять проектом с ее помощью?

Меня зовут Константин Попов, я руководитель направления 1С-Битрикс в группе компаний Т1.

В моей жизни было много проектов, не только в сфере ИТ: был девелоперский проект, проект на промышленном предприятии – развитие системы продаж, были проекты в сельском хозяйстве. И ИТ-проектов тоже было много – особенно за последние 7 лет.

В какой-то момент я начал искать некий «философский камень управления проектом». И мне кажется, я его нашел. Пусть это громко звучит, но, тем не менее.

Осенью 2022 года я уже выступал с этой темой на конференции Инфостарта. Тогда охват информации был гораздо шире, чем конкретная тема приоритизации задач – она составляла примерно треть от доклада. Но сейчас я раскрою вопрос значительно подробнее.

Инструмент, о котором пойдет речь, называется «Матрица Сложно-важно». Преимущество этой матрицы – в простоте и наглядности. Она не перегружена сложной терминологией, легко запоминается и позволяет быстро освоиться с принципами приоритизации задач.

Матрица «Сложно-важно». Незаменимый инструмент управления проектом!

Практически каждый, кто реализовывал ИТ-проекты, сталкивался с ситуацией, когда:

• Вы демонстрируете заказчику базовые возможности типового решения 1С «из коробки», а он в восторге: «Классно! Это то, что нужно!» Возникает вау-эффект.

• И наоборот – вы в ходе проекта реализуете сложную кастомную интеграцию, побеждаете ее с огромным скрипом и затратой ресурсов, а заказчик на это реагирует с раздражением: «Почему вы так долго с этим возились?»

Такая разница в восприятии обусловлена следующим:

• Интегратор (компания, которая внедряет ИТ-систему) оценивает задачу по признаку – сложно или просто ее реализовать. Именно от этого зависит планирование ресурсов, сроков, внимания и технических усилий.

• Заказчик же оценивает задачу по другому критерию – важно или неважно это функциональное требование для бизнеса.

Когда «важное» совпадает со «сложным», а «неважное» с «простым» – проблем не возникает. Но когда эти оценки не стыкуются, могут возникать сбои в коммуникации и даже риски срыва проекта.

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

Чтобы вам было проще и интереснее запомнить суть каждого квадранта, я попытался подобрать какие-то аналоги из древней мифологии – легенд и мифов древнего мира.

• Первый квадрант – «важно-сложно» – это «Золотое руно». Многие знают миф про поход аргонавтов за Золотым руном – там Ясон с товарищами собрал серьезную команду проекта, царь-заказчик обеспечил их ресурсами, команда долго плыла, преодолела кучу препятствий и привезла золотое руно царю-заказчику. Мощный проект: и заказчику это было важно, и проект сложный, и ресурсами все было обеспечено.

• Второй квадрант – важно заказчику, и просто сделать – это «Авгиевы конюшни», один из 12 подвигов Геракла. Царь Авгий приказал Гераклу почистить конюшни, где содержались огромные стада животных – лошадей, коров, быков и других. Конюшни не убирались много лет и представляли собой невероятное скопление грязи. Геракл нашел для этой задачи остроумное и простое решение – перекрыл реку и направил поток воды прямо через конюшни. Это был один из самых простых его подвигов – он справился за один день, выполнив при этом важную для заказчика задачу.

• Следующий квадрант – задача неважная и простая – это «Сизифов труд». Такие рутинные стандартные задачи есть в каждом проекте – например, мы настраиваем базовые права, выстраиваем оргструктуру, загружаем нормативно-справочную информацию. Это одни и те же простые задачи, многократно возникающие на каждом проекте – как камень, который Сизиф толкает на гору. Вроде неважно и несложно сделать, но в проекте нужно.

• И самый интересный квадрант – когда заказчику не важно, но сделать сложно – это «Гордиев узел». Согласно легенде об Александре Македонском, когда он захватил очередной город, в его честь устроили пир, на котором присутствовала и местная знать. В ходе пира устроили испытание: показали ссохшийся древний узел, завязанный много лет назад царем Гордием. Говорили, что тот, кто сумеет его развязать, станет владыкой Азии – а это как раз и была цель Александра. Он попытался развязать узел, но ничего не вышло: до него уже многие пытались, но безуспешно. Тогда он просто достал меч и разрубил узел. С тех пор и появилось выражение «разрубить Гордиев узел» – значит, справиться с неразрешимой задачей. Александр воспользовался стандартными возможностями меча для решения сложной задачи.

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

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

Таким задачам нужно уделять особое внимание:

• максимально подробное описываем требования в ТЗ;

• выделяем ресурсы с запасом;

• ставим задаче максимальный приоритет;

• контролируем ее сроки;

• тщательно планируем риски.

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

Приведу пример из практики. Однажды к нам обратилась крупная федеральная компания – официальный европейский дистрибьютор материалов для стоматологии, работающий в России. Они пришли с элементарной на первый взгляд задачей: нужно было загрузить в систему из Excel данные о компаниях и контактах. Звучит просто – сопоставить поля, нажать «загрузить», и все готово. Многие оценили бы такую задачу в несколько часов, максимум – в день работы.

Причем заказчик сразу предупредил, что до нас уже обращался в несколько компаний, и никто ему не смог помочь. Стало понятно, что этой задаче нужно будет уделить серьезное внимание – особенно, с учетом нормализации исходных данных. Причем, там оказалась непростая нормализация, с огромным количеством синонимов. Например, в списке контрагентов одно только слово «Dent» встречалось 50 раз во всех вариациях – 50 компаний с одним и тем же названием. Половина из них – разные компании, другая половина – их филиалы. Страшная вещь для ИТ-системы.

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

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

Вывод: даже если задача кажется элементарной, если она важна для заказчика – к ней нужно отнестись с полным вниманием:

• составляем подробное ТЗ в деталях;

• организуем демо-стенд с возможностью выбора вариантов;

• заложить достаточно ресурсов на реализацию;

• предлагаем заказчику подготовку подробных инструкций;

• планируем не менее 30% резервов на риски.

Следующий тип задач – Сизифов труд. Это простые и неважные для заказчика задачи – сюда относится настройка стандартных прав, заполнение карточек сущностей и другие задачи, реализация которых не составляет труда.

Здесь все максимально просто:

• Описываем реализацию в ТЗ стандартным образом.

• Не нужно готовить демо-стенды, разрабатывать сложные решения – это избыточно, все делаем простым понятным путем.

• Ресурсы выделяем без запаса.

• Реализуем с опережением сроков.

• Риски закладываем по минимуму.

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

«Гордиев узел» – самая коварная категория.

Расскажу пример из практики. Мы внедряли ИТ-систему для сети салонов оптики: запись к окулисту, заказы на изготовление очков, прочие типовые процессы. Среди требований была интеграция телефонии Mango с системой Битрикс. Казалось бы, задача элементарная – есть готовый модуль от Mango, установка занимает день-два и стоит недорого. Мы включили это как стандартный этап в проект.

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

Мы организовали большую презентацию с участием руководства заказчика. И тут директор спрашивает: «А нам точно нужны две телефонии?» – «Вообще-то нет. Мы можем их объединить».

И все – за две недели телефонии объединили, и мы успешно провели стандартную интеграцию за пару дней. Все масштабное решение оказалось не нужно вообще.

Сначала я был расстроен из-за потраченных усилий, но потом обрадовался – хорошо, что это выяснилось до реализации, а не после. Иначе потратили бы ресурсы, в потом услышали бы: «А зачем это вообще было нужно, если мы и так планировали их объединить?»

Поэтому, когда мы сталкиваемся со сложным требованием, реализация которого для заказчика не важна, мы должны действовать как Александр Македонский: разрубить это требование, превратив его в простое и решаемое стандартными средствами. Либо вообще отказаться от его реализации.

Иногда заказчик приходит с идеями, продиктованными внешними впечатлениями: например, он увидел где-то эффектную 3D-визуализацию, голографический интерфейс или дашборд с анимацией и говорит: «А сделайте нам такое же!» А потом, когда начинаешь обсчитывать все это, говорит: «Нет, тогда не надо. Мы-то думали это просто».

Такие задачи нужно максимально превратить в простые, переместив из четвертого квадранта «Не важно/Сложно» в третий «Не важно/Просто».

Итого, что у нас есть:

• Важно / Сложно. В этом квадранте у нас ключевые требования, поэтому выделяем ресурсы с запасом и следим за сроками.

• Важно / Просто. Уделяем внимание деталям и обучению. Необязательно говорить заказчику, что эта задача простая – главное, чтобы у него не возникло ощущения, что исполнитель относится к этой задаче с пренебрежением.

• Не важно / Просто – это наша стандартная рутинная работа, которую у нас джуны и миддлы максимум выполняют.

• Не важно / Сложно – это самые страшные вещи, от которых помирают все проекты. От этого нужно отговорить заказчика. И высший пилотаж, конечно, предложить ему стандартную функциональность, которая решит его задачу. Он явно будет рад этому варианту.

Если мы с самого начала правильно классифицируем функциональные требования, это закладывает фундамент всему проекту:

• Правильно расставляются приоритеты

• Эффективно распределяются ресурсы.

• Мы техническое задание прописываем грамотно – делаем детализацию там, где нужно и не тратим время на лишнее.

• Управляем достижением целей проекта.

• Успешно сдаем работы.

• Управляем изменениями проекта – все эти функциональные требования, которые прилетают в середине проекта, тоже надо рассмотреть. Может быть, это очередной «Гордиев узел», который нужно срочно разрубить или откинуть, если это возможно.

• И самое главное – в конце проекта от заказчика можно услышать: «Вы понимаете мои задачи лучше меня».

Навык заполнения матрицы «важно-сложно» нужно вырабатывать:

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

• Все, что сложно для исполнения, нужно проверять и уточнять с двойной силой – не получается ли там «Гордиев узел».

• Если требование сложное и неважное, нужно найти для него альтернативное типовое решение или отказаться от реализации.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.