Цитаты из книг автора «Сергей Дерцап»

Бывает ИСР, основанная на этапах проекта, когда первый уровень представляет собой фазы проекта. Например, подготовка и согласование технического задания, планирование, исполнение и тестирование. В крупных проектах с участием многих подрядчиков ИСР может базироваться на подрядчиках проекта. Например, компания 1, компания 2, компания 3 и список работ, который выполняет каждая из них. Повторюсь, в подавляющем большинстве проектов ИСР основывается на результатах поставки. Популярный вопрос: когда нужно строить ИСР? Ответ зависит от того, на каком этапе к менеджеру попал проект. Если на этапе тендера, то менеджер сначала строит высокоуровневую ИСР (с грубой оценкой) для подготовки тендерного предложения. Если компания выиграла тендер и готовит договор с соответствующим техническим заданием, то ИСР должна быть более детальной. И если проект уже стартовал и его устав готов, то ИСР должна быть полной и детализированной до уровня пакетов работ. Важно понимать, что ИСР отвечает на вопрос «Что нужно сделать в проекте?», но не отвечает на вопросы о том, в какой последовательности будут выполняться работы, сколько они будут длиться и в какую сумму обойдутся. Ответы на эти вопросы нам дают следующие шаги: оценка и расписание. Поэтому не нужно пытаться располагать работы строго в той последовательности, в которой, по вашему мнению, они будут выполняться. ИСР — очень удобный инструмент для создания статус-отчета по проекту: выполненные работы окрашиваются в зеленый цвет, что дает наглядную картину прогресса проекта. Кстати, еще один важный момент заключается в том, что перед созданием ИСР нужно решить, каким образом она будет храниться, поддерживаться и распространяться. Возможно, это будут стикеры на стене, некий инструмент типа Microsoft Project или Smartsheet, файл где-то в облаке с возможностью общего доступа и редактирования или другой удобный для вас вариант.

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

Требования должны иметь четкий критерий завершенности (definition of done). У менеджера должно быть четкое определение того, что считать выполненным. Кто-то считает, что уборка сделана, когда носки спрятаны под кровать, а для кого-то уборка — это вымытый с содой пол. Хорошие требования — это полные требования. Менеджер обязан собрать их у всех заинтересованных сторон. В самом начале важно не упустить людей, влияющих на проект, и их требования, в противном случае они будут блокировать сдачу проекта. Требования должны быть описаны максимально четко и детально, чтобы их поняли все заинтересованные стороны. Хорошая практика — если вы работаете в IT, дать почитать их кому-нибудь из сферы, не связанной с IT. Если человек поймет, что нужно сделать, значит, работа с требованиями проведена хорошо. Картинка в большинстве случаев говорит лучше слов. Мокап интерфейса — набросок того, как будут располагаться элементы на экране, — всегда лучше фразы «интуитивно понятный интерфейс». Используйте в требованиях как можно больше картинок или прототипов. Самое главное: требования должны быть задокументированы и согласованы со всеми ключевыми заинтересованными сторонами. Документирование — это один из лучших способов избежать разрастания содержания проекта (scope creep). В любом проекте заказчик постарается добавить новые работы, и содержание начнет разрастаться. Лучше всего я прочувствовал это на проектах, где сам выступал заказчиком.

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

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

Есть и другие способы сбора требований. Фокус-группы. Для интервью собирают 5–10 человек из тех, кто будет пользоваться разрабатываемой системой, чтобы выяснить их пожелания. Пользователей у системы может быть огромное количество, но предполагается, что мнения этих 5–10 человек совпадут с мнениями остальных. Семинары с участием модератора. Если заинтересованных сторон не слишком много (до 15 человек), то можно провести специальный семинар по сбору требований. Методы совместной разработки (Joint Application Development, Voice Of Customer, Agile). Команда быстро создает прототип или сильно упрощенную версию продукта (minimum viable product, MVP) и показывает его пользователям. Затем собираются пользовательские отзывы, которые и становятся требованиями. Такими маленькими итерациями список требований обновляется постоянно. Прототипы. Создание чего-то похожего на итоговый результат и демонстрация заказчику. Цель — получить отзыв и понять правильность выбранного направления движения. Обычно прототипирование применяется в тех случаях, когда заказчик сам до конца не понимает, чего именно хочет. Анкеты и опросы. Можно собирать требования при помощи анкет и опросов. Например, создавать их в Google Forms или SurveyMonkey и рассылать пользователям. Наблюдения. Суть в том, чтобы наблюдать, как работает человек или компания. Увиденные действия и процессы документируются для дальнейшей обработки и оптимизации. Бенчмаркинг. Заключается в адаптации лучших решений, применяющихся в других компаниях. Менеджер и команда изучают СМИ, отыскивая лучшие практики и решения у других компаний, а затем применяют их в своем проекте. Анализ существующих документов. Очень часто нужную информацию можно найти в существующей документации или переписке.

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

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

В первоначальной версии проекта такой функционал не был предусмотрен. В такой ситуации менеджеру лучше сразу же прописать в исключениях, что сайт в рамках конкретно этого проекта разрабатываться не будет. Возможно, эта работа войдет в содержание одного из следующих проектов, но не этого. Почему? Порой возникают случаи, когда все забывают о таком разговоре. Все, кроме директора по маркетингу. И вот уже несколько месяцев идет проект, но тут директор по маркетингу решает узнать, как продвигается разработка сайта. Он обращается к непосредственному руководителю менеджера: мол, помните, мы обсуждали такую-то идею? Как там дела обстоят? Руководитель вспоминает, что действительно был такой разговор, и идет к менеджеру. И вот здесь менеджеру хорошо бы иметь документ, в котором будет написано, что сайт — это другой проект. В противном случае конфликта не избежать. Некоторые заказчики чувствительны к формулировке «исключения из проекта»: «Мне это нужно! В смысле — не будем делать?!» В таких случаях этот пункт можно назвать «работа, которая будет выполнена в следующем проекте / на следующем этапе проекта». Ограничения проекта (Project constraints) — это то, в чем нас ограничивает заказчик: например, в выборе субподрядчиков или технологии. Не нужно вписывать в этот пункт ограничение по срокам и бюджету: им всегда отводится особое место. Допущения проекта (Project assumptions) — факторы в рамках процесса планирования, которые считаются верными без предоставления доказательств и демонстраций. Здесь же описывается влияние этих факторов на проект. Это предположения, с которыми согласны и вы, и спонсор проекта. Без этих предположений дальнейшее планирование проекта невозможно. В случае, если допущение не срабатывает, проект обычно требует изменения подхода и серьезного перепланирования. Например, если мы предполагали, что существующая инфраструктура в состоянии поддержать работу нового программного обеспечения, но это оказалось не так — придется или покупать новый сервер, или вносить в систему существенные изменения, которые позволят ей работать на старом железе. Возможно, вообще понадобится написать новую систему, используя другую технологию.

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