El triangle de desenvolupament web

Tots els nostres contractes amb els nostres clients són compromisos mensuals en curs. Molt poques vegades perseguim un projecte fix i gairebé mai no garantim la cronologia. Això pot semblar aterrador per a alguns, però el problema és que l'objectiu no hauria de ser la data de llançament, sinó els resultats empresarials. La nostra feina consisteix a obtenir resultats empresarials als nostres clients, no prendre dreceres per fer dates de llançament. A mesura que Healthcare.gov està aprenent, aquest és un camí que conduirà a les expectatives perdudes.

Per intentar mantenir els projectes dels clients puntual, separem els requisits en must have (que compleix els resultats de l'empresa) i agradable de tenir (millores opcionals). Tampoc planifiquem mai la finalització en el moment del llançament, ja que sabem que sempre caldrà fer alguns canvis.

Robert Patrick és CEO de Laboratoris de doctorat, una agència que dissenya, construeix i llança llocs web per a moltes empreses de Fortune 500. Robert ha estat controlant les dificultats amb què s'ha trobat Healthcare.gov i ha aportat cinc raons clau per al llançament fallit.

  1. Mai, mai violeu el Temps, cost i funció Estableix la regla. Penseu en això com en un triangle, heu de triar un punt per ser fixa i les altres dues variables. En aquest món, es pot crear gairebé qualsevol cosa sempre que hi hagi prou temps i diners. Tanmateix, qualsevol persona que construeixi una aplicació web hauria de triar, per davant, quina és la màxima prioritat. Això marca el to i l’enfocament de com s’ha de llançar un projecte. Per exemple,
    • S’hauria de llançar només quan es facin funcions específiques (els diners i el temps són variables).
    • Si es llança ràpidament (els diners i les funcions són variables).
    • Si es llança amb un pressupost en ment (el temps i les funcions són variables).
  2. Llançament amb el línia de meta en comptes de la línia de sortida. Les aplicacions web haurien de ser vistes com un projecte que sí Començar i després evolucionar. Construir allò que és important i obligatori per al dia d’avui amb el creixement i l’evolució sempre és millor que construir amb la intenció d’acabar al punt de partida.
  3. Hi ha massa proveïdors implicat. S'ha informat que el lloc web d'Obamacare tenia prop de 55 proveïdors implicats. Afegir diversos proveïdors a qualsevol projecte pot ser un pendent relliscós. Gairebé podeu garantir que hi haurà problemes amb la versió de fitxers, discrepàncies de fitxers d'art, discrepàncies d'opinió artística, abandonament de projectes i la llista continua. Imagineu-vos si tinguéssim 55 senats encarregats de resoldre una part del problema general.
  4. Arquitectura de la Informació no es pren seriosament. Sovint, les grans agències demanaran als venedors que presentin una oferta per a una oferta de compra i saltin completament el procés d'Arquitectura de la Informació saltant directament al desenvolupament sense entendre ni acordar un abast. Es tracta d’un enorme, lleig, pèrdua de temps, pèrdua de diners, error. És extremadament valuós arquitectar tanta aplicació com sigui possible i estar preparat per ser àgil i flexible en allò que no es podia preveure bé abans de començar a programar-la (és com construir una casa sense plànols). Els proveïdors estan destinats a esgotar-se el pressupost i començar a tallar cantons si això no es fa correctament.
  5. No hi ha prou temps per Assegurament de la Qualitat. És obvi que això va suposar una gran caiguda en el llançament de HealthCare.Gov. Estaven treballant en una data de llançament dur (el temps és la variable fixa del triangle en aquest cas) i les funcions i el pressupost s’haurien d’haver modificat per complir la data de llançament amb el temps per a una garantia de qualitat adequada integrada al pla. Aquest és un error crucial i probablement els costarà molta feina.

Què et sembla?

Aquest lloc utilitza Akismet per reduir el correu no desitjat. Esbrineu com es processa el vostre comentari.