Projekti kaitsepiirded: komitee kavandamine
Kui olete sõlminud lepingu, et luua lahendus teistele – eelkõige veebis, kuna see on valdkond, kus ma töötan –, arvan, et projekti jaoks on mitmeid tegureid .
- Ei tohiks olla "komisjoni poolt kavandatud".
- Mitte keegi teine, kelle arendustegevuse põhimeeskond peaks suutma arendust, lavastust ja tootmist pakkuda.
- Tootmisse ei tohiks kirjutada keegi peale arendusmeeskonna (ja isegi siis peaks olema juurutamisprotsess).
Olen alati kõhklev selliste avalduste tegemisel, kuna need tunduvad dogmaatilised, kuid leian, et mida kauem ma selles valdkonnas töötan, seda olulisemad on need kolm reeglit minu arvates.
Või on need tõesti lihtsalt juhised. Lõppude lõpuks helistatakse enne, kui me asjad valmis saame.
Sõltumata sellest, kas need on rohkem soovitused või reeglid, pole tegelikult oluline. On põhjuseid, miks me kõik teeme oma järeldused, eks? Ja nii järgmiste postituste (mitte ühe pika postituse) jooksul jagan ma põhjuseid, miks need kolm reeglit on mulle olulised.
Kujundus komisjoni poolt
Selle termini kasutamisel ei pea ma silmas seda, et saidi kujundamise eest peaks vastutama üks inimene. Pean silmas lihtsalt seda, et selle eest peaks vastutama agentuur või grupp inimesi, kes keskenduvad disainile.
Komitee kujundamine on halvustav termin projekti kohta, millesse on kaasatud palju disainereid, kuid puudub ühtne plaan või visioon.
Seega on "komitee" antud juhul see, kui grupp inimesi või kliendid või klientidega mingil määral seotud isikud tulevad vaatama juurutamise tulemust (või isegi ainult disaini), e-posti teel soovitusi selle kohta, mida nad sooviksid. meeldib näha ja oodata, et see juhtuks.
See tähendab ekspertiisi, kui antud disainer ohverdatakse teise rühma arvamuste nimel.
Printsess Leia ei olnud komitee.
Ja võib-olla äärmuslikel juhtudel (kuigi ma pole seda kunagi isiklikult kogenud) kasutada maksevõimendusena oma tahtmist.
Asi on selles, et inimesed, kellega leping kliendile lahendust kavandama, peaksid olema, nagu öeldud, oma ala asjatundjad. Nad mõistavad tüpograafiat, värve, ekraani eraldusvõimet, juurdepääsetavust ja nii edasi.
Nende jätmine oma pädevusvaldkonda on alati hea mõte.
Projekti eest hoolitsemine
See ei ole seotud sellega, et kellelgi on projekti üle suurem kontroll kui kellelgi teisel.
Selle eesmärk on tagada, et kõik projekti sidusrühmad töötaksid üksteisega koostöös ega ületaks vastutusvaldkondi. (Kujutage ette näiteks GIF-e, mida kasutataks reklaamimiseks, kui arendajad vastutaksid reklaamide eest. 😏)
Lõpptulemus on see, et edukas projekt on just see, kui igaüks jääb oma nurka ja töötab koos oma erialal.
Vastasel juhul kukuvad asjad sünkroonist välja ja tekitavad põhimõtteliselt rohkem probleeme, kui neid polnud (noh, vähemalt teatud valdkonnas), millest alustada.
Mis järgmiseks?
Järgmises postituses käsitlen keskkondade ettevalmistamise ideed, mida see tähendab ja kuidas see mõjutab projektijuhtimise üldist rolli. Aga ma räägin sellest postituses lähemalt.
Lõppkokkuvõttes seisneb see selle tagamises, kellel on lugemis- ja kirjutamisõigus erinevatele piirkondadele, kus rakendust või projekti saab juurutada. Muidugi, mõnele, kes seda loeb, võib see tunduda natuke "algaja" sisuna või üldse mitte "arenguga seotud" sisuna.
Aga kui töötate koos teistega lahenduse leidmiseks, siis on need asjad, millega tõenäoliselt kokku puutute ja lihtsam on koostada plaan, mis põhineb teiste tehtud vigadel (nimelt minul 🙂) kui asjade õppimisel. raske tee.