🥇 Organización del flujo de trabajo en equipo en un proyecto de TI

Hola amigos. Constantemente, especialmente en el outsourcing, veo el mismo panorama. La falta de un proceso de trabajo claro en los equipos de diferentes proyectos.

Lo más importante es que los programadores no entienden cómo comunicarse con el cliente y entre ellos. Cómo construir un proceso continuo de desarrollo de productos de calidad. Cómo planificar su jornada laboral y los sprints.

Y todo esto, al final, resulta en plazos incumplidos, horas extras, discusiones constantes sobre quién es el culpable y descontento de los clientes — adónde y cómo se está moviendo todo. A menudo, todo esto lleva al cambio de programadores, e incluso de equipos completos. A la pérdida de clientes, al deterioro de la reputación, y así sucesivamente.

En su momento, yo también caí en un proyecto así, donde había todas estas dificultades.

Nadie quería asumir la responsabilidad del proyecto (un gran marketplace de servicios), había una alta rotación, y el cliente estaba furioso. El CEO se acercó a mí y me dijo que tenía la experiencia necesaria, así que aquí tienes las riendas. Tómalo como tuyo. Si fracasas, cerraremos el proyecto y despediremos a todos. Si lo haces bien, será genial; entonces, dirígelo y desarróllalo como creas conveniente. Al final, me convertí en el líder del equipo en el proyecto y todo recayó sobre mis hombros.

Lo primero que hice fue desarrollar un proceso de trabajo desde cero, que en ese momento se alineaba con mi visión, y redacté un manual de funciones para el equipo. No fue fácil implementarlo. Pero, tras un mes, todo se estabilizó, los desarrolladores y el cliente se acostumbraron, y todo comenzó a fluir de manera tranquila y cómoda. Para demostrar al equipo que no era solo una "tormenta en un vaso de agua", sino una solución real, asumí la mayor parte de las responsabilidades, liberando al equipo de la rutina desagradable.

Ya ha pasado un año y medio, y el proyecto avanza sin horas extras, sin "carreras de ratas" y sin diversos tipos de estrés. Algunos en el antiguo equipo no quisieron trabajar así y se fueron, mientras que otros, por el contrario, apreciaron la existencia de reglas claras. Pero al final, todos los que están en el equipo están muy motivados y conocen a fondo el gran proyecto, tanto el frontend como el backend. Incluyendo la base de código y toda la lógica de negocio. Ya hemos llegado al punto de que no solo somos "remeros", sino que también diseñamos muchos de los procesos de negocio y nuevas características que han gustado al negocio.

Gracias a este enfoque de nuestra parte, el cliente decidió encargarnos otro marketplace, lo cual es muy gratificante.

Dado que esto funciona en mi proyecto, puede que también a alguien le sirva. Entonces, el proceso que nos ayudó a salvar el proyecto:

Proceso de trabajo del equipo en el proyecto "Mi proyecto favorito"

a) Proceso interno del equipo (entre desarrolladores)

Todas las tareas se crean en el sistema Jira
Cada tarea debe estar descrita al máximo y realizar una sola acción específica
Cualquier función, si es lo suficientemente compleja, se divide en muchas tareas pequeñas
El equipo trabaja en las funciones como si fuera una única tarea. Primero, hacemos juntos una función, la enviamos a pruebas y luego abordamos la siguiente.
Cada tarea se etiqueta, ya sea para el backend o el frontend
Existen tipos de tareas y bugs. Es necesario especificarlos correctamente.
Después de completar la tarea, esta se cambia a estado revisión de código (se crea un pull request a un colega)
Quien realizó la tarea rastrea su tiempo para esta tarea inmediatamente
Después de revisar el código, el PR es aprobado y luego, quien realizó esta tarea la fusiona en la rama principal, tras lo cual cambia su estado a lista para despliegue en dev servidor.
Todas las tareas listas para despliegue en el servidor dev son desplegadas por el team lead (es su responsabilidad), a veces por un miembro del equipo, si hay algo urgente. Después del despliegue, todas las tareas con estado lista para despliegue en dev se traducen a estado - lista para pruebas en dev
Todas las tareas son probadas por el cliente
Cuando el cliente prueba la tarea en dev, la cambia a estado lista para despliegue en producción
Para el despliegue en producción tenemos una rama separada, donde fusionamos la principal solo antes del despliegue
Si durante las pruebas el cliente encuentra bugs, devuelve la tarea para mejorar, estableciendo su estado como devuelta para mejoras. De esta manera, separamos las nuevas tareas de aquellas que no han pasado las pruebas
Al final, todas las tareas siguen el camino de creación a finalización: To Do → En Desarrollo → Revisión de Código → Listo para desplegar en dev → QA en dev → (Devolver a dev) → Listo para desplegar en producción → QA en producción → Hecho
Cada desarrollador prueba su código de forma independiente, incluidos los aspectos como usuario del sitio. No se permite la fusión de la rama principal a menos que se sepa con certeza que el código funciona.
Cada tarea tiene prioridades. Las prioridades son establecidas ya sea por el cliente o por el líder del equipo.
Los desarrolladores priorizan primero las tareas más críticas.
Los desarrolladores pueden asignar tareas entre ellos si se encuentran diferentes errores en el sistema o si una tarea requiere el trabajo de varios especialistas.
Todas las tareas creadas por el cliente llegan al líder del equipo, quien las evalúa y decide si pide al cliente revisión o las asigna a uno de los miembros del equipo.
Todas las tareas listas para desplegar en desarrollo o producción también llegan al líder del equipo, quien determina cuándo y cómo se realizará el despliegue. Después de cada despliegue, el líder del equipo (o un miembro del equipo) debe informar al cliente. También debe cambiar el estado de las tareas a 'listo para pruebas' en desarrollo/producción.
Todos los días a la misma hora (para nosotros, a las 12:00) realizamos una reunión entre todos los miembros del equipo.
En la reunión, cada uno rinde cuentas, incluyendo al líder del equipo, sobre lo que hizo ayer, lo que planea hacer hoy, y cualquier obstáculo que esté enfrentando. De esta manera, todo el equipo está al tanto de lo que cada uno está haciendo y en qué etapa se encuentra el proyecto. Esto nos permite prever y corregir, si es necesario, nuestras estimaciones y plazos.
En la reunión, el líder del equipo también informa sobre cualquier cambio en el proyecto y el nivel de errores actuales que han sido identificados y no por el cliente. Todos los errores son discutidos y asignados a cada miembro del equipo para su resolución.
En la reunión, el líder del equipo asigna tareas a cada uno, teniendo en cuenta la carga actual de los desarrolladores, su nivel de competencia profesional y la cercanía de cada tarea a lo que el desarrollador está trabajando en ese momento.
En la reunión, el líder del equipo formula una estrategia general sobre la arquitectura y la lógica de negocio. Después, todo el equipo discute esto y toma una decisión sobre si hacer ajustes o aceptar esta estrategia.
Cada desarrollador escribe código y construye algoritmos de manera independiente dentro de una misma arquitectura y lógica de negocio. Cada uno puede expresar su visión de la implementación, pero nadie es forzado a hacerlo de una manera específica. Cada decisión se argumenta. Si hay una mejor solución pero no hay tiempo para ella en ese momento, se crea una tarea en JIRA para una futura refactorización de una parte específica del código.
Cuando un desarrollador asume una tarea, la cambia a estado de desarrollo. Toda la comunicación sobre la clarificación de la tarea con el cliente queda bajo la responsabilidad del desarrollador. Las cuestiones técnicas pueden ser dirigidas al team lead o a colegas.
Si el desarrollador no entiende el sentido de la tarea y el cliente no ha podido explicarlo adecuadamente, procede a la siguiente tarea. El team lead toma la actual y la discute con el cliente.
Cada día el desarrollador debe escribir en el chat del cliente sobre qué tareas trabajó ayer y en cuáles trabajará hoy.
El proceso de trabajo se realiza bajo la metodología Scrum. Todo está dividido en sprints. Cada sprint dura dos semanas.
El team lead crea, llena y cierra los sprints.
Si el proyecto tiene plazos estrictos, tratamos de estimar aproximadamente todas las tareas. Y recopilamos a partir de ellas un sprint. Si el cliente intenta añadir más tareas al sprint, entonces establecemos prioridades y trasladamos algunas otras tareas al siguiente sprint.

b) Proceso de trabajo con el cliente

Cada desarrollador puede y debe comunicarse con el cliente.
No se debe permitir al cliente imponer sus propias reglas de juego. Es necesario hacerle entender de manera educada y amigable que somos especialistas en nuestro campo y que solo nosotros debemos definir los procesos de trabajo e involucrarlo en ellos.
Es recomendable, en ideal, antes de comenzar la implementación de cualquier funcionalidad, crear un diagrama de flujo de todo el proceso lógico para la funcionalidad. Y enviarlo para su aprobación al cliente. Esto se refiere solo a funcionalidades complejas y no evidentes, como sistemas de pago, sistemas de notificaciones, etc. Esto permitirá entender de manera más precisa lo que realmente necesita el cliente, mantener la documentación de la funcionalidad y protegernos de que el cliente pueda, en el futuro, decir que hicimos algo diferente a lo que pidió.
Todos los diagramas / mapas de flujo / lógica, etc., los guardamos en Confluence / Jira, donde pedimos al cliente que confirme en los comentarios la corrección de la futura implementación.
Tratamos de no abrumar al cliente con detalles técnicos. Si necesitamos entender cómo desea el cliente, dibujamos algoritmos primitivos en forma de mapas de flujo que el cliente puede comprender y corregir / modificar por sí mismo.
Si el cliente encuentra un error en el proyecto, le pedimos que lo describa detalladamente en Jira. Las circunstancias en las que ocurrió, cuándo, qué secuencia de acciones realizó el cliente durante las pruebas. Pedimos que adjunte capturas de pantalla.
Tratamos de desplegar en el servidor de desarrollo todos los días, o al menos cada dos días. Luego, el cliente comienza a probar la funcionalidad y el proyecto no se queda parado. Esto también sirve como un indicador para el cliente de que el proyecto está en desarrollo pleno y nadie le está contando historias.
Muy a menudo sucede que el cliente no entiende completamente lo que realmente necesita. Dado que está creando un nuevo negocio para sí mismo, con procesos aún no establecidos. Por lo tanto, es muy común que terminemos tirando a la basura fragmentos enteros de código y rehaciendo la lógica de la aplicación. De esto se desprende que no es necesario cubrir absolutamente todo con pruebas. Solo tiene sentido cubrir con pruebas las funcionalidades críticas y, eso sí, con ciertas salvedades.
Hay situaciones en las que el equipo se da cuenta de que no cumpliremos con los plazos. Entonces realizamos una auditoría rápida de las tareas y se lo comunicamos al cliente de inmediato. Como salida a la situación, proponemos lanzar a tiempo la funcionalidad importante y crítica, y dejar lo demás para después del lanzamiento.
Si el cliente comienza a inventar diversas tareas de la nada, empieza a fantasear y a explicar con gestos, le pedimos que nos proporcione un diseño de la página y un flujo con la lógica que debe describir completamente el comportamiento de todo el diseño y sus elementos.
Antes de asumir cualquier tarea, debemos asegurarnos de que esta característica está incluida en los términos de nuestro contrato. Si es una nueva característica que va más allá de nuestros acuerdos iniciales, debemos estimar esta característica ((tiempo aproximado de ejecución + 30%) x 2) y comunicar al cliente que nos tomará ese tiempo, además de que la fecha límite se retrasará el tiempo de la estimación multiplicado por dos. Si podemos completar la tarea más rápido, genial, todos se beneficiarán. Si no, estamos cubiertos.

b) Lo que no aceptamos en el equipo:

Falta de compromiso, desorganización, olvidos.
„Excusas constantes“. Si no puedes completar una tarea o no sabes cómo, debes informarlo de inmediato al líder del equipo, y no esperar hasta el último momento.
Presumir o alardear de alguien que aún no ha demostrado sus capacidades y profesionalismo mediante acciones. Si lo ha demostrado, está bien, dentro de los límites de la decencia 🙂.
El engaño en cualquiera de sus manifestaciones. Si una tarea no está completada, no se debe cambiar su estado a completada y escribir en el chat del cliente que está lista. Mi computadora se rompió, el sistema falló, el perro mordió mi laptop — todo esto es inaceptable. Si ocurre una verdadera fuerza mayor, el líder del equipo debe ser informado de inmediato.
Cuando un especialista siempre está fuera de línea y es difícil contactarlo durante el horario laboral.
¡La toxicidad en el equipo no está permitida! Si alguien no está de acuerdo con algo, todos deben reunirse para discutirlo y resolverlo.

Y una serie de preguntas/tesis que a veces le hago a mi cliente para evitar malentendidos:

¿Cuáles son sus criterios de calidad?
¿Cómo determina si hay problemas en el proyecto o no?
Al ignorar todas nuestras recomendaciones y consejos sobre cambios/mejoras en el sistema, usted asume todos los riesgos.
Cualquier cambio mayor en el proyecto (por ejemplo, cualquier flujo extra) puede provocar la aparición de errores (que, por supuesto, estaremos solucionando).
No es posible entender en cuestión de minutos qué problema ha surgido en el proyecto, y mucho menos solucionarlo de inmediato.
Trabajamos según un flujo de producto específico (Tareas en Jira — Desarrollo — Pruebas — Despliegue). Por lo tanto, no podemos reaccionar a toda la avalancha de solicitudes y quejas en el chat.
Los programadores son programadores, no testers profesionales, y no pueden garantizar la calidad adecuada en la prueba del proyecto.
La responsabilidad de las pruebas finales y la aceptación de tareas en producción recae completamente en ustedes.
Si ya hemos comenzado a trabajar en una tarea, no podemos cambiar de inmediato a otras hasta que terminemos la actual (de lo contrario, esto provoca aún más errores y aumenta el tiempo de desarrollo).
El equipo ha reducido su número (debido a vacaciones o enfermedades), pero el trabajo ha aumentado y físicamente no podremos responder a todo lo que ustedes desean.
Hacer un despliegue en producción sin tareas probadas en desarrollo son solo sus riesgos, no los de los desarrolladores.
Cuando plantean tareas poco claras, sin un flujo correcto y sin maquetas de diseño, esto requiere de nosotros un esfuerzo y plazos mucho mayores, ya que tenemos que realizar un trabajo adicional en lugar de ustedes.
Cualquier tarea relacionada con errores, sin una descripción detallada de cómo ocurren y sin capturas de pantalla, no nos permite entender qué salió mal y cómo simular ese error.
El proyecto requiere mejoras y ajustes constantes para aumentar su rendimiento y seguridad. Por lo tanto, el equipo dedica parte de su tiempo a estas mejoras.
Dado que a veces tenemos horas extra (fixes urgentes), debemos compensarlas en otros días.

Por lo general, el cliente entiende de inmediato que el desarrollo de software no es tan simple y que solo el deseo claramente no es suficiente.

En resumen, eso es todo. Dejo entre líneas muchas negociaciones y la configuración inicial de todos los procesos, pero al final todo se organizó. Puedo decir que este proceso se ha convertido para nosotros en una 'Bala de Plata'. Las nuevas personas que se unieron al proyecto pudieron comenzar a trabajar desde el primer día, ya que todos los procesos están documentados y la documentación y arquitectura en forma de diagramas ya proporcionaba una idea de en qué estamos trabajando.

P.D. Quiero aclarar que no hay un gerente de proyecto de nuestro lado. Está del lado del cliente. No es precisamente técnico. El proyecto es europeo. Toda la comunicación es solo en inglés.

Les deseo a todos éxito en sus proyectos. No se quemen y traten de mejorar sus procesos.

El código fuente está en mi blog.

Fuente: habr.com