Aceleramos el proceso de desarrollo de proyectos complejos. Sin caos y nervios

En la práctica, a menudo nos encontramos con el hecho de que el gerente de proyecto quiere acelerar el proceso de desarrollo; no está satisfecho con la velocidad de entrega de nuevas funciones. Por lo general, dichos clientes necesitan productos complejos, como un sistema de gestión hospitalaria, un sistema de intercambio comercial, sistemas bancarios y servicios bancarios.

En tales casos, puede conectar un nuevo equipo de especialistas, establecer procesos en uno existente o combinar ambos. Considere los pros y los contras de cada enfoque. Inmediatamente haga una reserva de que el artículo discute el desarrollo de proyectos grandes y complejos (más de 10,000 horas).

¿Por qué no puede conectar de inmediato a nuevos especialistas?

A menudo, la opción más fácil y obvia para aumentar la velocidad de desarrollo es conectar nuevos especialistas o un equipo. Al gerente del proyecto le parece que esto puede acelerar la velocidad de entregar valor comercial a los usuarios finales. En la práctica, este no es siempre el caso, especialmente cuando los procesos en el proyecto requieren procesamiento. Damos un ejemplo de nuestra práctica.

Era necesario conectar dos equipos a un proyecto de desarrollo existente. El proyecto se ha desarrollado durante más de 4 años y contiene una gran cantidad de subsistemas (más de 20) con sus mecanismos y servicios comunes. Una regresión completa requirió la participación de 5-7 ingenieros de control de calidad y aproximadamente 4-6 días hábiles. Al ingresar al proyecto y dejar a los equipos al nivel requerido de resolución de problemas, se encontraron con las siguientes dificultades:

• Una parte del código fuente del sistema estaba bajo el control del sistema de control de versiones svn, la otra git. SVN era anteriormente muy popular, sin embargo, para proyectos de equipos grandes y frecuentes cambios concurrentes, no es adecuado. Por lo tanto, antes de cambiar a git, se dedicó parte del tiempo a fusiones, edición de conflictos y otras operaciones relacionadas con la ramificación en svn.
• Había una instrucción desactualizada para implementar el entorno, por lo que los equipos recopilaron todo tipo de dificultades de este sistema y solo pudieron comenzar las primeras tareas después de 3-4 días.
• Analistas clave, expertos técnicos estaban ocupados preparando el lanzamiento, por lo que era imposible obtener rápidamente información aclaratoria sobre nuevas tareas. La configuración de la tarea fue de muy alto nivel. Esto ralentizó significativamente la implementación de tareas.
• El flujo de trabajo de las tareas fue difícil, al principio los equipos "tropezaron" con la forma de abordar la tarea durante todo su ciclo de vida.
• Al principio, el cliente quería sobrevivir solo con los esfuerzos de sus ingenieros de control de calidad, pero no lograron verificar completa y rápidamente la nueva funcionalidad de los equipos de desarrollo conectados, debido a la gran carga. Por lo tanto, tuve que trabajar con horas extras.
• La revisión del código se realizó de acuerdo con los principios y criterios establecidos por el proyecto. Los criterios no han sido documentados. Por lo tanto, se dedicó más tiempo a corregir los comentarios.

El resultado de los matices anteriores son:

• costos de tiempo adicionales que podrían gastarse en resolver problemas comerciales
• lento desarrollo de todo el sistema
• o horas extras

Considere cómo evitar esta situación.

Análisis de procesos

Antes de conectar a nuevos especialistas, vale la pena averiguar cómo se organiza el trabajo del equipo: es necesario encontrar y eliminar los cuellos de botella. Por lo general, PM se ocupa de este problema, ya que él es responsable del proyecto y quiere gastar menos energía en los procesos de seguimiento.

Al eliminar los cuellos de botella, el proyecto avanza. Por ejemplo, el tiempo requerido para ingresar a un nuevo especialista o equipo de especialistas se reduce, la participación del equipo en el proyecto aumenta, el costo de una hora se reduce debido a la correcta implementación de las tareas la primera vez. Si se eliminan todos los cuellos de botella, el gerente del proyecto recibirá un aumento tan rápido en la velocidad de desarrollo como lo permitan la práctica actual y el contexto del proyecto. En general, es bueno para todos.

El análisis de los cuellos de botella es posible desde dos lados: desde la alta dirección / experto y desde el equipo. Analizaremos cada opción por separado.



Expertos externos. En este enfoque, el proceso de trabajo es analizado por un equipo externo de expertos externos o por el gerente del proyecto junto con el líder del equipo. Con este último, no es el hecho de que resulte: es importante que puedan descartar todos los matices del proyecto, de lo contrario, el análisis no tendrá sentido.

Una condición importante es el apoyo a la gestión de proyectos y la preparación para el cambio.

En consecuencia, el experto se sumerge en el proyecto y analiza en detalle la documentación, el código fuente, la estructura de la base de datos, el proceso de producción (desde el análisis hasta el lanzamiento). El trabajo por fases se ve así:

1. Se considera toda la cadena de trabajo del proyecto de principio a fin. Se mide el tiempo de cada proceso.
2. Se construye un diagrama de Gantt. El experto observa qué procesos se ejecutan en paralelo, cuáles uno tras otro.
3. Un experto piensa cómo hacer que cada proceso sea más productivo y menos costoso. Como regla general, un experto entiende intuitivamente en qué lugares surgen las mayores dificultades y comienza a agilizarlas para una posible modernización.

Las ventajas de este enfoque:

• El trabajo es analizado por una persona que no está involucrada en el proyecto. Tiene una visión directa de los procesos, por lo tanto, puede encontrar aquellos problemas que no son visibles para los miembros del equipo.
• Un experto, como autoridad, puede convencer a un equipo para que acepte cambios en los procesos. Los equipos que han estado trabajando en un proyecto durante mucho tiempo no buscan la innovación. Para ellos, esto es mucho estrés, ya que tendrán que volver a aprender. Además, tal reacción va incluso a aquellos cambios que ayudarán a trabajar de manera más eficiente.
• Implementación rápida de soluciones: de 2 a 15 días. Todo depende del cambio global y la burocracia dentro de la organización.
• El equipo del proyecto aprovecha la experiencia de expertos externos. En el futuro, esto ayudará a configurar los procesos de forma independiente.

Contras:

• Los expertos necesitan pasar mucho tiempo para comprender las complejidades. El equipo puede estudiar la historia del proyecto en un día, mientras que el experto necesita al menos una semana y media.
  Qué hacer al respecto : establezca los objetivos del análisis junto con el gerente del proyecto / líder del equipo. Entregue al experto todos los proyectos "introductorios", no oculte los detalles.
  
  Si el cliente es tan leal que está listo para analizar iterativamente el proyecto, debe aprovechar la oportunidad y aceptar dichas condiciones. Posteriormente, será posible ajustar la dirección del análisis después de cada iteración, centrándose solo en la deseada.
• Algunos miembros del equipo pueden no estar de acuerdo con la decisión. Posteriormente, pueden sabotear el proyecto, implementar mal el acuerdo y esto afecta el estado de ánimo general del equipo.
  
  Qué hacer al respecto: discuta cada decisión con el equipo y no las ponga justo antes del hecho.
  
  Opción ideal: el experto analiza los procesos de forma independiente y luego los discute con las personas clave del proyecto. Si hay contradicciones, las discuten. Esto acumulará a muchas personas leales a los cambios que afectarán a otros miembros del equipo. Será posible convencer a los escépticos más ardientes.

Del equipo Este enfoque se puede llamar una retrospectiva, que es una parte integral del scrum. El proceso se ve así:

• Todo el equipo del proyecto se va
• Uno de los participantes asume el rol de facilitador (scrum-master). Se asegura de que la conversación sea constructiva.
• El equipo discute sus enfoques de trabajo. Se consideran todos los aspectos: procesos, codificación, establecimiento de objetivos, etc. Luego se destacan los pros y los contras.
• En una votación general, acuerdan los cambios: las ventajas deben ser reparadas, las desventajas eliminadas.
• Después de 3-4 semanas, el proceso se repite. El equipo observa los resultados, y si todos están contentos con todo, entonces el trabajo continúa.

Términos importantes:

1. Soporte de gestión para cualquier cambio e innovación.
2. Cohesión del equipo y enfoque en la mejora.

Si la cultura de la empresa no fomenta la iniciativa, la innovación, entonces la retrospectiva no es la mejor manera de rediseñar los procesos. Los miembros del equipo no irán más allá de su "pantano".

Ventajas del enfoque:

• Participación de cada participante en la discusión del proyecto.
• La capacidad de identificar todos los aspectos positivos del proyecto y, si es necesario, formarlos en un determinado modelo (mejor práctica).
• Los miembros del equipo comparten experiencias entre ellos.
• Resolución gradual de problemas, comenzando por aquellos que ralentizan más al equipo y al proyecto, terminando con pequeñas mejoras.

Contras:

• Existe el riesgo de que solo se resuelvan problemas menores, y todos los problemas clave permanecerán intactos.
  Qué hacer al respecto : PM, el líder del equipo y el facilitador deben influir en su opinión sobre el equipo a través de la autoridad. Su tarea es llamar la atención sobre problemas importantes en la etapa de discusión.
• Para cambios importantes que requieren mucho trabajo, se requiere tiempo adicional para la coordinación con la gerencia. Sin embargo, no es un hecho que la gerencia esté de acuerdo con las innovaciones.
  Qué hacer al respecto : defender su punto de vista ante el liderazgo es la única solución.
• Si el equipo no cuenta con capacitación continua (conferencias, intercambio de experiencias, capacitaciones), lo más probable es que las decisiones alcanzadas sean obsoletas y no sean tan efectivas.
  Qué hacer con él : intercambiar experiencias constantemente. Participe en conferencias relevantes, reuniones, entrenamientos internos. Si hablamos de una gran empresa, entonces una buena opción serían los días de demostración. En tales eventos, los equipos muestran qué resultados lograron en su trabajo.

En la mayoría de los casos, puede obtener adaptando y mejorando los procesos descritos anteriormente. Incluso si inicialmente está claro que realmente es posible completar el proyecto a tiempo solo atrayendo nuevos especialistas / equipos, le recomendamos encarecidamente que pruebe los pasos anteriores.

Si, después de eliminar los cuellos de botella, el gerente del proyecto cree que la capacidad no ha alcanzado el nivel deseado, entonces puede conectar nuevos equipos.

Preparando infraestructura para nuevos equipos

En esta etapa, vale la pena llevar a cabo un trabajo preparatorio que reducirá la duración y el costo de desarrollo, ayudará a salvar las células nerviosas de los desarrolladores. Consideremos qué condiciones deberían ser:

1. Las tareas para el nuevo equipo deben detallarse en detalle. Puede iniciar cada uno de ellos sin esperar, no depende de las tareas actuales o futuras. Se describen las áreas de responsabilidad de cada equipo.
   Si este no es el caso , entonces la mayoría del nuevo equipo permanecerá inactivo o participará en tareas secundarias que tengan el menor impacto en el valor del producto.
2. La arquitectura del proyecto es "correcta", es decir desglosado en módulos, subsistemas, componentes comunes.
   
   Si esto no sucede , la conexión de un nuevo comando fallará. Los desarrolladores trabajarán bajo el control del líder del equipo actual, pero una persona puede administrar efectivamente no más de 7-9 personas. Timlid se romperá y algunos miembros del equipo esperarán inactivos hasta que se les asignen tareas.
   
   Si no es posible aislar secciones aisladas del código del proyecto, pero necesita avanzar, puede intentar evitar esta limitación. Es necesario dividir el proyecto en varias partes mediante la refactorización.
   
   Otra opción: después de sumergir a dos o tres personas en el proyecto, dar al nuevo equipo más y más grandes funciones empresariales. Por lo tanto, los equipos desarrollarán el proyecto de manera aislada, y debido al nuevo líder del equipo (una persona que está inmersa en las sutilezas) reducirá la carga sobre el líder del equipo principal.
3. Los procesos de trabajo en el proyecto se describen en detalle. Por ejemplo, hay una tarea de flujo de trabajo, se muestra que la tarea se ejecuta en el sistema de control de versiones (la práctica muestra que no todos tienen un GitFlow estándar), se describe la interacción entre los participantes del proyecto.
   Si esto no sucede , se creará el caos en el proyecto. En este caso, el gerente del proyecto solo se ocupará de la gestión de emergencia “manual”.
4. Los componentes y módulos comunes tienen documentación relevante y comprensible. Hay pruebas de unidad e integración de las partes principales. Hay una descripción clara de la arquitectura de todo el proyecto, los mecanismos generales, así como las instrucciones sobre cómo aplicarlos. Si lo anterior aún no existe, entonces es necesario agregar tareas similares al grupo de deuda técnica para corregir la situación.
   
   Si este no es el caso , entonces aumenta el riesgo de hacer doble trabajo. Se escribirá un código fuente pobre o duplicado. En el futuro, esto conducirá a un soporte de proyecto más costoso. Como regla, conectar un nuevo equipo implica la posible conexión de varios equipos más. En consecuencia, los costos de tiempo serán escalados por un múltiplo del número de equipos.
5. Existen reglas fijas para escribir código: código de convención, scripts para actualizar la estructura de la base de datos: migración, principios generales de revisión obligatoria del código. A pesar de la gran similitud, seguro que cada proyecto tiene sus propias características.
   Si este no es el caso , la complejidad y el costo de seguir apoyando el proyecto aumentarán muchas veces.

Las condiciones anteriores le permiten conectar nuevos equipos de manera más efectiva. El tiempo que le toma a un equipo ingresar a un proyecto se reduce notablemente. Lo mismo sucede con los costos laborales de apoyar y desarrollar el proyecto.

Cómo conectamos un equipo adicional al proyecto

Tuvimos un caso cuando el proyecto necesitaba urgentemente acelerar el proceso de desarrollo. Se dejaron 2-3 meses hasta que la próxima versión principal se puso en operación comercial. El proyecto en sí era un sistema complejo que fue desarrollado por un equipo durante 3-4 años.
En primer lugar, nos sumergimos en el contexto del proyecto en sí. El resultado es la siguiente imagen de los cuellos de botella del proyecto:

1. No existe una única información precisa sobre cómo se deben implementar las características. La lista de tareas, errores, mejoras no está actualizada.
2. No existe una integración continua, y el desarrollo se lleva a cabo en dos ramas.
3. El proceso de prueba del producto no se depura. Por ejemplo, los ingenieros de control de calidad pueden encontrar errores que ya se han solucionado, lo que conlleva costos de mano de obra adicionales.
4. La base de los casos de prueba estaba en su infancia. Los ingenieros individuales de control de calidad comenzaron a escribir casos por sí mismos. Debido a esto, nadie podría dar una cierta evaluación de la calidad del producto y los posibles riesgos al lanzar una nueva versión.
5. El proceso de trabajo, desde la producción hasta la aprobación del cliente, no está documentado. Fue imposible predecir la composición exacta de las funciones de liberación, así como otros puntos menos significativos.

Después del análisis, creamos un plan para eliminar los puntos anteriores. Por supuesto, el equipo no estuvo de acuerdo inmediatamente con los cambios, pero con el apoyo del liderazgo y el desarrollo de plazos claros, pudimos persuadir a cada miembro del equipo.

Coordinamos nuestras acciones con las personas clave del proyecto: PM, líder de equipo, analista líder. Juntas, estas tres personas constituyen un solo centro de equipo de gestión de clientes. Además, promueven soluciones y monitorean su implementación en la práctica. Sin dicho equipo de gestión, es imposible coordinar las acciones de más de tres equipos.

Como resultado, se implementaron / optimizaron los siguientes procesos:

1. Creamos comunicaciones entre todos los miembros del equipo de producto: desarrolladores, analistas y especialistas en pruebas.
2. Documentaron funciones críticas y complejas para realizar pruebas más transparentes, eliminar defectos, resolver disputas y planificar el trabajo posterior.
3. Procesos de desarrollo optimizados. Adoptado por el proyecto WorkFlow y GitFlow. Ayudaron a configurar la integración continua y ejecutar pruebas automáticas en modo automático.
4. Duplicamos la velocidad de montaje de los bancos de prueba.
5. Organizó el proceso de pruebas adecuadas. Implementamos pruebas de regresión al final de cada iteración.
6. Introdujo el proceso de planificación de iteración.
7. Prueba de carga conducida.

Con base en los resultados de la primera iteración, preparamos la infraestructura para conectar un nuevo equipo. Paralelamente, dos de nuestros desarrolladores se unieron al equipo actual para sumergirse en la base del código. Entonces uno de ellos se convirtió en el líder del equipo del nuevo equipo. En la segunda iteración, los dos equipos lograron los siguientes resultados:

• Puesta en servicio después de 3 meses.
• Se corrigió el 70% de los errores.
• Cuatro características serias implementadas
• Optimizado y aumentado en 8 veces la velocidad de carga de algunas páginas.
• Recibí información precisa sobre la calidad de todo el producto.
• Construido RoadMap Iterations

Creo que uno de los logros más importantes de este proyecto es la alegría del cliente. Representó de manera transparente el estado del proyecto en cualquier momento, y las obligaciones con el negocio se cumplieron en su totalidad y a tiempo.

Conclusión

Hay dos formas principales de aumentar la velocidad del desarrollo del proyecto: eliminar los cuellos de botella y aumentar las capacidades de producción. En el primer caso, puede obtener un aumento del 30-40% en la velocidad de desarrollo, en el segundo 70-80%. Los comandos adicionales no dan un doble aumento en la productividad, ya que se dedica más tiempo a la interacción entre varios equipos.

Los factores clave de éxito para expandir los equipos de desarrollo son:

• trabajo preparatorio
• procesos establecidos
• un líder o miembro de un equipo de proyecto que promovería y supervisaría las actividades de los equipos,
• Centro de control de comando único.

Actualmente, tres equipos están trabajando en el proyecto que describimos anteriormente (uno antiguo y dos nuevos). El número de tareas realizadas aumentó en 1,9 veces .