Olio-ohjelmointi WordPressissä: Asiakkaiden odotusten ymmärtäminen
Kun jatkamme keskustelua oliosuuntautuneesta ohjelmoinnista WordPressissä, on tärkeää varmistaa, ettemme hyppää itsemme edellä, kun on kyse tuotteen rakentamisesta jollekin toiselle.
Niin usein on helppoa:
- kuulla mitä asiakas sanoo,
- rakentaa jotain sen perusteella, mitä olemme kuulleet,
- luovuta se mainitulle asiakkaalle.
Mutta siinä on paljon muutakin. Olen tanssinut sen ympärillä tämän sarjan aiemmissa viesteissä; Haluan kuitenkin alkaa perehtyä siihen, mitä tarkoittaa kuulla:
- Mitä asiakas sanoo,
- Kehitä joukko vaatimuksia,
- Ja sitten luoda palautesilmukoita sen ympärille.
Viime kädessä haluamme varmistaa, että ihmiset, joille työskentelemme, ja ratkaisut, joita rakennamme, ovat todella ratkaisuja eivätkä esteitä tai esteitä, joiden yli heidän täytyy hypätä.
Lisäksi mielestäni ei riitä, että asiakas vain nauttii lopputuotteestaan kokemuksesta, vaan myös siitä, että hän työskentelee ratkaisun rakentajan (tai niiden) kanssa.
Tämän jälkeen katsotaanpa, mitä tarkoittaa kuunnella, mitä he sanovat, ja mennä siitä eteenpäin.
Asiakkaiden odotusten ymmärtäminen
Aina kun luet kirjoja tai muuta materiaalia tämänkaltaisista asioista, se tekee usein toisesta osapuolesta "pahan kaverin". Ei aina, mutta joskus se tekee:
- asiakas näyttää tietämättömältä, mistä he puhuvat,
- tai se saa kehittäjän näyttämään ääliöltä, koska hän toimii kuin joku, joka tietää enemmän käsillä olevasta aiheesta.
Entä kolmas vaihtoehto, jossa asiakkaalla on selkeä käsitys siitä, mitä hän haluaa, kehittäjä(t) ovat valmiita kuuntelemaan ja työskentelemään yhdessä asiakkaan kanssa rakentaakseen jotain?
Tietysti matkan varrella tulee selvennyksiä, ja tulee olemaan termejä, jotka on määriteltävä, ja kehityskalenterin "uudelleenkalibrointi" saattaa jopa olla osa sitä.
Mutta lopputulos on tämä: kummankaan osapuolen ei pitäisi työskennellä toista vastaan. Sen sijaan kyse on yhdessä tekemisestä ratkaisun löytämiseksi. Toki se vaatii viestintää (missä kehittäjät eivät kokemukseni mukaan aina ole hyviä, mutta ei ole mitään syytä, miksi se ei voisi olla parempi).
Mitä asiakas sanoo? (Mitä kehittäjä sanoo?)
Aina kun tapaatte, ajattelette todennäköisesti samaa asiaa, koska puhutte kumpikin eri kieltä ja jokainen teistä ajattelee, että toinen sanonta on ammattikieltä.
Ja se ei ole väärin.
Asiakkailla on tapa puhua siitä, mitä he haluavat, ja kehittäjillä on tapa puhua siitä, kuinka he toimittavat.
Käyttämämme ehdot
Mutta yhteinen tavoite voi olla.
Pyri kuvaamaan ongelmaa, jota yritetään ratkaista. Yritä tehdä se maallikon termein niin, että muotoilu on linjassa ratkaisun tavoitteen ja toimivuuden kanssa.
En usko, toimiiko tämä kaikille, mutta tämä on ensimmäinen asia, jonka suosittelen tekemään aina, kun istut alas asiakkaasi kanssa.
Kuten näet myöhemmin näistä viesteistä, se auttaa kehittämään muutaman lauseen, joita voit käyttää työselostuksen alussa ja joihin voit palata joka kerta, kun sinun on tehtävä päätös.
Toisin sanoen sinä (ja he) voit kysyä:
Edistääkö se, minkä parissa työskentelen, yhteistä tavoitetta?
Ja tässä voit määrittää ydinvaatimukset.
”Sen täytyy…"
Kun tulee jotain ostamaan, rakentamaan, pyytämään jotain, haluamaan jotain tai mitä tahansa, on melko helppoa aloittaa lause "Haluan sen…"
Mutta "haluan sen tekevän [jotain]" ja "tarvitsen sitä [tehdäkseni jotain]" välillä on suuri ero, ja kun työskentelet ohjelmistojen parissa, on yleensä turvallista sanoa, että tarvittavat asiat ovat ydin sovellukseen. Ja asioita, joita halutaan, tulevat sen jälkeen, kun sovelluksen perusta on rakennettu.
Toisin sanoen, se on keskustelu "pakollinen" ja "halua saada". Ja on tärkeää käydä keskusteluja, jotta pääset siihen lopulliseen lausumaan sovelluksen yhteisestä tavoitteesta.
Kun se on tehty, voit aloittaa ohjelmiston suunnittelun asiakkaan ongelman ympärille. Ja tässä tulee esiin vaatimusten kerääminen.
Kehittämisvaatimukset
Mitä sinulla ja asiakkaalla on vankka käsitys siitä, mitä on rakennettava, on aika koota vaatimukset.
Tämä osa voi olla hauskempaa kuin miltä se kuulostaa. Tiedän, tiedän: Kuulostaa kotitehtäviltä tai tehtävältä, eikö niin? Mutta se ei ole. Sen sijaan se ottaa sen, mitä he haluavat, mitä olet ymmärtänyt, kääntämällä sen yhteiselle kielelle ja kirjoittamalla sitten asiakirjan, joka selittää, mitä ohjelmisto tekee.
Kokemuksestasi riippuen tämä voi kuitenkin olla tylsää. Ja tylsällä tarkoitan yhtä työsi pahimmista osista. Sitä paitsi vaatimukset muuttuvat aina, eikö niin?
Ei aina.
Jos otat aikaa ymmärtääksesi, mitä he haluavat alusta alkaen, vaatimusten ei tarvitse olla 50-sivuinen asiakirja, jossa esitetään, kuinka jokaisen yksittäisen moduulin on toimittava.
Monet kirjat dokumentoivat sen sanovan, että näin sen täytyy olla. Mutta lähes vuosikymmenen aikana minulla ei ole koskaan ollut mitään näin pitkää, ja asiakkaat ovat yleensä olleet uskomattoman kiitollisia nähdessään lyhyen luettelon, jota voidaan muuttaa sähköpostitse tai Google-dokumenteissa, allekirjoittaa ja jota kutsutaan sitten projektin siirroiksi. eteenpäin.
Puhun siitä lisää tulevaisuudessa, mutta mitä tahansa huonoa kokemusta sinulla on, pelkäät tai pelkäät, sinun ei tarvitse istua. Ja jatkamme siitä puhumista tämän sarjan kautta.