Сбор требований
Собрать и финализировать требования – один из наиболее трудоемких и плохо формализуемых процессов. Все что известно сейчас – крупноуровневые требования, зафиксированные в уставе (вполне возможно, что они описаны несколькими предложениями). Наша задача конкретизировать их.
Чтобы справиться с ней – необходимо понять «кто?» является источником требований на проекте и «что?» конкретно он хочет получить по окончании работ.
Крайне опасно на данном этапе поддаться искушению «назначить» ответственным за все требования спонсора или заказчика. Кто бы ни подписал наш устав, а, в дальнейшем, и контракт на выполнение работ – он никогда не станет единоличным источником информации о требованиях.
Лучшие проектные практики гласят:
- проект с неудовлетворенными ожиданиями заказчика не является успешным
- проект, результаты которого не используются конечными пользователями, не является успешным
Помните об этих двух тезисах. Сейчас вам предстоит одна из самых изнурительных задач в проектном управлении – выявлять заинтересованных лиц и собирать требования. Это не забота заказчика, это ваша забота. Пренебрегая ей – вы рискуете в лучшем случае «закрыть контракт формально, испортив отношения с заказчиком», а в худшем – получить на исходе проекта лавину претензий и придирок, которая утопит и вас и команду и сделает сдачу невозможной.
Выявляем заинтересованных лиц
Эту работы мы начали еще в фазу инициации (определив самых основных персон)? теперь работа продолжается. Результатом ее должен стать «реестр заинтересованных лиц». Пример такого документа приведен в Приложении 2.
Даже на небольшом проекте (с бюджетом в несколько миллионов рублей и командой порядка 10 человек) такой реестр должен содержать десятки (хорошо, если сотни) фамилий.
По какому принципу мы называем того или иного человека «заинтересованным лицом»?
Во-первых, это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда).
Во-вторых, заинтересованным лицом всегда являются конечные пользователи продукта (ни в коем случае не пренебрегайте их интересами в проекте!).
В третьих, не забывайте о боссах членов вашей команды.
В четвертых, помните о тех, кто напрямую не связан с проектом, но, так или иначе, оказывает на него влияние.
Последняя группа заинтересованных лиц – наиболее трудна к выявлению, однако порой вклад таких «серых кардиналов» очень велик. В качестве примера можно привести гипотетическую ситуацию, когда сын заказчика является в его глазах авторитетом в сфере информационных технологий и привлекается отцом к принятию принципиальных решений о внедряемых системах. При этом сын не является сотрудником ни одной из участвующих в проекте организаций (или, допустим, вообще еще школьник). Однако высказанные им советы имеют для папы больший вес, чем экспертные заключения его же сотрудников. Возможно, «добраться» до такого «заинтересованного лица» в ходе проекта вам и не удастся, но, знать (или, хотя бы, предполагать его существование) – достаточно важно.
Не бойтесь включать в реестр большое количество людей. Вы всегда сможете классифицировать их по «степени влияния на проект» позднее и работать только с самыми главными. Сейчас важнее никого не забыть (ибо влияние заинтересованного лица не проекте, со временем, может и возрасти).
Готовимся к сбору требований
По мере того, как список «заинтересованных лиц» формируется – мы приступаем к сбору требований.
Введем два термина: «требование» и «ожидание».
Ожидание – «умозрительная картинка будущего». Как правило – достаточно широкая. Пример ожидания: «чтобы производительность отдела возросла после внедрения ИТ-системы»; или «чтобы внедрение проекта не сильно сказалось на работе соседнего департамента». Ожидание нельзя включить в состав проекта, не преобразовав в требование.
Требование – конкретный, измеримый, проверяемый запрос заинтересованного лица. Пример требования: «система должна позволять проходить все пользовательские сценарии без использования манипулятора «мышь»».
Нам предстоит выбрать один или несколько методов «вытягивания» из заинтересованных лиц их ожиданий и требований (разумеется, нас в меньшей степени волнует наша собственная команда, и куда больше – представители заказчика и всевозможные стоящие за ним и над ним «серые кардиналы»).
Выбирая методы, необходимо тщательно взвесить наши потребности в информации и способности второй стороны ее предоставить.
Из наиболее распространенных можно выделить:
- Интервью
- Опросники
- Мозговые штурмы (в различных вариациях)
- Прототипирование
Интервью – является одним из самых надежных методов, он же – самый трудозатратный. Непосредственное общение позволяет собрать наиболее полную и достоверную информацию, а также установить конструктивный рабочий контакт с собеседником. Главный минус – трудозатраты (вам придется тратить свое и чужое время в больших количествах). Кроме того – с некоторыми заинтересованными лицами общение может оказаться невозможным по причине их «статусности» (так, не всегда возможно уговорить топ-менеджмент компании-заказчика уделить вам часок-другой на очной встрече, даже если это в интересах проекта).
Опросники – это хороший способ быстро собрать информацию с множества людей (к тому же предоставив им вводить информацию в удобное для них время). Увы, у метода масса недостатков, главные из которых: «однобокость» собранной информации, высокая вероятность формального подхода к заполнению анкет (по принципу «чтобы отстали»).
Мозговой штурм – весьма условно можно назвать «коллективным интервью». Проведенный по определенным правилам, мозговой штурм может оказаться крайне эффективным. Однако помните, что некоторым людям трудно общаться даже в небольших коллективах – чтобы они не «отмалчивались» и не стеснялись в высказываниях, развивайте навыки ведения подобных мероприятий.
Прототипирование – это прекрасный способ собрать или уточнить требования. Под прототипом мы можем понимать любой понятный вашему собеседнику образ продукта (будь то картинка, макет или какой-либо аналог). Прототипирование удобно сочетать с другими техниками (например, интервью); главное не ограничиваться только им, дабы не упустить существенные моменты, не реализованные в прототипе, но важные для продукта.
Собираем требования
К сбору требований мы приступаем, определившись с методами и вооружившись реестром заинтересованных лиц.
Сбор требований ПМ ведет не в одиночку, а совместно с командой. Собственно команда окончательно будет сформирована чуть позже, но на данном этапе нам уже пригодятся помощники (надеюсь, вы добавили соответствующую запись в устав и заблаговременно предупредили «хозяина ресурсов» о ваших потребностях).
Если в вашей компании есть специалисты по сбору и описанию требований (например, аналитики), тогда львиную долю забот в этой области можно переложить на них. Это очень неплохой сценарий, ибо требования являются самой сложной и трудоемкой для описания «гранью треугольника».
Однако, даже делегируя свои хлопоты – не выключайтесь из процесса и помните, что каждый день кто-то из членов команды (не обязательно аналитик) сталкивается с пожеланиями заинтересованных лиц, которые не были учтены раньше. Организуйте работу так, чтобы каждый ваш сотрудник в любой момент имел доступ к перечню выявленных требований – мог бы его просмотреть и дополнить.
Прежде чем отправиться к заинтересованным лицам (или отправить туда коллектив аналитиков) – определитесь, как будут храниться собранные требования. Совершенно не обязательно после каждого интервью или мозгового штурма рисовать схемы в определенной нотации. Если вы считаете, что достаточно будет текстовых описаний и произвольных картинок «от руки» – возможно, вы правы. Главное, договоритесь заранее, как будете фиксировать собранные требования со всеми участниками процесса.
После того, как процесс запущен, и требования стали поступать – не забывайте фиксировать их. Возможно, у вас на столе начинает расти пачка «организационных диаграмм», или электронная почта ежедневно пополняется подробными «отчетами об обследовании» и «отчетами об интервью». Все они окажутся весьма полезны в дальнейшем – при выполнении работ, при необходимости уточнить задачу.
Однако вам, как проектному менеджеру , важно сохранить контроль над процессом в целом, иметь возможность планировать и отслеживать выполнение работ для всего многообразия пожеланий заказчика. Для этого рекомендуется обзавестись выделенным списком, называть его можно «матрицей требований». Пример такого документа приведен в Приложении3.
Матрица позволяет фиксировать – когда обнаружено требование, кто автор (кто высказал), насколько данное требование важно (приоритетно). Также в матрицу целесообразно добавлять информацию о том, было ли требование выполнено в ходе реализации проекта, и не отменил ли его сам автор.
Обратите внимание – осуществляя сбор требований и заполняя матрицу, мы не пытаемся с ходу принять решение, «беремся ли мы за их реализацию в данном проекте, или нет». Проще говоря – собираем «все, что есть» (в рамках разумного, конечно). На этом этапе заинтересованным лицам не дается никаких обещаний. Мы лишь собираем их требования и ожидания (последние также превращая в требования с помощью авторов). И по мере того, как сбор требований завершается – приступаем к их «балансировке» (т.е. оценке того, что войдет в проект).
Когда остановиться? Проектные практики призывают нас собрать все требования, которые могут относиться к нашему проекту и только после этого двигаться дальше. Помните – «что нельзя спланировать, то нельзя и сделать».
Многие методологии разработки ПО обосновано считают строгую последовательность «спланировал» – «сделал» – «показал» – «сдал» (без демонстрации промежуточных результатов заинтересованным лицам и регулярной корректировки исходных планов) злом, повышающим риски провала.
Сбор требований в рамках начального планирования должен быть разумно-глубоким и максимально широким. Однако речь не идет о том, что на этом работа с требованиями должна прекратиться, а их список оказаться «фиксирован» до конца проекта. Работа с ожиданиями заказчика, накопление его согласия, корректировка планов в течение всего жизненного цикла проекта – основа проектного управления.
Иногда процесс первоначального сбора требований оказывается столько трудоемким и растянутым во времени, что целесообразно выделить его в отдельный проект. Если предполагаете большие трудозатраты – обсудите это со спонсором как можно раньше.
Балансировка требований
Балансировка требований – отбор требований, реализация которых предполагается в рамках проекта.
Процесс балансировки основан на сочетании интуиции и здравого смысла. Сперва, мы приоритезируем требования (выделяя наиболее значимые), а затем отбираем к реализации те из них, которые возможно уложить в рамки проектных ограничений (стоит помнить, что некоторые требования могут оказаться взаимосвязаны и включать или исключать их из треугольника можно только вместе).
На данном этапе мы обладаем лишь предварительными (грубыми) оценками стоимости и сроков проекта и пока не знаем точно, сколько «будут стоить» и длиться выбранные нами работы. В своих текущих оценках мы полагаемся на профессиональный опыт и чутье (свое и команды).
Позже, когда себестоимость и продолжительность работ будет оценена, мы сможем вернуться к этой части плана и скорректировать ее (возможно, от каких-то требований придется отказаться или пересмотреть). Однако важно понимать – процесс балансировки требований не должен противоречить уставу проекта. Если в уставе, скажем, прописано как одно из главных требований к продукту – скорость реакции интерфейса не более чем за 0,5 секунды, то мы не можем выбросить подобное требование из реестра (его невыполнение похоронит проект).
Технически балансировка может представлять простановку соответствующих отметок в матрице требований. Результаты сбора и балансировки можно утвердить у заинтересованных лиц проекта. Продумайте заранее – собираетесь ли вы получать подтверждение, в какой форме.
Обратите внимание еще на такой аспект: в нашем проекте мы не используем термин «техническое задание» (ТЗ)
Де-факто, матрица требований (а также схемы и описания, на которые она ссылается) как раз и представляет собой техническое задание. Однако на практике ТЗ – это статичный документ, который является неотъемлемой частью некоторых видов контрактов.
Именно статичность технического задания делает его неудобным для всех заинтересованных лиц проекта. Правильно организовав работу с требованиями, мы снижаем риск «промахнуться мимо ожиданий заказчика» (одновременно и прислушиваясь к ним весь проект, и отсекая невыполнимые). ТЗ может оказать обратный эффект.
Если вы все же столкнулись с необходимостью разработать ТЗ (или привлечены к его разработке) – адаптируйте информацию матрицы требований и позаботьтесь о том, чтобы в документе появились подробные описания процедуры уточнения требований (особенно формальной ее стороны). Приведем один из примеров подобных процедур: «Список используемых в системе справочников и классификаторов приведен в приложении №101. Данный список может изменяться в сторону его увеличения или сокращения, но не более чем на 10 позиций. При необходимости внести изменения в список справочников, заказчик уведомляет о такой необходимости исполнителя не позднее, чем до 1 декабря 2010 года и предоставляет описание… По результатам поведенного исполнителем анализа составляется акт на основе шаблона в приложении №102.»
