Diseñando un Equipo de Sistemas

Modelos y lecciones aprendidas para escalar un equipo para una empresa

La mayoría de las organizaciones están llegando a comprender los sistemas y por qué son importantes. Sin embargo, ¿cuánto cuesta? ¿Qué equipo necesitamos?

Un equipo del sistema sirve equipos de productos (o similares)

El excelente libro Org Design for Design Orgs de Peter Merholz y Kristen Skinner describe modelos y roles en la composición de equipos y organizaciones de diseño. En el capítulo Composición de roles y equipos, describen un equipo de investigación adjunto que sirve en muchos otros equipos:

"Los investigadores de UX ahora tienen una masa crítica para ser su propio equipo ... [con] un Jefe de Investigación ... apoyando el crecimiento profesional de los investigadores y manteniendo una comprensión global de los conocimientos de investigación en todos los productos y servicios de una empresa".

Cuando leí esto, pensé para mí mismo "Sí, como equipos de sistemas de diseño" resolviendo los problemas de diseño generalizados y simples: un lenguaje visual, componentes de interfaz utilizables, etc.

Con este modelo en mente, me sorprendió escuchar a Peter reflexionar sobre el equipo de sistemas (de Spotify) en noviembre pasado en UI21 como uno que tenía que "piratear un parche, un parche organizacional en [el] modelo [s]" que describió. Tal vez estoy malentendido. Pero he estado en ~ 15–20 equipos de sistemas a lo largo de los años que prestan servicios a muchos equipos de manera similar (pero no igual) a tales prácticas de investigación.

En mi experiencia, el equipo de sistemas óptimo es multidisciplinario e independiente para servir a muchos equipos que hacen cosas digitales. El equipo del sistema se comporta como un producto que consumen los productos (y otros equipos).

¿Quién está en ese equipo? ¿Son a tiempo completo o parcial? ¿Qué disciplinas se deben representar? ¿De qué equipo (s) los obtenemos?

Con esas preguntas en mente, este artículo ilustra las etapas comunes de crecimiento de un equipo de sistemas, comparte ejemplos de equipos que he liderado en los últimos cuatro años, y cubre los patrones y posibles dificultades que puede enfrentar al formar y operar un equipo de sistemas.

Etapas del crecimiento del equipo de sistemas

La mayoría de las personas con las que hablo en clientes, conferencias y el Sistema de Diseño Slack de nuestra comunidad están evolucionando a través de una de las cuatro etapas de crecimiento: temporizadores, personas asignadas, equipo dedicado y equipo de equipos.

Etapa # 1: Temporizadores de repuesto

El sistema de adaptación individual trabaja en los límites del tiempo a menudo describe cómo su explosión apasionada realmente no ha despegado:

"Estoy por mi cuenta. He creado una {Hoja de calcomanías de boceto o un kit de código mini-Bootstrap} en mi tiempo extra, pero nadie más lo está usando. ¿Cómo doy el siguiente paso?

Los sistemas construidos los viernes por la tarde o los domingos por la noche no perduran. Una plantilla de boceto inicial o un código inicial es mejor que nada. Sin embargo, los esfuerzos espartanos no son la práctica de una empresa en ciernes.

Para llevar: ¡No te desanimes! Muchos viajes del sistema comienzan así. Demuestre que sus herramientas conducen a resultados (consistencia, eficiencia, reutilización) en proyectos piloto. Es un trampolín para educar cómo los esfuerzos de un sistema benefician a otros.

Etapa 2: Individuo (s) asignado (s)

A medida que se reconoce el valor del sistema, un gerente talla la asignación predecible pero limitada de un individuo (10% - 25%) a partir de un compromiso del equipo del producto y publica la responsabilidad del sistema a los equipos y pares. Con el mandato y el tiempo necesarios, comienza a lanzar resultados tangibles con regularidad, ya sean activos de diseño estandarizados o un kit codificado.

En este punto, los defensores de sistemas con ideas afines pueden comenzar a coordinar el diseño y la ingeniería. Alguien puede comenzar un retraso, pero puede pudrirse con boletos vagamente definidos que descansan durante meses. La documentación a medio hacer brota en páginas web sin pulir o (¡oh no!) Confluencia. Las actualizaciones ocurren, pero pocos saben cuándo, cómo o por qué.

Para que un sistema prospere, debe publicar resultados de alta calidad y servir a los usuarios de manera confiable.

"Si eres bueno en eso, creas una demanda dentro de tu organización que no puede cumplir con las asignaciones actuales". - Jared Spool, más allá del punto de inflexión de UX

Con un flujo constante de resultados regulares, sus clientes (equipos de productos) adoptan piezas, las personas comienzan a ceder el control a los problemas resueltos por el sistema, y ​​la administración se calienta ante la idea de formar un equipo dedicado.

Etapa 3: Equipo del sistema como equipo de producto

Al establecer un equipo de sistema formal, busque una combinación con autoridad reconocida de las disciplinas de diseño e ingeniería.

Composición del equipo del sistema de alto nivel, por tamaño

Los equipos que he formado y dirigido recientemente se componen de una combinación de:

  • DEBEN TENER: Los miembros del diseño pueden abarcar subdisciplinas (visual, interacción, arquitectura de la información, por nombrar algunas), pero el equipo debe sobresalir en la creación de un lenguaje visual elegante.
  • DEBE TENER: Ingeniería aporta un enfoque frontal con conocimiento de HTML y CSS, habilidades experimentadas para establecer convenciones y construcción de herramientas.
  • DEBE TENER: habilidades de gestión de productos y liderazgo para establecer la visión, dirigir la dirección, seleccionar hojas de ruta, supervisar la adopción y organizar los atrasos, scrums y críticas.
  • PODRÍA TENER: preocupaciones de especialidad como estrategia de contenido, accesibilidad, rendimiento, SEO y más. Si bien es valioso, tenga en cuenta que los sistemas se unen principalmente con el diseño y la ingeniería.
  • USTALMENTE NO TIENE: QA e Investigación. La financiación del control de calidad a menudo no es suficiente y los equipos del sistema pueden establecer prácticas para evaluar la calidad de todos modos. La investigación puede existir como un servicio hermano para los equipos de productos.

Etapa 4: Equipo de equipos del sistema

Algunas empresas masivas (como, sospecho, Google, IBM, GE, Cisco o Microsoft) aumentan los esfuerzos de los sistemas para abarcar un grupo de múltiples equipos interrelacionados para lograr los objetivos del sistema.

Equipo de equipos

Para la mayoría de nosotros que sirven muchos menos productos que ellos, esta escala es completamente poco realista e innecesaria. Claro, es útil ver las proporciones atribuidas a cada práctica. Sin embargo, esta escala puede ahuyentar a los patrocinadores de un equipo de sistemas como equipo de producto. Alinee el tamaño de su equipo con objetivos realistas y resultados clave que desea obtener.

Ejemplos de equipo del sistema

Aunque participé en equipos de sistemas de diseño de manera continua desde 2006, la práctica se desvió considerablemente alrededor de 2012 cuando ocurrió la respuesta, se fortaleció HTML y CSS y los unicornios comenzaron (parcialmente) a diseñar sistemáticamente en código.

Los siguientes ejemplos expresan una progresión de modelos de equipo de sistemas con los que he estado involucrado desde entonces.

Ejemplo 1: el comercio electrónico se vuelve receptivo

Lo que funcionó bien: este equipo dedicado diseñó y documentó abundantes estándares en una experiencia personalizada basada en la web. Era el sistema del "gran kahuna": estilo, interacción, componentes, patrones, marca, editorial, SEO, accesibilidad, ¡funciona! A medida que la empresa tardó ~ 2 años en "responder", el sistema fue fundamental para converger un viaje dispar del cliente.

Lo que he hecho diferente desde: suspiro, ingeniería. Nuestro equipo del sistema construyó una biblioteca de componentes robusta para crear prototipos de diseños receptivos y construir el sitio estándar. Sin embargo, los líderes de ingeniería resistieron nuestro código y nunca construyeron una biblioteca para su comunidad. ¿El resultado? Esfuerzos duplicados, ineficiencias e inconsistencias, excepto que los desarrolladores introduzcan nuestro código en sus compilaciones.

Prometí no volver a buscar un sistema sin código en entornos que obviamente lo necesitan, pero los líderes de ingeniería bloquean la búsqueda.

Ejemplo 2: un lenguaje de diseño para una organización explosiva

Lo que funcionó bien: con el aumento de la organización de ~ 30 a más de 200 diseñadores en 12-18 meses, el equipo del sistema dirigió el desarrollo de un lenguaje de diseño compartido documentado en un sitio de estándares personalizados (por lo tanto, el desarrollador front-end). Dada la escala masiva y distribuida de la organización de diseño, empleamos diseñadores federados para impulsar la interacción, la experiencia de usuario y los conceptos básicos de iconos.

Si bien el alcance era más pequeño, solo estilo visual, botones y formas en seis meses de trabajo, fue aclamado como un éxito dada la escala y los desafíos enfrentados.

Lo que he hecho de manera diferente desde: Más personal interno haciendo y conectando. Si bien produjimos resultados de manera efectiva, el pastoreo de una comunidad tan grande se vio afectado por la geografía, la tecnología y las prácticas operativas inestables. La organización necesitaba más personal interno del sistema y estabilidad para eso.

Y, de nuevo: código. Deberíamos haber lanzado un kit y pedir perdón más tarde.

Ejemplo 3: la biblioteca de sitios web sencilla

Lo que funcionó bien: Armado con un lenguaje visual bien definido de una agencia separada, diseñamos, construimos y documentamos una biblioteca de componentes sencilla para propiedades web diversas y ricas en contenido. Nuestro equipo implementó con éxito una primera versión en tres meses y siguió con el mantenimiento y el crecimiento durante un período limitado.

Lo que he hecho de manera diferente desde: a pesar de las advertencias manifiestas sobre la capacidad requerida para mantenerlo con vida, la biblioteca entró en hibernación a medida que el personal se dispersó. Nuestro plan de sucesión y despliegue no fue lo suficientemente fuerte como para resistir la partida de mi agencia. En proyectos desde entonces, he planificado asertivamente asignaciones y sucesiones con líderes internos durante todo el período formativo del sistema.

Ejemplo 4: ecosistema de producto digital

Lo que funcionó bien: me uní a un diseñador interno para diseñar y documentar el estilo y los componentes basados ​​en el rediseño de productos insignia que habíamos hecho un trimestre antes. Aún mejor, la ingeniería invirtió a tres desarrolladores de medio tiempo de productos emblemáticos que tejieron los resultados del sistema de manera incremental en el trabajo continuo del producto.

Lanzamos una biblioteca v1.0 en tres meses y seguimos con ciclos trimestrales para refinar las herramientas y expandir el catálogo de la biblioteca. A medida que el diseño, la ingeniería y el producto se convocaron para la planificación de 2017, el VP Engineering elogió el sistema:

“Lo más importante que hicimos el año pasado fue construir este sistema. Es la base de todo nuestro trabajo futuro ".

Ejemplo 5: la biblioteca con competidores

Lo que ha funcionado bien hasta ahora: mientras comenzamos a optimizar y ampliar una biblioteca central existente, surgieron bibliotecas adicionales en otras líneas de negocio. Los equipos estaban confundidos: ¿cuál adoptar? En lugar de competir, coordinamos esfuerzos y nos integramos en un equipo más grande y único.

Hubo un arrastre a corto plazo para volver a formar equipo y refactorizar el código para servir de manera flexible a todos. Los scrums y la planificación también se hicieron más largos. Sin embargo, nuestro camino hacia adelante producirá juntos en el futuro previsible, y el CEO y otro VP parecen convencidos:

“Estaba sintiendo y admití que tendríamos dos bibliotecas, pero luego apareció una tercera. Estoy encantado de ver que hemos encontrado una manera de hacer solo una ".

Otro componente de escalar la práctica fue involucrar a la comunidad de diseño federada para que se ocupara de sus propias preocupaciones: UX, íconos, marca, gráficos, contenido y accesibilidad. Si bien ninguno de estos "propietarios de segmentos" tiene una capacidad dedicada, ahora todos son puntos de contacto para moderar las discusiones, impulsar prioridades e involucrar a sus pares para entregar resultados.

Lecciones aprendidas Equipos de gestión del sistema

# 1 El diseño codificado es la verdad. Diseño e ingeniería de mezclas.

Participé en suficientes equipos desde 2006 haciendo bibliotecas de plantillas de activos de diseño y documentando el diseño. Estoy convencido de que el valor de un sistema de diseño aumenta diez veces cuando se forma un puente entre un diseño sólido y prácticas de ingeniería.

Sí, hay condiciones de escala mundial (ejemplo: Google Material) en las que es esencial una especificación de diseño incluso sin código. Sin embargo, en mi práctica, al unificar un lenguaje visual, componentes y otros marcos en el código incorporado se da cuenta de la eficiencia, claridad y facilidad de mantenimiento prometidas por el sistema.

Para llevar: No importa el cliente, mi pregunta inicial más importante es quién de cada área puede trabajar en conjunto para lograr este objetivo compartido.

# 2 La capacidad de medio tiempo es una fortaleza, no una debilidad

¿Notan el patrón en cada equipo de arriba? Todos los miembros del personal están comprometidos a medio tiempo de capacidad, de lo contrario permanecen comprometidos con un producto. En un equipo de tamaño moderado, tales compromisos crean relaciones en 3–5 equipos clave de productos. Esto permite ver qué productos importantes necesitan y minimiza el sesgo hacia cualquier producto individual.

Diseñadores e ingenieros, convocados como equipos del sistema aún asignados a productos diferentes

Esto viene con riesgos:

  • Los líderes de productos reconocen una capacidad del sistema de medio tiempo, pero aún así asignan y esperan 32 o más horas de capacidad por semana para su producto.
  • Los miembros del equipo montan múltiples rituales conflictivos (scrum, planificación, crítica) que distorsionan la proporción de reuniones frente a "hacer cosas".

Para llevar: puede ir con los medios tiempos, solo espere alinearse. Para gestionar hacia arriba y al otro lado. Distinguir los compromisos de flexión de los que se rompen. Se complicará, pero no lo suficiente como para dañar seriamente el esfuerzo.

# 3 Balance de continuidad con rotación

Para los equipos del sistema con más de 2 empleados de cualquier disciplina, a veces identificaremos miembros permanentes destinados a un compromiso de un año o más. Estos miembros pueden escalar a tiempo completo y persistir no solo en decisiones y convenciones, sino también en rituales tribales. La continuidad es importante. Por otro lado, rotaremos a otro personal del sistema a medida que se adopte la adopción de productos.

Por ejemplo, después de un lanzamiento inicial, buscaremos qué productos son la "próxima ola" de adoptantes. Dentro de esos productos, buscaremos diseñadores e ingenieros disponibles y talentosos disponibles para un recorrido de medio tiempo de tres o seis meses con el equipo del sistema. Todos ganan: el sistema se aprende de manera profunda y previsible, y un producto puede expandirse y evolucionar el núcleo para su propio beneficio.

# 4. Anticipe la contracción periódica como una oportunidad

Es común que parte del personal del sistema vuelva al trabajo de producto a tiempo completo después de un lanzamiento significativo del sistema. Está bien.

Analice el cambio en las tareas relacionadas con la integración de las preocupaciones del sistema, monitoree cómo el ex miembro del equipo del sistema se está dando cuenta del potencial del sistema en su espacio y use esas mejoras del producto para construir la narrativa de los beneficios y la flexibilidad del sistema.

# 5. Nuevos miembros a bordo como prueba de fuego de la calidad del sistema

La integración de un nuevo miembro del equipo es un excelente (y fácil) caso de prueba de la claridad de diseño, la calidad del código y el cumplimiento de las promesas del sistema de su sistema.

El año pasado, un cuarto ingeniero subió a bordo e inmediatamente expuso la lamentable documentación del proceso del sistema en algunas áreas, así como un enfoque insuficiente en pruebas de accesibilidad específicas. Durante el mes siguiente, todos luchamos para mejorar esas cualidades. Aprovechando el momento, nuestro nuevo miembro saltó para resolver algunos de esos desafíos y estableció una posición influyente junto a los "temporizadores" que ya están en el equipo.

# 6. El personal del sistema debe abarcar circunscripciones

¿Sirve el sistema una cartera para una pero no para todas las líneas de negocio? Entonces ese es el límite de donde se obtiene el personal. ¿El sistema abarca organizaciones de marketing y productos? Luego trabaje duro para establecer (como mínimo) una colaboración regular y significativa entre los dos o (idealmente) mezclar al personal de ambas organizaciones en una práctica.

Sin una representación adecuada, es difícil lograr que un sistema creado por personas de aquí sea adoptado por equipos de allá y de todas partes.

27 de abril de 2017: los diagramas del artículo se actualizaron para eliminar la especificidad de género en respuesta al comentario de un lector.