Lean Coffee #1 - Resultados

Estimados y estimadas, sigamos aquí la conversación de nuestro primer Lean Coffee realizado el día 3 de Febrero de 2016.

Los temas listados para el encuentro fueron:

  1. Convencer a la Gerencia para Adoptar la Agilidad
  2. ¿Cómo motivar al personal?
  3. TDD
  4. ¿Cómo “persistir” el aprendizaje que se genera como parte del desarrollo de un proyecto?

El temá más votado fue en número 1: Convencer a la Gerencia para Adoptar la Agilidad.Lo desarrollamos a lo largo de toda la reunión y fue el único tema que abordamos.

Apuntes de la pizarra:

Tema a conversar: Convencer a la Gerencia para Adoptar la Agilidad
Apuntes:

  • Tema principal relacionado: Change Management
  • Governance
  • Mostrar resultados
    • evidencia
  • Hablar el idioma de la gerencia
    • “vender un proyecto”
    • que reporte un beneficio
  • le va tan bien al área de desarrollo que deja “feo” a otras áreas
  • confianza en el proceso actual de negocio versus el nuevo proceso
  • Libro: The Goal: A Process of Ongoing Improvement
  • Libro: Dígalo En Seis Minutos/ Said In Six Minutes (Spanish Edition)
2 Me gusta

@davidlaym ¿tú tienes unos apuntes? Los compartes?
@Guillermo_Schwarz tú pusiste unos buenos comentarios en la página del meetup. ¿Los colocarías acá también?

Gracias!

Mis apuntes esta vez no quedaron tan bien, pero igual los pego por si sirven a alguien mas:

1 me gusta

Para completar, hubo otro de los asistentes que mencionó un resumen de la parte política de la administración del cambio, respecto de los esponsors, los stakeholders y sus intereses y como manejar políticamente el cambio. Eso estaría bueno que estuviera también.

Por mi parte claro que sí.


Respondimos una sola pregunta y siento que no alcanzamos a llegar a consenso.

La pregunta era “como convencemos a la gerencia de usar agilismo”… y
para mí la respuesta es “change management”… Change management
consiste en hace cambios pequeños de alto impacto, también llamado
"low hanging fruit"… eso les da confianza de que lo estás haciendo
bien y genera expectativas de más cambios…

Entonces parten los “te prohibo hablar con la gente que no es de tu
equipo”… “te quiero concentrado en tus temas y déjame a mí las
interacciones”… o puede ser directamente que las solicitudes de
cambio de requerimientos en el proyecto no sean requerimientos reales,
sino sólo para ver que sabes lo que haces…

En otras palabras, “bad mouthing”. La gente con la que hablas empieza
a pedir cosas que no le sirven, sólo para que 2 días antes del término
de la iteración te pida lo que realmente necesita. Scrum soluciona
esto dejándolo para la iteración siguiente, pero el problema es más de
fondo… todo lo que hiciste no les sirve. Sólo la solicitud de último
minuto es lo importante y te das cuenta 3 meses después porque es lo
único que usan, y lo usan tanto que se queda pegado, porque nadie te
dijo que los cambios de precios lo harían solamente a través de una
planilla Excel… 40 mil productos de una… y cada producto demora 1
segundo… son 10 horas para cambiar los 40 mil productos…

Llega a ser un problema porque no estás usando un proceso más
pesado… si a los casos de uso les agregas “veces que se usa en el
año” y “número de registros a procesar”… claro salvaste ese caso de
uso… pero agregaste una carga innecesaria a los otros…

En algún punto dijimos que el gerente no lo ve como algo bueno que se
hagan tantos cambios si no ve beneficios directos y más aún si alguien
del equipo se está haciendo fama (y nada de fortuna), porque eso lo
desprestigia a él…

Ahora bien estamos hablando de un proceso de cambio y terminamos
hablando de hacer el proceso menos ágil. El proceso de cambio sólo
puede funcionar cuando se percibe éxito durante ese proceso de cambio.
Los requerimientos falsos y las funcionalidades irrelevantes que
terminan siendo “gauchadas” y que luego terminan siendo fundamentales
es el proceso típico que he visto en las empresas y que en el fondo
reflejan cómo funcionan las empresas políticamente hablando.

Tener algún tipo de analitics te sirve para saber quién usa qué realmente.

Respecto de los “requerimientos reales” lo vengo diciendo hace 20 años
y se lo vengo escuchando a otros hace 15. Es fácil decirlo, pero ¿cómo
obligas a que los usuarios y los gerentes te digan la verdad?

Imaginemos que tenemos una consultora y que esta se llama “Real
Requirements”. En vez de obligarlos a que te cuenten cuáles son los
requerimientos reales, tienes que cobrar por el coaching para
descubrirlos.

¿Qué harías?

La única solución que me parece válida es ¿cuánto dinero adicional vas
a ganar con este feature?

David creo que mencionó que el dinero no es importante, sino el valor.
Desafortunadamente para un gerente si le hablas de valor y no le
hablas de dinero, no entiende a lo que te refieres, ya que en las
escuelas de administración, son equivalentes, y te lo recalcan hasta
el final.

En otras palabras, ¿este feature que me pediste cuesta USD 5.000,
cuánto vas a ganar en el año con este feature? Si la respuesta es USD
5,000, no se hace porque es una pérdida de tiempo. Si la rentabilidad
es 30% o más, se hace, si no, no se hace.

Eso te da números a fin de año: Mi unidad de negocios generó USD 40
millones. Si los gerentes que me pidieron ciertas funcionalidades, no
lograron su objetivo, ese no es mi problema, según ellos esas eran las
funcionalidades que necesitaban… si se equivocaron tal vez no
entienden bien el negocio…


Si sé lo que me van a decir… eso no es agilismo porque falta la parte de la colaboración. Es cierto.

El enfoque de la gerencia es que no existe la colaboración y la colaboración es para los tontos. Ningún gerente acepta que su descripción de cargo sea “team player”, porque por definición el gerente captura recursos para producir más recursos, si te quitan los recursos tu proyecto por definición falla y si no te toman en serio en la empresa, buscas otra. Y el gerente es un bebé comparado con el dueño de la empresa, ya que él siempre se lleva la mayor parte de los recursos y tiene sus propios proyectos ¿porqué crees que cuando te contratan te ponen restricción de horario? Porque haz sido capturado por la empresa. No puedes ayudar a otras empresas ni a otras secciones dentro de la misma empresa, porque haz sido capturado. Si restablecieran la esclavitud, al día siguiente te ponen un grillete y un cepo.

Ahora bien, esto va en directa oposición a lo que dice el inventor de Scrum: Jeff Sutherland. Él dice que en los últimos años se ha dedicado a transformar completamente las empresas al enfoque ágil. No importa el área, siempre tienen un backlog de cosas que quieren y quieren que las personas colaboren, no que peleen por recursos porque eso es ineficiente. Y dice que todo esto partió porque su propia esposa lo aplicó en una iglesia (o parroquia), y la pregunta que se hizo Jeff fue “qué hay de diferente entre una iglesia y una empresa?” y la respuesta fue “nada”.

De modo que se tira de cabeza a aplicar Scrum en la gerencia general, en el área de finanzas, de marketing, de ventas, etc. Nadie se salva y siempre parte de arriba. Scrum meetings, Scrum board, backlog y de ahí no salen.

Nunca he visto una empresa administrada así, pero no creo que Jeff se “mande las partes” públicamente ante miles de personas y publicar los videos en youtube y todo sea un completo fracaso… Asumamos que sí funciona… entonces ¿porqué funciona?

Yo creo que para un gerente es muy dificil pararse antes sus pares y decir “no hice nada”, “no voy a hacer nada”, “no tengo impedimentos”. Si lo hace todos los días es como ponerse una soga al cuello. Lo más probable es que diga lo poco que hizo, lo poco que va a hacer y mencionar 3 o 4 impedimentos, que terminarán pasando la pelota a alguien. Con un issue tracker pasa lo mismo, la gente se pasa la pelota. Y eso lo veo como algo bueno, porque se crean áreas de responsabilidad y áreas de competencia, las que debieran ser idénticas. Para mí no es raro que en un issue tracker hayan 7 mil issues. Terminas haciendo priorización de los issues principales e iteraciones, al igual que en Scrum, sino no se entiende nada. Y el resultado es que hay un experto en persistencia, uno en servicios y uno en presentación.

Al fin da lo mismo de lo que se trate el proyecto, si lo puedes llevar a casos de uso o user stories con sus pantallas o mockups o paper mockups o lo que quieras, te aseguro que un equipo así es capaz de construir software como loco. Lo importante es que las personas son capaces de comunicarse, pedirse cosas, responderse y sacar adelante el proyecto.

En una reunión gerencial diaria, ¿qué pasaría? Agarran un issue del backlog, por ejemplo: aumentar un 10% las ventas al año, y quien toma el issue distribuye otros issues a quien corresponda. Por ejemplo, necesitamos 10% más de locales, 10% más de productos, 30% más de dinero para abrir los locales y comprar los productos, etc. Cada uno de esos ítemes lo toma un gerente diferente y cada uno de esos gerentes sale con un ítem a reunirse con su equipo a dividir la pega de la misma manera.

El hecho de que sea con papelitos lo unico que hace es que puedas manejar muchos menos papelitos… nadie podría llevar consigo 7 mil papelitos. Como dice la gente de XP lo importante de la arquitectura de los edificios es que tenga escala humana.

Pero yo creo que la pregunta principal es otra. ¿Nuestro enfoque está en el software o en aprender cómo se hace agilidad en toda la empresa?

Entonces desde nuestro punto de vista lo primero que tenemos que preguntarnos es si queremos aplicar agilismo solamente en desarrollo de software o queremos aplicar agilismo en toda la empresa y si el enfoque de Chile Ágil va a cambiar o vamos a crear otros meetups para incluir al resto de la gente.

Si nos tiramos de cabeza a cambiar una empresa no estamos haciendo change management porque no estamos cambiando las cosas de a poco, estamos haciendo un cambio brusco.

Me parece super interesante la propuesta, pero no he trabajado en tantas áreas como para estar seguro de que funciona en cualquier área esto del agilismo. Lo que que sí sé es que a muchas de estas charlas va gente que no es informática a aprender del agilismo. Gente del sector salud. Gente de ventas. Me sorprende que quieran aprender esto. Y me sorprende que les haga sentido.

Jeff Sutherland inventó esto porque estaba en la fuerza aérea en la guerra de Corea. Y decía “bueno si salí vivo de ahí, puedo hacer cualquier cosa”, de modo que se metió en el mundo del software y se dio cuenta que nadie entendía qué había que hacer, no había información en las paredes y era como contratar pilotos que bombardeaban con los ojos vendados. Nadie entendía qué pasaba y si haz trabajado en un proyecto grande (más de 20 personas) con cartas Gantt, UML, RUP y sin control de versiones ni issue tracker, sabes exactamente a lo que me refiero.

El burndown chart lo inventó Jeff porque así es como se aterrizan los aviones. Si no le “achuntas” al runway, debes subir, dar la vuelta y volver a intentarlo. ¿Te dice eso algo?

A mí me dice que siempre interpretamos Scrum mal. Lo vimos siempre desde la perspectiva del software y de las iteraciones y que se parece a XP, pero en realidad no es así. Es otro paradigma, es el paradigma de volar y bombardear al enemigo. De tener el control de tu avión porque tu jefe probablemente está acostado mientras tú expones tu vida y si no tienes control del avión, es mejor que coloques tu cabeza entre tus piernas y kiss your ass good bye.

De todas maneras cuando se trata de la salud me lleno de dudas. ¿Si el paciente sale mal operado lo cierro y lo opero de nuevo mañana? Las analogías no me cierran.

2 Me gusta

Excelente tu reflexión Guillermo. Creo que abarca muchas de las dudas y situaciones en que estamos hoy los que desarrollamos y/o gestionamos desarrollo de software, y quizás los que están en otros ámbitos.

Tu final de esta reflexión la encontré muy interesante de seguir desarrollándola: “¿Si el paciente sale mal operado lo cierro y lo opero de nuevo mañana? Las analogías no me cierran.”

La mente humana generalmente está muy enfocada en buscar patrones y aplicar secuencias de actividades o ideas para resolver esos patrones… y finalmente queremos encontrar el método-mágico-que-resuelva-todos-los-casos.

Entonces paso a agregar lo siguiente para continuar tu reflexión: Existen situaciones a las cuales no puedes aplicar agilidad, y aquí aplico una analogía a lo que digo (tomando ideas del libro “Software Craftsmanship” de Pete McBreen), porque creo que la agilidad se acerca a ayudar “estructurar” “un poco” el trabajo de un “artesano de software”, lo que se puede aplicar a una gran vasta mayoría de los desarrollos de software, pero no a sistemas críticos donde una estructura rígida tiene sentido, donde generalmente es muy cara (y necesaria) la solución o muy caro el costo de cometer errores, como la construcción ingenieril del software del “space shuttle” o, como tu ejemplo, la operación de una persona donde está en riesgo su vida, etc… Entonces, simplemente, no puedes aplicar en todo la analogía que buscas… hay casos y situaciones muy particulares y críticas… está bien que “no te cierren las analogías” en algunos casos.

Hola Edgard,

Ok, resumiendo tu postura, los proyectos ágiles se utilizan cuando no sabemos que queremos o los requerimientos no están muy claros y tenemos que ir probando lo que el usuario o cliente realmente quieren.

Obviamente esto funciona porque está absolutamente documentado que funciona. Si no habría una larga lista de pruebas de que no funciona.

Puse el ejemplo de la medicina porque a mi no me cuadra, pero algo no estoy entendiendo porque a los médicos sí les cuadra y quieren aprender agilidad. Creo que deberíamos investigar más porque les parece interesante y cómo lo aplican. En el fondo, si realmente les funciona, hay mucho nuevo que entender ahí.

Sin embargo, la segunda parte de lo que explicaste no me cuadra. Eso de vamos a tener una carta Gantt que te va a decir cuanto dura el análisis, cuanto el diseño y cuánto el desarrollo. ¿Cómo vas a tener una planificación de la construcción de un edificio si no tienes el diseño (los planos) del edificio? ¿Cómo vas a planificar el diseño de un edificio si los arquitectos trabajan de noche tratando de satisfacer necesidades del cliente que los mismos clientes no son capaces de expresar verbalmente?

En la arquitectura de edificios nacieron los patrones de diseño con Christopher Alexander, un arquitecto de edificios que estaba descontento con el estado de la arquitectura en los años 60’s, porque en ese tiempo se empezaron a fabricar montones de edificios “modernos” (lo que Federico Sánchez, el de City Tour, llamaría Torre y Placa)… y que la gente odiaba. Una de la razones porque la gente odiaba esos edificios es que no estaban diseñados para que las personas los habitaran (no estaban hechos a escala humana), sino para que se vieran como una diapositiva de la guerra de las galaxias, mostrar la grandiosidad de algo, como la arquitectura comunista, lo que puedes ver en el edificio Gabriela Mistral, ex Diego Portales, ex PNUD.

La conclusión a la que llegó Christopher fue que se había perdido el conocimiento antiguo, lo que llevaba miles de años en desarrollo, ya que era una práctica que se aprendía por copia y repetición, no estaba estructurada ni racionalizada, de modo que todo era tácito. Entonces Christopher se propuso racionalizar la arquitectura tradicional, ponerla por escrito a través de los patrones, que tratan con temas acerca de cómo construir una ciudad hasta donde poner las perillas de las puertas, pasando por cada tema imaginable com opor ejemplo “a la entrada debe haber una mesa a la altura de la cadera para dejar las llaves o cualquier objeto pesado que estas trayendo y puedas cómodamente cerrar la puerta”… todo eso para decir “arrimo”.

Bueno Ward Cunningham estaba sorprendido que enseñando “herencia, encapsulamiento y polimorfismo” el software resultante que escribían los aprendices era una basura. ¿Qué es lo que no les estamos enseñando que nos traen esta basura y piensan que está bien? ¿Cómo capturamos las ideas de cómo se debe hacer el software?

Y así nacieron los patrones de diseño: “cuando tengo este problema conocido, aplico esta solución que ya está probada”. En arquitectura de edificios Christopher ha encontrado más de 500 patrones he incluso escribió “a pattern language” en el que indica que en los proyectos en que los arquitectos saben de patrones terminan hablando de manera sucinta y tomando decisiones utilizando frases que mezclan patrones. Haciendo una arquitectura en una frase que mezcla 3 patrones conocidos… y lo más increíble es que la gente te entiende y el método funciona.

A mi me ha pasado en software, y realmente multiplicas la velocidad de desarrollo x10, sino más. Es muy dificil de medir porque el salto es demasiado grande.

Pero bueno, la carta Gantt es un antipatrón porque no identificas los pendientes fácilmente, no los puedes subdividir fácilmente, no puedes asignar responsabilidades (que no es lo mismo que asignar tareas)… además ¿cómo devuelvo un issue que no se entiende o que contradice al resto del sistema usando una carta gantt?

Además el mayor problema de la carta Gantt es ¿dónde están los requerimientos, las decisiones de diseño que resuelven esos requerimientos, los prototipos que muestran que esas decisiones de diseño son implementables y las implementaciones no tienen problemas?, ¿dónde están los prototipos evolutivos que juntan los prototipos aceptados? ¿cómo indico en una carta gantt que los prototipos deben ser enchufables y fáciles de sacar y reemplazar por otros cuando encontramos un problema?

Porque según yo la agilidad no consiste en poder armar cosas rápido, sino en poder “cambiar”, es decir “sacar cosas que no me gustan y poner cosas que sí me gustan” y eso hacerlo rápido. Si me demoro 2 meses en hacer un prototipo, me da lo mismo. Lo importante es que luego algo no me gusta y lo cambio. ¿Y si me demoro mucho no soy ágil? La verdadera agilidad se mide en poder cambiar las cosas rápido. En modelo de carta Gantt una vez que algo está hecho está completamente soldado al resto del proyecto. Si quiero cambiarlo, más me vale empezar el proyecto de nuevo.

La carta Gantt, según la mitología, fue desarrollada para ganar la segunda guerra mundial. Según Eisenhower “los planes son desechables, pero la planificación es indispensable”.

Dudo mucho que el tipo que dibujaba las cartas Gantt a mano en 1940 pensara que es muy entretenido actualizar la Gantt varias veces al día, que es en el fondo lo que Heisenhower está diciendo. Y esa es sólo la primera parte, porque tienes que mirar la carta Gantt acutalizada y ver si te calza… Sospecho que Eisenhower se agarraba todos los días con el goma que actualizaba la Gantt… No me cuadra… Nunca he visto a los militares de las películas de la segunda guerra mundial actualizando o siquiera mirando cartas gantt… Miran un mapa con tropas de juguete y las mueven para imaginar lo que va a pasar y diseñar planes… Esos sí son planes, ver casos hipotéticos y resolver “si pasa esto, hago esto otro”. Esa es la verdadera planificación, no la tontera de las cartas Gantt.

Y eso de ver la luz al final del túnel es cuando haz resuelto todos esos casos hipotéticos y “tienes una estrategia ganadora”.

En Microsoft existen las War Rooms (salas de guerra) donde van todos los que quieren y se planifica ganar la guerra (ver la luz al final del túnel). En Chile le llaman PMO, que son las salas donde se toman las decisiones de alto nivel, para evitar que los esfuerzos de una parte del equipo esté desconectado del esfuerzo de otra parte del equipo, además que van los stakeholders y resuelven sus inquietudes. En Scrum eso se llama Scrum of Scrum. ¿Tú crees que en Microsoft se hacen cartas Gantt? Obviamente no. Si requieres una gantt, haces que el issue tracker imprima una automáticamente.

Pero aún así no sirve. La carta Gantt siempre es una pérdida de tiempo y no transmite ninguna información útil. Como modelo conceptual es inútil y cumbersome. Si ves un proyecto con carta Gantt puedes estar seguro que ese proyecto está fracasado. Aún peor si la carta Gantt está pegada en la pared. Mucho peor si esa carta Gantt está desactualizada. Y créeme, siempre son incompletas, no incluyen eventos importantes, siempre están con información que no es relevante.

Lo que funciona: Tomar el proyecto y dividirlo en pendientes. Esos pendientes deben incluir los requerimientos, las decisiones de diseño que resuelven los requerimientos, los prototipos que muestran que las decisiones de diseño son implementables, etc. Luego, pensar cada issue individualmente. Como si tuvieras todo el tiempo del mundo. Subdividirlo hasta llegar a tareas que no toman más de 2 días. Tener personas que son “centro de responsabilidad” (esto va contra Scrum)… pero si no ¿cómo haces para “rejuntar” lo que debería ir junto? En otras palabras, así como no necesito código repetido, tampoco necesito diseño repetido. No necesito que hayan 10 maneras de implementar las pantallas, ni 10 maneras de implementar la persistencia, ni 10 maneras de resolver los servicios y la lógica de negocios.

En Scrum esto se resuelve haciendo reuniones de planificación/diseño al principio del Sprint en las que participan todos. Tiene un valor muy alto en el sentido de formar una cultura de equipo, realmente funciona, pero al no tener áreas de responsabilidad, me da la impresión que no es factible aumentar la velocidad de desarrollo de manera que avance realmente rápido. Puedo estar equivocado.

Volviendo a las cartas Gantt, si no es de la segunda guerra mundial, ¿de dónde vienen las cartas Gantt? La verdad es que sospecho que son muy posteriores. Sospecho que vienen del proyecto Apollo, porque hasta el proyecto Gemini tenía iteraciones de un día, se iban probando pequeñas mejoras, y al parecer alguien se desesperó y terminó el proyecto Géminis y empezó Apollo.

Primer evento del proyecto Apollo: su fervierte crítico y 2 astronautas más mueren quemados instantáneamente en una accidente.

Eso nos lleva a que el proyecto Apollo fue realmente un hoax, pero eso sería tema para otro día.

Es muy raro que todos los proyectos de software que tienen una alta planificación con Gantt fallen estrepitosamente, estamos sólo hablando de software, que es extremadamente maleable… ¿y me vas a decir que un proyecto de hardware como el proyecto Apollo y donde había que ir a un ambiente totalmente diferente no hizo prototipos y no fueron aplicando baby steps?

Esos proyectos en los que “todo el mundo está muy seguro de lo que hay que hacer”… digamos la verdad, si todo el mundo está muy seguro de lo que hay que hacer estamos trabajando en un macdonald, pones un niñita que está recién salida del colegio, le das las 5 tareas que tiene que aprender (sirve la bedida, saca el pan, pon la hamburguesa, la lechuga, el tomate, listo)… Si los proyectos de software fueran tan simples lo harían niñitos de 17 años en India por el precio de un MacDonald y estaríamos todos sin trabajo.

En la práctica tú agarras este proyecto donde “todos están tan seguros” y lo puedes hacer con requerimientos numerados, decisiones de diseño formales (por escrito y publicadas), prototipos que son tareas dentro del issue tracker y que quedan dentro del control de versiones, y no llevas ni la mitad de los anteriores y ya se están poco menos que redefiniendo el proyecto porque estás mostrando que lo que están pidiendo no tiene ni pies ni cabeza (can’t tell head from tails).

Incluso pruedes aplicar XP y Scrum y hacer release todos los días. Vas a darte cuenta de si cumples la Gantt o nomucho antes de llegar a la mitad del proyecto.

Al principio de tu carrera puede ser que no sepas cómo programar. Que pienses que tal o cual cosa es super dificil. Pero en realidad todo ya fue solucionado en software. Hasta Cassandra se basó en papers de los años 60, 70 y 80. Lo dificil es que te digan los requerimientos reales, siempre hay desconexión del negocio y el problema es tan prevalente, que incluso algunos proyectos son “vamos a reescribir este código” y no tienes ni el código antiguo ni los requerimientos originales, porque nadie los escribió… y si los escribieron, los botaron a la basura.

Porque un ingeniero de software podrá pensar que el desarrollo de software es tan dificil, pero para la gente que no trabaja en software, somos unos flojos y te lo dicen en la cara, y cualquiera puede diseñar un software. Según ellos, nadie trabaja, porque cuando estoy pensando generalmente estoy quieto, me quedo pegado mirando al infinito… o me recuesto en la silla pensando… en realidad en los proyectos más grandes y difíciles casi necesito una cama, porque pienso mejor de manera horizontal… no sé porqué… creo que tiene que ver con el hecho de que el cerebro se irriga y se oxigena mejor cuando estás horizontal… por eso dormimos en una cama y no parados como los caballos.

Si estuviera haciendo copy and paste, probablemente movería el mouse y el teclado mucho más, pero la calidad del trabajo no sería mejor.

Cuando te pasan los requerimientos y dice “pon acá un botón” y cosas por el estilo, en realidad te están pasando un diseño, hay un preconcepto, un prediseño… Y digo “pre” no en el sentido de “anterior en el tiempo” sino en el sentido de “inadecuado”, “incompleto”, “inconducente”, “lo contrario de”.

Te están llevando en un death march a un barranco del que no hay salida, porque esas personas no tienen los estudios para entender cómo se hace realmente y piensan que eres un payaso o un mono que se mueve por moneditas. Algo así como “quién te echó fichas?”. Es triste pero demasiado cierto.

Y eso lo hacen los usuarios porque piensan que tu trabajo es trivial. Es el equivalente de que vaya al médico y le dicte la receta. No creo que ningún médico acepte. Pero esta profesión está llena de no profesionales, gente que pasó por la universidad “copiando” y que a la salida de clases decían “esto no sirve para nada”… No creo ser el único que tuvo esa experiencia porque era demasiado usual.

Está llena de “jefes” que realmente no son jefes porque no saben hacer tu trabajo, sino clientes que creen que armar una catedral es poner un ladrillo arriba de otro… y contratan obreros del software, gente sin conocimientos que mueven las manos sin tener idea de lo que hacen… y luego se preguntan porque el software es tan malo.

Si contrato obreros, entonces la manera de hacer todo más productivo sería “trabaja más rápido”. Cada vez que escucho eso, sé que estoy trabajando con un imbécil. El software es una de las actividades en las que el proyecto sale antes cuando me dan tiempo para pensar y encontrar las abstracciones que permiten convertir un problema de programación en uno de configuración. ¿se puede hacer de otra manera? Claro, utiliza Scrum. Pero fíjate que si hacemos todo en 2 semanas, no es mucha la información que me van a dar, ¿cómo desarrollo abstracciones en 2 semanas?

¿No serán bastracciones? Esas son abstracciones que nadie reconoce que las inventó.

Scrum, en mi humilde opinión, no te da esos esos tiempos, al menos no explícitamente. ¿porqué digo esto? En rugby, scrum es el momento en que tu equipo empuja al otro equipo para obtener la pelota ovalada, patearla hacia atrás y que uno de los miembros de tu equipo, que no está haciendo el scrum, la tome en brazos como si fuera un bebé, y corra con ella hasta el arco contrario. Ese es el momento del “sprint”, que significa correr lo más rápido posible.

La idea del “sprint” es que no puedes estar más de 12 segundos haciéndolo. Quizás en alguna ocasión puedas hacer un sprint de 24 segundos. Quizás puedas incluso llegar a los 2 minutos de sprint ininterrupido, pero es imposible hacerlo durante todo el partido, porque el cuerpo “no da”.

Ahora bien, si vemos como se aplica scrum según los teólogos de la liberación, pasas de un scrum al siguiente sin pausa, y haces pair programming 8 horas diarias. Eso es el equivalente a tomar un rugbista y decirle que debe hacer sprint 8 horas diarias, 5 días a la semana. Se agota, rápido, muy rápido, y probablemente lo vas a tener tan reventado que si dura 3 días haciéndolo, deberían darte una medalla y a él internarlo en la UTI a ver si de alguna manera lo salvan de morir por stress post-traumático con pérdida de masa encefálica.

No se puede. Y no sólo no funciona para las personas, los proyectos se ven afectados porque el exceso de esfuerzo cerebral redunda en que el tipo está presente físicamente, pero el cerebro se encuentra muerto, o al menos, increíblemente seco. Y cuando digo seco, no me refiero a que el tipo sea seco, sino a que su cerebro no tiene suficiente irrigación sanguínea.

Es el equivalente en los proyectos con carta Gantt a “¿que estuviste haciendo’?”. Una pregunta que suena a “no me digas que no estuviste haciendo nada”, como si fuera un pecado mortal.

Los proyectos funcionan no porque le sacamos el jugo a la gente. Ese “jugo” se llama irrigación sanguínea, y el cerebro es la única parte del cuerpo que consume el 30% de la irrigación. Si le “sacas el jugo”, el tipo es un zombie que sigue órdenes, pero su capacidad no es mayor que la de un tipo random que sacaste de la calle.

Me da lata repetir lo que digo siempre, pero lo que te toma una hora a las 5 pm y sale mal, te toma 15 minutos a las 9 am y sale bien. Las jornadas de trabajo extensas sólo te matan la mente. Imagina si la jornada no sólo es extensa sino que además estás haciendo “sprint”. Te mata.

La actitud correcta es trabajar lento. Verificar que lo que están pidiendo tiene sentido. Tomarte tu tiempo. Pensar primero, actuar después. “Get in the zone”. Hacer todo con tests te sirve para medir cuando tu cerebro ya no está funcionando, porque si el cerebro es el que mide cuando el cerebro no está funcionando, bueno, por definición ya no está funcionando, así que no es factible que se auto revise.

Todo eso es muy lindo, pero si el CIO no tiene idea de lo que quiere el CEO, si no alinea los planes informáticos a los planes estratégicos de la empresa, si hay desconexión, y en Chile hasta el gobierno tiene desconexión cerebral, ¿qué quedará para el resto?

Las ideas son despreciadas, de hecho la gente piensa que es mucho más importante respetar al resto que armar una idea con conceptos claros, en otras palabras, nadie dice lo que piensa para no ofender a los que podrían estar escuchando. Las mujeres no te dicen que no, para que “no te de penita”, pero más penita me da pegarme un plantón porque la tipa no aparece. Eso no les da penita, obviamente, porque nuestra cultura es así, te desprecian, pero no te lo dicen, porque eso seria una falta de respeto.

A mí me queda claro que decir a todo que sí y después hacer otra cosa, eso sí es una falta de respeto mayúscula, si nadie te obliga a decir que sí, eso no es parte de ser educado, eso es parte de ser hipócrita, y en Chile somos especialistas en eso.

Eso conduce necesariamente a que las ideas no se dicen, todo es secretivo, y por lo tanto hay escases de ideas, porque si las ideas no se comparten, las nuevas generaciones no tienen ideas dentro de su cabeza. Así como la cultura romana era una cultura bastarda de la cultura griega (en el sentido de no ser reconocida por la cultura griega como “child”), la cultura española es también una cultura bastarda de la cultura romana, la cultura chilena bastarda de la española… y para más remate lo griegos eran inteligentes, pero no hacían nada porque los esclavos les hacían todo. Bueno chile tiene como base esa cultura, pero todos mutis porque no vaya a ser que los esclavos se den cuenta. ¿No es obvio? … Uno hace todo el trabajo y las decisiones vienen de otra parte… Los objetivos estratégicos no se comparten… “Oye hay desconexión de objetivos”… “Entonces no se me ocurre como alinear los objetivos de las distintas áreas”… “Contratemos un asesor”… Claro porque si digo mis objetivos entonces estoy contraviniendo una regla cultural y seré condenado al ostracismo… Si le pides algo a alguien se ofende… “no soy tu esclavo”. Muy poco explícita, pero al mismo tiempo demasiado obvia.

Nadie dice sus ideas, regla número 1. Si es que pudieran llamarse ideas, son más bien preconceptos. No por nada en Chile no se produce nada, bueno tal vez un poco de software, pero nótese que siempre es una actividad secundaria, no la principal, y el modelo para realizarla es “directivo”, en el sentido de que te dicen “qué hacer” y a veces hasta “cómo hacerlo”. Y si no funciona es “tu culpa”. Vaya, si hubiera sabido que esto se trata de “la culpa” habría traido mi rosario para rezar, ¿desde cuando esto se convirtió en una religión?

Si vas a mejorar la calidad de la educación, obviamente tienes que seleccionar, y la selección es discriminación, ojalá sea por notas y no por dinero, pero en Chile se produce la paradoja de que se piensa que los “ricos” son más inteligentes que los “pobres”… ¿Es idea mía o los ricos son los comerciantes? … Porqué está ampliamente documentado que las familias “ricas” chilenas tenían varios hijos… Siempre había un militar, un cura, profesionales y al tonto de la prole lo metían a comerciante porque no tenía cabeza para otra cosa. Y por lo menos hasta donde he visto “los comerciantes la llevan”, se podría decir que hasta dirigen el futuro del país, intervienen en la política, y si no son directamente ellos los que hacen las leyes, tienen lobistas que por una módica suma se dedican a servir sus propósitos viles.

Y cuando digo viles, me refiero a villanos. Como el señor feudal que cuando quería divertirse, tomaba chicas de la villa, literalmente villanas, y las convertía en doncellas.

Es un estado de las cosas que sirve a los propósitos de los que genéticamente son más descerebrados, pero que por lo menos hay que reconocer que sus ideas, por simples, funcionan. Sus modelos de negocio nunca tienen más de 3 pasos. Y si no funcionan, los pueden cambiar rápidamente. Se ufanan de sus capacidades para los negocios como si eso tuviera algún halo de inteligencia, siendo que realizan un rol muy bajo para la sociedad, pero se lo llevan todo. Y lo más chistoso, con eso no hacen nada.

Te pongo un ejemplo. Microsoft en los 90’s era la empresa más rica del mundo. Paul Allen y Bill Gates se propusieron crear una red de satélites de baja altitud para comunicar mediante telefónía satelital a todo el mundo. Si no me equivoco se llamaba Trillium. ¿porqué era tan buena idea? Podías estar en una isla en el pacífico y siempre tendrías señal. Quizás no batería, pero señal sí.

No encontré el nombre de la empresa, pero algunas historias de los desastres de Allen hasta 1994: http://www.wired.com/1994/08/allen-2/

A lo que voy, lo importante es crear productos o servicios que al menos en el papel sean disruptivos, si después falla porque tuviste mala suerte, contrataste al equipo equivocado, o el teléfono tenía que ser negro y no blanco, bueno qué importa… Si sé, acá en Chile, lo importante es ganar plata… si luego se revela que eras gerente de un banco y te robaste la plata, a nadie le importa y te eligen igual…

Bueno, ahora todos usamos telefonía satelital, ¿no? La idea de Allen fue un fracaso, para variar. Pero eso no es lo importante. Lo importante es que los tipos realmente creen que pueden hacer cosas. ¿De qué sirve vivir una vida si tu único logro fue abrir una tienda en un mall? Y una tienda es una bodega. No conozco a nadie que desde niño dijera “lo que quiero ser cuando grande es ser administrador de una bodega”. Suena pésimo. Si lo que ganas no fuera esplendoroso, estoy seguro que nadie lo haría. Eso probablemente es lo que hace que sea esplendoroso, que como a nadie le gusta la idea, tienes poca competencia, y eso automáticamente hace que ganes más.

Los que nos dijeron cuando niños “sigue tu vocación” nos arruinaron económicamente.

Ahora bien, si extrapolamos esto a Scrum, si Scrum realmente logra que a la gente “le guste” trabajar en software, lo que va a pasar es que los sueldos van a bajar un montón. No sé si eso es lo que realmente queremos.

De hecho la torpeza en el desarrollo de software es lo que mantiene la demanda alta. Por cada proyecto grande que falla, se dispara la demanda de metodologías ágiles. Por cada proyecto de software exitoso, la competencia quiere lo mismo. Y el resultado de todos estos sistemas es generar mucho dato, que luego hay que administrar. Si tu competencia tiene mucho sistema informático, no te puedes quedar atrás. Y los sistemas son cada vez más grandes y más ambiciosos. Cualquiera de los sistemas de hoy en 20 veces más grande que un sistema de hace 20 años atrás. Eventualmente vamos a ser todos programadores y eso asusta un poco, porque encuentro que el código de hoy, aunque es 10 veces mejor que hace 20 años atrás si se mira función por función, a nivel de diseño es 100 veces peor, el desorden de JSP, JSF, Hibernate, etc. es increíble. Imagínate si ponemos a cada persona que pasa por la calle a programar… me imagino todo automatizado, pero mal, metros chocando, autos chocando, semáforos que tienen luz verde en ambos sentidos, cajeros que no entregan el dinero… Estamos viviendo el futuro… Pero ese futuro sería una pesadilla…

Sin embargo lo que realmente importa son los sistemas disruptivos, aquellos por ejemplo que están para perfeccionar las imperfecciones del mercado. por ejemplo, Aquellos que encuentran la tarifa más baja en las líneas aéreas. O whatsapp que te permite ahorrar en llamadas. Todos estos sistemas que eliminan intermediarios y que más encima son gratis. Una vez que el mercado es tuyo, puedes cobrar por servicios premium.

Eso en Chile no ha pasado.Todavía no llega la idea a los genios comerciales. Quieres hacer un emprendimiento, entonces muéstrame el modelo de negocios, muéstrame cuanto te pagan los clientes, págame por hacerte un estudio de mercado, ¿en qué parte de mi cara dice que soy un idiota? Si Google se hubiera fundado en Chile todavía estarían buscando a alguien que les pasara el dinero.

Todo esto ocurre por la lucha de clases. No es la lucha de la clase E contra la clase ABC1, sino las verdaderas clases sociales, las diferentes profesiones. Una cosa es lo que piensa el gerente de finanzas, otra lo que piensa el de marketing, otra el gerente de ventas, etc. Pero en realidad todas esas ideas están equivocadas.

Todas las startups exitosas son fundadas por computines. Esa es la verdad del momento. Cuando ves un problema y dices “obvio, eso se soluciona asi”, en realidad están creando un disruptor del mercado. Todas las innovaciones son disruptivas. Y si no estás disruptiendo algo, no estás haciendo nada. Al menos, nada que valga la pena.

¿Qué significa disruptir? Arruinarle el negocio a los que actualmente tienen el negocio. Si logras disruptirlo, el mercado es tuyo. ¿Cómo vas a ganar dinero con eso? Eso es una tontera, no importa. Si tienes dudas, una vez que hayas disruptido, contrata un MBA y dile que quieres ganar plata. Para eso están los MBA, eso es lo que estudian, no pueden ser tan pencas que no te digan cómo.

En resumen, no creo en eso de que “hay proyectos que se llevan mejor con cartas Gantt”. No sólo no lo creo, sino que tengo cicatrices de 20 años que prueban que esas cosas no sirven, y más encima perjudican a los proyectos. ¿Cartas Gantt que nunca están actualizadas? ¿Cartas Gantt que no registran las dudas? ¿Cartas Gantt que no reflejan los riesgos del proyecto? En la práctica, ni siquiera empresas en las que se hace todos los días lo mismo, por ejemplo en un MacDonalds, tienen cartas Gantt. Lo que usan son issue trackers, o Kanban, con papelitos, tómalo como quieras, nunca vas a ver una carta Gantt en un MacDonalds y probablemente sea uno de los trabajos más repetitivos y estúpidos del planeta.

Un ejemplo de como todo el mundo se queja de las cartas gantt:

http://habilissoftware.com/Blogs/index.php/es/articulos/40-decalogo-para-hundir-proyectos-7-parte

Lo que el tipo dice es que las cartas gantt están siempre incompletas, y que los proyectos que parten con una carta gantt realista nunca se aprueban. Yo he estado del otro lado y lo que la gente piensa es “si todos los proyectos se atarasan y duran el doble, esto quiere decir que este proyecto también se va a demorar el doble”.

Por eso siempre las cartas gantt vienen apretadas y con itemes de menos, para apurarte.

Para más remate, nadie siente bien con una carta gantt de 7,000 itemes, donde ahora estoy haciendo el 3854… Es desmotivante ver que este tarea que me va a tomar un día o dos, es tan insignificante. Por lo menos gráficamente.

En el caso de Scrum, todo se vuelve a escala humana, sprints de 1 o 2 semanas, despejar la mente de lo que viene y concentrarse en la tarea actual, como si el resto no existiera, eso es lo que da resultado.