Selle seeria eelmises postituses rääkisime nõuete määratlemisest (või tööaruandest) ja sellest, miks on selle olemasolu oluline.
Enne kui hakkame objektorienteeritud koodi tegelikult mõistma ja kirjutama, tuleb arutada veel üht "äriga seotud" teemat: nõuded ja tingimused.
Paljude jaoks on see veidi kuiv teema, kuid kui soovite luua lahendusi kellegi teise jaoks, tehke seda maast-madalast ja tehke seda õigesti, siis on oluline veenduda, et teil on kõik vajalikud osad paigas enne seda.
Ja kui olete:
- tehtud analüüs (esimene ja teine osa ) ,
- mõista oma kliendi ootusi ,
- ja koostanud tööaruande ,
On aeg veenduda, et teil on tingimused, mille alusel töötate.
[piira makstud="true"]
Tingimuste määratlemine
Esiteks arvan, et on oluline mõista tingimuste (või lihtsamalt öeldes tingimuste) dokumendi eesmärki.
Wikipedia järgi defineeritakse termineid järgmiselt:
Lepingutingimus on "mis tahes säte, mis on osa lepingust". Iga tingimus toob kaasa lepingulise kohustuse, mille rikkumine võib kaasa tuua kohtuvaidluse. Kõiki tingimusi ei ole sõnaselgelt sätestatud ja mõnel tingimusel on vähem õiguslikku tähtsust, kuna need on lepingu eesmärkidega võrreldes perifeersed.
Kas see on liiga formaalne? Võib olla. Ma arvan, et see selgitab seda hästi, vähemalt üldises mõttes, kuid kui ma peaksin selle ise defineerima, siis läheneksin sellele veidi teisiti.
Lühidalt, ma üritaksin seda võimalikult lihtsana hoida. Võib-olla midagi sellist:
Tingimused määratlesid reeglid ja juhised kokkuleppe sõlmimiseks vähemalt kahe ärisuhte osapoole vahel.
Aga mida need peaksid sisaldama?
Mis on nõuete ja tingimuste dokumendis?
See küsimus on veidi subjektiivne, kuna see sõltub suuresti lahenduse suurusest, kaasatud ettevõtete suurusest ja ehitatava olemusest.
Üldiselt veendun siiski, et käsitletakse järgmisi teemasid:
- Hinnakujundus ja maksed määravad, kuidas hinnakujundus ja maksestruktuur toimivad.
- Hinnangud viitavad sellele, kuidas teenusepakkuja, nimelt teie või teie ja teie meeskond, esitate hinnanguid, mida nende jaoks nõutakse ja kuidas need erinevad tegelikest maksetest.
- Heakskiidud on kasulikud nii teenusepakkujale kui ka kliendile, et nad teaksid, millal antud funktsioon (või kogu projekt) on lõpetatud.
- Volitus lihtsalt määratleb kahe poole vahelise kokkuleppe arvete esitamise ja dokumendi ülejäänud sisu osas.
- Projekti valmimise ja tarnekuupäevad määravad ootused projekti ajakava suhtes. Lisan, et see ei hõlma puhkusi, „meie kontrolli alt väljuvaid väliseid jõude" ega kliendi hooletust suhtluse tagastamisel.
- Tühistamine selgitab, kuidas loodud, kasutatud, loodud ja osapoolte vahel jagatud ressursse säilitada või omada, kui projekt tühistatakse.
- Autoriõiguse vastutuse eesmärk on tagada, et mis tahes intellektuaalomandile, mille klient pakub, on vastavad autoriõigused ja et teid või teie meeskonda ei saa muul viisil vastutada.
- Intellektuaalset omandit saab kasutada selleks, et selgitada, kuidas säilib projekti käigus loodud kunstiteoste ja muude varade omandiõigus pärast projekti lõppemist. Mõnikord vastutab konkreetne ettevõte varade omandiõiguse säilitamise eest; muul ajal võib klient säilitada kogu projekti omandiõiguse.
- Muudatused selgitavad, kuidas muudatustaotlused töötavad ja nende eest võetakse tasu.
- Vastutuse piirang lihtsalt selgitab teie või teie meeskonna vastutuse taset kahjude või kahjumite eest pärast projekti vabastamist.
- Reklaamkasutus määrab, kas teie või teie meeskond saate teiste klientidega vesteldes kasutada reklaammaterjalis sisalduvat tööd või mitte.
- Kliendi kohustused kirjeldavad, mille eest klient vastutab projekti pakkumise eest. See kõik võib toimuda ette, verstaposti kohta või mis tahes ajakava alusel, mille kokku lepite.
- Juriidilised tasud määratlevad, kes mille eest vastutab, kui tegemist on advokaaditasudega, kui need tuleb esitada.
Olen püüdnud ülaltoodust anda lühikese kokkuvõtte. Töötamiseks kasutatavaid malle on veebist lihtne otsida, kuid soovitan tungivalt lasta advokaadil oma dokument enne selle kasutamist mis tahes õigusolukorras üle vaadata.
Nõuete ja tingimuste tööriistad
Kui rääkida ettevõtte juhtimisest ja objektorienteeritud programmeerimisest, võib see olla kõige kuivem materjal.
Kuid see on vajalik, kui soovite juhtida edukat ettevõtet, sest töö on midagi enamat kui lihtsalt kellegi teise jaoks koodi kirjutamine.
Kuigi ma ei saa pakkuda iga vabakutselise või agentuuri tingimusi, võin siiski pakkuda paar kohta, kus nende kohta rohkem lugeda ja e-allkirju seadistada, et alustada võimalikult lihtsaks.
Näiteks kasutan järgmist:
- Google Docs nõuete ja tingimuste koostamiseks ning projektipõhiseks uuendamiseks.
- Eversign elektrooniliste allkirjade seadistamiseks.
Ja see ongi kõik! Võib-olla on kõige keerulisem osa tingimuste koostamise alustamine.
Sellest hetkest alates hakkame sukelduma koodi ja rääkima objektorienteeritud programmeerimise erinevatest aspektidest ning kuidas neid WordPressi kontekstis rakendada.