¿Cuáles son los riesgos de la gestión de proyectos de TI?

El riesgo del proyecto es un evento o situación incierta que, de ocurrir, tendrá un impacto positivo o negativo en al menos un objetivo del proyecto, como el cronograma, el costo, el alcance o las metas de calidad. Entonces, ¿cuáles son los riesgos de la gestión de proyectos de TI? Echemos un vistazo:

(1) Riesgos técnicos.

La actualización del sistema central introduce los últimos productos de fabricantes subcontratados y utiliza muchas tecnologías nuevas. Al personal de I+D de la industria le llevará algún tiempo familiarizarse con estas tecnologías, pero inevitablemente encontrarán algunos problemas técnicos durante el proceso del proyecto. ¿Cómo se pueden resolver rápidamente estos espinosos problemas técnicos? Nuestro enfoque es: primero, designar una persona de contacto del fabricante subcontratado en la industria, que sea responsable de comunicarse con el personal técnico del fabricante subcontratado. Al mismo tiempo, esta persona de contacto es también la persona de la industria que está más familiarizada con los productos del fabricante. De esta manera, esta persona básicamente puede resolver los pequeños problemas comunes y el fabricante puede resolver los problemas más complejos. lo que ahorra tiempo en comparación con todos los problemas. En segundo lugar, compramos mano de obra de los fabricantes para soporte técnico e invitamos al personal de I+D de los fabricantes al sitio de desarrollo para trabajar con nosotros en investigación y desarrollo. En tercer lugar, durante el período de lanzamiento del sistema, está previsto que el fabricante acuda al lugar y esté preparado para afrontar los problemas de emergencia y responder a posibles problemas lo antes posible.

(2) Comunicar riesgos.

El proyecto involucra muchos proveedores de subcontratación, muchos canales de comunicación, altos costos de comunicación y entendimientos inconsistentes. Por lo tanto, el equipo del proyecto estableció una PMO especial, responsable de formular los planes de comunicación correspondientes, designar contactos industriales para cada fabricante, implementar una gestión jerárquica del personal interno, organizar reuniones periódicas para resolver problemas durante el proceso del proyecto y prevenir problemas debido a una comprensión inconsistente de requisitos Para evitar retrasos en el proyecto causados ​​por el proyecto, aprovechar al máximo las herramientas de comunicación existentes, como correos electrónicos, reuniones, llamadas telefónicas y mensajes de texto, y promover el uso de una herramienta de mensajería instantánea como principal herramienta de comunicación laboral.

(3) Riesgo de cambios en la demanda.

En vista de las inevitables actividades de cambio de demanda en los proyectos de software de TI, después de que se lanzó el proyecto, nuestro departamento detuvo todas las nuevas demandas comerciales que excedieran las 20 personas/día, excepto los requisitos de políticas, y también formuló un proceso de cambio de demanda. : Todos los cambios a los requisitos comerciales deben ser propuestos de manera uniforme por representantes de la parte comercial. Los cambios deben registrarse por escrito y los desarrolladores deben evaluarlos cuidadosamente para su aceptación. Finalmente, fue revisado por el China Construction Bank, que tenía poder de veto, simplificando así algunos requisitos poco razonables. A mitad del proyecto, se introdujo la herramienta de gestión de configuración CCCQ de IBM para gestionar el código y los defectos. Todos los errores se clasifican y se ingresan en el sistema CQ para evitar modificaciones repetidas, y no se registran registros después de las modificaciones. Todos los defectos posteriores al simulacro de migración serán analizados y revisados ​​por la persona a cargo de cada sistema para eliminar problemas relacionados con el sistema que puedan ser causados ​​por correcciones de errores.

(4) Riesgo de progreso.

La actualización central del proyecto ha provocado cambios en la estructura de datos del cliente y algunas interfaces externas. Al mismo tiempo, la plataforma empresarial front-end también ha realizado grandes ajustes, como el desarrollo de un nuevo sistema de permisos. y reemplazar el antiguo sistema de permisos en el host. Los datos de permisos se migraron a la microcomputadora, el protocolo de transmisión XML se reemplazó por JSON y se transformó el marco para que la microcomputadora llame al host. La carga de trabajo de desarrollo de la plataforma host y la plataforma abierta es enorme y es necesario reservar suficiente tiempo para las pruebas ST y UAT. El tiempo de desarrollo del proyecto es limitado. Para hacer frente a posibles retrasos en el progreso, hemos adoptado las siguientes contramedidas: primero, desarrollar un plan de progreso detallado para aclarar las tareas de todos. Cada equipo del proyecto verificará periódicamente el progreso del proyecto cada semana y, en segundo lugar, corregirá cualquier desviación de manera oportuna; , cooperar con la subcontratación Cooperar con la empresa para introducir mano de obra subcontratada y agregar temporalmente más tropas nuevas al proyecto, el tercero es forzar horas extras y el cuarto es paralelizar el diseño detallado y la codificación y fortalecer la revisión del código, acelerando así el progreso y reduciendo el retrabajo; .

(5) Riesgos de la migración de datos.

El proyecto involucra cientos de sistemas, el entorno de integración del sistema es complejo y la cantidad de datos a migrar es enorme. La migración de datos requiere alta precisión e integridad. El proyecto formuló una estrategia de integración por fases y múltiples simulacros de migración: previsualizar el trabajo de migración por adelantado y simular escenarios reales de migración en línea. Después de muchos simulacros, los problemas se redujeron considerablemente y también se redujo el riesgo de migración de datos en el sistema.

(6) Riesgos de recursos humanos.

El ciclo de construcción del proyecto es largo, dura dos años, y los movimientos de personal a gran escala pueden provocar retrasos en el proyecto.

Ante este riesgo, las contramedidas son las siguientes: hacer dos preparativos, intentar retener a los que quieren irse, ser racional y emocional, y al mismo tiempo pedir al departamento de recursos humanos de la empresa que mejore los beneficios de los empleados y aumentar el reclutamiento social; esfuerzos y organizar respaldo para puestos importantes, para evitar el desgaste debido a eventos inesperados como enfermedades de miembros y renuncias. Al final, este riesgo no se convirtió en un problema.

En el proyecto de actualización del proyecto, soy responsable de las partes de apertura de dos subsistemas. Debido al alto nivel de énfasis en la gestión de riesgos, también presto especial atención al control de riesgos durante la ejecución. Hay cuatro personas en el equipo del proyecto y el costo de comunicación es relativamente bajo, por lo que realizamos revisiones de código cada dos semanas para resolver algunos problemas técnicos y estándares de codificación. En el desarrollo real, utilizamos Checkstyle para verificar los estándares del código y eliminar posibles errores. códigos irregulares lo antes posible para los miembros del equipo desarrollar un sistema de informe de progreso semanal para evitar desviaciones de progreso frente a los cambios de demanda más probables en el front-end: cambios en la interfaz de usuario, intenté utilizar métodos prototipo para comunicarme de manera efectiva con el negocio; en la etapa inicial del diseño, lo que redujo en gran medida los cambios de la interfaz de usuario en las necesidades de la etapa posterior de la UAT. Pensando en un proyecto en el que trabajé cuando me uní a la empresa por primera vez, no consideré el riesgo de cambiar los requisitos de la interfaz de usuario. No hubo comunicación sobre el diseño de la interfaz de usuario en la etapa inicial, lo que resultó en muchas reelaboraciones durante la etapa de UAT. El proyecto se retrasó más de un mes y se desperdiciaron muchos recursos humanos. Imagínese, si este riesgo se hubiera identificado en ese momento y la probabilidad de que ocurriera se hubiera reducido en una etapa temprana, el proyecto podría haber ido mucho mejor.

Debido al control de riesgos adecuado en la etapa inicial, el proyecto del que era responsable se desarrolló sin problemas hasta el simulacro de migración. Sin embargo, surgieron algunos problemas durante el simulacro de migración. Uno de ellos fue la biblioteca. El programa del asistente no se pudo ejecutar normalmente y ocurrió varias veces. Mis colegas y yo pasamos mucho tiempo investigando el problema y finalmente descubrimos que la causa era un problema de parámetro de configuración. El personal de I+D utilizó parámetros de configuración incorrectos y los datos en la biblioteca de guías durante ST y UAT eran mucho más pequeños que durante el ejercicio real, por lo que no fueron descubiertos. Después de modificar la configuración, la biblioteca de guías ambientales se implementó con éxito. También existen problemas causados ​​por la falta de comunicación efectiva. Por ejemplo, durante el ejercicio, los usuarios informaron que las transacciones de consultas eran lentas. Después de la investigación, el personal de backend afirmó que la recepción había ajustado la transacción incorrecta y el personal de la recepción planteó una objeción: ¿Por qué la consulta del entorno ST es tan rápida? Resulta que el personal de backend escribió muchas transacciones de consulta. Las nuevas transacciones pueden mejorar la velocidad de la consulta, pero no hay ningún documento oficial que indique que el frontend deba reemplazar las transacciones antiguas con transacciones nuevas, y no hay otra forma de notificar. la interfaz, por lo que la interfaz llama a las transacciones antiguas, lo que provoca problemas de rendimiento de las consultas. Debido a las diferencias entre los entornos ST, UAT y los entornos de producción, es difícil exponer los dos tipos de problemas anteriores. Imagínese la probabilidad de que este problema hubiera aparecido en producción sin el ejercicio de migración. El simulacro de migración expuso defectos del sistema que ST y UAT no pudieron detectar de antemano, lo que le dio al personal de I+D tiempo suficiente para investigar los problemas y corregir defectos, reduciendo efectivamente el riesgo de implementación del sistema.

Después del bautismo de este proyecto de actualización central, entiendo profundamente la importancia de la gestión de riesgos en los proyectos de TI. Precisamente porque prestamos suficiente atención a la gestión de riesgos y preparamos planes de respuesta a los riesgos con anticipación, podemos resolver varios riesgos encontrados en el proyecto como expertos y, en última instancia, obtener la victoria en línea. Ningún proyecto es inmune a los problemas de riesgo. La existencia de riesgos hace imposible que casi todos los proyectos completen con éxito sus objetivos. Las buenas habilidades de gestión de riesgos ayudan a los gerentes de proyectos a lidiar con las incertidumbres del proyecto y garantizar el buen progreso del proyecto.

；