Не усложняй! Управление проектами по методу P3.express - Дмитрий Аркадьевич Ильенков

Классический пример проекта, где была допущена эта ошибка – строительство международного аэропорта Денвер. Команда не протестировала инновационную систему обработки багажа в реальных условиях. Это привело к многочисленным проблемам: тележек и буксировщиков оказалось недостаточно, возникали заторы, которые приводили к повреждению и потере багажа[36]. В итоге проект завершился с опозданием на 16 месяцев и превышением бюджета на два миллиарда долларов. А спустя 10 лет от непротестированной вовремя системы отказались полностью.

ЧТОБЫ НЕ ВСТРЕЧАТЬ ДЕДЛАЙН С ПУСТЫМИ РУКАМИ И НЕ ПОПАДАТЬ В УЧЕБНИКИ КАК ПРИМЕР ЭПИЧНОГО ПРОВАЛА, КАЖДЫЙ РАЗ, КОГДА У ВАС В ПРОЕКТЕ ЧТО-ТО ГОТОВО, ПРОВЕРЯЙТЕ РЕЗУЛЬТАТ.

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

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

ЛАЙФХАК: ЧТОБЫ ПРОЩЕ БЫЛО СОГЛАСОВЫВАТЬ ГОТОВУЮ РАБОТУ, ПРОПИСЫВАЙТЕ КРИТЕРИИ ПРИЕМКИ ДЛЯ ЗАДАЧИ ЕЩЕ ВО ВРЕМЯ ЕЕ ПОСТАНОВКИ.

На шаге B01 – «Обновить и детализировать планы» задайте вопрос команде: а как мы убедимся, что задача выполнена? И добавьте к описанию чек-лист, по которому можно будет проверить готовность.

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

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

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

Рисунок 22. Пример карточки результата с описанием критериев приемки и этапов работы

Есть еще один веский довод не затягивать с приемкой. Мультизадачность часто встречается и в вакансиях, и в резюме, но, по данным исследований, хорошо с ней справляются только 2 % людей[37], а остальные здорово теряют в продуктивности.

СОКРАЩАЙТЕ КОЛИЧЕСТВО ЗАДАЧ, КОТОРЫЕ КОМАНДА ВЫПОЛНЯЕТ ПАРАЛЛЕЛЬНО – ПРИНИМАЙТЕ ГОТОВУЮ РАБОТУ СРАЗУ.

Ну и наконец: как же приятно видеть в таск-трекере статусы «Готово». Не так ли? Тоже хороший повод сначала закончить текущую задачу, прежде чем взять следующую.

Раздел 7. Закрытие цикла

На протяжении почти ста лет британская сборная по велогонкам не блистала результатами. Все было настолько плохо, что один из производителей даже отказался продавать команде велосипеды: не хотел позориться! Так продолжалось до тех пор, пока в 2003 году у сборной не поменялся тренер.

Уже в 2004 году Великобритания выиграла на Олимпиаде две медали, в 2008 – восемь, а в 2012 установила девять мировых рекордов и семь олимпийских. А человек, изменивший ход истории велогонок, тренер Дэвид Джон Брейлсфорд, в 2014 году был произведен в рыцари ее Величества и получил к своему имени приставку сэр. В чем же был его секрет?

Процитирую:

«Весь принцип основан на идее, что, если разбить на составляющие все, что можно придумать в отношении езды на велосипеде, а затем улучшить каждую из них на 1 %, то в совокупности получится значительное улучшение»[38].

К делу отнеслись серьезно и совершенствовали буквально все: от велосипедных сидений до способа мытья рук. Даже установили, на каких подушках должны спать спортсмены. Звучит скучно, но эта методичная работа вывела команду-аутсайдера на вершину.

Мне очень нравится эта концепция, получившая название «накопление минимальных улучшений» – она применима и в управлении проектами.

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

Чтобы накапливать улучшения и не совершать одни и те же ошибки снова и снова, P3.express предусматривает этап «Закрытие цикла». Он состоит из трех шагов, которые позволяют сделать паузу для анализа проделанной работы и подумать, что стоит изменить в следующем цикле. Этап включает в себя сбор обратной связи от стейкхолдеров, извлечение уроков и коммуникацию результатов, достигнутых в цикле.

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

E01 – оценить удовлетворенность стейкхолдеров

ОТПРАВЬТЕ ОПРОСНИК ЧЛЕНАМ КОМАНДЫ, ЗАКАЗЧИКУ, ПОДРЯДЧИКАМ И ДРУГИМ ВНЕШНИМ СТЕЙКХОЛДЕРАМ, ЧТОБЫ ОЦЕНИТЬ ИХ УДОВЛЕТВОРЕННОСТЬ ПРОЕКТОМ В ПРОШЕДШЕМ МЕСЯЦЕ.

Руководство P3.express

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

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

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

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

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