Contenidos
Sistema de diseño Nielsen
El proceso de Diseño de Arquitectura es un método de intercambio y síntesis que permite al Director de Programa (PM) y al Ingeniero de Sistemas traducir los resultados de los procesos de Definición de Requisitos de las Partes Interesadas y Análisis de Requisitos en soluciones de diseño alternativas y establece el diseño arquitectónico de las soluciones candidatas que pueden encontrarse en un modelo de sistema. Las soluciones de diseño alternativas pueden incluir elementos de hardware, software y humanos; sus elementos de sistema habilitadores; y las interfaces internas y externas relacionadas.
El proceso de diseño de la arquitectura, combinado con la definición de los requisitos de las partes interesadas y el análisis de los requisitos, proporciona información clave sobre los riesgos técnicos en una fase temprana del ciclo de vida de la adquisición, lo que permite el desarrollo temprano de estrategias de mitigación. El diseño de la arquitectura es fundamental para garantizar que se consideren múltiples soluciones bien respaldadas. El proceso de diseño de la arquitectura apoya el análisis de las consideraciones de diseño y permite razonar sobre los aspectos y atributos clave del sistema, como la fiabilidad, la capacidad de mantenimiento, la capacidad de supervivencia, la sostenibilidad, el rendimiento y el coste total de propiedad.
Diseño de operaciones
Hay varias maneras de analizar las operaciones de diseño (DesOps), pero probablemente la más importante es como una forma de mapear el trabajo de diseño contra la mentalidad y los objetivos de las operaciones de los desarrolladores (DevOps). Como me dijo una persona hace poco, DevOps se creó como una forma de eliminar el control de calidad y la administración del sistema de la ecuación de las operaciones. Los desarrolladores eran dueños de su propio control de calidad y se les daban los medios y la autoridad para desplegar su código directamente a través del sistema o sistemas de entrega.
En el triunvirato del producto (gestión del producto, ingeniería, diseño), el diseño es el menos integrado en los entornos DevOps. Esto ha provocado los clásicos sistemas “wagile” (cascada antes que ágil) en los que han caído muchas organizaciones, mientras que las organizaciones más inteligentes han estado utilizando enfoques de “doble vía” que separan el descubrimiento de la entrega por completo. Para saber más sobre la doble vía, lea el libro “Inspired” de Marty Cagan.
Cuando se trata de la parte de diseño de la ecuación, no hay nada que se le parezca. Sistemas como Lean UX, son geniales, pero pocos los adoptan. Hablan sobre el proceso, pero a diferencia de DevOps, no operacionalizan el diseño en absoluto, y mucho menos de una manera que permita a las organizaciones mantenerse al día con el verdadero desarrollo de aplicaciones nativas de la nube de 12 factores (o principios similares) en el corazón de la mayoría de los sistemas DevOps.
Manual del sistema de diseño
Los flujos de valor y los procesos pueden ser operados por humanos, y estar total o parcialmente automatizados. Utilizan activos tangibles o intangibles y consumen recursos. Algunos ejemplos de activos tangibles son las fábricas, los centros de datos o las máquinas. Ejemplos de activos intangibles son las patentes, las relaciones con los proveedores o los conocimientos. Ejemplos de recursos son la electricidad, las materias primas o los servicios en la nube.
Los marcos de gestión y estrategia de operaciones utilizan el concepto de capacidad [MIT OCW 2010] sin proporcionar una definición comúnmente acordada. Existe confusión sobre qué es una capacidad operativa y qué diferencia las capacidades operativas de los recursos o las prácticas, ya que están estrechamente relacionadas [Wu 2010].
En las tres primeras definiciones, las capacidades proporcionan una representación de la empresa. Para diferenciar el modelado de capacidades de otras representaciones de la empresa, estas definiciones utilizan calificativos; por ejemplo:
La definición de Constantine Samaras y Henry H. Willis relaciona la capacidad con el logro de un efecto deseado. Una capacidad se convierte en un resultado que debe alcanzarse, más que en una representación de la empresa.
Incorporación de las operaciones de diseño
Con la feroz competencia que existe en el mercado, contratar a los mejores talentos del diseño no es tarea fácil. Sin embargo, reunir a un grupo de personas experimentadas y capacitadas en un mismo lugar es sólo una parte del éxito. Entre otras cosas, para crear un equipo de diseño de productos próspero también hay que invertir en operaciones de diseño (también conocidas como DesignOps).
En este artículo, explicaremos qué es DesignOps y cómo puede utilizarlo para mejorar el sistema de diseño digital en su organización. Hablaremos de áreas como la colaboración entre equipos, el establecimiento de objetivos y los sistemas de intercambio de información, junto con el uso del software DesignOps adecuado.
En el pasado, los diseñadores solían llevar muchos sombreros. Hacían la investigación de UX, escribían historias de UX, hacían wireframes, e incluso la codificación del frontend. Si bien este enfoque todavía puede funcionar bien para algunos equipos, es improductivo a escala. Aquí es donde entra DesignOps, ayudando a orquestar el trabajo en equipo y la construcción de una estructura y roles claros.
Dicho esto, DesignOps no es un ejercicio aislado, “sólo para el equipo de diseño”, reservado para las organizaciones de diseño. Requiere que se comparta mucha información con otras partes interesadas (especialmente, con los desarrolladores de software). Siguiendo un conjunto de prácticas, sus diseñadores pueden mejorar la calidad de estas interacciones, centrarse en la finalización efectiva de los objetivos y liberar tiempo para otras iniciativas.