Основы проектной деятельности Лекция 2
Что такое «содержание проекта»?
Содержание проекта – описание работ, которые необходимо выполнить, чтобы получить продукт.
Для описания ВСЕХ необходимых работ по проекту нужно: определиться с требованиями и ожиданиями заказчика, разобраться, какие из них реально выполнимы, и что для этого понадобится.
На языке нашей методологии данные шаги звучат следующим образом:
1. Собрать и финализировать требования
2. Сформировать концепцию
3. Создать ИСР (WBS)
Вернувшись к схеме в предыдущей главе, вы можете заметить, что формирование концепции и создание ИСР (WBS) разделены еще двумя шагами из других областей знаний. В настоящей главе мы будем говорить о первых двух этапах создания содержания проекта (без ИСР).
Первый шаг (собрать и финализировать требования) неявно включает в себя два компонента: выявление заинтересованных лиц и собственно сбор требований. Об этом подробнее мы поговорим ниже.
Сбор требований
Собрать и финализировать требования – один из наиболее трудоемких и плохо формализуемых процессов. Все что известно сейчас – крупноуровневые требования, зафиксированные в уставе (вполне возможно, что они описаны несколькими предложениями). Наша задача конкретизировать их.
Чтобы справиться с ней- необходимо понять «кто?» является источником требований на проекте и «что?» конкретно он хочет получить по окончании работ.
Крайне опасно на данном этапе поддаться искушению «назначить» ответственным за все требования спонсора или заказчика. Кто бы ни подписал наш устав, а, в дальнейшем, и контракт на выполнение работ - он никогда не станет единоличным источником информации о требованиях.
Лучшие проектные практики гласят:
проект с неудовлетворенными ожиданиями заказчика не является успешным
проект, результаты которого не используются конечными пользователями, не является успешным.
Помните об этих двух тезисах. Сейчас вам предстоит одна из самых изнурительных задач в проектном управлении - выявлять заинтересованных лиц и собирать требования. Это не забота заказчика, это ваша забота. Пренебрегая ей - вы рискуете в лучшем случае «закрыть контракт формально, испортив отношения с заказчиком», а в худшем - получить на исходе проекта лавину претензий и придирок, которая утопит и вас и команду и сделает сдачу невозможной.
Выявляем заинтересованных лиц
Эту работы мы начали еще в фазу инициации (определив самых основных персон)? теперь работа продолжается. Результатом ее должен стать «реестр заинтересованных лиц».
Входы:
- Концепция проекта
- ИСР (WBS) и ресурсы, распределенные по работам
- Команда проекта
Каждый элемент создаваемого нами плана должен быть понятным и реально использоваться заинтересованными лицами. Сейчас, когда все грани треугольника уточнены, стоит уделить особое внимание достаточности коммуникаций и распределению ответственности на проекте.
Даже на небольшом проекте (с бюджетом в несколько миллионов рублей и командой порядка 10 человек) такой реестр должен содержать десятки (хорошо, если сотни) фамилий.
По какому принципу мы называем того или иного человека «заинтересованным лицом»? Во-первых, это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда).
Во-вторых, заинтересованным лицом всегда являются конечные пользователи продукта (ни в коем случае не пренебрегайте их интересами в проекте!).
В-третьих, не забывайте о боссах членов вашей команды.
В-четвертых, помните о тех, кто напрямую не связан с проектом, но, так или иначе, оказывает на него влияние.
Последняя группа заинтересованных лиц - наиболее трудна к выявлению, однако порой вклад таких «серых кардиналов» очень велик. В качестве примера можно привести гипотетическую ситуацию, когда сын заказчика является в его глазах авторитетом в сфере информационных технологий и привлекается отцом к принятию принципиальных решений о внедряемых системах. При этом сын не является сотрудником ни одной из участвующих в проекте организаций (или, допустим, вообще еще школьник). Однако высказанные им советы имеют для папы больший вес, чем экспертные заключения его же сотрудников. Возможно, «добраться» до такого
«заинтересованного лица» в ходе проекта вам и не удастся, но, знать (или, хотя бы, предполагать его существование) - достаточно важно.
Не бойтесь включать в реестр большое количество людей. Вы всегда сможете классифицировать их по «степени влияния на проект» позднее и работать только с самыми главными. Сейчас важнее никого не забыть (ибо влияние заинтересованного лица не проекте, со временем, может и возрасти).
Готовимся к сбору требований
По мере того, как список «заинтересованных лиц» формируется – мы приступаем к сбору требований. Введем два термина: «требование» и «ожидание».
Ожидание - «умозрительная картинка будущего». Как правило - достаточно широкая. Пример ожидания: «чтобы производительность отдела возросла после внедрения ИТ-системы»; или «чтобы внедрение проекта не сильно сказалось на работе соседнего департамента». Ожидание нельзя включить в состав проекта, не преобразовав в требование.
Требование - конкретный, измеримый, проверяемый запрос заинтересованного лица. Пример требования: «система должна позволять проходить все пользовательские сценарии без использования манипулятора «мышь»».
Нам предстоит выбрать один или несколько методов «вытягивания» из заинтересованных лиц их ожиданий и требований (разумеется, нас в меньшей степени волнует наша собственная команда, и куда больше - представители заказчика и всевозможные стоящие за ним и над ним «серые кардиналы»).
Выбирая методы, необходимо тщательно взвесить наши потребности в информации и способности второй стороны ее предоставить.
Из наиболее распространенных можно выделить:
- Интервью
- Опросники
- Мозговые штурмы (в различных вариациях)
- Прототипирование
Интервью - является одним из самых надежных методов, он же - самый трудозатратный. Непосредственное общение позволяет собрать наиболее полную и достоверную информацию, а также установить конструктивный рабочий контакт с собеседником. Главный минус - трудозатраты (вам придется тратить свое и чужое время в больших количествах). Кроме того- с некоторыми заинтересованными лицами общение может оказаться невозможным по причине их «статусности» (так, не всегда возможно уговорить топ-менеджмент компании-заказчика уделить вам часок-другой на очной встрече, даже если это в интересах проекта).
Опросники - это хороший способ быстро собрать информацию с множества людей (к тому же предоставив им вводить информацию в удобное для них время). Увы, у метода масса недостатков, главные из которых: «однобокость» собранной информации, высокая вероятность формального подхода к заполнению анкет (по принципу «чтобы отстали»).
Мозговой штурм - весьма условно можно назвать «коллективным интервью». Проведенный по определенным правилам, мозговой штурм может оказаться крайне эффективным. Однако помните, что некоторым людям трудно общаться даже в небольших коллективах - чтобы они не «отмалчивались» и не стеснялись в высказываниях, развивайте навыки ведения подобных мероприятий.
Прототипирование - это прекрасный способ собрать или уточнить требования. Под прототипом мы можем понимать любой понятный вашему собеседнику образ продукта (будь то картинка, макет или какой-либо аналог). Прототипирование удобно сочетать с другими техниками (например, интервью); главное не ограничиваться только им, дабы не упустить существенные моменты, не реализованные в прототипе, но важные для продукта.
Собираем требования
К сбору требований мы приступаем, определившись с методами и вооружившись реестром заинтересованных лиц.
Сбор требований ПМ ведет не в одиночку, а совместно с командой. Собственно команда окончательно будет сформирована чуть позже, но на данном этапе нам уже пригодятся помощники (надеюсь, вы добавили соответствующую запись в устав и заблаговременно предупредили «хозяина ресурсов» о ваших потребностях).
Если в вашей компании есть специалисты по сбору и описанию требований (например, аналитики), тогда львиную долю забот в этой области можно переложить на них. Это очень неплохой сценарий, ибо требования являются самой сложной и трудоемкой для описания «гранью треугольника».
Однако, даже делегируя свои хлопоты - не выключайтесь из процесса и помните, что каждый день кто-то из членов команды (не обязательно аналитик) сталкивается с пожеланиями заинтересованных лиц, которые не были учтены раньше. Организуйте работу так, чтобы каждый ваш сотрудник в любой момент имел доступ к перечню выявленных требований - мог бы его просмотреть и дополнить.
Прежде чем отправиться к заинтересованным лицам (или отправить туда коллектив аналитиков) - определитесь, как будут храниться собранные требования. Совершенно не обязательно после каждого интервью или мозгового штурма рисовать схемы в определенной нотации. Если вы считаете, что достаточно будет текстовых описаний и произвольных картинок «от руки» - возможно, вы правы.
Главное, договоритесь заранее, как будете фиксировать собранные требования со всеми участниками процесса.
После того, как процесс запущен, и требования стали поступать - не забывайте фиксировать их. Возможно, у вас на столе начинает расти пачка «организационных диаграмм», или электронная почта ежедневно пополняется подробными «отчетами об обследовании» и «отчетами об интервью». Все они окажутся весьма полезны в дальнейшем - при выполнении работ, при необходимости уточнить задачу.
Однако вам, как проектному менеджеру , важно сохранить контроль над процессом в целом, иметь возможность планировать и отслеживать выполнение работ для всего многообразия пожеланий заказчика. Для этого рекомендуется обзавестись выделенным списком, называть его можно «матрицей требований».
Матрица позволяет фиксировать - когда обнаружено требование, кто автор (кто высказал), насколько данное требование важно (приоритетно). Также в матрицу целесообразно добавлять информацию о том, было ли требование выполнено в ходе реализации проекта, и не отменил ли его сам автор.
Обратите внимание - осуществляя сбор требований и заполняя матрицу, мы не пытаемся с ходу принять решение, «беремся ли мы за их реализацию в данном проекте, или нет». Проще говоря - собираем «все, что есть» (в рамках разумного, конечно). На этом этапе заинтересованным лицам не дается никаких обещаний. Мы лишь собираем их требования и ожидания (последние также превращая в требования с помощью авторов). И по мере того, как сбор требований завершается - приступаем к их «балансировке» (т.е. оценке того, то войдет в проект).
Когда остановиться? Проектные практики призывают нас собрать все требования, которые могут относиться к нашему проекту и только после этого двигаться дальше. Помните - «что нельзя спланировать, то нельзя и сделать».
Многие методологии разработки ПО обосновано считают строгую последовательность «спланировал»- «сделал» - «показал» - «сдал» (без демонстрации промежуточных результатов заинтересованным лицам и регулярной корректировки исходных планов) злом, повышающим риски провала.
Сбор требований в рамках начального планирования должен быть разумно-глубоким и максимально широким. Однако речь не идет о том, что на этом работа с требованиями должна прекратиться, а их список оказаться «фиксирован» до конца проекта. Работа с ожиданиями заказчика, накопление его согласия, корректировка планов в течение всего жизненного цикла проекта - основа проектного управления.
Иногда процесс первоначального сбора требований оказывается столько трудоемким и растянутым во времени, что целесообразно выделить его в отдельный проект. Если предполагаете большие трудозатраты - обсудите это со спонсором как можно раньше.
Балансировка требований
Балансировка требований – отбор требований, реализация которых предполагается в рамках проекта.
Процесс балансировки основан на сочетании интуиции и здравого смысла. Сперва, мы приоритезируем требования (выделяя наиболее значимые), а затем отбираем к реализации те из них, которые возможно уложить в рамки проектных ограничений (стоит помнить, что некоторые требования могут оказаться взаимосвязаны и включать или исключать их из треугольника можно только вместе).
На данном этапе мы обладаем лишь предварительными (грубыми) оценками стоимости и сроков проекта и пока не знаем точно, сколько «будут стоить» и длиться выбранные нами работы. В своих текущих оценках мы полагаемся на профессиональный опыт и чутье (свое и команды).
Позже, когда себестоимость и продолжительность работ будет оценена, мы сможем вернуться к этой части плана и скорректировать ее (возможно, от каких-то требований придется отказаться или пересмотреть). Однако важно понимать - процесс балансировки требований не должен противоречить уставу проекта. Если в уставе, скажем, прописано как одно из главных требований к продукту - скорость реакции интерфейса не более чем за 0,5 секунды, то мы не можем выбросить подобное требование из реестра (его невыполнение похоронит проект).
Технически балансировка может представлять простановку соответствующих отметок в матрице требований. Результаты сбора и балансировки можно утвердить у заинтересованных лиц проекта. Продумайте заранее - собираетесь ли вы получать подтверждение, в какой форме.
Обратите внимание еще на такой аспект: в нашем проекте мы не используем термин «техническое задание» (ТЗ)
Де-факто, матрица требований (а также схемы и описания, на которые она ссылается) как раз и представляет собой техническое задание. Однако на практике ТЗ - это статичный документ, который является неотъемлемой частью некоторых видов контрактов.
Именно статичность технического задания делает его неудобным для всех заинтересованных лиц проекта. Правильно организовав работу с требованиями, мы снижаем риск «промахнуться мимо
ожиданий заказчика» (одновременно и прислушиваясь к ним весь проект, и отсекая невыполнимые). ТЗ может оказать обратный эффект.
Если вы все же столкнулись с необходимостью разработать ТЗ (или привлечены к его разработке) - адаптируйте информацию матрицы требований и позаботьтесь о том, чтобы в документе появились подробные описания процедуры уточнения требований (особенно формальной ее стороны).
Приведем один из примеров подобных процедур:
«Список используемых в системе справочников и классификаторов приведен в приложении №101. Данный список может изменяться в сторону его увеличения или сокращения, но не более чем на 10 позиций. При необходимости внести изменения в список справочников, заказчик уведомляет о такой необходимости исполнителя не позднее, чем до 1 декабря 2010 года и предоставляет описание... По результатам поведенного исполнителем анализа составляется акт на основе шаблона в приложении №102.»
Создаем концепцию (scope) проекта
Позади достаточно кропотливая работа по сбору и балансировке требований. Настало время определиться – какие действия по проекту необходимы, чтобы выполнить задуманное.
Обратите внимание, переходя от сбора требований к формированию scope - мы отходим от непосредственной работы с представителями заказчика и погружаемся в наши собственные заботы. Мы уже знаем, «что» от нас хотят и пытаемся разобраться «как» выполнить обещанное.
Таким образом, «концепция проекта» крайне важна для команды, но не для тех, чьи интересы команда обслуживает. Мы должны будем позаботиться о том, чтобы «концепция» была доступна нашим собственным сотрудникам, понята и принята ими, а вот привлекать к его согласованию заказчика - ни к чему.
Как должен выглядеть документ? Представьте, что на проекте появляется новый сотрудник. Он был только что принят на работу и, появившись утром на пороге офиса , он вежливо здоровается и просит
«что-нибудь почитать по проекту», в котором ему предстоит участвовать.
Что вы ему дадите? Контракт? Не факт, что тот уже подписан, да и создается он, нередко, юристами для юристов.
Устав? Неплохая идея, но информация там слишком поверхностная - новый сотрудник вернется с новыми вопросами уже через несколько минут.
Матрица требований? Тоже неплохо, но она объясняет «что сделать», а не «как работать».
Наиболее правильным ответом является «концепция проекта». Данный документ будет содержать как общую информацию о проекте, так и ссылки на всевозможные требования и описания продукта, так что новый сотрудник, в зависимости от характера своих вопросов - сможет самостоятельно найти максимум информации без посторонней помощи.
Не менее важно и то, что «концепция» содержит описание «проектного подхода». Какие правила общения с заказчиком имеются на проекте?
Как мы условились с командой проводить совещания? Где посмотреть, кто, за что отвечает на проекте? Как поступать при необходимости внести изменения в первоначальные требования или добавить новое? Словом, концепция - краеугольный камень проекта.
Сама по себе она может быть немногословна, но изобиловать ссылками на внешние документы (избегайте ненужного переписывания информации из документа в документ - ограничивайтесь ссылкой; это сэкономит ваши силы и многократно облегчит поддержание целостности и непротиворечивости информации).
Один из возможных шаблонов «концепции» приведен в Приложении 4. В представленном варианте концепция содержит ссылки практически на все планы, многие из которых нам еще предстоит создать в рамках дальнейшего планирования по проекту (данный шаблон будет еще одним напоминанием
«не забыть запланировать все» или «явно указать, какие разделы проекта не планируются и по какой причине»).
Теперь любой член вашей команды (будь то разработчик, тестировщик или нанятый для консультаций эксперт) может максимально четко представить себе общую задачу и свою конкретную роль. Не забудьте сделать scope доступным и проинформировать о нем всех участников.
Выходы:
Реестр заинтересованных лиц
Матрица требований
Концепция проекта
Определяем команду и планируем список покупок
Входы:
-устав
-концепция проекта
Какие ресурсы потребуются?
Определившись с балансировкой требований и концепцией, приступаем к планированию ресурсов. Во время инициации мы поверхностно затрагивали эту тему со спонсором, теперь - стоит детально проработать этот вопрос. Есть ли в нашей компании доступные сотрудники с нужной квалификацией? Требуется ли специфичное оборудование? Может, для выполнения каких-то работ нужна особая лицензия?
Для проведения таких оценок нам потребуется хорошо спланированное содержание проекта и понимание доступных вам ресурсов и возможностей внутри организации (с этим могут помочь устав и общение со спонсором и хозяевами ресурсов).
Остановимся подробнее на оценке ресурсов.
Не всегда количество требуемых людей и их квалификацию ПМ в состоянии оценить самостоятельно. Обычно, это и не требуется. Необходим диалог с «хозяевами ресурсов». Главная ваша задача - донести суть выполняемых работ (тут уже начинают работать созданные нами документы - scope, матрица требований). Объясняйте, что придется сделать команде в рамках проекта и просите «хозяина ресурсов» помочь вам определиться с требуемыми для такой работы навыками и/или оборудованием.
Второй важный вопрос, помимо «кто нужен?» на проект - это «кто есть?» в вашей организации сейчас. Есть ли у нас сотрудники с требуемой квалификацией? Может, для выполнения работ потребуется специальная лицензия - а она у нас имеется? И так далее.
Обсудив принципиальное наличие ресурсов внутри организации - выясните, когда и на какой срок их можно задействовать в вашем проекте. Возможно, единственный подходящий специалист уже задействован на 120% до конца года? Или требуемый нам сервер можно получить в свое распоряжение лишь на пару дней? Все это может быть поводом для проведения закупок или привлечения подрядчиков.
Будем ли привлекать подрядчиков?
В подавляющем большинстве проектов для выполнения определенных работ можно привлечь стороннюю организацию (если это допускает специфика отрасли и нее противоречит специальным положениям контракта или политики компании).
Некоторые из «лучших проектных практик» рекомендуют такой подход:
o Обязательно использовать субподряды: Если это снижает риски проекта
- Можно использовать субподряды:
- Если мы бережем (читай «испытываем дефицит») собственных ресурсов
- Если мы пытаемся повысить управляемость проекта
- Если сталкиваемся с необходимостью использовать патенты / сертификаты и т.п.
Обратите внимание на пункт, касающийся «управляемости проекта». Иногда ее легче сохранить, поручив блок работ сторонней компании, чем контролировать множество собственных сотрудников, особенно если те, время от времени перемещаются на другие проекты, а к нам взамен приходят еще «не погруженные» в рабочий процесс люди.
Закупки на проекте требуют отдельного планирования и управления. В настоящей книге мы не будем рассматривать этот процесс подробно. Зачастую, ответственность за него распределена между ПМ- и специализированными службами (департаментом закупок, юридической службой, и т.д.), и мы будем исходить из предположения, что ваша ответственность ограничена решением «делать или покупать». Принятое решение (возможно, после согласования со спонсором) нужно транслировать соответствующим службам / отделам, уведомить их о сроках и в дальнейшем под их руководством предоставить требуемую для будущих контрактов информацию.
«Выбиваем» ресурсы
Итак, в ходе общения с хозяевами ресурсов мы определили: «Кто нужен?», «Кто есть?» и «Кого дают?» нам в рамках проекта. Мы также определились с целесообразностью привлечения подрядчиков. Теперь надо сформировать «список ресурсов».
Список ресурсов - совокупность договоренностей о выделении ресурсов на проект (обычно - в виде единого документа или набора электронных писем из корпоративной переписи).
Из определения выше видно, что список ресурсов не обязательно будет «официально подписанной бумагой». Во многих компаниях договариваться с «хозяевами ресурсов» принято неформально, а данный список - наш способ «напомнить» о прежних договоренностях.
Построение конструктивных взаимоотношений с «хозяином ресурсов» очень важно. Для этого:
- Не требуйте ресурсов «в последний момент». Всегда уведомляйте «хозяев ресурсов» о ваших потребностях как можно раньше (а для этого правильно ведите планирование)
- Просите «достаточно хорошие ресурсы». Не настаивайте на выделение к вам в команду «сверхкомпетента» без реальной необходимости.
Когда при формировании списка выясняется, что предоставить достаточные ресурсы на проект невозможно - обращайтесь к спонсору. Правильно написанный устав уполномочил вас не только общаться с «хозяевами ресурсов», но распределил ответственность между вами и спонсором.
Ваша «головная боль» ограничена уставом (где прописаны и ресурсы). За пределами устава - «голова болит» у спонсора. В чем бы ни была проблема с ресурсами - спонсор в состоянии ее решить (нанять дополнительных людей в отдел, разрешить привлечь подрядчиков, поменять приоритеты по распределению сотрудников между проектами «хозяевами ресурсов»). Альтернативой всегда является отмена проекта или переписывание устава (последнее во многом равносильно «закрытию проекта» и «открытию другого»). Однако, если вы не побеспокоитесь о выделении команды и техники
- никто другой этого не сделает (помните, ответственность за проект в целом лежит на вас, умолчав о проблемах на ранних стадиях - вы неявно берете на себя вину за провал проекта в будущем).
Все сотрудники, которых вы включите в список ресурсов автоматически войдут в состав команды проекта. Кто-то из них, возможно, уже поработал в составе команды (поучаствовав в сборе требований).
Включая сотрудника в список, прописывайте условия его привлечения настолько конкретно, насколько это возможно. Не забудьте указать:
Фамилию и имя сотрудника (избегайте указывать только должность)
Период и объем занятости (например, «доступен с 1 сентября по 31 декабря 2024 года, занятость - 50%» - если речь идет о привлечении сотрудника, который будет делить время между вашим и другим проектом).
Использование приведенных выше правил избавит вас от необходимости придерживаться строгих шаблонов (напомню, переговоры о ресурсах с «хозяевами» - не всегда формальный процесс), однако по необходимости можно воспользоваться документом, приведенным на слайде
Все, кто оказался в списке ресурсов, автоматически становятся членами команды проекта (не забудьте об этом на следующих этапах).
Выходы:
Решение «что покупаем» (устно или письменно)
Список ресурсов
Планируем время и стоимость с использованием специализированного программного обеспечения
Входы:
Концепция проекта
Матрица требований
Список ресурсов
Команда проекта (ключевые сотрудники по списку ресурсов)
Мы начали уточнять содержание проекта, и, создав «концепцию» и «матрицу требований» прервались, чтобы сформировать команду. Теперь вернемся к управлению содержанием, а заодно и уточним сроки и стоимость нашего проекта. Таким образом, мы проведем детальное планирование всех граней «проектного треугольника».
В начале наших занятий мы договорились, что будем рассматривать управление проектов в организации, где нет сложившихся корпоративных практик, а в своей работе будем использовать «подручные средства». Для этого нам потребуется одно из самых «продвинутых» подручных средств - специализированный софт для управления проектом.
Сразу подчеркнем:
1. В рассматриваемых нами сценариях софт должен быть установлен только на вашем компьютере (команда проекта в нем не работает, только вы)
2. При желании, вы можете обойтись без специализированного софта, но это увеличит ваши трудозатраты на работу с документами
Конкретный программный продукт не имеет значения. В настоящий момент на рынке существует множество платных и бесплатных решений, самые распространенные из них: MS Project, Spider Project, Primavera, Prince. Здесь мы будем использовать иллюстрации на базе MS Project 2010.
Мы не станем подробно останавливаться на описании приемов работы с программным продуктом - для этого существуют десятки специализированных издании. Лишь поясним, как могут выглядеть ваши планы, заведенные в соответствующий софт. Для простоты будем использовать сквозной пример условного проекта по созданию сайта (состоящего из одной странички).
Шаг первый: формируем ИСР (WBS)
Возвращаемся к планированию содержания. Наша задача – разбить общий результат поставки проекта (описанный в «концепции») на более мелкие соподчиненные блоки «результатов работ». Для этого мы создадим иерархическую структуру работ (или work breakdown structure) – сокращенно ИСР (WBS).
ИСР - ориентированная на результат поставки иерархическая декомпозиция работ, выполняемых командой проекта. Каждый следующий уровень иерархии отражает более детальное определение элементов проекта. Ориентация на результат поставки включает внутренние и внешние результаты поставки.
Зачем это нужно? Создание ИСР помогает структурировать необходимые поставки, сделать информацию о них более наглядной.
Помните - ИСР создается совместно с командой! Это очень существенный момент. Как бы организационно вы не подошли к данному вопросу (будете ли сами создавать некий «черновик» и потом «утверждать» его вместе с командой, или с самого начала соберетесь все вместе) - главное найти способ привлечь сотрудников к планированию. Это повысит достоверность планов и, в то же время, сплотит команду.
О чем следует помнить, создавая ИСР?
Во-первых, о том, что ИСР - поставко-ориентировано. На верхнем уровне структуры всегда находится главная поставка по проекту (иногда там пишут название проекта). На более низких уровнях - более мелкие поставки. Самыми важными уровнями считаются первый и второй (они отражать названия всех поставок, упомянутых в концепции проекта).
Во-вторых, занимаясь декомпозицией ИСР нужно уметь вовремя остановиться. Например, при разработке программного обеспечения, важно не увлечься декомпозицией ради декомпозиции (ведь, скажем, создание экранной формы всегда можно разбить на создание «кнопочки такой-то» и «кнопочки-другой» и так далее). Слишком поверхностный WBS нам тоже не подойдет. Разумная глубина отражена в понятии «пакета работ».
Основные признаки пакета работ:
Относительно короткий
Работы по созданию пакета могут быть выполнены без прерывания
Работы по созданию пакета могут быть выполнены на аутсорсинге
Обратите внимание на слова «относительно короткий» и «без прерывания». Это вовсе не означает, что пакетом является то, что можно успеть сделать до ближайшего перекура или в течение одного дня. Под прерыванием понимается вынужденная остановка работ (например, для проведения других действий или получения согласования). Так, нельзя назвать пакетом работы по созданию «макета и шаблона сайта», если мы знаем, что нарисованный макет нужно сперва предъявить заказчику и, только получив его согласие, можно приступать к формированию шаблона.
Источником данных для создания WBS служит концепция проекта. А вот наиболее удобным местом хранения введенных данных выступает специализированное ПО. Любой из перечисленных продуктов позволяет хранить информацию о работах в следующем виде:
Иногда, составление полной детализированной ИСР оказывается невозможной или нецелесообразной (например - слишком трудоемкой). В таком случае прибегают к методу
«набегающей волны». Суть его состоит - в детализации лишь самых ближайших к выполнению элементов (забегая вперед - в нашем примере это работы, связанные с макетом (пакеты работ № 3 и 4). Остальные элементы ИСР обознаются только на верхнем уровне (в нашем примере - можно было бы указать только создание Главной страницы, без декомпозиции на пакеты № 6, 7, 8, 9).
Важнейшим элементом ИСР служит так называемый «словарь ИСР» (WBS-dictionary). Словарь позволяет подробнее описать то, что мы имели в виду под скупой формулировкой в ИСР. В нашем сценарии роль «словаря» могут выполнять ссылки на данные результатов обследования (глава VI). При использовании специализированного ПО элементы словаря можно создавать и хранить разными способами, например - в виде специальных «заметок», привязанных к каждому элементу ИСР.
Информация словаря должна быть доступна всем членам команды - для использования при выполнении собственных работ.
Шаг второй. Определяем перечень действий.
Мы начинаем постепенно переходить от планирования содержания – к планированию времени. В том же самом программном продукте нам предстоит декомпозировать сформированный ранее пакет работ до действий.
Внимание! Пакет был поставко-ориентирован, в качестве пакета могли выступать экранные формы, элементы интерфейса, хранимые процедуры, структуры базы данных и т.д.
Сейчас мы декомпозируем их, описывая действия, каждое из которых может не иметь измеримого результата.
Здесь уже нет четких правил. Глубина декомпозиции никак не регламентируется. Да и сам пакет работ иногда декомпозиции не требует - можно оставить его в первоначальном виде (часто, для многих пакетов так и поступают).
В нашем примере декомпозиции подверглись только два пакета - «создать макет» и «утвердить макет у заказчика» (в каждую из них добавилось по два действия) Руководствуйтесь здравым смыслом, советуйтесь с командой.
Декмопозируйте до тех пор, пока вам это помогает, не делайте работу ради работы.
Шаг третий. Определяем последовательность действий.
Определившись с нужными действиями (а, возможно, и оставив некоторые или все пакеты в неприкосновенности) – переходим к их упорядочиванию.
Мы задаем порядок действий и пакетов в поле «предшественник» (в специализированном ПО, обычно, есть специальное поле «предшественник», которое может содержать ссылку на одну или несколько предшествующих работ).
Один из способов наглядно отобразить результат - перевести его из таблично вида в графический, сформировав «сетевую диаграмму».
Этот шаг довольно простой, но, будучи проделан совместно с командой, позволяет лишний раз проверить, что мы не упустили никакой важный пакет или работу.
Шаг четвертый. Определяем ресурсы
Определившись, какие действия в какой последовательности будут выполняться на нашем проекте, мы почти готовы приступить к непосредственной оценке их продолжительности и стоимости. «Почти» связано с тем, что в большинстве проектов ИТ-сферы исполнители оказывают огромное влияние на эффективность выполнения работы. До того, как мы дадим оценки по времени – мы должны знать «кто» и «над чем» будет работать.
Ссоставом команды проекта мы определились раньше. Более того, я надеюсь, что многие члены команды уже привлечены к планированию проекта. Определите, насколько это возможно, кто и за какую работу будет браться в проекте.
Специализированное ПО позволяет задавать список ресурсов для проекта и назначать один или несколько из них для каждого действия (заметьте, действия не обязательно должны выполняться в одиночку).
Шаг пятый. Определяем продолжительность и стоимость.
Сейчас нам предстоит уточнить продолжительность и стоимость работ.
Грубые (ROM) предположения были ранее включены в устав. Сейчас нам требуются намного более точные прогнозы. Потребителем таких оценок будет уже не спонсор / заказчик, а непосредственные исполнители, команда. То, что мы сделаем сейчас, станет мерилом их успешности на проекте.
Поэтому, приготовьтесь к напряженному процессу.
Оцениваем время
Мы не будем углубляться в техники и приемы оценки времени, а перечислим лишь некоторые из них и главные рекомендации
Среди основных методов оценки времени иногда называют:
Оценку одним человеком
Оценку по аналогу
Параметрическую оценку
PERT Program (Project) Evaluation and Review Technique (сокращённо PERT) - метод оценки и анализа проектов, который используется в управлении проектами.
Эвристическую оценку
Анализ резервов
Метод оценки одним человеком нужно использовать с осторожностью (в силу его субъективности) и никогда не делать основным.
Оценка по аналогу - прекрасный способ мгновенно получить грубую оценку (его часто используют в фазе инициации) а также дать команде простой и понятный «ориентир продукта». Однако на многих ИТ-проектах данный метод недоступен (в силу уникальности того же продукта).
Методы параметрических и эвристических оценок порождают огромное количество споров и дискуссий в разных профессиональных сообществах (корректно ли оперировать «строчками кода в день», верно ли утверждение что «тестирование занимает 1/3 разработки») и так далее. К какому бы лагерю спорщиков вы не относились - не пренебрегайте данными оценками, но относитесь к ним критично.
PERT (или «оценка по трем точкам) - чрезвычайно полезный прием, позволяющий оценить продолжительность выполнения работ, комбинируя «оптимистичную», «пессимистичную» и «наиболее вероятную» оценки. Используйте PERT для тех работ, оценка которых затруднена и/или имеет высокий диапазон допущения.
Данный метод оперирует тремя видами усредненных прогнозов - «пессимистичным»,
«оптимистичным» и «наиболее вероятным». Вам предлагается определить их (самостоятельно или с помощью экспертов) для каждой работы «достоверную» продолжительность которой вы собираетесь определить, а затем подставить в приведенные ниже формулы.
Согласно PERT предполагаемая длительность (или EAD) составит:
EAD = (P + 4M +O) / 6
где P - «пессимистичная оценка», O - «оптимистичная оценка», M - «наиболее вероятная оценка». С помощью PERT можно дополнительно уточнить и сам диапазон допущения вот таким способом:
Возможное отклонение (SD) составит: SD = (P-O) / 6
диапазон колебания (range) составит: Самый оптимистичный прогноз = EAD - SD Самый пессимистичный прогноз = EAD + SD
Используйте и комбинируйте методы оценки времени. По-возможности - привлекайте экспертов (внутри или вне компании), используйте сложившиеся корпоративные практики (если таковые существуют).
Помните, точность создаваемых сейчас оценок должна быть достаточно высокой (с погрешностью от 5 до 25%, или даже меньше, в зависимости от характера вашего проекта).
Полученные результаты мы вносим для каждого действия в специализированное ПО.
В соответствующих столбцах появляются отметки о продолжительности работ. Также становятся доступны дополнительные виды диаграмм, например, диаграмма Ганта.
Диаграмма Ганта помогает наглядно оценить продолжительность работ.
Оцениваем стоимость
Сделаем сразу оговорку – не на всех проектах ПМ явно управляет бюджетом. Иногда, эту функцию берет на себя спонсор, от которого руководитель проекта получает информацию лишь в количестве выделенных ему на определенный срок ресурсов. В таком случае ПМ как бы «покупает» (а, вернее, «берет в пользование») ресурсы компании, не задумываясь об их цене.
Мы рассмотрим случай, когда бюджет является головной болью руководителя проекта. В таком случае, нам понадобится оценить, сколько будут «стоить» действия внутри пакетов.
Многие из методов, описанных в предыдущем разделе, посвященном оцениванию времени, могли бы нам пригодиться. Это и оценка одним человеком, и оценка по аналогу, и параметрическая оценка, и тот же PERT (оперирующий вместо прогнозов времени - деньгами).
Однако одним из наиболее удобных и наглядных способов является оценка «снизу вверх», описанием которой мы и ограничимся.
Себестоимость ИТ-проектов, в массе своей, складывается из себестоимости их ресурсов. Перечень ресурсов мы завели в специализированное программное ПО во время шага 4. Теперь можем просто задать правила начисления их зарплаты (будь то ставки в час, зарплата в месяц, повышенные сверхурочные и т.п.). Все расчеты произведет ПО.
В новом поле отображаются затраты не только по каждой работе, но и этапу и проекту в целом. Посмотрите на результат – является ли он себестоимостью всех действий по вашему проекту? Не забыли ли вы включить существенные расходы, которым не нашлось места в сетевой диаграмме? Если да, то найдите способ их зафиксировать (простой, но некрасивый вариант – добавить в структуру работ веху с «говорящим названием» и определенной стоимостью; о вехах мы поговорим ниже).
Шаг шестой. Создаем расписание
На предыдущем этапе мы оценили продолжительность работ. Назвать ее расписанием нельзя, поскольку наши оценки пока привязаны к календарю. Сейчас мы именно этим и займемся.
Задаем точку старта
В уставе зафиксированы даты начала и окончания проекта. Используя специализированное ПО, мы задаем точку старта проекта и видим предполагаемую дату окончания. Укладывается ли результат в сроки, указанные в уставе? Возможно.
В этот момент нам удобно ввести понятие «вех».
Веха - это работа с нулевой длительностью. Вехи используются при создании расписания проекта, чтобы обозначить значимый этап.
Добавим в наше расписание значимые для нас вехи. Допустим, в уставе прописано, что до 10 сентября необходимо согласовать с заказчиком макет, а весь проект завершить не позже 15-го. Укажем в перечне задач соответствующие вехи.
Вехи будут помогать нам удобнее организовать расписание и, в то же время, могут выступать ограничениями проекта. Также «график вех» - одна из разновидностей отчета, который очень удобно использовать для коммуникаций с заказчиком.
Сетевой анализ расписания
Как видим, обе значимые для нас вехи легко уложились в расписание. Радоваться еще рано. Во- первых, подобное редко происходит в реальной жизни. Во-вторых – нам еще нужно кое-что утончить и расписание может поменяться. Совокупность этих действий принято называть «сетевым анализом расписания».
Сетевой анализ включает в себя:
анализ и выравнивание ресурсов
анализ критического пути
сжатие расписания (crashing и fast track)
анализ Монте-Карло
Анализ и выравнивание ресу рсо в начинается с анализа диаграммы использования ресурсов (доступна в любом специализированном ПО). Нет ли перегрузки - не получается ли, что один и тот же разработчик должен несколько месяцев решать одновременно множество задач, работая за троих?
Если да, то используйте «выравнивание ресурсов» (также стандартная опция в специализированном ПО - вот почему я так настойчиво рекомендую вам его использовать).
Посмотрите, как программа предложит вам поменять расписание проекта (какие-то работы сдвинуть во времени, чтобы дать возможность нашим сотрудникам закончить другие дела и приступить к другим).
Укладываемся ли мы в ограничения сроков из устава теперь? Возможно. Но с огромной вероятностью нет (такова природа проектов вообще и ИТ-проектов в частности). Будем работать над расписанием дальше.
Критический путь отражает самый длинный путь в нашей сетевой диаграмме и самое короткое время, за которое можно выполнить проект. Это одно из фундаментальных понятий в проектном управлении.
Работы на критическом пути нельзя делать параллельно (они строго последовательны).
Взятый нами ранее пример по разработке сайта был сознательно упрощен и весь состоит из критического пути. Так, мы не можем приступать к созданию главной страницы, не согласовав макет с заказчиком.
Задержка любой работы на критическом пути автоматически задерживает весь проект. Пока дизайнер не закончит - разработчик не может быть полезен на проекте.
Сжатие расписания всегда имеет целью ускорить выполнение работ по проекту.
Один из методов сжатия - crashing (добавление ресурсов). В нашем примере: задавшись целью ускорить работы, например, дизайнера, мы нанимаем дополнительных людей в команду. Это ускоряет выполнение работ, но повышает стоимость. Практическое использование данного метода состоит в корректировке списка ресурсов, а затем (на его основе) и расписания проекта (добавили нового дизайнера - назначьте ему часть работ и посмотрите, сократился ли критический путь).
Другой метод сжатия - «быстрый проход». Экстремальный метод, основанный на том, что работы критического пути начинают выполняться параллельно (мы начинаем разрабатывать шаблон сайта, не дождавшись согласования макета заказчиком, однако если тот не одобрит макет - нам придется многое переделать). Практическое использование метода сводится к отмене «предшественников» для определенных задач (которые вы планируете снять с критического пути), чтобы дать возможность команде приступить к ним по-раньше.
Используйте методы сжатия расписания, осознавайте риски, которые за ними стоят.
Анализ Монте -Карло - термин из теории игр. Этот вид анализа основан на задании исходных условий и дальнейшем моделировании возможных ситуаций. Осуществляется с использованием особого ПО (наше, «проектное» для этих целей не подходит, иногда пользуются электронными таблицами excel с преднастроенной логикой).
Урезание расписания
Сетевой анализ расписания иногда противопоставляют «урезанию» содержания работ (cutting scope). Порой, соблазн ПМ состоит в том, чтобы «выкинуть» некоторые работы из проекта, дабы получить более удобное расписание. Удержитесь от того, чтобы сделать это «тайком».
Помните, что проект всегда реализуется в интересах клиента. Если сетевой анализ не позволяет вам добиться реалистичного расписания к искомой дате без ущерба к конечному продукту - обсудите эту проблему со спонсором, предложите ему увеличить сроки проекта или позволить вам «выкинуть» определенные работы (по сути, вы просите переписать устав). Возможно, вам придется признать свою ошибку при грубом (ROM) планировании в фазе инициации. Не бойтесь этого. Не бойтесь поступать этично.
Итоговое расписание.
Результатом наших усилий должно стать реалистичное расписание. Такое, которое не противоречит уставу, обеспечено ресурсами, и по которому команда проекта действительно готова выполнить работы в соответствие с графиком.
Помните, расписание должно быть доступно заинтересованным лицам. Команде необходимо иметь доступ к подробной иерархии работ, спонсору же достаточно видеть основные вехи. Позаботьтесь о том, чтобы результаты планирования не остались у вас на компьютере – обеспечьте актуальной информацией всех, кто в ней нуждается любым приемлемым способом (письма, распечатки, и проч.).Шаг седьмой. Определяем предельную цену проекта (cost baseline)
Шаг 5 позволил нам оценить стоимость каждой работы (мы указали ставки и правила начисления заработной платы сотрудников, а также прочие расходы, а специализированное ПО отразило их общую стоимость).
Во время шага 6 мы создали расписание и ранее сделанные оценки стоимости автоматически скорректировались (возможно, какие-то работы придется выполнять сверхурочно или в выходные - общая сумма вознаграждения измениться, в соответствие с настроенными правилами).
Можно ли считать сумму себестоимости всех работ - бюджетом проекта? Ответ - нет, это лишь один из его элементов. Поясним данный тезис, дав определения двум новым терминам:
Предельная цена проекта (cost baseline) - это сумма себестоимости всех работ по проекту и стоимости всех резервов на непредвиденные случаи (contingency reserves). Определяется менеджером проекта.
Бюджет проекта - это сумма предельной цены проекта (cost baseline) и управленческих резервов (management reserves). Определяется спонсором.
Предельная цена проекта - это одна из граней тройственного ограничения. Неотъемлемым ее компонентом является стоимость резервов, которая определяется в ходе управления рисками. Об этом мы будем подробно говорить в главе X. Все, что нам доступно прямо сейчас - грубый прогноз такой стоимости резервов (ROM-оценка), используя который мы можем получить представление о «предельной цене».
Процесс планирования итеративен. Выполнив этап планирования реагирования на риски, мы сможем вернуться, в том числе, и к данному шагу, скорректировав свои оценки.
Бюджет проекта содержит «управленческие резервы» и поэтому является компетенцией спонсора, и нас абсолютно не интересует.
Подводя итог под уточнением треугольника
Эту лекцию мы начали словами, что собираемся «уточнить» каждую из граней проектного треугольника. Обратите внимание – сам треугольник мы не меняли (он заложен в устав, а устав – изменениям практически не подлежит).
Но мы создали элементы «плана управления проектом», которые «поясняют» нам и команде, как мы собираемся удержаться в треугольнике. Давайте заострим внимание, какие из них соответствуют каждой грани:
Грань «содержание»: Концепция + ИСР (WBS) + словарь (WBS Dictionary)
Грань «время»: расписание
Грань «стоимость»: предельная цена проекта (cost baseline)
Обратите внимание - планы никогда не должны противоречить уставу в ущерб интересам спонсора (т.е. можно сделать работы дешевле, но не дороже; быстрее, но не медленнее и т.п.).
Выходы:
ИСР (WBS)
Сетевая диаграмма
Перечень действий
Ресурсы, распределенные по работам
Оценки продолжительности работ и методики их расчета
Оценки стоимости работ и методики их расчета
Расписание
Предельная цена проекта
Запросы на изменения