Kuna me jätkame WordPressis objektorienteeritud programmeerimise aruteluga edasi liikumist, on oluline, et me ei hüppaks kellegi teise jaoks toote loomisel endast ette.
Nii sageli on lihtne:
- kuulata, mida klient ütleb,
- ehitada midagi välja selle põhjal, mida oleme kuulnud,
- andke see nimetatud kliendile üle.
Kuid selles peitub palju enamat. Olen selle sarja eelmistes postitustes natuke selle ümber tantsinud; siiski tahan hakata uurima, mida tähendab kuulmine:
- Mida klient ütleb,
- Töötada välja nõuete kogum,
- Ja seejärel looge selle ümber tagasisideahelad.
Lõppkokkuvõttes tahame olla kindlad, et inimesed, kelle heaks töötame, ja lahendused, mida me ehitame, on tõesti lahendused, mitte takistused või tõkked, millest nad peavad üle hüppama.
Veelgi enam, ma arvan, et ei piisa sellest, et klient lihtsalt naudib oma lõpptoote kogemust, vaid ka lahenduse loojaga (või nendega) töötamisest.
Seda öeldes vaatame, mida tähendab kuulata, mida nad ütlevad, ja sealt edasi minna.
Klientide ootuste mõistmine
Kui loed raamatuid või muud sellist materjali puudutavat materjali, muudab see sageli ühe kahest osapoolest "pahaks meheks". Mitte alati, kuid mõnikord teeb see:
- klient tundub teadmatuses, millest ta räägib,
- või tundub, et arendaja on nõme, kui ta käitub nagu keegi, kes teab käsitletavast teemast rohkem.
Kuidas on lood kolmanda variandiga, kus kliendil on selge ettekujutus, mida ta tahab, arendaja(d) on valmis kuulama ja töötama koos kliendiga, et midagi ehitada?
Muidugi tuleb teekonnal täpsustusi ja mõisteid, mis tuleb defineerida, ja mõni arenduskalendri "ümberkalibreerimine" võib isegi olla selle osa.
Kuid lõpptulemus on järgmine: kumbki osapool ei peaks töötama teisele vastu. Selle asemel tuleb lahenduse nimel koostööd teha. Muidugi nõuab see suhtlemist (milles arendajad minu kogemuse kohaselt alati suurepärased ei ole, kuid pole põhjust, miks see ei võiks olla parem).
Mida klient ütleb? (Mida arendaja ütleb?)
Iga kord, kui te kaks kohtute, mõtlete tõenäoliselt sama asja, kuna räägite igaüks erinevat keelt ja igaüks teist arvab, et see, mida teine ütleb, on kõnepruuk.
Ja see pole vale.
Klientidel on võimalus rääkida sellest, mida nad tahavad, ja arendajatel on võimalus rääkida sellest, kuidas nad ellu viivad.
Meie kasutatavad tingimused
Kuid võib olla ühine eesmärk.
Otsige probleemi kirjeldust, mida püütakse lahendada. Proovige seda teha võhikute terminites, et disain oleks kooskõlas lahenduse eesmärgi ja funktsionaalsusega.
Ma ei usu, kas see kõigile sobib, kuid see on esimene asi, mida soovitan teha alati, kui oma kliendiga maha istute.
Nagu näete hiljem nendest postitustest, aitab see koostada paar lauset, mida saate oma tööaruande alguses kasutada ja millele saate iga kord, kui otsustate, tagasi pöörduda.
Teisisõnu võite (ja nemad) küsida:
Kas see, mille kallal ma töötan, aitab kaasa ühisele eesmärgile?
Ja siin saate määrata põhinõuete kogumi.
“See peab…"
Kui asi puudutab millegi ostmist, ehitamist, millegi taotlemist, millegi soovimist või mida iganes, siis on üsna lihtne alustada lausega "Ma tahan, et…"
Kuid "ma tahan, et see teeks [midagi]" ja "ma vajan seda [millegi tegemiseks]" vahel on suur erinevus ning kui töötate tarkvaraga, on üldiselt ohutu öelda, et asjad, mida vajate, on põhilised. rakendusele. Ja asju, mida tahetakse, on see, mis tuleb pärast rakenduse vundamendi ehitamist.
See tähendab, et see on vestlus teemal "peab olema" ja "tahan saada". Ja on oluline pidada vestlusi, et jõuaksite rakenduse ühise eesmärgi lõpliku väiteni.
Kui see on paigas, saate alustada tarkvara planeerimist kliendi probleemist lähtuvalt. Ja siin tulebki mängu nõuete kogumine.
Nõuete väljatöötamine
Mis teil ja kliendil on kindel arusaam sellest, mida tuleb ehitada, siis on aeg nõuded kokku panna.
See osa võib olla lõbusam, kui see kõlab. Ma tean, ma tean: see kõlab nagu kodutöö või mõni ülesanne, eks? Aga ei ole. Selle asemel tuleb võtta see, mida nad tahavad, millest olete aru saanud, tõlkida see ühisesse keelde ja seejärel koostada dokument, mis selgitab, mida tarkvara teeb.
Olenevalt teie kogemusest võib see aga igav olla. Ja igavuse all pean ma silmas teie töö üht hullemat osa. Pealegi, nõuded muutuvad alati, eks?
Mitte alati.
Kui võtate algusest peale aega, et mõista, mida nad tahavad, siis ei pea nõuded olema 50-leheküljeline dokument, mis kirjeldab, kuidas iga moodul peab töötama.
Paljud raamatud kinnitavad, et see peabki nii olema. Kuid peaaegu kümme aastat seda tehes pole mul kunagi olnud midagi nii pikka aega ja kliendid on üldiselt olnud väga tänulikud, et nägid lühikest nimekirja, mida saab e-posti või Google’i dokumentide kaudu muuta, allkirjastada ja millele siis viidatakse kui projekti käigule. edasi.
Ma räägin sellest tulevikus, kuid ükskõik, mis halba kogemust teil on, kardate või värisete, ei pea istuma. Ja me jätkame sellest selle sarja kaudu rääkimist.