Как расставить приоритеты в команде разработки?

Я очень завидую тем, кто может себе позволить роскошь работать над одним проектом. В этом случае прекрасно работают инструменты Agile: Scrum, Kanban. Руководителям таких проектов приходится приоритезировать задачи, относящиеся к одному проекту, с основной целью — уложиться в ограничения проекта. 

Однако, судя по общению с IT директорами, вижу, что в подавляющем большинстве организаций, ситуация в IT подразделениях очень похожа на ту, что у меня. А именно, имеется крайне ограниченное по своим ресурсам IT подразделение, на которых сваливаются “хотелки” безо всяких ограничений, а часто и без серьезной приоритезацией на уровне тех, кто должен задавать стратегию развития фирмы… Да что там говорить, выстраиванием стратегии занимаются далеко не во всех компаниях. 

В моем конкретном примере, имеется IT подразделение, в котором 4 человека заняты инфраструктурой, 12 занимаются 1С, из которых 5 — это разработчики, и еще 9 человек — это команда разработки приложений. Преимущественно под WEB, но бывают небольшие заказы на приложения под windows и android.

Бывает в компаниях вообще комичная ситуация, что приоритет на работы IT подразделения получает тот, кто громче кричит

На все это хозяйство претендует огромное количество подразделений бизнеса: маркетологи, оптовики, сетевики, розничные магазины, интернет-магазины, подразделение работы с маркетплейсами, проектные подразделения (с выделенными продуктами), склад, бухгалтерия…  Основная проблема в том, что направлений бизнеса много. Одних только продающих сайтов более 15 штук. А в нескольких базах 1С количество кастомных отчетов и инструментов за последние годы создано столько, что уже никто и не помнит, зачем оно делалось.

И получается, что хотелок много, они падают со всех сторон. Серьезного анализа на соответствие этих задач целям стратегическим целям бизнеса или хотя бы методикой определения эффекта от внедрения этих решений попросту нет. При это текущую инфраструктуру и приложения надо как-то поддерживать. Ко всему этому еще примешивается политика. Руководители продажники могут использовать свое личное влияние в высшем руководстве для того, чтобы протолкнуть свои задачи с приоритетом безо всякого анализа целесообразности этих задач. Бывает в компаниях вообще комичная ситуация, что приоритет на работы IT подразделения получает тот, кто громче кричит. На практике, приоритеты должны выставиться, исходя из стратегических задач и реальной прибыли/убытка, которую компания (получит, получит в будущем, не получит, не получит в будущем), нужное подчеркнуть, при реализации того или иного проекта или емкой задачи.

Почему матрицы Эйзенхауэра недостаточно?

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

Давайте для начала вспомним, что такое матрица Эйзенхауэра и как ей пользоваться?

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

Срочно и важно

Дела, которые делаются в первую очередь. Они не только важные, но и медлить нельзя. Применимо к управлению проектам, это могут быть неожиданные вводные, вроде маленького “нюанса”, о котором забыли упомянуть ранее или, что более часто —  аварии. В случае коммерческой структуры, важность очень хорошо оценивается в деньгах, которые компания теряет/тратит/недополучает. 

Например, неожиданно обнаруженный баг на продакшн версии ПО, которое не пойми как прошло все тесты, но может приводить к нестабильной работе приложения, с которой может столкнуться, например 20% аудитории продукта за один сеанс использования — это и срочно и важно. Чем дольше вы будете исправлять эту проблему, тем выше репутационные потери, лояльные пользователи уходят… 

С этим квадрантом все относительно просто и понятно — в нем должно быть в нормальном рабочем режиме пусто. То есть, там может быть не пусто, но к этому надо стремиться. Если вы работаете над проектом с грамотным управлением, то в начале дня все участники проекта должны хорошо понимать, какие задачи у каждого из них лежат в квадранте “Срочно и важно”. Это работы первой очереди.

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

Примечание

Если задачи на диаграмме расположены так, как на рисунке выше, то это значит, что кто-то неадекватен… У меня такая картина ассоциируется с истеричкой, у которой АБСОЛЮТНО ВСЁ важно и срочно. Вероятно, такие люди есть в каждой компании. Их легко опознать по пометке “важный email” в корпоративной переписке — они оснащают этим значком все свои письма ))

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

Квадрант “Несрочные и неважные” 

Как правило, если есть какие-то задачи, которые можно отнести к этому квадранту — это задачи, которые можно отложить в трекере задач, чтобы не маячили перед глазами и возвращаться к этому списку регулярно. Например, я просматриваю такие задачи примерно 1 раз  в 1-1.5 месяца. Некоторые из них, спустя какое-то время могут быть перемещены в другие квадранты.

“Срочные, но неважные”

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

Квадрант “Важные, но несрочные” 

Собственно, ради этого квадранта и было затеяно все предыдущее длинное вступление, на случай, если кто-то был не знаком с этим принципом приоритезации. По классике — это основной квадрант, на котором следует концентрироваться для достижения некоторой долгоиграющей цели. При этом эта “неважность” больше из серии — “20 лет без этого жили, и дальше сможем прожить”.

Применимо к IT отделу примеры таких задач могут быть следующие: 

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

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

Грамотным IT  руководителям платят неплохие деньги именно в тех случаях, когда они направляют свою команду в нужную стороны еще до того, как понадобится кризис менеджер. Очень хорошо, если IT руководитель понимает, насколько важно иметь данные по сквозной аналитике посетителей сайтов. Хорошо, когда понимает необходимость перехода на новую систему маркировки… которая “неожиданно случится обязательной” через год… Подчеркну, если он будет сидеть и ждать ТЗ, то получит его в виде аврала и словами “ППЦ, уже неделю, как ввели штрафы, если компания не отвечает тому-то и тому-то”… 

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

Например, ваша картина может выглядеть как-то так

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

Мы же помним, что ресурсы, как правило ограничены, а вы, как руководитель IT службы, должны быть в состоянии оценить, что вы сможете сделать с имеющимися ресурсами, а что сделать не сможете. И тогда передать эти данные для CEO, для принятия стратегического решения — либо мы привлекаем дополнительные ресурсы, либо отказываемся от каких-то задач до лучших времен. Другими словами, переносим их в квадрант “неважные”.

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