Product ideation: Diagrama de Ishikawa

Dentro de la metodología de innovación en design thinking se puede hacer uso del diagrama de Ishikawa. 

El Diagrama de Ishikawa, también conocido como Diagrama de Espina de Pescado, una herramienta visual poderosa que te ayudará a navegar por las complejidades del proceso creativo y a asegurar que tu producto final sea un éxito rotundo.

El Diagrama de Ishikawa es una herramienta versátil y valiosa para cualquier equipo de desarrollo de productos. Al utilizarlo de manera efectiva, podrás anticipar y superar obstáculos, optimizar tus procesos y, en última instancia, crear productos que deleiten a tus clientes y impulsen el éxito de tu negocio.

¿Qué es el Diagrama de Ishikawa?

Imagina el esqueleto de un pez: la cabeza representa el problema o efecto que quieres analizar (en este caso, un producto fallido o con margen de mejora), y las espinas son las posibles causas que contribuyen a ese resultado. Estas causas se clasifican en categorías principales, como:

• Métodos: Procesos de diseño, desarrollo, producción.
• Máquinas: Tecnología, herramientas, equipos utilizados.
• Mano de Obra: Habilidades, capacitación, motivación del equipo.
• Materiales: Calidad, disponibilidad, costo de los insumos.
• Medio Ambiente: Condiciones de trabajo, factores externos.
• Mediciones: Métricas, sistemas de control de calidad.

¿Cómo Aplicarlo en la Creación de Productos?

1. Define el Problema: ¿Qué quieres lograr con tu producto? ¿Qué desafíos o problemas potenciales anticipas?
2. Identifica las Categorías Principales: Adapta las categorías tradicionales (6M) a tu contexto específico. Por ejemplo, en desarrollo de software, podrías considerar "Código", "Diseño UX/UI", "Requisitos", etc.
3. Lluvia de Ideas: Reúne a tu equipo y genera ideas sobre las posibles causas que podrían afectar el éxito del producto, asignándolas a las categorías correspondientes.
4. Profundiza en las Causas Raíz: Analiza cada causa y busca subcausas más específicas. Utiliza preguntas como "¿Por qué sucede esto?" para llegar al fondo del asunto.
5. Prioriza y Actúa: Identifica las causas más impactantes y desarrolla soluciones concretas para abordarlas.

Beneficios del Diagrama de Ishikawa:

• Fomenta la Colaboración: Involucra a todo el equipo en la identificación y resolución de problemas.
• Visualiza las Relaciones: Permite ver claramente cómo las diferentes causas interactúan y afectan el resultado final.
• Promueve el Pensamiento Crítico: Estimula el análisis profundo y la búsqueda de soluciones efectivas.
• Previene Problemas Futuros: Al identificar y abordar las causas raíz, se reducen las posibilidades de que los mismos problemas vuelvan a surgir.

Si quieres tener más información. Desde esta página puedes encontrar una template para trabajar este modelo:

https://miro.com/miroverse/diagrama-de-ishikawa/

MLOps - Machine Learning + Operations, un framework agile para equipos de Data Science

 Conforme aumenta la madurez en datos en las empresas y el uso de Machine Learning se hace más común el uso de framework e intentar buscar standares para que la colaboración dentro de la empresa y el self'service de datos sea más rápido y ágil. Cualquier que haya trabajado en un equipo de Data o de Analytics, o incluso haya tenido que trbajar creando modelos con Data Scientifics (Científicos de datos) se habrá dado cuenta que Scrum u otros frameworks de desarrollo de software no funcionan tan bien como en un proyecto puramente de desarrollo. Muchas veces se crean cuellos de botella o se tienen que rehacer tareas continuamente y el equipo dependen continuamente de DevOps para las release de los modelos y bueno, un largo etcétera.

Las grandes tecnológicas parece que han estado trabajando en como unir Operations y Machine Learning y han creado un framework para unirlo. Ya el año pasado comentaba el caso de DataOps manifiesto. Sin embargo, aquí se va un paso más alla y se especifica que es para equipos de Machine Learning o Aprendizaje Automático, ya que estos requieren de releases para los modelos y da esa agilidad que encontramos en Devops a los equipos de Data.

La wikipedia tiene una definicion de MLOps esto que viene a decir que la unión de DevOps y Machine Learning.

Esto, es algo bastante novedoso así que todavía esta todo un poco en pañales pero parece que tiene un gran futuro. Así que es mejor que nos informemos de como podemos empezar a usar este framework gracias al cloud computing

Qué tiene en común DevOps y MLOps

Si pensamos en un equipo de Devops, debemos fijarme en las prácticas ágiles que siguen. 

Las dos tareas principales que ambos tienen en común son

- Integración continua (CI)

- Entrega continua (CE)

Sin embargo, según el equipo de GCP que han creado una introdución a MLOps y las fases de maduración de las empresas o equipos, MLOps además  tienen otras fases que los distintgue de DevOps

- Entrenamiento Contínuo (CT)

Para saber más sobre MLOps es muy recomendable este artículo del equipo de GCP sobre las fases de maduración de MLOps

Para una introducción y saber como llevan esto las grandes empresas de tecnología, aquí puedes ver un video introductorio de Google sobre Best Practices

Y otro video de Microsoft de introducción de Machine Learning- Operations

User story - historia de usuario - en Metodologias Agiles

Qué son las User stories o historia de usuarios

Las User Stories son artefactos usados en Scrum, el framework más usado en Agile o Metodologías Ágiles.

Para qué se usan la user story en Agile

En Agile, siempre se intentan descomponer las tareas en unidades más pequenas. Las historias de usuario suponen la parte más pequena en la que trabajar en un producto o feature.

Cómo se crean historia de usuarios

Normalmente este siguen el siguiente esquema

“Como [ tipo de usuario ] 

necesito/quiero [ el qué ] 

así puedo [ beneficio ]”

Por qué usar historias de usuarios para definir nuestras tareas

Con esta sentencia ponemos al usuario en el centro de nuestras tareas tratando de resolver un problema que el usuario tiene por encima de lo que nosotros creamos que es mejor o más fácil de hacer

He creado algunos ejemplos de historia de usuarios en github qué puedes visitar aquí

Trabajar en Agile o metodologías Ágiles

Cada uno tiene su historia y

De cómo Agile llegó a mi vida

Hace un par de años empecé a trabajar en el Gobierno Británico. Ya conocía GDS por diferentes cursos que había hecho sobre Experiencia de Usuario y porque siempre me ha interesado el tema de la colaboración como Socióloga que soy la psicología social siempre me ha fascinado.

También conocía de oídas Agile y las metodologías Ágiles. Como analista digital siempre me ha tocado mi parte de project management y negociación. Al estar en el centro del negocio nos toca lidiar con todo tipo de stakeholders e influenciar a los programadores o techies para que hagan los cambios que necesitamos. Sin ellos no samos nadie. Así que desde que empecé en digital esto soy una ferviente leedora de blog y libros de como ser más productivos y suelo guardar los mejores artículos aquí  https://www.scoop.it/topic/productividad-y-tic,

Pues bien, el papel de transformación digital en GDS no puede entenderse sin Agile. Tengo que decir que al principio me costó pillar que estábamos haciendo y por qué trabajábamos así. Sin embargo ahora me he dado cuenta que la visión de Agile en la creación de software es la correcta. Entiendo que a las empresas les pueda dar un poco de miedo este cambio, sin embargo, cada vez que hablo con otros compañeros del sector que siguen trabajando con otras metodologías me reitero que Agile es la forma adecuada de trabajar para crear productos digitales - desarrollo de software.

De que va todo esto de Agile...

• De entrega rápida de software, en vez de mega proyectos que nunca se terminan (te suena...)
• De Trust o confianza y mucha transparencia. Hay mucho de psicología social y sociología en todo esto para los miembros de la empresa. 
• De tener en cuenta a los usuarios para darles lo que necesitan, adaptando el producto a sus necesidad en vez de que ellos se adapten al producto. Al fin y al cabo vivimos en un mundo cada más global donde la competición es cada vez más grande y los productos están en constante evolución.

Y si lo pensamos, asi es como deberia ser. Deberiamos confiar en nuestros jefes, en nuestros compañeros de equipo y en las personas que tenemos a nuestros mando. Una vez que todo esto se ha conseguido, todo va como la seda. Pero hasta que llegamos allí va a un largo camino y para ello alguien debe velar por que esto se pueda hacer y que esa confianza no se rompa.

Ya había comentado que Agile es una metodología, pero seguro que habrás oido hablar de Scrum, Lean ,de Kanban, de poner al usuario en el centro,... .Ahí un va un poco de luz a todo esto.

Agile es una metodología. Todo empezó con un manifiesto,aquí puede leer los principios del manifesto en inglés.Y  aquí puedes leerlo en castellano.
Sin embargo aunque esos principios no han ido cambiando con los años, si que se lo ha hecho como utilizarlos.

Dentro de Agile podemos encontrar dos frameworks ampliamente usados- Scrum (el más usado y más reglado) y Kanban. Sí, a mi también me sonaba a chino.

📊 👨‍👩‍👧‍👦 DataOps Manifesto - Cuando mezclas Data y Agile en un equipo

En mi último equipo tuvimos que encargarnos de hacer desde cero todo el sistema de reporting de la unidad, desde la investigación de nuevas métricas usando metodologías user experience research como entrevistas y focus group a crear todo el sistema de eventos en AWS, la ETL pipeline y el dashboarding y reporting en Python. Y todo esto usando metodologías Agile. No veas que converaciones teniamos más frikis de vez en cuando sobre métricas, calidad de los datos y performance.

Yo por mi parte además me llevaba muy bien con el depatamento de Devops o Reliability Engineering que eran los que usaban Kubernetes, Dockers y bases de datos, y todo lo que tenía que ver con PaaS (Platform as a Service). Y uno de mis compas le encantaba explicar lo que aprendía sobre analytics y tenía super paciencia al explicarlo. Eso me llevó a aprender sobre la existencia de balanceadores, la posibilidad de tener el backup en dos ´nubes´ diferentes o el reporting en Prometheus

Como firme defensora de trabajar en Agile en equipos multidisciplinares y diversos hay una cosa que no me terminaba de encajar al principio. Explicar a los programadores que había que testear los datos y que la definition of done no era la misma para los analistas que para los programadores nos trajo al equipo muchos dolores de cabeza y conversaciones metafísicas. Y mucho ensayo-error hasta encontrar la mejor metodología, donde tanto analistas como ingenieros tuvieramos nuestros requerimientos requeridos.El mayor problema era que tras meses implementando algo y darlo por finalizado, debíamos mejorarlo, o las necesidades de los usuarios cambiaban o nos mandaban hacer un análisis adhoc. Todo esto significó que tuvimos que aprender a trabajar juntos, y a su vez desaprendimos a trabajar como lo haciamos antes. Eso es lo bonito de Agile.

Y si llevamos todo mi largo comentario a metodología de Big Data e Inteligencia Artificial y la posiblidad de hacer todo esto en la nube podemos encontrarnos que este problema lo van a tener todas las empresas Data-Driven. Son mucho los equipos de desarrollo de software que se encuentran en esta tesitura, y por ello sólo era cuestión de tiempo que apareciera un nuevo manifiesto - DataOps.

DataOps o DevOps

DataOps toma la forma de su primo los DevOps, y lo que pretenden es que se integre esa mejora continua en los datos, mejorando así además la calidad de estos. Así que no, no se dan por finalizadas las tareas tan facilmente como ocurre en otros equipos de software, igualmente que los DevOps tienen que mantener operativa la plataforma 24/7. Como comenta IBM en su artículo en Data y Analytics hay una gran diversidad que operaciones a realizar y aunque todos sean con data, requieren de diferentes procesos y herramientas. (´Big Data Workloads are Diverse.´)

El DataOps manifiesto en castellano

El manifiesto empieza al igual que el Agile Manifiesto con las siguientes afirmaciones

• Personas e interacciones en lugar de procesos y herramientas
• Soluciones de analítica eficientes en lugar de documentación comprensiva
• Colaboración con el consumidor en lugar de negociaciones contractuales
• Experimentación, interacción y retroalimentación en lugar de un diseño extensivo directo
• Titularidad multidisciplinar de las operaciones en lugar de responsabilidades aisladas.

La traducción del manifiesto la puedes encontrar en el siguiente enlace, cuenta con 18 puntos que van desde la formación de los equipos, a la calidad de los datos y la necesidad de procesos de retroalimentación para la mejora continua. Están bastante claros, así que no vale la pena que los detalle aquí.
https://www.dataopsmanifesto.org/dataops-manifesto.html?lang=es .

Métricas para medir el Performance de tu equipo de Analítica o Data team

Este video explica alguna de las métricas que se pueden usar para medir el éxito del esfuerzo del equipo
https://www.youtube.com/watch?v=Ch4gJz3n8qw&list=PLVbsAdgZXvtyy6HVKCP0HChjCcq2oW3eK&index=18&t=0s

Más información para ampliar 

https://en.wikipedia.org/wiki/DataOps
https://www.gartner.com/en/newsroom/press-releases/2018-09-11-gartner-hype-cycle-for-data-management-positions-three-technologies-in-the-innovation-trigger-phase-in-2018
https://www.ibmbigdatahub.com/blog/3-reasons-why-dataops-essential-big-data-success
Canal youtube sobre DataOps
https://www.youtube.com/playlist?list=PLVbsAdgZXvtyy6HVKCP0HChjCcq2oW3eK