Која је права методологија управљања пројектима

Пре него што директно одговорите на питање у наслову, увек је добро да буде јасно који је крајњи циљ пројекта који желите да постигнете

Како ће производ изгледати за месец, пола године и годину дана од сада. Али опишите то сада. Ово ће вам дати неку перспективу и поставити основна очекивања о нивоу ваше предвидљивости, флексибилности, агилности, брзине до тржишта и фиксације трошкова на време.

Да, данас се чини да је постављање пројеката водопада смешна идеја. Поготово ако је већ небројено пута доказано да ако желите да брзо реагујете на промене на тржишту, немате другу опцију осим да будете агилни. Али ако је ваш циљ да испоручите производ за годину дана од сада са функцијама које су већ прилично јасне и ограничене од самог почетка, а имате тимове људи који немају претходног искуства са агилном методологијом, онда свакако останите конзервативни и идите у воду.

Није сваки случај тако једноставно закључити. Хајде да погледамо како да боље проценимо која методологија је боља за ваш пројекат.

Како изгледа водопад?

Уместо да улазимо у неке дефиниције којих су сви свесни већ неколико деценија, практичан исход пројекта водопада обично изгледа овако:

  • Прво планирајте шта желите да урадите као крајњи резултат/производ и колико то може отприлике коштати.
  • Започните процес прикупљања захтева. Детаљно сте разговарали о свим детаљима крајњег производа, приговорили, испитали, договорили, поново разговарали и на крају потврдили.
  • Процените целу ствар и потврдите буџетска очекивања.
  • Дизајнирајте решење. Одржати неколико састанака са заинтересованим странама. Направите различите документе и пустите заинтересоване стране да их прегледају. Потврдити и одобрити коначни функционални и технички пројекат.
  • Имплементирајте решење на основу дизајна. Овде развијате комплетан крајњи производ.
  • Уђите у фазу тестирања и извршите разне врсте тестова. Јединични тестови, системски тестови, функционални тестови, тестови интеграције, тестови перформанси, регресиони тестови, тестови прихватања корисника и потенцијално још много тога (у зависности од културе компаније). Документујте све и пустите заинтересоване стране да то прегледају и одобре.
  • Поставите решење у производно окружење. Овде циљни корисници почињу да користе финални и комплетан производ.
  • Закажите неку фазу подршке током које развојни тим исправља потенцијалне грешке решења.
  • Цео овај процес може трајати од неколико месеци до неколико година. Као што можете предвидети, корисници ће видети резултате тек на крају тог процеса. Дакле, после дугог чекања долази тренутак истине (или неуспеха).

    Ако се нешто промени током тог времена и крајњи производ треба да изгледа мало другачије, то је ситуација коју називате захтевом за промену. Дизајн мора бити поново отворен, прерађен и поново одобрен. Продужује цео временски распоред за други део. Свака промена захтева поновно покретање целог процеса пре.

    Са друге стране, имате чврсту дефиницију фазе, фиксни буџет за сваку фазу и фиксно време. Чак и ако морате дуго да чекате да бисте добили први резултат, ако су шансе за промене на том путу минималне, то и даље може бити пожељнија опција.

    Како Агилни изгледа?

    Ево како пројекат може да ради под агилним подешавањем:

  • Дефинишите пословну визију крајњег производа. Грубо, али са јасним пословним захтевима и очекивањима шта ће производ испунити за кориснике.
  • Направите листу функционалних Епица и техничких Енаблерс-а који покривају визију.
  • Урадите процену на високом нивоу епова и оних који омогућавају да успоставите нека очекивања у погледу економичног буџета и временски оквир испоруке. Дефинишите шта је Минимални одрживи производ (МВП) и које су остале карактеристике које чине коначни производ.
  • Подесите сцрум тим и закажите спринтове унутар временског периода. Раздвојите епове на карактеристике и приче са тимом. Процените приче и планирајте их за предстојеће спринтове на основу приоритета које функције и приче имају.
  • Радите на причама сваки спринт. Укључите све активности у спринтове, односно дизајн, развој, тестирање и примену. На крају сваког спринта, представите резултат повећања корисницима и тражите повратне информације.
  • Ако нешто крене ван колосека или има жељени исход, промените карактеристике или приче да бисте се прилагодили ажурираној стварности. Одразите то одмах од наредних спринтева.
  • Одмах након што се обим МВП-а заврши, пустите га крајњим корисницима како бисте брзо прикупили повратне информације о производњи.
  • Наставите да развијате остале карактеристике тако што ћете одражавати резултате повратних информација корисника из већ објављеног дела система.
  •   Да ли је Инцредиблес 2 на Нетфлик-у?

    Ово је само кратак резиме, али разлика у односу на водопад је већ јасна. Брза повратна информација, прилагођавање, одраз тренутних потреба које се мењају у времену, први вредан производ испоручен у најкраћем могућем року. Све су то некретнине које немате шансе да добијете у пројекту водопада.

    Агиле против водопада

    Пројекат не може бити успешан без одговарајуће методологије управљања пројектом. То значи дефинисање процеса, метрике, евалуације и опште начине рада за тимове који формирају пројекат.

    Тимови треба да знају која правила да поштују, шта ће дефинисати прекретнице, када да их достигну и како да мере и процене успех. У исто време, заинтересоване стране треба да разумеју шта могу да очекују од пројекта и када ће моћи да виде прве резултате рада.

    Уз мало генерализације, можемо рећи да је већа вероватноћа да ће пројекти који раде у цлоуд окружењима бити склонији агилним методологијама (или би барем требало). Пројекти који раде са локалним инфраструктурама и даље често преферирају водопадне процесе. Ово долази као природан закључак.

    Окружење у облаку је изграђено од тла како би одговарало окружењу које се стално мења. Прилагођава се што је брже могуће (уз разне „еластичне“ услуге) новој стварности. Локално окружење је често унапред дефинисано на почетку. Тешко је то променити током времена, тако да тимови раде са детерминистичким варијаблама током целог трајања пројекта.

    Резиме приступа Агиле против водопада.

    ФеатуреВатерфалл АппроацхАгилни приступУправљање корисничким захтевимаПромена се третира као формални процес (Захтев за промену). Посао ће можда морати да се понови, што утиче на трошкове и временске рокове. Обухвата промене као део стандардног процеса, без значајног утицаја на трошкове или временске оквире. Планирање пројекта и обим Дефинише обим на почетку и придржава га се. Фазе су круте и придржавају се првобитног плана. Има јасну визију финалног производа, али дозвољава промене. Рад је организован у спринтеве са флексибилношћу у начину на који се задаци завршавају. Праћење напретка пројекта Прати напредак у свакој фази. Кашњења у једној фази могу утицати на цео временски оквир пројекта. Прати напредак кроз демо сесије на крају сваког спринта. Фокусира се на изводљив производ. Тимска сарадња Различити људи у различитим фазама пројекта, ограничена интеракција. Међуфункционални тим са сталном комуникацијом међу члановима тима и заинтересованим странама. Управљање ризиком Праћење статуса засновано на напретку фазе. Реагује на ризике ретроспективно док се придржава плана. Фокусира се на проактивно решавање зависности између тимова и активности. Прилагођава план да елиминише пројектоване ризике. Оквир за имплементацију Традиционална методологија. Захтева праксе трансформације да би се прилагодио агилном приступу. Укључује промену навика и начина размишљања.

    Овај избор ће, међутим, дефинисати неколико аспеката својстава извршења пројекта.

      Уношење података објашњено најједноставнијим речима

    #1. Захтеви пројекта и управљање променама

    Један од најважнијих аспеката који дефинишу избор је како ће се задовољити захтеви корисника. И такође, какав је процес ако је накнадно потребна промена већ договорених захтева?

    Са пројектом водопада, сви захтеви су дефинисани и потписани од стране заинтересованих страна на почетку; ако дође до било какве промене тог стања, пројекат то третира као Захтев за промену. Мора се поново потврдити, усагласити и потврдити.

    Сваки посао који је већ обављен до тог тренутка мора се поново размотрити и започети изнова. Трошкове је потребно поново кориговати (пошто је то додатни посао који није покривен оригиналним уговором). У најгорем случају, чак и цео временски оквир пројекта треба да се продужи.

    Уз агилну поставку, промене су добродошле. Промене третирате као стандардни свакодневни посао. Слажете се са заинтересованим странама (вероватно као резултат најновије демонстрације спринта) да су промене кључне како би се одржала визија пројекта. Затим одмах закажете те промене за следеће спринтове.

    Досадашњи садржај ће се тиме променити, а тимови од тог дана настављају да раде са новим захтевима. Нема губитка времена или трошкова. Једноставно се одмах прилагодите новој стварности и замените првобитни план новим. Уопште није потребно посебно управљање захтевима за промене. Све је то део иницијатива за планирање спринта.

    #2. Планирање и обим пројекта

    Као што можете очекивати, пројекат водопада поставља и поправља сав опсег на почетку. Ви генеришете план пројекта око овог опсега. Затим поделите трајање пројекта на специфичне фазе (обично анализа, дизајн, развој, тестирање, примена, подршка и одржавање) и поправите тимове и ресурсе око тих фаза. За већину временског оквира пројекта, ваш главни циљ је да се држите овог оригиналног плана у смислу трошкова и времена што је више могуће.

    Агилан пројекат има визију коначног производа уместо чврстог плана. Крајње стање је јасно, али пут до тог стања је слободан да се мења. Такође, временски оквир пројекта је и даље дефинисан и договорен на основу прелиминарне процене потражње и искуства оптерећења капацитета за тимове који раде на пројекту. План нема одвојене фазе. Уместо тога, сваки спринт је сама по себи мала фаза која садржи све активности које су тиму потребне да успешно пусти производ повећања.

    Укратко, пројекат водопада третира промене као компликацију за решавање (и прилику за продавце да стекну додатни новац). Насупрот томе, агилни пројекат третира промену као уобичајени посао без додатних последица (осим бољег крајњег производа).

    #3. Праћење напретка пројекта

    Пројекат водопада прати напредак плана унутар фаза пројекта. Фаза пројектовања не може да почне пре него што се заврши фаза анализе, тестирање не може да почне пре него што се комплетна изградња заврши и тако даље.

    Ако нека од фаза дође до кашњења, то ће утицати на напредак преосталих фаза пројекта. Због тога је важно проверити активности унутар сваке фазе и осигурати да напредују линеарно током времена. У супротном, повећавате ризик од одлагања те одређене фазе, а самим тим и целог пројекта.

    Агилни пројекат прати напредак, углавном са демо сесијама које се дешавају на крају сваког спринта. Радни производ је примарно мерило напретка. Наравно, желите да осигурате да се сваки спринт заврши са потпуним садржајем спринта. Ниједна или само минимална прича се не преноси у следеће спринтове.

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

    #4. Тимска сарадња

    Овде се ради о строго одвојеним активностима водопада у односу на сталну сарадњу са свим странама агилног тима.

      Како избрисати послату поруку на Снапцхату

    Пројекат водопада обично има различите људе који раде у различитим фазама пројекта. Можда се у извесној мери преплављују једни друге, али су и даље различите групе људи. Скоро силоси, могло би се рећи.

    Дефиниција агилног тима лежи у комуникацији и вредности. То ће такође бити мултифункционални тим способан да изврши све активности животног циклуса производа. Силос тимова је нешто што не желите да постоји. Константна комуникација напред-назад између тима и спољних заинтересованих страна је основна дефиниција успешног агилног пројекта.

    #5. Управљање ризиком

    Очигледно, желите да имате процес за праћење свих ризика, проблема или било које врсте препрека које пројекат може донети током свог временског оквира.

    У случају водопада пројекта, ово се преводи у праћење статуса тренутне фазе пројекта. Стандардно извештавање о статусу налик семафору ће бити приказано зелено (све је у реду и у складу са планом), жуто (неки важни проблеми постоје, али још увек постоји јасно разумевање како да их решите) или црвено (што значи пројекат има озбиљне проблеме који могу утицати на првобитне временске оквире или буџет).

    Агилни пројекат је такође другачији овде. Ви заправо не пратите напредак ка циљу. Уместо тога, решавате зависности између различитих тимова и врста активности. Циљ је осигурати да ниједан тим не чека други тим са активностима напретка.

    Наравно, могу се појавити ризици, али тада решење мора да промени план у будућности тако да ризик нестане, а не да се пронађе решење за ризик, а да се и даље сачува првобитни план.

    Другим речима, агилна поставка пројекта користи све могуће начине да промени план да се не суочи са пројектованим ризицима, што значи да је управљање ризиком проактивно. У случају пројекта водопада, ретроспективно одговарате на ризике и покушавате да их решите у најкраћем могућем року држећи се првобитног плана.

    #6. Оквир за имплементацију

    Тактика имплементације за водопадне пројекте је очигледно мање проблематична него за агилне пројекте. Обично је методологија водопада статус кво који људи већ практикују дуги низ година.

    С друге стране, пројекти захтевају агилну праксу трансформације да би променили своје навике, начин размишљања и начин рада. То је тежак, а често и прилично дуготрајан процес. Компаније улажу значајну количину времена и ресурса да науче људе да се прилагоде агилним процесима.

    Предности у виду брзог прилагођавања променљивим потребама корисника су значајне, али промена начина размишљања људи и целокупног радног окружења је најтежи део.

    Већину времена, то је и једини начин да останете компетентни на тржишту, тако да су компромиси награђени великим успехом за оне који успеју.

    Завршне речи

    Рецимо то јасно. Осим ако немате веома конзервативног купца без велике мотивације да брзо испоручите резултате у производњу (из било којих разлога за то), најбоље је да почнете да моделирате агилне тимове од самог почетка. Ово је буквално незамисливо у данашњем свету. Ово важи чак иу случају традиционалног подешавања система на локалном нивоу. Нарочито ако је тим нов или почиње од нуле са оригиналним људима, и даље има смисла трансформисати процесе како би се ускладили са агилним методологијама.

    Рекавши то, и даље видим пројекте у којима људи једноставно одбијају да прате ову врсту агилног процеса или било које друге поставке, али стриктно фазно специфичну организацију рада. Они прате уобичајени пут уговарања посла за одређено време и буџет. Затим очекују да ће пројекат следити ову поставку без одступања од плана и новца (са разним исходима, најчешће не добрим).

    То је одлука коју имају право да донесу, али на крају, таквом одлуком и они одлучују да остану у прошлости. Можда ће им то радити још неко време, али само је питање времена када више неће радити.

    Затим погледајте детаљан чланак о животном циклусу Агиле тестирања.