Koliko uložiti u defanzivan dizajn?
Tim je nedavno preradio frontend jedne popularne ActiveCollab mogućnosti (Workload), sa ciljem da se unaprede performanse. U toj preradi je preskočen jedan defanzivan scenario. Kada se zadaci prebacuju sa jedne osobu na drugu, sistem bi trebalo da ne dozvoli prebacivanje na osobu koja nije u projektu u kom je zadatak.
To u novoj verziji nije bilo pokriveno. Korisnici su prijavili problem da prebacivanje zaduženja ne radi, jer su oni to tako doživeli, nesvesni pozadinskog ograničenja. Tim je krenuo da scenario pokrije na isti način kao i u staroj verziji, ali se implementacija nove i stare verzije toliko razlikuju da je procena za implementaciju starog rešenja prešla iz par sati u par dana.
Kada su mi skrenuli pažnju na to, moja preporuka je bila da se okanu starog rešenja i da probaju da nađu najjednostavnije novo rešenje koje će sprečiti korisnika da proba da prebaci zadatak na nekoga čije taj zadatak ne može biti zaduženje. Detalji rešenja me nisu puno zanimali, samo da bude jednostavno i brzo za realizaciju.
Kao razlog za nezainteresovanost da se udubimo i potrošimo puno vremena na “najbolje” rešenje je stav da se na defanzivonosti ne pravi velika korisnička vrednost. Rešenje treba da bude takvo da korisnike ne dovodimo u stanje greške ili da im je jasno kako da iz istog izađu ako već moraju u njemu da se nađu. To je dovoljno.
Sa druge strane, mesta gde se pravi korisnička vrednost su pozitivne stvari, takozvani “happy path” - planiranje rada kroz projekte i zadatke, praćenje vremena, pravljenje fakture i primanje uplate. Defanzivne mere treba imati na umu i pokriti što jednostavnije i jeftinije je moguće, da bi ostalo više vremena da se bavimo onim što pravi razliku.
Šta kaže struka?
