Hacer bien producto digital pasa por entender la propia naturaleza del software. A pesar de ser su principal material, la mayoría de las veces es ignorado, cuando no malinterpretado. El software no es madera, ni su tratamiento es el que históricamente hemos llegado a elaborar en torno a la arquitectura y otras disciplinas con los que operamos en el mundo no digital. Parece que muchas veces es lo que nos gustaría que sucediera, pero la realidad es tozuda y siempre nos acaba haciendo ver que ese marco no encaja. (View Highlight)
Nuestro cerebro todavía no asimila bien que algo que proyectamos no se materialice de forma prácticamente idéntica al modelo. Las compañías que inventan productos digitales se enfrentan constantemente a este reto y el anecdotario de situaciones divertidas, a pesar del fondo dramático sobre el que muchas veces tienen lugar, es realmente abundante y rico: diseños que persiguen un color exacto y que acaban teniendo distintas modulaciones en función del monitor y la configuración; disposiciones visuales que persiguen un determinado efecto y que acaban teniendo un resultado distinto o simplemente aparecen rotas en función de una determinada resolución, un cierto tipo de dispositivo, o una versión de cierto programa dentro de cierto tipo de dispositivo; flujos de interacción, que involucran datos y comunicaciones, que nunca llegan a sus destinatarios bien porque dependen de algo que estos deben activar, bien porque dadas ciertas condiciones de ambiente —red, localización, momento del día— no tienen lugar; experiencias diseñadas, donde puede llegar a intervenir la imagen, el movimiento y el sonido, que no tienen el desenlace esperado o lo tienen solo parcialmente, porque algo no va bien en el sistema, es decir, en el conjunto de todas las condiciones que tienen que darse. (View Highlight)
El cerebro entrenado en bellas cadenas de montaje donde el encaje de elementos en la entrada acaba dando la salida prevista —desde un automóvil a una hamburguesa— vive aquí su primera crisis. Y las personas no pueden dejar de tener que responder a ese colapso: a veces sencillamente se fugan —la realidad está mal o todavía no está lo suficientemente bien— y otras arrastran la carga de malvivir con algo que siempre produce insatisfacción. (View Highlight)
Los productos digitales nos acercan a lo que solemos vivir con nuestro propio cuerpo: pasan cosas dentro que no podemos entender atendiendo exclusivamente a nuestra epidermis. ¿Acaso no sucede que una analítica clínica —métricas de producto— te da valores correctos pero cuando te operan —te abren— descubren algo distinto a partir de una información que se ha hecho visible? (View Highlight)
Esta naturaleza de caja negra es algo que puedes experimentar con frecuencia. Por ejemplo, los errores en los productos digitales están totalmente normalizados. También, el hecho de no poder explicar satisfactoriamente por qué suceden. En ocasiones se alcanzan explicaciones superficiales, pero es muy común abandonar la aspiración de dar con la causa raíz, porque el esfuerzo no merecería la pena, pero también porque sobrevuela la sospecha de algo multifactorial que ni siquiera se podría rastrear correctamente en un sistema opaco. (View Highlight)
La información en los productos digitales es inherentemente dinámica. A diferencia de otro tipo de productos, donde la información suele ser estática una vez impresa o grabada, en el software los datos y las estructuras están en constante flujo. Empezar a desarrollar suele ser también el momento de descubrir que algo no estaba como pensabas; que algo cambió en algún momento sin que lo tuvieras en cuenta; o que algo directamente dejó de funcionar. (View Highlight)
Las ramificaciones son otro aspecto singular del software que suele sorprender a quienes no están familiarizados con su naturaleza. Un cambio aparentemente simple puede desencadenar un racimo de efectos inesperados en otras partes del sistema. Esto se debe a la compleja interconexión de los componentes y a la naturaleza dinámica de la información que maneja el software. (View Highlight)
En la práctica tiene tanto peso, en muchas ocasiones psicológico, que las expresiones habituales cuando se está incorporando algo nuevo al producto son de estilo cauteloso en la forma de “en principio no debería afectar”. La proliferación de métodos para hacer despliegues progresivos —por porcentajes, cohortes, o directamente por feature flag— es otra buena confirmación de lo interiorizado que está este fenómeno, puesto que el foco no está en cómo conseguir que no suceda sino en desplegar una red de seguridad puesto que se sabe que va a suceder en algún grado. (View Highlight)
Cuando el único límite es tu imaginación, es fácil que la exuberancia te confunda. Los productos digitales contienen una cierta promesa de economía de la abundancia que tiende a despreciar lo que la economía tradicional, una economía de la escasez, ponía en valor. Sabemos que este tipo de productos no suspende las lógicas que ya conocíamos, así que posiblemente se trata más de un problema de percepción que de cambio real. (View Highlight)
La maleabilidad del software sí es un hecho, para empezar por su propio propósito general. Esta plasticidad es algo que puedes comprobar a menudo, especialmente cuando se plantea una funcionalidad con un enfoque de reunir el conjunto integral de sus piezas para llevarlas a ejecución, y las propias piezas se van convirtiendo en nuevas posibilidades que engendran otras, y estas otras, y estas otras, en una secuencia abierta. En la industria es habitual utilizar expresiones del tipo “diseñar a máximos” para referirse a este tipo de situaciones. (View Highlight)
En primer lugar, sabemos que desde los años 30 del siglo XX se empiezan a formular planteamientos que se denominan Iterative and Incremental Development. Nacen de algunos ingenieros dedicados a la calidad, que empiezan a mostrar preocupación por algunas situaciones y proponen distintas soluciones. Ya en los años 50 y 60 se están aplicando este tipo de enfoques iterativos e incrementales en proyectos en organizaciones tan significativas como la NASA e IBM. (View Highlight)
También sabemos que hacia los 70 ya se había consolidado el debate entre este tipo de metodologías y aquellas que acababan agrupadas bajo la etiqueta de “desarrollos en cascada”, que se consideraban la forma estándar, puesto que importaban estilos de gestión que ya se conocían anteriormente y que se habían popularizado con la revolución de las organizaciones industriales y la gestión de proyectos. (View Highlight)
Los objetivos en la gestión solían relacionarse con cumplir plazos y costes, y en muchos aspectos sigue siendo una perspectiva dominante aún hoy. Las compañías también suelen tener una predisposición para promocionar el pase de testigos como si se trataran de cadenas de montaje que en vez de unir planchas y tuercas, unen piezas de software. (View Highlight)
A medida que se fueron consolidando este tipo de enfoques, fue cogiendo peso la línea que buscaba nuevas formas de programar y de organizar a los equipos en torno a la programación. En los años 90 se empiezan a publicar introducciones a la corriente conocida como extreme programming. Es el momento en el que el terreno de la programación ya empieza a mezclarse con un vocabulario que hasta entonces había permanecido en los márgenes, o directamente no había existido: la evaluación del éxito ya no venía por el cumplimiento de tiempos y costes sino por la propia satisfacción de los clientes. (View Highlight)
El cliente pasa a ser protagonista así como los equipos colaborativos. (View Highlight)
Finalmente, ya hacia la década que inaugura el año 2000 se publica el famoso Manifesto for Agile Software Development, con la firma de relevantes programadores. Sabemos, por lo tanto, que los distintos enfoques y formas de trabajar con el software nacían de las mismas personas que mejor lo conocían. En este momento, los tiempos y los costes han desaparecido ya por completo como principales objetivos, y en su lugar cogen protagonismo, entre otros, la colaboración con los clientes y la capacidad para responder al cambio.
(View Highlight)
Hoy ya manejamos como moneda común, especialmente cuando nos centramos en tácticas alrededor del desarrollo de productos digitales, cosas como los desarrollos atómicos, las técnicas de slicing, la entrega continua, las implementaciones iterativas, los despliegues progresivos y, en general, una caja de herramientas que se mantiene viva a través de aportaciones constantes. (View Highlight)
Ese giro hacia los clientes, incluso situándolos en un plano de colaboradores, añadió una nueva capa de complejidad a esa otra del software en la que nos hemos centrado hasta ahora. En primer lugar, porque se sumaba otra incógnita: ¿cómo llegar a saber quiénes son esos clientes? Cuanto más capacidad y relevancia han ido ganando los productos digitales, mayor número de usuarios y clientes los utilizan. Actualmente, puedes decir sin miedo a exagerar que la magnitud de algunos productos tiene el mismo impacto que realidades no digitales tan relevantes como, por ejemplo, la organización del tráfico. (View Highlight)
Actividades como el user research fueron surgiendo como una forma de ir despejando esa incógnita, al mismo tiempo que se incorporaba capacidad analítica para cuantificar comportamientos a través de interacciones. A través de un conjunto de atributos —clicks, visitas, funnels, sesiones, etc.—, conversaciones, encuestas, ejercicios de user testing y otras técnicas de una caja de herramientas que se ha enriquecido a lo largo de los años, intentamos satisfacer esa aspiración tan repetida de poner a las personas en el centro, y de ponerlas con cierta certeza de que no son directamente una invención nuestra. No es raro que muchas veces todo termine en una ilusión: las compañías haciendo de ventrílocuos, poniendo sus demandas en boca de esos clientes desconocidos. (View Highlight)
Artículo influyente de Gould y Lewis subrayando el enfoque temprano en las personas y sus tareas, la evaluación empírica y el diseño iterativo. (View Highlight)
Además, con la apertura a los clientes vino una reformulación de los problemas, que fueron pasando de considerarse proyectos consistentes en un conjunto de requisitos y una secuencia de tareas, a enfrentarse a lo que los científicos sociales suelen denominar problemas complejos, pero que también desde la perspectiva del design thinking se ha verbalizado como problemas perversos, retorcidos o también débilmente definidos (wicked problems). Un tipo de desafíos que carecen de soluciones o límites claros; que no tienen una respuesta definitiva ni suelen darse en una formulación clásica, y sus posibles soluciones no son enumerables. (View Highlight)
Artículo de Buchanan donde reflexiona sobre la importancia de lo problemas débilmente definidos en design thinking. (View Highlight)
Después de todo, este es el terreno en el que se mueven muchas de las cosas que intentamos resolver, y en el que tanto participan las ciencias sociales (¿cómo podemos resolver el envejecimiento de la población? ¿cómo podemos reducir el fracaso escolar? ¿cómo podemos reducir el impacto medioambiental?). Aunque en los productos las preguntas suelen ser más modestas (¿cómo podemos conseguir que los clientes mantengan más tiempo la suscripción? ¿cómo podríamos dar una mejor experiencia?), comparten esa naturaleza de pregunta abierta: tanto porque no siempre se está de acuerdo en que haya realmente un problema —es difícil que haya un hecho tan obvio que genere un consenso total— como porque nunca se aspira a eliminarla por completo, sino a moverse con indicadores relativos (un buen progreso es conseguir un 5% más de clientes que renuevan su suscripción). (View Highlight)
Así que pasado ya el siglo XX los productos digitales no solo han afrontado numerosos retos relacionados con lo que era su material principal, el software, sino que además han incorporado, en su consolidación como parte relevante de la actividad económica, otros retos que los acercan a otras muchas actividades humanas en las que nos orientamos a través de conjeturas, arañamos un poco de hechos patentes para sacar consecuencias y nos las vemos con el riesgo y la incertidumbre. Algunas nuevas metodologías, como la de Jobs To Be Done, quieren ser una forma de reducir esos nuevos desafíos, incorporando contexto real y situaciones concretas como una forma de minimizar esa indefinición de límites. (View Highlight)
Es fácil ver que el producto digital se ha hecho adulto, aunque con frecuencia las organizaciones que los inventan no sigan el mismo ritmo de madurez y lo sigan tratando como a aquel crío que era meramente un recurso técnico. Hay mucho margen de mejora en organizaciones que cuidan la cuenta de resultados o el modelo de negocio, pero que tratan el producto, que es la fuente de esas finanzas, o bien a través de peticiones o bien a través de grandes corazonadas volcadas en un backlog. Una incidencia de contorno estrecho no puede gestionarse igual que una decisión estratégica, como tampoco se trata igual el arreglo de un asiento en un tren y el rediseño de la propia red ferroviaria. En muchas compañías los asientos y las redes ferroviarias se confunden, y se tiende a intentar resolver ambos de la misma forma: todo se valora únicamente como cantidad de trabajo hecho sin buscar la correlación con unos resultados esperados. (View Highlight)
Cuanto más fuerte es la relación de una compañía con la invención de producto digital, o lo que viene a ser lo mismo, cuanto más es su negocio el propio producto, más se ve afectada por estos aspectos que acabamos de recorrer. Cuando no incorpora esta reflexión, a menudo malvive porque trabaja en un marco incorrecto. Por lo tanto, ni se da, como organización, la forma adecuada de pensarse, ni ofrece a las personas que la conforman el entorno en el que podrían ser más productivas. (View Highlight)
En primer lugar, a este tipo de compañías les sienta mal inventar a partir de proyecciones de alta fidelidad. Si el Figma es el punto de partida y además alguien lo valida, ya sea el CEO —algo todavía más común de lo que suele pensarse— o cualquier otra figura directiva, es muy alto el peligro de deslizarse por la pendiente de desarrollos que parecen no tener fin. Igualmente, el riesgo de tener poca velocidad (a veces la discusión queda secuestrada en el propio Figma). Asimismo, tendrá que apuntarse en el debe mucha frustración y pérdida de talento en sus equipos, puesto que ese resultado final, proyección de ese diseño a máximos en alta fidelidad, nunca podrá alcanzarse tal como se imagina, porque como hemos visto no existe esa correspondencia unívoca entre entrada y salida. (View Highlight)
Los productos digitales tratados como cadena de montaje suelen acabar siendo engendros. (View Highlight)
Son compañías, por lo tanto, a las que les sienta bien el punto gordo —baja fidelidad— y tocar para entender. O también, validar para reducir riesgo. Necesitan fomentar el ir a lo real para poder formarse una opinión. No es raro, en consecuencia, que les favorezca un estilo donde predomina el hacer cosas y compartirlas lo antes posible para ver qué tal son recibidas; el involucrar a los potenciales usuarios y clientes en el propio proceso de invención para incorporar aprendizaje lo más pronto posible; así como el insistir en que el ritmo, en sí mismo, es un valor positivo (el mantra speed wins es posiblemente el que mejor sintetiza esa orientación). Tocar para entender también significa que son organizaciones que malviven cuando no tienen interiorizado este material con el que trabajan: el negocio que puedes imaginar también está en función de tu comprensión de, por ejemplo, cómo funciona una petición en un navegador. (View Highlight)
El cliente pasa a ser protagonista así como los equipos colaborativos. (View Highlight)
Artículo influyente de Gould y Lewis subrayando el enfoque temprano en las personas y sus tareas, la evaluación empírica y el diseño iterativo. (View Highlight)
Artículo de Buchanan donde reflexiona sobre la importancia de lo problemas débilmente definidos en design thinking. (View Highlight)
Los productos digitales tratados como cadena de montaje suelen acabar siendo engendros. (View Highlight)
(View Highlight)