Ensimmäinen virhe: kohteen kuvaaminen väärissä yksiköissä
Suurin osa rakennuschatissa hukatuista kierroksista johtuu siitä, että tähdätään väärälle korkeudelle, ja tämä tapahtuu kahteen vastakkaiseen suuntaan. Jotkut pyytävät vähemmän kuin tarkoittavat — "paranna ulkoasua", "tee siitä parempi", "tämä ei vielä tunnu oikealta". Jokainen näistä on diagnoosi ilman kohdetta, joten seuraava versio on arvaus: se saattaa tummentaa otsikon, vaihtaa fontin tai järjestää navigaation uudelleen, etkä tiedä miksi ennen kuin tuijotat tulosta miettien, mitä tapahtui. Toiset yliampuvat ja pyytävät enemmän kuin pitäisi — he nimeävät istuntoevästeet tai CSS Gridin tai latausluurangon (loading skeleton) komponentin, koska he tietävät hieman ja haluavat olla avuksi. Tuo virhe on hiljaisempi, mutta yhtä kallis. Sillä hetkellä, kun määrittelet toteutuksen, olet yleensä määritellyt sen väärin — tai parhaimmillaankin kaventanut ratkaisuavaruuden vain siihen, mitä itse jo tiedät, mikä on kapeampi kuin se, mitä rakentaja olisi kokeillut omin päin, ellet ole ammatikseen ohjelmoiva kehittäjä. Ja jos nimeämäsi kirjasto tai malli osoittautuu vääräksi valinnaksi, se on nyt bugi, jonka itse toit mukaan — sellainen, jota rakentaja ei olisi koskaan tehnyt työskennellessään lopputuloksesta käsin.
Korjaus löytyy näiden kahden virhetyypin väliltä: nimeä asia, jota katsot, ja muutos, jonka haluat nähdä — älä mekanismia, joka sen tuottaa. "Vierailijoiden pitäisi voida varata ilman tilin luomista" voittaa kappaleen istuntoevästeistä, koska se, mitä oikeasti haluat, on kitkan poistuminen, ja siihen on todennäköisesti kolme tapaa, joita et ole vielä ajatellut. "Hintataulukko on sekava" on itsessään vielä liian ohut — sekava miten? — mutta "ihmiset eivät huomaa, että vuosipaketti säästää rahaa, laita alennus hinnan viereen sen sijaan, että se hukkuu pieneen präntättyyn tekstiin" antaa rakentajalle jotain konkreettista, jota vasten työskennellä. Jos et tiedä, miltä korjauksen pitäisi näyttää, sekin on ihan hyvä — kerro, mikä on vialla, ja anna sen ehdottaa muotoa. Se, mikä ei toimi, on epämääräinen tyytymättömyys ilman ankkuria, sillä se muuttaa jokaisen seuraavan version arvauspeliksi.
| Sen sijaan että sanot… | Sano… |
|---|---|
| "Paranna sitä" | "Sankarikuvan teksti on vaikea lukea valokuvan päältä — lisää kontrastia" |
| "Korjaa pelituntuma" | "Hyppy leijuu liian pitkään; tee siitä napakampi" |
| "Lisää jotenkin tunnistautuminen" | "Pelaajat tarvitsevat tilit, jotta tulokset säilyvät" |
| "Tee siitä nopeampi" | "Galleriasivulla kestää hetki ennen kuvien latautumista — näytä paikkamerkki tyhjän valkoisen sijaan" |
| "Tämä osio on huono" | "Suositukset näyttävät jälkikäteen lisätyltä — anna niille sama painoarvo kuin hintaosiolle" |
Toinen virhe: reagoiminen version yhteenvetoon eikä itse versioon
Toinen tapa, jolla ihmiset kompastuvat itseensä, on vastata chatin muutosyhteenvetoon eikä itse muutokseen. Joku lukee "siirsi aikataulun omalle sivulleen ja tummensi otsikon", muodostaa mielikuvan ja kirjoittaa palautetta tuota mielikuvaa vasten oikean sivuston sijaan. Useimmat "tämä meni väärin" -valitukset osoittautuvat olevan "en ollut vielä avannut esikatselua" — tulos oli hyvä tai lähes hyvä, ja huomautus koski oikeastaan olettamusta. Esikatselun läpikäyminen ennen kirjoittamista vie ehkä kolmekymmentä sekuntia, ja tuon askeleen ohittaminen on yksittäisistä syistä suurin sellaisten kierrosten aiheuttaja, joita ei olisi pitänyt olla. Vaikka arvioisit puhelimella kokouksen aikana, vilkaise esikatselu ensin — palaute kuvauksen kuvauksesta kertaa virheen nopeasti.
Aiheeseen liittyvä virhe on niputtaa toisiinsa liittymättömiä pyyntöjä yhteen viestiin ja menettää kyky tunnistaa, mikä aiheutti minkäkin muutoksen. Voit ehdottomasti pinota useita pyyntöjä ja saada ne kaikki samaan uuteen versioon — otsikon korjaava, aikataulun siirtävä ja mobiilinavigaatiota tiivistävä build on yhdellä kertaa helpompi katselmoida kuin kolme erillistä diffiä, koska arvioit sivuston yhtä yhtenäistä tilaa etkä kolmea muutosta liikkuvaa tavoitetta vasten. Ongelmat alkavat, kun pyynnöt eivät liity toisiinsa. Niputa aikataulusivun täydellinen uudistus yhteen globaalin värimuutoksen kanssa, ja jos jokin lopputuloksessa tuntuu väärältä, et yksinkertaisesti pysty sanomaan, mikä muutos sen aiheutti — johtuiko sivun huono luettavuus uudesta asettelusta vai uudesta väripaletista? Tämän selvittäminen maksaa lisäviestin ja kokonaisen uuden kierroksen vain yhden muuttujan eristämiseksi. Pidä "kaikki aikataulusivuun liittyvä" yhdessä viestissä ja "värisuunta" seuraavassa, vaikka mikään ei estäisi sinua yhdistämästä niitä — jokainen versio pysyy silloin selkeänä vertailukohtana, ja voit palauttaa tai säätää juuri sitä yhtä asiaa, joka sitä tarvitsee, sen sijaan että heittäisit pois muuten hyvän version yhden epäonnistuneen osan takia.
Kolmas virhe: jokaisen version käsitteleminen kertakäyttöisenä
Kolmas virhe on unohtaa, että versiokortti ei ole kuitti vaan työskentelyobjekti, ja ohittaa se, mitä se todella tarjoaa. Jokainen valmis kierros tuottaa kortin, jossa on live-esikatselu — oikea käynnissä oleva instanssi, ei kuvakaappaus, joten painikkeen klikkaaminen siinä tekee saman kuin tuotannossa. Mukana on Koodi-välilehti kaikkien muuttuneiden tiedostojen selaamiseen, mikä on tärkeää, jos olet tarpeeksi tekninen tarkistaaksesi jonkin tietyn asian (lähettääkö tämä lomake todella oikeaan päätepisteeseen?) odottamatta chat-vastausta vahvistukseksi. Lataa antaa sinulle raakatiedostot. Ja toimintovalikko on kohta, jossa versio lakkaa olemasta luonnos: julkaise se livenä, rakenna natiivit asennusohjelmat jos kyseessä on sovellus, toimita se kauppaan, tallenna koko paketti mallipohjaksi tulevia buildeja varten, tai ota se käyttöön itsenäisenä.
Ne, jotka ohittavat kaiken tämän, päätyvät yrittämään muistaa, oliko painike sininen vanhassa versiossa, sen sijaan että avaisivat vanhan version ja katsoisivat — koska korttien kertakäyttöisenä kohtelun jäljet ovat juuri tätä: luotetaan muistiin jossain, mikä on edelleen yhden klikkauksen päässä. Versiota 4 ei arkistoida tai jäädytetä, kun versio 7 julkaistaan. Sen esikatselu toimii yhä, sen koodivälilehti toimii yhä, sen toimintovalikko toimii yhä, ikuisesti. Kahden version vertaaminen ei ole diffin lukemista, vaan molempien esikatselujen avaamista rinnakkain ja niissä klikkailua. Kortti sisältää myös buildin vahvistustietueen — automaattisen tarkistuksen, joka vahvistaa buildin toimivan ennen kuin se annetaan sinulle valmiina — kohdistettuna juuri siihen versioon, mikä on toinen syy sille, miksi vanhojen korttien pysyminen elävinä on tärkeää: jos versio 6 vahvistui puhtaana ja versio 7 ei, sinulla on molemmat vertailtavana sen sijaan että luottaisit chat-viestiin, joka sanoo "korjattu".
Sama vaisto — kohdella työnkulkua jotain, mikä silmäillään läpi eikä käytetä — näkyy myös siinä, että ohitetaan jokaisen buildin jälkeen ehdotetut jatkotoimenpiteet. Ne eivät ole geneeristä täytettä; ne on poimittu itse buildista, joten ne tapaavat huomata asioita, joita et itse huomaisi omalla tarkastuskierroksellasi: tyhjä tila, jota kukaan ei suunnitellut, lomake joka ei vahvista lähetystä, sivu joka toimii työpöydällä mutta on ahdas mobiilissa. Niiden käyttöönotto ei ole pakollista, mutta niiden silmäily ei maksa mitään, ja ne ovat kohtuullinen korvike laadunvarmistuskierrokselle, jos sinulla ei ole aikaa klikkailla jokaista sivua itse läpi.
