Goodhart törvényének alkalmazása a szoftverekben
Kerülje el a rossz mutatókat, és mentsen meg mindenkit, nem csak magát
A nem kívánt oldalak megtekintésére szolgáló rejtett linkektől és hirdetésektől a hamis előfizetési tervekig, amelyek arra késztetnének, hogy fizessen a haszontalan szolgáltatásokért, a világ tele van alkalmazottakkal, akik azt hiszik, hogy a számok csak ott számítanak, ahol követik azt a rossz szokást, hogy bármit megtesznek, hogy elkészítsék a lapokat. tele akkor is, ha a jövőben a dolgok rosszabbak lesznek. Ezekben a helyzetekben Goodhart törvénye lép kézbe.
Mi a Goodhart törvénye?
A törvényt eredetileg Charles Goodhart fogalmazta meg azzal a céllal, hogy bírálja országa kormányát amiatt, hogy az a későbbiekben takarékosan használt célok alapján tartja be a monetáris politikát az alábbi formátumban.
Amikor egy intézkedés célponttá válik, megszűnik jó intézkedés lenni – Goodhart törvénye.
A mérőszámok követése ennek érdekében nem jó dolog, és ez minden épeszű ember számára nyilvánvaló, és a Goodhart törvénye ezt közvetlenül kimondja.
Jó példa a Goodhart-törvényre az „ügyfélszolgálati telefonközpont”, amely az ügynök által kezdeményezett hívások számára összpontosít a szolgáltatás minősége helyett, lehetővé téve az ügynökök számára, hogy a korábbinál gyorsabban zárják le a hívásokat anélkül, hogy törődnének azzal, hogy a szolgáltatást megfelelő módon nyújtották-e. út.
Mivel a törvény széles körben használható, alkalmazzuk néhány olyan problémára, amelyet a szoftverfejlesztés világában tapasztalhatunk.
Egyéni mutatók
Mindig nehéz meghatározni az egyének teljesítményének mérését, különösen a szoftverfejlesztésben, ahol az emberek többnyire csendben dolgoznak, és munkájuk nem látható a nyilvánosság számára, bár a modern eszközökkel van néhány híradás, például, hogy egy csapattag hány sornyi kódot írt. ami később azzá fejlődött, hogy hány PR-t (Pull Requests) vagy CR-t (Code Reviews) vetett fel egy csapattag, ami az elején jól hangzik, de valójában nem az.
A PR-ok/CR-ek száma egyáltalán nem jó mérőszám, mivel ez csak egy gyors javítás lehet néhány olyan hibára, amelyekre például az egységteszt nem terjedt ki, még a kódszámok sorai sem jók, mivel megváltoztathatók számos oka lehet, például egy egyszerű visszaállítás, ha a funkció meghibásodik, vagy egyszerűen nem hozza meg a kívánt eredményt a vállalkozás számára, így a számok csökkenni fognak!
Az ilyen mérőszámok haszontalanok, ha nem értjük az egyéni munka mögött rejlő valódi igényt, és minden esetre a megfelelő mérőszámot hozzuk létre, amellyel egy egyén szembesülhet, ahelyett, hogy olyan unalmas mérőszámokat követnénk, amelyekről senki sem tudja, miért léteznek a kezdetektől, az alábbi kódlefedettségi eset remek példa erre.
Tesztelési mérőszámok
Szoftverben kötelező a tesztelés, és ehhez nem fér kétség, de ne felejtsük el, hogy nem minden teszt igazán pontos, sőt némelyikük csak töltelék (mint például a kódlefedettség tesztjei, amelyeket az emberek a százalék növelése érdekében végeznek).
A tesztelés során az emberek mindenről feltételezéseket tesznek, különösen üzleti szempontból, ahol a PM-ek úgy vélik, hogy amit jónak találnak, az jó legyen a felhasználónak/ügyfélnek, ami téves, ehelyett eszközökkel kell rendelkeznünk a felhasználó és az alkalmazás közötti valós interakció rögzítésére, valamint felmérésekre. amelyek összegyűjtik a felhasználók visszajelzéseit a jobb eredmények érdekében a jövőben.
Áttérve az igaz/hamis mérőszámokról, ahol az emberek arra koncentrálnak, hogy ez a fokozott interakció vagy sem, a mintavételi és kiválasztási technikákra kell összpontosítanunk, hogy olyan intézkedéseket tegyünk, amelyek hosszú távra összpontosítanak, ne csak a jelenlegi helyzetre, hogy a munkával dicsekedjünk, ahelyett, hogy a felhasználókat szolgálnák ki. helyes utat.
Katasztrófamérők
A szoftverek katasztrófái bárkivel megtörténhetnek bárhol, a nyílt forráskódú projektektől, mint például az „ESLint”, a nagyvállalatokig, amelyek világszerte szolgálják az embereket, mint a „Facebook”, így ezek kezelése és az eredmények halott utáni megosztása kötelező, még akkor is, ha senki sem akarja. problémákat okoz a szoftverükben, de ez bárkivel megtörténhet, és úgy gondolom, hogy a postmortemek nagyszerű módja annak, hogy technológiai cégek és magánszemélyek tanuljanak egymástól.
A cégek azonban mérgező módon kezelik a poszthalálozást, és olyan mérőszámot hoznak létre, hogy a kevesebb postmortem jobbá tenné a csapatot, és emiatt a csapatok vagy hazudnak, vagy problémákat dobnak más csapatoknak! Egy ilyen cél követése a nyilvános megszégyenítés kultúráját generálná, ami óriási problémát fog okozni a jövőben, ahol az emberek hazudnak, hogy megmutassák, hogy jól csinálják, ahelyett, hogy rámutatnának a hibákra, és tanulnának belőlük. feddhetetlen kultúra.
Minden csapatnak rendelkeznie kell egy postmortem szerelővel, aki felülvizsgálja a problémákat, és jó korrekciós tervet készít az ilyen problémák jövőbeni elkerülése érdekében, de a kevesebb halotthalálra vonatkozó cél követése a hibáztatás és a figyelmetlenség kultúráját teremtené (ezt sok vállalatnál tapasztaljuk). .
Következtetés
A mérőszámok követése ennek érdekében nem igazi siker, és a vég kezdeteként tekinthet rá!
Kezdje el újradefiniálni a sikermutatókat, még akkor is, ha jól működnek, mert mindig lesz mód a mutatók feltörésére és feleslegessé tételére.
