[Parece que] Los proyectos de desarrollo no tienen riesgos
Si bien es sabido que los riesgos en proyectos de desarrollo de software existen, veo todo el tiempo equipos subestimándolos. Hay una mezcla de "a mí no me va a pasar" con "eso es para otro tipo de proyectos" increíble.
Así como el otro día decía que veo a mucho equipos más preocupados por temas de gestión que por temas técnicos, también veo que este –aún siendo tema de gestión- no es un tema que preocupe casi nunca. Pocas veces he visto que los equipos de desarrollo encaren la tarea de hacer una análisis de riesgos a conciencia que les permita entender por dónde van a venir los tiros.
Es como si flotara en el aire una sensación de perfección tal que no permitiera ver que las cosas en desarrollo de software rara vez salen bien y tenemos que responder a riesgos materializados todo el tiempo.
¿Alguien puede decirme por qué es esto?
Seguimos pensando..
Sin ánimo de ofender a nadie, supongo que es por estupidez, algo muy natural y común en el ser humano.
ResponderBorrarGracias por el *duro* comentario :-)
BorrarYo creo que es optimismo.
Coincido, y creo que viene de la mano con el hecho de que se pone más énfasis (esfuerzo y presupuesto) en la gestión que en lo técnico. No sólo en cuanto a análisis de riesgo sino también en otras áreas. Es solo una sensación, pero creo que ocurre porque se exige (en general) más en relacion a fechas, plazos, etc.
ResponderBorrarGracias por el comentario!
BorrarMe pasa esto, la gestión de riesgo se torna muro de los lamentos.
ResponderBorrar1) Los sueldos van a quedar desactualizados. Probabilidad uno. Impacto alto. Mitigación ir a la CGT. Contingencia Contratar Indios. Ahá. Muy interesante.
2) Vamos a tener alta rotación. Probabilidad uno. Impacto alto. Mitigación pagar mejores sueldos (ver riesgo 1). Contingencia Contratar becarios o hacer pair progamming. Ahá. Muy interesante.
3) En producción nos podríamos quedar cortos de hardware. Probabilidad uno. Impacto alto. Mitigación hacer test de stress. Contingencia comprar más hardware. Ahá. Muy interesante.
La mezcla de muro de los lamentos más solución obvia me aburre. Mitigaciones y contingencias me parecen siempre tareas obvias de un proyecto.
Y además... siendo CMMI nivel dos, hasta los riesgos son repetibles e iguales de proyecto a proyecto. Son tan iguales que hasta están esas taxonomías que estudiábamos en la facu.
Es mi porqué. Gracias por escribir.
Por un lado a mí me parece que siempre es posible pensar acciones o estrategias de mitigación más allá de las obvias. Como lo primero que uno piensa es lo obvio o lo imposible es que este tipo de "fumatas" se organizan entre varios en modalidad brainstorming. A alguno se le van a ocurrir cosas nuevas.
ResponderBorrarPor ejemplo si el riesgo es que "dada la alta rotación se podría perder conocimiento" podría mitigarse armando material de inducción que permita una rápida entrada a la gente nueva. En un modelo donde la gente se va porque consigue mejor sueldo, vos traes a otro que acepta el sueldo que pagas y lo inducís. Es el costo que pagas por no aumentar el sueldo.
En el caso del hardware tal vez alguna opción de arquitectura más escalable con máquinas más chicas. Recuerdo unos piratas que usaban la máquina de contingencias para hacer pruebas de año 2000. No se si te suena?
Por otro lado un riesgo de probabilidad 1 no es un riesgo, es un problema. Y un amigo mutuo dice que si un problema no tiene solución no es un problema. :-)
Lo que quiero decir con esto es que hay riesgos que sí podemos atacar y otros que no. Con los que no podemos hacer nada, nos resignamos. Con los que sí podemos hacer algo.. por favor hagamos algo.
Por último.. y hemos tenido esta discusión mil veces. En un mundo perfecto no es necesario hacer análisis de riesgos tampoco (al igual que Testing o tener un PM). Todos planifican perfecto y las acciones de mitigación o no son necesarias o están dentro del plan. No estamos en un mundo perfecto, ergo.. pensa un rato en los riesgos antes de que te exploten en la cara :-)
Seguimos pensando..
PD: Gracias por comentar, su comentario es mi recomensa.