{"id":791,"date":"2018-02-19T15:29:47","date_gmt":"2018-02-19T14:29:47","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/estratto-il-giusto-modo-per-scegliere-tecnologia\/"},"modified":"2018-02-19T15:29:47","modified_gmt":"2018-02-19T14:29:47","slug":"estratto-il-giusto-modo-per-scegliere-tecnologia","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/estratto-il-giusto-modo-per-scegliere-tecnologia\/","title":{"rendered":"Il modo giusto per scegliere la tecnologia, un estratto"},"content":{"rendered":"
\n

Nota degli editori:<\/b> siamo lieti di condividere un estratto dal Capitolo 4 del nuovo libro di Tony Byrne e Jarrod Gingras, The Right Way to Select Technology<\/em>, disponibile adesso da Rosenfeld Media<\/a>.<\/p>\n<\/div>\n

Dopo aver stabilito un business case solido, le imprese tipicamente cominceranno ad assemblare lo spesso temuto \u201cdocumento dei requisiti\u201d, o, pi\u00f9 accuratamente, un insieme di documenti, fogli di calcolo e diagrammi che compongono un pacchetto dei requisiti.<\/p>\n

In realt\u00e0, i grandi pacchetti di requisiti forniscono un falso senso di sicurezza. La tecnologia digitale moderna comporta l’interazione con gli schermi da parte di persone reali. I leader della selezione della tecnologia devono catturare questi requisiti interattivi, ma anche rimanere realistici in questa fase riguardo alla propria incapacit\u00e0 di sapere a fondo quello di cui ha realmente bisogno la loro azienda e quello che alla fine verr\u00e0 adottato.<\/p>\n

Questa sezione mostrer\u00e0 come i lunghi fogli di calcolo pieni di requisiti \u201ccosa\u201d non funzionano veramente e al contrario si concentrer\u00e0 su \u201ccome\u201d potrebbe funzionare una soluzione. Il modo migliore per rivelare le differenze chiave tra i fornitori \u00e8 di creare delle \u201cuser stories\u201d narrative con delle \u201cpersona\u201d (grossomodo l’equivalente dei casi d’uso con gli attori).<\/p>\n

In altre parole, raccontate storie testabili<\/em>. Gli utenti business hanno delle storie, cos\u00ec come le hanno i clienti, i partner, gli sviluppatori, i sysadmin, i designer, i revisori contabili e gli altri.<\/p>\n

Questa sezione vi guider\u00e0 attraverso un approccio per raccontare tali storie in modo che contribuiscano di pi\u00f9 a differenziare tra i fornitori di tecnologie.<\/p>\n

\n

Carpire requisiti che non facciano pena<\/h2>\n

Un’ottima comprensione dei requisiti della vostra organizzazione \u00e8 fondamentale per il successo del progetto. Ottenere quella comprensione implica una raccolta di informazioni da vari gruppi di stakeholder, potenzialmente utilizzando una serie di tecniche.<\/p>\n

Notate che in questa fase, i vostri requisiti dovrebbero essere incentrati sul business e sull’utente, piuttosto che specifiche tecniche dettagliate (Ci arriveremo nel Capitolo 6, \u201cAsk Questions That Really Matter\u201d). Il cruciale step finale qui \u00e8 analizzare e assegnare una priorit\u00e0 ai vostri requisiti per poter determinare quali enfatizzare nel RFP e nelle demo e nelle gare seguenti.<\/p>\n<\/div>\n

\n

Come non<\/em> articolare i requisiti<\/h2>\n

Qualsiasi cosa facciate, evitate i fogli di requisiti tipo \u201ccheck box\u201d, in cui chiedete al produttore: \u201cPuoi fare questo? Puoi fare quello?\u201d<\/p>\n

In pratica, i produttori hanno gi\u00e0 visto tutte queste domande e hanno capito come spuntare tutte le caselle. Ma quel che \u00e8 peggio \u00e8 che tali fogli di calcolo convertono la comprensione di quella che dovrebbe essere un’attivit\u00e0 human-centered, interattiva, in una serie sterile di attivit\u00e0 riga per riga adatte ai robot che ripetono sempre lo stesso task.<\/p>\n

Il tranello tipico qui comincia cos\u00ec: una business analyst (BA) va in giro a fare domande agli utenti e ad altri stakeholder e finisce con una lunga \u201cwish list\u201d di features. Excel le permette di assegnare una categoria a queste feature, il che \u00e8 comodo, ma dal momento che il numero di righe \u00e8 infinito, il suo spreadsheet tender\u00e0 ad enfatizzare la completezza piuttosto che l’impatto sul business.<\/p>\n

\n