Управление ИТ-проектом.
Эффективная система «с нуля» в любой организации

Селиховкин Иван
Санкт-Петербург – 2010

Назад Содержание Вперёд

Глава VI. Планируем содержание

Входы:

• устав проекта
• состав «плана управления проектом»

Что такое «содержание проекта»?

Содержание проекта – описание работ, которые необходимо выполнить, чтобы получить продукт.

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

На языке нашей методологии данные шаги звучат следующим образом:

1. Собрать и финализировать требования
2. Сформировать концепцию
3. Создать ИСР (WBS)

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

Первый шаг (собрать и финализировать требования) неявно включает в себя два компонента: выявление заинтересованных лиц и собственно сбор требований. Об этом подробнее мы поговорим ниже.

Сбор требований

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

Чтобы справиться с ней – необходимо понять «кто?» является источником требований на проекте и «что?» конкретно он хочет получить по окончании работ.

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

Лучшие проектные практики гласят:

• проект с неудовлетворенными ожиданиями заказчика не является успешным
• проект, результаты которого не используются конечными пользователями, не является успешным

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

Выявляем заинтересованных лиц

Эту работы мы начали еще в фазу инициации (определив самых основных персон)? теперь работа продолжается. Результатом ее должен стать «реестр заинтересованных лиц». Пример такого документа приведен в Приложении 2.

Даже на небольшом проекте (с бюджетом в несколько миллионов рублей и командой порядка 10 человек) такой реестр должен содержать десятки (хорошо, если сотни) фамилий.

По какому принципу мы называем того или иного человека «заинтересованным лицом»?

Во-первых, это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда).

Во-вторых, заинтересованным лицом всегда являются конечные пользователи продукта (ни в коем случае не пренебрегайте их интересами в проекте!).

В третьих, не забывайте о боссах членов вашей команды.

В четвертых, помните о тех, кто напрямую не связан с проектом, но, так или иначе, оказывает на него влияние.

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

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

Готовимся к сбору требований

По мере того, как список «заинтересованных лиц» формируется – мы приступаем к сбору требований.

Введем два термина: «требование» и «ожидание».

Ожидание – «умозрительная картинка будущего». Как правило – достаточно широкая. Пример ожидания: «чтобы производительность отдела возросла после внедрения ИТ-системы»; или «чтобы внедрение проекта не сильно сказалось на работе соседнего департамента». Ожидание нельзя включить в состав проекта, не преобразовав в требование.

Требование – конкретный, измеримый, проверяемый запрос заинтересованного лица. Пример требования: «система должна позволять проходить все пользовательские сценарии без использования манипулятора «мышь»».

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

Выбирая методы, необходимо тщательно взвесить наши потребности в информации и способности второй стороны ее предоставить.

Из наиболее распространенных можно выделить:

• Интервью
• Опросники
• Мозговые штурмы (в различных вариациях)
• Прототипирование

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

Опросники – это хороший способ быстро собрать информацию с множества людей (к тому же предоставив им вводить информацию в удобное для них время). Увы, у метода масса недостатков, главные из которых: «однобокость» собранной информации, высокая вероятность формального подхода к заполнению анкет (по принципу «чтобы отстали»).

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

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

Собираем требования

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

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

Если в вашей компании есть специалисты по сбору и описанию требований (например, аналитики), тогда львиную долю забот в этой области можно переложить на них. Это очень неплохой сценарий, ибо требования являются самой сложной и трудоемкой для описания «гранью треугольника».

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

Прежде чем отправиться к заинтересованным лицам (или отправить туда коллектив аналитиков) – определитесь, как будут храниться собранные требования. Совершенно не обязательно после каждого интервью или мозгового штурма рисовать схемы в определенной нотации. Если вы считаете, что достаточно будет текстовых описаний и произвольных картинок «от руки» – возможно, вы правы. Главное, договоритесь заранее, как будете фиксировать собранные требования со всеми участниками процесса.

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

Однако вам, как проектному менеджеру , важно сохранить контроль над процессом в целом, иметь возможность планировать и отслеживать выполнение работ для всего многообразия пожеланий заказчика. Для этого рекомендуется обзавестись выделенным списком, называть его можно «матрицей требований». Пример такого документа приведен в Приложении3.

Матрица позволяет фиксировать – когда обнаружено требование, кто автор (кто высказал), насколько данное требование важно (приоритетно). Также в матрицу целесообразно добавлять информацию о том, было ли требование выполнено в ходе реализации проекта, и не отменил ли его сам автор.

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

Когда остановиться? Проектные практики призывают нас собрать все требования, которые могут относиться к нашему проекту и только после этого двигаться дальше. Помните – «что нельзя спланировать, то нельзя и сделать».

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

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

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

Балансировка требований

Балансировка требований – отбор требований, реализация которых предполагается в рамках проекта.

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

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

Позже, когда себестоимость и продолжительность работ будет оценена, мы сможем вернуться к этой части плана и скорректировать ее (возможно, от каких-то требований придется отказаться или пересмотреть). Однако важно понимать – процесс балансировки требований не должен противоречить уставу проекта. Если в уставе, скажем, прописано как одно из главных требований к продукту – скорость реакции интерфейса не более чем за 0,5 секунды, то мы не можем выбросить подобное требование из реестра (его невыполнение похоронит проект).

Технически балансировка может представлять простановку соответствующих отметок в матрице требований. Результаты сбора и балансировки можно утвердить у заинтересованных лиц проекта. Продумайте заранее – собираетесь ли вы получать подтверждение, в какой форме.

Обратите внимание еще на такой аспект: в нашем проекте мы не используем термин «техническое задание» (ТЗ)

Де-факто, матрица требований (а также схемы и описания, на которые она ссылается) как раз и представляет собой техническое задание. Однако на практике ТЗ – это статичный документ, который является неотъемлемой частью некоторых видов контрактов.

Именно статичность технического задания делает его неудобным для всех заинтересованных лиц проекта. Правильно организовав работу с требованиями, мы снижаем риск «промахнуться мимо ожиданий заказчика» (одновременно и прислушиваясь к ним весь проект, и отсекая невыполнимые). ТЗ может оказать обратный эффект.

Если вы все же столкнулись с необходимостью разработать ТЗ (или привлечены к его разработке) – адаптируйте информацию матрицы требований и позаботьтесь о том, чтобы в документе появились подробные описания процедуры уточнения требований (особенно формальной ее стороны). Приведем один из примеров подобных процедур: «Список используемых в системе справочников и классификаторов приведен в приложении №101. Данный список может изменяться в сторону его увеличения или сокращения, но не более чем на 10 позиций. При необходимости внести изменения в список справочников, заказчик уведомляет о такой необходимости исполнителя не позднее, чем до 1 декабря 2010 года и предоставляет описание… По результатам поведенного исполнителем анализа составляется акт на основе шаблона в приложении №102.»

Создаем концепцию (scope) проекта

Позади достаточно кропотливая работа по сбору и балансировке требований. Настало время определиться – какие действия по проекту необходимы, чтобы выполнить задуманное.

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

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

Как должен выглядеть документ? Представьте, что на проекте появляется новый сотрудник. Он был только что принят на работу и, появившись утром на пороге офиса , он вежливо здоровается и просит «что-нибудь почитать по проекту», в котором ему предстоит участвовать.

Что вы ему дадите? Контракт? Не факт, что тот уже подписан, да и создается он, нередко, юристами для юристов.

Устав? Неплохая идея, но информация там слишком поверхностная – новый сотрудник вернется с новыми вопросами уже через несколько минут.

Матрица требований? Тоже неплохо, но она объясняет «что сделать», а не «как работать».

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

Не менее важно и то, что «концепция» содержит описание «проектного подхода». Какие правила общения с заказчиком имеются на проекте? Как мы условились с командой проводить совещания? Где посмотреть, кто, за что отвечает на проекте? Как поступать при необходимости внести изменения в первоначальные требования или добавить новое?

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

Один из возможных шаблонов «концепции» приведен в Приложении 4. В представленном варианте концепция содержит ссылки практически на все планы, многие из которых нам еще предстоит создать в рамках дальнейшего планирования по проекту (данный шаблон будет еще одним напоминанием «не забыть запланировать все» или «явно указать, какие разделы проекта не планируются и по какой причине»).

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

Выходы:

• Реестр заинтересованных лиц
• Матрица требований
• Концепция проекта

Глава VII. Определяем команду и планируем список покупок

Входы:

• устав
• концепция проекта

Какие ресурсы потребуются?

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

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

Остановимся подробнее на оценке ресурсов.

Не всегда количество требуемых людей и их квалификацию ПМ в состоянии оценить самостоятельно. Обычно, это и не требуется. Необходим диалог с «хозяевами ресурсов». Главная ваша задача – донести суть выполняемых работ (тут уже начинают работать созданные нами документы – scope, матрица требований). Объясняйте, что придется сделать команде в рамках проекта и просите «хозяина ресурсов» помочь вам определиться с требуемыми для такой работы навыками и/или оборудованием.

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

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

Будем ли привлекать подрядчиков?

В подавляющем большинстве проектов для выполнения определенных работ можно привлечь стороннюю организацию (если это допускает специфика отрасли и нее противоречит специальным положениям контракта или политики компании).

Некоторые из «лучших проектных практик» рекомендуют такой подход:

• Обязательно использовать субподряды:

  • Если это снижает риски проекта

• Можно использовать субподряды:

  • Если мы бережем (читай «испытываем дефицит») собственных ресурсов
  • Если мы пытаемся повысить управляемость проекта
  • Если сталкиваемся с необходимостью использовать патенты / сертификаты и т.п.

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

Закупки на проекте требуют отдельного планирования и управления. В настоящей книге мы не будем рассматривать этот процесс подробно. Зачастую, ответственность за него распределена между ПМ- и специализированными службами (департаментом закупок, юридической службой, и т.д.), и мы будем исходить из предположения, что ваша ответственность ограничена решением «делать или покупать». Принятое решение (возможно, после согласования со спонсором) нужно транслировать соответствующим службам / отделам, уведомить их о сроках и в дальнейшем под их руководством предоставить требуемую для будущих контрактов информацию.

«Выбиваем» ресурсы

Итак, в ходе общения с хозяевами ресурсов мы определили: «Кто нужен?», «Кто есть?» и «Кого дают?» нам в рамках проекта. Мы также определились с целесообразностью привлечения подрядчиков. Теперь надо сформировать «список ресурсов».

Список ресурсов – совокупность договоренностей о выделении ресурсов на проект (обычно – в виде единого документа или набора электронных писем из корпоративной переписи).

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

Построение конструктивных взаимоотношений с «хозяином ресурсов» очень важно. Для этого:

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

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

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

Все сотрудники, которых вы включите в список ресурсов автоматически войдут в состав команды проекта. Кто-то из них, возможно, уже поработал в составе команды (поучаствовав в сборе требований).

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

• Фамилию и имя сотрудника (избегайте указывать только должность)
• Период и объем занятости (например, «доступен с 1 сентября по 31 декабря 2010 года, занятость – 50%» – если речь идет о привлечении сотрудника, который будет делить время между вашим и другим проектом).

Использование приведенных выше правил избавит вас от необходимости придерживаться строгих шаблонов (напомню, переговоры о ресурсах с «хозяевами» – не всегда формальный процесс), однако по необходимости можно воспользоваться документом, приведенным в Приложении 6.

Все, кто оказался в списке ресурсов, автоматически становятся членами команды проекта (не забудьте об этом на следующих этапах).

Выходы:

• Решение «что покупаем» (устно или письменно)
• Список ресурсов

Назад Содержание Вперёд