I believe the hard part of building software to be the specification, design, and testing of conceptual construct, not the labor of representing it and testing the fidelity of the representation.
The hardest single part of building a software system is deciding precisely what to build
The mythical man month.
L’esperienza degli anni mi fa sempre di più apprezzare questa citazione, i problemi tecnici si superano, i bug vengono corretti, le tecnologie evolvono ed aiutano, ma se non si capisce cosa si deve costruire… è tutta fatica sprecata. Per questa ragione ritengo che il successo di un progetto non può prescindere da un buon analista, figura che però è quantomeno difficile da trovare. Spendendo i miei due cents penso che un buon analista:
1) debba capire quello che serve al cliente e non imporre le proprie scelte
2) debba necessariamente dialogare con i futuri utenti e fruitori del prodotto, e chiedere a loro opinioni su come vorrebbero il software
3) generare una documentazione molto snella dei requisiti e non generare documenti chilometrici pieni di “Fuffa” per intortare il cliente
4) includere il cliente nel ciclo di vita del prodotto
5) assumere un atteggiamento socratico “so di non sapere”
in particolare il punto 5 è molto importante, nei processi industriali ad esempio, bisogna approcciare l’analisi sapendo di non conoscere nulla del processo, e quindi è necessario fare interviste a tutte le figure, dai manager fino agli operai che lavorano sulla catena, approcciando ogni colloquio con l’attitudine di chi non sa nulla e deve apprendere da chi ha davanti. Spesso invece si adotta un approccio del tipo “arrivo io e ti spiego come devi lavorare”, che è foriero di problemi di ogni tipo.
alk.