Guarda che se sei padrone di una metrica ti devi porre poche domande e fare qualche moltiplicazione. Ci vogliono pochi minuti ed i framework ti aiutano a tenere in considerazione cose che, con l'esperienza pregressa, potresti benissimo trascurare o non sapere. Ti aiutano anche a darti fiducia se ti chiedono di fare qualcosa di nuovo, perché l'esperienza ti porta a dire che se una cosa è troppo diversa, non si può fare, mentre invece non è quasi mai così.
Per scrivere il tool, io mi soffermerei molto poco su quello che so fare io o sulla mia esperienza e fare domande del genere:
Con quanti componenti e sistemi si interfaccia?
Ha bisogno di dati che sono altrove?
Chi conosce le specifiche del progetto o dei componenti?
Sono persone interne o esterne, in sede o meno?
Quali sono gli obiettivi del progetto (performance/produttività/qualità)?
C'è documentazione o bisogna produrla?
Devo integrare qualcosa di pre-esistente (se è un tool magari va innestato su un egine?)?
Bisogna evolvere un tool o iniziare from scratch?
Ci sono persone che usavano la vecchia versione (o un equipollente) con cui parlare?
Perché sono queste le cose che fanno la differenza e spesso, se la mia esperienza fosse basata su progetti di ben altro tipo (magari tranquilli, fatti con gruppetti locali), non me le porrei nemmeno quelle domande, che però faranno l'80% del mio tempo di lavoro. Magari mi soffermerei (sbagliando) sul fatto che mi si chiede un tool Java quando io conosco il C++ o che per salvare i dati del tool devo usare Oracle (che non ho mai usato), invece che MySQL che conosco a menadito.
Inoltre, se qualcuno non sa rispondere a questi questiti, forse si riesce a fargli anche capire che non è ancora ora che mi assegnino il task... Staremo solo sprecando soldi su presupposti incerti.
