¡Tenemos un proyecto para desarrollar e implementar un nuevo sistema de TI! Y necesitas un PM ...
Que paso Donde sin eso. Y parece que el mercado está saturado de todo tipo de gerentes de proyecto.
- ¡Elige! Todos tienen una maravillosa y rica experiencia. Hay PMs con experiencia en la implementación de proyectos en Construcción y Defensa. Hay PMs con experiencia en la implementación de proyectos médicos. Incluso hay en la aeronave! ¿Qué más necesitas? El nivel de responsabilidad y exigencia en estas industrias es un completo vuelco de la cabeza.
"¿Él lo sabe?"
- ¿Por qué necesitas esto? Tiene un excelente conocimiento de la metodología de gestión de proyectos ... ¡esto es lo principal!
Y esto también sucedió ...
Comprendamos si se necesita TI para un gerente de proyecto que debe venir y organizar el desarrollo y la implementación de un sistema de información.
¡Entonces, primero necesitas desarrollar un sistema de información!
- Vamos, PM, ¿qué vas a hacer primero?
- Definir la necesidad y los objetivos!
- bien. Y entonces?
- ¡Elaboremos un plan de proyecto de desarrollo!
- Es lógico. ¿Y cuáles son las etapas de desarrollo? ¡Es necesario determinar las tareas de nivel superior para la composición!
"¿Por qué necesito esto?" Le preguntaré a alguien!
- ¿Y quién en TI posee esta información?
- Quien, quien? El programador ... probablemente ...
Más recientemente, me encontré con una historia similar. Por un lado, todo parece estar suave. De hecho, el programador sabe en qué etapas suele consistir el desarrollo. Pero hagamos una enmienda. Para no perder la marca, ¡vamos al Arquitecto! Debe saberlo con seguridad.
- Hola arquitecto. ¿En qué consiste el desarrollo? Necesita tareas en el plan.
- ¡Necesitamos usar TK y Gash funcional!
"¡¿Eso es todo ?!" Tan fácil
- Bueno, aún prueba.
- ¿Y si TK cambia en el proceso?
"No lo sé". Mi trabajo es trabajar en TK
Bajamos Preguntaron. Recibió 2 puntos: TK y Desarrollo.
- ¿Qué vamos a hacer, PM?
- ¡Entonces todo está claro! Lo pediremos y se lo daremos al Arquitecto. Deja que sea apreciado. Dice la fecha límite. Determinará los puntos de preparación, y lo controlaremos en estos puntos. Y periódicamente muestre al usuario el resultado.
Así es como sucede, aproximadamente, cuando el primer ministro no está al tanto.
¿Y qué le preguntaríamos cuando contratáramos? Y si vas muy lejos, entonces ¿Cuál es el ciclo de vida del Sistema de Información desde su nacimiento hasta la muerte? Aunque, los sistemas no mueren. Son "moralmente" obsoletos.
Nunca olvidaré la historia "divertida" con el sistema de aire acondicionado de canal que sucedió en nuestra fábrica. Encontrado, entonces, un sistema. Bueno, poderoso. Se suponía que enfriaría toda la planta y los edificios administrativos adyacentes. Bien comprado Por algo alrededor de 200K rublos americanos. Ellos lo ponen. Poner en funcionamiento. Después de varios meses de operación, el sistema está doblado. Por qué Sí, porque ningún sistema puede sobrevivir sin soporte y soporte técnico regular.
Pero el sistema de información no es diferente. Además, como otros sistemas, requiere puesta en marcha. Al igual que otros son infraestructuras. Y, a veces, los errores de implementación que ocurrieron en un proyecto para implementar un sistema financiero son mucho más caros que romper una kondeya.
Entonces, ¿cómo puede el primer ministro que vino al proyecto de TI de la industria de la aviación o la construcción ser capaz de dibujar un plan que debería contener todas estas etapas?
¿Obtener consejos del arquitecto? ¿Quién ve fragmentariamente su tarea y no imagina qué es "antes" y qué es "después"? Por desgracia Tal proyecto está condenado de antemano.
Por lo tanto, comprender el PM, en qué tareas consiste el proyecto, qué tareas están relacionadas y cuáles se pueden hacer en paralelo, es importante para un proyecto de TI.
¿Y cómo entendemos ahora cuánto PM corresponde al resultado esperado? Para hacer esto, hay una serie de preguntas no difíciles a las que necesitamos obtener respuestas claras.
Pregunta 1: ¿Cuáles son las etapas de la formación de especificaciones técnicas para el desarrollo?La respuesta es:- De la formación de los requisitos funcionales del cliente.
- Formación de la tarea para la infraestructura, que, a su vez, es el resultado del desarrollo del Contrato de tolerancia a fallas y respaldo
- Y desde el mapa de la interacción del futuro sistema con otros sistemas.
De hecho, tenemos 3 tareas a la salida: funcional y técnica, especificaciones técnicas para la infraestructura, especificaciones técnicas para el desarrollo de la interfaz. También son puntos de control para el control.
Pregunta 2: ¿Cuáles son las etapas de desarrollo?La respuesta es:- De la distribución de tareas por desarrolladores
- Desde la formación del plan de aceptación.
- De pruebas exhaustivas (pilotaje)
- Desde crear un plan de migración y desarrollar este plan
Pregunta 3: ¿Cuáles son las etapas de la puesta en servicio?
La respuesta es:- Prueba de carga
- La formación de materiales didácticos.
- Entrenamiento del usuario
- Completar todos los NSI (Información de referencia normativa + acceso de usuario)
- Migración de datos
- Conciliación de saldos
- Inicio del trabajo operativo (pilotaje)
- Asistencia en caliente durante el primer lanzamiento
Pregunta 4: ¿Cómo se ve el esquema para transferir el sistema a soporte después de la puesta en marcha?La respuesta es:Al menos el sistema tiene 3 niveles de soporte:
- Soporte de infraestructura y monitoreo de carga del servidor
- Soporte funcional y monitoreo de subprocesos, en caso de que algo salga mal en el sistema.
- Apoyo metodológico que proporciona respuestas a las preguntas de por qué esto funciona de esta manera y no de otra manera, así como también recoge las necesidades de evolución.
Y cada una de estas etapas debe tener su propio SLA. Aquí también hay una palabra que no siempre es clara para las personas ajenas a TI.
Si el candidato PM no nombró todas las etapas, no importa. Podría olvidar algo o preocuparse. A medida que se forma el plan, de alguna manera los encontrará. Es mucho peor si él no se imagina esto en absoluto. La situación se volverá más complicada si comienza a proyectar su experiencia previa de otras áreas comerciales en TI. En este caso, el equipo comenzará conflictos y "muerte" de los desarrolladores. El beneficio de un técnico mismo siempre se puede encontrar donde sea que la gestión competente de un proyecto de TI sea su zona de confort.