Tagasiside jaoks pole ideaalset suurust
Mida rohkem ma seda postitust koostasin, seda rohkem tundus, et peaksin kirjutama teatud tüüpi TL;DR-i teatud inimestele, kes seda loevad. Aja säästmiseks on see siin:
Kirjutan seda neile, kes pole füüsilisest isikust ettevõtjana või projektijuhtimises uued või kellel on üldiselt vähem kogemusi kui neile, kes küsivad: „Miks sa seda kirjutad?" Lõppkokkuvõttes õpib enamik meist sellest mingil hetkel selgeks. tööstusharu, kuid kui saame üksteist aidata varem või hiljem, saame sellest kasu kõik.
Kui olete pärast ülaltoodud märkuse lugemist endiselt huvitatud, siis eeldan, et soovite selles suhtlusaspektis paremaks saada. Mis on hea, sest nii olen ka mina 😏 ja väikese tagasisideahela kasutamine on üks viis, kuidas seda teha.
Igal tööstusharul on oma kõnepruuk ja paljud meist naeravad selle üle, kuid me kõik jätkame selle kasutamist professionaalses keskkonnas. Me oleme nii naljakad.
Igatahes on meie tööstuses üks fraasidest, mida me palju kasutame – ka mina – „tagasiside”. Esimest korda kohtasin seda fraasi võimendite tagasiside kohta. Sellel polnud tarkvaraga midagi pistmist. Sellegipoolest kasutame seda oma tegevuses üldiselt, et viidata sellele järgmiselt:
- päringu, kommentaari või üldise teabe saatmine kliendile,
- nimetatud teabe kohta kliendilt vastuse saamine.
Ja neile, kes pole selle ideega harjunud (sest on neid, kes teevad "suure paugu väljalaseid", millest räägin minuti pärast), peetakse tagasisideahelaid tavaliselt väikeseks või suureks.
Mida kauem olen tarkvaraga töötanud, seda rohkem olen alati sihiks võtnud väikese tagasisideahela, ükskõik mis.
Täiuslik tagasiside ahel
Väike tagasisideahel tähendab sagedast suhtlust ettevõtte ja kliendi vahel (nii et loomulikult on suur tagasisideahel harvema suhtluse korral).
Kui kasutate žargooni, siis mõelge sellele vähemalt mingil lõbusal viisil, eks?
Kuid teate kogu seda kõnepruuki, mida ma artikli alguses mainisin? Tavalise teisendamise korral ütleksin lihtsalt:
Projektiga töötades eelistan tihedamat suhtlemist.
Ja põhjus, miks ma seda eelistan ja isegi vaikimisi sellele eelistan, on see, et kui on vaja lahendust luua, olenemata suurusest, kellelegi teisele, tuleb alati arvestada liikuvate osadega.
Kui projektil on mitu osa, on mitu kohta, kus midagi võib vajada kohendamist või muutmist (või mis võib mõjutada kogu süsteemi), ning selle õigeks saamine varakult, mitte hiljem säästab palju aega (ja seega raha) ja stress enamiku asjaosaliste jaoks.
Mis siis?
Miks aga sellest kirjutada? Minu jaoks on põhjus selles, et mida kauem ma väikest kauplust juhin, seda rohkem kuulen klientidelt probleemidest, mis tulenevad varasemate projektide selguse, suhtluse ja projektijuhtimise puudumisest.
Jama. Ma ei taha seda tüüpi operatsiooni läbi viia. Nii et seda on lihtne parandada, eks?
Veelgi enam, arendustööstus on täis inimesi, kes võtavad vastu projekti nõuded, eeldavad, et saavad kõigest vajalikust aru ja tulevad siis tagasi, et ehitada midagi, mis mitte ainult ei lähe sihile, vaid näeb välja vaid mõnevõrra selline, nagu klient kavatses.
See ei pruugi olla programmeerijate koputus, kuid kogu selle sihtmärgi [puuduva] saab parandada, kui suhtleksime nendega, kellega koos töötame, veidi sagedamini kui mitte.
Ära eelda, et tead, mida nad tahavad.
Selle asemel esitage küsimusi, täpsustage nõuet, töötage funktsiooni kallal ja esitage seejärel kliendile lavastuskeskkonnas. Nad saavad teada, kas olete ehitanud selle, mida nad küsisid. Kui jah, siis järgmise funktsiooni juurde. Kui ei, siis on veel tööd teha. Sel viisil tegutsemine muudab nii palju projektides tekkivaid pingepunkte sujuvamaks.
Ja jah, paljude küsimuste esitamine võib muutuda tüütuks ja isegi tüütuks. Suur asi. Mainige algusest peale, et enne selle lahendamise proovimist küsite probleemi täielikuks mõistmiseks palju küsimusi. Põhjendage, miks te seda teete. See kipub end hästi ära tasuma.
Suure Paugu väljaanded
Varasemas postituses mainisin "suure paugu väljalaseid" ja see viitab üldiselt ideele, et klient esitab teile nõuded, naasete selle kallal nädalateks järjest tööle, siis ilmute tagasi ja ütlete: "Hei, ma Olen valmis – vaadake! ainult selleks, et teada saada, et see on kaugel.
Kui ma peaksin seda kontekstualiseerima teatud tüüpi tagasisideahela raames, siis ma ütleksin, et seda pole olemas. See pole isegi suur, sest tagasisidet ei küsitud. See on lihtsalt:
- Siin on projektile esitatavad nõuded,
- Olen projektiga lõpetanud.
Sageli viib see selleni, et arendajad saavad nõuetest valesti aru, kliendid on edenemisest teadmatuses ja kogu projekt läheb lõunasse. Lihtsamalt öeldes, ära tee seda nii.
Ideaalne suurus?
Ma ei tea, milline on tagasisideahela täiuslik suurus. Mõned kliendid, kellega olen koostööd teinud, registreerivad end iga päev, on kuskil iganädalased registreerimised ja mõned on öelnud, et "täitke see lihtsalt ja andke mulle teada, kui olete lõpetanud."
Iganädalased sisseregistreerimised, kohustused, vabastamised jne on tavaliselt minu lemmikud, kuid see on tingitud projekti suurusest ja meeskonna suurusest, kellega koos töötan. Sõltuvalt ülesandest pole ka igapäevane halb.
Ma ei tee kunagi suure paugu stiili, isegi kui klient ütleb, et see on okei. Mulle ikka meeldib, kui minu enda terve mõistuse jaoks on kontrollpunktid. Nii et mis tahes tüüpi tagasisideahel sobib teile, teie meeskonnale ja teie kliendile kõige paremini, on ideaalse suurusega.