Как навести порядок в проектах с p3express

Теория управления проектами стала слишком сложной и размытой. Когда звучит слово «проект», мы представляем себе что-то большое и грандиозное — строительство моста, создание новой вакцины, в крайнем случае разработку нового приложения.

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

С другой стороны, совсем без инструментов, документации и дедлайнов справиться с проектом не получится. Это Дмитрий Ильенков из Project Management Club и автор канала @pmclub на конференции TeamLead Conf 2020 наглядно показал в своем выступлении. И там же  познакомил нас с p3express — с простым фреймворком для проектов любого размера. Этот минималистичный, но системный фреймворк для управления проектами предлагает 37 понятных шагов — от идеи проекта до работы с выгодами по его завершению.

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

– Ты был на TeamLead Conf? Поделись, пожалуйста, с командой инсайтами!

– Можешь помочь обновить сайт?

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

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

Но несмотря на это,  мы можем снова и снова браться за небольшие с виду проекты-просьбы, пока в какой-то момент не остановимся и не подумаем: «Блин, я же через это проходил, меня же уже просили что-то немножко сделать, это же был проект! Возможно, сейчас это тоже проект и я буду управлять им как проектом»? Но почему так получается? Почему мы этого не делаем, хотя знаем, что раз за разом подписываемся под проекты? Почему мы игнорируем проектное управление вместо того, чтобы избежать всех проблем с дедлайнами и ресурсами, спланировав и оценив наши действия?

Этому есть несколько причин. 

Проекты проходят мимо радаров

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

Много букв

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

Я очень люблю PMBOK, и я — PMP. Я был президентом Московского Chapter PMI. Но шестой PMBOK  — это 700 страниц, это реально много. Во-первых, ты их и сам не прочитаешь, а во-вторых, ты не заставишь, а тем более не убедишь прочитать их команду. А  в-третьих, кто хочет для небольшого проекта использовать 700 страниц проектной методологии? Есть желающие? Обычно не находятся.

Нам уже было больно

Третья проблема: к вам в компанию приходили консультанты по управлению проектами? Я за последние полгода два раза столкнулся с абсолютно одинаковой историей в двух разных компаниях. К ним приходили консультанты, писали методологию и десятка полтора шаблонов.Люди пробовали заполнить эти 15 шаблонов, но даже 15 шаблонов —это очень много. Им было больно, у них не получилось, им не понравилось. Они теперь ходят и рассказывают: проектное управление не работает! Хотят ли они попробовать еще раз? Спасибо, нет.

Возникает вопрос: 

Что делать?

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

Решением будет использовать более простые решения. Тот же самый PMI, правообладатель того самого PMBoK, у которого в шестой версии 700 страниц, в стратегии 2.0 прямо написал: «Пришло время легковесных фреймворков». Седьмой PMBoK (я сейчас пишу к нему комментарии), который, надеюсь, выйдет в этом году, в части стандарта занимает только 37 страниц — чувствуете разницу? Проще нужно, проще!

И я хочу рассказать как раз о простом, но при этом системной фреймворке, который придумали мои партнеры Надер Кей Рад (Nader K Rad) и Фрэнк Тёрли (Frank Turley). Надер как раз в числе авторов этого короткого классного PMBoK.

p3express

Фреймворк p3express — это поток, который проведет вас от появления идеи проекта до получения выгоды от достигнутых результатов и пользы этого проекта.

В чем его фишка?

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

В управлении проектами этого категорически не хватало до сих пор. Даже мой любимый PMBoK или очень красивый британский PRINCE2 никогда ни в одном месте не отвечают тебе на простой вопрос: что нужно делать завтра? Они пишут, что лучше делать так, есть принципы и процесс, следуй процессу, но — завтра мне что сделать? 

p3express — это пошаговый алгоритм:

• Последовательно проходим 37 шагов, начиная от подготовки;

• Заходим в циклы, в которых работаем

• Выходим на закрытие проекта

• И дальше — к пост-проектным активностям, когда извлекаем выгоды:

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

Контекст имеет значение, поэтому наполнение вы адаптируете сами. За счет этого p3express становится одновременно:

• Тиражируемым — есть понятная система, ты берешь и переносишь ее;

• Адаптируемым — за счет универсальности он подходит к проектам любого размера: от совсем небольших до более крупных.

Пройдем по шагам от начала до конца и посмотрим, 37 шагов — это много или мало? Спойлер: немного.

Подготовка проекта

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

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

А01. Определить спонсора

Подготовка начинается с того, что мы определяем, кому этот проект вообще нужен. В проектном менеджменте есть спонсор (куратор) проекта — это человек, который заинтересован в результатах проекта и готов на него выделять ресурсы, не обязательно деньги. Это могут быть еще компетенции, экспертизы, какие-то связи. Это может быть кто-то из топов вашей компании или product owner. Главное, чтобы этому человеку нужны были результаты проекта и он был готов в него вкладываться — не каждый день работать в проекте, но вкладываться и поддерживать его.

Результаты исследования «Пульс профессии» (глобальное исследование в проектном менеджменте от PMI, обзор на русском) показывают, что компании, которые лучше управляют проектами и демонстрируют больше успешных проектов, чем в среднем, — имеют большую поддержку со стороны спонсоров проекта. И около четверти проектов, которые прямо провалились, в числе причин провалов указывают низкую поддержку спонсора.

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

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

Третьей причиной (из-за которой лично мне больно) бывает то, что приходишь в компанию и спрашиваешь, есть ли у ваших проектов спонсор? Они отвечают: «Да! У всех наших проектов есть спонсор. Это генеральный директор». У меня была своя история, когда я на эту ловушку попался. Я презентовал проект руководству компании, проект одобрили и даже дали подразделение в придачу. Я подумал — все круто! А через какое-то время мне влетело еще несколько проектов, на меня повесили кучу рутины, а замруководителя, который меня курировал, сказал: «Оставьте себе этот проект как хобби». Я посмотрел, как проект чахнет — и ушел.

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

А02. Составить резюме

Здесь мы отвечаем на очень простые вопросы: 

• Что мы хотим получить в результате проекта? 

• Зачем это нам нужно? 

• Сколько у нас есть на это времени и денег? 

• Что может пойти не так? Другими словами — какие риски могут возникнуть.

Ответы на эти вопросы мы упаковываем в простой одностраничный документ — это и называется резюме проекта. И эти ответы дают нам понятную пользу: задают вектор проекта и его границы.

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

А03. Определить лидера проекта 

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

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

А04. Развернуть рабочее пространство

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

А05. Определить команду

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

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

Возможно, вы встретите кого-то на TeamLead Conf, кто сможет вам помочь. Люди достаточно охотно делятся экспертизой — нам нравится чувствовать себя востребованными и полезными. Не пренебрегайте этой ролью, находите людей, которые помогут вам не повторять их ошибки, не наступать на их грабли. Не обязательно на full-time и за деньги, но привлекайте такую экспертизу в команду, чтобы сделать проект сильнее.

А06. Планирование проекта

Здесь мы декомпозируем проект, неважно, в каком формате — иерархическая структура, бэклог, PBS из PRINCE2 — любым способом, но это нужно сделать. Это позволяет нам потом приоритизировать продукты, которые получаем в рамках создания итогового продукта, повышать управляемость проекта и качество наших оценок.

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

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

А07. Определить внешних исполнителей

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

А08. Провести аудит подготовки

Еще одна особенность p3express — это поддержка здоровья проекта. Мы любим что-то контролировать, или по крайней мере стараемся поддерживать проект в русле — смотреть, чтобы он сильно не отклонялся от сроков и бюджета. Но почему эти отклонения происходят? У всего есть какая-то причина. Если мы действительно хотим поддерживать наш проект в русле, нам нужно искать проблему до того, как она становится уже пост-мортемом типа: да, мы не успеваем.

И первое в здоровом проекте — это чек-лист «Аудит подготовки». Перед тем, как принять окончательное решение — запускаем проект! — ответьте на несколько простых вопросов:

• У нас есть резюме проекта?

• Оно доступно команде?

• Мы развернули рабочее пространство?

• У членов команды есть доступ?

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

А09. Да/нет

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

Я был в такой ситуации: динамичная компания, и все в ней что-то делают — но это не точно. 5 дней в неделю люди работают, делают свои проекты и готовятся к защите этих проектов. Они выходят на защиту проекта, там им что-то советуют, комментируют, не говорят ни да, ни нет — и они снова продолжают одновременно и делать проект, и готовиться к защите. И совершенно непонятно — есть проект или его нет?

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

А10. Провести kick-off

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

А11. Фокусированная коммуникация

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

Не надо партизанить, коммуницируйте о проекте с теми, к кому он может относиться.

Циклы

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

Планирование цикла

А12. Обновить планы

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

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

А13. Определить внешних исполнителей

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

А14. Да/нет

Каждый месяц отвечайте на вопрос: нужно ли продолжать проект? Мы иногда забываем, когда следует закончить проект. Один ответ очевиден — мы все сделали, передаем результаты своей работы. Но бывают другие причины для остановки и закрытия проекта. Например, он утратил свою актуальность, изменилась ситуация в компании или изменилась ситуация на рынке. Зачем продолжать тратить ресурсы, если их можно переключить на что-то более полезное?

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

Итак, если решение положительное, то переходим к следующим шагам.

А15. Провести kick-off цикла

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

А16. Фокусированная коммуникация

Коммуницируем наши планы на этот цикл и переходим дальше к работе. Расскажите о достигнутых результатах, возникших рисках. Попросите помощи, если она нужна.

Еженедельные  действия

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

А17. Оценить прогресс

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

Что нужно проверить?

1. Метка-статус vs комментарии. Проверьте, соответствует ли метка-статус комментариям к продукту. Противоречий быть не должно. Для наглядности и простоты вы можете, например, использовать цветовые метки: зелёная — продукт готов, жёлтая — продукт в работе, красная — продукт не готов/проблема с продуктом.

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

3. Результаты vs бюджет. Сравните план по использованию бюджета с фактическими данными. Если перерасход, то по какой причине? Сделали больше запланированного или причина серьёзнее? Если бюджет не освоен — откуда взялась экономия?

4. Сопоставьте прогресс с другими проектами. Вы работаете не в вакууме: какие-то отставания критичны, а какие-то — нет, если в связанных проектах всё стоит.

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

А18. Работать с отклонениями

Работаем с найденными отклонениями (если требуется наше активное участие):

1. Убедитесь, что вы собрали полную и достоверную информацию;

2. Проранжируйте проблемы по важным для вас критериям — например, срочность/критичность;

3. Выберите наиболее острые проблемы;

4. Соберите дополнительную информацию;

5. Решайте проблемы на своем уровне или выносите их на уровень спонсора;

6. Помните, ваша задача — решить проблему, а не найти крайних.

А19. Еженедельная встреча

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

А20. Еженедельный аудит

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

А21. Фокусированная коммуникация

Пройдя аудит, мы снова направляем фокусированную коммуникацию, потому что то, что мы проговорили на встрече — это здорово, но отправить  follow-up — еще лучшая практика. Иначе все забывается и путается.

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

– Сделано? Сделано. ОК.

– Не сделано? Смотрим — почему. Но ни о чем не спорим, ничего глубоко не обсуждаем, просто тэгаем того человека, который может решить эту проблему и внести вклад в обсуждение.

Такие звонки у нас длились полчаса максимум, и 15 минут из этого времени уходили на «Как дела? Мы так рады с вами работать!» — все эти американские любезности. То есть мы успевали всё обсудить за 15 минут. После созвона лидер проекта направлял коммуникацию команде, что происходит в части работы с этим подрядчиком.

Это действительно идеальная история, и каждая может быть такой. Почему так обычно не получается? Да потому что проблема возникает на этапе получения информации. Информация о проекте, которой мы располагаем, часто бывает не релевантной. Вопрос — как мы ее измеряем, как ее визуализируем, что используем (метод освоенного объема, диаграмма сгорания, еще что-то) — это вторичный вопрос. Важнее вопрос: насколько мы и команда делаем работу над проектом прозрачной, насколько у нас постоянно есть доступ к этой информации? Все любят пользоваться таск-трекером на словах. На деле разные ситуации бывают. 

Почему мы плохо пользуемся такими инструментами? 

1. Один вариант — команда не понимает, как ими пользоваться технически. По дефолту нельзя рассчитывать, что все всё понимают, все прочитали инструкцию. Нет, людям нужно помочь и немножко их обучить.

2. Второй вариант — люди не очень понимают, зачем это надо. Тоже можно объяснить.

3. Третья ситуация смешнее и страшнее. Я ее наблюдал сам. 

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

Но вице-президент на эту встречу не пришел — это был первый звоночек. Второй звоночек был, когда его помощник нам сам создал доски и направил туда приглашения. Через пару недель вице-президент спрашивает: «А что вы не ведете ваши доски?», но сам при этом так и не зарегистрировался в Trello.

Убедитесь, что вы посылаете команде правильные сигналы, что это не история: «Не живи, как живет учитель. Живи, как учит жить учитель» — подавайте личный пример.

Ежедневные действия

Это даже не шаги, а рекомендации к ежедневным действиям. Каждый день мы сталкиваемся с какими-то новыми задачами, проблемами и рисками. RICs — это риски, проблемы, запросы на изменения. Тот же наш опрос тимлидов показал, что одна из проблем — это постоянно прилетающие новые задачи. И это неизбежно.

Что можно делать?

А22. Зафиксировать RICs

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

А23. Реагировать на RICs

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

А24. Принять готовые продукты

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

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

А почему возникает мультизадачность? Это происходит не только потому, что нам постоянно прилетают новые задачи, но и потому что мы не закрываем старые. 

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

Принимайте результаты работы как можно чаще!

Закрытие цикла

Каждый цикл мы открываем и закрываем.

Закрытие цикла состоит из трех шагов:

А25. Оценить удовлетворённость заказчика и команды

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

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

Приведу пример. История случилась со мной буквально неделю назад. Приходит письмо с адреса одного из наших партнеров: «Объясните, как мы можем вернуть денежные средства» — ни здравствуйте, ни пожалуйста, ни подписи. Думаю — нормально же общались, что случилось, почему деньги вернуть? Оказывается, сотрудница бухгалтерии отправила письмо по ошибке.

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

А26. Запланировать улучшения

Прогресс сам по себе не придет. Нужно понять, где можно работать лучше, что для этого нужно сделать. 

А27. Фокусированная коммуникация

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

Закрытие проекта

А28. Передать продукт

Вы уверены, что передавая продукт, вы его передаете правильным людям? Со мной случилась (к счастью, это было давно) очень забавная история. Компания, где я работал, решила внедрить довольно дорогую систему бизнес-аналитики. Купили 5 лицензий. 

Результат:

• Сколько из них пошли пользователям? Всего одна, две отдали айтишникам, две — топам.

• Сколько человек обучили пользоваться этой системой? Одного из айтишников (самого хитрого). Он стал носителем сверх-знаний и не потерялся — через полгода  стал начальником отдела по работе с этой системой.

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

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

А29. Передать проект

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

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

И в идеале именно этот человек проходит следующие шаги.

А30. Оценить удовлетворённость заказчика и команды

Последний раз оценивается удовлетворенность заказчика и команды. 

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

А31. Провести аудит проекта

В целом оценивается эффективность управления проектом.

А32. Извлечь уроки 

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

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

А33. Отметить окончание проекта

Можно сколько угодно говорить про выгорание, но если человек приходил на работу, делал-делал проект, не спал ночами и, завершив проект, пошел домой, поспал, вернулся и у него новый проект — это похоже на день сурка, причем паршивый день сурка. Не надо этого допускать. Умейте радоваться жизни — «Work Hard & Play Hard», отмечайте с командой все достижения, а окончание проектов — тем более.

А34. Фокусированная коммуникация

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

После проекта

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

А35. Оценить полученные выгоды

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

Мы об этом часто забываем. В презентациях часто красиво написано: «Внедрение CRM сократит ваши расходы на отдел продаж на 100%! Мы сократим расходы на ФОТ!». Подождите, сокращение расходов на ФОТ — это значит, кого-то уволили. Это называется disbenefits — то, что для кого-то хорошо, для кого-то плохо.

А36. Спланировать дополнительные действия

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

А37. Фокусированная коммуникация

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

• По мотивации; 

• По улучшению проекта. Люди должны понимать, что от них ожидают;

• По борьбе с бесполезными проектами.

Есть статистика от The Standish Group, сколько процентов фич никогда не используется. Такой статистики по проектам я не нашел, но к нам часто приходят с бесполезными проектами, которые мы тем не менее делаем. Но без коммуникации и измерений мы не можем потом сказать: «Нам кажется, что ты нам только бесполезные проекты приносишь».

Измеряйте выгоды, коммуницируйте!

Выводы

Мы прошли все 37 шагов — это оказалось не так много. И они все уместились на доске в нескольких колонках:

Я действительно люблю p3express. Мне нравится, что им просто пользоваться, что я могу пользоваться им не один, а управлять проектом вместе с командой, потому что объяснить, как это делать в p3express — достаточно просто. 

Пробуйте p3express на небольших проектах в вашей компании, пробуйте на своих pet-project, пробуйте масштабировать, раскатывать и помогать другим.

Simplicity is the ultimate sophistication!

Московская конференция TeamLead в этом году пройдет 29 и 30 апреля в Radisson Slavyanskaya. На конференции будет огромное количество информации, общения, обсуждений для тимлидов команд любых размеров и направлений. Не только для IT-сферы, не только для больших корпорация или маленьких старпапов. О том, как строить (и перестраивать) культуру в компании, как развиваться самому и помогать в этом команде, как решать конфликты для всех с профитом, про бизнес-процессы, коммуникацию, карьеру и многое другое — вы получите максимальную концентрацию тимлидского опыта на чел/час и кв.м.

Расписание конференции уже готово. Билеты уже в продаже. Можно участвовать как онлайн, так и по старинке, общаясь вживую. Присоединяйтесь!

Но если вы хотите еще и выступить, на питерскую конференцию Saint TeamLead Conf 2021 еще открыт прием докладов. Мы помогаем спикерам во всех вопросах выступления, в том числе учим выступать и как подготовить презентацию. А в Программном комитете ваши заявки просматривают и отбирают опытные спикеры, неоднократно выступавшие на разные темы и эксперты в своих направлениях. Выходите на свет рампы вместе с нами!