Deixa que la tecnologia existeixi abans d'acabar-la: el cas de la implementació iterativa

Resum de l'article:L'instint habitual en els projectes tecnològics és planificar a fons, construir completament i llavors publicar. El resu…Pensem en els nostres clients, així que hem fet una breu selecció de l'article. Prem per entendre ràpidament la idea principal.

L'instint habitual en els projectes tecnològics és planificar a fons, construir completament i llavors publicar. El resultat és un llarg interval durant el qual no arriba informació real d'usuaris reals, seguit d'un llançament que sovint revela que unes parts del sistema importen molt més que d'altres. L'enfocament més productiu és posar alguna cosa real en mans de clients reals el més aviat possible i deixar que l'experiència de fer-la servir reveli que construir a continuació.

Hi ha una creença específica que fa que els projectes tecnològics durin més del necessari, i no és sobre complexitat tècnica ni pressupost. És la convicció que el sistema necessita estar complet abans que se li permeti ser experimentat. El portal de client complet abans que cap client el faci servir. El flux de treball automatitzat complet abans que cap part d'ell s'executi. El xatbot acabat amb cada pregunta freqüent coberta abans que aparegui al web.

La intenció darrere d'aquesta creença és respectuosa: vols presentar alguna cosa polida, alguna cosa que compleixi l'estàndard que els teus clients esperen. La conseqüència, però, és que el punt en que arriba informació real d'ús real s'empeny cada vegada més cap al futur. I aquesta informació, el patró de com les persones interactuen realment amb el sistema, és la dada més valuosa disponible per a les decisions sobre que construir a continuació.

El patró en com es desenvolupen les plataformes

Cada plataforma digital que està en ús generalitzat avui, cada mercat en línia, cada eina professional, cada aplicació de consum, va començar amb una versió dramàticament més simple que la que existeix ara. La versió inicial feia un nombre petit de coses, algunes d'elles imperfectament, i les persones que la van fer servir van dir a l'equip, mitjançant el seu comportament i de vegades directament, que necessitaven més i on trobaven fricció.

Les decisions que van donar forma al desenvolupament d'aquelles plataformes, les funcionalitats que es van tornar centrals i les que van quedar en desús silenciosament, es van prendre amb aquelles dades d'ús real i no des de l'especificació inicial. L'especificació era el punt de partida, no la guia. La guia era l'experiència real de persones reals usant un producte real.

Aquesta dinàmica s'aplica directament als negocis de serveis que implementen tecnologia per primera vegada. L'empresari i l'equip d'implementació junts tenen una imatge clara del que la tecnologia ha de fer. Aquesta imatge val la pena actuar-hi. És la base per a la primera versió. Però la versió següent, i la que ve després, hauria d'estar modelada significativament per allò que els clients que van usar la primera versió van experimentar.

Per que la visibilitat importa tant com la qualitat

Hi ha una dimensió pràctica en l'argument per publicar aviat que val la pena dir directament. Una inversió tecnològica, per ben dissenyada que estigui, produeix valor només si és visible, està en ús i compleix amb el que va ser construïda per fer. Un sistema encara en desenvolupament no fa cap d'aquestes coses. Un sistema que es publica, encara que sigui en forma limitada, pot ser vist, pot ser experimentat, i pot començar a demostrar el seu valor.

Per a un negoci de serveis, això significa que un sistema de recordatoris de cites funcionant en la seva forma més simple, un sol missatge a un interval fix abans de cada cita, és més útil que un sistema sofisticat de recordatoris en múltiples passos que encara s'està configurant. La versió simple fa alguna cosa real per als clients que el reben i genera feedback real. La versió sofisticada, fins que es llança, no genera res.

Això no és un argument per llançar productes que estiguin mal construïts o que fallin en la seva promesa central. És un argument que l'estàndard per al que qualifica com a "llest per publicar" en la majoria dels projectes tecnològics empresarials s'estableix més alt del necessari, i que el cost d'aquell temps extra de desenvolupament es paga en benefici retardat i en absència de la informació del món real que hauria fet més efectiva la fase següent de desenvolupament.

Com GLC estructura la implementació per a això

Els plans d'implementació que construïm amb els clients inclouen punts de revisió explícits després de cada etapa de publicació. En cada punt de revisió, les preguntes que fem no són només si la tecnologia està funcionant com es va dissenyar, sinó que revela l'experiència de fer-la servir sobre el que més importa a les persones a qui està dissenyada per servir.

Les preguntes típiques de revisió inclouen com està trobant l'equip administratiu el nou flux de treball, on continuen fent coses manualment que el sistema hauria d'haver cobert, que estan mencionant o preguntant els clients en les seves interaccions amb el negoci, i si alguna part de la implementació està creant fricció que no s'havia anticipat. Les respostes a aquestes preguntes, recollides després de cada etapa d'un desplegament per fases, produeixen un conjunt de prioritats de desenvolupament que està fonamentat en l'ús real i no en suposicions de planificació.

Les empreses que acaben amb entorns tecnològics que les serveixen genuïnament gairebé sempre van arribar al seu estat actual mitjançant aquest tipus de procés iteratiu. El sistema complet que tenen ara és el producte de molts cicles d'ús, observació i ajust. El camí cap a un sistema complet és més llarg en temps de calendari, però produeix consistentment sistemes que es fan servir en lloc de sistemes que simplement es toleren.

Si vols parlar sobre com estructurar una implementació per fases per a un projecte tecnològic que estàs considerant, és una conversa on GLC pot proporcionar un marc específic basat en el que ha funcionat en contextos similars. Escriu-nos.