” funkció kérés!!!”
a szoftvermérnökök gyakran használják a csatakiáltást, hogy lekicsinyeljék az ügyfél problémájának sürgősségét. Végül is nincs idő új funkciók hozzáadására, amikor a soha véget nem érő hibanaplóra nézünk, amely előttünk áll.
az amerikai szoftvermérnökök számára a hiba és a szolgáltatáskérés közötti különbség kristálytiszta. A hiba eltérés a kód tényleges működése és a kód működésének módja között. A szolgáltatáskéréshez új kód szükséges egy olyan eset kielégítéséhez, amelyet az aktuális kódbázis nem képes kezelni.
ez a fajta gondolkodási folyamat mindig ahhoz az általánosabb kérdéshez vezet, hogy hogyan kell használni a DoneDone-hoz hasonló szoftvereket. Ha a szervezet egy típusú szoftvert használ a hibák naplózására, egy másik típusú szoftvert a közelgő feladatok kezelésére, és egy másik típusú szoftvert a funkciókérések nyomon követésére?
sok mentális energiát töltünk azzal, hogy megpróbáljuk szitálni az ügyfél vagy az ügyfél által naplózott kérdéseket, megpróbálva meghatározni, hogy egy problémát a “bug” vödörbe vagy a “feature request” vödörbe dobunk-e. A tanácsadói munka során, amikor egy előre meghatározott megállapodáson dolgozunk arról, hogy a szoftver hogyan viselkedjen, ennek van értelme. A funkciókérések felár ellenében igényelhetők.
de ha csak a jó szoftverek építésének tiszta gyakorlatáról van szó, különösen, ha saját termékeinken dolgozunk, mennyire kell törődnünk azzal, hogy egy problémát így kategorizáljunk?
hagyjuk, hogy a technikai dolgok (és a technika) akadályozzák a problémák megoldását.
Robert Martin (más néven Bob bácsi) sokat beszél a szoftverről. Úgy véli, a Web csak egy szállítási mechanizmus, semmi több. Ez nem a végfelhasználói élmény, és nem a szoftver célja. Ez csak egy apró kis buta részlet. Mégis, amikor mi programozók programozunk, alkalmazásaink architektúráját túlságosan befolyásolja az a tény, hogy ez egy webes alkalmazás.
ugyanígy, mi lenne, ha azt a kifejezést használjuk, hogy “egy dolog, amit meg kell tenni”, hogy egy buta részlet?
a “dolgot” naplózó személy szempontjából valóban számít neki, hogy új funkciót kér, szemben a hiba felfedezésével? Csak azt akarja, hogy a problémáját egy másik emberi lény oldja meg, és lehetőleg tudja, mikor lehet megoldani a problémáját.
lehet, hogy egyértelműbben látja a technikát, ha elhagyjuk a szoftvervilágot. Amikor a vízvezeték-szerelő bejön, hogy megjavítsa a szivárgó zuhanyt, gondolom, nem érdekli a részlet. Ha a zuhanyfejet helytelenül telepítették (hiba), vagy ha a tömítés megtört (hiba), vagy ha a Teflon szalag hiányzott egy olcsó csőből (funkció), akkor csak annyit érdekel, hogy mennyi ideig tart a javítás és mennyit kell fizetnie.
hiba vagy kérés? Mindkettő. És nem számít.
a múlt héten a mamut kiadott Kin, egy HR szoftver eszköz a kisvállalkozások számára. Kin ad egy egyszerű módja annak, hogy nyomon kövesse az egyes alkalmazottak időt le kéréseket. Az egyik dolog, amit Kin jelenleg nem tesz, az, hogy megkülönbözteti a hétvégéket és az ünnepeket a munkanapoktól. Tehát, ha egy teljes hetet szeretne levenni a Hálaadás ideje alatt, manuálisan kell megadnia azt az órát,amelyet kér.
a csapat már kapott néhány kérést, hogy a Kin automatikusan végezze el ezt a követést. Valójában a kiadási sorban van. De ha be van jelentkezve, bármilyen helyen is be van jelentkezve, a Kin csapatnak hibának, funkciókérésnek, feladatnak vagy tennivalónak kell-e tekintenie?
a belső Bob bácsit hívva a válaszom egyszerű: nem számít, hogyan osztályozza a kérést. Ez csak egy buta részlet.
ez nem azt jelenti, hogy egyáltalán nem kellene osztályoznunk. A Kin csapat a “szolgáltatáskérés” alatt jelölheti meg a problémát, és először a kritikus problémák kijavításán dolgozik (például egy engedélyezési problémával rendelkező felhasználó). Ez remek és remek, és helyes megközelítés.
hiba lenne azonban automatikusan feltételezni, hogy az all things-we-call-feature-requests kevésbé sürgős, mint az all things-we-call-bugs. Ez azt a meglehetősen apró részletet teszi a kérdés osztályozásának középpontjává, amikor megoldjuk. Ennek nem így kellene lennie. A nap végén, ezek a kérések egyszerűen olyan dolgok, amelyeket meg kell oldani.
legyen a technikai részlet a buta részlet
ebből a célból az összes kérésnek adott címke nagyrészt nem fontos. Ami még fontosabb, hogy valaki ellátja őket, és van egy általános elképzelés arról, hogy ezeket a kéréseket mikor fogják megválaszolni. Ami még fontosabb, hogy 33% – kal több felhasználó részesül az a tétel címzéséből a B tételhez képest. függetlenül attól, hogy milyen típusú a tétel vagy B elem, az a tétel értékesebb. Ez az. Semmi több.
tehát, ha legközelebb túl sok időt töltesz a feladatok, hibák, funkciókérések és feladatok kategorizálásával, ne felejtsd el a technikai részleteket. Ezek csak a buta részletek.
regisztráljon egy DoneDone fiókot 30 másodpercen belül. Szeretne többet olvasni Ka Wai Cheung – tól? Ka Wai új könyve a modern programozóról, A fejlesztői kód, elérhető e-könyvben és nyomtatásban. Akkor kövesse őt a Twitteren @ developerscode.