Unidad 1: Evolución de la agilidad

Introducción a la Agilidad
La agilidad es una filosofía, nace del manifiesto ágil que propone 4 valores y 12
principios.

Crystal Clear
Familia de métodos ágiles, donde cada una de ellas está adecuada a un tipo de
proyecto. Estas se caracterizan según dos dimensiones, tamaño y criticidad. Lo más
determinante para el éxito, o el fracaso, de un proyecto son las personas. Es decir,
una de las claves que determinan el éxito de un proyecto son las personas.

¿Qué es Agilidad? frameworks, manifiesto y algunas

fechas
Agilidad: podemos definirla como una filosofía para gestionar todo tipo de
proyectos de manera correcta, teniendo en cuenta que una buena gestión de
proyecto conlleva el buen manejo de las 4P (persona, proceso, producto y
proyecto).
Proyecto Ágil: proyecto el cual se vuelve en un ciclo iterativo e incremental
(extremo), semanas (1 a 4), con equipos auto-organizados y auto-gestionados.
Equipos Ágiles:
● Auto-organizados y auto-gestionados
● Pequeños (7+-2)
● Multifuncionales
● Autónomos

Auto-organizados vs auto-gestionados
Auto-organizados: me dicen que hay que hacer y proponemos cómo hacerlo.
Auto-gestionados: me dicen que hay que hacer y proponemos cómo hacerlo, y
también puedo proponer otras cosas que se pueden hacer.
Según Hacktan, un equipo auto-gestionado es aquel que:
● Hace las tareas.
● Se hace responsable de la gestión (cómo, cuánto y seguimiento).
● No fija los objetivos.
● No se auto-diseñan
Los fundadores de SCRUM dicen que la autoorganización no deja claro:
● El compromiso del equipo.
● Los objetivos.
● Satisfacer las necesidades de la organización.
Según ellos la autogestión deja más claro estos 3 puntos.

Scrum

Kanban
Kanban se utiliza cuando tenemos requisitos urgentes y cambiantes, por ejemplo,
en mantenimiento. Su funcionamiento es como una cola FIFO.
Kanban es un enfoque sencillo, es el tablero físico para Toyota.
Esto aplicado a la gestión de proyectos, se refiere a técnicas de representación visual para
mejorar la eficiencia en la ejecución.
● Visualiza el flujo de trabajo.
○ Divide el trabajo en bloques, escribe cada elemento en una tarjeta y la pone
en el tablero.
○ Utiliza columnas con nombre para ilustrar dónde está cada elemento en el
flujo de trabajo.
● Limita el WIP (work in Progress, trabajo en curso), asigna límites concretos a
cuántos elementos pueden estar en progreso en cada estado del flujo de trabajo.
● Mide el Lead Time (tiempo medio para completar un elemento), optimiza el proceso
para que el lead time sea tan pequeño y predecible como sea posible.

Tiempos
Tenemos 2 tipos de tiempos:
● Lead time: es el tiempo que transcurre desde que se pide hasta que se tiene
el resultado.
● Cycle time: es el tiempo desde que entró a producción hasta que se entrega.
Valores
● Transparencia.
● Balance (lograr definir la capacidad de trabajo de tal manera que haya un flujo de
trabajo continuo).
● Colaboración.
● Respeto.
● Enfoque al cliente.
● Flujo.
● Liderazgo.
● Comprensión.
● Acuerdo.

Prácticas
● Visualización de los estados: para esto se usa el tablero.
● Gestionar el flujo - Medir los flujos de trabajo: para controlarlos se definen 2 valores,
Lead Time y Cycle Time.
● Limitar el WIP.
● Explicitar las políticas.
● Implementar ciclos de feedback.
● Mejorar colaborativamente, evolucionar experimentalmente.

Beneficios
● Los cuellos de botella se vuelven visibles en tiempo real.
● Proporcionar una ruta de evolución más gradual.
● Tiende a extenderse de forma natural por toda la organización.

Kanban es recomendable para trabajar en entornos de mantenimiento.

Relación entre Scrum y Kanban

Scrum y Kanban son herramientas de proceso que te ayudan a trabajar más
eficazmente, en cierta medida, diciéndote qué hacer. Java también es una
herramienta, te ofrece una forma más sencilla de programar una computadora. Un
cepillo de dientes también es una herramienta, te ayuda a llegar a tus dientes para
que puedas limpiarlos
Como cualquier herramienta, Scrum y Kanban no son ni perfectas ni completas. No
te dicen todo lo que tienes que hacer, solo proporcionan ciertas restricciones y
directrices. Por ejemplo, Scrum te obliga a tener iteraciones de duración fija y
equipos interdisciplinarios, y Kanban te obliga a usar tableros visibles y a limitar el
tamaño de tus colas.
Scrum vs Kanban:
Similitudes:
● Ambos son Lean y Ágiles.
● Ambos emplean sistemas de planificación "pull".
● Ambos establecen límites WIP.
● En ambos la visibilidad del proceso es la base de su mejora.
● Ambos tienen como objetivo la entrega temprana y frecuente de software.
● Ambos trabajan con equipos auto-organizados.
● Ambos necesitan la división del trabajo en partes.
● Ambos revisan y mejoran de forma continua el plan del producto en base a datos
empíricos (velocidad / tiempo de entrega)
Diferencias:
Movimiento #NoEstimate
#NoEstimate viene a decir que las estimaciones no siempre son necesarias, trata de
desarrollar un proyecto sin ningún proceso de estimación. Pero para lograr lo
anterior es necesario que haya una relación de confianza con el cliente.
Está asociado a cuan definido está el producto tenemos. Se utiliza más cuando no
conocemos qué es lo que hay que hacer.
Problemas de Estimar:
● El cliente no sabe lo que quiere.
● La intangibilidad del SW hace que la industria tenga una dinámica distinta a
las demás.
● La industria tiende hacia la variabilidad.
● Los requisitos van a cambiar.
Propuesta: para construir SW necesitamos solo una visión clara y un propósito
compartido, así como un objetivo de alto nivel y no el detalle de cómo vamos a
lograrlo. En donde para poder medir la productividad debo enfocarme en lo que le
aporte valor al cliente, teniendo buenas priorizaciones e HU que valgan lo mismo.
Entonces, a partir del presupuesto que el cliente tenga, en vez de hacer
estimaciones de proyecto, se pone a un equipo de desarrollo bajo demanda de tal
forma que se vende al cliente horas ocupadas para lograr el producto.
Lo anterior se lo puede ver como realizar la transición del contrato llave en mano al
contrato “Bolsa de horas-Pago por tiempo trabajado”.
#NoEstimate propone una estimación a nivel de tarea y no hacer planning poker en
la preplanning.
Ideas para que el movimiento funcione:
● Definir HU pequeñas y similares.
● Comenzar los proyectos con poca inversión. Entregar SW funcionando.
● Financiar un prototipo que entregue SW funcionando, luego usa modelos
para hacer predicciones.
● Convertir las relaciones contractuales a partnership.
● Tener modelos de comercialización cloud.
Principios:
1. Confíe en su proceso o cámbielo.
2. Acorte el ciclo de retroalimentación.
3. Crea en los datos, no en las estimaciones.
4. Use alternativas para la toma de decisiones basado en estimaciones.
5. Pruebe el valor primero, luego pruebe la funcionalidad.
6. La estimación es un desperdicio, reduzca su impacto en su negocio.
7. Medir el progreso con SW validado y en ejecución.
8. El sistema en el que trabaja tiene resultados predecibles, aprenda a
comprender el sistema.
9. No apueste a su empresa por métodos con un historial deficiente, utilice
métodos con un historial probado.
10. La transformación comienza contigo.

Heart of Agile
Dado que las prácticas ágiles se complejizaron hasta el punto de contradecir alguna de sus
raíces, Heart of Agile viene a encarrilar a la agilidad recuperando la sencillez y potencia de
esta, las cuales se pueden expresar en cuatro palabras:
● Colabora
● Mejora
● Entrega
● Reflexiona
Estas cuatro palabras conforman el kokoro (corazón de la agilidad).
Para tratar el desarrollo de habilidades, se pueden utilizar las palabras “shu”, “ha” y “ri”,
donde:
shu:(“seguir”) es la etapa del aprendizaje en donde el novato aprende copiando al maestro
o de una receta. Esta etapa es la inicial para “aprender una técnica”.

ha: (“separar”) captura la próxima etapa de aprendizaje en la que la persona aprende

diferentes herramientas y técnicas, ya sea por curiosidad o alcanzando límites de las
técnicas que ya conoce. Esta etapa de aprendizaje es la de “técnicas de recolección”.

ri: (“salir”): etapa de práctica en la que la persona opera mediante la respuesta de todo el
cuerpo a situaciones en constante cambio, haciéndolo diferente cada vez. Estas personas
generalmente no pueden decir cómo deciden una técnica en el momento porque está muy
arraigada e inmediata. Esta etapa corresponde a “inventar y combinar técnicas”.

Al estar en esta última etapa, se busca regresar a la esencia y la simplicidad radical,

donde la esencia o corazón se denomina “kokoro” (esencia radicalmente simplificada de un
área de habilidad).

kokoro: representa la etapa de enseñanza del practicante avanzado. Se caracteriza por el

consejo “solo aprende lo básico”.

Tonces, la idea es no pasar por todas las etapas “shu”, “ha”, “ri” para llegar al “kokoro”, sino

🐓
llegar a este siguiendo la premisa de “Solo domina los conceptos básicos”. Donde el
kokoroco (corazón de Agile) es colaborar, entregar, reflexionar y mejorar (estas palabras
son en referencia al equipo, no individualmente).

Escalabilidad
Surge de los problemas que trae tener varios equipos en un solo proyecto.
Debemos coordinar la parte técnica y la gestión de equipos.
Escalamos los valores y principios ágiles.
Retos (consideraciones)
1. Intentar hacer agilidad en toda la empresa. Primero debo probar en un
equipo y luego ir hacia otros equipos. Para esto debo tener en cuenta:
a. Velocidad: cada cuanto hay que salir al mercado.
b. Distribución: la distribución en los equipos.
c. Innovación
d. Tiempo
e. Defectos
f. Complejidad
g. Capacitación
2. Estructura de los equipos. Tengo que tener la cantidad de personas
adecuadas para que el equipo sea multifuncional.
3. Visión estratégica. Tengo que saber la visión de la empresa y saber porqué
quiero ser ágil. Todos deben saber los objetivos.
4. Priorización del product backlog. Debe estar bien definido y bien
priorizado. Se debe realizar la descomposición del product backlog, cuando lo
descompongo, estos deben ser independientes.
5. Planificación de las releases. Todos lo deben conocer y es para todos los
equipos.
6. Gestión de las releases.
7. Feedback de los clientes / usuarios. De otros equipos.
8. Mejora continua y eliminar impedimentos.
9. Coordinar equipos cruzados. A través de políticas. Qué hacemos si
detectamos un error.

Modelo SPOTIFY
SPOTIFY ENGINEERING CULTURE.pdf - Google Drive
Nacieron siendo ágiles con SCRUM. Cuando crecen adaptan SCRUM a más
personas.
Los principios y valores de agilidad son los mismos que los de la empresa.
Al principio siguieron las reglas, luego adoptaron las reglas y en la actualidad, hacen
lo que se conoce como romper las reglas.
Agile coach: es el que sabe de agilidad y guía a los equipos a hacer agilidad. Es
uno para toda la organización.
Tienen sprint planning y un PO de PO.

¿Para escalar scrum se debe aumentar la cantidad de personas en el

equipo?
No.

Cultura ágil interpretada por Spotify

https://www2.deloitte.com/es/es/pages/technology/articles/introduccion-modelo-agile
-spotify.html
Uno de sus principios se basa en tener reglas al comienzo, pero luego romperlas y
crear unas mejores adaptadas a las necesidades de sus equipos y su negocio.
Otro tema interesante es que a los chicos de Spotify no les gustan los roles
definidos por defecto en el framework de scrum y para ello han renombrado el
Scrum Master como Agile Coach, y los Scrum Teams como Squads.
Modelo de trabajo en el sistema de Spotify
Como en cualquier modelo ágil, en spotify hay roles y agrupaciones de estos. Al
contrario que en scrum, las agrupaciones de estos tienen diferentes dimensiones.
Squads ( Equipos, Escuadrones )
Podría equivaler al Scrum Team de Scrum.
Consiste en un pequeño equipo multifuncional y auto-organizado de hasta 8
personas. Es un equipo con responsabilidad de principio a fin y trabajan juntos hacia
una meta a largo plazo. Su clave es la autonomía.
Cada ‘squad’ tiene autonomía para decidir qué hacer y cómo hacerlo, así como la
forma de trabajar juntos para conseguirlo.
A pesar de contar con autonomía, es necesario tenerlos alineados mediante la
‘misión’, la ‘estrategia de producto’ y usar metas a corto plazo.

Emerge la figura del líder, que es el encargado de comunicar el problema que

necesita ser resuelto. Así mismo es responsabilidad del líder el explicar por qué es
necesario resolver dicho problema.
Una vez puestos en situación, es el turno de los ‘squads’ el colaborar entre sí para
encontrar la mejor solución.
Tribus
Las tribus son una estructura matricial bastante ligera que lo que pretende es
agrupar a los ‘squads’ y mantenerlos bajo el foco de un producto. Podemos decir
que agrupa a los ‘squads’ bajo un paraguas de negocio, por ejemplo, el desarrollo
de funcionalidades relativas a la aplicación móvil que la compañía ofrece a sus
clientes.
Las tribus se localizan bajo el mismo espacio físico y el número de squads por tribu
no debe de exceder las 100, aunque generalmente hablamos de números bastante
inferiores.
La estructura de la tribu está concebida para apoyar al grupo de ‘squads’ y
‘chapters’. La tribu en 2012 estaba dirigida por un único líder, a menudo de
ingeniería. El liderazgo de la tribu cambió y ya no es responsabilidad de un solo
individuo, sino de un grupo, los líderes de la tribu, que está formado por personas
representativas del producto, ingeniería, diseño, negocios, etc …, cuya formación
dependerá de las propias necesidades de la tribu.
La clave para el liderazgo de la tribu es que, al igual que el liderazgo del capítulo, se
trata de un liderazgo de servicio.
Chapter ( División, Departamento, Sección )
El ‘chapter’ es otro tipo de agrupación cross-squad, que se focaliza en áreas de
competencia, como por ejemplo, la calidad, el desarrollo front o back, el ux/ui, etc.
Formados con personas que comparten el mismo rol.
Los ‘chapters’ están dirigidos por un ‘chapter lead’, cuyo propósito principal es
apoyar y enfocar el crecimiento de los miembros del ‘chapter’, tanto como individuos
como grupo. También sirven para “evangelizar” sobre las prácticas ágiles a los que
les va mal por así decirlo.
Guild ( Gremio )
Esta organización, más parecida a una comunidad de interés, agrupa a personas de
toda la compañía que quieren compartir conocimiento en un área específica. Es una
comunidad abierta, cualquiera puede unirse al gremio o salir de él en cualquier
momento.
Las personas pueden pertenecer a uno o varios gremios. Cada persona puede
decidir cuál de activo o inactivo es en relación a cada uno de los gremios a los que
está adscrito.
Los gremios también son orgánicos. La intención original del gremio en 2012 era
polinizar y cultivar las maestrías entre las tribus. En la actualidad ha progresado más
allá de eso y los gremios se forman en torno a cualquier interés común, incluso
aquellos que no tienen que ver con el propio producto o negocio.
Alineamiento vs. Autonomía
La autonomía proporciona a los empleados un sentido de propiedad colectiva. Las
personas trabajan con autonomía, dominio y propósito. La autonomía es
motivadora, y las personas motivadas construyen mejores cosas, y también más
rápido. La autonomía nos hace más rápidos al dirigir las decisiones que ocurren
localmente en lugar de los gerentes y comités.
La alineación permite la autonomía. Es importante que todo el mundo entienda la
cultura de la empresa/empresa. Cuanto mayor sea la alineación, mayor será la
autonomía que podamos permitirnos conceder. La autonomía con la alineación
aumenta la motivación, la calidad y también las entregas rápidas.

Spotify pretende (esforzándose) estar a la altura de una alta alineación con una alta
autonomía y siguen experimentando con diferentes formas de hacerlo. Aquí los
líderes se concentran en qué problema necesita ser resuelto y los equipos
averiguan cómo debe ser resuelto dicho problema. De esta manera, la alineación
permite la autonomía. Cuanto mayor sea la alineación, mayor será la autonomía que
puedan permitirse conceder.
En estos pilares se basa principalmente el modelo de éxito, por qué no decirlo, de
Spotify y sus numerosas copias, adaptaciones e implementaciones en el mercado
de las metodologías ágiles.
Prácticas para reducir desperdicio implementadas por Spotify:
● Retrospectiva
● Improvement Boards

SAFe
Metodología ágil para implementar agilidad en toda la empresa, framework para
escalar agilidad muy utilizado y muy criticado.
Se implementa a nivel organizacional, teniendo en cuenta las diferentes áreas de la
organización, pero centrado siempre en el cliente.
Beneficios comerciales de SAFe:
● Engagement
● Productivity
● Quality
● Time-to-market
Competencias básicas requeridas para la agilidad empresarial:
● Enterprise Solution Delivery
● Agile Product Delivery
● Team And Technical Agility
● Lean-Agile Leadership
● Lean Portfolio Management
● Organizational Agility
● Continuous Learning Culture

Tuenti

Agile coaching
Un Agile Coach es una persona que acompaña a personas, equipos y
organizaciones a implementar la “agilidad”.
Su misión: ayudar, guiar, proponer y mentorizar a las personas a adoptar la agilidad
tanto en su forma de hacer (marcos de trabajo, dinámicas, herramientas) como en
su forma de ser (mindset, valores, comportamientos).
El coaching es alguien que te guía y por medio de preguntas te ayuda a descubrir
las respuestas. Es alguien que acompaña, instruye o entrena.
Acompaña a los equipos para tener agilidad en toda la organización y para ello va a
proponer una estratégia ágil para cada área de la organización.
Un agile coach tiene 2 características:
1. Formación en coach.
2. Conceptos de agilidad.
El Agile Coach realiza funciones de Profesor, impartiendo conocimiento sobre agile,
de Facilitador en reuniones y dinámicas de trabajo, de Consultor ofreciendo
sugerencias basadas en sus observaciones, de Mentor al compartir su experiencia
práctica y de Coach haciendo a las personas y equipos preguntas poderosas y
retándolos para que mejoren y logren sus metas.
● Es para toda la organización
● Tiene que saber de agilidad en general
● Evalúa la situación de la empresa y para cada área de esta va proponiendo
diferentes soluciones ágiles
● Busca la cultura agile en toda la organización
El coach debe ser: ¿Qué es un Agile Coach y cuáles son sus competencias?
● Un conocedor de Lean y Agile
● Ser un profesional del coaching.
● Ser un facilitador, es decir, acompañar al equipo sin involucrarse en el
proceso.
● Tener habilidades técnicas: tiene que conocer las herramientas con las cuales
el equipo está trabajando.
● Conocer del negocio para poder buscar las técnicas adecuadas. Si no se
conoce del negocio es más difícil ayudar.
● Conocer sobre procesos de transformación.
● Saber transmitir, es decir, ser un buen profesor.
● Ser un buen guía, un buen motivador.
● Saber dar feedback. El feedback no se debe dar en cualquier momento.
● Estar atento todo el tiempo para poder detectar cuanto antes los conflictos o
desvíos que se dan en el equipo.
Cuando hay conflictos, el coach va a observar, si pasa a mayores va a ser de
mediador y cuando llega a peores casos va a intervenir.
Ciclo de vida
El coach siempre debe ser externo. Cuando todo va bien se va.
Analiza la situación a nivel organización, selecciona un área y observa el problema o
situaciones dentro de esta. Según lo anterior determina diferentes opciones, luego
toma una de estas y la implementa, prueba y experimenta para posteriormente
revisar como fue. Si todo funciona ataca otro problema, sino vuelvo a atacar el
mismo problema con otra opción.
Agile coaching vs Scrum master
Agile couch Scrum master

1 por empresa 1 por equipo

Ayuda a definir qué se debe hacer, Es el líder táctico del equipo. Facilita el
cómo hacerlo, quién lo hace, cuándo uso de técnicas ágiles y ayuda a que
hacerlo y por qué. los impedimentos se resuelvan lo antes
Se encarga de la organización, gestión posible.
de cambios, gestión de personas e Se puede decir también que es la voz
interacciones entre equipos ágiles y del proceso a nivel de equipo.
otras partes de la empresa.
Persiguen la implementación de una
visión organizacional de agile, tienen la
tarea de proporcionar conocimiento,
experiencia, coaching y mentoring al
equipo.

Expansión de la Agilidad

Agile 2
No entra en el parcial
 Unidad 2: Peopleware & Management 3.0
Management y Liderazgo y los diferentes estilos de
gestión, 1.0, 2.0 y 3.0.
Management 1.0 = JERARQUÍA
● Organización: centralizada, jerarquías estrictas.
● Empleados: recursos a administrar, especialización.
● Procesos: predefinidos, atados a políticas y a ciclos de estratégias. Control y orden.
● Principal objetivo: mayor productividad al menor costo.

Empleados:
● Baja motivación.
● Castigo fuerte a los fallos.
● Cultura de temor.
● Mientras más grande más éxito.

Las personas eran prácticamente máquinas, donde la estructura de las organizaciones se

ilustraba con la pirámide de Taylor.

Management 2.0 = TENDENCIAS

● Organización: matricial (administración, proyectos y grupos de trabajo). Centralizado
con optimizaciones locales.
● Empleados: personas a administrar.
● Procesos: acordados, siguiendo ciclos de priorización.
● Principal objetivo: cumplir con las metas propuestas en un ciclo (anuales,
semestrales, etc).

Empleados:
● Hay empresas que empiezan a romper el mercado.
● Se crean modelos para corregir lo que estaba mal.
● Se copian las prácticas superficiales, roles y procesos.

Viene a decir que las personas son los más importante dentro de la organización, donde las
personas del conocimiento no pueden ser subordinados de los gerentes. Sin embargo, esto
chocaba mucho con las viejas jerarquías (obsoletas) que seguían manteniéndose.

Management 3.0 = COMPLEJIDAD

● Organización: redes de personas, equipos de trabajo
● Empleados: talentos a aprovechar
● Procesos: acordados en los equipos, adaptados y revisados cuanto sea necesario.
● Principal objetivo: activar e involucrar a personas e interacciones, mejorar el trabajo
y deleitar a los clientes.
● Lo más importante es el equipo y la estructura organizacional está preparada para
ello. Redefine el liderazgo como una responsabilidad de grupo.
● Es un movimiento de innovación, liderazgo y gestión.
 ● Trabajar juntos para lograr los objetivos de la organización, manteniendo la felicidad
de las personas como una prioridad.

Merit Money: práctica del Management 3.0 para dar recompensas.

Sistema de bonos anuales:

Rara vez tienen un efecto positivo en el desempeño de las personas cuando están
involucradas en un trabajo de conocimiento creativo. Por el contrario, es probable que el
efecto sea negativo. El pago de incentivos se considera perjudicial. El dinero termina siendo
un desmotivador cuando lo uso como premio.
“Los sistemas de bonificación tradicionales rara vez tienen un efecto positivo en el
desempeño de las personas.”

Inconvenientes:
1. Las personas se vuelven adictas a las recompensas periódicas y, si no
obtienen la recompensa anticipada, se sentirán decepcionadas o castigadas.
En última instancia, esto destruye la motivación y, por lo tanto, el rendimiento.
2. Las recompensas individuales interrumpen la colaboración, que es crucial en
el trabajo de conocimiento creativo. Las recompensas individuales estimulan la
competencia y el engaño, lo que destruye las relaciones entre los trabajadores, y
también entre los trabajadores y sus jefes.
3. Los sistemas de bonificación tradicionales se basan en medidas objetivas,
pero la realidad es demasiado compleja para capturarla en números. Las
métricas a menudo ignoran el lado suave del buen desempeño, incluido el trabajo en
equipo y la colaboración.
4. Las recompensas distraen a las personas del trabajo complejo, interrumpen el
pensamiento creativo y aumentan los niveles de estrés de las personas. Esto
hace que jueguen a lo seguro y prefieran las tareas fáciles, mientras que la
innovación requiere lo contrario: asumir riesgos y realizar tareas complejas.
5. Las bonificaciones socavan la motivación intrínseca y el altruismo. Tan pronto
como se entregan las recompensas, la gente comienza a pensar: “Me pagan extra
por este trabajo; por lo tanto, no puede ser divertido, interesante o bueno”.

Appelo dice que el sistema de bono debe enfocarse en ganar por lo que cada persona vale,
no por la idea de hacer más cosas para ganar. Si vas a tener un sistema de bonos, lo mejor
es dividir ese sistema en 2 o 3 momentos en el año. Tanto los salarios como los extras
deben ser brutalmente justos y basados en el mérito, no en la igualdad.

Entonces, para implementar de mejor manera lo anterior, se siguen las siguientes reglas
para así evitar que el premio se piense como un derecho:
1. El empleado debe esperar su sueldo todos los meses, pero no un premio. Si el
premio se da, este debe ser inesperado.
2. Las ganancias deben basarse en la colaboración, no en la competencia. Sino el
equipo nunca va a trabajar como debería de hacerlo.
3. La retroalimentación de los compañeros es la principal medida del
desempeño. Las contribuciones a un propósito compartido son mejor detectadas y
evaluadas por pares, no por gerentes.
 4. Utilice el pensamiento creativo para hacer crecer el sistema de compensación.
Espere que las personas puedan (y lo harán) jugar con cualquier sistema y
aprovechar esa creatividad invitándolo y apoyándolo, en lugar de expulsarlo.
5. Utilice la compensación para nutrir su motivación intrínseca. Haga que el dinero
sea un reflejo de la curiosidad, el honor, la aceptación, el dominio y todos los demás
motivadores intrínsecos de las personas.

Para lograr lo anterior Appelo propone la práctica.

Virtual Currency
Consiste en crear una moneda virtual para representar los méritos que las personas pueden
acumular con el tiempo. Puede usar créditos, puntos, monedas, abrazos, frijoles, dulces,
plátanos o cualquier otra cosa para representar el reconocimiento de las contribuciones de
las personas a la red. Es importante no usar dinero real porque el valor monetario de la
moneda virtual es cero hasta que la gerencia decida que hay una buena razón para
convertir el dinero virtual en dinero real. Ese momento de intercambiar la moneda por dinero
debe ser inesperado.

Reglas:
● No prometer premios por adelantado.
● Si necesariamente se debe decir cada cuánto vamos a revisar las monedas, que sea
mínimo.
● Una vez metido en esta práctica, mantenerla en el tiempo y no olvidarla.
● El reconocimiento debe ser público.
● Se debe reconocer comportamiento.
● El reconocimiento debe venir de los pares, no de los subordinados.

Ejel del Management 3.0:

Culturas tribales: (conocer en qué tribu estás y trabajar en evolucionar a una tribu de una
etapa a otra)
Los responsables y líderes empresariales deberían conocer los grupos que hay dentro de
sus empresas, cómo esos grupos se comunican, qué cultura tienen y cómo son, y, sobre
todo, ser conscientes de la importancia que esto tiene para entender cómo opera la
empresa y hasta dónde puede llegar. Para explicarlo mejor, a dichos grupos les llaman
tribus(se compone entre 20 y 150 personas).
Hay una clasificación de 5 etapas en las que puede estar una tribu, donde la etapa uno es la
menos deseable y la cinco la más polenta y, normalmente, para evolucionar hasta una
etapa hay que pasar antes por las previas. Cada etapa se encuentra identificada con una
frase que representa el sentimiento y la cultura de esa etapa:

● Etapa 1: “La vida es una mierda”

No busco mejorar nada ya que el mundo es una mierda. Se tiene una mentalidad de
pandilla callejera. Las personas en esta etapa son hostiles, desesperadas, violentas
y se unen para salir adelante en un mundo violento e injusto. Ej: org.
gubernamentales.

● Etapa 2: “Mi vida es una mierda”

No está todo mal, pero mi vida es una mierda. La gente en esta etapa se resignan y
cruzan de brazos, son apáticos y desmotivados. Lo peor de esta etapa es que se
transmite la “mala onda”.

● Etapa 3: “Yo soy genial”

Representa un nivel proactivo pero individualista, se premia a las personas y la
competencia entre las personas. Prácticas por ej. empleado del mes, no comparto el
conocimiento (este es el poder). El éxito se mide de forma individual: ventas, obj.
comerciales,etc.

● Etapa 4: “Somos geniales”

Somos geniales como grupo, esta tribu suele tener un grupo con el que rivaliza y
compite, se lo puede tomar en base a lo anterior como “somos geniales”...”y ellos
no”. Genera competencia entre tribus-equipos-grupos. Se ubican en empresas del
management 3.0, tenemos formado un equipo, sabemos trabajar en equipo y
compartimos el conocimiento. El sentimiento de unión es a nivel de equipo.

● Etapa 5: “La vida es genial”

Ese sentimiento de que el grupo va a hacer historia, y no para vencer a un
competidor… sino porque su trabajo tendrá impacto global. Quieren cambiar el
mundo. Esta etapa es de liderazgo puro, visión e inspiración. Es el nivel 4 pero a
nivel organización.

Complexity Thinking, la teoría de la complejidad y las pautas para lidiar

con ella. Comunicación. Toma de Decisiones. Seguridad Sicológica
a. Practicas: Team Barometer, Niko Niko, Happiness Door y Moving Motivators
Para poder motivar a las personas que trabajan conmigo, es importante saber los
motivadores de todos ellos, y esto solo se logra solamente si nos conocemos entre
nosotros.
En management 1.0 y 2.0, para conocer a las personas que trabajan en un equipo
se consideraba importante saber en qué herramientas se especializa cada uno, a
que le gustaría dedicarse y con eso buscaban lograr la cohesión de equipos.
Sin embargo en management 3.0 se busca conocer a las personas de verdad. Para
ello se proponen las siguientes prácticas-técnicas:
Para poder motivar a las personas que trabajan conmigo, es importante saber los
motivadores de todos ellos, y esto solo se logra solamente si nos conocemos entre
nosotros.
1) Personal maps:
● Con esta técnica podemos vislumbrar cómo es la persona
● Lo importante y destacable de la herramienta: está bueno saber los
valores de la gente que trabaja conmigo, ya que los valores de uno no
son negociables.
● Se puede realizar la técnica de 2 maneras diferentes:
i) Haciendo un mapa mental, donde en el centro se ubica nuestro
nombre, y se proponen items para tener en cuenta como:
familia, amigos, objetivos, trabajo, educación.
Aquí cada uno hace y cuenta sobre su mapa personal y en base
a eso se le hacen preguntas.
ii) Nos reunimos de a 2, y cada uno hace el mapa personal del
otro en base a preguntas y luego en ronda se cuenta la historia
del otro.

2) Team Barometer: nos permite ver cómo estamos como equipo para tomar
acciones.

Mal Regular Bien

Colaboración

Compromiso

Confianza

Participación

Motivación
Responsabilidad

3) Speed Dating:
● Es ideal cuando tengo un equipo nuevo y quiero romper el hielo (es
que hicimos en clases).
4) Técnica del monigote:
● Es ideal cuando tengo un equipo nuevo y quiero romper el hielo
● En el monigote agrego cosas que me representan
5) Técnica constructiva: I like, I wish:
● la idea es en una hoja poner mi nombre, dividido la hoja en 2 y en un
lugar pongo like y en otro wish, luego los demás integrantes completan
según sus opiniones.
● se puede realizar a nivel de grupo o individual
● sirve para ver en qué podemos mejorar cada uno y como equipo.

6)

La felicidad/motivación se puede medir:

1) De manera personal:
a) Calendario Niko Niko:
● Se hace un calendario que va pegado en la puerta de la oficina
donde pueda verlo al salir
● En el calendario van los nombres de los integrantes del equipo
● Se eligen emojis
● Cada uno al salir coloca un emoji en el día asociado a su estado
de ánimo
● Cada cierto tiempo, pueden ser 15 días o cuando hay mucha
desmotivación o peleas se pregunta al equipo que sucede y se
busca la manera de brindar ayuda

😄
● Esta técnica es importante porque se dice que si hay:

😐
○ hay 100% de productividad

☹️
○ hay 50% de productividad
○ hay 10% de productividad
b) Happiness door:
● Es similar a Niko Niko pero a nivel organizacional.
 ● Pongo:
○ que me gusta de lo que estoy haciendo
○ cosas que no me afectan en nada
○ que me disgusta
● Es anónima y suele estar en la puerta de la empresa.
● Esta técnica sirve si se hace algo al respecto, sino produce el
efecto contrario es decir me enojo y me desmotivo,
transformándome en una persona X.
c) T-Shirt test:
● Es para saber cómo se sienten identificadas todas las personas
del equipo
● El nombre del equipo es identificador y nos hace sentir
pertenecientes
● El sentimiento de equipo se nota
● Debo generar sentimiento de pertenencia sino no seré un
equipo
● La técnica es ponerse nombre y que el equipo sepa que el
nombre es suyo.

Peopleware: equipos, multifuncionalidad,

auto-organización, etc.
Empoderar equipos: los equipos pueden autoorganizarse, y esto requiere el
empoderamiento, la autorización y la confianza del management.

● Equipos multifuncionales: sin héroes, dentro del equipo tengo todas las
capacidades que necesito, por cada una de estas tengo un experto y al menos otro
que sepa algo, para evitar que dentro del proyecto ese algo dependa de una sola
persona. La idea es que las personas del equipo cuenten con habilidades en T
(amplitud y especialidad).
● Equipos autoorganizados y autogestionados: la gerencia dice el “qué”, y el
equipo decide el “cómo”. Las decisiones se toman por consenso (manera en la cual
se va a trabajar-tomar decisiones).
● Equipo autónomo: capacidad de tomar decisiones, de organización, es adaptable
(a las circunstancias que van sucediendo) y responsable (deben tener claramente
definidas las responsabilidades dentro del equipo).
● El equipo ágil es estable y está “junto”.
Productividad en los equipos - factores que influencian la
productividad.

Entornos de productividad
Se refiere al entorno físico. No se puede medir la productividad de un trabajador del
conocimiento de la misma manera que en otras industrias.
Es importante el tipo de entorno físico donde trabajo, es decir las mesas, escritorios,
ventilación, porque eso influye en la productividad del equipo de trabajo.
La función del gerente es asegurarse de que todas las personas tengan lo que
necesitan para trabajar productivamente y que el trabajo del equipo en malas
condiciones físicas sea menor.
Características que hacen fallar la productividad:
a) Sistemas de fichar:
● Es marcar horario de entrada y salida.
● Son contra productivos ya que va en contra del objetivo del trabajador
del conocimiento.
b) Crunch mode:
● Comienza cuando un hombre dice que nadie cambia el mundo
trabajando solo 40 horas a la semana, sino que deben ser 80 horas
para arriba.
● Esta técnica va en contra de la práctica ritmo sostenible propuesta por
XP donde se busca encontrar las horas en las que el equipo es más
productivo es decir 6 en 8 horas y sostener esos horarios en el tiempo
● Esto permite gestionar el proyecto y hacer planificaciones con el fin de
no necesitar horas extra.
● Se debe recordar que soy menos productivo cuando más cansado
estoy. Pasado el punto de inflexión, los equipos pasan a ser más
destructivos que productivos.
● La técnica de crunch mode consiste en trabajar todo lo que puedas.
Es difícil cuantificar la productividad debido a la intangibilidad del trabajo, por eso es
importante medir la productividad por objetivos-metas-actividades cumplidas o
también por working software (algo que aporte valor al cliente o equipo).
Velocidad del equipo: capacidad de trabajo que tiene un equipo o la cantidad de
tareas-actividades que puede hacer en un determinado tiempo
Cosas que afectan a los entornos:
1. Malas condiciones físicas
2. Luz natural
3. Mala ventilación
4. Sistemas de fichaje (el de registro)
 5. Crunch mode

Productividad en los equipos

Para medir la productividad de un equipo, se puede medir a través de la velocidad
del equipo, tareas/objetivos completados.
Factores que afectan la productividad
1. Tamaño de los equipos
2. Entorno de trabajo
3. Motivación del equipo
4. Interrupciones
a. Externas
b. Internas
5. Reuniones interminables
6. Multitarea
7. Falta de calidad
8. Equipos no multifuncionales
9. Equipos que no sean autoorganizados.
10. Equipos que no sean autónomos, adaptables y responsables.
where is the brack - even ?
¿Qué hace que mi equipo tenga una velocidad menor? (Es decir que la velocidad de
entrega disminuya además de la motivación):
Tamaño de los equipos
La principal causa es el tamaño de los equipos, cuanto más grande es, es más
difícil tomar decisiones.
● Debemos recordar que los equipos deben ser autoorganizados,
autogestionados y pequeños lo que significa que se organizan solos y son
todos responsables de lo que se decide.
● Cuanto más grandes son los equipos es más difícil la coordinación y tengo
más canales de comunicación.
● Una fórmula para calcular cantidad de canales de comunicación es
𝑛(𝑛−1)
2
con n que es la cantidad de personas del equipo

● Lo peor que se puede hacer al estar atrasado en algo es contratar gente

nueva, sin embargo es lo más común. Contratar a alguien nuevo implica 3
meses de tiempo perdido.
● A partir de 9 personas la gente empieza a ser improductiva según Putman,
una cantidad buena es 7 ± 2. Con más de 9 personas en un equipo todo se
complejiza. En procesos de modelado no puedo tener más de 9 personas.
● Es un problema cuando las decisiones se toman entre todos.
Entorno de trabajo
Se refiere a los malos entornos físicos, por ejemplo, una mala organización de las
mesas.
El entorno debe permitir la comunicación osmótica.
Lo mejor es tener oficinas abiertas como por ejemplo, las de google. Para esto
necesitamos ser muy disciplinados y no se deben mezclar los equipos, tener 1
oficina para cada equipo, por ejemplo, nunca se debe tener en una oficina un equipo
de desarrollo y otro de mantenimiento.
Motivación del equipo
Dos tipos de personas:
1. Personas del tipo X: son poco proactivas, resistentes al trabajo. Hay que
persuadir, recompensar, …
2. Personas del tipo Y: tienen necesidades egoístas, sociales, de estimación y
de autorrealización, estas nunca se satisfacen, y si lo hacen es
indirectamente. Se puede volver una persona del tipo X por experiencias
anteriores.
2 tipos de motivaciones:
1. Motivación externa: es el impulso biológico, premios y castigos.
2. Motivación interna: es la que hace que nos levantemos todos los días, es
intrínseca. Es la más fuerte.
Interrupciones
También frena mucho la productividad las interrupciones. Por eso existen técnicas
para evitarlas.
Identificamos las interrupciones cuando al momento de una entrega preferimos
trabajar en cualquier lugar menos en mi lugar de trabajo.
Las interrupciones pueden ser del tipo:
● Internas
● Externas

Internas
● Surgen de la procrastinación, es decir, hago algo que no es urgente cuando
tengo algo urgente para hacer.
● Estas son las peores ya que no puedo negociar con nadie más que conmigo
mismo, el problema soy yo, y tiene que ver con que tan disciplinado es cada
uno.
● Una de las técnicas para evitarlas es la de pomodoro.
Externas
● Son las que se dan por la comunicación entre equipos.
● Es cuando alguien del entorno me interrumpe.
● Es cuestión de organización.
● Son manejables ya que puedo negociar para disminuirlas, aunque, a veces
no se pueden manejar.
Soluciones:
● Se pueden poner horarios para las interrupciones.
● Se pueden habilitar espacios separados para realizar reuniones, trabajo,
atender clientes.
● Deshabilitar notificaciones.

Reuniones interminables
Se maneja usando timebox y una agenda de que se va a hacer en la reunión,
también hay que poner un facilitador, alguien que corte el tema cuando se va por
las ramas.
Acá se comentaba de las reuniones del congreso, que están mal organizadas ya
que no te dan la agenda ni el timebox, esto genera que cuando ya te envian el aviso
de la reunión te desmotives y no hagas bien tu trabajo.
Multitarea
Da la sensación de que no se termina nunca.
Si tengo más de una cosa por hacer pierdo tiempo en el cambio de contexto.
Soluciones:
● Utilizar pomodoro.
● 1 proyecto por día.
● Limitar la cantidad de tareas.
Falta de calidad - Equipo inmaduro técnicamente
Se da cuando algunos miembros del equipo no saben algo, por ejemplo, si soy
desarrollador y no se usar los patrones de diseño.
Alguien no conoce los temas necesarios para el trabajo.
Equipos no multifuncionales
Un equipo multifuncional es aquel que tiene 1 experto y alguien más que sabe del
tema, esto por cada tema necesario.
Se deben tener habilidades en T.
Equipos que no sean autoorganizados
Los equipos autoorganizados son aquellos donde la gerencia dice el que hacer y el
equipo decide el cómo hacerlo.
Equipos que no sean autónomos, adaptables y responsables
Un equipo ágil es autónomo, adaptable y responsable.
Que sea autónomo, es decir, que no dependan de nadie.
Qué sean adaptables, es decir, se adapten a los cambios.
Que sean responsables, es decir, que tengan las responsabilidades definidas,
quién se hace cargo de que cosa.
Similitud con la estructura organizacional
Otra teoría es que los sistemas en equipos de desarrollo tienden a tener igual
estructura que su subsistema de comunicación . Un ejemplo puede ser la estructura
piramidal.

Energize People: Motivación, extrínseca vs. intrínseca,

técnicas.
Energizar a las personas
Las personas son la parte más importante de una organización y los managers
deben hacer todo lo posible para mantener a la gente activa, creativa y motivada.
Motivación extrínseca:
La motivación extrínseca se define como un comportamiento impulsado por
recompensas externas (otorgadas por otros), como dinero, calificaciones y elogios.
Las recompensas se encuentran entre las herramientas de gestión más
complicadas y menos comprendidas. Cuando se aplican de la manera correcta
pueden generar resultados significativos.
Una suposición común entre los gerentes es que nada funciona como el dinero
cuando se quiere que las personas trabajen más duro, por más tiempo o de manera
más efectiva. Además, a menudo se supone que la motivación extrínseca funciona
bastante bien cuando se implementa como un bono financiero. Estas suposiciones
son ambas incorrectas.
Los incentivos para el desempeño en realidad funcionan al revés. La anticipación
de una recompensa (ya sea dinero u otra cosa) funciona de manera
contraproducente, ya que mata la motivación intrínseca de las personas. Los
incentivos aseguran que las personas dejen de hacer cosas solo por el placer de
trabajar. Se llama efecto de sobrejustificación. En lugar de esperar y sentir placer, la
gente espera una recompensa.
Otro problema es que las recompensas basadas en los resultados aumentan el
riesgo de hacer trampa, ya que el enfoque de las personas es obtener una
recompensa en lugar de hacer un buen trabajo. Cuando recompensa a los
empleados según el resultado, tomarán el camino más corto hacia ese resultado.
Los malos comportamientos con efectos secundarios disfuncionales socavan el
desempeño de la organización, mientras que los empleados se van con un bono o
con el fondo de pensión de sus colegas.
La motivación extrínseca, con grandes incentivos basados ​en los resultados, es
como un globo aerostático con una canasta de oro. Es caro, y es difícil hacerlo volar.
“Los incentivos aseguran que las personas dejen de hacer cosas solo por el
placer de trabajar.”
Motivación intrínseca:
Las recompensas que activan la motivación intrínseca son más eficaces, más
sostenibles y, por lo general, cuestan menos dinero. La motivación intrínseca se
define como el comportamiento que se desencadena desde el interior de una
persona. En otras palabras, la persona se está recompensando a sí misma.
Las recompensas pueden funcionar a favor de su organización, y no en su contra, si
tiene en cuenta las siguientes seis reglas:
1. No prometa recompensas por adelantado. Otorgue recompensas en
momentos inesperados para que las personas no cambien sus intenciones y
se concentren en la recompensa. La investigación muestra que, cuando el
reconocimiento de un buen trabajo es una sorpresa, la motivación intrínseca
no se verá socavada.
2. Mantenga pequeñas las recompensas anticipadas. A veces, no puede
evitar que las personas anticipen una recompensa potencial. En tales casos,
según la investigación, es probable que las grandes recompensas reduzcan
el rendimiento. Pero con recompensas pequeñas, el riesgo de perjudicar el
desempeño es insignificante.
 3. Recompense continuamente, no una vez. No busques algo para celebrar
sólo una vez al mes o una vez al año. Cada día puede ser un día para
celebrar algo. Cada día es una oportunidad para una recompensa.
4. Recompense en público, no en privado. Todos deben entender qué se está
recompensando y por qué. El objetivo de dar recompensas es reconocer las
buenas prácticas y hacer que la gente también disfrute del trabajo. Para
lograr esto, un recordatorio público regular funciona mejor que uno privado.
5. Recompense el comportamiento, no el resultado. Los resultados a
menudo se pueden lograr a través de atajos, mientras que el comportamiento
se trata de trabajo y esfuerzo. Cuando te enfocas en el buen comportamiento,
las personas aprenden a comportarse. Cuando te enfocas en los resultados
deseados, las personas pueden aprender a hacer trampa.
6. Recompense a los compañeros, no a los subordinados. Las
recompensas no deben provenir sólo del gerente. Cree un ambiente en el
que las personas se recompensen entre sí porque los compañeros a menudo
saben mejor que los gerentes cuáles de sus colegas merecen un cumplido.
Estas seis reglas para las recompensas le brindan la mejor oportunidad de
aumentar el desempeño de las personas y su disfrute del trabajo, al tiempo que
fomentan la motivación intrínseca en lugar de destruirla. Observe que un cumplido
incidental dirigido a un colega en una reunión por un trabajo bien hecho satisface
casi todos los seis criterios.
12 pasos para la felicidad:
1. Ser agradecidos: se contagia y se genera un ambiente colaborativo.
2. Hacer regalos-reconocimientos físicos: para esto se implementa el
KudoBox (dejar un regalito físico en una caja para repartir cada lapso de
tiempo), esta técnica funciona solamente si todos están de acuerdo con
aplicarla, sino puede tener un impacto negativo.
3. Ayudar desinteresadamente.
4. Comer bien, sano y saludable.
5. Hacer ejercicio.
6. Descansar.
7. Experimentar nuevas cosas, nuevas soluciones o las mismas cosas pero
de diferentes formas.
8. Caminar.
9. Socializar, conocer a otras personas.
10. Meditar.
11. Apunta a una meta y haz que la gente entienda.
12. Sonreir.
Compromiso
Estado transaccional, es un estado de satisfacción, cumplo hasta ahí.
El estado de compromiso lo alcanzó cuando tengo el MAGIC, significado,
autonomía, impacto y conexión con el entorno, en este nivel tenemos un carácter
transformacional.
Al final de la semana tenemos que tener más momentos felices que infelices en el
trabajo.

Empower Teams: Auto-organización de equipos, niveles

de delegación.

Modelo de “Control y Mando”

Deriva del ejército. En SW se lo conoce como modelo clásico, “coding monkey”.
Tiene 3 problemas:
1. El conocimiento lo tienen quienes reciben las órdenes.
2. Una orden la cumplen pocas personas.
3. Equipos pequeños, los equipos grandes son pocos productivos
El que toma las decisiones más difíciles las toma el super líder.

Modelo de liderazgo
Nuevos modelos de liderazgo en equipos ágiles del management 3.0:
● Modelo clásico de “Control y Mando”.
● Super Leader: es quien termina tomando las decisiones más difíciles.
● Servant Leader: toma la postura-rol de facilitador, está pendiente de
quién necesita algo, no toma la postura de solucionador sino de brindar
todo lo que se necesita para que el equipo funcione correctamente.
● Host Leader: es quien toma el rol de anfitrión, es un sirviente del equipo,
incluso se involucra en la solución de problemas con el equipo.
● Guest Leader: es un líder momentáneo. Para lo de compartir el liderazgo
se utiliza la matriz tablero de delegación. Si en esta todas las opciones
quedan después de la columna número 3 no tenemos una figura de líder
único.
Servant Leader

Guest Leader

Tablero de delegación
Es el censo de cómo vamos a tomar las decisiones. Appello define 7 niveles de
toma de decisiones:

1. Tell (Decir) Toma las decisiones y luego informa

Toma las decisiones y cuando informa

2. Sell
cuenta el motivo por el cuál las tomo.
Lider/Jefe Cuando consulta y ahí ve si tomar en
3. Consult cuenta esa opinión o no para tomar la
decisión.

Antes de tomar la decisión pregunta al

4. Agree (Estar de
resto, en este nivel, si se tiene en cuenta la
acuerdo)
opinión de los demás.

Se toman las decisiones pidiendo consejos

5. Advise (Consejo) al jefe, puedo tener en cuenta el consejo o
no.

Equipo Tomó la decisión y luego explico por qué

6. Inquire
tomé esa decisión.

Se delega la toma de decisión a alguien,

este toma una decisión y avisa al resto del
7. Delegate
equipo, en este caso no es necesario
avisarle al líder.
Delegation boards and delegation poker
 Segundo parcial
Service Design thinking
Design thinking es un enfoque constituido por prácticas para diseñar un producto o
servicio. Tiene 4 fases que se tienen que seguir.
Para las organizaciones en la industria de servicios, el pensamiento de diseño de
servicios puede ser la diferencia entre el éxito y el fracaso. Un servicio
correctamente diseñado pone al consumidor en el centro del proceso de diseño; El
pensamiento de diseño de servicios significa organizar recursos y planificar
actividades comerciales con el objetivo de mejorar las experiencias de los
consumidores, así como de los empleados.
"El diseño de servicios ayuda a las organizaciones a ver sus servicios desde la
perspectiva del cliente. Es un enfoque para diseñar servicios que equilibran las
necesidades del cliente con las necesidades del negocio, con el objetivo de
crear experiencias de servicio fluidas y de calidad. El diseño de servicios se basa en
el pensamiento de diseño y aporta un proceso creativo y centrado en el ser humano
para la mejora del servicio y el diseño de nuevos servicios".

Principios
1. Centrado en el usuario, (User-centered o human-centered): Los servicios
deben ser modelados desde la filosofía ponerse en los zapatos del cliente y
ver qué queríamos de experiencia (incluyendo en user tanto clientes como
staff)
2. Co-creative: Todos los stakeholders deben estar incluidos en el proceso de
diseño del servicio → collaborative and cross disciplinary nature of service
design, → equipos multifuncionales
3. Secuenciación (Sequencing): El servicio debe ser visualizado como una
secuencia de acciones interrelacionados → secuencialidad y orden de las
cosas → customer journey maps
4. Evidenciar (Evidencing): Comunicación visual. Los servicios intangibles
deben ser visualizados de manera que se los vea como artefactos físicos →
pensar hacer probar → volver a pensar hacer probar
5. Holistic: Todo el entorno de un servicio debe ser considerado ver al todo en
su conjunto → crear ecosistemas
Si no entendiste: the-5-principles-of-service-design-thinking
Fases

Fuente: ¿Qué es el Design Thinking y por qué es importante? | HBS en línea

Aclarar
La primera fase consiste en reducir el enfoque del proceso de pensamiento de
diseño. Implica identificar la declaración del problema para obtener el mejor
resultado. Esto se hace a través de la observación y tomarse el tiempo para
determinar el problema y los obstáculos que impidieron una solución en el pasado.
Varias herramientas y marcos están disponibles, y a menudo son necesarios, para
hacer observaciones concretas sobre los usuarios y los hechos recopilados a través
de la investigación. Independientemente de las herramientas que se implementen, la
clave es observar sin suposiciones ni expectativas sesgadas.
Una vez que se recopilan los hallazgos de sus observaciones, el siguiente paso es
dar forma a las ideas enmarcando esas observaciones. Aquí es donde puedes
aventurarte en lo abstracto reformulando el problema en forma de una declaración o
pregunta.
Idear
Una vez que la declaración del problema o la pregunta se ha solidificado, no
finalizado, el siguiente paso es la ideación. Puede utilizar una herramienta como el
pensamiento inventivo sistemático (TIE) en esta etapa, que es útil para crear un
proceso innovador que se pueda replicar en el futuro.
El objetivo es, en última instancia, superar la fijación cognitiva e idear ideas nuevas
e innovadoras que resuelvan los problemas que identificó. Continúe evitando
activamente las suposiciones y mantenga al usuario a la vanguardia de su mente
durante las sesiones de ideación.
Desarrollar
La tercera fase consiste en desarrollar conceptos mediante la crítica de una gama
de posibles soluciones. Esto incluye múltiples rondas de creación de prototipos,
pruebas y experimentos para responder preguntas críticas sobre la viabilidad de un
concepto.
Recuerde: este paso no se trata de la perfección, sino más bien, experimentar con
diferentes ideas y ver qué partes funcionan y cuáles no.
Implementar
La cuarta y última fase, la implementación, es cuando todo el proceso se une. Como
una extensión de la fase de desarrollo, la implementación comienza con pruebas,
reflexionando sobre los resultados, reiterando y probando nuevamente. Esto puede
requerir volver a una fase anterior para iterar y refinar hasta que encuentre una
solución exitosa. Se recomienda este enfoque porque el pensamiento de diseño es
a menudo un proceso iterativo no lineal.
En esta fase, no olvide compartir los resultados con las partes interesadas y
reflexionar sobre las estrategias de gestión de la innovación implementadas durante
el proceso de pensamiento de diseño. Aprender de la experiencia es un proceso de
innovación y un proyecto de pensamiento de diseño propio.

Prácticas
Existen muchas prácticas para cada etapa del proceso de design thinking, en la
bibliografía que está en slack hay más.
● Self - Exploration
● Diseño de personas: Cada persona es un modelo de referencia
representativo de un tipo específico de usuarios. Técnicamente, pueden
llamarse arquetipos conductuales cuando se centran en capturar los
diferentes comportamientos (por ejemplo, "el elegido consciente") sin
expresar una personalidad definida o sociodemográfica. Cuanto más los
arquetipos asumen un sentimiento realista (por ejemplo, nombre, edad,
composición del hogar, etc.), más se convierten en personas reales,
expresando plenamente las necesidades, deseos, hábitos y antecedentes
culturales de grupos específicos de usuarios.
● Customer journey maps: El mapa de viaje es una representación sintética
que describe paso a paso cómo un usuario interactúa con un servicio. El
proceso se mapea desde la perspectiva del usuario, describiendo lo que
sucede en cada etapa de la interacción, qué puntos de contacto están
involucrados, qué obstáculos y barreras pueden encontrar. El mapa de viaje a
menudo se integra en capas adicionales que representan el nivel de
emociones positivas / negativas experimentadas a lo largo de la interacción.
● Stakeholders maps: El mapa de partes interesadas es una representación
de todas las partes interesadas involucradas en un proyecto, con el objetivo
 de aclarar roles y relaciones. Dependiendo de la necesidad específica, el
mapa se puede crear como un cuadrante simple con dos ejes (nivel de
influencia y nivel de interés o compromiso en el proceso), o como una matriz
de motivación más compleja (detallando lo que cada parte interesada aporta
a cada uno de los otros a través del proyecto de servicio).
● Value network maps
● Service prototypes: Los prototipos de experiencia permiten a los
diseñadores mostrar y probar la solución a través de una participación activa
de los usuarios finales, que interactúan con maquetas de puntos de contacto
de servicio específicos. Podría haber uno (o más) prototipo para cada punto
de contacto, para recopilar información sobre esa interacción específica, así
como sobre el flujo general de un punto de contacto a otro.
● Model business innovation

Bibliografía
● https://www.designthinking.es/inicio/index.php
● https://servicedesigntools.org/tools

Alinament Diagrams
Introducción a los diagramas de alineación – O'Reilly (oreilly.com)

Lean startup
¿Porque se incluyó en la materia?
El movimiento ágil comienza en los equipos de desarrollo de SW y se extiende por
la industria, los Startups (creación de empresas) es una de estas áreas.
Acá está descripto qué métodos deberían utilizar las startups para empezar a
trabajar.
Es el área de creación de empresas, también se lo llama emprendedurismo.
Lean startup es un método propuesto por Eric Ries. Son los métodos que vimos en
Ing. de SW pero para la creación de empresas.
Objetivos:
● Discutir los riesgos que hay para crear una startup.
2 y 2 son 4, 4 y 2 son 6, 6 y 2 son 8 y 8 __!
Definición de Startup:
● Es una empresa o organización,
● Es una organización formada para buscar un modelo de negocios repetible
y escalable. –Steve Blank
● Una organización formada para crear algo nuevo bajo condiciones de
incertidumbre extrema. –Eric Ries
 ● Si el modelo de negocio está establecido, se puede aplicar pero no vamos a
ser una startup. Puede ser mejor o no.
● No priorizo la rentabilidad actual sino que lo que priorizo es encontrar un
nuevo modelo de negocio que sea repetible, escalable y mejor si es
novedoso (desde el punto de vista de donde se lo aplica o si es
completamente nuevo). Hay que tener en cuenta la región en donde se lo
aplica
● Ej. tenemos a mercado libre, microsoft, google, facebook.

El 98% de las startup fracasan.

La burbuja de las startup.
Es un sector que ya está hace bastante tiempo establecido, donde las tasas de
préstamos eran muy bajas y eso desencadenó una ola de financiamiento. Donde
hoy en día se implementan los capitales de riesgo, que implica invertir un capital en
una bolsa de acciones de x cantidad de startups cruzando los dedos que algunas de
estas x se convierta en el próximo facebook, ML.

Time story de Minoli (tome su chocolate y sus malvaviscos).

A través de una propuesta de dudosa calidad …
uSpeak: duolingo versión manaos
¿Por qué fracasó la startup uSpeak?
1. Se tardó demasiado en lograr un MVP
2. Se subestimó el músculo técnico
3. Se administró mal el dinero
Requisitos para llevar adelante una startup:
1. SER ÁGIL
2. SER ÁGIL.
3. SER ÁGIL
4. y SER ÁGIL.
Ser ágil desde el punto de vista del producto.
Modelo de negocio: cuál es el modelo de negocio y cómo va a ser el esquema de
monetización del producto/servicio.
¿Cómo es trabajar en una startup?
Si queremos empezar en una startup, necesitamos ir al exterior y ya tenemos una
buena base, hay muchos modelos, por lo que no empezamos desde 0.
Ya no es necesario empezar de 0, existe un fuerte ecosistema vigente.(Nos
seguimos cayendo a pedazos aca).
La idea no es lo principal, sino saber montar el entorno en donde la idea se pueda
colocar y hacerla funkar.
Esta buena la idea de las stock options, que implica que tu salario está compuesto
por una remuneración económica y acciones de la empresa que se suelen hacer
efectivas en un tiempo X.
● En una startup sos todo, vas a ser desarrollador, tester, etc., aprendes de
todo.
● Todos los startuperos tienen una red de contacto sólida esto facilita el hecho
de cuando surge una nueva idea, es más “fácil” y rápido el conseguir
financiación. La otra cara de la moneda es que los startuperos suelen quebrar
sus primeras 3 o 4 incursiones.

Desafíos asociados al producto

Crunch base. Es una base de datos con todas las startup, están las ideas.
Las ideas están sobrevaloradas. Si tienes una idea contala, para darte cuenta si va
a funcionar y para tener más ideas.
¿Cantidad o calidad?
Visto en Ing. de SW en la parte de mejora continua. Para tener calidad hace falta
practicar constantemente.
La cantidad hace a la calidad, la práctica does makes a master. La práctica hace a
la calidad, aprender lo antes posible.
No es fallar por fallar, nosotros salimos a validar nuestro modelo y si sale bien
estamos y sino no pasa nada, siempre y cuando aprendamos del error. (Fail fast,
learn faster).

Principios básicos
1. Los emprendedores están en todos lados.
2. Emprendedorismo es gestión.
3. Aprendizaje validado.
4. build – measure - learn. Ciclo iterativo.
5. Contabilidad de la innovación, enfoque basado en datos para tomar
decisiones (Cuánto tiempo tarda desde que un cliente prueba mi app de
manera gratuita hasta que él decide pagar por la suscripción).
Debemos dejar de llamarnos emprendedores, de ahora en mas somos Starters
El taylorismo
“In the past, the man was first. In the future, the system will be first.” – Winslow
Taylor
Tiene un enfoque sistemático para la administración. Uno de los pioneros en decir
que trabajemos con un método ágil pero que sea adaptable.
Lo importante es trabajar con un método, puede ser ágil, adaptable, etc.
3 pasos para la validación (ciclo iterativo). Tengo los 3 pasos en un spring (es el
concepto de SCRUM sacado de software).
1. Construir (build):
2. Medir (measure)
3. Aprender (learn)
El objetivo es crear una organización, no un producto en sí.

clase 21/10
Un modelo de negocio para una startup debe ser escalable porque el modelo cuesta
mucho dinero y no tiene sentido que no sea escalable si no va a poder cubrir todos
los gastos. Si no es escalable nadie va a invertir en tu negocio.
Al principio el objetivo no es ganar dinero.

Validación
3 pasos para la validación
1. Build
2. Measure
3. Lean
Build
Turn ideas into products.
Acá aparece el MVP, es el producto mínimo por el que el cliente te va a pagar(esta
definición queda en Ing. de SW). El MVP lo ocupamos para validar nuestro modelo
de negocio.
El MVP es un artefacto que se utiliza para lograr el cometido que tiene una startup
que es crear y validar un modelo de negocio, validar la idea. Quien valida la idea
son los inversores.
Cualquier cosa que me sirva para validar el modelo de negocio es un MVP, hay que
ser creativos. Tenemos que decir cómo vamos a validar el modelo de negocio.
Ideas sobran, lo que falta son equipos para ejecutarla.
La idea es lo que quiero hacer, el modelo de negocio es la idea y algunas cosas
más.
Ejemplos de MVP:
1. MVP con funcionalidad mínima. Gmail: “la primera versión de Gmail fue
escrita en 1 día.” Y lanzaron una beta donde te tenían que invitar para formar
parte, salió con la funcionalidad básica.
2. Video explicativo. El MVP de Dropbox fue un video. Creo esto para explicar
 qué es lo que quería hacer. Un ej. de antipatrón es no presentar la idea
hasta tener todo una versión del producto para mostrar.
3. Una landing page. Ejemplo, PeopleiTrust. Microsoft está aplicando esto con
los productos nuevos de Azure. Cuando tienen una idea lo ponen en la
página de Azure, sin que funcione (Form Recognizer).
4. A single featured MVP. Google “solo” era un buscador cuando se lanzó. Por
más que tu idea abarque muchas cosas céntrate en aquellas por las cuales el
usuario te va a amar mucho.
5. Concierge MVP. Consiste en simular el servicio. Estudiar bien mi modelo de
negocio y a qué clientes quiero llegar. El supermercado food on the table
hizo esto.
Food on the table simuló de la siguiente forma: como no sabía cómo se comportan
sus clientes potenciales, y no tenia los mecanismos de distribución, hizo una serie
de interacciones con una técnica de dising thinking, en la primera iteración fue
hablando con la gente sobre cómo compra, donde, cada cuanto, luego en la
segunda iteración le ofreció que cada tantos dias el se ofreció a hacerles la
compras, en la tercera iteración, lo llevó a otros barrios, cuarta iteración, contrató a
un grupo de personas para que haga eso, y así hasta que sabía cada cuánto llamar,
que compraba, con esto pudo tener establecido el MVP para estos proveedores, y
con eso creó la web.
No podemos esperar a tener todo desarrollado para lanzarlo, si nuestra primera
versión del producto no nos da vergüenza, estamos llegando tarde al mercado.
Ver película de Steve Jobs, primero tenemos que leer el libro, estamos obligados
moralmente a leerlo antes de terminar la carrera.
Lo que importa es que haya capitalismo, porque el socialismo no financia un choto.
Measure
See how customers respond.
Distintas formas de medir:
1. Estimar: si no es estimar, es observar, no se. Siempre se tienen que crear
planes, aunque se tengan números muy estimativos son fundamentales
tenerlos.Es difícil crear planes, hay que estimar. Ej, creamos el MVP en
diciembre, luego en febrero voy a tener 300 clientes, y así, estimamos
cuantos clientes vamos a tener.
2. Con la técnica de dising thinkings, la de salir a la calle a hablar.
3. Split testing: Se puede usar un A/B testing. Esta técnica (canary release??
por lo que entendí es medio lo mismo) era la que a algunos usuarios le da la
versión nueva y a otros le dejas la vieja, y con esto haces una comparación
entre el desempeño de ambas versiones.
Lean
pivot or persevere.
Es necesario entonces tener métricas consistentes.
Al final de todo esto, de build y measure tengo que aprender, me sirve para
aprender.
Al momento de probar la idea, puede que los números vayan para otro lado y no
para el que queramos, entonces podemos proponer pivotear un poco la idea o
esperar un poco más porque pensamos que le falta un poco de tiempo para que
cierren los números.
Tengo que decidir si voy para algún lado (pivotar) o seguir como estoy (perseverar)
Pivots
1. Zoom in: Pasar de algo general a algo más enfocado. Por ejemplo, Flicker,
es una red social orientada a fotografía. Empezó siendo una red social
general como Facebook y luego hicieron un zoom in y se enfocan en ser una
red social para fotografía. Es el pivot más común al principio.
2. Zoom out: Lo contrario a zoom in, pasas de algo enfocado a algo más
general, ejemplo, Instagram.
3. Customer segment: Cuando empezamos enfocados a un segmento-”nicho”
de clientes y con el tiempo nos enfocamos en otro segmento de clientes.
4. Customer need: Cuando detectamos que la necesidad que intentó cubrir no
es la adecuada, identificó que mi cliente necesita algo pero para escalar
tengo que enfocarme en otra necesidad.
5. Platform: la plataforma que tenemos no es la indicada, por ende la
cambiamos. Soy una empresa de telefonía fija y luego pasó a ser una de
telefonía móvil.
6. Business architecture: cuando tengo que cambiar la arquitectura de
negocio, ejemplo la forma de facturar. Está muy relacionado a la forma de
factura. Por ejemplo, Netflix que empezó como un videoclub donde
comprabas la película y pasó a ser lo que es hoy en día.
7. Value capture: en qué parte vamos a meter efectivo para capturar el valor
que pueden aportar los clientes. Donde le aporto valor al cliente. Ejemplo,
empezar vendiendo comida desde tu casa y luego pasar por pedidos de los
clientes para tener mesas entonces paso a alquilar una rosticería. Otro
ejemplo con el ejemplo anterior es el de agregarle un servicio de delivery.
8. Engine of growth: como hago para crecer, que utilizo para crecer. Cual es el
motor por el cual voy a crecer. Por ej: estrategias de viralización. Engines of
Growth
a. Motor de crecimiento pegajoso (Sticky Engine): retener a los
clientes (describir las otras 2 clasificaciones!)
b. Viral Engine
c. Paid Engine
d. UX Drives Every Engine
9. Channel: cual es el canal de distribución, como hago llegar el producto a los
clientes.
Otras prácticas
1. The five whys: Preguntarse por qué están pasando las cosas.
2. Which activities create value?
3. Which are waste?
4. Find and fix root causes.

Plan de negocios
Un plan de negocios es un documento donde hacemos la preparación de como va a
funcionar mi negocio acá a 5 años, contiene presupuestos, costos, amortizaciones…
es la planificación en sí. Si no se que voy a hacer en el negocio no podré hacer un
plan de negocios.
En vez de un plan de negocios, en las Startup utilizan la práctica:
● Business Model Generation (está el libro con el mismo nombre)
Business model generation → si te aporta valor usalo crack
(justificación para usar esto y no un modelo de negocio clásico)
Presenta el business model de Canvas (lienzo) → es una herramienta gráfica para
describir el modelo de negocio.
La idea es tener el modelo de negocio a la vista de todos (transparencia). Es una
práctica ágil para la creación del modelo del negocio.
Bloques del modelo, que me dicen cada uno:
1. Qué hacer
2. Quien
3. Como hacer
4. Como fluye el dinero en este modelo
Partes de los 4 bloques mencionados arriba:
1. Segmento de clientes
2. Propuesta de valor: Porque los clientes van a pagar por nuestro producto.
3. Canales de distribución y comunicaciones
4. Relación con el cliente: porque nos van a amar, puede ser que nos amen por
algo y no paguen por otra cosa
5. Flujos de Ingreso
6. Actividades claves: en que tengo que ser muuuuy bueno, en esto voy a
buscar los recursos claves
7. Red de partness:
8. Estructura de costos:
9. Recursos clave:

Como Que Quién

$
Segmentos de clientes:
● Mercado masivo
● Mercado de nicho
● Mercado segmentado
● Mercado diversificado: a varios segmentos a la vez
● Plataformas multipartner: son aquellos productos o servicios en los cuales
tengo por lo menos 2 clientes (prosumidor y consumidor). Ej: Uber, Youtube,
cualquier plataforma que haga de intermediario.
Propuesta de valor:
● Newness, novedoso
● Performance. Tener mejor performance
● Customización: Lo hago específicamente para vos.
● “Getting the job done”: mi propuesta es que simplemente funciona, ej: los de
Elon Mask. paypal, tesla
● Desing. Diseño como apple (el mismo ladrillo todos los años)
● Brand/status. status o marca.
● Price. Precio, algo más barato.
Normalmente solo puedo ir por uno, no puedo tener más de uno.
Canales de distribución

Relaciones con el cliente

Flujos de Ingreso:
Acá entra lo de monetización.
Red de Partners (socios estratégicos)
Que personas necesito que lo hagan muy bien, lo que no es necesario hacerlo muy
bien, lo saco a partners.
Se divide en:
● Key activities: Actividades que tengo que hacer muy bien.
● Key resources: Qué necesito, recursos claves.
● Key partners: Son los socios. Alianzas claves, me sirven para cumplir con el
aporte de valor hacia el cliente.
Que tengo que hacer muy bien y lo tengo que hacer yo, que personas necesito que
hagan eso muy bien y todo lo que no sea necesario que tenga que hacerlo yo muy
bien lo tengo que sacar aparte.
Ejemplo mercado libre
● Clientes
○ Vendedor
○ Comprador
● Partners
○ Empezó Andreani que lo movieron hacia Key activities.
○ Bancos
● Key activities
○ Distribuidores, Andreani
● Propuesta de valor
○ No tiene nada, pero por ejemplo, para Amazon sería Alexa.
Partes
Como
● Key Partners
● Key Activities
● Key Resources
Qué
● Value Propositions
● Customer Relationships
● Channels
● Customer Segments
Como fluye el dinero
● Cost Structure
● Revenue Streams

Monetización
Modelo freemium
Concepto de Free + Premium: la parte free es el motor, y la parte premiun te
facturan. Es cuando te da algo gratis y te cobra otras cositas. Se da mucho en los
negocios de media.
Bonus: funnel de conversión
Cantidad de dinero destinada a obtener un nuevo cliente, la pregunta ahora es, que
consideramos un nuevo cliente??, se trata de los distintos estadios por los que van
pasando los clientes potenciales.
Los que se encargan especialmente de esto (túnel de conversión) son los que llevan
adelante el estudio de Customer Churn.
Ejemplos: aseguradoras, telefónicas, stream…

Intro a MLOps:
Básicamente data
Base de datos relacionales o no relacionales son entornos de datos transaccionales
OLTP. Los entornos de datos no transaccionales son los analíticos OLAP.
Entornos OLAP:
● Detección de fraude
● DSS. Data warehouse
● Los que están en la cima de la pirámide que dimos en Sistemas y
Organizaciones → Sistemas Gerenciales
● Machine learning: customer churn
 OLTP Modelo relacional. Cood ‘70 IBM
Mediado de los 80’ pegan el BOOM
A mediados de los 90’ aparece la información semiestructurada con
Internet. JSON - XML
NoSQL (aparecen para relajar un poco las restricciones de SQL)
en 2012 Big Data vienen las 3 V (Velocidad, Volumen, Variedad)

OLAP A partir de los 90’ se habla de Data Warehousing. - Copo de nieve,

estrella, etc.
Business intelligence 00´
Machine learning 2012/15

OLTP Modelo Semiestructur No

relacional. ada estructurada
Cood ‘70 IBM JSON - XML Big Data
Mediado de NoSQL
los 80’ , 90’ DATA
pegan el PRODUCT
BOOM

OLAP Data Business Machine

Warehousing intelligence learning
00´ 2012/15

Data product: unión de OLTP y OLAP, mezclar cualquier tipo de datos(estr, semi. y
no estr.) de OLTP con algún tipo de procesamiento de OLAP.
Disciplinas:
1. Operalización de Modelos: (MLOPS)
2. Estratégia de Organización de Datos: Hasta el año pasado había ideas dando
vueltas y alguien lo puso en un libro con Martin Fowler, la idea se llama ‘Data
Mesh’, esto es la última moda.
Leer de Kimbell y Data Mesh si queres hacer plata
DevOps es una disciplina, conjunto de prácticas.
MLOPS es una subclase de DEVOPS en la cual nos especializamos para llevar esto
a un modelo de machine learning.
En un modelo transaccional tengo Datos y el código, y lo hago con DevOps con los
pipeline.
En un modelo de machine learning, tengo
MLOps es DevOps pero para machine learning.
1. Desarrollar entornos de ML no es lo mismo que desarrollar sistemas
tradicionales.
Clase 28/10

Características particulares de ML
Los modelos complejos erosionan los límites
La práctica tradicional de la ingeniería de software ha demostrado que los fuertes
límites de abstracción que utilizan la encapsulación y el diseño modular ayudan a
crear un código mantenible en el que es fácil realizar cambios y mejoras aislados.
Los límites estrictos de abstracción ayudan a expresar las invariantes y la
consistencia lógica de las entradas y salidas de información de un componente
determinado [8].
Desafortunadamente, es difícil imponer límites de abstracción estrictos para los
sistemas de aprendizaje automático prescribiendo un comportamiento previsto
específico. De hecho, se requiere ML exactamente en aquellos casos en los que el
comportamiento deseado no se puede expresar de manera efectiva en la lógica del
software sin depender de datos externos. El mundo real no encaja en una
encapsulación ordenada. Aquí examinamos varias formas en que la erosión
resultante de los límites puede aumentar significativamente la deuda técnica en los
sistemas de ML.

Enredo
Los sistemas de aprendizaje automático mezclan señales, enredándose y haciendo
imposible el aislamiento de mejoras. Por ejemplo, considere un sistema que usa las
características X1, ... Xn en un modelo. Si cambiamos la distribución de valores de
entrada en X1, la importancia, los pesos o el uso de las características N - 1
restantes pueden cambiar. Esto es cierto si el modelo se reacuna completamente en
un estilo por lotes o se permite adaptarse de manera en línea. Agregar una nueva
característica XN+1 puede causar cambios similares, al igual que la eliminación de
cualquier característica XJ. Ningún aporte es realmente independiente. Nos
referimos a esto aquí como el principio de CACE: cambiar cualquier cosa lo cambia
todo. CACE se aplica no solo a las señales de entrada, sino también a los hiper
parámetros, la configuración de aprendizaje, los métodos de muestreo, los umbrales
de convergencia, la selección de datos y esencialmente todos los demás posibles
ajustes.
Una posible estrategia de mitigación es aislar modelos y servir conjuntos. Este
enfoque es útil en situaciones en las que los sub moscones se descomponen
naturalmente, como en entornos de clase múltiple disjunta como [14]. Sin embargo,
en muchos casos, los conjuntos funcionan bien porque los errores en los modelos
de componentes no están correlacionados. Confiar en la combinación crea un fuerte
enredo: mejorar un modelo de componentes individuales puede empeorar la
precisión del sistema si los errores restantes están más fuertemente correlacionados
con los otros componentes.
Una segunda estrategia posible es centrarse en detectar cambios en el
comportamiento de predicción a medida que ocurren. Uno de estos métodos se
propuso en [12], en el que se utilizó una herramienta de visualización de alta
dimensión para permitir a los investigadores ver rápidamente los efectos en muchas
dimensiones y cortes. Las métricas que operan sobre una base por corte también
pueden ser extremadamente útiles.

Cascadas de corrección
A menudo hay situaciones en las que existe el modelo MA para el problema A, pero
se requiere una solución para un problema ligeramente diferente A '. En este caso,
puede ser tentador aprender un modelo M 'A que toma MA como entrada y aprende
una pequeña corrección como una forma rápida de resolver el problema.
Sin embargo, este modelo de corrección ha creado una nueva dependencia del
sistema de MA, lo que hace que sea significativamente más costoso analizar
mejoras en ese modelo en el futuro. Los costos aumentan cuando los modelos de
corrección se cascan, con un modelo para el problema A '' aprendido además de M
'A, y así sucesivamente, para varias distribuciones de prueba ligeramente diferentes.
Una vez en su lugar, una cascada de corrección puede crear un punto muerto de
mejora, ya que mejorar la precisión de cualquier componente individual en realidad
conduce a detrimentos a nivel del sistema. Las estrategias de mitigación son
aumentar MA para aprender las correcciones directamente dentro del mismo
modelo agregando características para distinguir entre los casos o aceptar el costo
de crear un modelo separado para A '.

Consumidores no declarados
A menudo, una predicción de un modelo de aprendizaje automático MA se hace
ampliamente accesible, ya sea en tiempo de ejecución o escribiendo a archivos o
registros que luego pueden ser consumidos por otros sistemas. Sin controles de
acceso, algunos de estos consumidores pueden ser no declarados, utilizando
silenciosamente la salida de un modelo dado como una entrada para otro sistema.
En la ingeniería de software más clásica, estos problemas se denominan deuda de
visibilidad [13].
Los consumidores no declarados son caros en el mejor de los casos y peligrosos en
el peor, porque crean un acoplamiento apretado oculto del modelo MA a otras partes
de la pila. Es muy probable que los cambios en MA afectarán a estas otras partes,
potencialmente en formas no intencionadas, mal entendidas y perjudiciales. En la
práctica, este acoplamiento apretado puede aumentar radicalmente el costo y la
dificultad de hacer cualquier cambio en MA en absoluto, incluso si son mejoras.
Además, los consumidores no declarados pueden crear bucles de retroalimentación
ocultos, que se describen más en detalle en la Sección 4.
Los consumidores no declarados pueden ser difíciles de detectar a menos que el
sistema esté diseñado específicamente para protegerse contra este caso, por
ejemplo, con restricciones de acceso o acuerdos de nivel de servicio (SLA). En
ausencia de barreras, los ingenieros usarán naturalmente la señal más conveniente
en cuestión, especialmente cuando trabajan contra las presiones de la fecha límite.
Las dependencias de datos cuestan más que las dependencias de
código
En [13], la deuda de dependencia se observa como un contribuyente clave a la
complejidad del código y la deuda técnica en la configuración de ingeniería de
software clásico. Hemos encontrado que las dependencias de datos en los
sistemas ML tienen una capacidad similar para construir deuda, pero pueden ser
más difíciles de detectar. Las dependencias de código se pueden identificar
mediante análisis estático por compiladores y enlazadores. Sin herramientas
similares para dependencias de datos, puede ser inapropiadamente fácil construir
grandes cadenas de dependencia de datos que pueden ser difíciles de desenredar.

Dependencias de datos inestables

Para moverse rápidamente, a menudo es conveniente consumir señales como
características de entrada producidas por otros sistemas. Sin embargo, algunas
señales de entrada son inestables, lo que significa que cambian cualitativamente o
cuantitativamente el comportamiento con el tiempo. Esto puede suceder
implícitamente, cuando la señal de entrada proviene de otro modelo de aprendizaje
automático que se actualiza con el tiempo, o una tabla de búsqueda dependiente de
datos, como para calcular las puntuaciones TF/IDF o las asignaciones semánticas.
También puede ocurrir explícitamente cuando la propiedad de ingeniería de la señal
de entrada está separada de la propiedad de ingeniería del modelo que lo consume.
En tales casos, las actualizaciones de la señal de entrada se pueden realizar en
cualquier momento. Esto es peligroso porque incluso las "mejoras" a las señales de
entrada pueden tener efectos perjudiciales arbitrarios en el sistema consumidor que
son costosos de diagnosticar y abordar. Por ejemplo, considere el caso en el que
una señal de entrada estaba previamente calibrada. El modelo que consume es
probable que se ajuste a estas calibraciones erróneas, y una actualización
silenciosa que corrige la señal tendrá ramificaciones repentinas para el modelo.
Una estrategia de mitigación común para dependencias de datos inestables es crear
una copia versionada de una señal dada. Por ejemplo, en lugar de permitir que un
mapeo semántico de las palabras a los grupos de temas cambie con el tiempo,
podría ser razonable crear una versión congelada de este mapeo y usarla hasta que
un momento como una versión actualizada haya sido completamente examinada.
Sin embargo, el verso conlleva sus propios costos, como la posible estatidad y el
costo de mantener múltiples versiones de la misma señal con el tiempo.

Dependencias de datos subutilizadas

En el código, las dependencias subutilizadas son paquetes que en su mayoría son
innecesarios [13]. Del mismo modo, las dependencias de datos subutilizadas son
señales de entrada que proporcionan poco beneficio de modelado incremental.
Estos pueden hacer que un sistema ML sea innecesariamente vulnerable al cambio,
a veces catastróficamente, a pesar de que podrían eliminarse sin detrimento.
Como ejemplo, suponga que para aliviar la transición de un esquema de
numeración de producto antiguo a los números de nuevos productos, ambos
esquemas se dejan en el sistema como características. Los nuevos productos solo
obtienen un número nuevo, pero los productos antiguos pueden tener ambos y el
modelo continúa dependiendo de los números antiguos para algunos productos. Un
año después, se elimina el código que deja de poblar la base de datos con los
números antiguos. Este no será un buen día para los mantenedores del sistema ML.
Las dependencias de datos subutilizadas pueden arrastrarse a un modelo de varias
maneras.
● Características heredadas. El caso más común es que una característica F
se incluye en un modelo temprano en su desarrollo. Con el tiempo, F se
vuelve redundante por nuevas características, pero esto no se detectó.
● Características agrupadas. A veces, se evalúa un grupo de características y
se encuentra que es beneficioso. Debido a las presiones de la fecha límite o
efectos similares, todas las características del paquete se agregan juntos al
modelo, posiblemente incluyendo características que agregan poco o ningún
valor.
● 𝝐-Features. Como investigadores de aprendizaje automático, es tentador
mejorar la precisión del modelo incluso cuando la ganancia de precisión es
muy pequeña o cuando la sobrecarga de complejidad podría ser alta.
● Características correlacionadas. A menudo, dos características están
fuertemente correlacionadas, pero una es más directamente causal. Muchos
métodos de ML tienen dificultades para detectar esto y acreditar las dos
características por igual, o incluso pueden elegir la no causal. Esto da como
resultado la fragilidad si el comportamiento mundial luego cambia las
correlaciones.
Las dependencias subutilizadas se pueden detectar mediante evaluaciones
exhaustivas de salida de una sola característica. Estos deben ejecutarse
regularmente para identificar y eliminar características innecesarias.

Consumidores no declarados
Circuitos de retroalimentación
Una de las características clave de los sistemas Live ML es que a menudo terminan
influyendo en su propio comportamiento si se actualizan con el tiempo. Esto lleva a
una forma de deuda de análisis, en la que es difícil predecir el comportamiento de
un modelo dado antes de que se libere. Estos bucles de retroalimentación pueden
tomar diferentes formas, pero todos son más difíciles de detectar y abordar si
ocurren gradualmente con el tiempo, como puede ser el caso cuando los modelos
se actualizan con poca frecuencia.

Bucles de retroalimentación directa

Un modelo puede influir directamente en la selección de sus propios datos de
entrenamiento futuros. Es una práctica común usar algoritmos supervisados
estándar, aunque la solución teóricamente correcta sería usar algoritmos de
bandidos. El problema aquí es que los algoritmos de bandidos (como los bandidos
contextuales [9]) no necesariamente se reducen bien al tamaño de los espacios de
acción que generalmente se requieren para problemas del mundo real. Es posible
mitigar estos efectos utilizando cierta cantidad de aleatorización [3], o aislando
ciertas partes de los datos de ser influenciadas por un modelo dado.

Bucles de retroalimentación oculta

Los bucles de retroalimentación directa son costosos de analizar, pero al menos
plantean un desafío estadístico que los investigadores de ML pueden encontrar
natural para investigar [3]. Un caso más difícil son los bucles de retroalimentación
ocultos, en los que dos sistemas se influyen entre sí indirectamente a través del
mundo.
Un ejemplo de esto puede ser si dos sistemas determinan de forma independiente
las facetas de una página web, como una selección de productos para mostrar y
otro seleccionando revisiones relacionadas. Mejorar un sistema puede conducir a
cambios en el comportamiento en el otro, ya que los usuarios comienzan a hacer
clic más o menos en los otros componentes en reacción a los cambios. Tenga en
cuenta que estos bucles ocultos pueden existir entre los sistemas completamente
disjuntos. Considere el caso de dos modelos de predicción del mercado de valores
de dos compañías de inversión diferentes. Las mejoras (o, con mayor miedo,
errores) en uno pueden influir en el comportamiento de licitación y compra del otro.
ML-System Anti-Patterns
Puede ser sorprendente para la comunidad académica saber que solo una pequeña
fracción del código en muchos sistemas ML en realidad está dedicada al
aprendizaje o la predicción; ver Figura 1. En el lenguaje de Lin y Ryaboy, gran parte
del resto puede describirse como "plumbing" [11].
Desafortunadamente, es común que los sistemas incorporen métodos de
aprendizaje automático para terminar con patrones de diseño de alta deuda. En esta
sección, examinamos varios antipatrones de diseño del sistema [4] que pueden
surgir en los sistemas de aprendizaje automático y que deben evitarse o refactorizar
siempre que sea posible.
Código de pegamento
Los investigadores de ML tienden a desarrollar soluciones de propósito general
como paquetes autónomos. Una amplia variedad de estos están disponibles como
paquetes de código abierto en lugares como Mloss.org, o desde el código interno,
los paquetes patentados y las plataformas basadas en la nube.
El uso de paquetes genéricos a menudo da como resultado un patrón de diseño del
sistema de código de pegamento, en el que se escribe una gran cantidad de código
de soporte para obtener datos dentro y fuera de los paquetes de propósito general.
El código de pegamento es costoso a largo plazo porque tiende a congelar un
sistema a las peculiaridades de un paquete específico; Las alternativas de prueba
pueden volverse prohibitivamente costosas. De esta manera, el uso de un paquete
genérico puede inhibir mejoras, ya que hace que sea más difícil aprovechar las
propiedades específicas del dominio o ajustar la función objetivo para lograr un
objetivo específico del dominio. Debido a que un sistema maduro podría terminar
siendo (como máximo) código de aprendizaje automático del 5% y (al menos)
código de pegamento del 95%, puede ser menos costoso crear una solución nativa
limpia en lugar de reutilizar un paquete genérico.
Una estrategia importante para combatir el código de pegamento es envolver
paquetes de caja negra en API comunes. Esto permite que la infraestructura de
soporte sea más reutilizable y reduce el costo de cambiar los paquetes.

Pipeline Jungles
Como un caso especial de código de pegamento, Pipeline Jungles a menudo
aparecen en la preparación de datos. Estos pueden evolucionar orgánicamente, ya
que se identifican nuevas señales y se agregan nuevas fuentes de información de
forma incremental. Sin cuidado, el sistema resultante para preparar datos en un
formato de ML con ML puede convertirse en una jungla de rasguños, uniones y
pasos de muestreo, a menudo con salida de archivos intermedios. Gestionar estas
pipeline, detectar errores y recuperarse de fallas son difíciles y costosos [1]. Probar
tales pipelines a menudo requiere costosas pruebas de integración de extremo a
extremo. Todo esto se suma a la deuda técnica de un sistema y hace que la
innovación sea más costosa.
Las Pipeline Jungles solo se pueden evitar pensando de manera integral sobre la
recopilación de datos y la extracción de características. El enfoque de limpieza de la
pizarra de desechar una Pipeline Jungles y rediseñar desde cero es una gran
inversión de esfuerzo de ingeniería, pero que puede reducir drásticamente los
costos continuos y acelerar una mayor innovación.
El código de pegamento y las Pipeline Jungles son sintomáticos de los problemas
de integración que pueden tener una causa raíz en los roles de "investigación" e
"ingeniería" demasiado separados. Cuando los paquetes ML se desarrollan en una
configuración de IvoryTower, el resultado puede aparecer como cajas negras para
los equipos que los emplean en la práctica. Un enfoque de investigación híbrida
donde los ingenieros e investigadores están integrados en los mismos equipos (y de
hecho, a menudo son las mismas personas) puede ayudar a reducir
significativamente esta fuente de fricción [16].

Dead Experimental Codepaths

Una consecuencia común del código de pegamento o las pipeline jungles es que se
vuelve cada vez más atractivo a corto plazo realizar experimentos con métodos
alternativos mediante la implementación de codepaths experimentales como ramas
condicionales dentro del código de producción principal. Para cualquier cambio
individual, el costo de experimentar de esta manera es relativamente bajo: ninguno
de los alrededores debe reelaborar. Sin embargo, con el tiempo, estos códices
acumulados pueden crear una deuda creciente debido a las crecientes dificultades
de mantener la compatibilidad hacia atrás y un aumento exponencial en la
complejidad ciclomática. Probar todas las interacciones posibles entre los códices
se vuelve difícil o imposible. Un famoso ejemplo de los peligros aquí fue el sistema
de Knight Capital que perdió $ 465 millones en 45 minutos, aparentemente debido al
comportamiento inesperado de los códices experimentales obsoletos [15].
Al igual que con el caso de las banderas muertas en el software tradicional [13], a
menudo es beneficioso reexaminar periódicamente cada rama experimental para
ver qué se puede arrancar. A menudo, solo se usa un pequeño subconjunto de las
posibles ramas; Muchos otros pueden haber sido probados una vez y abandonados.

Deuda de abstracción, deuda de configuración, Deuda de

reproducibilidad, deuda de gestión de procesos
Los problemas anteriores destacan el hecho de que existe una clara falta de
abstracciones fuertes para respaldar los sistemas ML. Zheng recientemente hizo
una comparación convincente de las abstracciones ML del estado con el estado de
la tecnología de la base de datos [17], lo que hace que nada en la literatura de
aprendizaje automático se acerca al éxito de la base de datos relacional como una
abstracción básica. ¿Cuál es la interfaz correcta para describir un flujo de datos, un
modelo o una predicción?
Para el aprendizaje distribuido en particular, queda una falta de abstracciones
ampliamente aceptadas. Se podría argumentar que el uso generalizado de la
reducción de mapas en el aprendizaje automático fue impulsado por el vacío de
fuertes abstracciones de aprendizaje distribuido. De hecho, una de las pocas áreas
de amplio acuerdo en los últimos años parece ser que MAP-Reduce es una mala
abstracción para los algoritmos de ML iterativos.
La abstracción de parámetros-servidor parece mucho más robusta, pero hay
múltiples especificaciones competitivas de esta idea básica [5, 10]. La falta de
abstracciones estándar hace que sea demasiado fácil desdibujar las líneas entre los
componentes.
DataMesh
Es otra cosa como el MLOps pero no es para Machine Learning.
El data mesh es un paso más hacia la personalización de los productos o servicios
que las empresas ofrecen a cada cliente, pues jerarquiza los niveles de datos y, a su
vez, hace los procesos más rápidos para las necesidades digitales que demanda el
mercado.

Al fin y al cabo, el usuario navega desde más de un dispositivo y las

sincronizaciones entre ellos deben ser ágiles. El data mesh permite esto, que los
productos de datos se unan entre dominios permitiendo el intercambio de datos sin
almacén.