Tendiamo a trattare le nuove tecnologie come il Santo Graal, un faro di luce e la risposta a tutto ciò che è lento, inefficiente e vecchio. E può essere - se è implementato con un carico di pianificazione e lungimiranza.
Ma bene, sappiamo tutti come va.
Durante i miei anni al governo, dove a volte sembrava che stessimo giocando un gioco di recupero tecnologico impossibile da vincere, ho imparato cosa può accadere quando questa previsione è data per scontata. Assomiglia un po 'meno al Santo Graal e molto più a sovraccarichi di costi, ritardi e soluzioni contorte a problemi altrimenti semplici.
Come ho appreso, una delle principali chiavi per un progetto tecnologico di successo è la relazione armoniosa tra il team aziendale e il team tecnologico. Nella mia esperienza, il team aziendale ha spesso guidato il cambiamento (ad esempio, abbiamo bisogno di un sistema più complesso per tenere traccia delle spese federali per le sovvenzioni), ma non siamo riusciti a realizzare un gran numero di progressi senza che gli sviluppatori e i project manager IT siano in grado di renderlo accadere. I progetti spesso finivano per essere ben lungi dall'essere armoniosi, il risultato di parlare essenzialmente lingue diverse e di mantenere aspettative molto diverse (un cambiamento che mi sembrava minore, ad esempio, si rivelava spesso importante per gli sviluppatori).
Ma il business e la tecnologia possono - e devono - essere amici. Le buone notizie? Raggiungere l'armonia non è davvero così complicato. Come ogni collaborazione, ha a che fare con la frequenza e la qualità della comunicazione, un insieme di obiettivi reciprocamente concordati e un piano per gestire il quasi inevitabile spostamento di tali obiettivi. Ecco alcune linee guida di base per gestire il divario tra tecnologia e business.
1. Scopo di inchiodare i requisiti la prima volta
Pensa ai requisiti aziendali come a un progetto. Non disegneresti una serie abbozzata di progetti per una casa, non li consegneresti all'appaltatore e gli augurargli buona fortuna. Non torneresti per tre settimane in costruzione e gli chiederesti di aggiungere un terzo piano e un quarto bagno, e forse una vetrata nel soggiorno. E certamente non disegneresti i tuoi progetti senza il contributo di un architetto e un ingegnere.
Un progetto tecnologico non è così diverso. Deve essere progettato con precisione e, una volta iniziato lo sviluppo, non è sempre facile accogliere le modifiche senza influire sull'intera fondazione. Questo è il motivo per cui è fondamentale essere il più completi possibile sin dall'inizio e ottenere l'input e l'esperienza necessari mentre si pensa a ciò che la soluzione richiederà. Intervista agli utenti finali per comprendere le sfide che devono affrontare ed esattamente come dovranno utilizzare la nuova tecnologia. Non fare ipotesi e non lasciare alcuna parte della pianificazione per dopo.
2. Ma riconosci che ti mancheranno pochi
Detto questo, ho trovato quasi impossibile immaginare ogni singola caratteristica di cui avevamo bisogno durante le fasi di pianificazione astratta. Inevitabilmente, una volta sviluppato il sistema, ci rendiamo conto che ci siamo dimenticati di chiedere una funzione di ricerca avanzata o un pulsante "salva e continua". Quando ci siamo avvicinati agli sviluppatori per chiedere loro gentilmente di soddisfare queste nuove richieste, abbiamo incontrato spesso frustrazione. Forse il nuovo cambiamento richiederebbe loro di annullare il lavoro che avevano già fatto e di riprogettare parti della soluzione. Forse l'avevamo immaginato impiegare due ore quando in effetti ci sarebbe voluto un giorno.
Potresti non essere in grado di prevenire queste rivelazioni successive nel gioco, quindi la cosa migliore che puoi fare è creare un buffer per adattarle. Aggiungi una settimana in più alla sequenza temporale iniziale e un ulteriore 5-10% sul budget. Molte organizzazioni, riconoscendo quanto spesso cambiano le aspettative, hanno adottato un approccio agile allo sviluppo, implementando la tecnologia in fasi per consentire una rivalutazione periodica. Qualunque sia il tuo approccio, non commettere l'errore di pensare di aver pensato a tutto sin dall'inizio. Non succede quasi mai.
3. Conoscere l'ambito Creep quando lo vedi
Man mano che il progetto avanza e vengono alla luce nuove esigenze, è importante distinguere tra quelli di cui hai veramente bisogno e quelli che desideri semplicemente. Chiedere ai vostri sviluppatori di soddisfare ogni campanello e fischio che la mente può immaginare in genere porta a progetti senza fine e risultati finali eccessivamente complessi. Ogni nuova richiesta, prima di essere fatta, dovrebbe essere prioritaria.
Quando stai considerando una funzione, poniti alcune domande di base: il sistema funzionerà senza di essa? Quanto tempo ci vorrà per implementare e quanti benefici alla fine verranno offerti all'utente finale? Se aspettiamo una versione futura per affrontarla, qualcosa andrà perso? È un esercizio di definizione delle priorità e a tutto può essere assegnato uno stato di alto, medio o basso. Se è basso, inseriscilo in un parcheggio figurativo: ho sentito parlare di aziende che hanno documenti di "richiesta di sviluppo di sogni" a cui chiunque può aggiungere idee e che gli ingegneri possono navigare a loro piacimento. Può sempre essere rivisitato come parte di una serie di miglioramenti da apportare una volta che il progetto è decollato e funziona correttamente.
4. Sviluppa un linguaggio comune
Ogni nuovo sistema ha una serie di obiettivi aziendali al centro. Ti consentirà di acquisire più dati, semplificare un processo esistente o offrire nuovi servizi ai tuoi clienti. È fondamentale che il team aziendale e il team tecnologico siedano prima di iniziare qualsiasi lavoro e comunicare questi obiettivi. Gli obiettivi aziendali non devono perdersi in un mare di discorsi tecnici e devono essere tenuti a mente con fermezza durante ogni fase del lavoro.
Sviluppare un linguaggio comune significa non solo fissare obiettivi collettivi, ma tenere traccia dei progressi in un modo che funzioni per tutti. Business e tecnologia possono utilizzare strumenti diversi per misurare il proprio lavoro, ma è necessario che vi sia almeno una visione del progresso condivisa. Questo potrebbe essere semplice come un piano di progetto o un foglio di calcolo con campi concordati, come date, obiettivi e percentuale di completamento, in modo che tutti abbiano accesso allo stato di ogni attività da completare. L'obiettivo è quello di evitare una situazione in cui il team aziendale pensa di essere a metà strada e il team tecnico dice che sono solo un quarto: tutti dovrebbero avere la stessa comprensione di ciò che è stato fatto e di ciò che resta da fare.
Puoi parlare in business plan e PowerPoints e possono parlare in codice, ma a meno che tu non comunichi chiaramente fin dall'inizio, non riuscirai mai a uscire da Babel. Un progetto tecnologico di successo riguarda un incontro delle menti, non solo all'inizio, ma ad ogni passo lungo la strada. Riconosci i tuoi presupposti e cerca di non farne troppi. Minore è il divario tra business e tecnologia, più facile sarà attraversare insieme i tuoi ponti.
