Гъвкави методи за управление на проекти
Адаптация и перспективи
Гъвкавите методи за управление Agile намират много широка широката област на приложение. Те предлагат по-голяма свобода на действие и по този начин откриват редица възможности, в сравнение с конвенционалните методи. В същото време незадължителното изискване на строга дисциплина и изчерпателна документация крият потенциални опасности.
В статията ще се спрем на основните принципи на гъвкавите методи, за възможностите за тяхната адаптация, перспективите и областите за тяхното приложение. Читателите ще научат за ползите и потенциалните трудности от тяхното използване.
Текст: списание Енергия
снимка: EDF
Нека започнем с това, че при гъвкавите методи (ГМ) за управление на проекти липсват точни инструкции за тяхното прилагане. Няма списък от детайлни методи, методики и правила. „Всичко е добро, при условие че го приеме клиента” изглежда да е основния неформален принцип, обединяващ всички ГМ. Фирмите и екипите, деклариращи, че работят по тези методи, могат да имат доста различни практики, обявени от тях за най-добрите практики и отнасящи се само за тях. Ако зададете на десетина души въпроса какво според тях са гъвкавите методи и практики и как ги прилагат, може да получите доста различни отговори, които е трудно да се сравнят по ефективност.
Липсата на ефективен контрол върху версиите на продукта (проекта) може лесно да доведе до непоправим хаос в проекта. На практика всяка седмица или на всеки от 2 до 6 седмици на клиента се изпраща някаква версия на продукта, а това може да не е желаната практика от него. Оценката на извършената работа през седмицата може и да отнеме повече от предвиденото време и това проваля плана за следващата седмица.
Концентрирането върху близки цели (еднодневни, едноседмични, месечни) е добре за елементарен проект, разбит на много малки и много ясни задачи, което не винаги е възможно. Това е добро и за кратък курс на обучение. В индустрията обаче, проектите продължават много месеци и дори години. Късото планиране води до изпускане от поглед на целия проект с крайните му цели, заради вглеждане в отделни детайли и групи от детайли. ГМ правят планиране в рамките от една седмица до един месец, което е крайно недостатъчно за големи, продължителни или сложни проекти. Планирането и отчитането в рамките на един ден е много натоварващо за ръководителите на екипа и им пречи да изпълняват и другите си задължения.
Ежедневните разговори върху извършеното през предишния работен ден понякога поставя незаслужено служителите в неудобно положение. Често се получава така, че в рамките на един ден се намира някакво решение, което се счита за добро и се работи по него. На следващия ден се оказва, че решението е неподходящо и се намира второ решение, което отпада на третия ден и т.н. Това изглежда като лутане и ако трябва да се говори всяка сутрин за това какво е правено предишния ден и на следващия ден и да се казва че направеното е погрешно и т.н. в продължение на няколко седмици, това определено не е в полза на служителя. А намирането на правилно решение може и да изисква повече от няколко седмици. Това противоречи с планирането по ГМ, което обикновено се прави в рамките на една до четири седмици.
Фирмите или екипите може да декларират, че са за ГМ, но всъщност да инвестират много повече в нови инструменти и технологии, отколкото в кадри и методи за развитието им. Разминаването между думи и дела е налице и тук, т.е. вниманието и инвестицията в персонала се заместват с внимание и инвестиция в процеси и инструменти, защото втората инвестиция е по-сигурна и може би по-необходима за фирмата. Обикновено инструментите остават собственост на фирмата, а хората могат и да напуснат. Освен това, инструментите и най-вече специализираните бази с данни регистрират и съхраняват безучастно и завинаги всичко, попаднало в тях.
Приемането по всяко време на нови изискванията към проекта води до трудно проследяване на промените в него. Ако в проекта има само няколко десетки или няколкостотин изисквания, нещата вървят общо взето лесно и просто, но в проект с десетки хиляди или повече изисквания приемането на нови изисквания по всяко време обикновено или води до хаос, или на практика до отклоняването на новите изисквания, или до модифицирането им, което променя и първоначалния им замисъл.
На теория, изпълнителят е декларирал, че работи по ГМ и би трябвало да приема ентусиазирано всички промени в изискванията, идващи по всяко време от възложителя (дори и в крайния етап на проекта) и да се заема с реализирането им. Очевидно е, че това е прекалено и може да доведе до блокиране на завършването на проекта. Натискът върху изпълнителите е голям и затова изпълнителите често отклоняват изискванията за промени с фрази като „Това няма да Ви трябва!”, „Става много сложно!”, „Ресурсите, които сте предвидили, няма да стигнат”, „Продуктът ще остарее за пазара!”, „ Сега не се прави така.” и т.н. Това е така, защото повечето фирми-изпълнители знаят, че трябва да излизат редовно на пазара с нови продукти и с горе-долу успешни проекти и не могат да си позволят прекалено протакане и твърде много промени в проекта или в продукта.
Приоритизиране на задачите
Представителят на клиента в проекта, който е в постоянен контакт с изпълнителите, обикновено е компетентен само по част от целите на проекта. Освен това, той може и да не разбира технологиите и инструментите, използвани от екипа. Понякога в проекта се включват и други представители на клиента, които дават главно устни консултации. Консултациите са дадени набързо и само в устна форма или са лошо документирани и не са много полезни в дълговременен план.
Тесните неформални и дори непрофесионални взаимоотношения между тестващи/валидиращи специалисти и разработчици или между управляващи проекта и клиента могат да доведат до значителни рискове, например пропускане на грешки, поемане на неизпълними ангажименти и т.н. Липсата на детайлни писмени процедури и процеси за тестване, валидиране и качествен контрол води до изпълнение на проекта с много скрити дефекти, което е неприемливо за критичните приложения.
Най-важният критерий за ефективността на ГМ е доставката на работещ продукт, като критериите за това може и да не са съвсем ясни. Проблемът е там, че при липса на точни изисквания за продукта един работещ продукт може да работи сам за себе си и през по-голямата част от времето, но да има множество грешки, който да го правят нестабилен или да не се покрива с крайните очаквания на клиента. Освен това, терминът „работещ продукт” може да има толкова дефиниции, колкото са и приемащите и използващите резултатите от проекта специалисти и е по принцип неясен и противоречив. Много по-добре е да се специфицира надеждността на продукта и да има пълни изисквания, срещу които да се тества и валидира резултатът от проекта.
Простотата на изпълнението на проекта е съществена черта на ГМ. Но простотата е и понякога субективно свойство. Освен това, някои проекти имат толкова много изисквания, че няма начин да се намери просто и цялостно решение за проекта. Т.е. при ГМ често липсват обективни количествени измерителни параметри за простотата и достатъчността за завършване на проекта.
Постоянната интеграция, т.е. прекалено честото създаване на версия на продукта, създава понякога огромно количеството версии на продукта, които трудно се контролират и сравняват, за да се определи полезността им. Тези постоянни дейности могат да се окажат излишно разпиляване на сили и средства в проекта и да не доведат до очаквания резултат.
ГМ на теория отричат основните цикли на традиционните проекти, които обикновено се свеждат до няколко нива на изработка и детайлизиране на изискванията към проекта, разработка на общо решение, детайлизация на общото решение, намиране на решение за детайлите на проекта, тестване на детайлите от проекта и на сглобени (интегрирани) части от проекта, тестване, валидиране и приемане на целия проект, поддържане на проекта, повторно използване на части от проекта или тяхното рециклиране и напълно унищожаване и затваряне на проекта. Но всъщност ГМ повтарят голямата част от тези етапи многократно, върху малки порции от проекта, като не оставят много документация след себе си, твърдейки че това оскъпява и забавя проекта и че не е нужно. Оскъпяването на проекта заради разработката на документация може и да е вярно, но навременното и точното документиране е абсолютно задължително за по-дългосрочните и по-важните проекти.
Поддържането на обща база данни, в която да се съхранява работата по проекта, по принцип е полезно за проекта. Обаче достъпът до нея би трябвало да се ограничи до необходимия за свършване на съответната задача. В противен случай, този достъп може да действа разсейващо на част от служителите, които вместо да се съсредоточат върху задачите си може да започнат да изучават базите данни и инструментите и да дават неадекватни предложения и забележки, които още повече да увеличат напрежението и дори хаоса по проекта. Освен това, неограниченият достъп е предпоставка за изтичане на чувствителна вътрешна информация към публиката.
ГМ на практика елиминират инженерите по качеството на проекта (понякога наричани процес-инженери или инженерите по вътрешни процеси в проекта/фирмата), които се занимават само със следене на това дали при работа по проекта се изпълняват всички предписания на системата по качеството, приета от фирмата. Тази дейност може да изглежда излишна или бюрократична, защото с нищо не допринася за пряката работа по проекта и дори натоварва работещите с допълнителни задължения, но е необходима, за да се гарантира качество с определено ниво.
Документацията - предизвикателство пред ГМ
Съставянето на подробна и точна документация е много добър метод за проверка на действието на проекта и за спояване на индивидуалната работа в едно цяло, т.е. документирането е част от интеграцията компонентите на проекта в едно цяло. Документацията всъщност е много добра визитна картичка и реклама на проекта. Практиката показва, че когато липсва подробна и точна документация това обикновено е проблем, защото скрива някакви несъответствия, които след това може да се превърнат в неприятни изненади.
Написването на документация е и време за обхващане и осмисляне на работата по проекта. Ако това време е малко, обикновено самооценката за проекта е неточна, което става предпоставка за преповтарянето и задълбочаването на направените технически и управленски грешки.
Наличието на подробни утвърдени шаблони за документите гарантира, че вероятността да се пропусне нещо от описанието на проекта или проблема е минимална. Това е особено важно при по-сложните проекти където има множество детайли, които лесно се пропускат, ако няма подсещащи шаблони на документите, които трябва да се попълват. Вярно е, че понякога тези шаблони за документи са много големи и могат да съдържат множество въпроси които не са свързани с една или друга задача, но в крайна сметка са изпитан и сигурен метод за документиране и отчитане на планираната или извършената работа.
Повторната оценка, осъвременяването, ремонтите, модернизацията и повторната употреба на проекта и на неговите компоненти са силно затруднени и дори невъзможни без подробна документация. Много продукти и фирми дължат доброто си име и място на пазара, както и много добрите си перспективи за развитие, благодарение на високото качество на доставяната документация. Практика е цели проекти под формата на продукти, съоръжения или предприятия след няколко години работа да се изнасят в други райони или страни поради по-изгодните икономически условия. Това е възможно само ако има достатъчно документация и строга дисциплина. ГМ изглежда не предлагат това в класическия си вид.
Адаптацията
Едва ли има метод на управление на проекти, който може да се приложи абсолютно точно, макар и за един единствен по-значителен проект. Адаптацията на формалните методи за управление, дори и на стандартизираните такива, е налице всеки път, когато се използват. Методите за управление обаче се отличават значително по начините и по степента, с която могат да се адаптират.
ГМ също се адаптират когато се прилагат и често се комбинират с елементи от други методи. Това е нормална практика, защото продължителността на проекта или на неговите фази, на наличните ресурси или на променящите се пазарни условия могат да наложат промяна в избрания метод за управление. Степента и начините за адаптация могат да бъдат различни – от минимални промени, до значително прекрояване на метода и до разработка на нов метод. В това отношение ГМ благоприятстват процеса, защото не са обвързани с многобройни правила и препоръки, а имат само десетина основни принципи и следователно могат да се прекрояват съобразно нуждите на всеки нов проект. Това разбира се създава чувство на нестабилност и безперспективност в дългосрочен план и затова ГМ са подходящи главно за по-малки и сравнително краткосрочни и интензивни проекти. Това не пречи да се проведат и добре планирано експериментално прилагане и в по-дългосрочен проект. Известно е, че няма идеален метод, подходящ за всички проекти, и че управлението на проекти е процес на съчетаване на формални и неформални методи и дори непрекъснато експериментиране в динамично променяща се среда.
Проблемът с оценките
Не всеки проект е подходящ за ГМ и не всяка фирма, която твърди че прилага ГМ, им отделя голямо внимание. От тук възникват следните проблеми: определяне на критерии за оценка на проекта, разработка на критерии за оценка на изпълнителя и на възложителя, как да се съгласуват оценката на проекта с оценките на изпълнителя и възложителя на проекта (клиента) и т.н. Засега тези проблеми са намерили само частични решения с методи като размити множества, индексация, списък с въпроси на които трябва да се отговори с експертно давана оценка и др.
За оценка на гъвкавостта се предлагат два индекса със сходни имена. Първият се нарича AIM (Agility Index Measurements) и е предназначен да измерва гъвкавостта на проекта спрямо няколко предварително дефинирани параметъра. Вторият индекс има много близко име – AMI (Agility Measurement Index), който оценява по-скоро изпълнителя на проекта, отколкото проекта. Например, вторият индекс оценява риска, нововъведенията, положените и необходимите усилия, ефективността на взаимодействията и др. фактори вътре в екипа на изпълнителя. Както параметрите, така и оценките, които се дават, имат своето субективно измерение и трябва да намерят отражение в подходящи оценки. Но тези два индекса са добър ориентир за организация, която ще прилага ГМ или ще работи с организации, използващи тези методи.
Всяка организация или фирма може да изработи и собствени мерки за гъвкавост и да ги съгласува с партньорите си, така че изпълнението на проекта да върви успешно. Например, може да се направи само система от оценки на резултатите от всяка итерация на проекта, като крайната оценка да включва както технически, така и финансови и други параметри в края на етапа.
Съществува възможност за разработка на скала за оценка на базата на размита логика (fuzzy logic), методи за самооценка, критерий за оценка на останалите от екипа, оценка на комуникацията с възложителя и др. За съжаление няма много използваеми публикации за методите за оценка на гъвкавостта на индивиди, екипи, фирми и за резултатите от практическите им приложения. Едното предположение е, че фирмите прилагат сравнително нови методи, за които няма натрупана статистика и направени изводи. Другото е, че представляват професионална тайна; третото, че няма заинтересовани по въпроса (това е съмнително, като се има предвид броят на фирмите, деклариращи, че работят по ГМ и изискващи от кандидатите за работа да имат познания по тези методи).
Перспективите за развитие
Гъвкавите методи имат много добри перспективи за развитие в некритичните приложения с проекти от всякакъв вид, след разбира се известна адаптация според областта на приложение. Те са един ускорител на бизнеса, тъй като се използват за масово тестване на нови технологии и продукти. Понякога по-свободните методи са добри за обучение на млади и прохождащи фирми и екипи, които нямат опит в по-тежките и по-сериозни методи за управление и изпълнение на проекти и няма вероятност да бъдат включени някога в критични проекти. В тези случай представителят на клиента и ръководителя на екипа играят в известен смисъл ролята и на учители и наставници на членовете на екипа.
ГМ са подходящи и за фирми с богат опит, които се впускат в нова и непозната за тях сфера на дейност, където все още не могат да завършват успешно висококачествен и високонадежден проект и където все още нямат адаптиран модел за управление на проекти. ГМ обаче не изглежда да са подходящи за проекти, изискващи високонадеждни продукти, отговарящи на множество стандарти, които трябва да преминат през национални и интернационални сертифициращи органи и организации и които трябва да се разработват, произвеждат и поддържат в продължение на десетилетия (кораби, автомобили, самолети, дълговременни съоръжения, АЕЦ, ТЕЦ и други подобни).
Гъвкавите или по-свободни методи на изпълнение и на управление на проекти имат своята стойност и би трябвало да се познават дори и да не се прилагат, защото част от изпълнителите, подизпълнителите и контракторите и особено по-малките и по-високотехнологичните фирми могат да ги прилагат. Все по-голяма част от фирмите изработват и поддържат софтуерни продукти и инсталации и прилагат или декларират, че прилагат някои от ГМ. Работата с тези фирми изисква познаването на терминологията, принципите и практиките на ГМ. Така ще се облекчи комуникацията с тях и ще се намали броя на разминаванията в изискванията и броя на разочарованията за неизпълнени очаквания.
ГМ изглеждат подходящи най-вече за малки фирми и за по-леки и по-евтини проекти. Изглежда най-успешните фирми комбинират няколко метода за управление на проекти, плюс творческа свобода и богат опит от страна на ръководителите и изпълнителите за получаване на впечатляващ и надежден краен резултат. Между гъвкавите и твърдите методи за управление на проектите има огромно пространство, в което двете тенденции се преливат. Това дава големи възможности за изследователска и практическа работа, за да се намери най-подходящият компромис от нови методи за управление и реализиране на проекти във всяка област на приложение и за всеки тип проекти и условия за изпълнение.