El triángulo del desarrollo web

Todos nuestros contratos con nuestros clientes son compromisos mensuales continuos. Muy raramente perseguimos un proyecto fijo y casi nunca garantizamos el cronograma. Eso puede parecer aterrador para algunos, pero el problema es que el objetivo no debe ser la fecha de lanzamiento, sino los resultados comerciales. Nuestro trabajo es lograr que nuestros clientes obtengan resultados comerciales, no tomar atajos para establecer fechas de lanzamiento. Como Healthcare.gov está aprendiendo, ese es un camino que conducirá a perder expectativas.

Para intentar mantener los proyectos de los clientes a tiempo, separamos los requisitos en imprescindibles (cumplir con los resultados comerciales) y agradables de tener (mejoras opcionales). Tampoco programamos la finalización en el momento del lanzamiento, ya que sabemos que siempre habrá algunos cambios necesarios.

Robert Patrick es director ejecutivo de Laboratorios de doctorado, una agencia que diseña, crea y lanza sitios web para muchas de las principales empresas de Fortune 500. Robert ha estado pendiente de las dificultades con las que se ha encontrado Healthcare.gov y ha proporcionado 5 razones clave para el lanzamiento fallido.

  1. Nunca, nunca violes el Tiempo, costo y función Establecer regla. Piense en esto como un triángulo, debe elegir un punto para ser fija y las otras dos variables. En este mundo, se puede crear casi cualquier cosa siempre que haya suficiente tiempo y dinero. Sin embargo, cualquiera que cree una aplicación web debe elegir, por adelantado, cuál es la máxima prioridad. Esto establece el tono y el enfoque de cómo se debe lanzar un proyecto. Por ejemplo,
    • Debe lanzarse solo una vez que se hayan realizado funciones específicas (el dinero y el tiempo son variables).
    • Debe lanzarse rápidamente (el dinero y las características son variables).
    • Debe lanzarse con un presupuesto en mente (el tiempo y las características son variables).
  2. Lanzando con el línea de meta en mente en lugar de la línea de salida. Las aplicaciones web deben verse como un proyecto que comienza y entonces evoluciona. Construir lo que es importante y obligatorio para hoy con el crecimiento y la evolución en mente es siempre mejor que construir con la intención de terminar en el punto de partida.
  3. Demasiados proveedores involucrado. Se ha informado que el sitio web de Obamacare tenía cerca de 55 proveedores involucrados. Agregar varios proveedores a cualquier proyecto puede ser una pendiente resbaladiza. Casi puede garantizar que habrá problemas con el control de versiones de los archivos, las discrepancias en los archivos de arte, las discrepancias en las opiniones sobre el arte, el abandono del proyecto, y la lista sigue y sigue. Imagínese si tuviéramos 55 senados, cada uno con la tarea de resolver una parte del problema general.
  4. Arquitectura de la Información no tomado en serio. A menudo, las grandes agencias pedirán a los proveedores que presenten una oferta en una RFP y se salten por completo el proceso de Arquitectura de la información y salten directamente al desarrollo sin comprender o acordar un alcance. Este es un gran, feo, pérdida de tiempo, pérdida de dinero, error. Es extremadamente valioso diseñar la mayor parte de la aplicación que pueda por adelantado y estar preparado para ser ágil y flexible en las cosas que no se pudieron pronosticar bien antes de comenzar a programarla (esto es como construir una casa sin planos). Los proveedores están destinados a quedarse sin presupuesto y empezar a tomar atajos si no se hace correctamente.
  5. No hay suficiente tiempo para Seguro de calidad. Es obvio que esto fue una gran caída para el lanzamiento de HealthCare.Gov. Estaban trabajando en una fecha de lanzamiento dura (el tiempo es la variable fija del triángulo en este caso) y las características y el presupuesto deberían haber sido modificados para cumplir con la fecha de lanzamiento con tiempo para el Control de calidad adecuado integrado en el plan. Este es un error crucial y probablemente le costó el trabajo a mucha gente.

¿Qué piensas?

Este sitio usa Akismet para reducir el correo no deseado. Descubra cómo se procesan los datos de sus comentarios.