Hola a todos! Mi nombre es Roman, y hoy compartiré mi experiencia en un equipo de diseño distribuido. Le contaré sobre los procesos que hemos construido y cómo un equipo de cuatro personas cubre las necesidades de diseño de una unidad completa que consta de más de 30 productos y más de 20 equipos de productos.
También hablaré sobre cómo:
- Monitorear el trabajo de un equipo distribuido;
- Para lograr la consistencia del código en diferentes proyectos;
- Distribuir tareas de manera justa;
- Mantener un trabajo de alta calidad;
- No acumule tareas sin terminar;
- Para evitar el agotamiento y desarrollar empleados.
En lugar de unirse
Creo que vale la pena decir de inmediato por qué tenemos diseñadores de diseño dedicados en Tinkoff Business. Después de todo, existe la opinión de que cualquier desarrollador web debería poder recuperarse bien.
En muchas empresas, los desarrolladores se están componiendo a sí mismos. Pero, en primer lugar, no a todos los desarrolladores les gusta escribir y hacerlo bastante bien. En segundo lugar, para el desarrollador, el diseño dista mucho de ser siempre de alta prioridad, el foco se desplaza al código. Y cuando no hay foco, la calidad y la actitud hacia los detalles se resiente.
Por lo tanto, tenemos diseñadores de diseño dedicados, pero no están vinculados a un proyecto específico, porque no todos los proyectos pueden proporcionar tareas de diseño todo el tiempo.
¿Cómo estuvo antes?
Anteriormente, el proceso era bastante simple.
En mi unidad había cuatro máquinas de escribir y una sala de chat especial donde todas las personas interesadas lanzaban rompecabezas para el diseño, y los clasificamos lentamente. En general, el sistema funcionaba, pero había, por supuesto, sus inconvenientes.
Por ejemplo, se podría lanzar una tarea, pero ninguna de las máquinas de escribir respondió al mensaje. El autor de la tarea comenzó a escribir en la sala de chat nuevamente; dicen: ¿quién se encargará de la tarea? Además, no había planificación ni comprensión de quién estaba haciendo qué, cuándo fue liberado y en qué proyectos estaba inmerso.
Para que los mensajes de los autores no cuelguen sin respuesta, incluso cuando todos están ocupados, comencé a responder todos los mensajes y me pregunto quién podrá tomar esta o aquella tarea cuando. Al mismo tiempo, fijó quién participó en qué proyectos, quién sabe qué tareas mejor. Duró aproximadamente un mes, el sistema comenzó a funcionar mejor, una reacción instantánea a las tareas de los clientes completamente satisfechos.
Es cierto que este enfoque todavía no proporcionó respuestas a muchas preguntas. Por ejemplo, fue difícil predecir la carga, no hubo unidad en los enfoques, no hubo ningún tipo de planificación, cada uno fue por su cuenta y resolvió su problema de forma independiente. Además del chat, no había un único punto de entrada en el diseño, no había nadie para discutir con el nuevo proyecto, para evaluar el diseño, porque no está claro quién trabajará en él y cuándo.
Y en una de las reuniones con el líder, decidimos organizar un nuevo equipo de diseño de todos los diseñadores de diseño, con quienes compartimos tareas para construir procesos y proporcionar diseño para todos los proyectos.
Esto es lo que salió de eso.
Construyendo un equipo
Dado: cuatro máquinas de escribir de diferentes ciudades e incluso países. Más de 30 proyectos en la misma pila, pero debido a la naturaleza de los proyectos, a menudo con diferentes arquitecturas, diferentes versiones del diseño y componentes, diferentes equipos de desarrollo que a veces practican sus enfoques.
En primer lugar, creamos un chat privado solo con diseñadores de diseño. Esto le permite resolver rápidamente los problemas del equipo cuando no necesita mucha urgencia, y siempre puede hacer una pregunta, pedir ayuda a sus colegas o revisar su trabajo.
Control
¿Cómo controlar el trabajo de los empleados, si no se sientan a continuación?
En general, existen diferentes tipos de control según el nivel de habilidades y el nivel de confianza en el empleado. No me detendré en ellos en detalle, tú mismo aprenderás todo.
Tuve suerte: todos los muchachos eran igualmente buenos y, por defecto, tenían un 100% de confianza. Por lo tanto, el sistema era necesario no tanto para el control como para sincronizar acciones y comprender el panorama general. Para hacer esto, presentamos llamadas matutinas diarias de hasta 10 minutos de duración, durante las cuales todos dijeron lo que hicieron ayer y lo que iban a hacer hoy.
Estas frases solo sirven para la sincronización por tareas y proyectos, no implican el análisis de problemas, dificultades, holivares u otros problemas; todo esto, si es necesario, se presenta en frases o discusiones separadas en el chat. Es muy importante controlar esto y detener todos los intentos de transferir la llamada a una conversación de una hora sobre el clima.
Consistencia de código
Estamos recibiendo tareas de proyectos completamente diferentes con código y calidad diferentes, por lo que fue necesario lograr la entrega de un diseño único de alto nivel para todos los proyectos, independientemente de los datos de origen. Para hacer esto, a través de discusiones generales y votaciones, desarrollamos reglas y pautas para el diseño, que cumplimos estrictamente dentro de nuestro equipo, y también recomendamos para el uso de todos los demás. Incluso el orden de las propiedades está registrado.
Sí, si escribe una propiedad CSS de color por encima del ancho, recibirá un comentario y su PR no se atenuará. Esto puede parecer extraño, porque en la mayoría de los casos el orden de las propiedades no afectará el resultado final, pero recordamos: muchos proyectos, un solo nivel alto de calidad. Por lo tanto, debemos tener el orden máximo. En todas partes Incluso el orden está en el orden de las propiedades.
Debo decir de inmediato que fue una buena idea arreglar el pedido. Le permite escribir CSS más estructurado y reflexivo. Por ejemplo, hay una regla para agrupar propiedades. Si escribe display: flex, todas las propiedades relacionadas (elementos de alineación, contenido de justificación) deben describirse una al lado de la otra para facilitar la comprensión de lo que está sucediendo.
Ahora, gradualmente, llegamos a la conclusión de que estamos poniendo todas las reglas en las listas para reducir el número de comentarios no críticos sobre la revisión, así como para permitir que los revisores se centren en cosas realmente importantes, por ejemplo, la arquitectura.
Por cierto, nuestras configuraciones de linter son de dominio público, tal vez te sean útiles. Descargar configuraciones .
Distribución de tareas
Entonces, la comunicación está establecida, las reglas del juego son fijas, pero ¿cómo jugar? ¿Por qué Vanya solo realiza tareas simples y Pete se complica, e incluso de un proyecto en el que nadie ha estado involucrado durante mucho tiempo?
De hecho, hay proyectos que:
- constantemente necesita diseño;
- constantemente necesita diseño y todo cambia constantemente;
- que fueron escritos hace mucho tiempo y comienzan a desarrollarse nuevamente.
Esto plantea otra pregunta: ¿cómo distribuir las tareas de manera equitativa?
¿Es necesaria la justicia?
Puede usar el recurso administrativo y decir rígidamente: "Petya, haces estas tareas, a nadie le gustan, pero por ahora tomaremos estas interesantes con Vanya".
Esto, por supuesto, se puede hacer, y por algún tiempo incluso funcionará. Pero hay varias desventajas de esto:
- A Petya le desagrada un poco, lo que significa que está menos involucrado en el trabajo en equipo;
- Petya puede algún día quemarse y dejar de fumar, sin siquiera avisar con anticipación, y tendremos un agujero en nuestros recursos;
- Petya tenía la mayor experiencia en proyectos complejos, y ahora cada uno de los restantes necesitará mucho tiempo para comprender los proyectos de Petit.
Parece que no deberías hacerlo. Pero que hacer?
Primero debe seleccionar varios grupos por los cuales puede dividir todas las tareas entrantes.
Se ve algo así para nosotros.
Los proyectos A, B y C generan constantemente cientos de tareas, y están listos para proporcionarnos trabajo para el año próximo. Y hay otros proyectos que vienen con una o dos tareas cada pocas semanas. Debido a las limitaciones de recursos, acordamos que una persona está trabajando constantemente en los proyectos A, B y C, y la cuarta asume todas las tareas de otros proyectos. Parece que todos los recursos están distribuidos, puedes trabajar.
Pero nuevamente, nos encontramos con un problema cuando una persona que trabaja constantemente en el proyecto A no tiene idea de lo que está sucediendo en el proyecto C.
Para resolver este problema, introdujimos el servicio de dos semanas.
Desde el lunes y las próximas dos semanas, Petya trabaja en el proyecto A, luego pasa al proyecto B, luego a C, por lo que cambia regularmente sus actividades.
Se parece a esto:
¿Qué nos da esto? En primer lugar, todos los chicos están igualmente bien versados en todos los proyectos y pueden reemplazarse fácilmente. En segundo lugar, hay proyectos más interesantes y este es su deber favorito, que además motiva, da fuerza y no permite agotarse del mismo trabajo.
Además, para eliminar la regulación manual, acordamos que el proyecto mismo establece la prioridad para el trabajo. Es decir, destacamos a la persona y él realiza las tareas que le da el proyecto. Esto es muy conveniente: no necesitamos priorizar al equipo y pensar en el pedido. Esto lo hace el proyecto, su equipo y el gerente de producto.
Es cierto, puedes encontrar el problema. Una persona comprende las tareas de todos los proyectos que surgen de manera irregular: el que no trabaja en ninguno de los principales proyectos en servicio actual.
Parece que puede ser bombardeado con tareas, y los clientes serán retirados de todos lados y, como resultado, no se les permitirá trabajar. Para eliminar este riesgo, tenemos una página especial con tales tareas. Cuando aparece la siguiente tarea, se agrega al final de la lista.
Aquí hay un ejemplo de tal página:
Todas las tareas y sus estados son visibles en él. En cualquier momento, el cliente puede seguir el progreso y comprender cuándo aproximadamente su tarea irá a trabajar.
Por supuesto, todos tienen las tareas más urgentes y todos quieren salir de turno. Especialmente para tales situaciones, se inventó el siguiente mecanismo: si el cliente está "en llamas" y quiere que su tarea funcione más rápido, debe estar de acuerdo con alguien que se encuentre en la lista que se encuentra sobre él. Si está listo para ceder su lugar, no hay problema, intercambie las tareas en la lista.
Puede pensar que este es un punto bastante débil y debería llenarnos, pero durante seis meses ha estado funcionando.
Por supuesto, las situaciones pueden ser diferentes, pero nadie ha cancelado la regulación manual y los recursos administrativos;)
Control de calidad
Todos cometen errores. Todavía no he visto un solo desarrollador o diseñador de diseño que nunca se haya equivocado. ¿Cómo se puede minimizar la cantidad de tales errores?
Para hacer esto, aplicamos activamente la práctica de las revisiones de diseño. Que incluye?
Cuando se completa el trabajo en el diseño, el diseñador de diseño llama al diseñador y le muestra el resultado del trabajo en su pantalla. Esto le permite resolver varios problemas a la vez:
- El diseñador puede ver lo más rápido posible tanto el error del diseñador de diseño como su propio error si una imprecisión se infiltró en el diseño.
- Resuelva rápidamente problemas tales como "¿cómo debe mostrarse cuando se desplaza o se enfoca?". A menos, por supuesto, que estas condiciones no se reflejen en el diseño.
- Y una gran ventaja adicional: el diseñador puede ver que el resultado no se ve óptimo y hacer cambios en línea.
Al comienzo de la implementación de esta práctica, temíamos que el trabajo se ralentizara porque:
- el diseñador no está en su lugar;
- el diseñador está enfermo y nadie más lo sabe;
- Durante la revisión, el diseñador decidió cambiar completamente el diseño.
Pero en la práctica, este enfoque ha funcionado bien y lo hemos implementado en la mayoría de los proyectos.
Revisar
Bombeamos bien a nuestro equipo de diseño, ¡puedes ir a trabajar! Pero no, hay una cosa más. Hemos adoptado la práctica de la revisión cruzada.
Esto significa que cualquiera puede revisar sus relaciones públicas y dejar comentarios sobre ellas. Solo, para ser honesto, a muchos desarrolladores no les gusta profundizar en la revisión del diseño y están listos para entregar la actualización "sin mirar", si solo el diseño cayera lo antes posible y pudieran escribir más lógica.
Para evitar esto, tenemos una regla: cada diseñador de diseño debe agregar todos los diseñadores de diseño a todas sus solicitudes de grupo.
Y las relaciones públicas no pueden congelarse si no ha recibido al menos un upruv de otra máquina de escribir. No está mal, pero parece que existe el riesgo de atascos de tráfico en forma de una gran cantidad de relaciones públicas, porque los empleados pueden ver el código de sus colegas de manera inoportuna, lo que ralentizará el trabajo.
Para evitar esto, tenemos un recordatorio sobre la necesidad de realizar una revisión de nuestros colegas dos veces al día, a las 10:00 y a las 15:00. Y cuando entras en el escondite, ves cuántos RP están esperando tu análisis.
Intentamos mantener esta cifra al mínimo. Para esto, tenemos otra regla de buena revisión. Si ha examinado el RP hasta el final, no tiene conflictos y no tiene el estado "en el trabajo", significa que debe tener una reacción: "arriba" o "para revisión". Si dejó comentarios, pero no indicó su posición, significa que no ha visto completamente las relaciones públicas.
Además, existe una responsabilidad personal adicional para sus solicitudes de fondos. ¿Qué significa esto?
Hiciste el diseño, todo está de acuerdo con el diseño, todo es hermoso, pero no hay funcionalidad. Y es imposible poner algo así en la comida. Por lo tanto, no puede congelarse en el desarrollo. Y tienes relaciones públicas abiertas, hay aruvs y parece que has hecho tu trabajo. Además, el desarrollador se acerca a usted y le dice: "Esperemos un par de días, cargaré la lógica directamente en su sucursal e inmediatamente trabajaré en la función y es liberable". ¡Pero no! Entonces no funciona. Y no debería.
El trabajo no se considera terminado hasta que su PR con diseño no se apaga. ¿Qué hacer en tal situación? Sí, es muy simple: el desarrollador crea su propia rama, donde planea escribir lógica, e imitamos el diseño en su rama. Ganancia
Cada tipografía monitorea independientemente sus PR-s y se ocupa de tales situaciones: cuando no hay dónde congelar, las compilaciones no se recopilan, la empresa decidió posponer la fecha de lanzamiento, etc. Su trabajo no se ha completado hasta que PR está muerto.
De vez en cuando organizamos una encuesta sobre llamadas telefónicas: quién tiene cuántos RP abiertos y cuántos RP deben revisarse. Los números son consistentemente menores a 10, nos esforzamos por llegar a ser menores a 5. Tales encuestas confirman que los recordatorios automáticos en el chat aún funcionan y que los empleados están respondiendo a ellos.
Ahora existe la sensación de que el trabajo se construye muy bien, puede sentarse y mirar sin cesar cómo se transfieren las tareas de un estado a otro (por cierto, seguimos estrictamente esto), pero ¿qué pasa con el desarrollo? Tablas de composición? ¿No sabes que la web no se detiene?
Desarrollo
Para que el equipo se desarrolle no solo en términos de experiencia entre proyectos, sino también en términos de habilidades, tenemos una tarea semanal especial llamada Bandera Verde. Si esta semana eres una bandera verde, entonces pasas tiempo todos los días buscando información útil sobre composición tipográfica, enfoques o simplemente tecnologías y lanzas enlaces a artículos en nuestro chat privado. Esto generalmente se hace en la mañana o inmediatamente después del almuerzo.
Se toma información sobre sus recursos favoritos, en el mismo "Habré", por ejemplo. Esto es bastante conveniente, porque sabe que su colega lanza enlaces a los principales artículos al chat todos los días, y solo tiene que leerlo por la noche después del trabajo.
Vale la pena mencionar de inmediato: a pesar del hecho de que todos apoyan esta actividad, muchos se olvidan de hacerlo diariamente. Por lo tanto, introdujimos otro deber, también semanal, que está diseñado para motivar a la bandera verde a no olvidarse de nuestros deberes. Y si aún olvida la bandera verde, el inspector puede quitarse la información. Curiosamente, pero este enfoque funciona sin fallas y, a veces, ambos asistentes arrojan validez al chat.
Si tienes miedo del número de obligaciones, entonces no todo es tan malo. Un empleado estable tiene un deber: este es el proyecto en el que trabaja. Y periódicamente se agrega un segundo reloj, la bandera verde o el motivador de la bandera verde, que, de hecho, es solo una formalidad.
Resumen
Por lo tanto, acabamos de reunir desde cero un equipo distribuido y, lo más importante, un equipo de diseño funcional. Recordemos lo que nos ayudó:
- El chat privado le permite resolver rápidamente todos los problemas emergentes.
- Las transacciones diarias lo ayudan a realizar un seguimiento de quién está haciendo qué y a comprender el panorama general.
- Las reglas de trabajo fijas y su estricto cumplimiento permiten mantener la coherencia del código en todos los proyectos.
- Los turnos de dos semanas durante todo el día le permiten estar en el contexto de todos los proyectos y proporcionar una distribución automática justa de las tareas.
- La revisión del diseño le permite estar seguro de la calidad del resultado que llega al cliente.
- Nos aseguramos de que la revisión se realice con regularidad y que su trabajo inacabado no se acumule.
- El responsable diariamente arroja nuevos artículos al chat para el desarrollo, discute nuevos enfoques y prácticas, intenta, aplica.
Todo esto nos ayuda a cerrar tareas y proporcionar un diseño para toda la unidad. ¿Y qué actividades hay en sus equipos?