En el mundo de las tecnologías de TI modernas, cuando numerosas aplicaciones de Google Play y Appstore informan diariamente sobre las actualizaciones, es bastante común escuchar al equipo del proyecto para la implementación del sistema ERP "el proyecto tomará de 9 (optimista) a 12 meses (realista)". Además, hay proyectos más complejos. En una de las empresas donde trabajaba mi amigo, solo la etapa de creación y firma del diseño de los procesos duró 6 meses. El volumen del documento de diseño resultó ser bastante impresionante y, en forma impresa, bien podría haber salvado la vida de un guerrero de la antigua China (dicen que usaron papel como material para su armadura). Los días de la antigua China han pasado, pero hoy este montón de papeles sigue salvando, si no la vida, al menos el sistema nervioso de los consultores en la etapa de poner en funcionamiento el sistema. Pero lo que no salva un documento de diseño es un cambio en el momento del lanzamiento del proyecto y problemas con la calidad del sistema en el momento de la operación comercial. Tratemos de descubrir por qué sucede esto y si es posible de alguna manera diferente.
Imagine que está ordenando la reparación de su nuevo apartamento. Antes de comenzar a trabajar, el equipo del contratista le pide que firme un documento de texto, generalmente sin ilustraciones, sobre cómo se verá su apartamento después de la reparación, incluidos todos los detalles: enchufes, interruptores, muebles, etc. El líder del equipo advierte que los cambios durante la fase de aceptación son más probables total dará lugar a costos adicionales. Por esta razón, aborda la tarea de manera responsable, pasa mucho tiempo y al final firma el documento. Bueno, supongamos que te vas por seis meses del país. Y confíe completamente en el equipo de implementación para que realice la reparación usted mismo sin ningún control y monitoreo de su parte. Después de seis meses, regrese, entre al departamento y vea que el departamento terminado no cumpla con sus expectativas. Luego le pide al equipo del proyecto que rehaga algunos detalles, por ejemplo, acerque los enchufes al refrigerador. El equipo del proyecto dice que será bastante costoso transferir los enchufes y tomar mucho tiempo, porque tienes que vaciar la pared y hay azulejos, etc. Entras en la habitación, enciendes el aire acondicionado ya instalado y entiendes que te soplarás de noche . Pídale al equipo que lo mueva, pero obtendrá la misma respuesta que con los enchufes. Sin embargo, esto es una cuestión de principios para usted y usted dice que no comenzará a vivir en el apartamento hasta que el aire acondicionado esté donde lo necesita, porque en su apartamento actual está exactamente donde lo necesita, y no ve el punto de mudarse, si es necesario. empeorará la comodidad de tu vida diaria. Como resultado, llama a un departamento 3 meses después del plan original con un exceso de presupuesto del 20%.
El problema principal, en mi opinión, es que estamos tratando de prever y corregir todos los detalles en la etapa de diseño antes de comenzar a trabajar. La fase de diseño se retrasa porque Los usuarios empresariales rara vez pueden dedicarse por completo al proyecto, tienen que ocuparse de sus procesos comerciales diarios. Para el momento en que se firma el diseño, han acumulado una acumulación de tareas pendientes bastante extensa y ya no están listos para involucrarse en el proyecto hasta la etapa de prueba. Ya han pasado mucho tiempo planeando todos los detalles y les gustaría ver un sistema terminado y sintonizado. Sin embargo, el resultado final no cumple con las expectativas. Una razón para esto se ilustra a continuación:
En nuestra empresa, estamos probando con éxito un nuevo enfoque para proyectos para la implementación y replicación de sistemas ERP. Al mismo tiempo, en los proyectos de replicación, el enfoque le permite completar el proyecto incluso más rápido que el plan habitual con fases sucesivas de diseño, desarrollo y pruebas (también conocido como Cascada).
Pasamos de esto:
A esto:
Llamamos a este enfoque mixto (Cascada - Ágil) porque usamos elementos Ágiles (trabajo de sprint) y Cascada (la operación comercial comienza solo después de la finalización de todo el proyecto). La aceleración se debe al hecho de que, en primer lugar, trabajamos con usuarios comerciales en paralelo (trabajo en el diseño de futuros sprints y personalización, desarrollo de los actuales), y en segundo lugar, "transferimos los enchufes" más cerca del futuro refrigerador antes de colocar los mosaicos. y juego de cocina montado. Cuanto mayor sea el volumen del proyecto, mayores serán las ganancias de tiempo y calidad en comparación con el enfoque clásico de Waterfall.
Proyecto de muestra en Marte utilizando un enfoque combinado
Las principales características del proyecto:
- 5½ períodos (22 semanas) desde el inicio hasta el lanzamiento
- Equipo completo del proyecto: 40 personas (usuarios de negocios y consultores de TI, desarrolladores)
- 4 equipos funcionales dentro del equipo del proyecto: Departamento de Finanzas, Compras, Logística y Ventas, Control de Calidad
- 4 ciclos de pruebas comerciales con el 93% de scripts exitosos en el primer intento. 5 talleres a tiempo completo
En la etapa previa al proyecto, estimamos que haríamos el proyecto en 30 semanas. De hecho, utilizando el enfoque ágil, hicimos todo en 22 semanas. Durante 4 meses de operación después del lanzamiento, recibimos 1 solicitud de cambio de la empresa.
Factores clave de éxito
Equipos internos de TI. Tan pronto como sea posible, haga arreglos con los equipos clave de TI que participarán en la implementación. Obtenga el apoyo de la gerencia para entablar un diálogo con un contratista externo.
Contratista externo El equipo del proyecto del contratista debe incluir profesionales que conozcan bien el sistema en sí y los principios de implementación ágil. Los principiantes no deberían ser. Realice entrevistas selectivas con el equipo antes de firmar el contrato.
El equipo de negocios debe tener la oportunidad y el deseo de participar regularmente en el proyecto durante todas las fases de desarrollo. Esto no significa que el negocio tendrá que trabajar más. Redistribuimos su tiempo de la fase habitual de diseño y prueba en cada segmento del desarrollo.
Algunas preguntas frecuentes
Pregunta 1: El departamento comercial solicita firmar un contrato con un contratista de valor fijo antes de comenzar el desarrollo. Pero, ¿cómo evaluar el costo si no hay un diseño completo y firmado?
Respuesta 1: Firmamos un contrato de Equipo fijo con un contratista; fijamos el equipo y el tiempo de implementación del proyecto, por ejemplo, 8 meses. Esto no es lo mismo que Tiempo-Material, ya que Registramos la duración y la cantidad total de trabajo. Al mismo tiempo, seguimos siendo flexibles para cambiar / agregar requisitos comerciales si la duración del proyecto y el equipo no aumentan.
Pregunta 2: ¿Qué sucede si los usuarios comerciales agregan constantemente nuevos requisitos durante la revisión y planificación de cada sprint?
Respuesta 2: en este caso, le pedimos que priorice los requisitos y elimine aquellos que tienen la prioridad más baja y que no se ajustan a los plazos del proyecto. Es decir agregue uno nuevo en lugar de algo existente. Todos estos cambios / nuevos requisitos nos estarán esperando en cualquier caso en la etapa de aceptación, independientemente del enfoque. Pero en el caso de la aceptación intermedia al final de cada sprint, tenemos más oportunidades para gestionar estos requisitos, mientras que al aceptar inmediatamente antes del lanzamiento, corremos el riesgo del momento del lanzamiento y la calidad del sistema (la calidad por definición es la correspondencia del resultado final con las expectativas del usuario, no diseño de texto).
Si está interesado en este artículo, tiene preguntas o simplemente desea compartir una opinión sobre lo anterior, le agradeceré si comparte sus comentarios en la publicación o en un mensaje personal. Ilustraciones y contenido ideológico del artículo con la participación de Angelina Abdullaeva
angelina .abdullayeva.