Új build, új fejlesztés érkezik. Telepíted, használni kezded, de már az elején furcsán viselkedik. Aztán újabb és újabb hibákat fedezel fel. Szeretnél eljutni legalább egy alap funkció leteszteléséig, de annyi a hiba, a kavarás, akkora szar az egész, hogy legszívesebben hagynád a fenébe. Az ösztönös reakció, hogy ezt most vigyék vissza, javítsák ki, és majd szóljanak, ha lesz belőle használható verzió.
Az érzés valid. Nagyon rossz minőségben kiadott verziók voltak és lesznek is, természetes, hogy semmi kedved időt tölteni egy ilyennel.
A fenti ösztönös reakció (hogy vigyék vissza, javítsák ki, aztán majd szóljanak) azonban rossz, mert se vezetői szinten, se a fejlesztők nem tudnak mit kezdeni azzal, hogy „szar az egész”. Főleg, ha az a dolgod, hogy a minőségi problémákat higgadtan, tényekkel és részletekkel alátámasztva prezentáld.
Ezért a megoldás, hogy engedd el, mi mindent akartál letesztelni aznap. Helyette válassz ki 1 darab problémát, és csak arra koncentrálj. Riportold le úgy, mintha az az egy probléma lenne a builddel összesen. Higgadtan vizsgáld meg, reprodukáld többször, dokumentáld, küldd el. Aztán válassz egy következőt, azt is dolgozd ki a szokásos alapossággal, majd ebéd után egy harmadikat is.
Ha egy buildről egy nap alatt három súlyos hibát be tudsz írni, akkor már vezetői szinten is megszólal majd a csengő, hogy valami baj van. Másrészt a fejlesztők sem tudják az egész programot kijavítani, hanem csak konkrét problémákat, egyesével. Segíts nekik, hogy lássák, pontosan hány darab hiba van, van-e köztük esetleg összefüggés, milyen sorrendben kellene javítani őket.