Mejor colaboración al incorporar a los diseñadores al proceso de revisión del código

La colaboración fluida entre desarrolladores y diseñadores es algo a lo que todos aspiran, pero es notoriamente difícil. Pero con la web avanzada de hoy en día, es difícil, si no imposible, crear un producto verdaderamente excelente sin la colaboración entre disciplinas. Debido a la gama de tecnologías requeridas para construir un producto, el producto solo puede tener éxito cuando todas las disciplinas (desarrolladores y diseñadores, creadores de contenido y estrategas de la experiencia del usuario) están profundamente involucradas desde las primeras etapas del proyecto. Cuando esto sucede, todos los extremos de lo que se necesita para construir un producto se unen naturalmente en un todo unificado y, por lo tanto, en un gran producto.

Debido a esto, ya nadie promueve realmente los procesos en cascada. Sin embargo, involucrar a otras personas desde el principio, especialmente a personas de otras disciplinas, puede dar miedo. En el peor de los casos, conduce a un "diseño por comité".

Además, tanto los diseñadores como los estrategas de contenido a menudo tienen antecedentes en campos en los que un solo genio creativo sigue siendo el ideal. Hacer que otra persona pruebe tu trabajo puede parecer una amenaza para tu creatividad.

Entonces, ¿cómo puede involucrar a las personas desde el principio para evitar la cascada, pero también asegurarse de que no se está preparando para el diseño por parte del comité? Encontré mi respuesta cuando aprendí sobre revisiones de código.

El ¡Ajá! Momento

En julio de 2017, fundé Confrere junto con dos desarrolladores, y rápidamente contratamos a nuestro primer ingeniero (yo no soy desarrollador, soy más diseñador de contenido o UX). Nuestra colaboración funcionaba sorprendentemente bien, tanto que en nuestras retrospectivas, el tema recurrente era que todos sentíamos que lo estábamos “haciendo bien”.

Me senté con mis colegas para tratar de identificar qué era exactamente lo que estábamos "haciendo bien" para que pudiéramos tratar de preservar ese sentimiento incluso cuando nuestra empresa crecía y nuestro equipo se expandía. Nos dimos cuenta de que todos apreciábamos que todo el equipo se involucrara desde el principio y que fuéramos honestos y claros en nuestros comentarios mutuos. Nuestro CTO Dag-Inge agregó: “Funciona porque lo estamos haciendo como compañeros. No estás siendo regañado y solo estás recibiendo una lista de fallas”.

La palabra "compañero" es lo que me dio el momento aha. Me di cuenta de que aquellos de nosotros que trabajamos en UX, diseño y contenido tenemos mucho que aprender de los desarrolladores en lo que respecta a la colaboración.

La revisión por pares en forma de revisiones de código es esencial para la forma en que se construye el software. Para mí, las revisiones de código ofrecen inspiración para mejorar la colaboración dentro de nuestros propios campos, pero también un modelo para colaborar entre campos y disciplinas.

Si ya está familiarizado con las revisiones de código, no dude en pasar a la siguiente sección.

¿Qué es una revisión de código?

Una revisión de código se puede hacer de varias maneras. Hoy en día, la forma más típica de revisión de código ocurre en las llamadas solicitudes de extracción (usando una tecnología llamada git). Como se ilustra a continuación, las solicitudes de incorporación de cambios permiten que otras personas del equipo sepan que un desarrollador ha completado el código que desea fusionar con el código base principal. También permite que el equipo revise el código: brindan comentarios sobre el código antes de fusionarlo, en caso de que necesite mejoras.

Las solicitudes de incorporación de cambios tienen funciones claramente definidas: hay un autor y un revisor o revisores.

Como ejemplo, supongamos que nuestro ingeniero senior Ingvild ha realizado un cambio en el flujo de registro de Confrere. Antes de que se fusione con el código base principal y se envíe, ella (la autora) crea una solicitud de extracción para solicitar una revisión de nuestro CTO Dag-Inge (el revisor). No hará ningún cambio en su código, solo agregará sus comentarios.

Depende de Ingvild cómo quiere actuar sobre los comentarios que recibió en la revisión. Actualizará su solicitud de incorporación de cambios con los cambios que considere oportunos.

Cuando los revisores aprueban la solicitud de incorporación de cambios, Ingvild puede fusionar sus cambios con el código base principal.

¿Por qué molestarse en hacer una revisión de código?

Si nunca ha realizado una revisión de código, el proceso anterior puede sonar burocrático. Si tiene dudas, aquí hay un montón de publicaciones de blog e investigaciones académicas sobre las ventajas de la revisión de código.

Las revisiones de código marcan la pauta para toda la empresa de que todo lo que hacemos debe estar abierto al escrutinio de otros, y que dicho escrutinio debe ser una parte bienvenida de su flujo de trabajo en lugar de verse como una amenaza.

— Bruce Johnson, cofundador de Full Story

La revisión del código reduce el riesgo. Tener a alguien que revise su trabajo, y también saber que alguien revisará su trabajo, ayuda a eliminar errores y aumenta la calidad. Además, garantiza la coherencia y ayuda a cada miembro del equipo a familiarizarse con más código base.

Cuando se hace bien, la revisión del código también crea una cultura de colaboración y apertura. Tratar de comprender y criticar el trabajo de otras personas es una excelente manera de aprender, al igual que recibir comentarios honestos sobre su trabajo.

Tener siempre al menos dos personas revisando el código también reduce las ideas de "mi" código y "su" código. Es nuestro código.

Teniendo en cuenta estas ventajas, una revisión no debería ser solo para el código.

Revise los principios para todas las disciplinas, no solo el código

En las reseñas, siempre hay un autor y uno o más revisores. Eso significa que puede involucrar a las personas desde el principio sin caer en el diseño por comité.

En primer lugar, debo mencionar dos factores importantes que afectarán la capacidad de su equipo para realizar revisiones beneficiosas. No necesariamente tienes que haberlos dominado, pero como mínimo, debes aspirar a lo siguiente:

• Usted y sus colegas se respetan mutuamente y respetan las disciplinas de cada uno.
• Está lo suficientemente seguro de sí mismo en su propio rol como para sentir que puede dar y recibir críticas (esto también está relacionado con la seguridad psicológica del equipo).

Incluso si no estamos revisando el código, hay mucho que aprender de las mejores prácticas existentes para las revisiones de código.

Dentro de nuestro equipo, tratamos de adherirnos a los siguientes principios cuando hacemos revisiones:

1. Critique la obra, no al autor.
2. Sea crítico, pero manténgase afable y curioso.
3. Diferenciar entre a) Sugerencias b) Requisitos, c) Puntos que necesitan discusión o aclaración.
4. Mueva las discusiones de texto a cara a cara. (El vídeo cuenta)
5. ¡No olvides elogiar las partes buenas! ¿Qué es inteligente, creativo, sólido, original, divertido, agradable, etc.?

Estos principios no se escribieron realmente hasta después de que discutimos por qué nuestra colaboración estaba funcionando tan bien. Todos sentimos que ya se nos permitía y se esperaba que hiciéramos preguntas y sugiriéramos mejoras, y que nuestras motivaciones siempre fueron sobre construir algo grandioso juntos, y no sobre criticar a otra persona.

Debido a que teníamos claro qué tipo de retroalimentación dábamos y también recordábamos elogiar el buen trabajo de los demás, hacer reseñas era una fuerza positiva en lugar de una desmotivación.

Un ejemplo

Para darle una idea de cómo nuestro equipo usa la revisión en todas las disciplinas ya lo largo de un proceso, veamos cómo los diferentes miembros de nuestro equipo cambiaron entre los roles de autor y revisor cuando creamos nuestro flujo de registro.

Paso 1: Recopilación de requisitos

Autor: Ida (UX)

Revisores: Svein (estrategia), Dag-Inge (ingeniería), Ingvild (ingeniería).

Las sesiones de pizarra pueden ser agotadoras si no tienen una estructura. Para mantener la productividad y la creatividad, utilizamos la estructura autor/revisor, incluso para algo tan aparentemente básico como una lluvia de ideas en una pizarra. En este caso, en el que estábamos elaborando los requisitos para nuestro flujo de registro, yo tenía que ser el autor y el resto del equipo dio su opinión y actuó como revisor. Debido a que también sabían que podrían revisar lo que se me ocurrió en el paso 2 (muchas más oportunidades para ajustes, sugerencias y mejoras), trabajamos rápidamente y pudimos acordar los requisitos en menos de 2 horas.

Paso 2: Mockup con microcopia

Autor: Ida (UX)

Revisores: Ingvild (ingeniería), Eivind (diseño), Svein (estrategia).

Como autor, creé una maqueta del flujo de registro con microcopia. ¿Tuvo sentido el flujo de registro, tanto desde la perspectiva del usuario como de la ingeniería? ¿Y cómo podríamos mejorar el flujo desde una perspectiva de diseño y frontend? En esta etapa, era fundamental trabajar en un formato en el que fuera fácil para todas las disciplinas dar su opinión (optamos por Google Docs, pero también se podría haber hecho con una herramienta como InvisionApp).

Paso 3: Implementación del flujo de registro

Autor: Ingvild (ingeniería)

Revisor: Ida (UX) y Dag-Inge (ingeniería).

Habíamos acordado el flujo, los campos de entrada y la microcopia, por lo que dependía de Ingvild implementarlo. Gracias a Surge, podemos crear automáticamente direcciones URL de vista previa de los cambios para que las personas que no pueden leer el código también puedan dar su opinión en esta etapa.

Paso 4: prueba de usuario

Autor: Ida (UX)

Revisor: Los usuarios.

Sí, consideramos las pruebas de usuario como una forma de revisión. Llevamos nuestro flujo de registro recién construido cara a cara con los usuarios reales. Este paso nos dio mucha información y, como resultado, surgieron los cambios más significativos en nuestro flujo de registro.

Paso 5: Diseño

Autor: Eivind (diseño)

Revisores: Ingvild (ingeniería) e Ida (UX).

Cuando el diseño aparece de repente aquí en el paso 5, puede parecerse mucho a un proceso en cascada. Sin embargo, nuestro diseñador Eivind ya había estado involucrado como revisor desde el paso 2. Dio muchos comentarios útiles en esa etapa y también pudo comenzar a pensar en cómo podríamos mejorar el diseño del flujo de registro más allá de los módulos existentes. en nuestro sistema de diseño. En este paso, Eivind también podría ayudar a resolver algunos de los problemas que identificamos en las pruebas de usuario.

Paso 6: Implementación

Autor: Ingvild (ingeniería)

Revisor: Eivind (diseño), Ida (UX) y Dag-Inge (ingeniería).

Y luego volvemos a implementar.

Por qué funciona la revisión

En resumen, siempre hay un solo autor, evitando así el diseño por comité. Al involucrar a una variedad de disciplinas como revisores desde el principio, evitamos tener un proceso en cascada.

Las personas pueden señalar sus inquietudes con anticipación y también comenzar a pensar en cómo pueden contribuir más adelante. Los roles claramente definidos mantienen el proceso en marcha.

Tutoriales de revisión regulares

Inspirándonos en los tutoriales de código, también realizamos tutoriales de revisión regulares con diferentes enfoques, guiados por los siguientes principios:

• El tutorial se hace juntos.
• Una persona se encarga de revisar y documentar.
• La idea es identificar problemas , no necesariamente resolverlos.
• Elija un formato que brinde la mayor cantidad de contexto posible, de modo que sea fácil actuar sobre los hallazgos más adelante (por ejemplo, InvisionApp para revisiones visuales, Google Docs para texto, etc.).

Hemos realizado recorridos de revisión para cosas como auditorías de accesibilidad, revisión de solicitudes de funciones, auditoría de la implementación del diseño y evaluaciones heurísticas de usabilidad.

Cuando hacemos nuestras revisiones de accesibilidad trimestrales, nuestro consultor de accesibilidad Joakim primero revisa la interfaz y los documentos y prioriza los problemas que encontró en una hoja de Google compartida. Joakim luego nos explica los problemas más importantes que ha identificado.

Reunirse cara a cara (o al menos en video) para analizar los problemas ayuda a crear un entorno para el aprendizaje en lugar de una sensación de supervisión o microgestión.

Si te encuentras siempre ocupado con algo que debe publicarse o arreglando lo que está en la parte superior de tu bandeja de entrada, las revisiones pueden ayudar a remediarlo. Si reserva medios días regulares para revisar el trabajo que ya ha realizado, puede identificar los problemas antes de que se vuelvan urgentes. También puede ayudarlo a reenfocarse y asegurarse de que sus prioridades se mantengan en la línea correcta. Tal vez su equipo no debería comenzar a crear esa nueva característica antes de que esté seguro de que las características existentes están a la altura de sus estándares.

Las pruebas de usuario son una forma de revisión

Una motivación importante para las revisiones de código es reducir el riesgo. Al hacerlo cada vez que introduce un cambio o agrega algo nuevo a su producto, y no solo cuando sospecha que algo no está a la altura, disminuye la posibilidad de errores de envío o características deficientes. Creo que deberíamos mirar las pruebas de usuario desde la misma perspectiva.

Verá, si desea reducir el riesgo de envío con problemas importantes de usabilidad, las pruebas de usuario deben ser parte de su proceso. No basta con que los diseñadores de UX revisen la interfaz. Varios estudios han encontrado que incluso los expertos en usabilidad fallan en identificar todos los problemas reales de usabilidad. En promedio, 1 de cada 3 problemas identificados por los expertos fueron falsas alarmas; no eran problemas para los usuarios en la práctica. Pero lo que es peor, los expertos pasaron por alto 1 de cada 2 problemas que los usuarios tenían.

Omitir las pruebas de usuario es un riesgo tan grande como omitir la revisión del código.

¿La revisión significa la muerte de la creatividad?

Las personas que trabajan en diseño, experiencia de usuario y contenido a menudo tienen antecedentes educativos de escuelas de arte o tal vez de literatura, en las que el único creador o genio artístico creativo es aclamado como el ideal. Si retrocedes en la historia, este también solía ser el caso de los desarrolladores. Con el tiempo, esto ha cambiado por necesidad, ya que el desarrollo web se ha vuelto más complejo.

Si te aferras a la idea de que la creatividad proviene de algún lugar muy profundo de ti mismo, la idea de revisar puede parecer amenazante o atemorizante. ¿Alguien entrometiéndose en tu trabajo a medio terminar? Ay. Pero si piensas en la creatividad como algo que puede surgir de muchas fuentes, incluido el diálogo, la colaboración o cualquier forma de inspiración (ya sea del exterior o de algún lugar dentro de ti), entonces una revisión es solo un activo y una oportunidad.

Mientras estemos construyendo algo para la web, no hay manera de colaborar con otras personas, ya sea dentro de nuestro propio campo o de otros. Y una buena idea sobrevivirá a la revisión.

Vamos a crear algo grande juntos.