Como regla general, en el campo del desarrollo web personalizado, todas las agencias solo sueñan con clientes cuyos proyectos crecerán dos veces en facturación anual, entregan regularmente casos de los que puede presumir y ganan premios de calificaciones de perfil para la agencia. Dichos clientes son líderes de la industria. Estas son compañías cuyo negocio se basa en la web o grandes redes fuera de línea que, gracias a inversiones impresionantes, van a las posiciones de liderazgo en el canal web.
Parece que al tener un par de esos clientes, puede descansar en sus laureles, dejar de vender y simplemente controlar el flujo cada vez mayor de tareas. Pero en realidad, a medida que el proyecto crezca, le brindará desafíos nuevos y nuevos para enfrentar y salvar al cliente, mientras trabaja de manera rentable, será una tarea muy difícil.
Crecimiento del proyecto y desafíos relacionados
Es importante tomar medidas proactivas a tiempo y asumir los costos adicionales asociados con el escalado. Al principio, esto puede afectar negativamente la rentabilidad, pero al alcanzar ciertos volúmenes quedará claro que la inversión inicial estaba justificada.
Estos son los principales desafíos que la agencia puede enfrentar en un proyecto de este tipo:
- El problema del escalado es la reestructuración de la estructura del equipo con el crecimiento de los volúmenes.
- La necesidad de comprender el producto y las tareas comerciales: sin una fuerte analítica del producto, es imposible trabajar eficazmente en un proyecto grande.
- Software sofisticado y arquitectura de servidor: de la mano con el crecimiento de los volúmenes de producción bajo el proyecto, también hay un aumento en la asistencia, lo que lleva a una arquitectura más compleja y la necesidad de usar soluciones de alta carga.
- Requisitos de alta calidad.
- La necesidad de garantizar un funcionamiento ininterrumpido 24 × 7 y una alta velocidad de respuesta a incidentes, incluso fuera de horario.
- Alto grado de responsabilidad para detener las ventas.
- Seguimiento y control de indicadores empresariales.
No todas las agencias en el mercado tienen las competencias necesarias para hacer frente a todos estos desafíos. Hoy hablaremos sobre el problema de escalar el equipo, el aspecto más difícil, en mi opinión, de trabajar con un proyecto en crecimiento.
Tuve la oportunidad de trabajar en varios proyectos con un crecimiento explosivo, incluida la tienda en línea más grande de artículos para niños y la compañía de seguros líder.
Participé en estos proyectos primero como gerente, y luego como jefe de un equipo de gestión, y quiero compartir la experiencia adquirida.
Roles en un proyecto pequeño y por qué necesita escalar
El esquema de roles se ve así en el caso general:
En AGIMA, utilizamos la gestión en tres etapas, cuando todas las cuestiones tácticas se deciden en el marco de la interacción dentro del equipo del proyecto, y las cuestiones estratégicas se llevan al nivel de director de cuentas y jefe del departamento de servicio al cliente. Se construye una jerarquía dentro del equipo del proyecto, dependiendo de la escala del proyecto, hablaré sobre esto a continuación.
Así es como se ve un diagrama de roles típico dentro de un equipo de proyecto en un proyecto pequeño:
El proyecto tiene dos roles clave: gerente de proyecto (RP) y líder de equipo.
La empresa se comunica con el cliente, formaliza tareas, elabora una cartera de pedidos, determina prioridades, hace planes y ejerce el control de las tareas para cumplir con la lógica empresarial. Además, RP se comunica en todas las etapas del trabajo con los departamentos de diseño, diseño, análisis y administración de sistemas.
Timlid realiza la formalización técnica de las tareas, define las tecnologías / herramientas utilizadas, realiza una revisión del código, realiza lanzamientos, monitorea la integridad arquitectónica del proyecto y coordina los equipos de desarrollo.
Los recursos restantes se pueden conectar al proyecto según sea necesario y son altamente intercambiables.
Un hito importante en el crecimiento del proyecto y un cambio de paradigma peculiar se produce en un momento en que es imposible mantener toda la información en una cabeza. Un líder de equipo físicamente no puede controlar toda la arquitectura del proyecto, ya que crece demasiado rápido. Un gerente no tiene tiempo para sumergirse en todas las tareas y controlar todo el trabajo.
Hay una necesidad de separación y duplicación de deberes de los empleados, y el esquema de roles estándar se expande y se vuelve más complicado.
Estructura del equipo de gestión
Una de las unidades más difíciles de escalar es RP.
A medida que el proyecto crece, tiene sentido implementar el clásico esquema de administrador de cuentas de pares: administrador de proyectos, cuando un RP se ocupa del servicio al cliente, incluidos los problemas del producto, y el segundo organiza el proceso de producción dentro de la empresa.
Sin embargo, tal esquema se convierte en punto muerto con el crecimiento posterior. En el marco de un proyecto, puede haber hasta varias decenas de productos, cada uno de los cuales requiere una atención cuidadosa desde el punto de vista de los procesos comerciales. En este caso, las situaciones surgen periódicamente cuando el desarrollo paralelo de diferentes productos conduce a conflictos lógicos dentro del marco de la arquitectura de la aplicación web o la lógica empresarial, lo que conlleva riesgos extremadamente altos.
Por lo tanto, el esquema ideal desde el punto de vista de una mayor escalabilidad es el siguiente:
El Jefe de grupo (GH) administra el personal administrativo del proyecto y es responsable de controlar los presupuestos, la rentabilidad, la formación del equipo (tanto ejecutivos como ejecutivos directos) y la asignación de recursos, y resuelve los problemas estratégicos de la gestión del proyecto. También lleva a cabo el control del producto y monitorea la ausencia de conflictos en procesos paralelos. No dedica tiempo a actividades operativas y al monitoreo de la implementación de cada tarea específica.
Gracias a la introducción de este rol, los casos se eliminan cuando se realizan varias tareas grandes en paralelo y se revelan contradicciones y conflictos lógicos en la etapa final, que en el caso menos exitoso resultan en una refactorización completa.
Si es necesario, se conecta una función adicional de propietario del producto, a la cual GH delega parte de las responsabilidades del producto. Muy a menudo, este empleado se basa en el lado del cliente y transmite todos los deseos del negocio en forma de tareas formalizadas para su ejecución.
Cada RP en el equipo es responsable de su "pieza" del proyecto, tomando el control de todas las tareas actuales para una serie de productos (idealmente, estas deberían ser áreas relacionadas). Sus responsabilidades incluyen el tiempo y la calidad de todas las tareas en el marco del desarrollo de productos responsables.
El esquema es fácilmente escalable y tiene un umbral de entrada relativamente bajo, ya que cuando se conecta un nuevo RP, no necesita cubrir simultáneamente toda la base de conocimiento del proyecto, es suficiente para comprender el principio de funcionamiento de "sus" productos.
Es importante que cada RP sea responsable no solo del proceso de producción, sino también de la lógica comercial de sus productos. Gracias a esto, todas las decisiones de gestión no solo son correctas desde el punto de vista de la gestión de proyectos, sino que también son útiles para negocios y arquitectónicamente verificadas.
En algunos casos, el rol del administrador del proyecto se debe destacar por separado: este empleado no se sumerge en el componente del producto o el proceso de producción, sino que se dedica a preparar informes, es responsable de la gestión de documentos y también desempeña el papel de la "primera línea", asegurando la continuidad de la comunicación y las respuestas rápidas a todas las solicitudes de clientes y socios. .
Al mismo tiempo, todo el equipo de gestión incluyó motivación colectiva, vinculada a la gestión de las expectativas del cliente, en primer lugar: entrar en los plazos del proyecto.
- 10 días hábiles antes del comienzo del mes, cada RP asigna de tres a cinco de sus tareas clave para el próximo mes.
- 5 días hábiles antes del comienzo del mes, GH selecciona dos o cuatro de ellos para cada gerente y establece los plazos: 1 - plazo del cliente (50%), 2 - plazo interno (100%) e ingréselo en la tabla.
Condiciones de bonificación (según los resultados del mes):
- El gerente recibe un 100% de bonificaciones si todas sus tareas se completan dentro del plazo interno.
- El gerente recibe el 50% de las bonificaciones si al menos una de sus tareas dejó el período interno, pero se completó en el período del cliente.
- Ninguno de los gerentes recibe bonificaciones si al menos una tarea de la lista general no se completó en el tiempo del cliente.
Este esquema permite que todo el equipo de gestión trabaje de manera eficaz y correcta para gestionar las expectativas del cliente.
Prueba no solo del código final: comando de control de calidad
A medida que el proyecto crece, se acumula una base de conocimiento sólida, aumenta el número de matices y características, las relaciones lógicas se vuelven más complejas y diversas. En algún momento, estos factores comienzan a ejercer una influencia tan fuerte que la depuración previa al lanzamiento lleva un tiempo acorde con el desarrollo y requiere la misma cantidad de recursos.
Para evitar esta situación, se nos ocurrió la idea de crear un equipo de control de calidad completo basado en el equipo de prueba. La principal diferencia es que las pruebas se llevan a cabo no solo en la etapa de desarrollo-depuración-lanzamiento, sino en todas las etapas del proyecto:
- QA es responsable de la calidad del producto y de su cumplimiento estilístico y lógico con otros productos y generalmente aceptado en las reglas del proyecto.
- El control de calidad analiza todos los artefactos que aparecen en el proyecto: la formalización inicial de la tarea, los prototipos, las especificaciones, el diseño y, por supuesto, probar el código y el diseño, escribir casos de prueba, cubrir la funcionalidad existente y nueva con una cuadrícula de pruebas automáticas.
- Sin la validación de los materiales por parte del equipo de control de calidad, el RP no tiene derecho a lanzar la siguiente etapa o enviar materiales para su aceptación al cliente.
Tal enfoque puede reducir en gran medida los riesgos de depuración prolongada y retrasar las fechas de lanzamiento.
Timbales: ¿eficiencia o intercambiabilidad?
Tan pronto como el segundo líder del equipo es presentado al proyecto, la pregunta surge de inmediato: ¿qué esquema de distribución de responsabilidades se debe aplicar?
Hay varias opciones: dividir el proyecto por tipo de actividad, es decir, por ejemplo, el equipo A se enfoca en la arquitectura, la revisión de código y la formalización técnica de las tareas, mientras que el equipo B administra los equipos de desarrollo y lanza las construcciones, es responsable de la continuidad y la seguridad. La segunda opción es un desglose del producto, en el que cada líder de equipo es totalmente responsable de su conjunto de productos dentro del proyecto.
Ambas opciones son buenas en términos de utilización de recursos, pero conllevan grandes riesgos en términos de intercambiabilidad.
Por ejemplo, ¿qué debo hacer si uno de los líderes del equipo se enferma, se va de vacaciones o deja de fumar? Será difícil incluir un nuevo líder de equipo en el proceso, ya que el período de inmersión en este rol es extremadamente largo.
Por lo tanto, vale la pena usar un esquema híbrido en el proyecto, en el que cada líder de equipo se dedica a sus propias tareas, pero hay una serie de actividades en las que se dedican todos o al menos dos líderes de equipo.
Dichas actividades incluyen las de mayor riesgo, por ejemplo: arquitectura del proyecto, continuidad, seguridad, productos clave que representan las ventas más activas y cuyo desempeño se especifica en el SLA.
Este esquema, por supuesto, reduce la productividad laboral, pero elimina la mayoría de los riesgos. Es necesario encontrar un equilibrio entre eficiencia e intercambiabilidad, delineando una lista de los momentos más cruciales.
Por separado, tiene sentido conectar a los líderes de los equipos con actividades alienadas: un producto que está divorciada arquitectónicamente de la parte principal del proyecto, o una actividad que se puede involucrar en paralelo. Por ejemplo, es completamente posible seleccionar un diseño de líder de equipo que tomará el control por completo de todas las operaciones de primera línea; Se distinguen por separado los roles del equipo de control de calidad, diseño, análisis.
Intercambiabilidad de miembros del equipo
Cuantas más personas participen en el proyecto, más activamente necesitará usar herramientas para reducir el umbral de entrada para los nuevos empleados, también simplifican la intercambiabilidad de los miembros del equipo existentes y reducen el factor del autobús.
Aquí hay una serie de herramientas que funcionan bien en casi todos los proyectos.
Sistema de diseñoEl sistema de diseño es un kit de diseño completo y actualizado y una biblioteca de componentes en el repositorio. Refleja el conjunto completo de elementos estándar en el proyecto y le permite recopilar nuevas páginas de estos bloques. El sistema de diseño no solo contiene un conjunto de elementos, sino que también describe su interacción y también contiene ejemplos de código.
El uso de un sistema de diseño puede simplificar enormemente la comprensión de un nuevo empleado, ya sea gerente, diseñador o programador, de las reglas visuales del proyecto, y aplicar soluciones existentes en lugar de inventar constantemente nuevas.
El uso de tales herramientas requiere un gran gasto de recursos para el desarrollo y el apoyo. Además, a menudo toma mucho esfuerzo moral explicarle al cliente por qué es necesario adherirse a este sistema y por qué razón se rechazarán propuestas como "Agregar un nuevo botón verde en esta página, como en el sitio N, que se ve tan hermoso".
La documentaciónCuanto más grande sea el proyecto, más cuidadosamente se documentará cada producto y cada característica, de lo contrario, los expertos dedicarán más y más tiempo a la depuración y a descubrir cómo debería funcionar uno u otro funcional.
La documentación del proyecto tiene sentido dividir en 4 tipos:
- Especificaciones de la interfaz: una descripción del comportamiento de la funcionalidad implementada (lógica de trabajo, validación de campo, conjunto de pantallas).
- Casos de prueba (descripción de escenarios de usuario y los resultados de su aprobación), en base a ellos, si es necesario, se desarrollan pruebas automáticas.
- Especificaciones del servicio (descripción de la interacción con los servicios web, datos de prueba, ejemplos de solicitud-respuesta).
- Documentación de código (descripción de componentes, clases y su jerarquía, plantillas).
Toda la documentación debe agregarse en una base de conocimiento en línea (Wiki) y mantenerse actualizada.
GitPara acelerar la conexión de nuevos desarrolladores de otros proyectos de la compañía, se está introduciendo un enfoque estándar para GitFlow. En AGIMA utilizamos el enfoque de "trabajar con dos ramas principales".
En lugar de usar la rama maestra, se usan dos ramas principales del historial del proyecto: la maestra para lanzamientos y la desarrollada para fusionar la funcionalidad desarrollada de las ramas de características.
Flujo de trabajoOtra herramienta que regula y estandariza el trabajo de todos los miembros del equipo es el flujo de trabajo por día de la semana.
Cada semana es un ciclo de producción estándar: los lanzamientos se realizan estrictamente los martes y jueves; Miércoles - día de evaluaciones; La retrospectiva y la planificación de nuevos envíos se realizan al final de la semana, los jueves y viernes. Este es un ejemplo de un flujo de trabajo de uno de los proyectos, para cada caso específico, se debe desarrollar un enfoque.
El cliente también debe participar en el flujo de trabajo; dicho sistema no puede funcionar unilateralmente.
No menos importante es el flujo de trabajo en el estado de las tareas, que simplifica la transición de los empleados entre proyectos. Debe ser idéntico en todos los proyectos de la empresa. En AGIMA, se ve así:
Mantener informados a los miembros del equipo
Incluso si la documentación está perfectamente organizada en el proyecto y todos los procesos funcionan como un reloj, es imposible prever todos los riesgos asociados con la falta de conocimiento de cada artista específico. Para esto, se organizan eventos regulares de varios formatos.
1. Reuniones de productosEn tales reuniones, los empleados más experimentados le cuentan al equipo sobre productos específicos. Se destacan los aspectos de lógica empresarial, implementación técnica y arquitectura. La conciencia de cada empleado sobre los principales matices de los productos ayuda a presentar ideas útiles y tomar las decisiones correctas en todas las etapas de implementación.
2. Secciones de infraestructuraEl proyecto está creciendo dinámicamente, esto implica el constante desarrollo y expansión de la infraestructura. En las secciones regulares, se discuten los problemas y tareas actuales para el desarrollo de la infraestructura, y se discute el progreso en la implementación de cada uno de ellos.
3. Retrospectivas y planificación del trabajo.Es necesario mantener reuniones semanales para discutir las tareas implementadas durante la semana pasada, resaltar errores y planificar el trabajo para el próximo período contable.
Conclusiones
La aplicación cuidadosa de todas las herramientas y enfoques anteriores ayudará a construir un equipo coherente y resistente que se ampliará fácilmente con el mayor crecimiento del proyecto.
Sin lugar a dudas, la organización de un sistema de este tipo conlleva una serie de dificultades y requiere competencias profundas dentro de la agencia y la disposición del cliente a invertir en tales decisiones, lo que puede ser difícil en nuestro mercado en desarrollo, pero tales esfuerzos dan resultado y conducen a una cooperación fructífera a largo plazo y permiten emitir El mercado es realmente productos de calidad.