” Feature request!!!”
se on usein meidän ohjelmistoinsinöörien käyttämä taisteluhuuto, jolla vähätellään asiakkaan asian kiireellisyyttä. Loppujen lopuksi ei ole aikaa lisätä uusia ominaisuuksia, kun katsomme ulos loputon bug loki, joka on edessämme.
yhdysvaltalaisille ohjelmistoinsinööreille bugin ja ominaisuuspyynnön ero on kristallinkirkas. Bugi on ristiriita sen välillä, miten koodi todella toimii ja miten koodimme oli tarkoitus toimia. Ominaisuuspyyntö vaatii uuden koodin täyttääkseen tapauksen, jota ei voida käsitellä nykyisellä koodilla.
tällainen ajatusprosessi johtaa aina yleisempään kysymykseen siitä, miten Donedonen kaltaisia ohjelmistoja tulisi käyttää. Tulisiko organisaatiosi käyttää yhden tyyppistä ohjelmistoa bugien kirjaamiseen, toisen tyyppistä ohjelmistoa tulevien tehtävien hallintaan ja vielä toisen tyyppistä ohjelmistoa ominaisuuspyyntöjen seuraamiseen?
käytämme paljon henkistä energiaa yrittäen käydä läpi asiakkaan tai asiakkaan kirjaamia asioita, yrittäen selvittää, heitämmekö ongelman ” bug ”- ämpäriin tai” feature request ” – ämpäriin. Konsulttityössä, kun työskentelemme ennalta määritellyllä sopimuksella siitä, miten ohjelmistojen pitäisi käyttäytyä, tämä on järkevää. Ominaisuuspyynnöt saattavat vaatia lisämaksua.
mutta kun kyse on vain puhtaasta käytännöstä rakentaa hyviä ohjelmistoja, varsinkin jos työstämme omia tuotteitamme, kuinka paljon meidän pitäisi välittää ongelman luokittelusta tällä tavalla?
annamme muotoseikkojen (ja tekniikan) tulla ongelmien korjaamisen tielle.
Robert Martin (alias Bob-setä) puhuu paljon ohjelmistoista. Hän pitää nettiä vain toimitusmekanismina eikä mitään muuta. Se ei ole loppukäyttäjäkokemus, eikä se ole ohjelmiston tarkoitus. Se on vain pieni tyhmä yksityiskohta. Mutta kun me ohjelmoijat ohjelmoimme, sovellustemme arkkitehtuuriin vaikuttaa liian kokonaan se, että kyseessä on verkkosovellus.
samalla tavalla, mitä jos pitäisimme käyttämäämme termiä ”asia, joka pitää saada tehtyä” tyhmänä yksityiskohtana?
kyseisen ”asian” kirjaajan näkökulmasta, onko hänelle todella väliä, että hän pyytää uutta ominaisuutta vs. löytää bugin? Hän haluaa vain toisen ihmisen ratkaisevan ongelmansa, ja mieluiten tietävän, milloin hänen ongelmansa mahdollisesti ratkeaa.
teknisyyden voi nähdä selvemmin, jos lähdemme ohjelmistomaailmasta. Kun putkimies tulee korjaamaan vuotavaa suihkua, kuvittelisin, ettet välitä yksityiskohdista. Jos suihkupää on asennettu väärin (vika) tai jos tiiviste on rikki (vika) tai jos Teflon-teippi puuttui halvasta putkesta (ominaisuus), välität vain siitä, kuinka kauan sen korjaaminen kestää ja kuinka paljon sinulta veloitetaan.
vika vai pyyntö? Molempia. Eikä sillä ole väliä.
viime viikolla olemme mammutin julkaisema Kin, pienyritysten HR-ohjelmistotyökalu. Kin antaa sinulle yksinkertaisen tavan seurata jokaisen työntekijän aikaa pois pyynnöistä. Yksi asia, jota Kin ei juuri nyt tee, on erottaa viikonloput ja lomat työpäivistä. Joten, jos haluat ottaa pois koko viikon kiitospäivänä, sinun täytyy manuaalisesti syöttää määrä tuntia, että olet pyytää pois.
tiimille on jo tullut muutamia pyyntöjä, että sukulaiset tekisivät tämän seurannan automaattisesti. Itse asiassa se on julkaisujonossa. Mutta kun se on kirjautunut, missä tahansa se on kirjautunut sisään, pitäisikö Kin-tiimin pitää sitä bugina, ominaisuuspyyntönä, tehtävänä tai tehtävänä?
kutsuen sisäistä Bob-Setääni vastaukseni on yksinkertainen: ei ole väliä, miten pyynnön luokittelee. Se on vain tyhmä yksityiskohta.
se ei tarkoita, etteikö sitä pitäisi luokitella lainkaan. Kin-tiimi saattaa merkitä ongelman kohtaan ”ominaisuuspyyntö” ja työskennellä kriittisempien ongelmien korjaamisessa ensin (kuten käyttäjä, jolla on Valtuutusongelma). Se on hieno ja hieno, ja pätevä lähestymistapa.
olisi kuitenkin virhe olettaa automaattisesti, että kaikki asiat-we-call-feature-pyynnöt ovat vähemmän kiireellisiä kuin kaikki asiat-we-call-bugit. Se tekee melko pieni yksityiskohta, miten luokittelemme ongelman keskipiste, kun ratkaisemme sen. Sen ei pitäisi olla niin. Loppujen lopuksi kaikki nämä pyynnöt ovat vain asioita, jotka on ratkaistava.
olkoon muotoseikka se tyhmä yksityiskohta
sitä varten kaikille näille pyynnöille antamamme merkintä on suurelta osin merkityksetön. Tärkeämpää on se, että joku hoitaa niitä ja on yleinen käsitys siitä, milloin näihin pyyntöihin puututaan. Tärkeintä on, että 33% enemmän käyttäjiä hyötyvät kohde A on osoitettu verrattuna erä B. riippumatta siitä, minkä tyyppinen asia erä A tai Kohta B on, Kohta A on arvokkaampi käsitellä. Juuri noin. Ei muuta.
joten seuraavan kerran, kun käytät liikaa aikaa tehtävien, bugien, ominaisuuspyyntöjen ja tehtävien luokitteluun, muista unohtaa muotoseikat. Ne ovat vain typeriä yksityiskohtia.
tilaa DoneDone-tili 30 sekunnissa. Haluatko lukea Lisää tekijältä Ka Wai Cheung? Ka Wain uusi kirja nykypäivän ohjelmoija, kehittäjän koodi, on saatavilla eBook ja tulostaa. Voit seurata häntä Twitterissä @developerscode.