Este documento presenta una charla sobre ingeniería de software y desarrollo de productos digitales. Comienza reflexionando sobre la predicción del futuro y las revoluciones tecnológicas. Luego discute el cambio del pensamiento de proyecto a producto, así como prácticas relacionadas con la entrega de valor como mostrar el trabajo y reducir las dependencias. Finalmente, presenta conceptos como el Teorema de Bayes y las métricas proxy.
2. Comienzo como siempre, con una hoja en blanco.
Colecciono referencias, ideas ajenas y experiencias, es abrumador…
(Pensé en hacerles un homenaje, no viniendo…)
3. Contenido
● Profunda reflexión sobre la predicción
del futuro (como 2 minutos)
● Revoluciones tecnológicas
● Del pensamiento de proyecto a
producto
● Discovery, Delivery (Agile, Lean),
Team design
● Medidas: Lord Kelvin versus Lord
Cantonnet
Esta es una charla elemental, lo cual no quiere decir simple. Para
comprender las consecuencias, sí se requiere una cantidad infinita de
inteligencia (como le gustaba decir al Prof. Richard Feynman)
4. Preludio - Sobre la predicción del futuro
Con la excepción de algunas
disciplinas no somos muy
buenos prediciendo el futuro
"Quienes se dedican a elaborar
versiones imaginadas del futuro
tienen a sufrir una enfermedad
denominada neomania. El amor a
lo moderno por la modernidad en sí
misma" Nassim Nicholas Taleb & Daniel Kahneman
Taleb ha escrito la colección Incerto (5 volúmenes) sin desperdicio, en
Antifragile se expone lo que sigue. A Kahneman lo veremos más adelante…
5. ¿Cómo imaginaría alguien en 1950 la experiencia de ir
a cenar en el 2022?
● El restaurante es un tipo de establecimiento que cuenta con 25 siglos de
existencia
● Si camina con zapatos (seguramente no muy diferentes a los que usaba
el hombre hace unos 5.300 años)
● Si emplea cubiertos, tecnología que tiene ya algunos años entre las
manos del hombre
● Si beberá vino, líquido que venimos consumiendo desde hace unos
6.000 años, el vaso es una innovación de hace unos 2.900 años
5
¿Y si le preguntara qué imagina hoy para una cena del 2060?
6. Prof. Nassim Taleb
(...) el pasado (y no el presente) es
mejor maestro para indicarnos las
propiedades de un futuro
Le agregaría algunas ideas…
● Formato del iPad es el de la vieja tableta de
piedra
● La Enciclopedia es el abuelo del hipervínculo
En suma que aunque no hay que apegarse al
pasado, en ocasiones el futuro suele venir
"wrapped" en el pasado…
Pero no me preguntó nada…
6
7. Revisamos pues, el pasado…
Las 5 revoluciones tecnológicas (que se han producido en los últimos
240 años)
● (1771) Industrial (fábricas, máquinas, canales)
● (1829) Ferrocarril, Máquinas vapor, acero, carbón
● (1875) Acero e Ingeniería pesada (química, eléctrica, civil, naval)
● (1908) Producción masiva (automóvil, plástico, petróleo)
● (1971) Telecomunicaciones y la tecnología de la información
● ( ? )
8. De invenciones tecnológicas a revoluciones…
Hasta el siglo XVIII la invención tecnológica fue el resultado de creadores
«solitarios» que concebían una nueva herramienta y, si tenían suerte, podían
recibir alguna recompensa o protección por su invento. Galilei (telescopio),
Jaquard (telar), Volta (pila eléctrica), Morse (telégrafo)
Luego ya aparece el inventor asociado con el capital financiero (James Watt,
Mathew Bulton)
Y se pueden distinguir períodos con patrones que se repiten…
● Período de instalación: aparecen los grandes números de capital
financiero cuando se considera que una tecnología es disruptiva
● Turning point: Período de "destrucción creativa" (Schumpeter)
● Período de Deployment: Cuando las organizaciones comienzan a
dominar la nueva forma de producir y toman porciones de la economía y
la infraestructura… 8
9. Revoluciones tecnológicas y modelos de gestión
Ref.:Technological revolutions and techno-economic paradigms, Carlota Perez
10. La producción de software
Lo interesante a notar es que cada ola tecnológica
redefine el concepto de producción, que dispara
nuevos negocios mientras termina de eliminar
aquellos que nacieron en la ola anterior y no se
subieron a la nueva
Así lo muestra, por ejemplo, el índice de las
empresas SP&500 donde en 2021 el 30% está
conformado por productores de software
10
Es decir, en la era digital, lo que se requiere dominar es la
producción de software
11. Revoluciones tecnológicas
Los cambios tecnológicos implican que los negocios
existentes dominen la nueva forma de producir.
Si en la era anterior, era la línea de montaje, en
esta es la producción de software
La ingeniería de software tiene ya, 50 años…
12. Mary Shaw1
12
Hipótesis, experimentos, prototipos, simulaciones,
uso y abuso de ciencia y matemáticas…
La ingeniería de software es hija legítima de las
ciencias de la computación…
(...) el propósito de la ingeniería es crear soluciones
costo-efectivas para problemas prácticos mediante la
aplicación del conocimiento científico para
construir en servicio de la humanidad
(1)
Cómo recordarán los arquitectos de software, Mary Shaw
junto con David Garlan introducen la idea de Architectural
Styles, el arco iris era aún en blano y negro…
13. ¿Y a mí qué me importa?
La producción de software tiene una
naturaleza distinta, es sobre conectar
gente (no piezas) con procesos y
herramientas distintas...
La mentalidad de gestión, con diseños
organizacionales jerárquicos,
presupuestos anuales, centros de
costos, etc. son "de la ola anterior…" Algunos pudieron "transformarse" en el último minuto…
La organización de tecnología pasa de "área de soporte" a ser
"el negocio"...
14. ¿Es para tanto?
Creo que sí. ¿Cuántas prácticas, métodos y formas de pensar provienen de la
"ola anterior"?
● Los diagramas Gantt (gestión de proyectos)
● La inspiración en la manufactura,
● El Toyota Production System, etc…
La desconexión se da entre el negocio y las capacidades de IT
Las prácticas modernas (y no tanto) como la "Agilidad" y "DevOps"
no van a resolver lo anterior, son "optimizaciones locales…"
15. Un ejemplo: Henry Gantt (1917)
Este finado es Gantt, Ingeniero
mecánico (amigo de Taylor) pergeñó
los diagramas que aún
seguimos construyendo… para
vincular actividades (y) en función del
tiempo (x)
Son muy útiles para… El ingeniero era un poquito
incómodo de ver, tenía un rostro un
tanto irreparable…
16. … para las grandes construcciones (de la revolución del acero),
como la Represa Hoover
17. Henry Gantt & Taylor
El foco estaría en detectar trabajo
común, determinar las mejores
prácticas, la división y especialización
del trabajo
Esto es, que las personas sean
consideradas recursos
intercambiables…
… Se han construído grandes cosas con las técnicas de gestión de
proyectos. Ahora bien hemos de considerar si aplican a las organizaciones
que tienen que producir software, una actividad esencialmente creativa
20. Project versus Product (lo que todos sabemos)
Proyecto
● Tradicionalmente, los equipos de proyecto
se arman en función de un business case,
en el cual, entre otras cosas, se justifica la
inversión a realizar
● Los equipos de proyecto suelen operar bajo
un project plan
● El equipo de proyecto construye una
solución
● Los equipos de proyecto suelen finalizar su
cometido y pasar al próximo proyecto,
habitualmente desmantelando el equipo
20
Producto
● Los equipos de producto suelen
focalizar en un problema de negocio
persistente, los cambios drásticos de
dirección suelen acomodarse alegremente
● Los de producto mediante un product
RoadMap
● El equipo de producto debe encontrar la
mejor solución
● En oposición los equipos de producto
suelen ser más estables
22. Continuous Discovery
El discovery es
encontrar la función
cuadrática, el delivery
es, sepa disculpar,
entregar la banana…
1
El propósito de los experimentos (o prototipos) de Discovery que se
construyen es proveer evidencia de que
vale la pena construir el producto planteado
23. ¿Granjero o bibliotecario?
Veamos cuando la intuición es irracional (ejemplo: una idea que
proviene de los expertos de negocio, o ventas, etc…)
Supongamos que nos ofrecen la siguiente descripción de un sujeto de
nombre Sebastián.
“Sabemos que es introvertido, siempre dispuesto a ayudar a los demás,
pero bastante alejado de la realidad. Necesita orden y estructura para
sentirse bien y tiene cierta pasión por los detalles”
Si tuviera que elegir entre dos actividades laborales que pueda tener
Sebastian, granjero o bibliotecario ¿Cuál le parece a usted más
probable que sea?
Sin embargo, este juicio sería irracional. Veamos porqué!.
23
Experimentos científicos han mostrado que en un 85% el juicio de las personas se inclina
por establecer que es más probable que nuestro sujeto sea un bibliotecario
1
24. ¿Granjero o bibliotecario?
Supongamos que existe un ratio de 10 bibliotecarios cada 200 granjeros (o 1 a 20 que es lo mismo)
● Supongamos que un gran %, como el 40% de los bibliotecarios tienen mayor apego a esa descripción, es
decir, el 40% de 10, que es 4..
● Y que solamente el 10% de los granjeros se apegan a dicha descripción (el 10% de 200) que son 20
● La población total (entre potenciales bibliotecarios y granjeros) es 20 granjeros + 4 bibliotecarios = 24
sujetos
● La probabilidad P (”que el sujeto sea bibliotecario dada esa descripción”) = 4/24 = 16,7%
● Mientras que, P("que el sujeto sea granjero dada esa descripción) = 20/24 = 83,3%.
Esto es:
● P(bibliotecario) = 16,7%
● P(granjero) = 83,3%
24
Si su cerebro sigue con nosotros, acaba de comprender uno de los más terribles
enunciados de la inferencia estadística:
el Teorema de Bayes P(H|E) = P(H) * P(E|H) / P(E)
1
25. Sobre "Don" Bayes…
Thomas Bayes (1702-1761) no fue un terrícola común. Ministro
presbiteriano, matemático y miembro de la Royal Society, dotado de
una enorme inteligencia (1)
…
● Usted consume el teorema de Bayes cuando se decide cuales
son las chances de que el e-mail que se recibe sea spam..
● Para el autocompletado en Google search…
● Para encontrar barcos hundidos (como el SS Central
América)
● En Machine Learning, cuando usa "naive bayes"
(1) el teorema se encontró de forma póstuma, una historia similar al Teorema de Fermat, que como sabe cualquier
perito calígrafo es una abstracción del Teorema de Pitágoras, si quieren les cuento sobre Pitágoras en otra charla
25
Los experimentos del Discovery producen datos (no opiniones como indica
Savoia) con los cuales se pueden hacer inferencias sobre el éxito (o el
potencial fracaso) de la idea para un producto, feature, etc…
1
26. Si no hemos
construido aún un
nuevo producto,
proceso o
servicio…
¿De dónde
pepinos
obtenemos los
datos?
1
27. Testa
Elon Musk tenía que fabricar el Tesla.
Tomó un Lotus Elise y le instaló un motor eléctrico.
Si lo quiere, tiene que depositar 5.000 dólares
(Si está pensando que usted no hace autos… le recuerdo que Tesla es software
sobre ruedas)
1
28. Nota al pié sobre
las mediciones…
El finado de la derecha es William Thomson (con
esa cara, no precisaba mascota..)
Puede conocerlo como Lord Kelvin.
"Lo que no se puede medir, no se puede mejorar"
–Lord Kelvin
"No sólo importa la medida, también para que
pepinos la usa"
–Lord Cantonnet
28
29. Las métricas "proxy"
Las van a reconocer con cierta velocidad:
● Tenemos un Deployment Frequency
de 3.648 veces por día!!
● Hicimos como 34 story points, que
son como 4 points más que el Sprint
anterior
● La velocidad del equipo "A" es de 10,
mientras que el "B" es de 34
El problema no son las métricas en sí mismas, sino emplearlas
como aproximaciones a resultados de negocio (o medidas de éxito)
30. 30
El "efecto sandía" se refiere a cuando los indicadores externos
son todos verdes mientras que "por dentro" está todo en rojo…
Los "silos" y las "métricas proxy" contribuyen alegremente…
31. Prácticas relacionadas con la entrega de valor
Tres cosas que permiten mejorar el flujo de trabajo
● Mostrar el trabajo (cuando no lo hacemos, aparece "el crimen
perfecto")
● El tamaño de la pieza a trabajar (small batches)
● Calidad del producto / entregable (no es negociable)
Conviene saber qué es lo que empeora el flujo de trabajo
● Las dependencias (suelen hacer que no fluya el valor)
● Operar bajo el máx(utilización) de los equipos (Ecuación de
Kingman)
● El trabajo no planificado, el conflicto de prioridades
31
Esto afecta: individuos, equipos de desarrollo,
organizaciones completas…
2
32. Prácticas relacionadas con la entrega de valor
Mostrar el trabajo
● Todo trabajo no planificado, toda actividad
requerida (que habitualmente tiene poco
análisis y lleva más de lo esperado) es el
crimen perfecto: no deja evidencias
● De modo que cuando tenemos que
argumentar sobre porque no llegamos con el
trabajo planificado, no podemos
evidenciarlo…
● El trabajo no planificado debe entrar en el
board
32
2
33. En honor al profesor George Boole
Supongamos que necesitamos dos inputs para
terminar algo
● Queremos, por ejemplo, escribir y publicar un simple
artículo
● Una vez escrito, necesitamos: diseñar el post y publicarlo
en wordpress (los dos inputs)
Decidimos que el diseño y la publicación son dos
inputs que provienen de otros lugares
De modo que, tenemos 1 sola chance en 4 de que
podamos publicar en tiempo y forma
George Boole es…
James Moriarty
Además de ser el padre de la Revolución
Digital, George Boole es la inspiración del
temido Prof. James Moriarty, la mayor mente
del crimen (y el archienemigo de Sherlock
Holmes)
Pero esa es una historia para otra charla sobre
lógica y novelas policiales ;-)
33
2
34. Prácticas relacionadas con la entrega de valor
Por las dudas que lo anterior le haya provocado un infarto de córnea, expliquemos:
Si 0 es verdadero y 1 es falso, y dependemos de dos inputs para publicar nuestro
contenido (diseño y publicación); las permutaciones son como siguen
00 -> Tenemos ambos inputs, entregamos en fecha
01 -> Entregamos tarde
10 -> Entregamos tarde
11 -> Entregamos tarde
Es posible que le parezca que lo anterior no reviste ninguna gravedad
Hasta que se da cuenta de que se puede expresar mediante la siguiente
función f(x) = 2x
34
2
35. Prácticas relacionadas con la entrega de valor
Ahí se desayuna (mitad por haber sido torturado en su adolescencia con las funciones aún existiendo las planillas
de cálculo), de que es una función que "crece rapidito..."
¿Y con 3 inputs?. Para jugar con los números, tenemos (y siempre tendremos)
una sola chance para entregar pero en 8!!
1. 000 -> Tenemos los 3 inputs, entregamos en fecha
2. 001 -> Entregamos tarde
3. 010 -> Entregamos tarde
4. 011 -> Entregamos tarde
5. 100 -> Entregamos tarde
6. 101 -> Entregamos tarde
7. 110 -> Entregamos tarde
8. 111 -> Entregamos tarde
El impacto en la entrega, por ende, es asimétrico
Es una forma muy fina de decir que, si agrego más dependencias, se va todo a la mierda!
35
2
36. El tamaño de la pieza (paquete, story, etc..)
Se trata de "partir" el trabajo, por ejemplo,
las user stories (sabiendo que puede
comenzar por los patrones conocidos)
● Pasos de un workflow
● Validaciones
● Reglas de negocio
● Variaciones en los tipos de datos
Otra alternativa (más violenta) es limitar el
tamaño de las user stories a x story points
(ejemplo: x=5)
Flujo de trabajo (cont.)
36
2
37. Delivery
• Cuando los equipos (y los clientes) se dan cuenta que la
velocidad es fútil para determinar productividad, otras
personas se focalizan en la utilización de las personas
• Veamos brevemente este último:
• Suponga que es viernes de tarde y su presunta novia lo está
esperando para hacerle un homenaje a 50 km de su casa…
37
2
38. Delivery
• Es esperable que aumente la
densidad de autos y por lo tanto,
su velocidad promedio baje..
• Si usted está sólo en ruta
(densidad tendiendo a 0) podrá
ejercitar su máxima velocidad
tanto en la ruta como en la cama,
si me permite la donosura
• Estos resultados aparecen en
"teoría de colas" y asuntos
matemáticos, todos muy serios...
38
2
39. Lo que quiero decir es…
La ingeniería de software está evolucionando a gran velocidad
Que la gestión de la producción de software es una actividad esencialmente
técnica (menos diván y más ingeniería, es decir, menos supuestos y más
empirismo)
Hay una fuerte tendencia hacia la producción de productos que implican:
prácticas y técnicas distintas a la "ola anterior"
Los datos y la evidencia siempre van a estar encima de las opiniones
39
40. Eso es todo lo que quería contarles…
gracias!
40