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

Дело в том, что логирование времени исполнителями — это нормально. Рядовой разработчик касается в день, максимум, трёх задач. Тестировщик тоже. У дизайнера тоже плюс-минус фиксированное количество задач и честное логирование времени не представляется проблемой, будь то ведение табличек в экселе или трёхкратное нажатие кнопочки в джире.

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

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

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

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

— Sergey Voskoboynikov (@voskoboynikov) November 11, 2022

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

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

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

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

Эта статья может быть полезна начинающим PM-ам.

Снизу вверх

Я применяю этот метод чаще других. Он сводится к тому, что ТЗ декомпозируется до атомарных (или не очень атомарных, но относительно мелких) задач и каждая из этих задач оценивается. Затем оценки суммируются и мы получаем достаточно точную калькуляцию.

Недостатки метода в том, что он не работает, когда нет чёткого ТЗ и в том, что он относительно медленный.

Сверху вниз

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

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

Оценка по аналогам

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

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

Параметрическая оценка

Усложнённый вариант оценки по аналогам. Например, если мы говорим о вёрстке, вы можете по опыту предыдущих проектов понять, что, например, блок обратной связи ваш верстальщик делает за 3 часа, а классический слайдер с кружочками и стрелками по бокам — за 4 часа. Таким образом, можно рассчитать стоимость достаточно быстро и точнее, чем при оценке по аналогам.

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

Анализ предложений

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

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

Экспертная оценка

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

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

Подавляющее большинство проектов проваливается. Понять, что данный проект провалится, не очень сложно. Есть несколько маячков.

Дедлайн спущен сверху

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

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

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

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

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

Планируют и реализуют разные люди или даже подразделения

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

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

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

Руководитель проекта недостаточно квалифицирован или мотивирован

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

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

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

Не определились с особенностями реализации проекта

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

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

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

Не определены специфические критерии успешности проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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