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

Варианта два. Либо у него, действительно, скопилась критическая масса долгов и он не может самостоятельно расставить приоритеты, либо он врёт. Чтобы увильнуть от работы или чтобы скрыть от вас детали процессов, в которых участвует, неважно.

В любом случае, услышав эту фразу, вы должны на неё триггернуться, отложить свои дела и сесть рядом с сотрудником. А затем попросить рассказать в деталях, какие именно у него сейчас дела. Составляем список, потом матрицу Эйзенхауэра, выделяем дела, которые не нужно делать или которые можно поручить другим сотрудникам. Учим расставлять приоритеты. И так до тех пор, пока это обобщение не исчезнет. Сделать это очень важно, потому что сотрудник, не умеющий справляться с потоком задач, быстро выгорит.

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

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

Не позволяйте вами манипулировать при помощи обобщений.

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

Вот вы здесь говорите, что должна быть голосовая почта. То есть, в приложении должен быть контакт, позвонив на который вы можете прослушать голосовые сообщения, я правильно понимаю? Ну а здесь по всем канонам юзабилити мы будем размещать кнопку управления группами контактов, не так ли? Здорово, что мы с вами понимаем друг друга. Мне однажды доводилось курировать разработку подобного приложения, там был случай…

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

Как не настроить заказчика против себя при сборе требований? Вести диалог так:

Вот вы здесь говорите, что должна быть голосовая почта. Как по-вашему её нужно реализовать? Как вы считаете, где стоит разместить кнопку управления группами контактов? А она всегда отображается, для всех пользователей? Есть какой-то референс?

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

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

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

Одна из ценностей T-shape подхода — взаимовыручка, когда члены команды помогают друг другу справляться с большим объемом текущих задач. Чем больше таких людей в команде, тем более гибко она реагирует на любые изменения.

Формирование команды из Т-образных специалистов позволяет достичь высоких значений bus-factor (максимальное количество членов команды, которых может одномоментно «сбить автобус» и работа при этом не остановится). В идеале значение этого параметра должно быть равно количеству членов команды минус один. То есть, в идеальной команде проект может, пусть и очень медленно, довести до конца любой произвольно взятый сотрудник. Конечно, такого идеала трудно достичь, но к этому можно стремиться.

Компании, которые хотят приобрести имидж отзывчивых и клиентоориентированных, руководствуются следующим правилом:

Дефект продукта, о котором сообщил клиент, должен быть исправлен с максимальным приоритетом.

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

В окружении проекта можно выделить следующие роли:

• Спонсор
• Заказчик и пользователи
• Менеджер проекта
• Команда
• Другие участники

Спонсор — лицо или группа лиц, снабжающее проект ресурсами.

Предположим, вы работаете в диджитал-студии, занимающейся аутсорсной разработкой. Вам в работу прилетел очередной проект. У проекта есть заказчик, который располагает деньгами и готов поделиться ими с вашей компанией. То есть, заказчик и будет спонсором? Увы, нет.

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

Проясню ещё раз. Заказчик и спонсор — в 99 % случаев разные люди. Даже во внутренних проектах.

Заказчик и пользователи — лицо или группа лиц, которые будут использовать результаты проекта (чаще всего это продукт).

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

Команда — лицо или группа лиц, которые выполняют проектные работы для достижения целей проекта.

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

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

Итак, команда — это сотрудники, которые будут писать код, тянуть сеть, таскать кирпичи и производить другие проектные работы.

Менеджер проекта — лицо, осуществляющее управление проектной командой и имеющее в качестве основной цели попадание в проектный треугольник. Формально входит в состав команды.

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

Рассмотрим все перечисленные термины в контексте местонахождения относительно проектного треугольника.

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

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

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

Для начала определимся, какие именно задачи должен делегировать руководитель. Критерий простой — финансовое влияние данной задачи на бизнес, финансовые последствия в случае провала.

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

Вот картинка с тремя квадратами, на которые следует разбивать задачи:

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

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

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

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

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

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

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

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

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

Какие приоритеты делегирования? То есть, кому из четырёх категорий сотрудников делегировать в первую очередь, кому во вторую? Возникает соблазн завалить работой уверенного профессионала, но вы рискуете допустить его выгорание, поэтому он в очереди делегирования всего лишь третий.

Если есть временной резерв, в первую очередь делегируйте начинающим энтузиастам. Это инвестиция, есть вероятность, что из него вырастет уверенный профессионал. Во вторую — усталым исполнителям и только в третью — своей гвардии, уверенным профессионалам. Также уверенным профессионалам можно делегировать, если временного резерва нет.

Картинки взял из курса City Business School по тайм-менеджменту. Если будет время, перерисую их на свой лад.

Когда задач очень много и нужно понять, какие из них следует делать в первую очередь, имеет смысл посмотреть в сторону приоритизации по матрице Эйзенхауэра, которую придумал одноимённый генерал и президент США.

Матрица состоит из четырёх квадратов и выглядит так:

Поговорим про каждый из квадратов.

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

ПриоритЕт, но приоритИзация, приоритИзировать. Режет глаз, нелогично, но это так. 

Первоначальная основа: приоритет. Усекается ет, остается приорит + глагольный морф изирова + ть = приоритизировать. От этого глагола образовано существительное приоритизация.

Грамота.ру

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

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

Зелёный. Несрочные, неважные. Это поглотители времени. Эти задачи не нужно делать вообще. При правильном планировании этот квадрат, как и красный, должен быть пустым.

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

Жить, не вступая в конфликты, невозможно. Некоторые их избегают, иные же любят поконфликтовать и поспорить. Ранее я писал, как избежать конфликтов между старыми и новыми сотрудниками. В этой статье я кратенько расскажу об уровнях конфликтов и способах их разрешения, доступных всем.

Конфликты бывают трёх уровней, а именно конфликт за ресурс, конфликт за правоту и конфликт, существующий в голове руководителя.

Конфликт за ресурс или конфликт первого уровня самый простой. Есть два или больше претендентов и один ресурс, на который они претендуют. Например, бюджет или парковочное место. Этот конфликт разруливается так называемым «методом пирога». Нужно детально разобраться в мотивации и потребностях каждой стороны конфликта. В большинстве своём выясняется, что на самом деле они хотят разные вещи и есть возможность прийти к решению, которое устроит обе стороны.

Конфликт за правоту или конфликт второго уровня. Возникает в виде апгрейда конфликта первого уровня, когда одна из сторон произносит сакральную фразу: «То есть, ты хочешь сказать, что я неправ?» При конфликте за правоту изначальный желаемый ресурс перестаёт быть важным, на первое место выходит необходимость выяснить, кто прав. На этом уровне конфликт неразрешим. За всю историю ещё никого не удавалось убедить в неправоте. Даже если дело дойдёт до суда и судья установит правоту одной из сторон, вторая сторона не успокоится и будет аппелировать, искать правоту в более вышестоящем суде. Однако этот конфликт можно понизить до первого уровня, глубоко выдохнув, собравшись с мыслями и сказав: «Ты знаешь, я подумал, всё-таки ты прав». Эту фразу очень трудно произнести, так как на первый взгляд кажется, что она предполагает отказ от борьбы за ресурс. На самом деле, это не так. При помощи этой волшебной фразы можно понизить конфликт и спокойно разрулить конфликт первого уровня методом пирога. Это работает, если конфликтуете вы. Увы, если конфликтуют ваши подчинённые, задача усложняется.

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

Уставом или паспортом проекта называется внутренний договор менеджера проекта со спонсором. Он содержит неизменные параметры проекта. Изменяется устав — перезапускается проект.

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

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

В первую очередь, устав защищает менеджера от поползновений вида: «Дай мне, пожалуйста, трёх программистов, на другом проекте очень надо». Меняется численность команды — перезапускается проект.

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

Что должно входить в состав устава?

• Название;
• Имя спонсора;
• Имя менеджера;
• Основные проектные цели;
• Треугольник ограничений;
• Перечень ресурсов, выделяемых в распоряжение проекта;
• Главные заинтересованные лица (не дублировать реестр заинтересованных лиц, перечислить только ключевых);
• Главные результаты поставки;
• Основные KPI;
• Ключевые (терминирующие) риски.

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

Ограничения следует формулировать в терминах «не более, чем». Это рамки, при выходе за которые проект теряет смысл.

В правилах игры в футбол написано, что мяч нельзя брать руками, при выходе мяча за боковую линию производится аут, при выходе за лицевую — угловой или свободный удар. В правилах не пишут, что команда А должна на 13 минуте перейти в атаку, причём форвард Б должен дать горизонтальный пас форварду С. Это глупо.

Из предыдущей цитаты следует, что устав не должен быть большим по объёму. Если вы сгенерили устав в 100 страниц, вы неправильно поняли его суть. Объём устава не может превышать 3-5 страниц, вне зависимости от того, строите вы трубопровод или делаете инновационный дейтинг с геолокацией. На проекте просто не бывает неизменных параметров на сотню страниц.

Ресурсы могут быть выражены в деньгах, а могут в людях. Заменимых людей рекомендуется записывать по названиям должностей (3 фронтендера), незаменимых, без которых вы не влезете в треугольник, можно и по имени.

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

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

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

Мне доводилось работать в небольшой компании, использующей в качестве таск-трекера clickup. В этой системе можно создать на каждый проект пространство, в котором генерить иерархические задачи. Я создавал в каждой проектной области псевдозадачу и писал в ней, собственно, устав. А в комментариях к задаче каждую неделю расписывал статус работ по проекту. Такой подход тоже имеет право на жизнь.

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

А давай сделаем MVP на костылях и с упрощённым дизайном за месяц. В следующих релизах отрефакторим и отредизайним!?

Так вот, ещё ни разу, ни одно такое приложение не было ни отрефакторено, ни отредизайнено. Это не плохо и не хорошо, просто живите с этим.