Продолжение моего учебного курса по проектному управлению. Предыдущие материалы:
1. Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера
2. Три фундаментальных принципа проектного управления
3. Роли в проектном управлении
4. Управление заинтересованными сторонами
5. Устав проекта - это скорлупа яйца
6. Алгоритм управления содержанием проекта
Зачем нужна концепция проекта? Когда вы собрали и описали требования (см. предыдущий шаг) - их много, и они разнокалиберные.
Порой, они даже друг другу противоречат.
Предположим, вы строите многоквартирный жилой дом. И зафиксировали в матрице требований пожелания к входным дверям от архитектора и от маркетолога. Первый просил, чтобы двери были железными. Второй настаивает на деревянных. Как поступить? Необходимо выбрать один из вариантов (это называется "калибровкой требований").
Проблема матрицы требований еще и в том, что каждый член команды, для того чтобы составить себе представление о том что именно мы делаем на проекте - как будет выглядеть результат, продукт - должен внимательно изучить всю эту матрицу, во всей ее "разнокалиберностью" (требования к фасаду и крыше может соседствовать с требованиями к дверным ручкам), противоречивостью ("нужна стеклянная дверь" и "нужна деревянная дверь" и это про одну и ту же дверь). На серьезных проекта список требований может быть очень большим, а следовательно и порог вхождения в проект для тех членов команды, кто хочет представить себе конечный результат - повышается.
Матрица требований позволяет упростить эту задачу, снизить порог вхождения. Больше всего она напоминает собой привычное во многих компаниях "ТЗ" (техническое задание). Формирует ее руководитель проекта или кто-нибудь еще (например, аналитик) или несколько человек. Отправной точкой служит все та же матрица требований (содержание которой обдумывается, балансируется, корректно описывается в виде целостного документа). В отличие от списка требований - концепцию легко читать. Пробежавшись по ней можно за 20-30 минут составить вполне целостное представление о том, что мы делаем на проекте и каким будет его результат.
Коль скоро мы говорим о сборе требований, то могу подсказать надежный способ, как нажить себе врага. Очень просто - спросите у него пожелания к результату проекта, а потом сделайте по-другому. Это на 100% будет ваш враг. Если бы вы его не спросили, то он мог бы еще вас простить, поморщиться, но все-таки простить. Но если вы спросили и сделали иначе, вы точно станете врагом номер один. Ведь на проектах очень часто встречаются ситуации, когда требования противоречат друг другу, и вам придется выбирать, какие из требований реализовать, какие - убрать. Чтобы «нейтрализовать» недовольство заинтересованных сторон, чьи требования вам пришлось проигнорировать, стоит как-минимум дать им обратную связь по этому поводу.
Могу привести конкретный пример из своей практики. Мы реализовывали проект по модернизации колл-центра в связи с его переездом на другую площадку. Предстояло полностью переоснастить колл-центр, обучить персонал, заново запустить в работу. На момент начала проекта в колл-центре работал уже сложившийся коллектив из 40 человек, почти все женщины. В ходе сбора требований по проекту были опрошены почти все работницы, поскольку они были пользователями. И каждая сотрудница высказалась, чего бы ей хотелось, все требования зафиксировали. Но когда дошло дело до написания концепции, оказалось, что многие требования противоречили друг другу. Поэтому некоторые из них пришлось выкинуть. Менеджер не сообщил об этом пользователям заранее, поэтому после сдачи-приемки, когда уже обкатывалась вся система, почти 40 женщин были недовольны результатами проекта. Они активно «ябедничали» на плохую проектную команду и писали докладные записки на имя начальства.
Недовольство можно было бы существенно смягчить, если бы работницам сразу сообщили, что их требования выполнить не получится. Если есть объективная причина, почему выполнить то или иное требование невозможно, человек вынужден будет ее принять. Но вам надо будет это правильно объяснить. Процесс работы с требованиями, когда вы соотносите противоречивые запросы, оставляете правильные, а затем даете обратную связь заинтересованным сторонам, называется калибровкой требований.
Но вернемся к концепции проекта. В ней остаются только те требования, которые могут быть реализованы в проекте. И это уже не разрозненные тезисы, а целостный текст. Но его вид и содержание может отличаться в зависимости от того, какие правила у вас приняты. Например, если вы работаете в госсекторе, то концепция, скорее всего, у вас будет сделана по каким-то ГОСТам, если предстоит военная приемка, то будет выверен каждый миллиметр поля листа и использованного шрифта, появятся определенные требования к оформлению, потому что в этой сфере все делается по заранее определенным шаблонам. В айти сфере обычно совсем простые концепции. Если, например, вы делаете небольшой сайт, то концепция будет выглядеть как книжечка с картинками (в методологии Agile это называется wireframe). Сначала будет главная страница сайта, какие-то кнопки, надписи. Картинка – окошко, опять картинка. Подобный формат позволяет легко находить общий язык аналитикам, разработчикам и пользователям. Разработчикам не нужны дополнительные разъяснения, им по этим картинкам все понятно, что предстоит делать на проекте.
Важно помнить, что концепция может быть разного размера, с картинками, схемами или другими графическими элементами – все зависит от специфики проекта.
Еще один важный момент: в концепцию входит все то же самое, что и в устав, только описывается очень подробно. Принципиально указать, что исключено из проекта: , что вы делаете в проекте, а что - не делаете. Например, дом вы строите, но придомовую территорию вы не оформляете, или не проводите сдачу госкомиссии. Все потенциально спорные вопросы как можно подробнее расписывается в концепции.
Следующий этап планирования содержания (и следующая тема) – иерархическая структура работ (ИСР).
Предыдущая часть курса: Сбор требований. Курс по управлению проектами, часть 7
Следующая часть курса: Иерархическая структура работ (ИСР). Курс по управлению проектами, часть 9
Начало курса: Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера. Курс по управлению проектами, часть 1
Если вас интересует тема "Управления проектами" и вы хотите самостоятельно подготовиться к экзамену на сертификат Project Management Professional, то приглашаем пройти новый видеокурс Ивана Селиховкина "Подготовка к экзамену РМР"
