Después del pilotaje "caliente" la semana pasada, el cerebro aparentemente se relajó y quedó atrapado en la pregunta: "¿Qué debería haberse hecho para que todo saliera bien y sin todos estos nervios?"
Intentaré indicar las opciones para las respuestas que generó.
Sobre mí
9 años - Consultor de TI SAP ERP. Responsabilidades: diseño, trabajo en equipo, pruebas y depuración, capacitación, pilotaje.
Marco de aplicabilidad
Escribió en base a proyectos de 3 a 4 meses a 1 año con integración entre sistemas compleja.
Habiendo decidido no arriesgarme a ahogarme en el logro del perfeccionismo, habiendo perdido la pasión inicial por la escritura, tuve que abandonar las afirmaciones de un alto nivel de estructura, consistencia e integridad. Por las mismas razones, escribí el texto solo "por experiencia personal", no leí los textos que estaban en sintonía con el tema antes de la publicación.
Por lo tanto, hasta cierto punto, cuento con los comentaristas para, posiblemente, escribir una segunda edición, en la que los criterios anteriores ya estaban en el nivel adecuado.
Glosario
BA - analista de negocios
BZ - base de conocimiento del proyecto
BT - requisitos de negocios
TI - arquitecto y consultores del equipo del proyecto
KP - usuario clave de
MC - consultor junior,
PR enikeista - solución de diseño
Prod -
desarrollador del sistema productivo - desarrollador
CT - escenarios de prueba
SC - senior consultor, diseñador de
especificaciones técnicas - términos de referencia
Claves para el éxito del proyecto de TI
El mensaje general es comunicación fluida.
Es necesario lograr la sincronización entre el negocio y la TI en la percepción de los requisitos del negocio, escenarios de prueba, decisiones de diseño y cómo se verá en la implementación.
BT detallado y reflexivo
BT debe tener una comprensión completa y sincrónica entre el negocio y la TI. Para hacer esto, debe ser BA y KP (idealmente, cuando BA es un antiguo KP).
Conjunto completo de scripts de prueba
El número máximo de escenarios máximamente detallados debe conocerse y calcularse antes de escribir la solución. Los guiones deben escribirse en orden desde el más común hasta el más raro. Este último, en el caso de su costosa automatización, debe tener un cuidadoso control manual.
División del trabajo dentro de TI
El equipo del proyecto debe tener una división de acuerdo con la complejidad intelectual del trabajo. Es bueno si el diseñador tiene la habilidad de diseñar la documentación estilísticamente sin costo adicional. De lo contrario, es mejor dar la guía de "belleza" a una persona con una posición junior.
Lo mismo se aplica al contenido de TK / PR en el estado actual:
- SK escribe al desarrollador sobre los ajustes y coloca el MK en una copia
- MK recopila y refleja los cambios en el modo de edición utilizando versiones
- SK acepta ediciones
- MK actualiza la documentación en el KB
Las pruebas también deben delegarse a MK.
No sé cómo fuera de SAP, pero el principio de un consultor-recolector se usa muy a menudo aquí, lo que hace todo (diseño, prueba, redacción de documentación).
Como resultado, la calidad, los términos (y "dinero") sufren y los riesgos asociados con el hecho de que todo está atado para 1 persona
Prueba de guiones antes del lanzamiento
- Las pruebas deben llevarse a cabo en un entorno cercano a la producción (idealmente en una copia de las ventas).
- La participación de personas que trabajarán directamente con la funcionalidad es obligatoria (es aconsejable llevar a cabo un programa educativo por decisión previa).
Espacio común para equipos que integran sistemas
Cuando hay una integración compleja en el proyecto, es imperativo crear un campo común del contexto del proyecto y proporcionar "cerca del cuerpo". Idealmente, todo el equipo del proyecto debería estar en una habitación. De lo contrario, necesita una persona separada o una herramienta conveniente que brinde sincronización entre los equipos.
Adecuación técnica del host
La aprobación formal del RP por parte de la empresa es el flagelo del proyecto. El anfitrión debe imaginar completa y detalladamente la decisión. Si el proyecto se refiere a una profunda modernización de la funcionalidad existente, entonces la empresa debería saberlo perfectamente.
Idealmente, si el anfitrión es una persona de negocios perfectamente informada con una lógica consistente y estructurada.
Moderador piloto
Neutral para las personas de TI y de negocios con las características de un árbitro. Crea un plan piloto, elabora informes de prueba, realiza un seguimiento de los comentarios y sus correcciones.
Si hay prisa, existe una idea para describir los problemas que pueden surgir si no se siguen las recomendaciones descritas.