Riesgos en la vida de un director de proyectos (registro de riesgos y problemas) / Sudo Null IT News

Todos los directores de proyectos han escuchado la frase “gestión de riesgos”. Si pregunta en una entrevista qué son los riesgos y cómo gestionarlos, está claro que los PR recuerdan diligentemente la definición de riesgo, recuerdan la palabra “mitigación”, pero casi nadie puede responder a la pregunta de cómo trabajar con él. Al mismo tiempo, hay muchos libros dedicados a la gestión de riesgos en proyectos; hay varios artículos interesantes sobre Habré (lo busqué en Google mientras me preparaba).

¿Por qué sucede esto? ¿Qué, no hay ningún riesgo en los proyectos de TI, sólo problemas? ¿O necesita trabajar con riesgos a partir de un cierto nivel del proyecto?

Veamos los riesgos.

Este artículo es parte de una serie de artículos sobre lo que generalmente no se enseña en los cursos de RP y lo que llegué a lograr al pisar numerosos rastrillos a lo largo de 25 años de experiencia en TI. Si está interesado en una experiencia de este tipo, lea mis otros artículos aquí sobre Habré y vaya a mi Canal TG “Zanahoria delante, zanahoria detrás”».

Parte 1. Riesgos típicos

Vi lo que son los “riesgos realizados” en uno de mis primeros proyectos. Yo era un analista idiota verde y estaba aprendiendo a dibujar en UML, cuando el director del proyecto nos reunió a finales de año y dijo: “chicos, subestimé los riesgos del proyecto, esto es una especie de basura, yo también viejo para esto, estoy cansado, me voy”, después de lo cual renunció, y nuestro Lead Analytics dijo (en broma, por supuesto ): “este proyecto está podrido, necesitamos buscar uno nuevo en el análisis fase” y se fue para otro proyecto. Y luego todo nuestro equipo de proyecto esperó 9 meses de intensa basura para entrar en producción, trabajando noches y fines de semana. Fue entonces cuando me di cuenta de cuál era “el riesgo de subestimar el alcance del trabajo debido a una falta de experiencia”, lo cual ocurrió.

Empecemos: cualquier proyecto tiene riesgos y problemas. Al principio de un proyecto no suele haber problemas y puede haber la ilusión de que todo se trata demuy bonito y tranquilo. Pero es bueno para usted que simplemente no vea la ola en forma de riesgos que se le acerca. Ésta es la diferencia entre un RP experimentado y un principiante. El recién llegado lleva a cabo alegremente reuniones sobre el estado, mientras que el experimentado estudia detenidamente el contrato. Un novato pasa su tiempo en reuniones de análisis y uno experimentado observa qué sucede con las integraciones, si es necesario arrastrar y soltar datos, qué sucede con la descripción de los datos en las fuentes, cuáles son los requisitos de informes, qué está pasando con NFR, reunión con líderes técnicos, etc. ¿Por qué es así? Porque en todo lo anterior hay riesgos.

Después de 3 a 6 meses, generalmente se ve así: con la misma complejidad de proyectos, el principiante se atasca, corre como loco, no tiene tiempo para hacer nada y pide ayuda, y el viejo hace el proyecto con su talón izquierdo y se le deberían dar 1 o 2 proyectos más de este tipo. Ésta es la diferencia misma entre June y Signor, sobre la que escribí aquí, y por la que a la gente se le paga dinero.

Si no ve los riesgos, tendrá problemas.

Si a menudo y de repente tiene problemas en su proyecto que resuelve rápidamente, no sabe cómo predecir y no sabe cómo ver los riesgos. No haces esto porque no tienes experiencia o porque, de hecho, te gusta así. Incluso hay un tipo psicológico especial de gerentes a quienes les encanta trabajar en modo de extinción de incendios y charlar continuamente, y cuando todo es predecible y tranquilo, se aburren y se sienten innecesarios.

El problema es que este enfoque es perjudicial para la empresa. El creciente caos en el proyecto provoca cambios en los plazos. Plazos retrasados ​​= lucro cesante.

El PR debe mirar más allá de sus narices y ver los problemas de antemano. El RP y solo el RP debe ser el principal histérico al inicio del proyecto, esto es necesario precisamente para que el resto del equipo del proyecto no se ponga histérico al final del proyecto. Un RP normal siempre debería poder desencadenar una carga de paranoia en su cabeza en forma de las Leyes de Murphy:

Por supuesto, es imposible preverlo todo y es imposible enseñarlo todo en teoría. A menudo, un proyecto de TI es la creación de un nuevo producto único, lo que significa que los riesgos pueden ser tan específicos del proyecto que es imposible preverlos.

Pero seamos honestos: la mayoría de los proyectos de TI son implementaciones empresariales típicas. Se trata de la digitalización de procesos, la transferencia de datos de plataformas obsoletas a otras nuevas y la mejora y soporte continuo de los sistemas informáticos existentes. Y es muy posible predecir problemas en estos proyectos. Además, después de 5 años de tales implementaciones, usted mismo aprenderá a verlos perfectamente.

¿Riesgos típicos de un proyecto de TI o qué podría salir mal?

Comenzaré respondiendo la pregunta al comienzo del artículo: ¿por qué los PR generalmente saben qué son los riesgos, pero tienen dificultades para decir cómo trabajan con los riesgos? En mi experiencia, la respuesta es que los PR funcionan con riesgos.pero inconscientemente. Como regla general, el director del proyecto identifica los problemas típicos del proyecto que ya ha encontrado y se prepara para ellos, priorizando una lista de riesgos que tiene dentro de su cabeza. Simplemente no lo lleva a ninguna parte, no sabe que el riesgo tiene “peso” y otras teorías.

¿Por qué esto funciona para proyectos pequeños? Porque los riesgos de un proyecto informático típico también lo son. A continuación he preparado una lista de riesgos del proyecto que considero típicos y que recomiendo que los gerentes novatos utilicen directamente como lista de verificación:

1. Funciones del sistema. Cuanto más complejos e inciertos sean los procesos que necesita digitalizar, cuanto más complejas sean las funciones del sistema o la GUI del sistema, más trabajo habrá. Y si bien se pueden agregar funciones simples rápidamente, realizar cambios en el proceso puede resultar muy desagradable en una etapa avanzada del proyecto. Estas exigencias del cliente pueden poner en peligro los plazos de entrega.

   Mitigación: estudiando las especificaciones técnicas junto con el líder de análisis, destacando los “puntos débiles”: diagramas de proceso poco descritos, requisitos de funciones poco claros. Esto debe aclararse inmediatamente o no olvidarse durante la fase de aclaración de requisitos. Además, reserve dinero y tiempo para posibles problemas.

2. Integraciones (y migraciones). Si tiene un sistema bancario o de telecomunicaciones serio, es muy probable que deba integrarlo con varios otros sistemas de TI para intercambiar grandes volúmenes de datos. Las integraciones pueden ser muy “pesadas”. Subestimar las integraciones al principio de un proyecto = problemas hacia el final que no podrás superar rápidamente si no piensas en el futuro.

   Mitigación: observamos cuántas integraciones deben realizarse, qué flujos de datos y la complejidad de la lógica de intercambio. Convencionalmente, pasar 2 parámetros a un sistema vecino no tiene sentido, actualizar diariamente información sobre un millón de objetos con registros históricos y subobjetos es hemorroides, requiere mucho tiempo, una arquitectura separada y un equipo.

3. Informes. Una bomba potencial para cualquier proyecto de digitalización de procesos de negocio. El cliente casi nunca comprende lo que necesitará para generar informes al principio, y cuando lo comprende en el momento de la aceptación, resulta que los puntos del proceso necesarios no se han digitalizado y no hay datos en el sistema. Esto puede molestar mucho al cliente e impedirle entregar el proyecto.

   Mitigación: discuta de antemano qué tipo de informes desea el cliente. Puede que sea necesario realizar cambios en los requisitos, pero es mejor que sufrir durante la prueba de aceptación. Pues grabar todas estas discusiones para que después no te digan que no avisaste.

4. Requisitos no funcionales. A menudo pueden ocultar indicadores como “99,7% de disponibilidad” o “tiempo máximo de respuesta del sistema 0,1s”, etc. Parece inocente, pero implica requisitos de reserva:

   1. Disponibilidad del 99,7%: puede llevarlo al concepto de “resiliencia ante desastres”, que requerirá el mismo equipo para los hosts principal y de respaldo, ubicación en diferentes centros de datos y reglas de replicación. Si esto no se incluye en la evaluación del trabajo, tienes grandes problemas;

   2. tiempo máximo de respuesta: se puede comprobar sin carga y bajo carga (en este punto puede tener problemas).

   Mitigación: si se fabricaran sistemas similares para el mismo cliente, observe cómo se detallaron allí requisitos similares y cómo fue la aceptación. Si no se ha hecho, agregue más. tiempo y dinero.

Se trata de riesgos en el propio sistema. También debemos considerar los riesgos administrativos. Veamos los principales:

1. Riesgo de configuración política compleja. Sucede en departamentos internos, cuando el RP es de TI y los clientes son departamentos internos. Cuando hay más de 10 departamentos de este tipo, el patrocinador es el vicepresidente de la empresa y el RP es nuevo, esto amenaza con grandes problemas. Hay muchos lados, muchos deseos que pueden cruzarse y contradecirse.

   Mitigación: de repente, la Carta del Proyecto con objetivos fijos para los Departamentos, con empleados asignados al equipo del proyecto. Mucha comunicación con los departamentos, destacando los departamentos problemáticos para un trabajo intensivo. Registrar todos los acuerdos en una carpeta separada en caso de análisis de “¿quién tiene la culpa?”

2. RP tiene mucha responsabilidad, pero ningún poder.. A menudo, el director de proyectos en la TI interna de una gran organización es un “hacedor sin manos”. Es responsable de los plazos para los clientes y su negocio, es responsable de proporcionar datos a su contratista, pero no tiene recursos propios para influir en la situación (análisis, desarrollo, pruebas) y no puede influir en el contratista ( entonces, por desgracia, sucede que el contratista está predeterminado un par de niveles por encima del nivel RP). Como resultado, es muy fácil llegar al extremo y culpar a todo, entre la empresa (que siempre tiene la razón) y el contratista (que lleva cien años aquí y conoce muy bien su camino).

   Mitigación: estudie lo mejor posible la información introductoria de la empresa, estudie la entrega al contratista (contrato) tanto como sea posible y luego nivele las expectativas de la empresa respecto del trabajo del contratista (por regla general, están infladas). Bueno, aún necesitas solicitar que un analista se una a tu personal.

3. Riesgo de gran volumen de desarrollo. Si tiene un proyecto con más de 10 desarrolladores, existe el riesgo de que se produzca un caos en el desarrollo y la entrega si no crea adecuadamente el proceso de desarrollo y entrega del código. Los analistas plantearán preguntas de “quién sabe qué”, los desarrolladores reducirán la velocidad y harán preguntas, no habrá una metodología para combinar funciones en lanzamientos, reglas para ensamblar código, etc., lo que provocará retrasos en la entrega del código.

   Mitigación: construye el proceso de entrega en el proyecto. Formalización de requisitos, reglas de desarrollo, reglas de prueba, reglas de ensamblaje, reglas de implementación para el cliente (escribir e implementar en su tracker, por supuesto).

Conclusión de la Parte 1

Recomendaría que cualquier RP analice primero los riesgos anteriores. Por supuesto, esta es una lista incompleta. Cuanto más grande sea su proyecto, mayores serán los riesgos. El equipo no se entregará a tiempo, estamos en temporada navideña, el propio vendedor no conoce el sistema que vende para su implementación, etc., aquí todo es muy individual. Pero lo escrito arriba casi siempre suena. Conociendo estos peligros, ya estará un 30% mejor preparado. Pues bien, el 70% restante aún habrá que obtenerlo pisando un rastrillo, ¿dónde estaríamos en nuestro trabajo sin rastrillo?

Trabajar con riesgos es quizás la principal herramienta de la gestión proactiva. Miras hacia delante, sabes lo que te espera y te preparas.

Si ve riesgos y los resuelve, los problemas no ocurren o sí previsible.

Parte 2. Registro de riesgos y problemas

En la Parte 1 anterior, analicé los riesgos típicos de cualquier proyecto: lo que recomendaría que los gerentes de proyecto consideraran primero. Sin embargo, ¿qué hacer si además de estos riesgos ves otros? ¿Qué pasa si hay muchos y necesitas sistematizar este trabajo? Aquí es donde el “Registro de Riesgos y Problemas” vendrá al rescate.

Érase una vez, hace mucho tiempo, cuando yo, el RP verde, tuve un gran proyecto. Inmediatamente me sentí abrumado por un montón de tareas urgentes: el equipo de análisis necesita ayudar con los problemas comerciales, el equipo de desarrollo necesita entornos de desarrollo y prueba, el equipo de integración no puede integrarse sin muestras de datos y es necesario solicitarlos, es necesario Construyó un proceso de desarrollo y comenzó desde cero, y el equipo ya estaba distribuido en 5 ciudades en diferentes países con una diferencia en zonas horarias de 8 horas.

En resumen, no pude dormir. Me asusté y sentí que no podía hacer frente: las nuevas tareas llegaban más rápido de lo que tenía tiempo para procesar las antiguas, sentí que un poco más y continuaría haciendo algo tan crítico que no sería posible solucionarlo. él. Hola neurosis.

Una noche, cuando no podía dormir, simplemente escribí todo lo que podía pasar y que era terrible (pero que aún no había sucedido) en el proyecto. Y se quedó dormido.

Y mañana recordé que vi la plantilla del cliente para una matriz de riesgos y problemas y… ¡bingo! Me di cuenta de que había escrito los riesgos de mi proyecto de la noche a la mañana y todo lo que tenía que hacer era completar el resto de la plantilla.

Usted, como Gerente de Proyecto, necesitará un registro para tener un organizador donde pueda mirar si le falta algo crítico. Al mismo tiempo, aprenderá a utilizar la fórmula clásica Prioridad de riesgo = probabilidad * impacto en la vida real (y asegúrese de que esta sea la misma priorización basada en “quién morirá” que mencioné en el artículo aquí).

registro de riesgos

A continuación se muestra un ejemplo de un registro de riesgos tal como lo usé. Todos los campos son opcionales y puedes cambiarlos como quieras, siempre y cuando esta herramienta te beneficie.

¿Para qué sirven los campos?

1. Breve descripción: título.

2. Cuando se descubre: puede ser necesario al comunicarse con la gerencia. Y un riesgo que se descubrió hace mucho tiempo y que es importante, pero no hay trabajo al respecto, es más fácil de encontrar.

3. Importancia (0..1). Respondemos a la pregunta “Si esto sucede, ¿quién morirá y qué pasará?” Si todos mueren y hay plazos incumplidos y horror, horror, eso es 1. Si nadie se da cuenta, entonces 0,01.

4. Probabilidad (0..1). La probabilidad de que ocurra un evento depende de su opinión personal. 0 – nunca sucederá, 1 – sucederá al 100%.

5. El peso es la métrica de riesgo más importante mediante la cual se clasifican los riesgos.

6. Descripción: aquí los no iniciados deberían tener claro cuál es el riesgo.

7. Plan de remediación (registro): historial de eventos de riesgo. Es necesario restaurar la secuencia de pasos si necesita resolverlo más adelante.

Cómo trabajar con eso: Complete todos los riesgos que tiene en mente y que le preocupan. Incluso si hay 50 (¡especialmente si hay 50!). A continuación, ordene por el campo “Peso” en orden descendente y luego trabaje solo con los 10 riesgos principales. Todo.

El registro podrá actualizarse siempre que se produzcan cambios en los riesgos objeto de seguimiento. Por ejemplo, tomó medidas para mitigar el riesgo de “no entregarán equipos al centro de datos”, firmó un contrato con un proveedor confiable, él garantizó los plazos, se redujo el riesgo, se actualizó el registro, se reordenó y monitoreamos solo los relevantes con el peso máximo.

¿Qué te aporta el registro?:

1. Te protege de la paranoia y pesadillas como “Olvidé algo”. Todo lo que sabes ya está en el registro y ordenado, puedes dormir tranquilo.

2. Te protege en caso de que el riesgo se haga realidad y se convierta en un problema. Por lo general, aquí es donde comienza el enfrentamiento “¿quién tiene la culpa?”. y “¿qué debo hacer?” En este lugar, el registro de riesgos le ayudará perfectamente a responder preguntas sin tener que buscar frenéticamente el historial del problema en el correo, rastreadores y mensajería instantánea.

Registro de problemas

El problema es un riesgo que se ha hecho realidad. Si tiene un problema crítico, pero no existía tal riesgo en el registro, debe pensar en cómo sucedió que no se dio cuenta del riesgo. El registro de problemas se construye de manera similar al registro de riesgos, excepto que los campos “probabilidad” e “importancia” no son necesarios; puede completar inmediatamente el “peso”.

La lógica del trabajo es la misma: clasificamos en orden descendente y trabajamos en el top 10, revisándolo todos los días (o con menos frecuencia, depende de tu discreción y de la velocidad de toma de decisiones).

Conclusión de la Parte 2

Como puedes ver, los registros de riesgos y problemas son necesarios como herramienta para estructurar la información cuando existe un flujo de información realmente grande. No tiene sentido utilizar registros en proyectos pequeños. Sin embargo, los conceptos de “grande” y “pequeño” son conceptos flexibles y dependen, entre otras cosas, de la experiencia del Project Manager. Por lo tanto, recomendaría que el RP, que no haya hecho esto, pruebe a trabajar con el registro en su proyecto actual más complejo. Si lleva este trabajo a la automatización, incluso en proyectos muy complejos, no necesitará completar Excel, ya tendrá toda esta tabla y lógica en su cabeza.