Продолжение моего учебного курса по проектному управлению. Предыдущие материалы:
1. Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера
2. Три фундаментальных принципа проектного управления
3. Роли в проектном управлении
4. Управление заинтересованными сторонами
5. Устав проекта - это скорлупа яйца
6. Алгоритм управления содержанием проекта
1. Откуда брать требования?
Первый вопрос – откуда брать требования – сравнительно простой. Представьте: вам надо собрать требования для проекта. Откуда вы узнаете, что надо делать? В первую очередь, информацию вы получаете от заказчика и от пользователей (если это возможно). Кроме того, есть нормативные документы – законы, ГОСТы, СНиПы, из которых тоже можно брать требования.
Еще один источник – исполнители, ваша команда. Представьте, клиент попросил дом со стеклянной крышей. Но он не эксперт, поэтому не может объяснить, как именно стеклянную крышу можно построить. Для этого в команде есть архитектор – специалист, который подскажет, что именно надо сделать в такой ситуации. Например, получить какую-то дополнительную лицензию или подготовить какие-то особые материалы. То есть технические требования может сформулировать только команда. У вас могут быть внешние эксперты, но ключевую роль играет все-таки команда.
2. Как собирать требования? Какие есть способы для этого?
Техник на самом деле много, и у каждой есть свои плюсы и минусы.
Совещание/интервью
Этот способ предполагает, что вы придете и лично поговорите с заказчиком. Этот способ, несомненно, лучший и наиболее эффективный, но у него есть большой минус – он очень дорогой. Во-первых, потому что это очень долго. Во-вторых, пока сотрудник разговаривает с заказчиком, исполнителями, другими заинтересованными сторонами, ничего другого он делать не может. Кроме того, как показывает практика, не все могут проводить интервью, не все могут в разговоре с заказчиком или пользователем и задавать адекватные и наводящие вопросы, точно услышать ответ, не затягивать время, но при этом выяснить все необходимое. И зачастую бывает мало смысла в интервью, если отправить его проводить неподходящего человека.
Бизнес-аналитик - одна из ролей (и возможных специализаций на проекте), которая прекрасно справляется с интервью. У них одна из задач – сбор требований, их обдумывание и формулирование, а затем представление всей команде. Если в вашей команде есть подготовленный бизнес-аналитик - это хорошо.
Еще один недостаток интервью – много их не проведешь. В день можно успеть побеседовать примерно с 3-4 людьми, потому что на каждое интервью необходимо примерно 1,5-2 часа. Кроме того, надо не только беседовать, но и записывать все требования, приводить их в вид, который будет понимать команда проекта. Больше 5 интервью в день провести крайне сложно.
Анкетирование
Плюсы этого метода в том, что можно массово задать вопросы, получить на них ответы, обработать - и все, можно использовать. Анкетирование оказывается заметно дешевле интервьюирования. Но и тут есть проблемы – анкету надо уметь писать, и она не везде подходит в принципе, поскольку нельзя задавать все подряд вопросы, анкета не интерактивная - не умеет подстраиваться под конкретного собеседника. Кроме того, результаты анкеты бывает очень неточными.
Могу привести конкретный пример из жизни. В рамках одного крупного проекта была поставлена задача установить оборудование во всех медицинских учреждениях г. Санкт-Петербурга. Надо было выяснить, если ли в каждой клинике сеть – интернет или ЕМТС (особая ведомственная сеть в СПб), есть ли там компьютер, и прочие технические моменты. Проблема в том, что в объектов было 500 штук. Физически обойти всех невозможно, и интервью, как техника сбора требований, не подходит. Поэтому решили писать анкеты.
Приготовили, как сначала показалось, хорошую анкету с 5-6 вопросами типа: есть ли у вас сеть – интернет или емтс, есть ли компьютер и т.д. И в конце указан электронный адрес, на который надо ответить. Эту анкету вместе с распоряжением городского комитета по здравоохранению Ответить в определенный срок” рассылают по клиникам.
Полученные ответы команду расстроили. Главная ошибка была в формулировках анкеты - люди отвечали именно так, как их спросили. Нужно было выяснить "какая именно сеть используется для подключения", а спросили "подключен компьютер к Интернет или ЕМТС". Ответом было, разумеется, "да". И больше никаких подробностей. А переспросить – нет возможности.Вторая проблема, с которой столкнулись, – в анкетах оказалось много недостоверной информации. Например, приехали в поликлинику, чтобы установить оборудование. В анкете они написали, что у них есть компьютер, а по факту его не было. Точнее, он был, но в бухгалтерии, совмещенной с регистратурой. В том отделе, где надо было устанавливать оборудование, компьютера не оказалось.
Неточность ответов была связана и с тем, кто отвечал на вопросы. Сначала опросник вместе с распоряжением городского комитета попадал к главврачу. Тот читал его и решал, что это надо отправить в регистратуру. А в регистратуре сидят немолодые женщины, которые оказываются перед дилеммой: с одной стороны, они не очень понимают технических вопросов, с другой - им нельзя не ответить на анкету, потому что она пришла за подписью главврача. Поэтому они понимают, как понимают, и не всегда отвечают по существу.
Другая проблема может возникнуть при обработке анкет. Не всегда поступившие ответы удается корректно обработать. Особенно, если вы разрешаете писать развернутые ответы. Готовьтесь: ответы могут быть настолько пестрыми, что объединить их воедино и сформулировать общие требования может не получиться.
Но, безусловно, плюс такого способа сбора требований в том, что он бесплатный и массовый. Если вы наловчитесь писать анкеты, составлять вопросы, и сумеете организовать закрытый опрос (у тех людей, от кого вы просите ответы), то анкета – хороший способ, хотя немного и ограниченный.
Изучение аналогов
Представьте, что заказчик не специалист в той области, в которой проект выполняется. И ему иногда даже сложно сформулировать, что именно он хочет. Например, ему нужен новый сайт, но какой именно - он пока затрудняется ответить. Поэтому ему можно предложить изучить сайт конкурентов. Вы вместе рассматриваете каждый элемент – дизайн, функциональность, какие-то сервисы и спрашиваете у заказчика, что ему нравится, а что он бы хотел изменить. Как раз в этот момент заказчик способен высказать свои требования, которые остается только фиксировать. Так что изучение аналогов - это хороший добротный способ, который можно использовать одновременно, например, с интервью.
Benchmarking (бенчмаркинг) – заимствование чужого
Похожая на изучение аналогов техника, но со своими особенностями. Допустим, мы хотим сделать томограф. Требования к нему можно взять у конкурентов. Например, томографы выпускает еще фирма Siemens, и они хорошо продаются. Можно подсмотреть, какое у этого оборудования энергопотребление, какая масса, какая функциональность. Для сбора требований benchmarking очень хорош.
Это не значит, что вы воруете что-то у конкурентов, может быть, вы заимствуете какой-то опыт у соседнего подразделения, где уже делали похожий проект.
Мозговой штурм (групповые методы решения)
Этот способ очень хороший, но и у него есть сложности. Главная проблема – сложность общения с группой. Представьте, я задаю вопрос, вы молчите, а кто-то говорит и говорит. Более тихим людям не представляется никакой возможности вставить хоть слово, не перебивая говорливого коллегу. Хорошо, что он говорит, но когда вы собираете требования, вам очень важно выяснить правду, а не просто поговорить.
Еще одна проблема: чтобы группа хорошо работала, когда вы проводите мозговой штурм, нужно помнить про одно золотое правило – не критиковать. А раз нельзя критиковать, начинают говорить те, кто легко говорит, и молчат те, кто легко молчит. И обычно первые – это менеджеры и люди, занимающиеся продажами, а вторые – которые молчат – инженеры. А вам надо услышать всех, да еще потом найти правду.
Отсюда рождается множество техник, которые позволяют работать в группах. Одна из таких техник – facilitated workshop – «семинар, которому оказывают содействие». Такой семинар ведут 2 человека. Один – писатель (scriber), а другой – тот, кто общается с группой (facilitator). Во время работы в группе facilitator смотрит только в группу и руководит процессами в ней. Допустим, начали обсуждать требования к высотности будущего дома. Один начинает говорить, другой молчит, а надо, чтобы участвовали все. И критиковать нельзя. Поэтому facilitator предлагает человеку, который говорит много, высказать еще 1 идею, а затем помолчать 5 минут, чтобы дать возможность высказаться другим участникам. Затем он выискивает тех, кто еще не озвучил ни одной идеи и просит его высказаться. По сути, всё общение контролирует facilitator. Его задача – смотреть в группу, вовлекать в работу всех, чтобы все что-то могли предложить.
Второй человек – scriber. Он стоит в стороне, в группу не смотрит, но все записывает. И его задача – не упустить ни одну мысль. Этих двух людей специально разделяют, чтобы каждый мог выполнять свою задачу.
Когда обе задачи выполняет один и тот же человек - это оказывается куда менее удобно. Если вам надо будет и работать с группой, и записывать все идеи, то либо вы не соберете все требования, либо часть из них потеряется. Технически это просто делается: один доброволец ведет чат, где все записывается, а менеджер непосредственно общается с группой.
Фокус-группы
Один из случаев, когда хорошо подходит этот способ - когда на проекте нет заказчика, когда не у кого спросить. Например, компания Гугл делает обновление сервиса Гугл-карты. Ее никто не просил, она сама решила сделать, чтобы люди пользовались. Нет заказчика в явном виде. Никто со стороны не заплатит за эту разработку. Поэтому не у кого спросить о пожеланиях. В таком случае подходит фокус-группа. Она будет вместо заказчика.
Допустим, вы решили создать томограф. Фокус-групп здесь несколько. Во-первых, главврачи. Они хотят, чтобы томографы были компактными и не тяжелыми, чтобы их можно было перемещать с этажа на этаж. Также их интересует энергопотребление: эксплуатация томографов не должна обходиться слишком дорого. Во-вторых, фокус-группа из врачей, которые будут пользоваться томографами. Они просят определенный интерфейс, наличие 3D моделирования или поддержку системы медицинских решений (системы подсказок). Есть еще одна фокус-группа – пациенты. Не все конечно, а те, кто уже видел и знает, что такое томограф и как он работает. Для них главными требованиями могут быть тихая работа, прозрачные стенки, чтобы не было страшно, какие-то другие требования. По сути все эти три группы заменяют нам заказчика. У них и уточняем, что нужно. После этого строим томограф.
Но и у этого метода есть сложности. Бывает, собираете требования, опрашиваете, но общую картину создать не получается. Одни говорят одно, другое – другое. Поэтому фокус-группы не всегда могут заменить реального заказчика.
Наблюдения
Сразу пример из жизни. Есть проект – надо внедрить в поликлиниках для взрослых аппаратные программы для записи человека на прием в электронном виде. Что надо сделать? Надо пойти в поликлинику и собрать у пользователей системы требования. Вы приходите в регистратуру, объясняете, зачем пришли, рассказываете про проект, интересуетесь, как строится работа.
В регистратуре готовы сотрудничать, но работники находятся на уровне неосознанного знания.
Неосознанное знание - это когда человек что-то может сделать, но не может объяснить, как он это делает. В ходе освоения того или иного знания люди обычно проходят 4 этапа:
Неосознанное незнание (понятия не имею) -> Осознанное незнание (нашел интерес) -> Осознанное знание (изучил) -> Неосознанное знание (применяю)
Почти все эксперты в какой-то момент переходят в это состояние. Например, хирург. Он делает операцию, но не может объяснить, что и как делает. Мозг не включается, он автоматически это делает. То же самое с галстуком: руки помнят, как его завязывать, а голова – нет.
Такая же проблема у работников регистратуры: они пытаются рассказать про все этапы работы, но не могут все объяснить. По их словам, всегда происходит одно и то же: приходит пациент, просовывает в окошко паспорт, полис и СНИЛС, ему выдают карточку и все. И больше никогда ничего не происходит.
Тогда было решено воспользоваться методом наблюдения. Надо просто посмотреть, как все происходит, и, может быть, заметить что-то важное для себя, чтобы потом система работала идеально. Во время наблюдения выясняется, что многие нюансы были упущены.
Например, приходит в поликлинику ребенок: ему по возрасту уже надо перейти в другое медучреждение. В таком случае система переключается: у него забирают старую карточку, выдают новую, много других моментов происходит, важных для системы. Другая ситуация – приходит военнослужащий или моряк. У них есть ведомственная медицина, но прививку они могут сделать и в обычной поликлинике. Но у этих пациентов нет паспортов, у первого – военный билет, а у второго – паспорт моряка. Для системы это совсем другие документы и другие параметры. Система скажет, что вы ошиблись с документом, если в поля, предназначенные для регистрации человека с обычным паспортом, занести данные из военного билета. Вот такие моменты, то что человек забыл рассказать, вы можете наблюдать.
Какие есть минусы у наблюдения? Это, конечно, дорого, как и интервью, и не всякий человек может этим заниматься. Во-первых, надо на весь процесс именно смотреть, надо быть сфокусированным, чтобы заметить, что что-то пошло не так. Например, работник регистратуры все карточки складывает в ниши, а одну в тумбочку положил. Почему он так сделал? Надо обязательно спросить. Может, это делается для того, чтобы человек мог попасть завтра на повторный прием. Но надо еще догадаться, что это важное событие, и нужен опыт, чтобы это понять.
Еще одна проблема: вам может не повезти с наблюдением. Описанное наблюдение проводилось в четверг. А потом выяснилось, что по средам в ней проводится еще грудничковый день. И там все по-другому, но команда об этом не знала.
Кроме того, не везде такой вариант, как наблюдение, годится. Ведь врачи тоже имеют возможность записать человека на прием повторно – без участия регистратуры. Но мы не можем зайти, например, в кабинет хирурга, посмотреть, как он осматривает пациентов, чтобы понять, в каких случаях он сам записывает на повторный прием, а когда отправляет на запись в регистратуру.
Анализ документации
Это литература, статьи, нормативные акты, если есть зарегулированные вещи. Здесь все и так понятно. Перед анализом документации важно оценить ее релевантность - то есть соответствует ли она действительности.
Диаграммы
Это дополнительный способ к интервью и другим методам. Это когда вы что-то услышали, что можно не только записать, но и зарисовать схематично. Потому что картинки человеком лучше воспринимаются, чем буквы.
3. Как фиксировать? (матрица требований)
Инструментов для этих целей очень много. Вы можете фиксировать требования, как хотите и как вам удобнее: на бумаге, на доске, на флипчарте. Главное – ничего не потерять. Потому что требования очень многообразные. Допустим, строим многоэтажный дом: требования могут быть к этажности, к материалам, из которого строится здание, к дверям, к отделке и т.д. И вам надо обязательно записывать и большие, и мелкие требования, чтобы ничего не упустить.
PMI «на случай атомной войны», когда нет никаких других идей, предлагает все требования собирать в табличку, реестр, матрицу. Такая матрица требований может содержать несколько столбцов, основные из которых описывают:
- наименование требования, например, требование к строительным материалам;
- ФИО и контакты человека, который просил сделать это;
- информацию о человеке, который зафиксировал требование (для уточнения);
- вспомогательная информация, например, дата выявления требования, чтобы проверить, не устарело ли оно.
Можно добавлять и другие поля на свой вкус.
Есть такой термин «ожидание». Это близкое, но не тождественное понятие с термином «требование». Речь идет о невнятных требованиях. Например, вам заказчик говорит, что хочет дом определенной этажности из конкретных материалов. А потом добавляет, что нужна хорошая детская площадка. А хорошая – это какая? С песочницей? С кустами и клумбами? Или какие-то другие требования?
Каждый раз, когда вы видите невнятное требование, надо переводить его во внятное. Надо написать 3-4 внятных требования, чтобы команда могла работать. Какая это, хорошая площадка, что в ней есть? И заказчик рассказывает: например, скамейки, клумба, песочница.
Некоторым может показаться, что лучше оставить невнятные требования, и сделать все интуитивно. Но не факт, что это сработает. И в большинстве случаев это ловушка для менеджера. Руководитель проекта сделал все по своему усмотрению, но оно не совпало с предположениями заказчика, и он не готов принять результат. Поэтому лучше прояснять все требования, и сделать реалистичный план. Иначе вы можете сильно осложнить приёмку проекта.
Вообще, матрица требований – это самая первая вещь, с которой работает менеджер. В нее вписывают все требования, а потом разбирают. Матрица - это внутренний документ, показывать ее заказчикам необязательно. Это планы для команды, чтобы люди знали, как и что делать на проекте. И подписывать у заказчика необязательно. Но по желанию, если вы понимаете, что это будет полезно, и требования, и концепцию можно согласовать с заказчиком.
Предыдущая часть курса: Алгоритм управления содержанием проекта. Курс по управлению проектами, часть 6
Следующая часть курса: Создание концепции проекта (project scope statement). Курс по управлению проектами, часть 8
Начало курса: Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера. Курс по управлению проектами, часть 1
Если вас интересует тема "Управления проектами" и вы хотите самостоятельно подготовиться к экзамену на сертификат Project Management Professional, то приглашаем пройти новый видеокурс Ивана Селиховкина "Подготовка к экзамену РМР"
