Проектен план. Планиран проект. Основни понятия. Характеристики на планирането на ресурсите

Управлението на проекти е симбиоза от технология и изкуството да се решава уникална задача навреме в рамките на бюджета, предназначен за нея. За да бъде успешно завършен проектът, е необходимо да се постигне разбирателство между ръководството на фирмата и РМ как ще се изпълнява, от кого, кога и каква работа трябва да се извърши. Планът на проекта се разглежда не като един документ, а като цял набор от документирани решения, които отговарят на горните въпроси. Представям на вашето внимание прегледна статия, разглеждаща основите на технологията за планиране на проекти.

Същността на планирането на проекта

Планирането на проекта включва много взаимосвързани повторения, резултатът от които е единен генерален план. Под план на проекта по-нататък ще разбираме системата от планирани дейности, документирани в резултат на подготовката. Тази система се състои от параметри, свързани по специален начин, осигурявайки решаването на отделен проблем за разработка. Тези параметри се формират въз основа на редица функционални области на проектната дейност:

• съдържание;
• крайни срокове;
• цена;
• персонал;
• консумативи;
• комуникации;
• рискове и др.

Планът е ключов елемент от системата за управление на проекти. Ако министър-председателят е успял да изготви подробен набор от документи за планиране, тогава той има право да очаква гарантирано получаване на необходимите резултати в края на работата. За тази цел времето, ресурсите и други аспекти трябва да бъдат добре планирани. Докато не бъде разработен план, е невъзможно да се знае колко пари и време ще са необходими за изпълнение на уникална задача. Без план ръководителят практически е лишен от насоки за съответствие на работата с целите на проекта.

Трябва да разберете, че планирането не винаги в крайна сметка дава положителни резултати, но отрицателните заключения могат да донесат не по-малко, а понякога дори по-големи ползи. Във всеки случай ефективността на инвестирането на средства се увеличава и не се случва „разпиляване“ на спечелените печалби. Планирането на проекта полага основата за продуктивна работа и решава следните приложни проблеми.

1. Изяснете и детайлизирайте целите и резултатите от събитието.
2. Определете състава и обхвата на работата.
3. Оценете времевите рамки и бюджетните разходи.
4. Направете график и бюджет за основните фази или целия проект.
5. Направете прецизна оценка на изискванията за ресурси за всяка фаза или за цялата задача.
6. Направете план за ресурси.
7. Извършете оценка на риска и създайте план за реагиране на риска.
8. Обяснете подробностите за събитието на клиента.
9. Съгласете плана с основните участници.
10. Разпределете отговорността за работата и задачите между участниците.
11. Одобрете генералния план.
12. Изяснете плановете за взаимодействие и процедурите за управление на планирането.

Място на плана за управление на проекта на етапа от неговия жизнен цикъл. Източник: PMBOK 5 Guide

Мястото на процесите на планиране сред другите процеси на изпълнение на проекта. Източник: PMBOK 5 Guide

Планирането на проекта не може да бъде оставено във въздуха. То се предшества от иницииране, а резултатът от тези процеси е реалното изпълнение на проекта. И ние разпознаваме редица важни моменти при планирането:

• обвързани с конкретна времева точка от жизнения цикъл на уникална задача и с нейния значим период (вижте диаграмите, показани по-горе);
• итеративен – не приключва след написването на плановете, изисква редовно актуализиране до активната фаза на затваряне;
• изчерпателен - не се ограничава до един инструмент и включва редица инструменти и съответни изходни документи.

Разширен състав на процесите на планиране

Планът на проекта е различен от плана за управление на проекта и свързаните с него процеси на планиране. Както вече дефинирахме, в широк смисъл под план разбираме предварително планирана система от дейности, за които са установени редът на изпълнение, последователността и времето на работа. В тесен смисъл планът е документ, който отразява реда на планираните действия и сроковете за изпълнение. Планът за управление на проекта е резултат от регламентирани процедури (процеси) на планиране, при които принципът на контрол се поема от редовни, регламентирани процедури за създаване на планове като документи.

Дефиниции на основните концепции за планиране от PMI. Източник: PMBOK 5 Guide

Планирането на събития включва две групи процеси: процеси за директно разработване на планове и спомагателни процедури. Резултатът от блок за разработка е документ, наречен главен план на проекта. Той включва календарен план, бюджет на събитието и редица други документи. Съставът и съдържанието на работата, необходимите ресурси за изпълнението им определят последователността, продължителността и размера на разходите за тяхното производство.

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

Модел на процесите на планиране в управлението на проекти

Известно е, че според стандарта PMI, почти всеки раздел от ръководството PMBOK отделя цял блок за планиране. Въз основа на диаграмата, представена по-горе, това е съвсем естествено. Разделът PMBOK „Управление на интеграцията на проекти“ демонстрира най-цялостната картина на управлението на планирането и създаването на единен генерален план. По-долу е локален блок от диаграмата на потока от данни за разработване на план за управление на събития.

Блок от диаграма на потока от данни за разработване на план за управление на местни проекти

Визуалният блок, представен по-горе, е забележителен по редица причини. Базата от знания за управление на проекти, целият опит, натрупан в тази област, и разпоредбите са от съществено значение за успеха на планирането. Това важи и за стандарти, софтуер, организационна структура и култура, методи на управление, инфраструктура и т.н. Хартата е основно ръководство за планиране. Тези процеси са основата за интегриране в генералния план и предлагат следното като входни данни за разработването на окончателната му версия:

• планове за управление на параметрите на проекта;
• основни планове за съдържание, цена и график;
• актуализации на плана.

Етапи на разработване на календарен план

Както си спомняме, управлението на проекти е изградено върху „три стълба“: съдържанието на работата, ограниченията и рисковете. Ако един мениджър знае как да работи добре с тези три параметъра, то за него няма нерешими задачи. Нека да разгледаме разработването на календарен план от гледна точка на тези три позиции и да разделим този процес на етапи. Първият и вторият етап ще се отнасят към съдържанието на работата.

1. Етапът на определяне и писане на списъка с произведения. Доста често се допускат грешки поради факта, че не е възможно да се представи цялата работа наведнъж. За качествено определяне на състава на операциите е полезно да се използват основите на метода на последователно разлагане на работата.
2. Етап на определяне на изпълнението на проекта по отношение на последователността и продължителността на работата, които зависят от технологията за тяхното изпълнение. За да се създаде висококачествен резултат от този етап, вече споменатият метод за последователно разлагане на задачи и експертна оценка на продължителността на работа с помощта на методи като, например, мозъчна атака са много подходящи.
3. Определяне на ресурсната наличност. Събитието използва различни ресурси: финансови, материални, трудови, информационни и др. От гледна точка на финансовите ресурси е необходимо обвързването на работния график с графика за финансиране. Въвежда се понятието ограничен ресурс: уникални специалисти и капацитет. Това оставя отпечатък върху последователността и продължителността на работа.
4. Дефиниция на външните ограничения. Тези ограничения включват сезонност, технологични процеси за доставка на оборудване и различни външни събития. Ако вземем предвид примера за специални желания на клиента (за конкретни партньори) или външни събития (например времето за завършване на даден етап да съвпадне с национален празник), тогава такива събития се включват в събитието в формата на етапи.
5. Етапът на създаване на план за реагиране на риска. Анализираме проектните рискове и разработваме план за реагиране на основните заплахи. Като вземем предвид този план, ние финализираме графика.

Третият и четвъртият етап са свързани с позициите на ограниченията, петият етап - с рисковете. Две бази на реакция (активна и пасивна) определят момента на вземане на решение и включването му в плана на проекта. Активното реагиране означава, че включваме допълнителна работа в графика, насочена към минимизиране на рисковете. Това може да повлияе на времето за друга работа.

Като пример можем да разгледаме проект за въвеждане на нова услуга на пазара. Да кажем, че е идентифициран рискът от липсата му на търсене на пазара. След това, за да се сведе до минимум този риск, е необходимо да се проведат допълнителни изследвания и тази работа трябва да бъде включена в графика. Пасивното реагиране предполага формиране на допълнителни финансови резерви за идентифицирани рискове. Етапите на разработване на график могат да бъдат представени и в логическата последователност, представена по-долу.

Логическа последователност за разработване на график

Основни дейности по планиране на проекта

За да създаде генерален план, ръководителят на проекта прилага серия от итерации на планиране. По време на изпълнението на процесите на планиране се генерират важни инструментални и окончателни документи, които заедно съставят генералния план. Между тях:

• йерархична структура на работата (WBS);
• мрежова диаграма;
• план за управление на качеството;
• график на проекта;
• бюджет;
• организационна схема;
• рисков регистър;
• комуникационен план;
• генерален план на проекта.

Визуален модел на процесите на планиране на проекта

По-горе е даден модел на процесите на планиране за проектна задача. Пълният състав на процесите можете да видите на диаграмата. Процесите на планиране на басейни са свързани с почти всички области на управление на проекти. Много от посочените в модела процеси ще имат възможност да бъдат представени в отделни статии на нашия уебсайт. В този материал накратко се фокусираме върху основните процедури за планиране.

1. Процесът на определяне на обхвата се извършва, за да се изясни обхватът на проекта, границите с описание на неговия продукт. Процесът започва с изясняване на целите на събитието, връзката му със стратегията на компанията и разглеждане на различни подходи за изпълнение. Ръководителят на проекта трябва да е наясно каква работа е извън обхвата на проекта и какви са изискванията към продукта.
2. Процесът на определяне на обхвата на работата. Основите, положени в предишния процес, се развиват в пълния набор от необходими операции за постигане на успех. Тяхната структура и състав са свързани с основната цел на проекта. WBS е основният инструмент, използван от PM за решаване на проблема на настоящия процес.
3. Определяне на трудови взаимоотношения. Логическата последователност на работата е предмет и цел на този процес. Най-добрият инструмент и резултат от внедряването на процеса е мрежов модел (диаграма, графика), изграден и оптимизиран по метода PERT и CPM.
4. Процесът на оценка на продължителността на работа. Прогнозирането на продължителността на всяка дейност, включена в WBS и мрежовия модел, се извършва въз основа на различни подходи. Основните методи са методи за оценка, базирани на аналози, „отдолу нагоре“, от изпълнители, експертна и параметрична оценка.
5. Процесът на оценка на потребностите от ресурси. Целта на процеса е да се определи необходимото количество човешки ресурси, машинни ресурси и механизми. Ресурсите се делят на групи: възобновяеми, консумативни и финансови.
6. Процедура за разработване на календарен план. Процесът се провежда, за да се определят очакваните времеви рамки за отделната работа и проекта като цяло. Важен е въпросът за детайлизирането на плана. Дълбочината на неговата разработка трябва да е достатъчна, за да може ръководителят на проекта да контролира хода на работата и изпълнението на възложените задачи.
7. Разработване на генерален проект. Той комбинира всички резултати от работата по планирането на събитието в единен интеграционен документ на проекта.

В тази статия се запознахме с „максималния набор“ от процедури и документи, които създават план на проекта. В реалната практика, особено когато проектът е среден или малък по мащаб и е от обичаен характер, често не са необходими прекомерни усилия за планиране. В такива случаи можете да се ограничите до стандартни решения за планиране и непълен набор от документи. В същото време едва ли е възможно да се направи без основен документален филм в консолидиран план, а усилията, изразходвани за неговото разработване, се отплащат щедро.

Принципи на проектното планиране.

Структура на разбивката на работата.

Планиране на проекта по времеви параметри.

Методи за мрежово планиране на проекти.

Организация на работата по планиране на проекта.

Управление на проекти: учебник / A.G. Ивасенко, Я.И. Никонова, М.В. Каркавин. – Ростов n/a: Феникс, 2009. – С.177-212.

Мазур И.И. Управление на проекти: учебник. помагало за студенти, обучаващи се по специалността „Управление на организацията”/И.И. Мазур [и други]. ; редактиран от I.I. Мазура и В.Д. Шапиро, 6-то изд., изтрито. - М.: Издателство "Омега-Л", 2010. -960 с.

Същността на планирането е да се определят цели и начини за постигането им въз основа на формирането на набор от работи (събития, действия), които трябва да бъдат извършени, използването на методи и средства за изпълнение на тези работи, свързване на ресурсите, необходими за тяхното изпълнение , и координиране на действията на организациите, участващи в проекта.

Дейностите по разработване на план обхващат всички етапи от създаването и изпълнението на проекта. Започва с участието на ръководителя на проекта (ръководителя на проекта) в разработването на концепцията на проекта, продължава с избора на стратегически решения за проекта, както и в разработването на неговите детайли, включително подготовката на предложения за договори, договаряне , изпълнение на работата и завършва със завършването на проекта.

На етапа на планиране се определят всички необходими параметри за изпълнение на проекта:

продължителност за всеки от контролираните елементи на проекта,

необходимостта от трудови, материални, технически и финансови ресурси,

срокове за доставка на суровини, материали, компоненти и технологично оборудване,

срокове и обеми на участие на проектантски, строителни и други организации.

Процесите и процедурите за планиране на проекта трябва да гарантират осъществимостта на проекта в рамките на дадена времева рамка при минимални разходи, в рамките на стандартните разходи за ресурси и с подходящо качество.

В добре организиран проект, специфичен орган за управление трябва да отговаря за изпълнението на всяка цел: ръководителят на проекта за всички цели (мисия на проекта), отговорни изпълнители за частни цели и др. Тоест дървото на целите на проекта трябва да съвпада със структурата на организационната единица, отговорна за изпълнението на проекта. За тази цел се разработва така наречената матрица на отговорността, която определя функционалните отговорности на изпълнителите на проекта и уточнява набора от работи, за изпълнението на които те носят лична отговорност.

Колкото по-високо е нивото на ръководния орган, толкова по-обобщени, обобщени показатели той взема решения за управление на подчинените звена. С увеличаването на нивото на йерархията се увеличава интервалът от време между издаването на планираните задачи, наблюдението на тяхното изпълнение и т.н. Освен това в интервалите между моментите на намеса (издаване на планирани задачи, определяне на показатели и т.н.) звената от по-ниско ниво работят независимо, независимо от единиците на същото или съседно ниво. Независимото функциониране на отделите трябва да бъде осигурено от определени резерви от ресурси, които също трябва да бъдат планирани.

Основната цел на планирането е изграждането на модел за изпълнение на проекта. Необходимо е да се координират дейностите на участниците в проекта; помага да се определи редът, в който трябва да се извършва работата и т.н.

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

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

Самият процес на планиране не може да бъде напълно алгоритмизиран и автоматизиран, тъй като съдържа много несигурни параметри и често зависи от случайни фактори. Следователно вариантите на плана, предложени в резултат на планирането, могат да се различават, ако са разработени от различни екипи, чиито специалисти имат различни оценки за въздействието на външни фактори върху проекта.

ДА СЕ основни процеси планирането включва:

планиране и документиране на обхвата на проекта;

изготвяне на прогнози, оценка на разходите за ресурси, необходими за изпълнение на проекта;

дефиниране на работа, формиране на списък от конкретни работи, които осигуряват постигането на целите на проекта;

организация (последователност) на работа, идентифициране и документиране на технологични зависимости и ограничения за работа;

оценка на продължителността на работата, разходите за труд и други ресурси, необходими за извършване на отделни работи;

изчисляване на графика, анализ на технологичните зависимости на изпълнението на работата, продължителността на работа и изискванията за ресурси;

планиране на ресурсите, определяне какви ресурси (хора, оборудване, материали) и в какви количества ще са необходими за завършване на работата по проекта. Определяне в какъв срок може да бъде завършена работата, като се вземат предвид ограничените ресурси;

бюджетиране, обвързване на очакваните разходи с конкретни видове дейности;

създаване (разработване) на проектен план, събиране на резултатите от други процеси на планиране и комбинирането им в общ документ.

Помощни процеси изпълнявани според нуждите. Те включват:

планиране на качеството, определяне на стандарти за качество, подходящи за даден проект и намиране на начини за постигането им;

организационно планиране (дизайн), дефиниране, проучване, документиране и разпределение на проектни роли, отговорности и отношения на отчитане;

подбор на персонал, формиране на проектен екип на всички етапи от жизнения цикъл на проекта, набиране на необходимите човешки ресурси, включени в проекта и работещи в него;

планиране на комуникациите, определяне на информационните и комуникационни нужди на участниците в проекта: кой от каква информация се нуждае, кога и как трябва да му бъде доставена;

идентифициране и оценка на рисковете, определяне кой фактор на несигурност и до каква степен може да повлияе на напредъка на проекта, определяне на благоприятни и неблагоприятни сценарии за изпълнение на проекта, документиране на рисковете;

планиране на доставките, определяне какво, как, кога и с кого да се купува и доставя;

предложения за планиране, документиране на продуктовите изисквания и идентифициране на потенциални доставчици.

Определянето на нивата на планиране също е предмет на планиране и се извършва за всеки конкретен проект, като се вземат предвид неговите специфики, мащаб, география, времеви срокове и др.

По време на този процес се определят вида и броя на нивата на планиране, съответстващи на разпределените работни пакети за проекта, техните същностни и времеви връзки.

Плановете (графики, мрежи) като израз на резултатите от процесите на планиране трябва да формират заедно някаква пирамидална структура, която има свойствата на агрегиране на информация, диференцирана по нива на управление на информираността, ешелонирана по периоди на развитие (краткосрочни, средносрочни и дългосрочни -термин). Нивата на планиране и системата от планове трябва да бъдат изградени с помощта на принципите на обратната връзка, които осигуряват постоянно сравнение на планираните данни с действителните данни и имат голяма гъвкавост, уместност и ефективност.

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

Основен функции на планиранеса дадени по-долу.

Превръщане на нуждите в управляеми задачи.Първоначално проектът се появява под формата на изисквания, разработени и съгласувани с клиента. Целта на планирането е да представи тези изисквания като набор от отделни задачи, чието изпълнение може да се контролира.

Определяне на необходимите ресурси.Подробните планове ще определят броя на хората, необходимото оборудване и условията на работа, които ще са необходими за завършване на проекта.

Координация на екипната работа по проекта.Много често един проект се разделя на отделни задачи, които могат да се изпълняват паралелно. Плановете позволяват да се координират тези дейности, като се определя кой какво прави и кога.

Оценка на потенциалните рискове.Въпреки че някои рискове могат да бъдат идентифицирани по време на формулирането на изискванията, много други се откриват след извършване на подробно планиране. Познаването на съществуването на тези рискове ще ви позволи да ги забележите по-рано (ако се материализират) и да се подготвите да се справите с тях.

Аларма при възникване на проблеми.Отклонението от плана служи като сигнал, че са възникнали проблеми. Плановете не са догма, която трябва да се следва безусловно. За ръководителя на проекта е по-вероятно те да бъдат предположения и база за сравнение. Ако проектът не отговаря на очакванията, планът трябва да бъде съответно коригиран.

Група процеси на планиранепоказано на фиг. 3.10. Тези процеси могат да се повтарят и да са част от итеративна процедура, докато се постигне определен резултат. Например, ако първоначалната дата на завършване на проекта не е приемлива, тогава необходимите ресурси, цената и понякога съдържанието на проекта (Групи процеси за управление на проекти

Група за процес на планиране

Управление на човешките ресурси на проекта

Планиране

Разработване на план за управление на човешките ресурси технически ресурси

Определение

Управление на времето на проекта

Определение

операции

контрол

интегритет

Планиране на доставките

Управление на разходите по проекта^

Оценка на разходите

Управление на качеството на проекта

Разработване на план за управление на проекта

Определение

последователности

операции

оперативни ресурси

Планиране

качество

продължителност

операции

развитие

графици

Управление на риска на проекта

Определение

Планиране

управление

риск

Провеждане на качествен анализ на риска

Провеждане на количествен анализ на риска

Планиране на отговорите на рисковете

Ориз. ЗЛО. Процеси на планиране

проектът трябва да се промени. Резултатът в този случай ще бъде договорените срокове, обеми, набор от ресурси, бюджет и съдържание на проекта, съответстващи на неговите цели.

Планирането е необходима предпоставка за изпълнението на всяка задача, дори и на най-простата. Неадекватното планиране може да доведе до провал на проекта или неподходящи резултати в средата на проекта.

Планирането под една или друга форма се извършва през цялото времетраене на проекта. В началото на жизнения цикъл на проекта обикновено се разработва неофициален първоначален план - груба представа за това какво ще трябва да се постигне, ако проектът трябва да бъде изпълнен. Решението за избор на проект до голяма степен се основава на оценките на този първоначален план. Официалното и подробно планиране на проекта започва след вземане на решението за изпълнението му.

Планирането се състои от изготвяне на следното планове:

• изпълнение на работата, включително оценка на нейната трудоемкост и срокове;
• управление на съдържанието и обема на работата;
• организационна структура;
• управление на конфигурацията;
• управление на качеството;
• управление на риска;
• управление на доставките;
• заверка на резултатите от проектирането и дейността на изпълнителите.

Определение нива на планиранесъщо е предмет на планиране и се извършва за всеки конкретен проект, като се отчитат неговите специфики, мащаб, география, времеви срокове и др. По време на този процес се определят вида и броя на нивата на планиране, съответстващи на разпределените работни пакети за проекта, техните същностни и времеви връзки.

Плановете (графики, мрежи) като израз на резултатите от процесите на планиране трябва да формират като съвкупност някаква пирамидална структура, която има свойствата да агрегира информация, диференцирана по нива на управление на осведомеността, и трябва да бъде ешелонирана по периоди на развитие (краткосрочни, средносрочни -срочни и дългосрочни). Нивата на планиране и системата от планове трябва да бъдат изградени на принципите на обратната връзка, осигуряващи постоянно сравнение на планираните данни с действителните данни, те трябва да имат голяма гъвкавост, релевантност и ефективност.

Мрежовите планове са консолидирани поради факта, че общият мрежов план се състои от много частни мрежови планове. Във всеки от тези частни планове се определя най-дългият път. След това тези пътища се поставят на мястото на отделни части от мрежата. С помощта на такова постепенно агрегиране се получават многостепенни мрежови планове (фиг. 3.11). Обикновено има концептуален план, стратегически план за изпълнение на проекта и тактически (подробни, оперативни) планове.

Мрежов план с множество проекти (за висше ръководство)

Ниво 1

Ниво 3

Ниво 2

Мрежов план с ключови етапи (крайни етапи)

Подробен мрежов план

Ориз. 3.11.Многослойни мрежови планове

Идейно планиране, което води до идеен план, е процес на разработване на основна проектна документация, технически изисквания, оценки, подробни графици, процедури за контрол и управление. Концептуалното планиране се извършва в началото на жизнения цикъл на проекта.

Стратегическо планиранее процес на разработване на стратегически, интегрирани, дългосрочни планове.

Подробно (оперативно, тактическо) планиранесвързани с разработването на тактически, подробни планове (графици), базирани на йерархичната структура на работа (WBS) за оперативно управление

на ниво отговорни изпълнители.

Планирайте управление на съдържанието.Една от често срещаните „болести“ на софтуерните проекти е т.нар "пълзящ фичъризъм"когато първо се добави навес за съхранение на градински инструменти към първоначално проектирания щанд за любимо куче, а след това къща на няколко етажа за неговия собственик. И те се опитват да изградят всичко това на една и съща основа и от същите материали. Този подход причини смъртта на много проекти за разработка на софтуер. Следователно, веднага щом беше възможно да се стабилизира и договори WBS - йерархичната структура на работа, е необходимо да се разработи план за управление на обхвата на проекта, за което трябва:

• идентифицирайте източниците на заявки за промяна;
• установява процедура за анализ, оценка и одобрение/отхвърляне на промени в съдържанието;
• определя процедурата за документиране на промените в съдържанието;
• определя процедурата за информиране за промени в съдържанието. Първата задача, която трябва да бъде решена при анализиране на заявка

за промени - идентифицирайте обекти на промяна: изисквания, архитектура, структури от данни, изходни кодове, тестови скриптове, потребителска документация и т.н. След това е необходимо да проектирате и опишете подробно промените във всички идентифицирани обекти. И накрая, трябва да се оценят разходите за извършване на тези промени, тестване на промените и тяхното въздействие върху графика на проекта. Тази работа ще изисква време, прекарано, а понякога и значително, от различни специалисти: анализатори, дизайнери, разработчици, тестери, както и ръководител на проекта, и следователно трябва да се вземе предвид в плана.

Планиране на организационната структура.Организационна структура- това е съгласувано и одобрено разпределение на ролите, отговорностите и целите на ключовите участници в проекта. Тя задължително трябва да включва следното:

• система от работни взаимоотношения между работните групи по проекта;
• система за отчетност;
• оценки на напредъка на проекта;
• система за вземане на решения.

Трябва да се помни, че организационната структура на проекта е „жив“ организъм. Той започва да се оформя на етапа на планиране и трябва да се променя с напредването на проекта. Нестабилността на организационната структура (честите промени на изпълнителите) може да се превърне в сериозен проблем при управлението на проекта, тъй като има заместваща цена, която се определя от момента, в който нов участник влезе в контекста на проекта.

Планиране за управление на конфигурацията.Един от важните процеси за производство на софтуер е управление на конфигурацията.Повече от една книга е написана за тази област на знанието. Тук ще говорим само за това как трябва да се планира тази работа. Планът за управление на конфигурацията на проекта трябва да включва:

• работа за осигуряване на единно хранилище за цялата проектна документация и разработения програмен код, гарантирайки безопасността и възстановяването на информацията за проекта след повреда;
• работа по настройка на работни станции и сървъри, използвани от членовете на екипа на проекта;
• работата, необходима за организиране на сглобяването на междинни версии на системата, както и нейната окончателна версия.

Тази работа обикновено се извършва от инженер по конфигурация. Ако проектът е малък, тогава тази роля може да бъде допълнителна за някой от програмистите или ръководителя на проекта. „Разпространяването“ на тази работа сред всички участници в проекта е, първо, неефективно. Инсталирането и конфигурирането на среди за разработка, като бази данни и сървъри на приложения, изисква специфични компетенции и познания за конкретни версии на продукта. Ако всички разработчици трябва да научат тези умения, това ще отнеме твърде много време за работа. Второ, „разпространението“ на работата по управление на конфигурацията може да доведе до колективна безотговорност, когато никой не знае защо „проектът няма да работи“ и как да се „върне“ към предишната версия.

Управлението на конфигурацията може да стане много по-сложно, ако екипът на проекта, успоредно с разработването на функционалност на нов продукт, трябва да поддържа няколко версии на този продукт, които преди това са били инсталирани от различни клиенти, но цялата тази работа трябва да се вземе предвид в проекта план.

Планиране на управлението на качеството.Друга основна област на познание в софтуерното инженерство е осигуряването на качество. Има различни мнения относно това какво е качество на софтуера и как то да се гарантира ефективно. Нека се ограничим до твърдението, че осигуряването на качеството е доста важна работа, която трябва да бъде планирана предварително и извършена през целия софтуерен проект, а не само по време на тестовете за приемане.

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

План за управление на качествототрябва да включва следната работа:

• обективна проверка на съответствието на програмните продукти и технологичните операции с приложимите стандарти, процедури и изисквания;
• установяване на отклонения в качеството, установяване на причините за тях, прилагане на мерки за отстраняването им, както и наблюдение на изпълнението на предприетите мерки и тяхната ефективност;
• предоставяне на висшето ръководство на независима информация за несъответствия, които не са разрешени на ниво проект.

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

Йерархична структура на работа(WBS) е ориентирана към резултатите разбивка на работата, извършена от екипа на проекта за постигане на целите на проекта и необходимите резултати. С негова помощ се структурира и определя цялото съдържание на проекта. Всяко следващо ниво на йерархията отразява по-подробна дефиниция на елементите на проекта. Основата за разработване на WBS е концепцията на проекта, която дефинира проектните продукти и техните основни характеристики. WBS гарантира, че цялата работа, необходима за постигане на целите на проекта, е идентифицирана. Много проекти се провалят не защото нямат план, а защото планът пренебрегва важна работа като тестване и коригиране на грешки, както и проектни продукти като потребителска документация. Следователно, ако WBS е компилиран правилно, тогава всяка работа, която не е включена в него, не може да се счита за работа по проекта. WBS разделя проекта на подпроекти, работни пакети и подпакети. Всяко следващо ниво на декомпозиция осигурява последователно детайлизиране на съдържанието на проекта, което дава възможност да се оцени времето и обхвата на работата. WBS трябва да включва всички междинни и крайни продукти.

Има различни начини да разбиете работата по даден проект. Например, GOST 19.102-77 предвижда водопад подходи определя следното етапи на развитие на софтуерната система.

• 1) технически спецификации;
• 2) идеен проект;
• 3) технически проект;
• 4) работен проект;
• 5) изпълнение.

Ако следваме този стандарт, тогава тези дизайнерски продукти трябва да бъдат на първо ниво на WBS. Ако трябваше да разработим автоматизирана система за управление на ядрен реактор или пилотиран космически кораб, тогава трябваше да се направи точно това. При разработването на комерсиален софтуер обаче този подход е неефективен.

Съвременният процес на разработка на комерсиален софтуер трябва да бъде постепенен. Това означава, че на най-горното ниво на декомпозицията на проекта трябва да има продуктите на проекта, а на следващото ниво - компонентите, от които се състоят тези продукти. Компонентите могат допълнително да бъдат разложени на „характеристики“ – функциите, които трябва да изпълняват.

Изолирането на компонентите, които изграждат софтуерния продукт, е елемент от дизайна на високо ниво, който трябва да се извърши по време на фазата на планиране на проекта, без да се чака да бъдат разработени всички функционални изисквания за софтуера, който се разработва. Компонентите могат да бъдат както приложни подсистеми, така и инфраструктурни или ядрени, например подсистема за удостоверяване и сигурност, библиотека от визуални компоненти на графичен интерфейс (GUI). Когато изготвяте основен работен план, не трябва да се стремите да детайлизирате цялата WBS работа, достатъчни са 3-5 нива.

В контекста на детайлизирането термините "задачи" и "работа" често се използват взаимозаменяемо. Все пак е по-правилно да се каже, че задачата определя постигането на междинен резултат, а работата е набор от действия за постигане на тези резултати. Тъй като всяка задача изисква определена работа, която трябва да бъде извършена при определени ограничения, със сигурност можем да говорим за несъмнено „картографиране“ на задачите към работа и обратно. Това е причината за взаимозаменяемостта на термините в ежедневието. В същото време разбирането на разликите между тези понятия ви позволява да усетите нюансите на изгледа на процеса на създаване на продукт и следователно жизнения цикъл на проектите, включително проектите на софтуерни системи.

Като цяло можем да говорим за детайл: „програма – проект - задачата е операцията.”На фиг. Фигура 3.12 предоставя пример за такова детайлизиране (показани са само операции със задачи А).

Ориз. 3.12.Пример за използване на термини: програма, проект, задача, операция

Всеки елемент от такава структура е свързан с ограничения и други значими характеристики и данни. Уместността се отнася до тяхната необходимост или полезност за вземане на решения. Дълбочината на детайлност и нивото на прилагане на определени термини зависят от конкретния проект, културата на управление, стандартите за жизнения цикъл, спецификата и мащаба на проекта, както и други фактори, уникални както за конкретна организация, така и за конкретен проект.

Личната отговорност трябва да бъде установена за всички части на проекта (подпроекти и работни пакети). За всеки работен пакет крайният резултат трябва да бъде ясно дефиниран. Оценките за работа и проект трябва да бъдат съгласувани с ключови членове на екипа, ръководството на фирмата изпълнител и, ако е необходимо, с клиента. В резултат на споразумение членовете на екипа поемат задължения за изпълнение на проекта, а ръководството поема отговорност за осигуряване на проекта с необходимите ресурси.

WBS е един от основните инструменти (средства) в механизма за управление на проекти, с помощта на който се измерва степента на постигане на резултатите от проекта. Най-важната му функция е да гарантира, че всички участници в проекта разбират и разбират как ще бъде направен проектът. Впоследствие базовата линия ще служи като ръководство за сравнение с текущото изпълнение на проекта, за да се идентифицират отклонения.

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

Основната трудност при алгоритмичното моделиране на цената на проекта е зависимостта на оценката на разходите от свойствата и параметрите на крайния продукт. В ранния етап на проекта е невъзможно да се определят точно тези свойства и параметри. Има много методи за оценка на цената на софтуера, които трябва да се използват паралелно. Ако получените резултати са много различни, това означава, че за анализа е използвана недостатъчна или неподходяща информация. Цена на софтуерен продуктчесто се определя предварително за целите на договарянето, което води до последващо настройване на функционалността на системата към тези, които биха съответствали на тази цена.

Известен модел за оценка на разходите по проекта B. Boema SOSOMO взема предвид характеристиките на дизайна, свойствата на създавания софтуер, хардуера и възможностите на персонала. Този модел включва и инструменти за определяне на продължителността на работа по даден проект. Времето, необходимо за изпълнение на работата, не зависи пряко от броя на специалистите, наети за проекта. Добавянето на повече хора към проект, който изостава от графика, може допълнително да забави завършването му.

Алгоритмичните модели за изчисляване на разходите за проекти се използват за управление на софтуерни проекти, тъй като поддържат анализ на количествени параметри. Тези модели ви позволяват да оцените приноса на всеки отделен параметър към общата цена на проекта и да направите обективно (макар и неимунизирано срещу грешки) сравнение на тези параметри.

Оценка на разходите по проекта- една от най-важните работи по проекта, която се определя въз основа на цената на отделните части на проекта, условията за изпълнение на работата, действителния персонал на изпълнителите, използваните методи и инструменти. Цената на проекта включва и разходите за изпълнение на проекта, т.е. компютри, софтуер, пространство, мебели, телефони, модеми и много други. Освен това понякога трябва да се вземат предвид допълнителни разходи (например сигурност). Допълнителните разходи за проекта включват закупуване на система за тестване, CABE система и др. Основната оценка в проекта е оценка на разходите за проекта, изразено в човекодни работа на изпълнителите по проекта. Тази оценка се извършва на ранен етап от управлението и планирането.

Общата стойност на проекта се определя от опитни специалисти с грешка до 10%. Оценката на разходите може да бъде отгоре надолу, отдолу нагоре или въз основа на цената на предварително произведен дизайн. Експертите правят песимистични, оптимистични и реалистични оценки, като интервюират всички членове на работната група и коригират всяка оценка, за да получат най-правдоподобната. В някои работни групи песимистичните и оптимистичните оценки могат да бъдат много различни.

Алгоритмични методи за оценка на разходите по проектапоказват връзките между разходите по проекта и факторите, които им влияят.

Съществуват различни емпирични подходи за оценка на цената на даден проект, например цената на даден проект се предлага да се определи с помощта на формулата

ЦЕНА = (a + b?)t(X),

където 5 е определена оценка на размера на системата; а, б, в -емпирични константи; X - вектор на разходните фактори с размерност Пет -регулаторен мултипликатор, базиран на факторите на разходите.

По-опростена оценка, получена експериментално, се изразява, както следва:

РАЗХОД = 5,255 0,91 .

Тези оценки са получени от анализ на проекти, при които програмите варират по размер от 4000 до 467 000 реда код и са написани на 28 различни езика за програмиране на 66 компютъра. За разработката са изразходвани от 12 до 11 758 човекомесеца. Известни са и други техники за емпирично моделиране.

Първите модели използваха ценови показатели, отчитаха персонала и свойствата на проекта, продукта и околната среда. Моделите включват оценка на три етапа на управление на проекта. На първия етап се изгражда прототип за високорискови задачи (потребителски интерфейс, софтуер, система за взаимодействие, внедряване и т.н.) и се оценяват разходите (например броя на таблиците в базата данни, екрани и формуляри за отчети и т.н. .). На втория етап се оценяват разходите за проектиране и изпълнение на функционалните точки на проекта, отразени в изискванията на проекта. В третия етап оценката се отнася до завършения проект, когато размерът на системата може да бъде определен по отношение на завършени програмни линии и други фактори.

Основният модел за експериментална оценка на разходите по проекта днес е следното уравнение:

РАЗХОД = bS c m(X),

Където bS c -първична оценка, която се коригира с помощта на вектор на разходите t(X)и отчитане на броя стари и нови обекти; с- параметър, който варира от нула до единица за първия етап на проекта и от 1,01 до 1,26 за останалите етапи.

При формализиран подход оценката на проекта се основава на използването на LOC и FP показатели.

Конструктивен модел на разходите(SOSOMO - Constructive cost model), предложен от B. Boehm, съчетава най-известните формализирани техники за оценка на проекта - Оценки на LOC(LOC - Lines of Code), които се базират на броя редове програмен код. В процеса на прилагане на този модел се формират предварителни оценки, които позволяват да се представят на клиента правилни изисквания за цената и разходите за разработване на софтуера, както и да се осигури възможност за изготвяне на софтуерен план.

Функционално ориентирани FP метрикиВместо да изчисляват LOC резултати, те индиректно измерват софтуерния продукт. Не се взема предвид размерът, а функционалността или полезността на продукта. Автор на тази метрика е А. Албрехт. Определянето на функционалния размер се състои от няколко стъпки и започва с идентифициране на функциите, които приложението трябва да има. Международната група потребители на функционални точки (IFPUG) публикува критерии, по които се определят функциите на приложението. При изчисляване на метриката FP се използват пет информационни характеристики: брой външни входове; брой външни изходи (изходите означават отчети, екрани, разпечатки, съобщения за грешки); брой външни заявки; брой вътрешни логически файлове; брой външни интерфейсни файлове.

След като съберете цялата необходима информация, продължете към изчисляване на показатели -определи брой указатели на функции FP (функционални точки) по определена формула, където стойностите на коефициентите за корекция на входната сложност (всеки коефициент може да приеме следните стойности: 0 - няма влияние; 1 - произволно; 2 - малко; 3 - средно; 4 - важни; 5 - основни) се избират емпирично в резултат на отговорите на 14 въпроса, които характеризират системните параметри на приложението.

Методът се състои в измерване на всички възможности на дадено приложение еднакво за всеки проект и изразяване на размера на приложението като едно число, което след това може да се използва за оценка на броя редове код, цената и времето на проекта. На негова основа се формират показатели за производителност, качество и др.

Предимствофункционално-ориентирани метрики е, че те не зависят от езика за програмиране и се изчисляват лесно на всеки етап от проекта.

недостатъцифункционално-ориентирана метрика - резултатите се основават на субективни данни, а не на директни измервания. Освен това трябва да имате определени умения, за да прилагате този метод точно и последователно.

Използвайки стандартни таблици, оценките на FP могат лесно да бъдат преобразувани в оценки на LOC, т.е. От функционалния размер изчислете броя на редовете код. Резултатите от преобразуването обаче зависят от езика за програмиране, използван за внедряване на софтуера (например в Java една единица функционален размер е равна на 53 реда изходен код). От своя страна броят на редовете код ви позволява да определите общата интензивност на труда, изразена в човеко-месеци, и графика на проекта.

При извършване на оценка има две възможни употреби на LOC и FP данни: като променливи за оценка, които определят размера на всеки продуктов елемент, или като показатели, събрани по време на работа по минали проекти и включени в базата на показателите на компанията.

Пример 3.1. Нека разгледаме процедурата за извършване на процедурата за оценка на работата въз основа на метриката ShS.

Етап 1. Областта на предназначение на проектирания продукт е разделена на редица функции /i,/2,/3, всяка от които може да бъде

оценявайте индивидуално

Етап 2. За всяка функция/планировчик генерира най-доброто LOC n, най-лошото YUS Xи вероятно ЮС Воценки. В процеса на формиране на прогнози се използват експериментални данни от метричната база или интуитивни идеи на проектанта. Обхватът на възможните оценки съответства на предоставената степен на несигурност.

Етап 3. За всяка функция f t очакваната стойност на оценката се определя:

YUS I + YUS X + 4 BOC^охладител = 6"

yus.

Етап 4. Стойността на AL-производителността на развитието на функцията се изчислява в съответствие с едно от трите правила.

Правило Л.За всички функции се взема една и съща стойност, равна на средната производителност на PR avg, взета от метричната база, т.е.

PR, = PR ср.; / = 1, 2, ..., П.

Правило Б.За i-тата функция се изчислява персонализирана стойност на производителност въз основа на показателя за средна производителност:

ys sr

MS готин ’

Където YUS Сряда -среден LOC резултат, взет от метричната база (съответства на средната производителност).

Правило Б.За /та функция регулируемата стойност на производителността се изчислява с помощта на избрания аналог (взет от метричната база):

BOSDnI

Г-жо Ожи

Използването на правило А в следващите етапи осигурява минимална точност с максимална простота на изчисленията. Правило B ви позволява да постигнете максимална точност с максимална сложност на изчисленията.

сцена 5. Общата оценка на разходите (човек-месец) за проекта се изчислява, ако се използва правило A:

ако се използва правило B или C:

б1у ^ож/

Етап 6. Общата оценка на разходите по проекта се изчислява, ако се използва правило A или B:

COST = UDST avg? yuS 0Zh/ ;

ако се използва правило B:

COST = UDST an/ ^YUS 0Zh/ ,

където UDST avg е метрика на средната цена на един ред програмен код; UDST an, - метрика на цената на една аналогова линия (и двете метрики са взети от метричната база).

Разработване на график на проекта.След определяне на трудоемкостта на работата е необходимо да се определи графикът за тяхното изпълнение и общата времева рамка за проекта, т.е. съставете работен график за проекта Основен графикпредставлява одобрен график с посочени времеви фази на проекта, етапи и елементи от йерархичната структура на работа.

Основният график в повечето случаи е елемент от договора с клиента. Контролни точки (основни етапи)служат като точки за анализиране на статуса на проекта и вземане на решения във формат „§o или po1 §o“, следователно те трябва да демонстрират видимо статуса на проекта. Има определени изисквания за избор и формиране на контролни точки, например контролната точка „Проектирането е завършена“ е неинформативна, методът на последователно доставяне се счита за по-ефективен подход: горепосочената контролна точка е формулирана във формата „; Тестването на изисквания 1, 3, 5 и 7 е завършено.“

Ако работите не са свързани помежду си, тогава всяка от тях може да бъде започната и завършена, когато ни е удобно; цялата работа може да се извършва паралелно, като в този случай минималната продължителност на проекта е равна на продължителността на най-дългата работа. На практика обаче обикновено има зависимости между работните места, които могат да бъдат „твърди“, например „анализ - проектиране - кодиране - тестване - документиране“ на конкретна функция, или „меки“, които могат да бъдат преразгледани или омекотени, например , последователното изпълнение на задачи от конкретен изпълнител може да бъде пренасрочено на друг изпълнител и вместо да разработвате основен софтуер, който трябва да предшества разработването на приложен софтуер, можете да създадете „пънове“, които емулират работата му.

Разработването на работен план със срокове за изпълнението им може да се извърши чрез метода на критичния път CPM или метода за анализ и оценка на PERT програми. Планът на проекта е представен на етапи: „Планиране“, „Проектиране“, „Кодиране“, „Тестване“ и „Поддръжка“. Планирането се отнася до определянето на спецификациите, бюджета и графика, както и разработването на цялостния план на проекта.

IN метод на критичен път на проекта(Критичен път) се използва най-дългата верига от работа в проекта. Увеличаването на продължителността на всяка работа в тази верига води до увеличаване на продължителността на целия проект. Винаги има поне един критичен път в проекта, но може да има няколко. Критичният път може да се промени по време на изпълнението на проекта.

Когато изпълнява проект, мениджърът трябва първо да обърне внимание на изпълнението на задачите по критичния път и да наблюдава появата на други критични пътища. Има практическа препоръка: на критичния път трябва да има работа с нетвърди връзки, които винаги могат да бъдат пренасрочени, ако има заплаха от пропускане на срокове. Работният график е съставен съгласно диаграмата, показана на фиг. 3.13.

График на изискванията

към проекта

Ориз. 3.13.Стъпки за планиране на работа по проект

Когато планирате за метод за анализ и оценка на програмата PERT събитие или дата в плана е крайъгълен камък (контролна точка) по пътя на отделната работа по проекта и се използва за показване/маркиране на статуса на завършеност на определени работи. В контекста на даден проект мениджърите използват етапи, за да идентифицират важни междинни резултати, които трябва да бъдат постигнати по време на проекта.

Често се нарича последователността от етапи, определени от мениджъра етапен план (по събития).Определянето на план за постигане на съответните етапи създава график, базиран на етапи.

На етапа на планиране може да се използва и мрежова разбивка на работата и диаграма на Гант.

Разбивка на мрежата на работа(SPP) е йерархична структура за разлагане на проектни задачи на подзадачи. На по-ниско ниво има работи, детайлизирани в елементи на дейност в мрежовия модел на системата от работещи системи.

Мрежовият модел ви позволява да разделите работата на основни компоненти и подкомпоненти, да определите области на дейност, насочени към постигане на сложни цели, да разпределите отговорните за изпълнението на индивидуалната работа по проекта и да завършите отчетите, обобщаващи информацията за резултатите от проекта.

Работният план трябва да отразява основните етапи на работа и необходимото състояние на работа на всеки етап, разделянето на всяка работа на отделни задачи, както и връзките между работите, интервалите от време за завършване на всяка дейност, времето за начало и завършване на работата. Работният план включва различни видове демонстрации на проектни функции, подсистеми, надеждност, защитно оборудване и др. Документите на плана включват също набор от ръководства и техники за извършване на определени операции, поддържане на системни връзки с други подсистеми и др.

Работният план под формата на WBS графика съдържа фази (етапи), стъпки и дейности, включително началните и крайните дейности на процеса (фиг. 3.14).

Фаза И

Стъпка 1 Стъпка 2

Ориз. 3.14.Графика на плана на проекта стъпка по стъпка

Друга форма на визуално представяне на работния план може да бъде мрежова диаграма,посочени под формата на графика, в чиито върхове са разположени работни елементи, а върху дъгите - броят дни (седмици), необходими за завършването им (фиг. 3.15). Тези знаци се използват за задаване на времето за изпълнение на процеса. Дъга, напускаща инициала

Ориз. 3.15.

връх и влизане в крайния връх, съответства на клеймото за време „нула“.

Графиката може да съдържа циклични пътища. Графиката се използва за анализиране на критични пътища, т.е. определят продължителността на всеки процес.

Разработването на график се състои от определяне на началната точка (събитие или набор от събития, настъпили преди началото на стъпка на процеса и за които е описан набор от условия, включително началото на процеса), продължителност (интервалът от време, през който процесът трябва да завърши успешно изпълнението си), краен срок (дата, до която процесът приключва изцяло или частично изпълнението си) и крайна точка на процеса (контролната точка, в която клиентът проверява качеството на получените резултати от процеса).

Най-очевидният начин за представяне на основния график е Диаграма на Гант- линейна диаграма, където проектните задачи са представени по периоди от време, включително начална и крайна дата за изпълнението им, като се вземат предвид възможните забавяния. В тази диаграма планираните дейности (елементи от структурата на разбивката на работата) са изброени от лявата страна, датите са показани в горната част, а продължителността на дейността е показана като хоризонтални ленти от началната дата на дадена дейност до датата на нейното завършване (Фигура 3.16).

Ориз. 3.16. Диаграма на Гант

Група за процес на изпълнение

Групи процеси за управление на проекти

Управление на качеството на проекта

Сигурност

качество

Съвременният софтуер за управление на проекти осигурява визуализация на структурата на графиката на проекта и работните процеси, например широко известната и доста често използвана в практиката система за управление на проекти. Това позволява на разработчика или ръководителя на проекта да види как се извършват различните дейности - последователно или паралелно и дали са на критичния път.

Планирането на проекти е част от управлението на проекти, която включва използването на графици, като например диаграма на Гант, за планиране на работата и след това докладване на напредъка в среда на проект.

Първоначално е определен обхватът на проекта, но не са определени подходящите методи за завършване на проекта. След тази стъпка работните единици, необходими за завършване на работата, трябва да бъдат изброени и групирани в структура на разбивка на работата (WBS), като се вземе предвид продължителността на различните задачи. Планирането на проекти често се използва за организиране на различни области на проект, включително планове на проекти, натоварвания и управление на екипи и хора. Логическите зависимости между задачите се определят с помощта на мрежова активна диаграма, която позволява да се определи критичният път.

Планирането на проекта е несигурно и трябва да бъде направено преди проектът действително да започне. Поради това продължителността на задачите често се оценява чрез средно претеглена стойност от оптимистични, нормални и песимистични оценки. Това добавя „буфери“ при планирането, за да можете да предвидите забавяния (като продължителни одобрения) при изпълнението на проекта. Времето в график може да се изчисли с помощта на софтуер за управление на проекти. Необходимите ресурси и разходи за всяка дейност могат да бъдат оценени, като се даде общата стойност на проекта. На този етап графикът на проекта може да бъде оптимизиран, за да се постигне подходящ баланс между използването на ресурси и продължителността на проекта, в съответствие с целите на проекта. След като графикът на проекта бъде създаден и одобрен, той се превръща в базов (или целеви) график. Напредъкът на интегрирания проект ще бъде измерван спрямо основен график по време на продължителността на проекта. Анализирането на напредъка спрямо базов график се нарича метод на спечелената стойност.

Входни данни към фазата на планиране на проекта са хартата на проекта и предложенията за концепция. Резултатите от етапа на планиране на проекта включват изискванията на проекта, графика на проекта и плана за управление на проекта.

Планирането на проекти може да се извърши ръчно, но често се използват софтуерни пакети за управление на проекти. Такива комплекси включват професионалния Oracle Primavera и по-ежедневния MS Project.

В областта на управлението на проекти графикът на проекта е списък с етапи на проекта, задачи и резултати, обикновено с очаквана начална и крайна дата. Тези елементи често се оценяват спрямо друга информация, включена в графика на проекта, като разпределение на ресурси, бюджет, продължителност на задачите, връзки, зависимости и планирани събития. Графикът на проекта обикновено се използва при планиране и управление на портфолио от проекти. Елементите на графика могат да бъдат тясно свързани със структурата на разбивката на работата (WBS) чрез ключови събития, отчет за работа или данни за договор.

Характеристики на проектните графици

В много индустрии, като инженерство и строителство, разработването и поддържането на график на проекта е отговорност на вътрешен плановик или екип от плановици, в зависимост от размера на проекта. Методите на планиране са добре разработени и се прилагат последователно във всички отрасли.

Трябва да се отбележи, че управлението на проекти не се ограничава до индустрията; обикновен човек може да използва този метод, за да организира собствения си живот. Някои програми за управление на проекти, шаблони, диаграми и примери ще помогнат на потребителите да създадат своя график.

Методи за разработване на графици на проекти

Преди да създадете график, трябва да разработите структура за разбивка на работата (WBS), да оцените разходите за всяка задача и да определите списък с ресурси. Ако тези компоненти на графика не са налични, те могат да бъдат създадени с помощта на методи за оценка, базирани на консенсус, като например метода Delphi. Причината за това е, че самият график е прогноза: всеки ден от графика е прогнозен и освен ако тези дати не се основават на действителния опит на хората, които ще свършат работата, тогава графикът няма да е точен.

За да бъде графикът на проекта реалистичен, трябва да бъдат изпълнени следните критерии:

• Графикът трябва постоянно (за предпочитане ежеседмично) да се актуализира (актуализира).
• EAS стойността (резултат при завършване) трябва да бъде равна на базовата стойност.
• Натоварването трябва да бъде правилно разпределено между членовете на екипа (като се вземат предвид почивните дни).

ВЪВЕДЕНИЕ

Управлението на проекти е свързано с изготвяне на план и проследяване на напредъка на работата по него. Съответно, колкото по-добър е планът на проекта, толкова по-точно е изготвен, толкова по-лесно е след това да се извърши проектантска работа и успешно да се завърши проектът.

За да планирате добре, трябва преди всичко да имате добра представа какво представлява един проект и от какви елементи се състои планът му.

Дейността на всяка организация е да извършва операции и проекти. И двете имат много общо, например, те се изпълняват от хора, за които се отделят ограничени ресурси.

Основната разлика между операциите и проектите е, че операциите са текущи и се повтарят, докато проектите са временни и уникални. Въз основа на това проектът се определя като временно усилие, предприето за създаване на уникален продукт или услуга. „Временен“ означава, че всеки проект има конкретна начална и крайна дата. Когато говорим за уникален продукт или услуга, имаме предвид, че той е забележимо различен от подобни продукти или услуги.

Уникалността на всеки проект създава трудности при планирането му, тъй като често е трудно да се предвиди как реално ще бъдат постигнати резултатите. Следователно резултатът от проектната дейност е не само продукт или услуга, но и научени уроци, тоест опит, който се използва в бъдеще при планиране и изпълнение на следващи проекти.

ПЛАНИРАН ПРОЕКТ

Етапът на планиране е един от най-важните. На този етап се определят задачите, бюджетът и времевата рамка на проекта. Доста често планирането се разбира само като планиране на работа, като се забравя за управлението на ресурсите, бюджетирането и т.н.

Пълната техника на планиране включва следните стъпки:

• 1) Дефиниране на целите на проекта и тяхното описание. Доста често проектите започват без ясна цел.
• 2) Определяне на технологичните етапи. За проекта трябва да бъде избрана технология за изпълнение, която определя етапите на развитие на проекта. Една от типичните грешки при планирането е несъответствието между плана и технологичния цикъл.
• 3) За технологичните етапи е необходимо да се определи списък от задачи, да се посочат техните взаимоотношения (последователност) и прогнозна продължителност (в зависимост от предоставените ресурси).
• 4) Необходимо е да се договорят ресурсите, отпуснати за проекта. Трябва да се отбележи, че всички ресурси на компанията трябва да се разпределят централно. Доста често възниква грешка при планиране поради факта, че някои оскъдни ресурси се използват едновременно в два различни проекта едновременно.
• 5) Ако определяте цените на ресурсите, бюджетът може да се получи и автоматично. Една от типичните грешки е, че бюджетът се определя без да се обръща внимание на прогнозната стойност на проекта.
• 6) Писмената задача, бюджетът и работният график формират официалния документ „План на проекта“. Доста често, преди началото на даден проект, някои от тези документи липсват; последствията от това ще бъдат обсъдени по-долу.

Следователно за успеха на планирането на проекта редица фактори са важни и трябва да бъдат взети под внимание:

• · клас на задачите за решаване, брой копия на готовия продукт, вид работа (разработка, развитие, поддръжка);
• · избор на работен план (модел на жизнения цикъл), като се вземе предвид сложността на проекта и възможностите на екипа за разработка;
• · опит в предметната област и средствата за автоматизация на разработката;
• · оборудване на разработчиците със средства за автоматизация и хардуерна и софтуерна база;
• · ниво на изискванията на клиента за срокове и качество на работа.

В един добре организиран проект, специфичен орган за управление трябва да отговаря за изпълнението на всяка цел: ръководителят на проекта, за всички цели (мисия на проекта), отговорни изпълнители за частни цели и т.н. Това означава, че дървото на целите на проекта трябва съвпадат със структурата на организационната единица, отговорна за изпълнението на проекта. За тази цел се разработва така наречената матрица на отговорността, която определя функционалните отговорности на изпълнителите на проекта и уточнява набора от работи, за изпълнението на които те носят лична отговорност.

Основната цел на планирането е изграждането на модел за изпълнение на проекта.

Често срещани грешки при планирането

Планиране с грешни цели.Всеки проект по своето съдържание има за цел да реши проблем, да задоволи конкретна потребност и т.н. В зависимост от това се формулират определени конкретни цели. Ако проблемът е неясен и не е ясно формулиран, тогава можете да срещнете често срещана грешка, когато се вземе правилното решение, но не се знае точно какъв е проблемът.

За да се избегне подобна ситуация, е необходимо да се открие реалната основа за работата: запис - за предпочитане документиран - описание на проблемите и нуждите, които трябва да бъдат решени след завършване на проекта; установете как решението на конкретни проблеми се отразява в описанието на целите и задачите на проекта. Едва след това можете да започнете да планирате.

Планиране въз основа на непълни данни.Подобна ситуация е типична, когато е необходимо да се планира работа, чието начало и вероятно самият факт на нейното изпълнение зависи от резултатите от тестовите тестове или успехите / неуспехите в предишни фази.

Подобна ситуация често възниква при проекти за разработване и адаптиране на информационни системи. Клиентът има непреодолимо желание да получи готов инструмент възможно най-бързо. Той обаче има само бегла представа за възможностите на софтуера, който е избрал и какво иска да автоматизира. От друга страна, доставчиците на софтуер знаят много малко за действителните процеси на управление (функционални, информационни, организационни структури) в организацията на клиента. И едва когато започнат да изпълняват проекта, започва процесът на взаимно информиране и обучение. Изясняването на твърдението води до значително, понякога няколко пъти, увеличаване на обема на работата и промяна в нейните цели и състав.

Планирането се извършва с участието само на проектанти.Такава организация на планиране може да доведе до значителни загуби поради липса на отчитане на важни фактори. По правило се забравят привидно незначителни подробности или обстоятелства, неспазването на които обаче може да доведе до колосални загуби. Следователно отговорните за конкретната работа по проекта, отговорните за финансирането на проекта, за доставките и т.н. също трябва да бъдат включени в планирането. Да не говорим за психологическите аспекти на изпълнението на плана, в чието разработване не са участвали конкретни изпълнители.

Планиране без отчитане на предишен опит.Дори и при най-добри оценки, без използване на предишен опит в изпълнението на подобни проекти, могат да се допуснат сериозни грешки при планирането.

Планиране на ресурси без отчитане на тяхната наличност.Това се отнася на първо място за трудови ресурси с определена квалификация и способност да пристигнат в определено време на дадено място, за да извършат работата по проекта. Друг проблем е, ако една и съща група специалисти е планирана в няколко едновременно работещи проекта.

Планиране без отчитане на мотивацията.По правило за работа по проекти се привличат изпълнители от функционални отдели, които имат свои собствени. Мениджмънт, техните собствени цели и конкретни задачи и, разбира се, собствената им форма на възнаграждение, която обикновено няма нищо общо с целите и задачите на проекта. Следователно изпълнителите не чувстват отговорността и важността на работата по проекта без подходящо стимулиране за резултатите от дейността си. Но ръководителят на проекта не е надарен с достатъчно права да стимулира изпълнителите и не може да формира бюджет за финансови стимули въз основа на резултатите от проекта.

Планиране с прекомерни детайли.Когато един проект е планиран твърде подробно , възникват проблеми при анализирането, планирането и следенето на състоянието му - например какво е изпълнено и какво е забавянето. Освен това е трудно да се управлява ефективно голям брой ресурси, да се определят времеви закъснения, да се оценяват разходите и да се разработват реалистични графици, приемливи за целите на управлението. Прекомерната детайлност при отчитане на факторите води до необходимостта от разрешаване на огромен брой конфликти, до чести промени, до необходимостта от постоянна координация с други проекти, изпълнявани едновременно. Въпреки това, прекомерното уголемяване може също да доведе до проблеми със загуба на управляемост. Необходима е златна среда, когато проектът планира само онези параметри, които могат и трябва да бъдат контролирани.

Какво ви трябва, за да избегнете грешки при планирането (няколко съвета):

• · за проекта трябва да бъде формулиран списък от проблеми за решаване;
• · основната цел на проекта (мисията) трябва да бъде доведена до знанието на всички участници;
• · трябва да се идентифицират рисковете и, ако е възможно, да се изключат инциденти;
• · необходимо е да се гарантира, че стратегията на проекта може да бъде изпълнена и удовлетворява ограниченията на бюджета, времето и обхвата (извършен е PCTS анализ на осъществимостта: P - Изпълнение, C - Разходи, T - Време, S - Обхват. Разходите са функция на ниво изпълнение P, време T и съдържание, обхват на работа S);
• · наличието на положителни резултати от анализа на „плюсовете и минусите“ на изпълнението на проекта (извършен е анализ на силовото поле, който се състои от описание и количествена оценка на факторите, които могат да улеснят и възпрепятстват изпълнението на проекта );
• · крайният резултат трябва да е ясен за всички членове на екипа по проекта;
• · индикаторите за оценка на резултатите от проектните дейности трябва да оценяват състоянието на нещата с необходимата точност. Препоръчително е да се разработят вътрешни скали за оценка на изпълнението по вид работа.

Определяне на целите на проекта

Поставянето на цели първо означава, че проектът трябва да започне с формулиране на целта. В този случай целта трябва да бъде записана писмено под формата на измерими показатели.

Етап на формулиране на проблема, този етап се осъществява по договор за консултация, т.е. етапното плащане е базирано на времето. Поради несигурността на задачата е невъзможно предварително да се планира нейната цена. Цената на сцената е приблизително равна на 10% от цената на цялата работа.

Основният продукт на етапа е документът „Изложение на проблема“ (Визия на продукта).

Този документ трябва да дефинира целта на проекта и да включва списък с ключови изисквания без подробно обяснение. Важен критерий: въпреки липсата на подробно описание, списъкът трябва да подлежи на статистическа оценка на интензивността на труда със стандартно отклонение (риск) в приемлив диапазон.

Въз основа на „Изложение на проблема“ се изисква да се състави документ „Икономическа обосновка“.

Този документ трябва да съдържа статистическа оценка на трудоемкостта (цената) на работата. От друга страна трябва да се направи анализ на икономическия ефект от внедряването.

Анализът използва статистически данни за трудоемкостта (ефективността) на подобни проекти. При липсата на тази статистика грешките в оценките са неизбежни, в този случай трябва да се опитате да получите статистика въз основа на резултатите от разработването/демонстрацията на прототипи.

Оценката на риска трябва да бъде изразена под формата на възможно превишение на интензивността на труда (песимистична оценка). Именно от тази оценка трябва да се изхожда при определяне на общата трудоемкост (цена) на продукта.

В резултат на това имаме неясно формулирана задача в „Изложение на проблема“ и оценка на разходите в „Икономическа обосновка“. Рисковете от неясни изисквания трябва да бъдат покрити от песимистична оценка. Условие за завършване на етапа: подписване от страните на „Изявление на проблема“ и „Икономическа обосновка“.

Управление и планиране на ресурсите

ресурс за планиране на проекти за управление

Управлението на ресурсите е една от основните подсистеми на управлението на проекти. Включва процесите на планиране, закупуване, доставка, разпределение, отчитане и контрол на ресурси, обикновено труд и логистика. Задачата на управлението на ресурсите е да осигури тяхното оптимално използване за постигане на крайната цел - формирането на резултат от проекта с планирани показатели.

Материално-техническите ресурси са суровини, материали, конструкции, компоненти, енергийни ресурси, технологични ресурси и др.

Трудови ресурси са тези, които пряко работят с материално-техническите ресурси.

Управлението на материалните ресурси на проекта по същество започва на прединвестиционната фаза по време на разработването на предпроектно проучване; по време на фазата на планиране се разработват потребностите от ресурси и възможността за тяхното осигуряване. Практиката показва, че във всеки един момент ресурсите са ограничени и затова основните задачи на управлението на ресурсите са:

• 1. Оптимално планиране на ресурсите
• 2. Управление на логистиката, включително:
  • · управление на доставките на ресурси;
  • · управление на разпределението на ресурсите.

Концепцията за ресурси е взаимосвързана с концепцията за „работа“, тъй като ресурсите не са свързани с проекта като цяло, а с конкретна работа, извършена в планирана последователност, съответстваща на работния график на проекта.

Планиране и организиране на покупки и доставки -първият етап в управлението на ресурсите на проекта. Състои се от етапи, включително избор на доставчици, пускане на поръчки и наблюдение на доставките.

На етапа на планиране се извършва балансиран анализ на работните пакети и изразходваните ресурси, като се вземат предвид ограниченията и тяхното прогнозно разпределение въз основа на графиците за търсене на ресурси. Планирането на ресурсите на проекта е основа за определяне на нуждите от ресурси във времето и определяне на възможността за осигуряване на ресурси за сключване на договори за закупуване на ресурси, планиране на доставката на ресурси, както и основа за разпределяне на вече закупени ресурси за работа по проекта.

Като основен компонент на управлението на проекти, планирането на ресурсите включва редица компоненти, включително:

• · разработване и балансиран анализ на работни пакети и ресурси, насочени към постигане на целите на проекта;
• · разработване на система за разпределение на ресурсите и назначаване на отговорни изпълнители;
• · наблюдение на напредъка на работата - сравняване на планираните работни параметри с действителните и разработване на коригиращи действия.

Ресурсите действат като осигуряващи компоненти на работата по проекта, включително изпълнители, енергия, материали, оборудване и т.н. Съответно, функцията за изискване на ресурси може да бъде свързана с всяка работа и изискванията за ресурси за проекта като цяло могат да бъдат изчислени с помощта на методи за планиране и методите за съпоставяне могат да осигурят нужди за съответствие, наличност или способност за предоставяне на ресурси.

По принцип, когато се планира да се изпълнят изискванията за ресурси за дейности по проекта, трябва да се вземе предвид едно общо правило: общият обем на изискванията за всеки тип ресурс във всеки момент от жизнения цикъл на проекта трябва да бъде не по-малък от общия обем наличността на този ресурс в този момент, като се вземат предвид резервите.

Оценка на разходите по проекта

В зависимост от етапа на жизнения цикъл на проекта и целта на оценката се използват различни видове и методи за оценка на стойността на проекта. В зависимост от целите на оценките, точността на тези оценки също варира. Няма да разглеждаме подробно, но трябва да имате предвид, че най-голямата грешка възниква, разбира се, в етапа на стабилизиране на проекта, когато се идентифицират и коригират грешки в определена версия; възможно е и всичко това е направено не е изпълнено правилно (в технологичен смисъл), но това вече се отнася до неграмотен дизайн.

За да оцените цената на даден проект, трябва да знаете цената на ресурсите, които съставляват проекта, времето, необходимо за завършване на работата, и цената на тази работа.

По този начин оценката на разходите започва с определяне на ресурсите и работната структура на проекта. Тези задачи се решават като част от планирането на проекта и модулът за оценка на разходите трябва да получи резултатите от този процес. Стойността на проекта се определя от ресурситенеобходими за извършване на работата.