Hola amigos. Muy a menudo, especialmente en la subcontratación, veo la misma imagen. La falta de un flujo de trabajo claro en los equipos en varios 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 un producto de calidad. Cómo planificar tu jornada laboral y sprints.
Y todo esto finalmente da como resultado plazos incumplidos, horas extra, enfrentamientos constantes sobre quién tiene la culpa e insatisfacción del cliente: dónde y cómo se mueve todo. Muy a menudo, todo esto lleva a un cambio de programadores, e incluso de equipos completos. Pérdida de un cliente, deterioro de la reputación, etc.
En un momento, me metí en un proyecto así, donde había todas estas delicias.
Nadie quería asumir la responsabilidad del proyecto (un gran mercado de servicios), el volumen de negocios era terrible, el cliente simplemente se desgarró y tiró. El CEO de alguna manera se me acercó y me dijo que tienes la experiencia necesaria, así que tienes las cartas en tus manos. Toma el proyecto por ti mismo. Si la cagas, cerraremos el proyecto y echaremos a todos. Resultará, será genial, luego diríjalo y desarróllelo como mejor le parezca. Como resultado, me convertí en un líder de equipo en el proyecto y todo recayó sobre mis hombros.
Lo primero que hice fue diseñar un flujo de trabajo desde cero que coincidiera con mi visión en ese momento y escribí una descripción del trabajo para el equipo. Implementarlo no fue fácil. Pero en algún lugar dentro de un mes todo se calmó, los desarrolladores y el cliente se acostumbraron, y todo transcurrió tranquila y cómodamente. Para mostrarle al equipo que esto no es solo una tormenta en un vaso, sino una salida real de la situación, asumí la máxima cantidad de responsabilidades, eliminando la rutina desagradable del equipo.
Ya ha pasado un año y medio, y el proyecto se está desarrollando sin horas extras, sin "carreras de ratas" y todo tipo de estrés. Alguien en el antiguo equipo no quería trabajar así y se fue, por el contrario, alguien realmente se metió en eso para que aparecieran reglas transparentes. Pero como resultado, todos los miembros del equipo están muy motivados y conocen el gran proyecto en su totalidad, tanto en el front-end como en el back-end. Incluyendo tanto el código base como toda la lógica empresarial. Incluso ha llegado al punto de que no somos solo “remeros”, sino que nosotros mismos creamos muchos procesos comerciales y nuevas características que le gustan al negocio.
Gracias a este enfoque de nuestra parte, el cliente decidió solicitar otro mercado de nuestra empresa, lo cual es una buena noticia.
Dado que esto funciona en mi proyecto, tal vez también ayude a alguien. Entonces, el proceso en sí, que nos ayudó a salvar el proyecto:
El proceso de trabajo en equipo en el proyecto "Mi proyecto favorito".
a) Dentro de un proceso de equipo (entre desarrolladores)
- Todas las tareas se crean en el sistema Jira
- Cada tarea debe describirse tanto como sea posible y realizar estrictamente una acción.
- Cualquier característica, si es lo suficientemente compleja, se divide en muchas tareas pequeñas
- El equipo trabaja en funciones como una sola tarea. Primero, hacemos una función juntos, la damos para que la prueben y luego tomamos la siguiente.
- Cada tarea está etiquetada para backend o frontend
- Hay tipos de tareas y errores. Necesitas especificarlos correctamente.
- Una vez completada la tarea, se transfiere al estado de revisión de código (se crea una solicitud de extracción para su colega)
- El que completó la tarea realiza un seguimiento inmediato de su tiempo para esta tarea
- Después de verificar el código, se aprueba el PR y después de eso, el que realizó esta tarea lo fusiona de forma independiente en la rama maestra, luego de lo cual cambia su estado a listo para su implementación en el servidor de desarrollo.
- Todas las tareas listas para implementarse en el servidor de desarrollo las implementa el líder del equipo (su área de responsabilidad), a veces un miembro del equipo, si algo es urgente. Después de la implementación, todas las tareas desde listo para implementación hasta desarrollo se transfieren al estado: listo para probar en desarrollo
- Todas las tareas son probadas por el cliente.
- Cuando el cliente ha probado la tarea en el desarrollador, la transfiere al estado listo para implementarse en producción.
- Para la implementación en producción, tenemos una rama separada donde fusionamos el maestro justo antes de la implementación.
- Si durante la prueba el cliente encuentra errores, entonces devuelve la tarea para revisión, configurando su estado devuelto para revisión. Así es como separamos las tareas nuevas de las que no han sido probadas.
- Como resultado, todas las tareas van desde la creación hasta su finalización: Tareas pendientes → En desarrollo → Revisión de código → Listo para implementar en desarrollo → Control de calidad en desarrollo → (Volver a desarrollo) → Listo para implementar en producción → Control de calidad en producción → Listo
- Cada desarrollador prueba su código de forma independiente, incluso como usuario del sitio. No está permitido fusionar una rama con la principal, a menos que se sepa con certeza que el código funciona.
- Cada tarea tiene prioridades. Las prioridades las establece el cliente o el líder del equipo.
- Los desarrolladores hacen primero las tareas prioritarias.
- Los desarrolladores pueden asignarse tareas entre sí si se encontraron diferentes errores en el sistema o si una tarea consiste en el trabajo de varios especialistas.
- Todas las tareas que crea el cliente se envían al líder del equipo, quien las evalúa y le pide al cliente que las finalice o las asigna a uno de los miembros del equipo.
- Todas las tareas que están listas para implementarse en desarrollo o producción también llegan al líder del equipo, quien determina de forma independiente cuándo y cómo implementarlas. Después de cada implementación, el líder del equipo (o miembro del equipo) debe notificar al cliente sobre esto. Y también cambie los estados de las tareas para que estén listas para probar en dev/prod.
- Todos los días a la misma hora (la tenemos a las 12.00) hacemos un mitin entre todos los miembros del equipo
- Todos en el mitin informan, incluido el líder del equipo, lo que hizo ayer, lo que planea hacer hoy. Qué no funciona y por qué. Así, todo el equipo sabe quién está haciendo qué y en qué etapa se encuentra el proyecto. Esto nos da la oportunidad de predecir y ajustar, si es necesario, nuestras estimaciones y plazos.
- En la reunión, el líder del equipo también anuncia todos los cambios en el proyecto y el nivel de errores actuales que no fueron encontrados por el cliente. Todos los errores se clasifican y asignan a cada miembro del equipo para resolverlos.
- En el mitin, el líder del equipo asigna tareas para cada uno, teniendo en cuenta la carga de trabajo actual de los desarrolladores, su nivel de formación profesional y también teniendo en cuenta la proximidad de una tarea en particular a lo que el desarrollador está haciendo actualmente.
- En la reunión, el líder del equipo desarrolla una estrategia general para la arquitectura y la lógica empresarial. Después de eso, todo el equipo discute esto y decide si hacer ajustes o adoptar esta estrategia.
- Cada desarrollador escribe código y crea algoritmos de forma independiente dentro de una única arquitectura y lógica empresarial. Todos pueden expresar su visión de la implementación, pero nadie está obligando a nadie a hacerlo de esta manera y no de otra manera. Toda decisión está justificada. Si hay una solución mejor, pero ahora no hay tiempo para ello, entonces se crea una tarea en fat, para la futura refactorización de una determinada parte del código.
- Cuando un desarrollador asume una tarea, la mueve al estado de desarrollo. Toda la comunicación sobre la aclaración de la tarea con el cliente recae sobre los hombros del desarrollador. Las preguntas técnicas se pueden hacer al líder del equipo oa los colegas.
- Si el desarrollador no comprende la esencia de la tarea y el cliente no pudo explicarla con sensatez, entonces continúa con la siguiente tarea. Y el líder del equipo toma el actual y lo discute con el cliente.
- Todos los días, el desarrollador debe escribir en el chat del cliente sobre en qué tareas trabajó ayer y en qué tareas trabajará hoy.
- El flujo de trabajo se basa en Scrum. Todo se divide en sprints. Cada sprint dura dos semanas.
- Los Sprints son creados, completados y cerrados por el líder del equipo.
- Si el proyecto tiene plazos estrictos, tratamos de estimar aproximadamente todas las tareas. Y recogemos de ellos un sprint. Si el cliente intenta agregar más tareas al sprint, establecemos prioridades y transferimos algunas otras tareas al siguiente sprint.
b) El proceso de trabajo con el cliente
- Cada desarrollador puede y debe comunicarse con el cliente
- No se puede permitir que el cliente imponga sus propias reglas de juego. Es necesario de manera educada y amable dejarle claro al cliente que somos especialistas en nuestro campo, y solo nosotros debemos construir procesos de trabajo e involucrar al cliente en ellos
- Es necesario, idealmente, antes de proceder con la implementación de cualquier funcionalidad, crear un diagrama de flujo de todo el proceso lógico para una característica (flujo de trabajo). Y enviarlo al cliente para su confirmación. Esto se aplica solo a funciones complejas y no obvias, por ejemplo, un sistema de pago, un sistema de notificación, etc. Esto le permitirá comprender con mayor precisión qué necesita exactamente el cliente, guardar la documentación para la función y también asegurarse contra el hecho de que el cliente puede decir en el futuro que no hicimos lo que pidió.
- Todos los diagramas/diagramas de flujo/lógica, etc. guardamos en Confluence/Fat, donde le pedimos al cliente en los comentarios que confirme la corrección de la implementación futura.
- Intentamos no sobrecargar al cliente con detalles técnicos. Si necesitamos entender cómo quiere el cliente, dibujamos algoritmos primitivos en forma de diagrama de flujo que el cliente puede entender y arreglar/modificar todo por sí mismo.
- Si el cliente encuentra un error en el proyecto, le pedimos que lo describa con gran detalle en Fat. En qué circunstancias ocurrió, cuándo, qué secuencia de acciones llevó a cabo el cliente durante la prueba. Adjunte capturas de pantalla.
- Intentamos todos los días, como máximo cada dos días, implementar en el servidor de desarrollo. Luego, el cliente comienza a probar la funcionalidad y el proyecto no está inactivo. Al mismo tiempo, esto es un marcador para el cliente de que el proyecto está en pleno desarrollo y nadie le está contando cuentos de hadas.
- A menudo sucede que el cliente no comprende completamente lo que necesita. Ya que crea un nuevo negocio para sí mismo, con procesos que aún no han sido depurados. Por lo tanto, un caso muy común es cuando tiramos piezas enteras de código a la basura y remodelamos la lógica de la aplicación. De esto se deduce que no es necesario cubrir absolutamente todo con pruebas. Tiene sentido cubrir solo la funcionalidad crítica con pruebas y luego con reservas.
- Hay situaciones en las que el equipo se da cuenta de que no nos ajustamos a los plazos. Luego realizamos una auditoría rápida de las tareas e informamos inmediatamente al cliente al respecto. Como una forma de salir de la situación, sugerimos lanzar la funcionalidad importante y crítica a tiempo y dejar el resto para después del lanzamiento.
- Si al cliente se le ocurren diferentes tareas de la cabeza, comienza a fantasear y a explicar con los dedos, entonces le pedimos que nos proporcione un diseño de página y un flujo con lógica que describa completamente el comportamiento de todo el diseño y su elementos.
- Antes de emprender cualquier tarea, debemos asegurarnos de que esta función se haya incluido en los términos de nuestro acuerdo/contrato. Si esta es una característica nueva que va más allá de nuestros acuerdos iniciales, entonces definitivamente debemos estimar esta característica ((plazo de entrega aproximado + 30%) x 2) e indicarle al cliente que nos llevará tanto tiempo completarla, además el plazo se desplaza por el tiempo estimado multiplicado por dos. Hagamos la tarea más rápida. Genial, todos se beneficiarán de esto. Si no, entonces estamos asegurados.
c) Lo que no aceptamos en el equipo:
- Inconsistencia, incoherencia, olvido
- "Alimentación en el desayuno". Si no puede completar la tarea, no sabe cómo, entonces debe notificarlo de inmediato al líder del equipo y no esperar hasta el final.
- Brovadas y alardes de un hombre que aún no ha demostrado con hechos sus capacidades y profesionalidad. Si se prueba, entonces es posible, dentro de los límites de la decencia 🙂
- El fraude en todas sus manifestaciones. Si la tarea no se completa, entonces no debe cambiar su estado a completada y escribir en el chat del cliente que está lista. La computadora falló, el sistema falló, el perro mordió la computadora portátil, todo esto es inaceptable. Si ocurre una fuerza mayor real, se debe notificar inmediatamente al líder del equipo.
- Cuando un especialista está desconectado todo el tiempo y es difícil comunicarse con él durante las horas de trabajo.
- ¡La toxicidad en el equipo no está permitida! Si alguien no está de acuerdo con algo, todos se reúnen para un mitin, discuten y deciden.
Y una serie de preguntas/tesis que a veces le hago a mi cliente para quitar todo malentendido:
- ¿Cuáles son sus criterios de calidad?
- ¿Cómo se determina si un proyecto tiene problemas o no?
- Violar todas nuestras recomendaciones y consejos sobre el cambio/mejora del sistema, solo usted corre con todos los riesgos
- Cualquier cambio importante en el proyecto (por ejemplo, todo tipo de flujo adicional) dará lugar a la posible aparición de errores (que, por supuesto, corregiremos)
- Es imposible entender en un par de minutos qué tipo de problema ocurrió en el proyecto, y más aún solucionarlo allí mismo.
- Trabajamos en un flujo de producto específico (Tareas en Zhira - Desarrollo - Pruebas - Implementación). Esto significa que no podemos responder a todo el flujo de solicitudes y quejas en el chat.
- Los programadores son solo programadores, no evaluadores profesionales, y no pueden garantizar la calidad adecuada de las pruebas del proyecto.
- La responsabilidad de la prueba final y la aceptación de las tareas en la venta recae completamente en usted.
- Si ya hemos asumido una tarea, entonces no podemos cambiar inmediatamente a otras hasta que completemos la actual (de lo contrario, esto genera aún más errores y un aumento en el tiempo de desarrollo)
- Hay menos gente en el equipo (por vacaciones o enfermedad), y hay más trabajo y físicamente no tendremos tiempo de responder a todo lo que quieras
- Pedirle que implemente en producción sin tareas probadas en desarrollo es solo su riesgo, no el desarrollador
- Cuando establece tareas difusas, sin flujo correcto, sin diseños de diseño, esto requiere mucho más esfuerzo y tiempo de implementación de nuestra parte, ya que tenemos que hacer una cantidad adicional de trabajo en lugar de usted.
- Cualquier tarea sobre errores, sin una descripción detallada de su ocurrencia y capturas de pantalla, no nos da la oportunidad de comprender qué salió mal y cómo podemos emitir este error.
- El proyecto requiere refinamiento y mejoras constantes para mejorar el rendimiento y la seguridad. Por lo tanto, el equipo dedica parte de su tiempo a estas mejoras.
- Debido a que tenemos horas extras (arreglos urgentes), debemos compensarlas en otros días
Como regla general, el cliente comprende de inmediato que no todo es tan simple en el desarrollo de software, y que el deseo por sí solo claramente no es suficiente.
En general, esto es todo. Detrás de escena, dejo muchas negociaciones y la depuración inicial de todos los procesos, pero como resultado, todo salió bien. Puedo decir que este proceso se ha convertido en una especie de “Silver Bullet” para nosotros. Las nuevas personas que se acercaron al proyecto ya pudieron aprovecharse de inmediato para trabajar desde el primer día, ya que todos los procesos están descritos, y la documentación y la arquitectura en forma de diagramas dieron una idea inmediata de lo que todos estamos haciendo. aquí.
PD: Quiero aclarar que no hay un gerente de proyecto de nuestro lado. Está del lado del cliente. No es un aficionado a la tecnología en absoluto. proyecto europeo. Toda la comunicación es solo en inglés.
Buena suerte a todos en sus proyectos. No te quemes y trata de mejorar tus procesos.
fuente en mi .
Fuente: habr.com