Viime vuoteen asti yksi tavoista, joilla olen määritellyt virstanpylväitä, perustuu vahvasti siihen, miten minä tai tiimini ja minä aiomme työskennellä projektissa.
Tässä lähestymistavassa on kuitenkin ongelma: niille meistä, jotka yrittävät sisällyttää asiakaspalautteen koko kehitysprosessiin, heidän ei ole yhtä helppoa ymmärtää käyttämämme ammattislangia ja silti saada heidän ymmärtämään sitä.
Tätä tarkoitusta varten olen alkanut rajata WordPress-projektien virstanpylväitä hieman eri tavalla, jotta ne ovat hieman asiakasystävällisempiä, mutta silti järkeviä, kuinka kehittäjätiimi voi saavuttaa sen, mikä on välttämätöntä asioiden toimivuuden varmistamiseksi.
WordPress-projektin virstanpylväät
Mieti hetki, milloin viimeksi olit vastuussa mukautetun laajennuksen rakentamisesta tai mukautettujen toimintojen integroimisesta WordPress-projektiin. Ehkä se sisälsi jotain tällaista:
- Tuo tiedot WordPress-tietokantaan,
- Tee tiedoista katseltavissa ja muokattavissa WordPressin hallinta-alueelta,
- Näytä tiedot käyttöliittymässä ja tavalla, joka voidaan lajitella esimerkiksi sarakearvojen mukaan,
- Tiedot voidaan päivittää toisella tuonnilla tai hallita hallintoalueelta,
- Ja ehkä joitain muita siihen liittyviä ominaisuuksia.
Jos haluat jakaa tämän kehittäjien puheeksi, puhut paljon tietyistä tuontiin, tietojen jäsentämiseen, tietojen eheyteen ja niin edelleen liittyvistä asioista. Ja kaikki tämä on 100% oikein, ja kaiken sen pitäisi olla kehittäjän näkökulmasta.
Mutta jos käytät projektinhallintaohjelmistoa (jonka olemme sopineet Asanaan viime aikoina ), tämäntyyppiset virstanpylväät eivät auta, kun tuot käyttäjiä projektiin.
- Kuinka heidän pitäisi tietää mitään tuontiprosessin yksityiskohdista?
- Kuinka heidän pitäisi ymmärtää lajittelutavan tekemisen tekniset ominaisuudet?
- Onko olemassa tapaa kuvata heille helposti algoritmi, jolla on edes merkitystä?
Sanoisin ei. Joten miten voimme tehdä WordPress-projektien virstanpylväistä helpommin saavutettavissa? En tiedä, onko vastaukseni vankka, mutta se on jotain, jota olemme yrittäneet ja joka näyttää toimivan suhteellisen hyvin, mutta se on yksinkertainen:
- Asiakkaat ajattelevat usein projektejaan koskien sivuja (tai jotain vastaavaa),
- Koska me kehittäjät voimme työskennellä tässä kontekstissa, voimme määritellä julkisen projektin, joka jakaa tehtävät sivulta sivulta.
Siten WordPress-projektin virstanpylväät kertovat enemmän tehtävistä sivukohtaisesti ja loput tehtävät "yleisemmässä" virstanpylvässä.
Sana teknisistä näkökohdista
Kaikki yllämainittu toimii hyvin, kun asiakas on mukana projektin tietyissä osissa, mutta se jättää silti kysymyksen "mitä teemme teknisemmillä puolilla?"
Ja sen mukaan se voi olla mitä tahansa siitä, kuinka aiot järjestää käyttöliittymäsi, luokat, menetelmät ja niin edelleen, siihen, kuinka aiot toteuttaa tietyn algoritmin. Siitä huolimatta asia on, että on käytävä syvempää teknistä keskustelua. Joten mitä teemme niille, kun keskustelemme WordPress-projektin virstanpylväistä?
Vaihtoehtoja on useita:
- Aseta erillinen virstanpylväs, ryhmä tehtäviä, projekteja, keskustelua, mikä tahansa järjestelmäsi sallii, ja pidä se sinun ja tiimisi välillä.
- Hyödynnä GitHub-ongelmia, GitHub-projekteja, wikiä, Trelloa tai muuta järjestelmää,
- Säilytä tiedot toisessa sovelluksessa, joka on kaikkien kehittäjien saatavilla, mutta erillään asiakkaasta.
Toki se lisää hieman yleiskustannuksia, mutta olen huomannut, että mitä enemmän tietoa olet jakanut projektisi eri osiin, sitä menestyvämpi projekti voi olla.
Kun tietoa jätetään pois, hajallaan, ei jaeta tai ei ole yksityiskohtaista, sen hallinta muuttuu sitä vaikeammaksi mitä pidemmälle projekti etenee, varsinkin tulevien iteraatioiden aikana.
Tärkeintä on, että mielestäni on tärkeää jakaa WordPress-projektien virstanpylväät osiin, joissa asiakas ymmärtää helposti, mitä työtä tehdään ja että sinulla ja tiimilläsi on tapa hallita sitä, mitä tehdään.
Se, miten teet sen, on tietysti sinun päätettävissäsi, mutta olen havainnut, että sen määrittäminen kannattaa.