O triángulo de desenvolvemento web

Todos os nosos contratos cos nosos clientes son compromisos mensuais continuos. Moi poucas veces perseguimos un proxecto fixo e case nunca garantimos o cronograma. Isto pode parecer asustado para algúns, pero o problema é que o obxectivo non debería ser a data do lanzamento, senón os resultados comerciais. O noso traballo é obter resultados empresariais dos nosos clientes, non tomar atallos para facer datas de lanzamento. A medida que Healthcare.gov está aprendendo, ese é un camiño que levará ás expectativas perdidas.

Para tentar manter os proxectos dos clientes puntualmente, separamos os requisitos en must have (cumprindo os resultados da empresa) e agradable de ter (melloras opcionais). Tampouco programamos a finalización no momento do lanzamento, xa que sabemos que sempre haberá algúns cambios necesarios.

Robert Patrick é CEO de Laboratorios de doutoramento, unha axencia que deseña, constrúe e lanza sitios web para moitas compañías Fortune 500. Robert estivo atentos ás dificultades coas que se atopou Healthcare.gov e proporcionou 5 razóns fundamentais para o lanzamento errado.

  1. Nunca, nunca infrinxa o Tempo, custo e función Establecer regra. Pense nisto como un triángulo, ten que escoller un punto para ser fixado e as outras dúas variables. Neste mundo pódese crear case calquera cousa sempre que haxa tempo e cartos suficientes. Non obstante, calquera que constrúa unha aplicación web debería escoller, por diante, a prioridade máis alta. Isto define o ton e o enfoque de como se debe lanzar un proxecto. Por exemplo,
    • Debería ser lanzado só unha vez que se fan funcións específicas (o tempo e o diñeiro son variables).
    • Se se lanza rapidamente (o diñeiro e as funcións son variables).
    • Debería ser lanzado pensando nun orzamento (o tempo e as características son variables).
  2. Lanzamento co liña de meta presente en vez da liña de saída. As aplicacións web deberían verse como un proxecto que o fará Comezar e despois evolucionar. Construír o que é importante e obrigatorio para hoxe tendo en conta o crecemento e a evolución sempre é mellor que construír coa intención de rematar no punto de partida.
  3. Demasiados vendedores implicado. Informouse de que o sitio web de Obamacare tiña preto de 55 vendedores implicados. Engadir varios vendedores a calquera proxecto pode ser unha pendente escorregadiza. Case pode garantir que haberá problemas coa versión de ficheiros, discrepancias de ficheiros de arte, discrepancias de opinión de arte, abandono de proxectos e a lista continúa. Imaxina se tivésemos 55 senados encargados de resolver unha parte do problema xeral.
  4. Arquitectura da Información non se toma en serio. A miúdo, as grandes axencias pedirán aos vendedores que presenten unha oferta por unha compra-venda e salten completamente o proceso de Arquitectura da Información saltando cara ao desenvolvemento sen comprender nin acordar un alcance. Este é un enorme, feo, que perde o tempo, perde cartos, erro. É moi valioso arquitectar a maior parte da aplicación e estar preparado para ser áxil e flexible sobre as cousas que non se podían predicir ben antes de comezar a programala (é como construír unha casa sen planos). Os vendedores están destinados a esgotar o orzamento e comezar a cortar cantos se isto non se fai correctamente.
  5. Non hai tempo suficiente para Garantía de calidade. É obvio que esta foi unha gran caída no lanzamento de HealthCare.Gov. Estaban a traballar nunha data de lanzamento dura (o tempo é a variable fixa do triángulo neste caso) e as características e o orzamento deberían ser modificados para cumprir a data de lanzamento co tempo para unha correcta garantía de calidade integrada no plan. Este é un erro crucial e probablemente custará a moita xente o seu traballo.

¿Que pensas?

Este sitio usa Akismet para reducir o spam. Aprende a procesar os teus datos de comentarios.