martes, 22 de mayo de 2018

Las Implicaciones Financieras de la Deuda Técnica

by Erik Frederick - Finance Expert @ Toptal (translated by Yesica Danderfer)

¿Qué pasaría si no tuvieras idea de la cantidad de deuda que tenías? Sería una posición incómoda para estar, no saber cuánto costaba o hasta qué punto impedía que tu empresa realizara mejoras operativas, reaccionara a los cambios del mercado o incluso transformara el negocio por completo.

Por otra parte, ¿qué pasa si casi cualquier persona en su organización puede incurrir en deudas sin solicitar permiso? Por ejemplo, su jefe de bienes raíces podría entrar rápidamente en un contrato de arrendamiento de varios años con un alquiler anual bajo, pero con rentas que se incrementarán significativamente en los últimos años, sin que nadie lo divulgue más que de manera conversacional.

Todo esto suena a un gobierno imprudente, pero en realidad es bastante común en las empresas. La trampa es que este tipo de “deuda” no viene en la forma de los instrumentos financieros tradicionales que todos conocemos tan bien.

La deuda técnica tiene todas estas características.
La deuda en su forma más simple es pedir prestado hoy con la intención y promesa de pagar en el futuro. La deuda tiene sentido cuando los préstamos de hoy llevarán a un mañana mejor, por ejemplo, pedir prestado para la universidad o comprar una casa. En general, la deuda es mala cuando pedir prestado hoy conducirá a un mañana peor, por ejemplo, salir a cenar caro y ponerlo en una tarjeta de crédito que no pagará de inmediato.

En términos corporativos, la deuda puede ser buena cuando se incurre para financiar inversiones que proporcionarán un mayor rendimiento que el costo de la deuda También puede tener sentido si planeas vender el negocio mucho antes de que venza la deuda. La desventaja de la deuda es que tiene un gasto muy real que arrastra el efectivo y las ganancias, restringe la flexibilidad y puede llegar a ser tan oneroso que en última instancia podría conducir a quiebra.

Hasta ahora, la metáfora a la que nos referimos es acerca de la deuda financiera, otra forma de deuda técnica de la deuda (o “deuda tecnológica”) tiene muchas características similares y debe medirse, administrarse e incorporarse de manera deliberada. Si le permites a tu empresa llegar al mercado antes que la competencia, muy probablemente valga la pena. Del mismo modo, asumir la deuda tecnológica para mitigar una vulnerabilidad de seguridad potencialmente grave probablemente también valga la pena.

Sin embargo, la deuda técnica tiene sus desventajas, lo que genera ineficiencia e inercia, como cuando un departamento no quiere usar el software de otro, o si demora una actualización varias veces para alcanzar objetivos financieros a corto plazo.

Entonces, ¿qué es la deuda técnica?

La deuda técnica es un término que se ha utilizado principalmente en la comunidad técnica por Ward Cunningham, un programador de computadoras, quien acuñó la frase en 1992. Su uso ha despegado recientemente y ha ocupado un lugar central con la proliferación de programación ágil. La deuda técnica discutida en este artículo no se trata de metodología de programación sino más bien de las implicaciones estratégicas de su existencia.

En términos simples, la deuda técnica es el costo incremental y la pérdida de agilidad para tu empresa como resultado de decisiones anteriores que se tomaron para ahorrar tiempo o dinero al implementar sistemas nuevos o al mantener los existentes. Ocurre cuando los sistemas no están integrados correctamente o el código es demasiado complejo. Esto se debe a una variedad de razones, como ineficiencias, consideraciones de tiempo hasta el mercado o ejecución de versiones obsoletas del software, entre muchas otras.

Algunos ejemplos claros serían:
  1. Usar versiones anteriores de Windows que impidan usar nuevo software o aplicar una actualización de seguridad
  2. Los sistemas ERP en un círculo vicioso de ser tan viejos y personalizados que no se pueden actualizar, ya que sería un esfuerzo de “destripar y reemplazar”
  3. Sistemas similares que tienen funciones superpuestas en diferentes partes de tu organización
El siguiente diagrama es un gráfico útil para enmarcar cómo la deuda tecnológica difiere de otras implementaciones tecnológicas que se pueden hacer dentro de la pila tecnológica de una compañía. A menudo confundido con un error, la deuda técnica es muy diferente en el sentido de que su presencia podría no ser descaradamente obvia. Ahí radica el peligro, ya que mientras más tiempo permanezca intacto, mayor será la magnitud del efecto en el futuro.

una representación visual de un cuadro de matriz que organiza los cuatro tipos de mejoras técnicas que se pueden realizar

Como CFO que ha trabajado en IT y que me ha informado de TI en empresas empresariales con un alto nivel de apalancamiento, me sorprendió cómo la deuda técnica similar es a la deuda tradicional.

También me sorprendió lo opaco y arriesgado que es. Quienes tienen antecedentes financieros están bien versados ​​en los mecanismos de la deuda financiera; es tangible y fácil de calcular. Sin embargo, no ocurre lo mismo con la deuda técnica, que a menudo se entiende mal o se supone erróneamente que es un problema ajeno.

¿Cuáles son exactamente los costos de la deuda técnica y son reales?

La respuesta corta es que los costos en efectivo son muy reales. También hay algunos costos blandos importantes que deben identificarse y medirse y administrarse por separado. A continuación detallaré algunos ejemplos de estos costos:

Costos en efectivo

La deuda técnica es tan real como los pagos de intereses. Sin embargo, generalmente se manifiesta en las pérdidas y ganancias de una manera más indirecta que un simple gasto de línea de “interés”, como en las siguientes formas:

Jefe
  • Se necesita más personal simplemente para mantener los sistemas existentes
  • Tiempo adicional de desarrollador para generar nuevas capacidades
Gastos generales
  • Retraso en la realización de sinergias de integración de adquisiciones
  • Remediación y multas que emanan de infracciones de seguridad
Ventas
  • Ventas perdidas debido a cortes del sistema
  • Gasto de marketing menos eficiente
Capital de trabajo
  • Mayores requisitos, especialmente para las empresas con altos saldos de inventario

Costos suaves

Si bien los costos fijos tienen montos en dólares reales asociados con ellos, también hay costos menores que, a pesar de ser más difíciles de cuantificar y realizar ahorros, tienen un lastre absoluto en los resultados de su negocio. Éstas incluyen:

Inteligencia de mercado
  • Incapacidad de adaptarse rápidamente a las oportunidades o cambios en el mercado
  • Capacidad reducida de convertir datos en información para tomar mejores decisiones
  • Múltiples versiones de la verdad
Productividad
  • Menor productividad del personal debido a cortes de sistemas
  • Personal menos productivo que pasa más tiempo extrayendo y masajeando datos que analizándolo
  • Desviar el tiempo y la atención de la alta dirección si ocurre una importante violación de seguridad

En cuanto a la comparación de la deuda técnica y financiera, una de las principales diferencias es que la primera no tiene control formal. Con la deuda financiera, generalmente hay comités de crédito, equipos de administración de activos y pasivos, y personal del tesoro que supervisa los niveles como un halcón. Con la deuda técnica, sin embargo, muy pocos de estos controles existen en las empresas tradicionales.

![una tabla que muestra una lista de verificación de la deuda técnica y financiera]](https://uploads.toptal.io/blog/image/125779/toptal-blog-image-1522317985377-f0d07c5a22dfca04c062ef9ae9959c6b.png)

Cómo y por qué se incurre en deuda técnica

Con la deuda tradicional, la junta, junto con el CEO y el CFO, generalmente establecen la estructura de capital, es decir, la cantidad de capital, la cantidad de deuda y el tipo de deuda (revólver, basado en activos o no garantizados). La tabla de límites es incluso explícita en cuanto a qué deuda se pagará y cuándo. Una vez que todo esto se ha decidido formalmente, se lanza un proceso estructurado para aumentar la deuda.
Los prestamistas analizan la capacidad de una entidad para pagar sus deudas a través de evaluaciones de la historia de la devolución de la deuda, las calificaciones crediticias y la calidad de las garantías que la respaldan. Sin embargo, ninguno de este proceso formal, cuantificación y cierre de sesión ocurre cuando se incurre en deuda técnica. Echemos un vistazo a cómo y por qué ocurre esto a través de los procesos en los que se incurre en deuda técnica:

Las limitaciones de tiempo llevan a un compromiso

El tiempo de comercialización es todo en los negocios. Implementar nueva tecnología es mucho más rápido de hacer cuando se puede hacer de forma independiente. Desafortunadamente, las implicaciones de esto son que otros sistemas no están sincronizados con la implementación. Para las organizaciones delgadas con una tecnología simple, esto puede no parecer tan malo.

Sin embargo, se vuelve problemático a medida que las configuraciones del sistema se multiplican en su complejidad. Al final, la tecnología automatiza los procesos y captura los datos que se transforman en información. La tecnología que no está integrada da como resultado procesos comerciales que no funcionan juntos y múltiples versiones de la verdad.

Cuando se sacrifica el tiempo de velocidad, los protocolos de prueba establecidos pueden ignorarse o recibir una exención. Esto generalmente provoca “errores” en el camino que se manifiestan en alguna forma de degradación del sistema y la distracción del tiempo del desarrollador para arreglarlos.
Si observamos el efecto de la deuda tecnológica a lo largo del tiempo, cuanto más tiempo se deja sin tocar, mayor será la magnitud del efecto. Lo que comienza como un ejercicio de refactorización de código pequeño puede convertirse en un esfuerzo completo de modernización y reemplazo.
una ilustración gráfica de los pasos para administrar la deuda técnica a lo largo del tiempo

La tentación del ahorro de costos a corto plazo

Seamos realistas: los equipos ejecutivos están bajo presión constante para alcanzar los números. Evitar gastar hoy puede ayudarlo a ganar el trimestre, pero, como pedir prestado, tiene que devolverlo en algún momento. Estas son algunas formas en que las empresas ahorran dinero a corto plazo pero terminan generando deuda técnica:

Actualizaciones de software

A veces el costo y el problema de implementar una actualización periódica de software puede provocar que se retrase. En ocasiones, esto continúa por años. Todos somos culpables de dejar de usar Microsoft AutoUpdate cuando aparece en momentos inoportunos.
Cuando los sistemas terminan estando muy por detrás de su versión actual, el software más nuevo que tiene que integrarse simplemente no puede. Además, la actualización de varias versiones a la vez suele ser más costosa y casi siempre requiere más tiempo que mantenerse al día.

Reemplazo de hardware

A medida que las organizaciones crecen en complejidad, el gran esfuerzo de sincronizar los ciclos de actualización de hardware puede ser abrumador y costoso. Esto puede hacer que el hardware actual se alargue al extremo y que existan grandes disparidades entre la calidad del hardware entre los equipos. Algunos equipos se sienten frustrados, compran hardware nuevo y simplemente lo gastan a través del presupuesto de su escritorio en lugar de esperar a que la TI instigue las actualizaciones.
Esta disparidad tiene implicaciones para la productividad y la compatibilidad de hardware/archivos para ejercicios de colaboración.

Tácticas para abordar una situación de deuda técnica

En lugar de solo hablar sobre problemas, aprendamos algo de proactividad y recetemos algunas soluciones para resolver la deuda técnica.
Para eso, podemos recurrir a las técnicas utilizadas para administrar la deuda financiera. Para administrar sus pasivos, primero necesitar saber cuántos son y sus condiciones de pago. Vamos a trabajar en esto para la deuda técnica.

1. Calcula qué y cuánto deudas técnicas tienes

La deuda financiera viene en tramos que se definen por la antigüedad de cada pieza (por ejemplo, senior, entresuelo o revólver), que a su vez muestra cuál es la que se paga primero. La deuda técnica tiene un patrón similar de antigüedad; para empezar, debe comenzar con sus sistemas de misión crítica. ¿Qué deuda técnica tienen? Luego, observe el ecosistema más amplio: mejor, ¿qué deuda técnica entre tus sistemas está causando gastos?
No compliques demasiado este proceso. En algún momento querrás llegar a una evaluación de arriba a abajo, pero no tiene que comenzar allí. Haz que tu jefe de IT reúna a tu equipo administrativo con esta tarea:
“Si hubiéramos aclarado por completo toda nuestra deuda técnica hace un año, ¿cómo podría haber sido mejor este año (o este próximo año)?”
Obtén tus diez mejores ideas y colócalas en una matriz de 2x2: fácil/difícil de pagar en un eje y grado de beneficios en el otro. Esperemos que lo visual te ayude a descubrir por dónde empezar.

 

A partir de ahí, practica para validar tus suposiciones sobre el tamaño del premio y el esfuerzo. La neutralidad es la clave aquí, así que ten cuidado con los proveedores de software que ofrecen realizar una “evaluación gratuita”.

2. Decida qué hacer

Una vez que sepas qué deuda técnica tienes, ahora debes decidir cómo manejarla. Hay muchas opciones para tomar.

En última instancia, puede ser mejor no hacer nada. Para la deuda que se evalúa como “pequeña” o con “tasa de interés baja”, puede ser óptimo simplemente dejarla, del mismo modo, si existe una “penalidad por pago anticipado” significativa de cancelarla anticipadamente. También podría haber ventajas estratégicas también. Estar una versión atrás y permanecer allí suele ser bueno y, a veces, tiene la ventaja de dejar que los problemas se solucionen en la moneda de otra persona.

Pagar o reducir la deuda técnica implicará reemplazar los sistemas y asumir el costo. Esto se puede hacer de inmediato o con el paso del tiempo a través de un proceso de mejoras graduales. Al igual que con la deuda financiera, existen formas creativas en las que puede “refinanciar” la deuda técnica, y la externalización del mantenimiento es una de ellas. En última instancia, puede costar más resolverlo, pero puede extenderse para reducir el costo inmediato y, a través de los principios de la división del trabajo, delega la tarea a una entidad más especializada.

La llegada del software basado en la nube y los servicios de hardware también ofrecen una comparación con la popularidad de las finanzas basadas en arrendamiento. El uso de servicios en la nube también es una herramienta efectiva para reducir la deuda técnica, tanto para eliminar los requisitos de CAPEX como para cambiar el enfoque de desarrollo hacia el proveedor de la nube.

3. Crear un plan de pago

No te sientas abrumado por el costo de reducir tu deuda técnica y no intentes pagarla toda de una vez. Este sería un ejercicio ambicioso que podría abrumar a una organización de cualquier tamaño o balance.

Nuevamente, volviendo a las comparaciones financieras, ten la mentalidad de pagar primero la tarjeta de crédito con la tasa de interés más alta. Esto simplemente significa atacar actividades de alto valor/bajo esfuerzo primero.

En la sección anterior, discutí las diversas formas de abordar la deuda técnica. Al evaluar el costo de cada uno, es mejor realizar un ejercicio de comparación. La clasificación del costo del flujo de efectivo de cada resultado potencial puede permitir a los interesados tener una visión clara de las ventajas y desventajas de cada camino. Un ejemplo de tal visual se incluye a continuación.

un gráfico de barras que muestra una comparación de flujo de caja de ejemplo entre varios proyectos técnicos de reducción de deuda

Esta comparación muestra el trade-off que existe entre una resolución teórica y el marcado contraste entre resolver el problema y no hacer nada (“línea de base existente”). En este ejemplo, pasar a una nube, la solución basada en SaaS sería la opción más económica para el negocio.

Gestión de la deuda técnica en el futuro

Una vez que hayas establecido tu línea de base y tu plan de ataque, querrás preservar esa visibilidad y evitar que la nueva deuda se arraigue. Piensa en el ejercicio como un nuevo comienzo y la oportunidad de implementar las mejores prácticas para evitar problemas. escalando de nuevo en el futuro.

Implementar una declaración de divulgación de préstamo

La mayoría de los proyectos de tecnología tienen un proceso formal de aprobación completo con un patrocinador ejecutivo, un objetivo de alto nivel, beneficios anticipados, un cronograma y, por supuesto, costos. Este es un gran lugar para eliminar nuevas deudas técnicas que se incurrirán y la justificación de la misma.

Establecer umbrales de endeudamiento

No te excedas demasiado estableciendo nuevos estándares. Del mismo modo que emites tarjetas de crédito corporativas con límites preestablecidos, no deseas sobre-administrar la deuda técnica. Muchas deudas técnicas son pequeñas y están relacionadas con la escritura de códigos que se amortizarán rápidamente. Esto es particularmente cierto con el desarrollo ágil. Confía en tu jefe de IT para establecer y controlar este umbral.

Volver a capacitar a tus suscriptores

En las empresas más grandes, IT tiene un proceso llamado “gestión del cambio”. Antes de que el nuevo software se active, generalmente pasa por la administración del cambio. En términos simples, cambiar el trabajo de la administración es garantizar que los nuevos cambios en el sistema tecnológico de la empresa no afecten a otros sistemas. Lo hacen asegurando que el nuevo sistema cumpla con los métodos y procedimientos estandarizados. Considera usar este proceso para prevenir o, al menos, identificar nuevas deudas que se introduzcan.

La deuda técnica es un costo real de hacer negocios y una causa real de interrupciones en los sistemas y un lastre para la agilidad general de la compañía. No tiene que ser una carga constante, sin embargo, y los CFO inteligentes sabrán cuánto endeudamiento tecnológico tiene tu organización tiene y lo que tomará para optimizarlo.

https://www.toptal.com/finance/part-time-cfos/las-implicaciones-financieras-de-la-deuda-tecnica/es

miércoles, 16 de mayo de 2018

Mapeo Wireframe: Cómo Evitar El Atraso de los Scope

by Frauke Seewald - Designer @ Toptal (translated by Yesica Danderfer)

Imagina esta situación: Estás trabajando en un nuevo sitio web y en el proceso de creación de los wireframes. En tus reuniones de revisión, recibes comentarios de su cliente y equipo, prefaciando la generación inevitable de solicitudes de cambios, sugerencias de mejoras y actualizaciones. Después de varias reuniones de revisión, te sientes como si estuvieras atrapado en un bucle sin fin, los cambios se están haciendo y revirtiendo, la demanda de tu cliente para más características parece seguir para siempre, y llegar a un acuerdo parece imposible.

O, tal vez, ocurre lo contrario: presentas tus wireframes, todo el mundo asiente con la cabeza de acuerdo, y los wireframes están bien para pasar a la siguiente etapa. Pero, a medida que el trabajo avanza, te das cuenta de que no refleja tu intención-más características están siendo abarrotadas y el flujo se siente.

¿Que pasó? La respuesta es simple: falta de comunicación.

Comunícate más Eficazmente con tus Wireframes


Una de nuestras principales herramientas de comunicación como diseñadores de UX son los wireframes, los “blueprints” en blanco y negro que nos convierten en los arquitectos del diseño web. Aunque los wireframes carecen de los detalles coloridos del diseño visual, son la base para el diseño del producto, del mismo modo que los planos arquitectónicos son la base para la construcción final de un edificio.

Los wireframes son más que un mapa estático. Usando la analogía de una casa, no sólo muestran una habitación, sino más bien toda la casa y todas las diferentes maneras que un usuario puede mover a su alrededor. También incluyen el interior, definiendo el propósito principal de cada habitación.

Además, los wireframes muestran más que sólo habitaciones. Ayudan a planificar los viajes y definir la experiencia que un visitante tendrá en un paseo por la casa. Puedes usar wireframes para muchas cosas, y son muchas cosas que tu equipo y cliente necesitarán entender a medida que un proyecto evoluciona. Parte del trabajo de diseñador de UX es ser traductor, asegurando que todos los involucrados comprendan la visión prevista.

Llevando tus Wireframes al Siguiente Nivel con un Mapa de Wireframes


Entonces, ¿cómo comunicamos el viaje del usuario? ¿Cómo se puede mapear la experiencia del usuario de una manera que sea fácil de leer para que tu equipo y tu cliente pueda visualizarlo? ¿Cómo puedes asegurarte de que el viaje siga siendo sencillo y ofrezca todos los elementos necesarios para cada habitación sin crear barreras frustrantes?

Aquí hay una herramienta útil para comunicar y organizar tus wireframes con mayor eficacia: un mapa wireframe.

Un mapa wireframe es una forma de hacer coincidir tus wireframes con el sitemap de tu sitio web (o con los flujos de usuario de tu producto). Para este proceso de asignación, necesitas plantillas de estructura de wireframes que representen un tipo de página específico (por ejemplo, página de formulario vs. página de destino vs. página de lista de productos vs. página de detalles del producto).

Es como decidir el propósito de cada habitación en una casa primero, que luego determina los elementos dentro de cada habitación. Una plantilla sería un cuarto de baño con un inodoro y un fregadero como elementos de contenido común.

La creación de un mapa wireframe le beneficiará de varias maneras:
  • Ayuda a estimar el alcance del proyecto (¿Cuántas plantillas de wireframe necesito?)
  • Proporcionar una visión general de todas las plantillas diferentes que deben crearse (que también puede ser valioso como un índice para un estilo, o una simple lista de verificación para identificar plantillas que pueden ser reutilizadas para otras páginas)
  • Mejorar la comunicación con respecto al objetivo de sus wireframes y ayudar a sus clientes a entender mejor el viaje del usuario

¿Cómo Crear un Mapa de Wireframe?


Hay tres pasos involucrados en la creación de un mapa wireframe.

Paso 1: Identificar Elementos de Contenido

Antes de empezar a bucear en wireframes, es útil pensar en todas las diferentes piezas que necesitan vivir en un wireframe, como los elementos que desea tener en cada habitación para decidir cuán grande debe ser su habitación. Para un sitio de comercio electrónico, los ejemplos pueden ser: barra de búsqueda, filtrado de productos, descripción del producto, imagen del producto, precio, selector de cantidad, botón ‘añadir al carrito’, productos recomendados, icono del carrito de compras … Considerando los componentes de IU necesarios.
  • Comienza a enumerar todos los elementos de contenido (componentes) en los que puedas pensar: piensa en la funcionalidad que desea ofrecer para ayudar al usuario a avanzar y cumplir con los requisitos del negocio.
  • Agrega otra columna para el tipo de página (por ejemplo, la página de detalles del producto, el carrito de la compra, la página de destino, etc.) para agrupar los elementos de contenido.
  • En una tercera columna, clasifica sus artículos de contenido por importancia (es decir, bajo, medio, alto).
  • Si tienes historias de usuarios, puedes agregar otra columna para referirte a los números de historia relacionados.

Lista de elementos de contenido para un mapa wireframe
Un ejemplo de una lista de elementos de contenido

¿Por qué es útil la clasificación de los elementos de contenido? Tiene dos propósitos principales:
  1. Creación de una jerarquía: El ranking define la jerarquía de contenido de cada página y le da una guía para sus wireframes (qué contenido debe estar en la parte superior).
  2. Evitar el desorden: Priorizar los elementos de contenido ayudará a mantener el enfoque minimalista, así como ayudarte a tomar decisiones con ty equipo sobre qué contenido realmente necesita.
Los elementos de contenido definen el ámbito del trabajo. Tener una lista de elementos de contenido te ayudará a pasar a la fase de planificación más fácilmente y se puede utilizar para definir el proceso y estimar el trabajo de los wireframes. (Por ejemplo, ¿cómo estructuramos nuestros sprints?, ¿qué contenido abordamos primero?)

La lista de contenido también es muy útil durante cualquier discusión con respecto a los requisitos. Puede identificar fácilmente los elementos de contenido que acordó y qué elementos adicionales se solicitan y se consideran una solicitud de cambio.

Paso 2: Definir el Mapa del Sitio y los Flujos de Usuario

Tienes los elementos de contenido que necesitas proporcionar y los agrupas en páginas. Echemos un vistazo a una visión general por ponerlos fuera. ¿Cómo están interconectados? ¿Cómo navega un usuario a través de ellos para lograr sus objetivos?

Llega a este nivel creando un sitemap (para sitios web) o un flujo de usuario (para aplicaciones):
  • Mapa del sitio: Muestra una visión general de todas las páginas y su jerarquía.
  • Flujos de usuario: Visualiza cómo se interconectan las páginas para los escenarios clave de casos de uso.

Mapa de sitio y flujo de usuario
Versión simplificada de un mapa del sitio y del flujo de usuario
 

Paso 3: Mapea tus Wireframes

Ahora que ya sabes qué contenido debe proporcionar, en qué páginas debe proporcionarlos y cómo están conectados, puedes empezar a trabajar en tus wireframes.
  • Define las plantillas de página que necesitan wireframes basadas en el mapa del sitio y los flujos de usuario. (Cada página que requiera funcionalidad única va a ser una plantilla diferente).

Plantillas de wireframe
Plantillas de alambre que representan páginas únicas
 
  • Si encuentras variaciones menores para determinadas plantillas (por ejemplo, una página de contenido con un control deslizante en el encabezado o no), trabaja en páginas maestras y omite estas variaciones menores. Tus wireframes deben incluir todos los componentes principales que vivirían en esta plantilla de página maestra.
  • Ahora traza sus wireframes al mapa del sitio y los flujos de usuario. Puedes actualizar tu sitemap con miniaturas de wireframes para cada tipo de página. La codificación de colores o la numeración mantendrán las cosas en sincronía, ayudarán a dar una mejor visión general y ayudarán a los clientes a entender qué wireframes necesitan.

A color-coded sitemap
Un ejemplo de mapa de sitio con código de color
 
Plantillas de wireframe con código de colores
Un ejemplo de mapa de sitio con código de color
 
Plan de sitio con códigos de colores y plantillas de wireframes
Un ejemplo de un mapa de plantilla wireframe. El mapa del sitio está a la izquierda y los wireframes están a la derecha con los códigos de color correspondientes.
 
Mapa del sitio numerado y wireframe
Para sitios muy complejos, un sistema de numeración puede tener sentido frente a la codificación de color
 
¿Por qué es útil este proceso de mapeo? Es una gran herramienta para usar al crear la visión general de alto nivel de un proyecto. En lugar de simplemente mirar los wireframes autónomos página por página, el mapa wireframe le permitirá a ti y a tu equipo ver los wireframes en su contexto. ¿De dónde vienen los usuarios? ¿A dónde van ahora?

Para volver a la analogía de la casa, es el plano que se crea para visualizar la estructura de la casa, en consecuencia pasar a mirar las primeras representaciones de cada habitación (que son los wireframes para cada plantilla de página), y luego para compartir el resultado final y la visión general.

Llevando el Flujo de Trabajo de Wireframe al Siguiente Nivel

En resumen, aquí es por qué los mapas de wireframe son una comunicación útil y una herramienta de organización:
  • Ayudarán con la planificación. (¿Qué contenido tenemos y qué wireframes necesitamos?).
  • Serán útiles como una lista de verificación durante el proceso de creación del proyecto. (¿Qué componentes puedo reutilizar para mantenerme constante?).
  • Ayudarán con la estimación de costo y tiempo del proyecto, así como para reducir las ineficiencias.
  • Te ayudarán a rastrear tus tareas (trabajo completado vs. trabajo todavía en el backlog).
  • Te ayudarán a comunicar mejor el propósito y el objetivo de sus wireframes durante las revisiones (como los wireframes se están utilizando para el proyecto en general).
Un mapa de wireframes es una herramienta útil para estimar el alcance del trabajo al principio de un proyecto, y como una lista de verificación a través de su proceso de trabajo. Ayudará a mejorar el proceso de toma de decisiones de tu equipo, mantendrá a todos en la misma página y periódicamente los reenfocará en la visión general de alto nivel del proyecto. ¡Feliz mapeo!

 https://www.toptal.com/designers/wireframing/mapeo-wireframe-como-evitar-el-atraso-de-los-scope/es