Pakāpeniska projekta panākumu izstrāde

Progresīva izstrāde - izveidojiet projekta panākumus soli pa solim

Daudzi cilvēki baidās izveidot labu projekta plānu - viņi domā, ka tas prasa pārāk ilgu laiku. Projektu vadības institūtam (PMI) ir risinājums, ko sauc par progresīvo izstrādi. Tas ir fantastisks termins, lai soli pa solim veiktu labu dizainu, līdz mēs sniedzam lieliskus rezultātus.

Progresīvā izstrāde

Sūdzība, ko es bieži saņemu no cilvēkiem, kurus apmācu projektu vadībā, ir tas, ka ir nepieciešams pārāk ilgs laiks, lai definētu projektu pietiekami precīzi, lai novērstu projekta katastrofas. Viņus uztrauc tas, ka mēs plānosim uz visiem laikiem un nekad nedarīsim nevienu darbu. Tas ir reālas bažas, un es to analīzē saucu par paralīzi . Bet izcilai plānošanai un projektēšanai nav jāveic analīze.

Izprotot trīs galvenos punktus, progresīvas izstrādes rezultātā tiks atvērta kvalitatīva dizaina ideja un vērtība.

• Precizitāte nav tas pats, kas detaļa.
• Pirmo reizi pareizi to izdarīt ir lētāk.
• Mums tas nav jāprojektē uzreiz, priekšā.

Lasiet tālāk, lai uzzinātu vairāk.

Precizitāte nav tāda pati kā detaļa

Pakāpeniskas izstrādes atslēga ir tā, ka mēs varam sākt ļoti augstā līmenī ar vispārēju priekšstatu par vēlamo. Tad mēs varam virzīties uz priekšu ar projektu un virzīties uz leju sīkākās un smalkākās detaļās. Tādā veidā mēs sākam strādāt agri un turpinām strādāt, izstrādājot savu dizainu. Tas novērš paralīzi, veicot analīzi.

Lai to izdarītu labi, mums jābūt ļoti skaidriem: augsta līmeņa darbības joma vai dizains var nebūt detalizēts, taču tam tomēr jābūt precīzam. Tas var būt īss un vienkāršs, taču tajā nedrīkst būt nekādu neskaidrību.

Gadījuma izpēte: vietņu uzlabojumi, lai palielinātu reklāmguvumu līmeni

Šajā gadījumā, kas raksturīgs manam konsultēšanas darbam, mēs skatāmies uz uzņēmumu, kuram ir laba mārketinga un reklāmas kampaņa - daudzi cilvēki apmeklē viņu vietnes. Un tirgus izpēte rāda, ka cilvēki, kas nāk, atrodas viņu mērķa tirgū. Turklāt viņiem ir laba, noturīga produktu līnija - tur nekas nav jāmaina. Bet pēc tam, kad cilvēki apmeklē vietni, daudzi to nepērk. Mums jāpalielina reklāmguvumu līmenis, ko sauc arī par slēgšanas līmeni. Ko var darīt?

Pakāpeniski izstrādāsim šī projekta apjomu:

• Izpilddirektora līmeņa darbības jomas paziņojums: Tiks veiktas izmaiņas vietnē, lai palielinātu reklāmguvumu līmeni, tas ir, to cilvēku procentuālo daļu, kuri faktiski kaut ko pērk no tiem, kas ierodas vietnē. Kad mēs paaugstināsim šo likmi, mēs vēlamies saglabāt jauno likmi. Darbības jomas izslēgšana: Mārketings vai mūsu produktu līnija netiks mainīta. Tie pārbauda labi.
• Izpildvaras līmeņa mērīšana: Tas ietver pašreizējo konversijas likmi, nozares standarta konversijas kursu izpēti, mērķu noteikšanu jaunam konversijas kursam līdz noteiktam datumam.
• Pārvaldības līmeņa darbības jomas paziņojums: Izmaiņām vietnē jāpalielina reklāmguvumu līmenis, netraucējot darbspējas laiku, produktivitāti, iepirkumu grozu un finanšu pārvaldību. Izmaiņām un to sekām jābūt izsekojamām, tāpēc mēs uzzinām, kas jāglabā, kas jāizmet un kas jāturpina pilnveidot.
• Vadības pieeja: vadība izvēlas noteiktus produktus, ar kuriem eksperimentēt. Veiksmīgi eksperimenti tiks atkārtoti visiem piemērotajiem produktiem.
• Tehniskie jautājumi: mēs izpētām sīkāk aprakstīto informāciju.
• Tehniskā pieeja: Mēs izstrādājam eksperimentus, pārbaudot dažādas iespējas, lai tos salīdzinātu un redzētu, kas darbojas.

Šie seši soļi pakāpeniski izstrādā projekta dizainu. Katrs domāšanas līmenis sniedz sīkāku informāciju - sīkāku izstrādi - progresējot jaunu tīmekļa lapu izstrādē un ieviešanā.

Ņemiet vērā, ka ir vismaz trīs dažādas cilvēku komandas - iespējams, četras, ja mums ir gan tehniskā mārketinga eksperti, gan tehniskie programmētāji. Katra komanda nāk pēc vajadzības un papildina panākumiem nepieciešamo detaļu.

Plašāka informācija: ieniršana mārketinga detaļās

Šeit ir daļējs mārketinga (nevis tīmekļa dizaina) tehnisko detaļu saraksts, ar kuru projekts strādās, lai palielinātu reklāmguvumu līmeni.

• Mazāk klikšķu, lai aizvērtu. Pētījumi rāda, ka jo vairāk klikšķu starp ienākšanu lapā un darījuma slēgšanu, jo vairāk cilvēku pamet vietni. Tātad lapas var pilnveidot, lai palielinātu reklāmguvumu līmeni.
• Steidzamības sajūtas radīšana. Ja produkts izskatās tā, kā tas būs vēlāk, cilvēki bieži aizkavē pirkumu - un tad vairs neatgriežas. Tehniskās mārketinga komandai var nākties atgriezties pie vadītājiem, lai jautātu, vai īstermiņa atlaižu pārdošana ir pieņemams veids, kā palielināt tuvu likmi.
• Novērst neskaidrības. Detalizēti norādījumi un daudz juridiskas valodas samazinās aizvēršanas ātrumu.
• Tiešās galvenās lapas. Reklāmām jābūt tieši uz galvenajām lapām, kas ir reklamētās preces pārdošanas lapas.
• Laipni lūdzam klientus atgriezties. Izmantojot sīkfailus, klientu pieteikšanos vai abus, mēs varam novirzīt klientus, kuri atgriežas, tur, kur viņi visvairāk vēlas. Mēs varam arī pārbaudīt ar izpilddirektoru par kredītkaršu saglabāšanu failā, lai racionalizētu nākotnes pirkumus.

Kā redzat, sākumā nav jādomā par kādu no šīm idejām. Izpilddirektors nosaka mērķi, vadība vada virzienu, un pēc tam tehniskās komandas pakāpeniski izstrādā, kā izmaiņas sasniegs mērķi.

Mākslinieki vienmēr ir izmantojuši progresīvu izkopšanu

Šī ir agrīna skice, kurā mākslinieks papildus pilnīgas figūras atveidošanai pievieno divas alternatīvas galvas un cilindru. Filmā "Edouard Manet portrets, kurš sēž krēslā" Degas izstrādā savas idejas, neuztraucoties par pēdējā skaņdarba izveidi.

Edgars Degas, Luvras muzejs, Parīze (publiskais domēns), izmantojot Wikimedia Commons

Šajā melnās krīta skicē koncepcija ir pilnīgāk izstrādāta kā "Pētījums par Edouard Manet portretu". Izstrāde turpinās.

Edgard Degas, Ņujorkas Metropolitēna muzejs (publiskais domēns), izmantojot Wikimedia Commons

Šis pilnīgais Edouard Manet portreta ofortēšana, Etūde, kas pagriezts pa kreisi, ir bagātīgs, spēcīgs Degas progresīvās viņa tēmas izstrādes rezultāts.

Edgars Degas, Bostonas publiskā bibliotēka (publiskais domēns), izmantojot Wikimedia Commons

Pirmo reizi to pareizi izdarīt ir lētāk

Jebkurā projektā kvalitātes un rezultātu ziņā ir tikai trīs izvēles iespējas:

• Vislētākā izvēle ir panākt, lai lietas tiktu definētas pareizi pirmo reizi.
• Otra iespēja ir kļūdīties, pēc tam to novērst projekta laikā.
• Trešā iespēja ir kļūdīties un nodrošināt sliktus rezultātus.

Tātad kopumā labāk ir būt skaidram un precīzam sākumā. Cik daudz labāk? Pēdējo 40 gadu pētījumu rezultāti liecina, ka kļūdu novēršanas izmaksu attiecība ir vienāda; izmaksas nosaka kļūdu projekta laikā; un jucekļa tīrīšanas izmaksas pēc projekta. Minimālā attiecība ir 1: 10: 100. Tātad kļūda, kuru var novērst papildus plānošanas stundā ar 100 USD stundā, prasīs desmit stundas projekta laika un 1 000 USD, lai to novērstu projekta laikā, un 100 stundas un 10 000 USD, ja pēc projekta pabeigšanas mums ir jāatsauc. Attiecības, kas ir daudz lielākas par 1: 10: 100, ir atrastas, ja mēs jau no paša sākuma izmantojam paraugpraksi kvalitātes vadībā, lai projektētu bez defektiem.

Nodarbība: Progresīvai izstrādei - detalizētākai attīstībai, virzoties uz priekšu - vienmēr ir jēga. Nevērīgam darbam nekad nav jēgas.

Mums tas nav jādara visi uzreiz

Mēs veicam labu, skaidru darbu ik uz soļa. Tajā pašā laikā mums nav jāpanāk, lai viss projekts tiktu definēts vienlaikus, vai arī sākumā būtu jādefinē visa informācija. Tā vietā mēs varam strādāt pa posmiem. Katrā posmā mēs esam skaidri un precīzi, bet mēs ejam sīkāk. To sauc par progresīvo izstrādi. Labi darot, ietilpst:

• Sākot ar kopainu un virzoties uz detaļām.
• Katrā sanāksmē jābūt skaidrībai, uzrakstīt rezultātus un tos apstiprināt.
• Sekošana tam, cik daudz mēs esam definējuši, un cik daudz vēl nav definēts.
• Atvediet pareizos cilvēkus uz katru sapulci. Agrākas tikšanās biežāk notiek ar vadītājiem un augstāka līmeņa vadītājiem. Mēs, projektu vadītāji, visticamāk, būsim visās sanāksmēs. Cenšoties atklāt procesa, darbplūsmas un saskarnes detaļas, mēs vairāk strādājam ar darbiniekiem. Tā kā sanāksmes kļūst arvien tehniskākas, mums ir nepieciešams vairāk tehnisku cilvēku (piemēram, programmētāji un inženieri), kas iesaistīti projekta pusē.
• Mēs turpinām darboties, līdz tiek definēta katra detaļa par katru produkta vai pakalpojuma iezīmi, kuru mēs veidojam vai uzlabojam. Tomēr, iespējams, mums ir daudz programmas uzrakstīts vai izstrādāts produkts, turpinot detalizēt citas daļas.

Progresīva projektu izstrāde, kas novērš problēmas

Projekti, kas novērš problēmas, ir īpašs gadījums, kad pakāpeniska izstrāde ir īpaši noderīga.

Problēma ir kaut kas parādījies, kas neļauj uzņēmumam vai ražošanas līnijai strādāt tā, kā tas bija agrāk. Tātad mērķis jau ir skaidrs: lai šī d ** mn * d lieta darbojas! Vadītāju līdzdalība ir minimāla, un vadītājiem ir maz ko darīt, izņemot to, ka viņi sniedz atbalstu. Patiesībā, tā kā vadītāji jau zina, kas ir "lieta" un kā tai vajadzētu darboties, "Iedarbiniet šo d ** mn * d lietu!" ir pilnīgs un precīzs paziņojums par augsta līmeņa izpildvaru.

Gadījuma izpēte: 2006. gada kosmosa kuģa Atlantis aizkavēšanās

Labs šāda veida projekta piemērs radās 2006. gadā, kad problēmas ar 10 gadus vecu degvielas mērītāju, kas mēra ūdeņraža daudzumu Space Shuttle Atlantis degvielas tvertnēs, turpināja darboties. Mērītājs kļuva neuzticams, dažreiz parādot, ka tvertne bija tukša, kad tā bija pilna, un problēma bija periodiska.

Izpilddirektora darbības jomas paziņojums būtu skaidrs: nofiksējiet degvielas mērītāju, lai mēs varētu vadīt maršruta autobusu!

Tomēr, pētot problēmas līmeni pa līmeņiem, izmantojot pakāpenisku izstrādi, mēs atrodam četrus tehniskus jautājumus, kas padara problēmas risināšanu arvien grūtāku:

• Vadības lēmums: ja mēs zinām, ka mērinstruments ir kļūdains, vai mēs varam to vienkārši izslēgt un paļauties uz citiem mērierīcēm un jebkurā gadījumā lidot. Par to bija daudz diskusiju. Bet beidzot tika nolemts, ka būtiska drošības funkcija, galvenā dzinēja izslēgšana (MECO), nebūtu uzticama bez šī mērierīces. Tātad vadības lēmums bija tāds, ka gabarīts bija jānosaka.
• Tehniskais jautājums: problēma bija periodiska. Tāpēc jebkurš pārbaudījums, kas tika izturēts, nebija pierādījums tam, ka mērinstruments darbojas un ka atspole var droši lidot. Bija jāatrod konkrētā problēma, lai pārliecinātos, ka tā ir novērsta.
• Detalizēts tehniskais jautājums: mērinstruments nebija vienkārša ierīce. Tas ietvēra daudz dažādu komponentu un elektriskos savienotājus starp tiem. Daži no tiem tika aprakti dziļi maršruta elektroinstalācijas vados. Vienkārši atrast visus komponentus un iztīrīt to savienotājus bija liels darbs. Ne reizi vien inženieri domāja, ka ir novērsuši problēmu, taču mērinstruments netika pārbaudīts tīri.
• Ļoti detalizēts tehnisks jautājums: iespējams, ka kosmosa kuģa projektēšanas plāni nav precīzi atbilduši Atlantis, jo tā tika uzcelta. Daļas tika modernizētas un nomainītas. Viens inženieris ziņoja, ka visu mērierīces daļu atrašana bija izpētes misija, ka viņi joprojām uzzināja, kā darbojas kosmosa kuģis!

Tas parāda, kā pakāpeniski jāizstrādā ļoti vienkārša izpilddirektīva līdz detalizētākam un detalizētākam līmenim, lai nodrošinātu panākumus. Tomēr šai izstrādei nav jānotiek kā plānošanas sastāvdaļai. Kad tika sasniegta katra degvielas mērierīces sastāvdaļa, to varēja notīrīt, pārbaudīt un dokumentēt. Tas ir domāts ar pakāpenisku projekta izstrādi, kas novērš problēmu.

Progresīvā izstrāde nav paredzēta tikai darbības jomai

Lai gan šajā rakstā galvenā uzmanība tiek pievērsta progresīvai izstrādei, izstrādājot darbības jomas definīciju un darba sadalījuma struktūru (WBS), pakāpeniskas izstrādes jēdziens ir plašāks. Faktiski to var attiecināt uz visām deviņām projekta vadības jomām. Šeit ir daži piemēri:

Projekta komunikācijas plāna pakāpeniska izstrāde

Projekta komunikācijas plāna pirmā versija varētu būt tikai komandas locekļu un projekta klientu kontaktu saraksts. Mēs to izstrādājam:

• Visu projekta dalībnieku identificēšana un pievienošana sarakstam
• Izlemt, kā sazināties ar katru ieinteresēto personu
• Izlemt, kā projektā iekļaut klienta balsi

Riska vadības izstrāde projektā

Projekta riska pārvaldības oficiālajos posmos pakāpeniski tiek izstrādāta mūsu projekta riska definīcija - kas varētu noiet greizi - un mūsu atbilde:

• Riska identificēšana, kur mēs izveidojam sākotnējo risku sarakstu.
• Riska analīze, kur mēs novērtējam un prioritizējam riskus
• Riska reakcijas plānošana, kur mēs izlemjam, kā rīkoties, lai novērstu riska notikumus, un kā rīkoties, ja tie notiek
• Riska uzraudzība un kontrole, kur mēs novērojam riskus, meklējam jaunus riskus un rīkojamies ar tiem, kad tie notiek.

No šiem piemēriem jūs varat redzēt, ka pakāpeniska izstrāde ir standarta prakse visās deviņās projekta vadības jomās.

Progresīvā izstrāde un projekta dzīves cikli

Progresīvu izstrādi dažādiem projektiem var piemērot atšķirīgi. Izvēloties, kā veikt pakāpenisku izstrādi, galvenais ir sasaistīt detaļu izstrādi ar izmantoto projekta dzīves ciklu.

Progresīvā izstrāde klasiskajā ūdenskritumā

Klasiskajā ūdenskritumā jeb sistēmas attīstības dzīves ciklā (SDLC) visa plānošana notiek pirms izpildes. Tāpēc pakāpeniska darbības jomas izstrāde notiek plānošanas stadijās.

Progresīva izstrāde ar ātru izsekošanu

Ja klasiskais ūdenskritums tiek modificēts, lai nodrošinātu ātru izsekošanu, viss produkts tiek sadalīts moduļos. Tā kā katra moduļa plānošana ir pabeigta, šī moduļa izstrāde var turpināties, kamēr citi vēl tiek plānoti. Šajā dzīves ciklā daži moduļi tiek izstrādāti ātrāk nekā citi.

Vienlaicīga projekta vadība

Vienlaicīgu projekta vadību izstrādāja Hewlett-Packard, un tagad to plaši izmanto automobiļu rūpniecībā. Sākumā apvienojot visus dažādos speciālistus, projekta dzīves ciklu (teiksim, jauna konceptauto laišanai tirgū) var samazināt no pieciem gadiem līdz 18 mēnešiem! Vienlaicīgā projekta vadībā progresīvu izstrādi ātri un ātri veic savstarpēji funkcionālas komandas.

Nulles defektu programmatūras izstrāde

Programmatūras izstrādes nulles defektu metode ir vērsta uz precizitāti, lai novērstu kļūdu iekļūšanu kodā. Agrīna dizaina izstrāde, kam seko agrīna paša koda izstrāde, ar vairākām pārskatīšanas reizēm pievērš uzmanību vairākām acīm, radot visaugstākās kvalitātes programmatūru par viszemākajām izmaksām. Pieliekot 80% pūļu labam dizainam, tiek ievērojami samazināta testēšana un atkļūdošana, kas ir dārga.

Spirālveida modelis

Spirālveida modelis bija Agile attīstības priekštecis. Tas funkcijas iekļauj grafikā, un, ja līdzeklis darbojas vēlu, tas tiek nomests uz vēlāku ciklu spirālē. katra iezīme tiek izstrādāta, kad tā nāk klajā ar dizainu, un pēc tam atkal nākamajā ciklā, kad tā tiek izstrādāta.

JAD un RAD

JAD, kopīgu lietojumprogrammu izstrāde un RAD, ātra lietojumprogrammu izstrāde, nav reālas dzīves cikla alternatīvas. Drīzāk tie ir prasību izraisīšanas paņēmieni, kas ietekmē dzīves ciklu. Dizaineru un programmētāju tuvināšana saviem klientiem, lietojumprogrammas lietotājiem, paātrina attīstību. Biežas sanāksmes ļauj ātri un pakāpeniski izstrādāt. Un šī pieeja ir galvenā Agile Development sastāvdaļa.

Progresīva izstrāde veiklā attīstībā

Agile Development, saukta arī par Agile Programming, ir jaunākā pieeja projekta dzīves ciklam, un tā īpaši labi darbojas ar mūsdienu objektorientēto kodu un tīmekļa izstrādes platformām. Programmētāji cieši sadarbojas ar klientu, bieži pastāvīgi uzturoties katrā klientu nodaļā. Izmantojot prototipus un ātru lietojumprogrammu modifikāciju, dizains tiek apvienots ar attīstību. Progresīva izstrāde ir nemainīgs process visā projektā.

Ko jūs domājat par progresīvo izstrādi?

Progresīvā izstrāde nodrošina projekta kustību

Tātad pēdējā mācība ir šāda: neatkarīgi no tā, kāda veida projektā mēs strādājam, un neatkarīgi no tā, kādu dzīves ciklu un citas metodes izvēlamies, mēs neplānojam un pēc tam dodamies. Ar pakāpenisku izstrādi mēs plānojam un ejam, un turpinām plānot.