No estas solo. Recibo llamadas regularmente de personas que: compañías de desarrollo seleccionadas, obtienen el 50% del proyecto y pierden la confianza en la capacidad del equipo para tener éxito.
En mi experiencia, los equipos de desarrollo fallan cuando:
- Escribir código antes de escribir especificaciones
- Seleccione la tecnología incorrecta para un proyecto (o el proyecto incorrecto para su tecnología)
- Falta de experiencia y confianza en las tecnologías del proyecto.
- Carece de un proceso de garantía de calidad integral y / o
- No están motivados hacia el éxito (por ejemplo: operar bajo un contrato con los incentivos equivocados)
Cada una de las razones anteriores podría ser una respuesta en sí misma, y a menudo 3 o más factores conducen a la falla.
- ¿Tengo que ser desarrollador web con desarrollo móvil?
- ¿Por qué es necesario desarrollar una aplicación móvil para un negocio?
- ¿Alguien ha usado Meteor para crear aplicaciones móviles multiplataforma?
- ¿Qué plataforma de SDK es mejor para integrarse con otros SDK de aplicaciones?
- ¿Cuáles son las mejores plataformas / aplicaciones para crear anuncios de Facebook?
Por qué las malas especificaciones conducen al fracaso
Pero, me enfocaré en # 1 – Especificaciones, porque no solo es el problema más común, sino que también conduce al resto. Por ejemplo:
- # 2/3 – ¿Cómo puede estar seguro de tener una tecnología adecuada antes de definir el proyecto? ¿Y cómo sabe si tiene confianza para resolver un problema que no ha identificado?
- # 4 – ¿Cómo puedes probar una aplicación si no has definido lo que se supone que debe hacer?
- # 5 – ¿Cómo puede aceptar un contrato que sea justo para ambas partes sin saber cuál es el alcance?
Cómo especificar un proyecto antes de desarrollar
Paso 1 • Análisis de requisitos comerciales:
Esto se hace mejor antes de considerar a los vendedores. Siempre puede mejorar los requisitos de su negocio con el tiempo, pero cuanto mejor los defina por adelantado, mejor podrá comunicar sus requisitos a los proveedores y solicitar estimaciones significativas del proyecto.
- Objetivos
- Interesados clave
- Lista detallada de necesidades que requieren satisfacción
- Un caso de negocios que vincula la satisfacción de estas necesidades con los beneficios financieros de la aplicación (costos / ingresos) y los compara con los costos de desarrollo. Esto también identificará sus métricas clave de éxito y alineará la toma de decisiones de diseño entre todas las partes interesadas.
Paso 2 • Especificaciones gráficas y tecnológicas
Durante esta fase, su objetivo es crear una imagen lo más clara posible de su aplicación antes de comenzar el desarrollo. Esto es crucial porque las aplicaciones no son simples. Cualquier imagen que tenga en mente es probable que (a) esté incompleta y (b) sea imposible de ver para cualquier otra persona.
Incluso si tiene una relación con un líder de proyecto en una empresa de desarrollo y siente que el líder del proyecto comprende su visión; Si esa visión no está documentada, su proyecto está destinado a salirse de los rieles (consulte “Cómo las especificaciones deficientes conducen al fracaso” más arriba)
Hay una gran cantidad de modelos utilizados por profesionales para desarrollar especificaciones. Estos son los que a mi equipo le gusta usar:
- Interfaz:
- Mapa de página: proporciona una imagen general instantánea de la aplicación, permitiendo a todas las partes ver cómo encajan las piezas.
- Maquetas: proporciona un punto de discusión común para cada interfaz, clave para comunicar la sensación general de la aplicación e identificar detalles que podrían generar confusión. No te detengas en fotos bonitas. Describa la lógica y la interacción detrás de cada elemento en la interfaz.
- Técnico:
- Conceptos: los conceptos fuerzan la selección y definición de los términos clave que se relacionan con su proyecto. Los conceptos son las cosas que todos los usuarios de la aplicación deberán comprender, por lo que garantizar que tengan sentido es fundamental para la usabilidad.
- Tecnologías: utilizaré esto como un conjunto para todas las dependencias sin código de su aplicación, y esto puede variar dramáticamente de una aplicación a otra. ¿Quizás requiera la integración con un tercero como una pasarela de pago? ¿Quizás tiene un algoritmo complejo que necesita ser diseñado y validado? La lógica y la validación (en realidad, pruebas para verificar que la lógica funciona con la tecnología) es crucial en esta fase para garantizar el alcance y la viabilidad general de su aplicación.
- Varios: no olvide cosas como mensajes de texto por correo electrónico, procesos de contraseña olvidados, seguridad, infraestructura, escalabilidad y cualquier requisito reglamentario que se aplique a usted.
- Flujos de trabajo / Historias: Los flujos de trabajo son el componente más frecuentemente omitido de las especificaciones técnicas porque deben aprovechar todos los demás elementos. Los flujos de trabajo son los enlaces entre interfaces, conceptos y tecnologías y. A medida que refina sus especificaciones de flujo de trabajo, también refinará todas las demás especificaciones. Finalmente, las especificaciones de los flujos de trabajo son cruciales para las pruebas, ya que es en las permutaciones de los flujos de trabajo donde surgen muchos comportamientos inesperados.
Para cuando complete el Paso 2, debe tener una idea clara de cómo se cumplirán los requisitos comerciales del Paso 1 y cuánto costará.
Las especificaciones no son importantes para las aplicaciones. Las aplicaciones son especificaciones.
La gente a veces piensa que desarrollar software significa escribir código. Esta mentalidad es lo que lleva a las razones comunes de falla enumeradas al principio.
Desarrollar software es especificar, luego expresar esas especificaciones con más detalle (código), luego probar las especificaciones contra las especificaciones, y luego lanzar el producto.
La pregunta no es si especificar o no. La verdadera pregunta es cuándo desea especificar:
- Por adelantado, para que pueda evitar las razones comunes del fracaso del equipo,
- Una vez que se desarrolla el código, lo que lleva a la necesidad de reescribir el código o cambiar las tecnologías, o
- Después de liberar el código, lo que lleva a una experiencia de usuario horrible y el dinero desperdiciado en sus procesos de lanzamiento
Si estuviera construyendo una casa, ¿le ahorraría tiempo comenzar clavando algunos clavos?
En mi experiencia, las especificaciones completas deben tomar alrededor del 20-30% del tiempo total del proyecto y requieren una inversión sustancial de la mayoría de las partes interesadas del proyecto. Hacer las especificaciones más adelante en el proyecto significa que el tiempo total del proyecto aumenta; sin embargo, la proporción de tiempo requerida para las especificaciones se mantiene bastante constante.
Especificaciones y MVP
Si ha leído libros como “The Lean Startup”, está familiarizado con las ideas de fracasar en el aprendizaje temprano y validado. ¿Un proceso de especificaciones riguroso no reducirá la velocidad de comercialización y su flexibilidad?
¡De ningún modo! Tus especificaciones son tu primer MVP.
Las especificaciones son mejores cuando se desarrollan en un proceso rigurosamente colaborativo. Con creatividad, sus especificaciones se pueden usar para probar todo tipo de suposiciones contra las partes interesadas y validar su caso de negocios.
Puede permitir que los usuarios finales reales hagan clic en las maquetas de la interfaz. Puede validar que las API en las que confía funcionan según sea necesario. Puede realizar pruebas de carga en algoritmos prototipo.
Un MVP que toma entre el 20 y el 30% del tiempo total del proyecto es mucho más barato que llevar una aplicación completa al mercado, y los aprendizajes que logra a través del proceso de especificaciones son fundamentales para garantizar que su MVP completamente funcional no esté completamente a la basura.
Respuesta al comentario original de la pregunta del póster:
Para elaborar, estoy buscando saber qué necesitaría el nuevo desarrollador para continuar trabajando de manera efectiva en una aplicación (por ejemplo, historias de usuarios, hoja de especificaciones, etc.).
Las primeras preguntas que le haría son: (a) ¿por qué razones está abandonando a su desarrollador actual? (b) ¿puedo ver los requisitos comerciales y las especificaciones técnicas que tenga? (c) qué tecnologías se están utilizando y (d) puedo ver el prototipo actual.
Por lo general, esto lleva a una de dos recomendaciones:
- Si la aplicación actual se ve sólida y se basa en tecnologías razonables, le recomendaría que busque una empresa con un historial comprobado que publique aplicaciones increíbles en esa pila de tecnología.
- Si la aplicación actual está mal planificada y desarrollada (por lo general, la razón para buscar otro equipo), probablemente el único valor en el trabajo hasta la fecha es su aprendizaje. Arreglar un código incorrecto es como arreglar una casa fea construida sin cimientos. Es mejor para todos derribarlo y comenzar desde cero.
La desafortunada verdad es que es probable que deseches mucho menos que un proyecto completo al 50%.
En mi experiencia, en la marca de finalización del 50%, una aplicación tiene:
- Las especificaciones están completas
- Todas las interfaces han sido desarrolladas
- La mayor parte de la lógica compleja se ha desarrollado.
Aproximadamente un 60% de finalización, se debe desarrollar todo el alcance del proyecto. Es en este punto que ocurre el 40% restante del proyecto de desarrollo (garantía de calidad, arreglos, pruebas de integración y lanzamiento).
Estos números varían de proyecto a proyecto y de equipo a equipo; sin embargo, si no se está desarrollando a partir de buenas especificaciones, eso solo empuja la inversión de especificaciones a un trabajo incompleto futuro para el proyecto.
Espero que esto sea un estímulo para que su próximo equipo pueda ser una mejor experiencia. Las sorpresas son frustrantes y costosas al desarrollar aplicaciones, pero un proyecto bien planificado puede minimizar las sorpresas.
Cuando busque su próximo equipo de software, seleccione el que cree que especificará todo antes de que desarrollen algo .
