• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

Producto

¿Qué es la transformación digital?

No importa si llevas tiempo en este sector de la Tecnología o si estás acercandote por primera vez. La transformación digital es un hecho. Todo el mundo habla de ella.

Todas las organizaciones están invirtiendo en su estrategia digital, empleando miles de profesionales para ello. Si preguntáramos a una selección de estos miles ¿Qué es la transformación digital? posiblemente obtendríamos respuestas muy dispares.

La irrupción de la Informática

No hace tanto tiempo -el suficiente para que los más jóvenes no se acuerden- llegaron los primeros ordenadores a las empresas en España.

Un antiguo presidente de una empresa cotizada del IBEX me contaba que hicieron una gran inversión en la compra de equipos informáticos allá por 1987 o 1988 sólamente para darse cuenta que no había nadie en la fábrica que supiera usarlos.

En no pocas ocasiones, las organizaciones se subieron al carro de la informática más por moda que por necesidad. Sin embargo, la moda fue calando y en pocos años no había una empresa en la que todos los empleados no tuvieran un ordenador para realizar su trabajo diario.

En 1987 mi padre aquirió un Amstrad 1512 con 512Kb de memoria y sin disco duro que dió 11 años de servicio y en el que por primera vez tuve la oportunidad de enfrentarme a retos con LOGO y QBasic -además de darme la oportunidad de probar todos los juegos de la época-. Aprender fundamentos de programación fue algo que cambiaría mi vida para siempre.

Pertenezco a la ultima generación de la historia que sabe que es vivir sin internet.

Los departamentos de informática empezaron a crecer al mismo tiempo que decrecían muchos trabajos manuales, como el de los contables, los administrativos o las secretarias de dirección. Un nuevo mundo se abría.

Por primera vez éramos capaces de analizar datos rapidísimamente, escribir textos fácilmente editables o hacer consultas a bases de datos de clientes estando a cientos de kilómetros de distancia. Había comenzado una nueva era, una en la cual el conocimiento era más valioso para la gran mayoría de la fuerza laboral que la capacidad manual de hacer determinadas tareas.

Negocio e IT se separan

El departamento de informática, estratégicamente situado lejos de la vista de los transeuntes -lleno de monitores y teclados viejos- recibía cada vez más peticiones para hacer cosas más y más complejas.

Ya no se trataba de informatizar pedidos, sino de automatizar todo el proceso de pedido. Más tarde el de producción. Y todo mientras se actualizaban los balances y las cuentas de resultados sin necesidad de un contable.

Durante los 90, a informática se le dió un nuevo nombre: Tecnologías de la Información y la Comunicación (TIC). El trabajo ya no consistía en el mantenimiento de equipos o la entrada de datos, sino que también incluía redes, servidores y programación. Eso provocó un importante crecimiento en el personal dedicado a esta labor.

El departamento se mudó a otra planta, o incluso a otro edificio y se contrataron directores y ejecutivos que se aseguraran que todas las peticiones salían adelante. Los informáticos eran gente extraña, siempre ponían problemas a todo.

Al abrigo de este crecimiento emergió un nuevo tipo de compañía de servicios, la que proporcionaba apoyo técnico a organizaciones que ya existían para momentos puntuales o proyectos específicos de alta carga.

La premisa era la siguiente: No es necesario que contrates a todos estos ingenieros ya que una vez que completes tu proyecto no los vas a necesitar. Nosotros te proporcionamos el know-how, la fuerza laboral que necesitas y tu sigues en control de tu negocio. Era una propuesta de valor sólida.

OPEX y CAPEX

Al comienzo del nuevo milenio y con la burbuja punto com a punto de ser dinamitada, las compañías empezaron a mirar a sus balances buscando maneras de mejorar sus beneficios sin necesidad de reducir su competitividad.

Una nueva hornada de ejecutivos que habían crecido en los 70 y estudiado MBAs tomaba el mando para dar un nuevo rumbo a estas organizaciones. Lo primero que hicieron fue preguntar y profesores cómo hacerlo. Había una forma de incrementar los beneficios mágicamente.

Si tenemos una empresa y compramos un vehículo, no podemos deducir al gasto de la compra inmediatamente. Dado que le vamos a dar uso durante varios años, las normas contables exigen que cada año nos deduzcamos un poco de ese gasto, hasta completar la vida útil del mismo.

Cuando una compañía desarrolla una aplicación que le va a permitir gestionar sus clientes durante varios años, sigue el mismo procedimiento. Así que la inversión en los abultados departamentos de informática ni siquiera podía ser deducida como gasto, sino que había que amortizarlo en varios años, lo cual lastraba el beneficio. Este tipo de inversiones se denominan CAPEX.

¿Que ocurre si en lugar de comprar un vehículo pagamos un alquiler todos los meses por el uso de uno? Pues que esa operación pasa de ser inversión a ser gasto y entonces si que lo podemos deducir de forma inmediata. Lo que se conoce como OPEX. ¿Podríamos aplicar la misma lógica a nuestras aplicaciones contratando a una empresa externa que se encargara de nuestro personal y asi mejorar nuestros beneficios? Sí, podemos. Las empresas decidieron externalizar su personal a empresas de servicios y contrataron a esas mismas empresas para continuar desarrollando sus productos. Había nacido el outsourcing.

De aquellos polvos, estos lodos

Esta decisión -aparentemente- no tendría por qué tener un impacto más allá de incrementar el porcentaje de beneficios de una organización. Las empresas conservaron y contrataron Project Managers, especialistas dedicados a supervisar y asegurar que el gasto en TIC estaba bien gestionado. Y durante un tiempo, fue bien.

Sin embargo, tuvo un efecto colateral. Las organizaciones dejaron de conocer las entrañas de sus sistemas y aplicaciones, ya que los que tenían ese conocimiento ahora trabajaban para otros.

La capacidad de negociar se veía mermada. ¿Cómo puedes pedirle algo a quien tiene el verdadero control de tu negocio?

Esta situación provocó que durante años se dedicara poca inversión a sistemas ya obsoletos y que muchas organizaciones fueran totalmente inconscientes del impacto que sus sistemas y aplicaciones tenían en la gestión del ciclo de vida de sus clientes. A pesar de ello, como el mercado estaba dominado por grandes monopolios y oligopolios, no era necesario ser más competitivo que el resto sino al menos tan competitivo como el resto. Y todos hacían lo mismo.

Llegó la crisis

En España y latinoamérica, la crisis financiera del año 2008 impactó con fuerza. La situación histórica de los paises de habla hispana provocó que les fuera mucho más difícil sobreponerse a la crisis que a los anglosajones.

En España no se habló sólidamente del final de la crisis hasta el año 2016. Durante todo ese tiempo, todas las empresas habían recortado a causa de -o usando como excusa- la crisis.

Cuando los presupuestos empezaron a fluir de nuevo hacia el interior de la organización el panorama había cambiado. Los osos despertaban de su letargo para darse cuenta que el bosque que antes conocían ya no les era familiar. Mientras ellos dormían, una generación nueva -los millenials- había tomado el relevo y estaba dándoles a sus clientes lo que necesitaban más rápido, mejor y a una fracción del coste.

Los sistemas obsoletos, en los que se había ahorrado al máximo durante años, hacían que cualquier cambio tomara meses. Mientras, cualquier startup era capaz de implementar esos cambios en minutos. El problema no era tecnológico -o al menos, no sólamente tecnológico-.

Darle la vuelta a esta situación suponía darle la vuelta a todo: Personas, trabajo y tecnología. Si lo pensamos detenidamente, es darle la vuelta a organizaciones que lo que mejor saben hacer es hacer que su manera de trabajar prevalezca y expulsar a todo aquel que no esté contento con el statu quo.

El reto es aceptar que la tecnología ha dejado de ser un centro de coste o algo que mejora nuestra propuesta de valor para abrazar el hecho de que la tecnología es nuestra propuesta de valor. Todo lo que hemos hecho hasta ahora, lo que nos diferenciaba, ya no vale.

Ha llegado la hora de que todas las organizaciones sean tecnológicas.

No hay bancos, hay tecnológicas con licencia bancaria. No hay electricas, hay tecnológicas que operan en el mercado energético. No hay hoteleras, hay tecnológicas que operan en el mercado turístico.

Esto es la transformación digital.

Ciencia de Datos, Producto y Agilidad

Muchas son las empresas que se están amparando en la agilidad para sobrevivir ante un mercado y contexto social cada vez más dinámico y donde la disrupción de tecnologías, nuevos modelos de negocio y gestión del talento han hecho que antiguas mentalidades y formas de trabajo no sean las más adecuadas para estos tiempos.

La agilidad nos lleva a trabajar colaborativamente con equipos multidisciplinares y esto no excluye a disciplinas como la ciencia de datos, que además entendemos estratégica a todos los niveles de una organización. Cada vez son más las empresas que apuestan por obtener valor de sus activos en forma de datos, utilizando el talento de los científicos de datos para impactar considerablemente en el negocio.

Sin embargo, la (relativa) novedad de la ciencia de datos y la cada vez más habitual aplicación de las metodologías ágiles no siempre tienen una convivencia fácil en el contexto de creación de productos.

El objetivo de este artículo es buscar un punto de encuentro entre responsables de producto y los equipos involucrados en la creación de producto, asumiendo que la involucración de la disciplina de datos cada vez va a ser más habitual.

Nos gustaría Identificar y explicar los momentos donde esta disciplina es un factor diferencial en la creación de productos y cómo se podría organizar de forma ágil.

Cada responsable de producto tiene su propia manera de crear productos, basada normalmente en frameworks, métodos, gurús o experiencia (Lean Startup, Design Thinking, Scrum, SAFe, Less, etc) o una combinación de todo lo anterior.

Para evitar que nuestra conversación se focalice en frameworks o métodos, vamos a suponer que independientemente del framework que utilice, un equipo involucrado en la creación de un producto pasaría por ciertos “planos”, que representamos en la siguiente figura.

  • Identificación de oportunidades: Registro de oportunidades que pueden venir  de cualquier miembro o grupo de trabajo de la empresa.
  • Entendimiento de la oportunidad: Entendemos el problema a solucionar o la necesidad a cubrir junto con el potencial impacto de negocio.
  • Ideación de soluciones: Identificamos las posibles soluciones para solventar los problemas y las necesidades.
  • Implementación de soluciones: Desarrollamos y entregamos los incrementos de producto a nuestros beneficiarios.
  • Feedback contínuo: Comúnmente hablamos de feedback en relación al impacto y el valor esperado de la solución pero podemos pensar en el feedback como planos transversales a los anteriores, unos más orientados a la forma de trabajo y otros relativos al valor entregado.

Supuestamente a medida que avanzamos desde ideación hasta feedback, vamos disminuyendo nuestro nivel de incertidumbre (de ahí la forma de funnel). Además, la madurez del producto con respecto a su ciclo de vida influye a la hora de organizar el trabajo de creación de dicho producto.

A continuación vamos a recorrer cada plano explicándolo con más detalle:

Plano Identificación de Oportunidades

Asumimos que este plano representa el espacio donde todas las ideas u oportunidades son merecedoras de consideración. Dichas oportunidades pueden haberse originado en workshops de ideación, discovery, design thinking, resultados de una investigación con usuarios, estudios de mercado, análisis de la competencia, ideas de cualquier grupo de trabajo o miembro de un equipo que participe en la creación del producto, refinamientos, revisiones, etc.

Todas estas potenciales oportunidades de mejora o evolución del producto son recogidas de forma que puedan pasar a otros planos, normalmente a lo que llamamos Entendimiento donde articulamos dichas oportunidades (lo explicamos en el siguiente apartado)

En esta fase, el papel de la disciplina de datos y en particular la del científico de datos no se diferencia de la de otros roles, excepto porque las ideas podrían venir de un proceso relativo a la ciencia de datos, como por ejemplo el uso de nuevas fuentes de datos externas o internas, los avances técnicos en algoritmos o la identificación de ciclos de adquisición y realimentación de datos.

Uso de nuevas fuentes de datos (externas o internas)

En muchos productos uno de los diferenciadores puede ser el uso de datos. En este sentido identificar fuentes de datos diferenciales y poder valorar su utilidad en etapas tempranas del proyecto es clave para la viabilidad de las ideas generadas. Por ejemplo, podemos tener la idea de que la información en portales públicos de compra venta de pisos podría ser utilizada para mejorar  la valoración del precio de una vivienda, que hasta ahora era generada basada en datos internos.

Avances técnicos en algoritmos

Algo similar ocurre con la disponibilidad de nuevas herramientas o algoritmos para el tratamiento de datos. En ocasiones, el acceso a un nuevo algoritmo puede hacer viable, técnica o económicamente, una idea. Los avances en algoritmos de Deep Learning aplicados a Visión Artificial han permitido rebajar el número de ejemplos necesarios para clasificar imágenes abriendo la puerta a nuevas aplicaciones. Por ejemplo, gracias a estos avances decidir si una imagen proporcionada contiene un coche es ahora mucho más sencillo y preciso.

Identificación de ciclos de adquisición y realimentación de datos

Otra tipo de aportación desde el equipo de datos consiste en identificar cuáles serían los mecanismos para obtener los datos deseables para nuestro producto y definir una estrategia para su adquisición. Esta estrategia, que DJ Patil define como Data Jiujitsu, ha sido ampliamente utilizada en el caso de las redes sociales como LinkedIn o Facebook para soportar su modelo de negocio.

Cabe destacar que el feedback de los resultados generados en otros planos (Entendimiento, Ideación, Ejecución, etc. explicado en apartados posteriores) podría ser una de las fuentes más interesantes de las que se puede nutrir el plano de Identificación.

Plano Entendimiento

En este plano articulamos la oportunidad y, por lo tanto, la hipótesis que tenemos con respecto al beneficio que nos reportaría llevarla a cabo, tanto a nivel de negocio como para nuestros clientes o usuarios. Además, en este plano podemos empezar a perfilar una visión o a alinearnos con una ya existente.

Como parte de ese refinamiento, el equipo de datos puede acometer tareas como:

Análisis exploratorio de datos para validar idea

Como parte del entendimiento de una idea, el análisis de los datos del mercado nos va a ayudar a definir mejor la oportunidad (público objetivo, segmentación, modelo de negocio, etc) y a acotar el trabajo a realizar en el resto de planos.

Identificar problemas e implicaciones éticas en el uso de datos

En esta etapa es necesario profundizar en las implicaciones de usar las fuentes de datos que se hayan identificado  y la forma en la que se van a usar. En este caso hay que tener en cuenta tanto aspectos legales, de privacidad y éticos. Es el momento de identificar posibles sesgos en los datos y considerar si el producto agravaría esos sesgos.

También si es capaz de satisfacer a todos los usuarios objetivo, o por el contrario se requieren mecanismos o acciones especiales para que la solución elegida sea inclusiva. Por ejemplo, en aplicaciones que incluyen reconocimiento de voz se ha encontrado que la baja representación de ejemplos femeninos o de voces no nativas suele implicar un peor calidad en el reconocimiento para estos colectivos.  

Viabilidad y análisis crítico de los datos disponibles

Es labor del equipo de datos, además del uso responsable de los mismos, velar por la utilidad práctica de dichos datos y así como de los correspondientes algoritmos. Aunque en la etapa de ideación es necesario mantener una mentalidad abierta para identificar datos que supongan una ventaja competitiva, en esta etapa es el momento de mirar los datos desde un punto de vista más crítico. Los sesgos en la recolección de datos, además de tener implicaciones éticas, pueden invalidar o limitar su utilidad en términos analíticos. Otro problema frecuente es que no se disponga de la profundidad histórica necesaria o no se recojan los datos con la frecuencia o la resolución necesaria.

Por ejemplo, un dataset puede registrar la fecha en la que sucede un evento pero en cambio, para ser útil en un  nuevo contexto se requiere el timestamp con información de hora, minuto y segundo. Identificar este tipo de necesidades y problemas, así como corregirlos para que se disponga del histórico necesario también es responsabilidad de la disciplina de datos.

Plano Ideación de Soluciones

Este es el nivel donde pensamos en las diferentes soluciones para la creación del producto, así como todo lo necesario como para poder empezar a experimentar y aprender con algo tangible (a algunos les sonará el concepto de MVP).

El objetivo es definir las características del producto y en el caso específico de que requieran funcionalidades basadas en el uso y explotación de datos, abordar cómo se podrían construir.

A grandes rasgos las aportaciones que se pueden hacer desde el equipo de datos para contribuir a la solución se agrupan en los siguientes  grandes bloques:

  • Análisis Exploratorio de Datos: Se trata en este caso de responder preguntas de negocio, por ejemplo, mediante los datos de uso del producto. Estos análisis pueden ayudar a definir una estrategia de producto, escoger una solución o priorizar el problema en el que enfocarse.
  • Visualización y Resumen de Datos: Muchos productos basados en datos incluyen alguna forma de visualización de los propios datos generados por sus usuarios, por ejemplo un gadget destinado a medir nuestra actividad física Es labor del equipo de datos buscar una visualización eficaz y adecuada.
  • Predicción Es la capacidad para inferir el valor de una o varias variables de interés para nuestra aplicación  Puede tratarse, entre otras, de la categoría de un objeto (imagen), el valor numérico de una cantidad medible (el precio de un vuelo) o las películas en las que puede estar interesado un usuario, como en el caso de un recomendador.
  • Diseño de ciclos de realimentación de datos: Cualquier funcionalidad basada en datos tiende a obtener mejores resultados si dispone de más datos, así que parte de la labor del equipo de datos es definir mecanismos que permitan recogerlos y transformarlos en mejores predicciones o visualizaciones de mayor exactitud.
  • Otras funcionalidades: La disciplina de datos puede proporcionar otras soluciones basadas en datos como la optimización o la simulación, ambas relacionadas con los puntos anteriores.

Como ejemplo, pensemos en una funcionalidad familiar para muchos de nosotros: organizar las fotografías de nuestro dispositivo móvil según las personas que aparecen.Si tratamos de asociar las aportaciones al diseño que puede aportar un científico de datos:

  • En primer lugar, puede ser necesario clasificar qué fotografías tienen personas y cuáles no, que claramente es un problema de predicción.
  • Del mismo modo, agrupar qué fotografías son de la misma persona aunque puede ser abordado de diferentes formas como clustering, clasificación o ranking, es en general, otro ejemplo de problema de predicción.
  • Un tercer punto es cómo mostrar los grupos de fotografías que se podría clasificar como un problema de visualización de datos. Si bien podemos usar heurísticos sencillos (primero los grupos más numerosos o los que tienen alguna foto más reciente), también podríamos pensar en otros  más complejos (primero las personas que aparecen en más selfies) que a su vez podría requerir más problemas de predicción.
  • Además, podríamos facilitar que los usuarios pudiesen hacer sus propios grupos o quitar, poner o mover una foto mal clasificada. Si capturamos este tipo de acciones, podríamos usarlas para mejorar los modelos de predicción anteriores, que serían un buen ejemplo de la creación de un ciclo de realimentación de datos.

Para cada funcionalidad donde la ciencia de datos contribuye, hay que considerar la participación del resto de disciplinas (UX, visual design, backend, frontend, servicios, etc) y pensar en ¿qué impacto tiene para nuestros beneficiarios y/o negocio el hecho de ofrecer dicha funcionalidad? En este caso, podemos expresarlo como hipótesis de beneficio.

Por ejemplo, si incluimos la funcionalidad de ver fotos organizadas por personas, aumentará un 20% el tiempo que pasan los usuarios en la aplicación y crecerán los usuarios que suscriban un plan superior partiendo del journey “ver sus fotos organizadas”. Como consecuencia de esta funcionalidad esperamos aumenta nuestro beneficios un 5%. Es en este caso, el que el equipo de científicos de datos también puede colaborar definiendo los KPIs de negocio, definiendo el experimento científico y facilitando la obtención de conclusiones.  Del mismo modo, mediante por ejemplo la realización de test A/B, podemos validar los resultados obtenidos con la entrega de un incremento de producto.

Plano Implementación

Este es el plano donde generamos un incremento de producto de forma que entregamos valor al cliente o beneficiario. Aquí el científico de datos tiene la oportunidad de contribuir en el impacto esperado con dicho incremento, “exprimiendo” lo trabajado en todos los planos anteriores y de forma conjunta con el resto del equipo, para así entregarlo a los correspondientes beneficiarios o clientes finales.

Se asume que gran parte del trabajo en entendimiento del negocio y en la decisión del enfoque análitico se ha llevado a cabo en los planos etapas previas de entendimiento e ideación. Para la disciplina de datos este plano abarca desde el trabajo técnico de la  ingesta de datos, la validación de estos mismos, exploración, construcción del modelo predictivo (o de una visualización) hasta la posterior validación de sus resultados y en el mejor de los casos el despliegue de la funcionalidad y la infraestructura adecuada. Dejamos aparte  la medición de los resultados del proyecto, y por tanto la obtención de feedback, como parte los niveles transversales.

Construcción interaccionando con otras disciplinas

Muchas veces existen complicaciones al compatibilizar el ciclo de desarrollo tradicional de la disciplina  de datos con las iteraciones llevadas a cabo por el resto del equipo. Suponemos que el equipo en su conjunto es capaz de entregar un incremento de producto por ellos mismos, pero  las dependencias y la burocracia son típicas complicaciones que entorpecen el flujo de valor. De hecho, son habituales no sólo para científicos de datos si no para cualquier equipo ágil en general. En muchos casos la solución está más relacionada con la organización y estilos de liderazgo. Aunque esta es una discusión muy interesante, no la abordamos directamente aunque sí podemos comentar una serie de comportamientos que obstaculizan la inclusión de un científico de datos en un equipo ágil.   Se trata del mismo concepto pero abordado desde dos perspectivas diferentes, una desde el responsable de producto y la otra desde el científico de datos:

  • El responsable de producto piensa que todos los miembros del equipo tienen que contribuir en cada iteración con un incremento de funcionalidad y no tanto en un incremento de valor, no entendiendo que la ciencia de datos conlleva cierta parte de experimentación (incluso investigación) con niveles bajos de predictibilidad: Esta preocupación se hace más latente cuando un equipo no trabaja de manera multidisciplinar y colaborativamente para conseguir un objetivo, sino que se distribuyen el trabajo por disciplina o tecnología. La peor consecuencia de esta forma de trabajo es la imposibilidad de entregar valor con un flujo continuo, haciendo necesaria la integración (en algún punto futuro) de las diferentes partes implementadas a lo largo de los anteriores sprints, creando un estilo de trabajo waterfall. Por lo tanto, es importante entender que el científico de datos podría tener como resultado final de una iteración, un aprendizaje o algo que no se incluya directamente en el incremento de producto. Pero son estos experimentos los que nos llevan iterativamente a conseguir algo que finalmente sí contribuya en el incremento de producto (normalmente de manera muy significativa).
  • El científico de datos trabaja en una caja negra que se integra con el resto de funcionalidad cuando tiene un rendimiento determinado: Entendemos que las iteraciones deberían de ser incrementales, pero del producto y no solo de la parte de datos. Hay que entender que es el equipo el que tiene como objetivo entregar un incremento de producto que aporte valor en cada iteración, y no partes específicas  del equipo o individuos concretos. Como consecuencia, los ciclos de inspección y adaptación son del producto, donde el valor aportado por un incremento depende de todas las disciplinas aunque alguna sea más estratégica que otras. Por ejemplo, por muy brillante que sea un algoritmo, no va a tener el impacto esperado si UX o el visual designer no lo hace deseable o usable para el usuario, o de igual forma, las personas de operaciones no han conseguido la disponibilidad que el usuario espera.

Cadencia, Timebox, Avance Iterativo e Incremental

Creemos que merece la pena comentar un tema bastante habitual cuando científicos de datos pertenecen a un equipo ágil que itera con un timebox típico de por ejemplo 2 semanas.

Al final de la iteración se espera un incremento de valor, este incremento puede tener diferente naturaleza, aunque al final muchos entiendan o simplifiquen este valor a beneficio financiero, que ya sea de forma directa o indirecta.

La naturaleza del valor aportado en esta fase puede tener un potencial de predictibilidad diferente, de forma que ciertos trabajos sean más de research con un nivel de predictibilidad bajo y otros más de ejecución con alto nivel de predictibilidad. Normalmente está relacionado con los planos explicados con anterioridad, donde por ejemplo la predicción es complicada si nos encontramos con actividades del nivel de identificación de oportunidades o entendimento.

Cuando tenemos objetivos complicados de estimar debido a que el camino para conseguirlos es difuso, las prácticas iterativas destinadas a conseguir un objetivo en un timebox determinado podrían no ser demasiado útiles. De esta forma, intentar meter todo el trabajo realizado por los equipos en todos los planos dentro de la iteración de dos semanas, no tiene sentido en muchas ocasiones. Pero eso no quiere decir que los ciclos de inspección y adaptación no sean útiles en cualquiera de los planos, en nuestra opinión siguen siendo útiles para gestionar las expectativas del propio equipo y de los diferentes stakeholders. Sería el plano de implementación donde las iteraciones con un timebox específico resultarían más adecuadas.  

Aun así, la labor de construir una funcionalidad completa basada en datos en el nivel de implementación, en un periodo de dos semanas es en general complicada. Es la labor de los responsables de producto y los científicos de datos establecer la estrategia adecuada para facilitar la entrega de incremento de producto en el menor tiempo posible sin que eso implique tener una funcionalidad completa.

Estas son algunas estrategias para facilitar el trabajo colaborativo de un DS con el resto del equipo:

  • Construir hacia atrás. En ocasiones disponemos de funcionalidades que se pueden empezar a desplegar mediante heurísticos sencillos que luego podemos reemplazar con algoritmos más complejos. En este caso podemos trabajar en integrar estos heurísticos como un stub con el resto de la aplicación y junto al resto del equipo. La gran ventaja es que podemos empezar a testear el valor que la funcionalidad  aportaría al producto sin necesidad de construir una funcionalidad completa.
  • Construir por dominios de datos. En este caso el objetivo es identificar cual es el conjunto mínimo de datos que facilitan la mejor aproximación al modelo ideal. El objetivo es centrarse solo en la adquisición de estas fuentes de datos y su explotación combinando criterios de utilidad y disponibilidad. Posteriormente se pueden ir  incrementando el número de dominios de datos a introducir.
  • Construir por incremento de resolución. Uno de los grandes problemas en el tratamiento de datos es que tanto la adquisición y limpieza de datos requieren una gran cantidad de tiempo. En muchos casos, es viable rebajar los requisitos de este procesos si en vez de un incremento de producto, buscamos un incremento de valor. Como por ejemplo determinar si una fuente de datos o un enfoque es el adecuado. 
  • Construir mediante incrementos de complejidad. En general, conviene explorar el uso de los algoritmos (o visualizaciones) más sencillos o estándar antes de buscar soluciones más complejas, y que requieren mucho más trabajo y experimentación. Hay pocas cosas peores que contrastar, gracias al feedback de los usuarios que la funcionalidad que hemos tratado de resolver, no es en realidad deseable. Es preferible determinar cuánto antes que se trata de una funcionalidad interesante aunque requiera de mayor exactitud o sofisticación para ser útil.

Planos Feedback

Representamos el feedback como planos que cortan de manera transversal al resto de los planos. Un tipo feedback serían el relativo al proceso o mejora de la forma en que se trabaja para crear el producto en cada uno de los planos. El otro tipo de feedback se corresponde con la forma con la que que podemos validar nuestras hipótesis y criterios de éxito para pivotar o persistir en nuestras siguientes iteraciones. El feedback puede tener lugar dentro de cada plano debido a que una iteración no implica necesariamente un cambio de plano.

También puede tomar varias formas, desde el feedback cualitativo del equipo o de los usuarios hasta feedback cuantitativo. Precisamente es en este último, donde la disciplina de datos también ha contribuido en el diseño de experimentos destinados a la validación de hipótesis del producto, de la solución o sobre detalles de la implementación. Cualquier cambio o mejora, como un nuevo algoritmo para una predicción o un cambio en la interfaz, es susceptible  de ser validado con usuarios reales.

Uno de los mayores retos es que el periodo para obtener feedback accionable es   demasiado largo como para trabajar en iteraciones cortas. Para afrontar esta problemática podríamos definir leading indicators que nos permitan validar nuestras hipótesis a más corto plazos.

Ejemplos de Implantación

Dependiendo del contexto la forma de aterrizar todo lo explicado en los anteriores apartados puede variar considerablemente. Especificar un framework para todos los casos sería una simplificación de una situación que seguramente es muy compleja. Incluso algunas personas pensarán que para todos o la mayoría de casos, la utilización de un framework  es un error y la mejor aproximación sería la mejora contínua de los equipos basada en principios y valores ágiles sin especificar prácticas específicas.

Con la simple intención de ayudar a generar ideas, algunas alternativas  serían:

  • Realizar el trabajo con sistemas Kanban de manera que cada work item atraviese uno o varios planos y lo completen las personas que tengan las skills oportunas.
  • Utilizar un sistema Kanban para los planos de identificación, entendimiento e ideación y luego trabajar con los diferentes equipos en scrum (por decir el framework de agilidad más usado) en el plano de implementación. A la hora de gestionar la capacidad (sobre todo en la estimación de scrum) habría que considerar que algunos miembros contribuyen en varios planos.
  • Trabajar con un equipo scrum en los planos de identificación, entendimiento e ideación y luego trabajar con los diferentes equipos en scrum en el plano de implementación. En este caso, como scrum tiene una serie de ceremonias determinadas, si un integrante del scrum de un plano pertenece o participa también en otros scrums, podría existir un riesgo de ineficiencia.

Muchas gracias por el feedback y ayudar en la divulgación a Jerónimo Palacios, Marcelo Soria, Victor Adaíl y Jairo Alberto.

Los autores de este artículo somos César de Pablo Sánchez y Félix Serrano Martín. Nos conocimos trabajando en BBVA D&A, César trabajando como Científico de Datos y Félix como Agile Coach. Las opiniones expresadas por ambos en este artículo son personales y no necesariamente las de su empleador.

César de Pablo es Ingeniero de Telecomunicaciones por la ETSIT-UPM y Doctor en Ingeniería Informática por la UC3M. Tiene más de 15 años de experiencia en desarrollo de productos y soluciones basadas en análisis de datos, aprendizaje automático y procesamiento de lenguaje natural.

¿Cooperar o competir en un mundo digital?

Mi empresa actual no es la primera en la que soy propietario u ostento una participación significativa. Durante los últimos doce años he creado varias, de las cuales esta ha sido la más exitosa. Algunas incluso las he vendido a otros competidores del mercado.

Cooperar o Competir, ese es el dilema

Uno de los aspectos que siempre me ha parecido más interesante del mundo empresarial es el de colaborar o competir con otras empresas que, en principio, son competidores nuestros.

Probablemente el primer impulso cuando tratamos con un competidor sea el de evitar colaborar. ¿Por qué querría colaborar con alguien que puede quitarme lo mío? Detrás de este pensamiento a priori lógico se encuentra un dilema bastante más amplio de lo que pensamos.

Imaginemos que estamos ante una oportunidad empresarial enorme a la que concurrimos en competencia con otra compañía a la que conocemos bien. Si colaboramos para conseguirla, ambos ganamos. Si nosotros intentamos colaborar pero nuestro competidor se aprovecha de esa posición, entonces perdemos. Si nuestro competidor intenta colaborar pero nosotros nos aprovechamos, entonces ganamos. Si ambos intentamos aprovecharnos el uno del otro, entonces ambos perdemos.

Esta es una adaptación del dilema del prisionero y parte de la teoría de juegosfruto del trabajo de John Nash, que fue ilustrada en la película Una mente maravillosa.

El contexto es clave

En el caso del dilema del prisionero, el contexto es clave. No es lo mismo un contexto de suma cero, donde si uno gana otro pierde, que un contexto más rico donde si perdemos, tenemos otra oportunidad. Los entornos empresariales modernos son del segundo tipo, lo cual permite adaptar nuestra estrategia a la de los competidores.

Volviendo al ejemplo anterior, si en una oportunidad posterior nos volvemos a encontrar con el mismo competidor, entonces podemos decidir colaborar o no dependiendo de lo que este haya hecho la vez anterior. En general podemos optar siempre por una estrategia (colaborar o competir) o adaptar nuestra estrategia en función de lo que haga nuestro competidor. Por último, podemos actuar aleatoriamente, o dejándonos llevar por otros factores.

¿Y que hay de la falta de comunicación?

Imagina que en el ejemplo, nuestro competidor se aprovecha de nosotros pero es a causa de un error de comunicación. ¿Deberíamos de darle otra oportunidad? ¿Y si no sabemos que ha sido a causa de un problema de comunicación?

En ese caso, podríamos incorporar una regla a nuestra estrategia que nos indicara si debemos dar una segunda o una tercera oportunidad cuando pensamos que nuestra falta de colaboración se debe a un error de comunicación.

Adoptando heurísticos

La clave es adoptar una posición fija ante cierto tipo de situaciones. Un marco de decisión que nos facilite el tomar decisiones sin tener que hacerlo una por una. En nuestra vida real lo hacemos continuamente, están estudiadas y se llaman heurísticos. El problema es que no siempre somos conscientes de ellas y de las consecuencias de las mismas.

Daniel Kahnehman lo describe en su libro thinking fast and slow. El problema de los humanos es que tenemos un cerebro primitivo, mucho más viejo evolutivamente hablando, y un cerebro moderno, que es capaz de tomar decisiones infiriendo información. Eso hace, por ejemplo, que nos sintamos en ocasiones tristes, o amenazados, sin saber por qué. Nuestro cerebro más viejo toma el control para protegernos de peligros que identificamos como amenazantes aunque realmente no lo sean.

¿Entonces que debo hacer? ¿Colaborar o competir?

La regla de oro es: trata a otro como deseas ser tratado. El problema es que el mundo es injusto y en ocasiones poner la otra mejilla no es fácil. ¿Quieres simularlo? Los chicos de NCASE han desarrollado un simulador de confianza que permite ver cuales son las estrategias más óptimas desde todos los parámetros que hemos visto.

Tener conocimiento de esto permite desarrollar una estrategia de toma de decisiones rápida sobre colaborar o competir. Solamente este mes me he encontrado ante 3 de estas situaciones. Este marco me ha ayudado a tomar una decisión rápida y coherente a lo largo del tiempo.

Delivering a product has nothing to do with what you think

When I was 18, my father kicked me out of home. I was not the easiest teenager in this world, but who is anyway? One of the things I did for a while was working at several restaurants, where I rotated among different roles. From cleaning dishes to waiting tables I could understand a well know secret in the hospitality industry: success has little to do with the food.

Most Product Managers think that developing a product is about great user experience. Some of them center on the user interface. The old school ones focus on marketing, the 4Ps and that kind of think. But there is little to none that I have known that really understand that developing a product is about being able to create an economy around it. That’s it.

Creating an economy around it might sound misleading. It’s not about people buying it or having an impact on the stock market. It’s about understanding how your product development works. How to make decisions based on data that reflects the economy of the product. Knowing your customers and how they use it it’s ok, but knowing them and the wisdom to push what they don’t know they want makes all the difference.

15 years later, I love cooking and I love delighting my friends with some dishes prepared at home when they come over. But that does not make me able to open a restaurant, where managing uncertainty is more important than you think. When you go to a restaurant, of course you think you go for the food. But you don’t. You expect certain qualities when being there. That you are served timely. The more expensive, the more timely. That restaurant hasn’t run out of food. That there are desserts.

All the same, of course your customers join because they like your product. And they also expect certain qualities, that if present, they won’t even notice. Those qualities you can manage and are the ones that will mae you money.

Most Product Managers or Product Owners don’t know how to quantify anything of the follow: Cost of Delay, Development in Progress, Total Cost of Ownership or Queues. These things are there and they don’t pay attention. They make decisions that have a huge impact in total cost of ownership -i.e. creating technical debt- just to push features that don’t even have a revenue return.

They decide to add old browsers compatibility just because someone said that the app does not work in Internet Explorer 6. They think that Scrum or Kanban are just control methods for lazy developers and ignore tools to manage tactical risk. Some of them think that those frameworks are just HR tools.

Yes, I could think that because I am a good cook at home, I could open a restaurant. Just to find out that it’s all about managing complexity -How much food should I buy today? (Development in Progress)-, Expectations -Dishes that don’t take ages to arrive (Release frequency), How much people can I accept in my restaurant -Number of tables (Queuing), Running Costs (TCO) and maintaining a good Product Cost Ratio. What do you think you learn at chef school, how to cook? That’s the easy part, the difficult one is how to run a sustainable business.

You might think you are a vissionaire product developer, but that does not make you capable to run a Product that might be successful at the real market. There is an unfair advantage, the people that know about processes and management methods to manage complexity. Make good use of them.

Métricas ágiles fundamentales (II)

Después del primer post sobre métricas ágiles, donde se exponía como medir conceptos como el Average Customer Lead Time, Cycle Time y WIP a través de su relación con la Ley de Little, quedó pendiente una explicación de métricas de producto a nivel circunstancial y cómo agregarlas a alto nivel

El problema de la Pizza

Imaginemos que nos asociamos con nuestros mejores amigos para abrir una Pizzeria. Por supuesto, para poder elaborar un plan de negocio y seguirlo, necesitaremos de una serie de métricas que nos indiquen como va el negocio. La más importante son los ingresos y los beneficios. Pero más allá, ¿Que podríamos medir?

Podemos imaginarnos muchas cosas que nuestro negocio nos permite medir, como el número de Pizzas entregadas en cada viaje en moto, las pizzas más rentables, el número de repartidores, el número de reclamaciones, el valor medio de un pedido, etc…

Métricas directas vs Métricas circunstanciales

En realidad, todas estas métricas se pueden agrupar en dos tipos de métricas: directas y circunstanciales. Las directas son las que tienen una aplicación directa sobre el valor que generamos, mientras que las circunstanciales nos dan información que debe ser agregada antes de poder usarla para obtener valor.

En el caso de nuestra Pizzeria, el número de pedidos entregados por viaje en moto de nuestro repartidor podría ser una buena métrica, hasta que nos preguntamos: ¿Realmente son rentables estos viajes? Si estamos regalanado nuestras Pizzas por debajo de precio, cada viaje en moto no sólo no agrega valor a nuestro negocio sino que genera valor negativo: Nos cuesta dinero.

En una gran Telco, el Management de area decidió implementar un bonus para aquellos que encontraran más bugs dentro de la aplicación. El resultado fue espectacular, el número de bugs reportados se incrementó en más del 100%. Sin embargo, un análisis posterior reveló que la mayoría de estos bugs eran descripciones similares o iguales a problemas ya conocidos dentro de la aplicación

¿Cómo medimos entonces el valor?

En primer lugar, hay que tener claro que significa valor para la organización. Esta es simple: Valor es la capacidad de generar beneficio económico. Para organizaciones sin ánimo de lucro es: Capacidad de generar un beneficio para la sociedad. Ojo, beneficio económico o beneficio social no sólamnete son euros contantes y sonantes, sino que pueden incluir, por ejemplo, una mejora en la valoración de la compañía.

Una definición clara de valor es parte de una estrategia de negocio, apoyado en una visión y misión clara. Lamentablemente, muchas organizaciones no tienen claro estos puntos antes de lanzar nuevos productos o compañías al mercado.

Metricas circunstanciales -> Métricas directas

Volvamos al ejemplo de la Pizza. Si medir el número de pedidos por viaje no tiene sentido sin considerar el beneficio de cada pedido, ¿Cómo podemos transformar esas métricas circunstanciales en métricas directas? Mediante la agregación y el balanceo. En el caso de nuestra Pizzería, tendremos que buscar la manera de agregar diferentes métricas para obtener una que nos permita saber si somos rentables o no.

Métricas directas en el desarrollo de Software

Cuando desarrollamos un producto de Software nos encontramos en una situación aún más complicada. No sabemos que parte de nuestro Software y de la inversión que hacemos influye más en la generación de valor para nuestro producto o compañía.

No he conocido a ninguna compañía que mida el efecto que un training de Scrum como el que yo mismo hago en su creación de valor. O de una Hackaton. La mayoría lo hacen siguiendo una filosofía de Cargo Cult. Lo hacen porque otros lo hacen. No son capaces de relacionarlo con su propia creación de valor.

La mayoría de las métricas que podemos obtener en el desarrollo de Software son puramente circunstanciales.

Aquellas métricas más directas no sirven para ajustar la estrategia. Sin embargo, podemos usar las métricas cricunstanciales para medir directamente el valor utilizando el framework de Evidence Based-Management.

Evidence-based Management

EBMgt surge por parte de Scrum.org como una respuesta a la pobre medición y seguimiento que hacen las organizaciones que usan Scrum de su valor. La idea es prestada de la Medicina Basada en la Evidencia (MBE). Para poder tomar una decisión, es necesario tener pruebas que den soporte a esa decisión, evitando las decisiones basadas en el conocimiento común o las corazonadas.

Evidence-based Management propone una serie de tres métricas directas desagregadas en 12 métricas circunstanciales obtenidas de la información de la compañía: Valor actual, Time to Market y Capacidad de innovación.

Evidence Based Management metrics

Valor actual

El valor actual se obtiene de la agregacion de cuatro métricas:

  • Ingresos por empleado: Se obtiene midiendo los ingresos brutos/número de empleados. Nos indica una rentabilidad bruta por empleado.
  • Satisfacción de los empleados: Porcentaje de empleados que se califican a sí mismos como “Satisfechos” o “Muy satisfechos”.
  • Satisfacción de los clientes: % de clientes que se consideran “satisfechos” o “muy satisfechos”. Se puede sustituir por el Net Promoter Score.
  • Product cost Ratio: Coste de la inversión de mejoras (training, herramientas, espacios de trabajo) comparado con el cambio en ingresos brutos

Si introducimos mejoras en el proceso de despliegue fomentando DevOps y formamos al equipo para que use

Scrum pero nuestros ingresos brutos se mantienen o descienden, entonces sabremos que no estamos enfocandonos en el área de la compañía que requiere atención. Al igual que la medicina, hay que dar un tiempo para ver como evoluciona el paciente antes de tomar otras acciones.

Time to Market

El tiempo que tardamos en llegar al mercado es una métrica fundamental de negocio, ya que nos permite medir el coste de oportunidad perdido usando el Cost of Delay correspondiente a un producto o una característica existente de nuestro producto. En EBMgt lo medimos en base a tres métricas circunstanciales:

  • Frecuencia de Release: El tiempo que pasa entre release funcionales, no de corrección de bugs o mantenimiento.
  • Estabilización de Release: Tiempo que pasa entre que se completa el código y se lanza realmente a los clientes.
  • Cycle time: El tiempo que necesitamos para entregar una pequeña funcionalidad nueva (no bugs) al cliente

Es importante reseñar que, si al igual que en el caso anterior, fomentamos DevOps para reducir nuestro Time to Market, si tenemos gran deuda técnica, no haremos más que pagar esa deuda técnica y nuestros valores de esta métrica permaneceran estáticos. Para eso tenemos la siguiente.

Capacidad de innovación

Nuestra última métrica directa es una medición de nuestra capacidad para innovar. Para ello utilizamos cinco métricas circunstaciales que nos daran una idea de cómo de bien lo hacemos en este área.

  • Versión instalada: % de clientes en la última versión comparado con el número de versiones mantenidas
  • Índice de uso: % de funcionalidades usadas más del 50% del tiempo
  • Ratio de innovación: % del presupuesto dedicado a desarrollar nuevas funcionalidades. A mayor porcentaje, menor Coste de propiedad (TCO).
  • Densidad de defectos: % de cambio de bugs en producción desde la última medición
  • Product Cost Ratio: Coste total de gastos, incluyendo gastos operacionales/ingresos brutos.

Agregando todas estas métricas podemos tener una idea excelente de cual es nuestra capacidad de innovar. Así, una organización con una gran deuda técnica verá reflejada en esta métrica su deuda técnica, que le impide innovar.

La idea de todas estas métricas, que pueden cambiar de una compañía a otra, es proporcionar un marco para la toma de decisiones, no de ser decisiones en sí mismas. Teniendo una medida continua de estas métricas, que es fácil de obtener mediante los sistemas de información que tienen las organizaciones hoy en día, tendremos un marco que nos permitirá actuar con eficiencia sobre el sistema, independientemente de sus ineficiencias locales.

Leer más

Si quieres leer más, puedes descargar el whitepaper de Evidence Based Management.

Si quieres aprender más sobre como generar y medir valor en tu organización, te recomiendo le eches un vistazo a nuestros próximos cursos de Product Owner en Madrid y Barcelona.

  • Ir a la página 1
  • Ir a la página 2
  • Ir a la página siguiente »

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad