ЕНЕРГИЯ - Списание за оборудване, технологии и инженеринггодина VI, брой 4, 2014

Гъвкави методи за управление на проекти

Част 1: Принципи и предимства

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

Гъвкавите методи (ГМ) за разработване и управление на проекти се споменават главно във връзка със софтурните проекти, но корените им са по-дълбоки. Тези методи бяха разработени с цел да се понижи времето за изпълнение на проекта и да се понижи цената му. Периодът след 1970г. се характеризира с масовото навлизане на миникомпютрите, микропроцесорите, микромпютрите и емебедед системите в множество проекти. В търсене на ефективни методи за управление на милионите нови проекти, софтуените специалисти заимстваха идеи и практики от други области и създадоха нови методи за управление на проекти. Резултатите от този процес се оказаха приложими и извън разработката на софтуер и на ембедед системи и затова тази статия е посветена на тях.

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

Манифестът Agile
Документ, наречен накратко Agile Manifesto, е съставен през 2001г. от група опитни разработчици на софтуер. У нас материалът обикновено се нарича „Манифестът на Agile”. Документът е на разположение в Интернет на няколко езика и съдържа основните принципи на гъвкавата методология за разработка на софтуерни проекти. На базата на този манифест беше създадена група Agile Alliance, която се занимава с пропагандирането на принципите в манифеста. Част от принципите са спорни и дори съдържат елемент на вътрешно противоречие, но за щастие значителна част от тях отговарят и на практиките на свободното договаряне и приемане на проекта от страна на клиента, което под една или друга форма се практикува в много отрасли у нас, но се описва по по-различен начин.

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

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

Методи за управление на проекти
В Манифеста могат да бъдат намерени оригиналните принципи на Agile. Манифестът защитава така наречените леки (по-свободни) методи за разработка и управление (lightweight methods) на проекти и ги противопоставя на стриктните, твърди, тежки и по-бюрократични методи (heavyweight methods) за постигане на целите на проекта. Това противопоставяне е доста условно, защото има приложения, като например движещи се машини (автомобили, кораби самолети), комуникационни системи, АЕЦ и др., при които единственото решение са тежките методи, изискващи строг контрол, подробна документация и пълно тестване. Но от друга страна, за много офис приложения, интернет приложения, експериментални проекти, учебни приложения и др. подобни, тежките методи за управление биха оскъпили твърде много крайния продукт. Например, учебен макет или демонстрационен макет на АЕЦ, ТЕЦ или самолет може да покаже разумен брой дефекти, но в крайния продукт от проекта грешки не трябва да има. Ето защо, проектът за макета на някаква машина, съоръжение или сграда може да се разработи по-евтино по ГМ и след като се оценят правилно положителните и отрицателните му страни да се премине евентуално към истинската реализация по по-тежките и скъпи методи.

Към по-свободните методи за разработка и управление могат повече или по-малко да се причислят следните методи за изпълнение на проекти: Scrum, Crystal Clear, Extreme programming, Adaptive Software development, Feature Driven Development, Dynamic Systems Development Method и др. Част от основните им принципи са резюмирани в тази статия и могат да са от полза за много клиенти, ръководители и изпълнители на проекти.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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