Текст книги "Проджект-менеджмент. Как быть профессионалом"

Выводы

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

Глава 5
Содержание проекта. Требования и иерархическая структура работ проекта

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

Описание содержания продукта (Product scope description) – это текстовый документ, который последовательно (сначала на высоком уровне, а потом более детально) уточняет характеристики продукта, услуги или результата, описанного в уставе проекта.

Критерии приемки (Acceptance criteria) – четкий перечень условий, которые должны быть выполнены, чтобы результаты проекта могли быть приняты заказчиком. Это чек-лист, согласно которому заказчик будет принимать работу и проверять, насколько она соответствует его требо-ваниям.

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

Исключения из проекта (Project exclusions) – формулировка того, что именно находится вне содержания проекта. Проще говоря, это описание того, что в проект не входит.

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

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

Некоторые заказчики чувствительны к формулировке «исключения из проекта»: «Мне это нужно! В смысле – не будем делать?!» В таких случаях этот пункт можно назвать «работа, которая будет выполнена в следующем проекте / на следующем этапе проекта».

Ограничения проекта (Project constraints) – это то, в чем нас ограничивает заказчик: например, в выборе субподрядчиков или технологии. Не нужно вписывать в этот пункт ограничение по срокам и бюджету: им всегда отводится особое место.

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

С терминами разобрались, теперь перейдем к основной части.

Базовый план

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

Для чего это нужно? Жизнь всегда вносит коррективы в любой план. Например, я задумал повесить три светильника. Плановая стоимость светильников – 100 руб. за штуку, плановая стоимость работ по установке – 250 руб. Это и есть мой базовый план. Приехав в магазин, я узнаю, что вышла новая коллекция светильников, но их цена уже 110 руб. за штуку, а старой коллекции нет. В итоге я вынужден потратить на светильники 330 руб. Установка прошла по плану и стоила 250 руб. В конце проекта я сравниваю фактические расходы с базовым планом. В итоге получилось отклонение в 30 руб.

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

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

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

Базовый план по содержанию проекта состоит из требований к проекту, соответствующей иерархической структуры работ (ИСР) и ее словаря.

I. Требования к проекту

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

1. Как собирать требования к проекту?

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

Есть и другие способы сбора требований.

● Фокус-группы. Для интервью собирают 5–10 человек из тех, кто будет пользоваться разрабатываемой системой, чтобы выяснить их пожелания. Пользователей у системы может быть огромное количество, но предполагается, что мнения этих 5–10 человек совпадут с мнениями остальных.

● Семинары с участием модератора. Если заинтересованных сторон не слишком много (до 15 человек), то можно провести специальный семинар по сбору требований.

● Методы совместной разработки (Joint Application Development, Voice Of Customer, Agile). Команда быстро создает прототип или сильно упрощенную версию продукта (minimum viable product, MVP) и показывает его пользователям. Затем собираются пользовательские отзывы, которые и становятся требованиями. Такими маленькими итерациями список требований обновляется постоянно.

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

● Анкеты и опросы. Можно собирать требования при помощи анкет и опросов. Например, создавать их в Google Forms или SurveyMonkey и рассылать пользователям.

● Наблюдения. Суть в том, чтобы наблюдать, как работает человек или компания. Увиденные действия и процессы документируются для дальнейшей обработки и оптимизации.

● Бенчмаркинг. Заключается в адаптации лучших решений, применяющихся в других компаниях. Менеджер и команда изучают СМИ, отыскивая лучшие практики и решения у других компаний, а затем применяют их в своем проекте.

● Анализ существующих документов. Очень часто нужную информацию можно найти в существующей документации или переписке.

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

1. Почему мы делаем этот проект?

Этим вопросом мы уточняем бизнес-цель.

2. Какова ваша роль в проекте?

Анализируем заинтересованные стороны. Выясняем степень их влияния на проект.

3. Как итоги проекта могут повлиять на вашу карьеру или положение в компании?

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

4. Кто еще может влиять на проект, на кого он окажет сильное влияние?

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

5. Какое финансовое влияние проект окажет на компанию?

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

6. В состоянии ли существующая в компании инфраструктура поддерживать этот проект?

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

7. Каких результатов вы ждете от проекта? При каких условиях проект будет считаться завершенным?

Результаты поставки, которые заинтересованное лицо ожидает получить по завершении проекта.

8. Как вы определите успешность проекта?

Критерии приемки, с помощью которых мы сможем оценить, успешен проект или нет.

9. Когда и что должно быть готово?

Этот вопрос поможет найти существующие ограничения в расписании и сроках сдачи проекта.

После того как все пожелания заказчика задокументированы, необходимо разделить их на требования и исключения. Конечно, бывают так называемые gold-plated, или проекты «на голубой тарелочке с золотой каемочкой», в которых бюджет и сроки неограниченны. В таких проектах реализуются абсолютно все пожелания. Правда, такое бывает нечасто. В большинстве случаев у менеджера есть ограничения расписания или бюджета. Соответственно, ему нужно разделить пожелания того, что будет реализовано, – требования, и того, что в рамках этого проекта создано не будет, – исключения. В требованиях нужно оставить то, что действительно важно для достижения цели проекта и цели бизнеса, без чего бизнес остановится. Все остальное уходит в исключения. Задача руководителя проекта на данном этапе – помочь заказчику с этим делением, предоставить больше информации и разъяснить спорные моменты. Также нужно напомнить заказчику, что часть работ, необязательных для этого проекта, всегда можно внести в содержание следующего совместного проекта.

2. Как выглядят хорошие требования?

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

Пример из практики. Знакомый бизнесмен, владеющий бизнесом по разработке и внедрению CRM, заключил договор с крупной логистической компанией. В договоре очень хорошо и детально была описана CRM, а также имелась следующая формулировка: «Система должна генерировать следующие отчеты: 1. (описание), 2. (описание), 3. (описание), 4. (описание), 5. (описание), 6. (описание), 7. (описание), 8. (описание), 9. (описание), 10. (описание), и т. д.».

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

Требования должны иметь четкий критерий завершенности (definition of done). У менеджера должно быть четкое определение того, что считать выполненным. Кто-то считает, что уборка сделана, когда носки спрятаны под кровать, а для кого-то уборка – это вымытый с содой пол.

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

Требования должны быть описаны максимально четко и детально, чтобы их поняли все заинтересованные стороны. Хорошая практика – если вы работаете в IT, дать почитать их кому-нибудь из сферы, не связанной с IT. Если человек поймет, что нужно сделать, значит, работа с требованиями проведена хорошо.

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

Самое главное: требования должны быть задокументированы и согласованы со всеми ключевыми заинтересованными сторонами. Документирование – это один из лучших способов избежать разрастания содержания проекта (scope creep). В любом проекте заказчик постарается добавить новые работы, и содержание начнет разрастаться. Лучше всего я прочувствовал это на проектах, где сам выступал заказчиком.

II. Иерархическая структура работ

Иерархическая структура работ (ИСР) – это список работ, которые необходимо выполнить, чтобы успешно завершить проект. ИСР формируется на базе требований к проекту и отражает только те работы, которые нужно выполнить в ходе проекта. Если в ИСР какой-то работы нет, то она не входит в проект, а значит, делать ее не нужно.

Вот определение ИСР из PMBOK: «иерархическая декомпозиция полного содержания работ, выполняемых командой проекта для достижения целей проекта и создания требуемых поставляемых результатов».

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

1. Собрать чемодан:

● пять пар носков;

● пять трусов;

● шесть маек;

● теплый свитер;

● удобные ботинки;

● косметичка с бритвой, шампунем, зубной щеткой и т. д.

2. Собрать рюкзак:

● ноутбук;

● наушники;

● зарядное устройство для ноутбука и телефона;

● бутерброды;

● бутылка воды.

3. Собрать документы/деньги:

● паспорт;

● водительские права;

● кошелек (наличные + две карточки).

Это и есть иерархическая структура работ (ИСР) мини-проекта сборов в дорогу. Когда мы выполнили все пункты, проект готов.

ИСР – это основа планирования проекта. Если у менеджера нет четкого списка работ, то он не может посчитать, сколько будет стоить проект и сколько времени на него понадобится. ИСР помогает структурировать и определить все содержание проекта. ИСР можно создавать в формате структурированного списка, как в нашем примере, или в виде дерева (рис. 11).

При создании ИСР руководитель проекта должен декомпозировать работы до того уровня, когда он сможет управлять ими. Работы, находящиеся на нижнем уровне ИСР, называются пакетами работ. О пакете работ менеджер должен знать три вещи:

1) кто его будет выполнять;

2) сколько времени на это понадобится;

3) как проверить, что работа готова.

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

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

Рекомендованный размер пакета работ – 40 часов, так как 40-часовую работу проще контролировать. Дело в том, что если исполнитель знает, что у него на работу есть месяц, то срабатывает «синдром студента»: хочется отложить все на потом, ведь времени еще много.

В большинстве проектов используется ИСР, основанная на результатах поставки. Ее верхний уровень – это артефакты, которые необходимо передать заказчику в конце проекта. Затем менеджер разбивает результат на составные части до уровня пакетов. Рассмотрим пример.

Проект строительства дома

1. Подготовка фундамента.

2. Строительство стен.

3. Строительство крыши.

4. Прокладка электрики.

5. Подготовка сантехники.

6. Внутренняя отделка.

7. Постройка забора.

8. Обустройство участка.

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

1. Фундамент.

1.1. Подготовка котлована.

1.2. Обрешетка фундамента.

1.3. Заливка фундамента.

1.4. Заливка площадки.

И т. д.

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

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

Важно понимать, что ИСР отвечает на вопрос «Что нужно сделать в проекте?», но не отвечает на вопросы о том, в какой последовательности будут выполняться работы, сколько они будут длиться и в какую сумму обойдутся. Ответы на эти вопросы нам дают следующие шаги: оценка и расписание. Поэтому не нужно пытаться располагать работы строго в той последовательности, в которой, по вашему мнению, они будут выполняться.

ИСР – очень удобный инструмент для создания статус-отчета по проекту: выполненные работы окрашиваются в зеленый цвет, что дает наглядную картину прогресса проекта.

Кстати, еще один важный момент заключается в том, что перед созданием ИСР нужно решить, каким образом она будет храниться, поддерживаться и распространяться. Возможно, это будут стикеры на стене, некий инструмент типа Microsoft Project или Smartsheet, файл где-то в облаке с возможностью общего доступа и редактирования или другой удобный для вас вариант.

III. Словарь ИСР и для чего он нужен

Сам формат ИСР подразумевает краткость формулировок, но в процессе ее создания у менеджера возникает много вопросов, мыслей и идей. Чтобы их не потерять, можно использовать словарь ИСР. По сути, это документ, в котором менеджер оставляет заметки к конкретным задачам. В электронных инструментах работы с ИСР это могут быть специальные поля типа Notes или «Заметки».

Выводы

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

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

Работая по модели с MVP (минимально жизнеспособный продукт) и прототипом, мы много раз сталкивались с одним интересным заблуждением. MVP или прототип – это быстро созданные решения, которые слабо масштабируются. Несколько таких решений могут накладываться друг на друга, что со временем затрудняет очередное расширение функционала. Это ведет к необходимости переделывать часть программы. При этом заказчик уверен, что у него уже есть полный функционал, который работает замечательно. Менеджер должен предупреждать заказчика о подобных рисках.