Factores a considerar para la gestión de riesgos de software

¿Cuáles son los factores de riesgo que debemos tener en cuenta al planificar un proyecto de software?

• ¿Está su equipo adecuadamente entrenado?
• ¿Tu equipo es lo suficientemente grande?
• ¿Tiene contingencia en caso de que alguien abandone el proyecto y cómo afectaría el cronograma?
• ¿Tu equipo es demasiado grande?
• ¿Tienen los recursos que necesitan?
• ¿Podría un competidor llevar un producto al mercado antes de que se complete su proyecto?
• ¿Se puede tratar con los requisitos modificados?
• ¿Puedes lidiar con que el proyecto se vuelva irrelevante?
• ¿Tiene la aceptación de la alta dirección?
• ¿Confía en proveedores o contratistas?
• ¿Estás haciendo algo interno en el que tu equipo no es lo suficientemente competente?
• ¿Tiene un presupuesto lo suficientemente grande como para cubrir el costo estimado del proyecto?
• ¿Puede afrontar los costos imprevistos del proyecto?
• Y cualquier cosa que sea específica para tus circunstancias :-)

Yo agregaría a la lista de @ Graham:

• ¿Están algunos de los requisitos fuera de su control (por ejemplo, las leyes sobre el cálculo del impuesto sobre las ventas) y podrían cambiar?
• ¿Está utilizando una herramienta por primera vez y qué tan seguro está de que la herramienta funcionará para usted? (Puede ser nuevo, por ejemplo, Azure, o simplemente nuevo para su equipo)
• ¿Confía en una aceptación general por parte de los usuarios de otro producto (por ejemplo, escribir una aplicación para iPhone significa que espera que sus usuarios tengan iPhones, escribir una aplicación para BlackBerry significa que espera que sus usuarios tengan BlackBerries, etc.)
• ¿Puede restaurar / recrear cualquier trabajo perdido o cambiado incorrectamente?
• ¿Tiene herramientas y procesos que le permitan comprender el progreso, la falta de progreso y las regresiones? ¿Entiende la gerencia los hitos? (He tenido proyectos en los que con un 10% de finalización, la gerencia vio prototipos de interfaz de usuario y creyó que el trabajo estaba "casi terminado" y luego presioné para apresurarse, apresurarse a partir de ese momento).
• ¿Tiene pruebas (automatizadas o no) para demostrar que un conjunto particular de cambios no ha roto alguna otra parte de la aplicación? Sin estas pruebas, ¿podría realizar cambios significativos, como la transferencia a otro idioma o plataforma?

Yo agregaría lo siguiente:

• ¿Conoces las necesidades de tus clientes? Si no es así, ¿su equipo de recopilación de requisitos ha determinado adecuadamente qué es lo que el cliente desea en el pasado y ha respondido lo suficiente como para garantizar que los cambios se propaguen lo más rápido posible al equipo de desarrollo? ¿Están agregando enchapado en oro a los requisitos?
• ¿Existe un producto existente con el que compita y ha determinado antes del diseño cómo competirá con este producto? Esto es crítico ya que los productos existentes a menudo presentan aspectos de "Quiero esa característica también" que podrían hacer que se desvíe de los planes originales. ¿Puede su equipo / gerencia / cliente objetivo ser ignorado por tal ocurrencia y tiene planes de contingencia establecidos para manejar tal problema?
• ¿El diseño propuesto de su producto es relevante para el mercado? A mitad de camino, no desea descubrir que si bien satisface las necesidades de sus clientes, carece de aspectos críticos para competir en el "nuevo" mundo.

El desarrollo rápido de Steve McConnell contiene un capítulo sobre gestión de riesgos, con una larga lista útil de riesgos potenciales. Lo he usado como punto de partida más de una vez.

¿Tienes la combinación correcta de personas? ¿Están todos los desarrolladores de aplicaciones de desarrolladores en un proyecto centrado en datos? ¿Necesita un diseñador de bases de datos, una persona de control de calidad o un especialista en interfaz de usuario en lugar de solo contratar personas con la misma combinación de habilidades?

¿Tiene el hardware adecuado para respaldar el proyecto? Esto es especialmente cierto si está creando un sistema de alto volumen o si es demasiado barato para comprar servidores de desarrollo además de servidores de producción.

¿Ha configurado copias de seguridad de sus bases de datos? Solo tener el código para recrear una base de datos no es suficiente, también debe mantener los datos incluso en el desarrollador.

¿Sus desarrolladores están trabajando con un pequeño conjunto de datos en lugar de uno del tamaño que tendrá la producción? Esto casi garantiza problemas de rendimiento de producción porque las consultas que funcionan bien en un conjunto de datos pequeño a menudo no lo hacen en un conjunto grande. He visto muchas actualizaciones de producción fallidas que tuvieron que revertirse inmediatamente debido a este problema en particular.

¿Estás definiendo qué hacer en casos extremos y los estás probando? Por ejemplo, he visto proyectos en los que nadie definió qué sucede, qué aprobación se requiere y el aprobador dice que no.

¿Te verás obligado a tomar malas decisiones de diseño para cumplir con plazos irrazonables?

En su planificación para el proyecto, ¿consideró que las personas se toman vacaciones y días de enfermedad, tienen que ser miembros del jurado, se van de vacaciones, etc. Debe planificar no solo para las personas que abandonan el proyecto, sino también para el tiempo libre diario que las personas obtienen.