Что значит содержание проекта
Содержание проектной работы
Содержание (план) проектной работы – это основные разделы, главы, параграфы работы, структурированные в порядке иерархии.
Содержание проектной работы
Содержание должно точно повторять название структурных элементов проектной работы. Кроме названия структурного элемента в содержании указывается страница, с которой начинается данный структурный элемент в тексте работы.
Как правильно оформить содержание проектной работы, а также скачать готовые листы с содержанием можно в данной статье: Оформление содержания проектной работы.
Составление содержания (плана) проектной работы
Разработка содержания является первым этапом написания проектной работы, именно от правильного названия глав и параграфов зависит, насколько полно будет раскрыта тема.
Перед составлением содержания (плана) проекта необходимо изучить литературу по теме работы, чтобы понимать, какие разделы следует включить в план, так как для раскрытия какого-либо вопроса по теме исследования должно быть достаточно информации, которую можно изучить, переработать и включить в свою работу. Если перед составлением плана не изучить литературу по теме, то при написании какого-либо параграфа можно столкнуться с недостаточным количеством информации для его раскрытия.
Также при составлении плана необходимо учитывать актуальность вопросов, которые могут быть изучены и проанализированы в ходе выполнения проектно-исследовательской работы.
Еще одной важной особенностью проектных работ является то, что большинство тем предполагает исследовательскую часть, что необходимо учитывать при составлении плана. Проект, в котором проведено исследование может состоять из 2-3 глав, проект без исследовательской части обычно не превышает 2 глав (подробнее с отличиями можно ознакомиться здесь: Основная часть проектной работы).
Требования к содержанию (плану) проектной работы
Название глав, параграфов и пунктов проектной работы не может состоять из одного слова, как и быть длинным (более 12-16 слов), названия указанных частей проекта не должны быть в вопросительной форме, все разделы проектной работы указываются только в утвердительной форме.
После составления содержания (плана) проекта, перед началом работы над исследованием можно предоставить план учителю на утверждение.
При составлении плана (содержания) проектной работы запрещается:
При использовании чужого плана при написании работы учитель имеет право не принять такую работу, т.к. использование чужого плана является плагиатом, в таком случае школьнику либо вновь придётся писать проект по той же теме (даже если он использовал только план, а вся работа была написана им самостоятельно), либо может быть выдана новая тема для выполнения проекта. Поэтому лучше потратить несколько дней на изучение литературы по теме исследования, затем составить содержание (план), утвердить его у учителя, после чего можно смело приступать к подготовке работы.
Процессы управления содержанием проекта
Когда компания начинает планировать проект с тем, чтобы разработать календарный план, ее руководству нужно детально учесть три основных аспекта, связанных с реализацией уникальной задачи: содержанием, ограничениями и рисками. Содержание проекта является его основным предметом и служит первым звеном процессов планирования. Решение этой задачи PM не может выполнить один и должен привлечь для этих целей всю свою команду, экспертов внутренних и внешних.
Правила определения состава работ
Настоящий вопрос мы начали рассматривать еще в материале, посвященном технологии создания плана проекта. Напомню лишь несколько моментов из той статьи. Для того чтобы хорошо спланировать решение проектной задачи, необходимо максимально полно создать список всех необходимых работ. Далее следует определить технологии исполнения общей задачи, ее последовательность и длительность. Данные шаги и определяют содержание инвестиционного проекта. Учет доступности ресурсов, внешних ограничений и рисков завершают подготовку к календарному планированию.
Планирование состава работ целесообразно выполнять, используя основные правила декомпозиции системы на элементы (обратите внимание на модель, размещенную ниже). Под декомпозицией будем в общем смысле понимать деление целого на связанные части. Как научный метод, декомпозиция берет начало из теории управления через задачный подход, использует структуру задачи как средства управления. Данный метод предполагает замену одной общей задачи (которой, собственно, и является проект) на ряд более мелких действий, выполнение которых дает результат материнской постановки (некой надсистемы).
Описание содержания проекта гармонично укладывается в логику декомпозиции. Она графически представляется в форме иерархической структуры. При этом, как некая логическая блок-схема структура может быть применена в отношении задач и работ в одинаковой степени. Разница состоит лишь в том, что в случае задач для разбиения мы оперируем статической категорией результата, а для работ делим на элементы соответствующую динамическую процессуальную категорию.
Управление содержанием проекта осуществляется в процессуальном контексте. И название мероприятия при грамотной его формулировке строится как отглагольное существительное с заданным результатом уникального проектного действия. В теории выделяют правила декомпозиции, имеющие следующие особенности, применительно к составу работ.
Процессы планирования и управления содержанием проекта
Управление содержанием проекта включает в себя собственно процессы планирования и процессы управления содержанием. На первый взгляд разница незначительная, однако мы отдаем себе отчет, что непосредственно исполняемые процедуры всегда несколько уже управленческого контекста за счет того, что управление наполняется описанными в регламентах процедурами функционального содержания (планирование, организация, контроль и т.д.). Предметная часть процессов планирования имеет в своем составе два процесса:
Мы рассматривали данные процессы в упомянутой выше статье. Краткое содержание проекта формируется в составе документа, именуемого планом по вехам. Развернутый состав работ находит отражение в ИСР, сетевой модели и, наконец, в расписании (календарном плане проекта). Управление данной категории глубоко описано в руководстве PMBOK, в котором рассматривается шесть процессов данного раздела управления проектами.
Три последних процесса мы рассмотрим в отдельных материалах сайта.
Институт PMI рассматривает вопрос с позиции содержания продукта (свойств и функций, характеризующих продукт) и содержания проекта. Под последним понимается непосредственный состав работ для получения результата с заданными функциями и свойствами. Планирование управления предметом в форме модели DFD представлено выше. Под сбором требований рассматривается комплексная процедура выявления, документирования запросов заинтересованных сторон, управления их потребностями и требованиями.
В ходе основного процесса управления предметной частью производится описание содержания проекта. И проект, и его продукты подробно описываются. Становятся ясными границы продуктов, услуг и результатов благодаря тому, что четко определяются требования, включаемые в предметную сущность, и требования, исключаемые из нее. Подробное описание содержания проекта играет важную роль для успеха всего мероприятия. Оно выполняется на основе сформулированных еще на этапе устава проекта целей, результатов, продуктов, ограничений и критериев успешности.
В настоящей статье мы рассмотрели основные моменты, определяющие подходы к работе по наполнению содержимого проектной реализации. После устава – это вторая краеугольная часть предварительной работы над таким серьезным мероприятием, как проектная задача. Содержание – зона прямой ответственности PM, и ему необходимо почувствовать, что все удалось предусмотреть, учесть все значимые для целей требования участников, что иерархия работ полноценна и лаконична. И если такое получается, то проект уже наполовину успешен.
Оформление оглавления (содержания)
Содержание проектной или исследовательской работы включает название глав и параграфов, которые точно соответствуют заголовкам в тексте проекта.
«Содержание» помещается на втором листе.
Все главы в «Содержании» начинаются с заглавной буквы.
В Содержании исследовательской работы пишутся названия глав и параграфов с указанием номеров страниц, с которых они начинаются. Последнее слово главы или параграфа соединяется с соответствующим ему номером страницы многоточием.
При оформлении заголовки ступеней одинакового уровня необходимо располагать друг под другом. Заголовки каждой последующей ступени смещаются на пять знаков вправо. Все они начинаются с заглавной буквы без точки в конце.
Главы и параграфы нумеруются по многоуровневой системе, то есть обозначаются цифровыми номерами, содержащими во всех ступенях номер своей рубрики и рубрики которой они подчинены(напр. 1.1, 1.2, и т.д.).
Разделы «Введение», «Заключение», «Список литературы» и «Приложения» не нумеруются.
Пример Содержания исследовательской работы:
Содержание
(Во введении обычно описывают: обоснование выбора темы работы, объект и предмет исследования, цель и задачи исследования, гипотезу, методы исследования, новизну исследовательской работы(при наличии), теоретическую и практическую(при наличии) значимость работы)
1. Подготовка к исследованию(например). 5
1.1 Исторические сведения. 5
1.3 Проведение анкетирования. 8
1.4 Техника безопасности. 9
(Правила техники безопасности описываются при необходимости)
2. Проведение исследования(например). 10
2.1 Первый этап исследования. 10
2.2 Второй этап исследования. 11
2.3 Заключительный этап исследования. 12
(Итоги исследовательской работы)
Список литературы. 14
Содержание исследовательского проекта оформляется очень аккуратно, со всеми выравниваниями.
Для того, чтобы в текстовом редакторе Microsoft Word сделать автособираемое оглавление, необходимо выполнить следующие действия.
1. Все заголовки, которые должны попасть в оглавление должны быть выполнены стилем «Заголовок 1» (после составления содержания можно будет поменять стиль оформления)
Что значит содержание проекта
Что такое «содержание проекта»?
Содержание проекта – описание работ, которые необходимо выполнить, чтобы получить продукт.
Для описания ВСЕХ необходимых работ по проекту нужно: определиться с требованиями и ожиданиями заказчика, разобраться, какие из них реально выполнимы, и что для этого понадобится.
Вернувшись к схеме в предыдущей главе вы можете заметить, что формирование концепции и создание ИСР (WBS) разделены еще двумя шагами из других областей знаний. В настоящей главе мы будем говорить о первых двух этапах создания содержания проекта (без ИСР).
Первый шаг (собрать и финализировать требования) неявно включает в себя два компонента: выявление заинтересованных лиц и собственно сбор требований. Об этом подробнее мы поговорим ниже.
Сбор требований
Собрать и финализировать требования – один из наиболее трудоемких и плохо формализуемых процессов. Все что известно сейчас – крупноуровневые требования, зафиксированные в уставе (вполне возможно, что они описаны несколькими предложениями). Наша задача конкретизировать их.
Чтобы справиться с ней – необходимо понять «кто?» является источником требований на проекте и «что?» конкретно он хочет получить по окончании работ.
Крайне опасно на данном этапе поддаться искушению «назначить» ответственным за все требования спонсора или заказчика. Кто бы ни подписал наш устав, а, в дальнейшем, и контракт на выполнение работ – он никогда не станет единоличным источником информации о требованиях.
Помните об этих двух тезисах. Сейчас вам предстоит одна из самых изнурительных задач в проектном управлении – выявлять заинтересованных лиц и собирать требования. Это не забота заказчика, это ваша забота. Пренебрегая ей – вы рискуете в лучшем случае «закрыть контракт формально, испортив отношения с заказчиком», а в худшем – получить на исходе проекта лавину претензий и придирок, которая утопит и вас и команду и сделает сдачу невозможной.
Выявляем заинтересованных лиц
Эту работы мы начали еще в фазу инициации (определив самых основных персон)? теперь работа продолжается. Результатом ее должен стать «реестр заинтересованных лиц». Пример такого документа приведен в Приложении 2.
Даже на небольшом проекте (с бюджетом в несколько миллионов рублей и командой порядка 10 человек) такой реестр должен содержать десятки (хорошо, если сотни) фамилий.
По какому принципу мы называем того или иного человека «заинтересованным лицом»?
Во-первых, это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда).
Во-вторых, заинтересованным лицом всегда являются конечные пользователи продукта (ни в коем случае не пренебрегайте их интересами в проекте!).
В третьих, не забывайте о боссах членов вашей команды.
В четвертых, помните о тех, кто напрямую не связан с проектом, но, так или иначе, оказывает на него влияние.
Последняя группа заинтересованных лиц – наиболее трудна к выявлению, однако порой вклад таких «серых кардиналов» очень велик. В качестве примера можно привести гипотетическую ситуацию, когда сын заказчика является в его глазах авторитетом в сфере информационных технологий и привлекается отцом к принятию принципиальных решений о внедряемых системах. При этом сын не является сотрудником ни одной из участвующих в проекте организаций (или, допустим, вообще еще школьник). Однако высказанные им советы имеют для папы больший вес, чем экспертные заключения его же сотрудников. Возможно, «добраться» до такого «заинтересованного лица» в ходе проекта вам и не удастся, но, знать (или, хотя бы, предполагать его существование) – достаточно важно.
Не бойтесь включать в реестр большое количество людей. Вы всегда сможете классифицировать их по «степени влияния на проект» позднее и работать только с самыми главными. Сейчас важнее никого не забыть (ибо влияние заинтересованного лица не проекте, со временем, может и возрасти).
Готовимся к сбору требований
По мере того, как список «заинтересованных лиц» формируется – мы приступаем к сбору требований.
Введем два термина: «требование» и «ожидание».
Ожидание – «умозрительная картинка будущего». Как правило – достаточно широкая. Пример ожидания: «чтобы производительность отдела возросла после внедрения ИТ-системы»; или «чтобы внедрение проекта не сильно сказалось на работе соседнего департамента». Ожидание нельзя включить в состав проекта, не преобразовав в требование.
Требование – конкретный, измеримый, проверяемый запрос заинтересованного лица. Пример требования: «система должна позволять проходить все пользовательские сценарии без использования манипулятора «мышь»».
Нам предстоит выбрать один или несколько методов «вытягивания» из заинтересованных лиц их ожиданий и требований (разумеется, нас в меньшей степени волнует наша собственная команда, и куда больше – представители заказчика и всевозможные стоящие за ним и над ним «серые кардиналы»).
Выбирая методы, необходимо тщательно взвесить наши потребности в информации и способности второй стороны ее предоставить.
Интервью – является одним из самых надежных методов, он же – самый трудозатратный. Непосредственное общение позволяет собрать наиболее полную и достоверную информацию, а также установить конструктивный рабочий контакт с собеседником. Главный минус – трудозатраты (вам придется тратить свое и чужое время в больших количествах). Кроме того – с некоторыми заинтересованными лицами общение может оказаться невозможным по причине их «статусности» (так, не всегда возможно уговорить топ-менеджмент компании-заказчика уделить вам часок-другой на очной встрече, даже если это в интересах проекта).
Опросники – это хороший способ быстро собрать информацию с множества людей (к тому же предоставив им вводить информацию в удобное для них время). Увы, у метода масса недостатков, главные из которых: «однобокость» собранной информации, высокая вероятность формального подхода к заполнению анкет (по принципу «чтобы отстали»).
Мозговой штурм – весьма условно можно назвать «коллективным интервью». Проведенный по определенным правилам, мозговой штурм может оказаться крайне эффективным. Однако помните, что некоторым людям трудно общаться даже в небольших коллективах – чтобы они не «отмалчивались» и не стеснялись в высказываниях, развивайте навыки ведения подобных мероприятий.
Прототипирование – это прекрасный способ собрать или уточнить требования. Под прототипом мы можем понимать любой понятный вашему собеседнику образ продукта (будь то картинка, макет или какой-либо аналог). Прототипирование удобно сочетать с другими техниками (например, интервью); главное не ограничиваться только им, дабы не упустить существенные моменты, не реализованные в прототипе, но важные для продукта.
К сбору требований мы приступаем, определившись с методами и вооружившись реестром заинтересованных лиц.
Сбор требований ПМ ведет не в одиночку, а совместно с командой. Собственно команда окончательно будет сформирована чуть позже, но на данном этапе нам уже пригодятся помощники (надеюсь, вы добавили соответствующую запись в устав и заблаговременно предупредили «хозяина ресурсов» о ваших потребностях).
Если в вашей компании есть специалисты по сбору и описанию требований (например, аналитики), тогда львиную долю забот в этой области можно переложить на них. Это очень неплохой сценарий, ибо требования являются самой сложной и трудоемкой для описания «гранью треугольника».
Однако, даже делегируя свои хлопоты – не выключайтесь из процесса и помните, что каждый день кто-то из членов команды (не обязательно аналитик) сталкивается с пожеланиями заинтересованных лиц, которые не были учтены раньше. Организуйте работу так, чтобы каждый ваш сотрудник в любой момент имел доступ к перечню выявленных требований – мог бы его просмотреть и дополнить.
Прежде чем отправиться к заинтересованным лицам (или отправить туда коллектив аналитиков) – определитесь, как будут храниться собранные требования. Совершенно не обязательно после каждого интервью или мозгового штурма рисовать схемы в определенной нотации. Если вы считаете, что достаточно будет текстовых описаний и произвольных картинок «от руки» – возможно, вы правы. Главное, договоритесь заранее, как будете фиксировать собранные требования со всеми участниками процесса.
После того, как процесс запущен, и требования стали поступать – не забывайте фиксировать их. Возможно, у вас на столе начинает расти пачка «организационных диаграмм», или электронная почта ежедневно пополняется подробными «отчетами об обследовании» и «отчетами об интервью». Все они окажутся весьма полезны в дальнейшем – при выполнении работ, при необходимости уточнить задачу.
Матрица позволяет фиксировать – когда обнаружено требование, кто автор (кто высказал), насколько данное требование важно (приоритетно). Также в матрицу целесообразно добавлять информацию о том, было ли требование выполнено в ходе реализации проекта, и не отменил ли его сам автор.
Обратите внимание – осуществляя сбор требований и заполняя матрицу, мы не пытаемся с ходу принять решение, «беремся ли мы за их реализацию в данном проекте, или нет». Проще говоря – собираем «все, что есть» (в рамках разумного, конечно). На этом этапе заинтересованным лицам не дается никаких обещаний. Мы лишь собираем их требования и ожидания (последние также превращая в требования с помощью авторов). И по мере того, как сбор требований завершается – приступаем к их «балансировке» (т.е. оценке того, что войдет в проект).
Когда остановиться? Проектные практики призывают нас собрать все требования, которые могут относиться к нашему проекту и только после этого двигаться дальше. Помните – «что нельзя спланировать, то нельзя и сделать».
Многие методологии разработки ПО обосновано считают строгую последовательность «спланировал» – «сделал» – «показал» – «сдал» (без демонстрации промежуточных результатов заинтересованным лицам и регулярной корректировки исходных планов) злом, повышающим риски провала.
Сбор требований в рамках начального планирования должен быть разумно-глубоким и максимально широким. Однако речь не идет о том, что на этом работа с требованиями должна прекратиться, а их список оказаться «фиксирован» до конца проекта. Работа с ожиданиями заказчика, накопление его согласия, корректировка планов в течение всего жизненного цикла проекта – основа проектного управления.
Иногда процесс первоначального сбора требований оказывается столько трудоемким и растянутым во времени, что целесообразно выделить его в отдельный проект. Если предполагаете большие трудозатраты – обсудите это со спонсором как можно раньше.
Балансировка требований – отбор требований, реализация которых предполагается в рамках проекта.
Процесс балансировки основан на сочетании интуиции и здравого смысла. Сперва, мы приоритезируем требования (выделяя наиболее значимые), а затем отбираем к реализации те из них, которые возможно уложить в рамки проектных ограничений (стоит помнить, что некоторые требования могут оказаться взаимосвязаны и включать или исключать их из треугольника можно только вместе).
На данном этапе мы обладаем лишь предварительными (грубыми) оценками стоимости и сроков проекта и пока не знаем точно, сколько «будут стоить» и длиться выбранные нами работы. В своих текущих оценках мы полагаемся на профессиональный опыт и чутье (свое и команды).
Позже, когда себестоимость и продолжительность работ будет оценена, мы сможем вернуться к этой части плана и скорректировать ее (возможно, от каких-то требований придется отказаться или пересмотреть). Однако важно понимать – процесс балансировки требований не должен противоречить уставу проекта. Если в уставе, скажем, прописано как одно из главных требований к продукту – скорость реакции интерфейса не более чем за 0,5 секунды, то мы не можем выбросить подобное требование из реестра (его невыполнение похоронит проект).
Технически балансировка может представлять простановку соответствующих отметок в матрице требований. Результаты сбора и балансировки можно утвердить у заинтересованных лиц проекта. Продумайте заранее – собираетесь ли вы получать подтверждение, в какой форме.
Обратите внимание еще на такой аспект: в нашем проекте мы не используем термин «техническое задание» (ТЗ)
Де-факто, матрица требований (а также схемы и описания, на которые она ссылается) как раз и представляет собой техническое задание. Однако на практике ТЗ – это статичный документ, который является неотъемлемой частью некоторых видов контрактов.
Именно статичность технического задания делает его неудобным для всех заинтересованных лиц проекта. Правильно организовав работу с требованиями, мы снижаем риск «промахнуться мимо ожиданий заказчика» (одновременно и прислушиваясь к ним весь проект, и отсекая невыполнимые). ТЗ может оказать обратный эффект.
Если вы все же столкнулись с необходимостью разработать ТЗ (или привлечены к его разработке) – адаптируйте информацию матрицы требований и позаботьтесь о том, чтобы в документе появились подробные описания процедуры уточнения требований (особенно формальной ее стороны). Приведем один из примеров подобных процедур: «Список используемых в системе справочников и классификаторов приведен в приложении №101. Данный список может изменяться в сторону его увеличения или сокращения, но не более чем на 10 позиций. При необходимости внести изменения в список справочников, заказчик уведомляет о такой необходимости исполнителя не позднее, чем до 1 декабря 2010 года и предоставляет описание… По результатам поведенного исполнителем анализа составляется акт на основе шаблона в приложении №102.»
Создаем концепцию (scope) проекта
Позади достаточно кропотливая работа по сбору и балансировке требований. Настало время определиться – какие действия по проекту необходимы, чтобы выполнить задуманное.
Обратите внимание, переходя от сбора требований к формированию scope – мы отходим от непосредственной работы с представителями заказчика и погружаемся в наши собственные заботы. Мы уже знаем, «что» от нас хотят и пытаемся разобраться «как» выполнить обещанное.
Таким образом, «концепция проекта» крайне важна для команды, но не для тех, чьи интересы команда обслуживает. Мы должны будем позаботиться о том, чтобы «концепция» была доступна нашим собственным сотрудникам, понята и принята ими, а вот привлекать к его согласованию заказчика – ни к чему.
Что вы ему дадите? Контракт? Не факт, что тот уже подписан, да и создается он, нередко, юристами для юристов.
Устав? Неплохая идея, но информация там слишком поверхностная – новый сотрудник вернется с новыми вопросами уже через несколько минут.
Матрица требований? Тоже неплохо, но она объясняет «что сделать», а не «как работать».
Наиболее правильным ответом является «концепция проекта». Данный документ будет содержать как общую информацию о проекте, так и ссылки на всевозможные требования и описания продукта, так что новый сотрудник, в зависимости от характера своих вопросов – сможет самостоятельно найти максимум информации без посторонней помощи.
Не менее важно и то, что «концепция» содержит описание «проектного подхода». Какие правила общения с заказчиком имеются на проекте? Как мы условились с командой проводить совещания? Где посмотреть, кто, за что отвечает на проекте? Как поступать при необходимости внести изменения в первоначальные требования или добавить новое?
Словом, концепция – краеугольный камень проекта. Сама по себе она может быть немногословна, но изобиловать ссылками на внешние документы (избегайте ненужного переписывания информации из документа в документ – ограничивайтесь ссылкой; это сэкономит ваши силы и многократно облегчит поддержание целостности и непротиворечивости информации).
Один из возможных шаблонов «концепции» приведен в Приложении 4. В представленном варианте концепция содержит ссылки практически на все планы, многие из которых нам еще предстоит создать в рамках дальнейшего планирования по проекту (данный шаблон будет еще одним напоминанием «не забыть запланировать все» или «явно указать, какие разделы проекта не планируются и по какой причине»).
Теперь любой член вашей команды (будь то разработчик, тестировщик или нанятый для консультаций эксперт) может максимально четко представить себе общую задачу и свою конкретную роль. Не забудьте сделать scope доступным и проинформировать о нем всех участников.
Глава VII. Определяем команду и планируем список покупок
Какие ресурсы потребуются?
Определившись с балансировкой требований и концепцией, приступаем к планированию ресурсов. Во время инициации мы поверхностно затрагивали эту тему со спонсором, теперь – стоит детально проработать этот вопрос. Есть ли в нашей компании доступные сотрудники с нужной квалификацией? Требуется ли специфичное оборудование? Может, для выполнения каких-то работ нужна особая лицензия?
Для проведения таких оценок нам потребуется хорошо спланированное содержание проекта (см. главу VI) и понимание доступных вам ресурсов и возможностей внутри организации (с этим могут помочь устав и общение со спонсором и хозяевами ресурсов).
Остановимся подробнее на оценке ресурсов.
Не всегда количество требуемых людей и их квалификацию ПМ в состоянии оценить самостоятельно. Обычно, это и не требуется. Необходим диалог с «хозяевами ресурсов». Главная ваша задача – донести суть выполняемых работ (тут уже начинают работать созданные нами документы – scope, матрица требований). Объясняйте, что придется сделать команде в рамках проекта и просите «хозяина ресурсов» помочь вам определиться с требуемыми для такой работы навыками и/или оборудованием.
Второй важный вопрос, помимо «кто нужен?» на проект – это «кто есть?» в вашей организации сейчас. Есть ли у нас сотрудники с требуемой квалификацией? Может, для выполнения работ потребуется специальная лицензия – а она у нас имеется? И так далее.
Обсудив принципиальное наличие ресурсов внутри организации – выясните, когда и на какой срок их можно задействовать в вашем проекте. Возможно, единственный подходящий специалист уже задействован на 120% до конца года? Или требуемый нам сервер можно получить в свое распоряжение лишь на пару дней? Все это может быть поводом для проведения закупок или привлечения подрядчиков.
Будем ли привлекать подрядчиков?
В подавляющем большинстве проектов для выполнения определенных работ можно привлечь стороннюю организацию (если это допускает специфика отрасли и нее противоречит специальным положениям контракта или политики компании).
Некоторые из «лучших проектных практик» рекомендуют такой подход:
Обратите внимание на пункт, касающийся «управляемости проекта». Иногда ее легче сохранить, поручив блок работ сторонней компании, чем контролировать множество собственных сотрудников, особенно если те, время от времени перемещаются на другие проекты, а к нам взамен приходят еще «не погруженные» в рабочий процесс люди.
Закупки на проекте требуют отдельного планирования и управления. В настоящей книге мы не будем рассматривать этот процесс подробно. Зачастую, ответственность за него распределена между ПМ- и специализированными службами (департаментом закупок, юридической службой, и т.д.), и мы будем исходить из предположения, что ваша ответственность ограничена решением «делать или покупать». Принятое решение (возможно, после согласования со спонсором) нужно транслировать соответствующим службам / отделам, уведомить их о сроках и в дальнейшем под их руководством предоставить требуемую для будущих контрактов информацию.
«Выбиваем» ресурсы
Итак, в ходе общения с хозяевами ресурсов мы определили: «Кто нужен?», «Кто есть?» и «Кого дают?» нам в рамках проекта. Мы также определились с целесообразностью привлечения подрядчиков. Теперь надо сформировать «список ресурсов».
Список ресурсов – совокупность договоренностей о выделении ресурсов на проект (обычно – в виде единого документа или набора электронных писем из корпоративной переписи).
Из определения выше видно, что список ресурсов не обязательно будет «официально подписанной бумагой». Во многих компаниях договариваться с «хозяевами ресурсов» принято неформально, а данный список – наш способ «напомнить» о прежних договоренностях.
Когда при формировании списка выясняется, что предоставить достаточные ресурсы на проект невозможно – обращайтесь к спонсору. Правильно написанный устав уполномочил вас не только общаться с «хозяевами ресурсов», но распределил ответственность между вами и спонсором.
Ваша «головная боль» ограничена уставом (где прописаны и ресурсы). За пределами устава – «голова болит» у спонсора. В чем бы ни была проблема с ресурсами – спонсор в состоянии ее решить (нанять дополнительных людей в отдел, разрешить привлечь подрядчиков, поменять приоритеты по распределению сотрудников между проектами «хозяевами ресурсов»). Альтернативой всегда является отмена проекта или переписывание устава (последнее во многом равносильно «закрытию проекта» и «открытию другого»). Однако, если вы не побеспокоитесь о выделении команды и техники – никто другой этого не сделает (помните, ответственность за проект в целом лежит на вас, умолчав о проблемах на ранних стадиях – вы неявно берете на себя вину за провал проекта в будущем).
Все сотрудники, которых вы включите в список ресурсов автоматически войдут в состав команды проекта. Кто-то из них, возможно, уже поработал в составе команды (поучаствовав в сборе требований).
Использование приведенных выше правил избавит вас от необходимости придерживаться строгих шаблонов (напомню, переговоры о ресурсах с «хозяевами» – не всегда формальный процесс), однако по необходимости можно воспользоваться документом, приведенным в Приложении 6.
Все, кто оказался в списке ресурсов, автоматически становятся членами команды проекта (не забудьте об этом на следующих этапах).