Lo más importante es que los programadores no entienden cómo comunicarse con el cliente y entre ellos. Cómo construir un proceso de desarrollo de productos de calidad continuo. Cómo planificar tu jornada laboral y tus sprints.
Y todo esto, en última instancia, se traduce en plazos interrumpidos, horas extraordinarias, enfrentamientos constantes sobre quién tiene la culpa y la insatisfacción del cliente, dónde y cómo se mueve todo. Muy a menudo, todo esto conduce a un cambio en los programadores, o incluso en equipos completos. Pérdida de un cliente, deterioro de la reputación, etc.
En un momento, acabo de embarcarme en un proyecto así, donde estaban todos estos encantos.
Nadie quería asumir la responsabilidad del proyecto (un gran mercado de servicios), el volumen de negocios era terrible, el cliente simplemente se rompió y golpeó. El director ejecutivo se me acercó una vez y me dijo que tienes la experiencia necesaria, así que aquí 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 desarrolle como mejor le parezca. Como resultado, me convertí en líder de equipo en el proyecto y todo cayó 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. No fue fácil de implementar. Pero en 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í el máximo de responsabilidades, quitando la rutina desagradable del equipo.
Ya ha pasado año y medio y el proyecto se desarrolla sin horas extras, sin "carreras de ratas" y todo tipo de estrés. Alguien del antiguo equipo no quiso trabajar así y se fue, alguien, por el contrario, estaba muy interesado en que aparecieran reglas transparentes. Pero como resultado, todos los que están en el equipo están muy motivados y conocen el gran proyecto en su totalidad, tanto con el front-end como con el back-end. Incluyendo tanto la base de código como toda la lógica empresarial. Incluso ha llegado al punto de que no somos sólo "remeros", sino que también hemos ideado muchos procesos de negocio y nuevas funciones que la empresa encontró de su agrado.
Gracias a este enfoque de nuestra parte, el cliente decidió solicitar otro mercado de nuestra empresa, lo cual es una buena noticia.
Dado que funciona en mi proyecto, tal vez también pueda ayudar a alguien. Entonces, el proceso en sí que nos ayudó a salvar el proyecto:
Proceso de trabajo en equipo en el proyecto "Mi proyecto favorito"
a) Proceso de equipo interno (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 muchos pequeños intercambios
- El equipo trabaja en funciones como una sola tarea. Primero, hacemos todos juntos una función, la enviamos para probar y luego tomamos la siguiente.
- Cada tarea está marcada, para el backend o frontend.
- Hay tipos de colmillos e insectos. Debe indicarlos correctamente.
- Una vez completada la tarea, se transfiere al estado de revisión de código (esto crea una solicitud de extracción para su colega)
- Quien haya completado la tarea rastrea inmediatamente su tiempo para esta tarea.
- , , , , , .
- , , ( ), , - . —
- ,
- ,
- , , . ,
- : To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- , . , , .
- . , .
- .
- , .
- , , , , .
- , , , , . ( ) . , /.
- ( 12.00)
- , , , . . , . , , .
- , . .
- , , , , .
- . .
- . , , . . , , , .
- , . . .
- , , . .
- Todos los días, el desarrollador debe escribir en el chat del cliente sobre las tareas en las que trabajó ayer y las tareas en las que trabajará hoy.
- El flujo de trabajo se basa en Scrum. Todo se divide en sprints. Cada sprint dura dos semanas.
- Los sprints crean, completan y cierran un líder de equipo.
- Si el proyecto tiene plazos estrictos, intentamos estimar aproximadamente todas las tareas. Y recopilamos un sprint de ellos. Si el cliente intenta agregar más tareas al sprint, establecemos prioridades y transferimos algunas otras tareas al siguiente sprint.
b) El proceso de trabajar con el cliente
- Cada desarrollador puede y debe comunicarse con el cliente.
- No se debe permitir que el cliente imponga sus propias reglas del juego. Es necesario de manera educada y amigable dejar claro al cliente que somos especialistas en nuestro campo, y solo debemos construir procesos de trabajo e involucrar al cliente en ellos
- , , - , - (). . , , , .. , , , , , , .
- /-/ .. /, .
- . , , -, /.
- , . , , . .
- , . . , .
- , , . , . , . , . .
- , , . , . , .
- Si el cliente comienza a pensar en diferentes tareas, 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 sus elementos.
- Antes de emprender cualquier tarea, debemos asegurarnos de que esta característica esté incluida 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 evaluar esta característica ((tiempo de entrega estimado + 30%) x 2) e indicarle al cliente que nos tomará mucho tiempo, además de que el plazo se cambia por dos veces la estimación. Hagamos la tarea más rápida; genial, todos solo se beneficiarán de esto. Si no es así, estamos asegurados.
c) Lo que no aceptamos en el equipo:
- Opcionalidad, falta de montaje, olvido
- „ “. , , , .
- , . , , :)
- . , , . , , — . -, .
- .
- ! - - , .
Y una serie de otras preguntas / tesis que a veces le pido a mi cliente para eliminar todos los malentendidos:
- ¿Cuáles son sus criterios de calidad?
- ¿Cómo se determina si un proyecto tiene un problema o no?
- Violando todas nuestras recomendaciones y consejos sobre cómo cambiar / mejorar el sistema, todos los riesgos son asumidos únicamente por usted
- Cualquier cambio importante en el proyecto (por ejemplo, todo tipo de flujos adicionales) conducirá a la posible aparición de errores (que, por supuesto, arreglaremos)
- Es imposible por un par de minutos entender qué tipo de problema ocurrió en el proyecto, y más aún solucionarlo de inmediato.
- Trabajamos en un producto de flujo específico (Tareas en Fat - 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 probadores profesionales, y no pueden garantizar la calidad adecuada de las pruebas del proyecto.
- , , ( )
- ( ), ,
- — ,
- , , , ,
- , , , ,
- .
- , ( ),
Como regla general, el cliente se da cuenta de inmediato de que no todo es tan simple en el desarrollo de software y que el deseo por sí solo no es suficiente.
En general, eso es todo. Dejo detrás de escena 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 para nosotros en una especie de "bala de plata". Las nuevas personas que se acercaron al proyecto pudieron acostumbrarse inmediatamente a trabajar desde el primer día, ya que se describen todos los procesos, y la documentación y arquitectura en forma de diagramas dio de inmediato una idea de lo que todos estábamos haciendo aquí.
PD: Me gustaría aclarar que no hay un director de proyecto de nuestro lado. Está del lado del cliente. No es un técnico en absoluto. El proyecto es europeo. Toda la comunicación es solo en inglés.
Buena suerte a todos en proyectos. No se agote y trate de mejorar sus procesos.
La fuente está en mi blog .