Igualdad y desarrollo de software. ¿A quién le conviene?

wp_20150201_001

Hace unos días asistía en Twitter a la conversación de varios desarrolladores, MVP, técnicos, etc. acerca de la visibilidad de las mujeres en el evento para desarrolladores Codemotion. Espoleados por nuestro particular Pepito Grillo de la comunidad Microsoft en España Edin Kápic, los comentarios no se hicieron esperar por parte de desarrolladores, MVP o evangelistas de Microsoft como Isabel Cabezas cuya opinión como representante femenina tiene especial valor.

Al final, entre tanto hilo y con la limitación de espacio que caracteriza a Twitter parece que teníamos muchas preguntas e interés en el tema de mujeres y desarrollo de software pero pocas respuestas.
Como parte doblemente interesada por ser desarrollador y padre de una hija a la que me gustaría ver en “ciencias” (STEM), quiero hablar solo un poco (el tema es extremadamente complejo por lo que parece absurdo intentar ir más allá en solitario) de mis opiniones y dudas acerca de si es necesario o siquiera buena idea esforzarse en aumentar la presencia femenina en el sector.

Empezaré diciendo que la vez que más abiertamente he escrito sobre el feminismo fue comentando en junio el documental CodeGirl  y que cobra mayor relevancia con cada evento que persigue la igualdad estadística entre sexos. Y no lo he hecho más a menudo porque es un tema “caliente” que podría volver fácilmente un texto en un problema para el autor, pero con una hija estos temas cobran cada vez más importancia. También, quizá por haber leído Universidad y Ciencia en España, de Clara Eugenia Nuñez  y La Tabla Rasa de Steven Pinker, me surgen serias dudas sobre si es buena idea lanzarse a movilizar mujeres y hombres a la búsqueda de la igualdad estadística, en parte por si estamos resolviendo un problema equivocado y en parte por si provocaremos efectos secundarios no deseados.

En cuanto a mi opinión sobre las mujeres en el software, aunque muchos comentan que todas las desarrolladoras de software con las que han trabajado eran estupendas, yo diré que también las he encontrado muy malas, pero parecen trabajar mejor en equipo en general. De todos modos no he tenido ocasión de trabajar con tantas como hombres ni de lejos así que aquí tengo un sesgo clarísimo, y eso señala un problema o una característica social o del sector que valdría la pena explorar.
Sobre mujeres dando charlas, la única vez que he insistido en que alguien nos diese una charla técnica fue de una compañera de front-end. Ella pensaba que “no era tan buena” pero yo veía evidente que sí y creo que el tiempo acabó dándome la razón. En ningún caso quería incluir mujeres (era interna) sino aprender de los más competentes y en este caso era ella.

Por último, pongamos algunas cosas sobre la mesa:

  1. Hay un interés económico claro y reconocido de aumentar el pool de desarrolladores disponibles para la industria (lean algunos comentarios, son interesantes).
  2. Hay un interés claro de determinadas empresas en aumentar la diversidad de desarrolladores (más allá del sexo) en sus plantillas en pro de la “innovación”. Sea lo que sea eso.
  3. Como sociedad, parece que España es una de las mejores del mundo, muy lejos de la estadounidense.
  4. Desarrollar software no es fácil, y requiere de una dedicación seria con una necesidad de renovación constante que no todo el mundo (sea del sexo que sea) está dispuesto a asumir y mucho menos a disfrutar. Recordemos que los jóvenes quieren ser funcionarios.
  5. Los Estados Unidos son una sociedad diferente, con problemas diferentes a la Española, de los cuales no deberíamos importar soluciones sin más, sin un poco de espíritu crítico, a riesgo de generar nuevos problemas o romper cosas que funcionan, como la sanidad pública.
  6. Hay despidos en empresas técnicas como Microsoft a nivel mundial o HP localmente.

Por tanto, mi opinión actual es que tenemos varias economías nacionales con intereses claros en aumentar y diversificar el pool de desarrolladores. Tenemos también una oleada de problemas “del primer mundo” y soluciones extraídas de la sociedad estadounidense que están siendo importadas prácticamente sin espíritu crítico por colectivos interesados como son políticos (votadme mujeres de 18 a 35 años), empresas de eventos (mujeres, venid a mi evento de pago) y empresas/profesionales de formación (hágase rica programando con mi curso). Sobre la formación además parece que estamos ante una burbuja.
Y por último tenemos a los desarrolladores sin distinción de sexo o edad, que parece que tenemos un incentivo económico para NO aumentar el pool de desarrolladores. Con ello algunos esperan conseguir sueldos un poco más altos (acordes a lo que esperaríamos en otras economías del entorno) o al menos evitar despidos como los de HP por poner un ejemplo. Este último caso deja claro que no hay escasez real de mano de obra técnica, sino de mano de obra barata.

Todo esto debería dar bastante que pensar y hace que me plantee decenas de preguntas. Tantas que he desistido de intentar articularlas o mencionarlas aquí con idea de centrarme en la más importante.

¿Qué problema queremos resolver realmente?

O a nivel más personal y concreto ¿cómo va a hacer más felices a mi mujer y a mi hija el aumento de mujeres desarrollando software?

A la primera pregunta la única respuesta evidente es que queremos abaratar costes a empresas (no a autónomos, ojo). Por favor, si alguien tiene otra, que me la diga, porque yo no soy capaz de dar una alternativa.

A la segunda pregunta no parece que aumentar el número de mujeres desarrollando vaya a tener un efecto beneficioso sobre el futuro de mi hija. A priori, siendo mujer te puede ir mejor si está dispuesta a aprovecharte del sistema y de los sesgos (leyes, micromachismos) aunque imagino (que no veo) que puede tener sus ventajas aumentar el número. Pensando en efectos secundarios lo que veo es un escenario de sueldos peores y mayor competencia, por lo que estaríamos ante la típica carrera hacia el abismo.

Así que, aunque me parece normal y deseable que grandes empresas se envuelvan en la bandera de la inclusión para mejorar ingresos, yo no veo ningún incentivo para que los trabajadores apoyen iniciativas de este tipo, fuera de los sectores de formación, organización de eventos y política (que no es poco). E incluso yendo más allá y reconectando con el tema que abría este post, me pregunto si tienen sentido los eventos técnicos presenciales a día de hoy o si deberían cambiarse a un formato más inclusivo para todos como es el remoto vía Hangouts y similares. Quizá las hololens y otras tecnologías puedan aliviar a eso y permitir que las minorías que no pueden o no quieren viajar a los eventos, formen parte de estos.

Para terminar este artículo, me gustaría dar algo de visibilidad a la iniciativa de Codemotion y a Isabel Cabezas para que aquellas mujeres que quieran dar una charla sepan que son bienvenidas en el Codemotion 2017. Yo por mi parte intentaré organizar una mesa redonda en el Meetup que hacemos regularmente en Toledo, acerca de la inclusión de niños (tenemos padres y tíos) y mujeres (no se animan a venir) en el mundo de desarrollo software.

PD: he tenido que reescribir este artículo tantas veces, para evitar problemas, no dispersarme demasiado y hacerlo digerible, que casi voy a tener que coger unas vacaciones en cuanto lo publique.

Anuncios

Las dos palabras que todo profesional debería usar más

Hace unos días, Manuel de la Peña twiteó un texto que comentaba una vieja historia (más bien fábula) de monos, jaulas, preguntas y procedimientos.

Eso me trajo a la memoria pequeño artículo que leí en Hardvard Business Review sobre el arte de hacer preguntas. Un artículo que en su momento me invitó a pensar en la importancia no tanto de las técnicas de hacer preguntas, como de lo esencial que es conocer el “por qué” de las cosas (y para lo que se necesita hacer preguntas, claro).

También me recordó este otro artículo sobre qué hacen las personas que son buenas escuchando y que en mi opinión es una consecuencia de interés genuino en entender los “por qué“.

La falta de interés y esfuerzo en tratar de entender las cosas, sus objetivos y contextos (esto es, el “por qué“) es un tema que me da mucha rabia observar (incluso en mi) y del que hace tiempo que tenía pendiente quejarme un poco en público. En público, porque tiene relación directa con todos los procesos que se realizan en cualquier empresa; también con las buenas prácticas (best practices) que parece que muchas personas se emperran en recomendar o exigir sin entender que dependen del contexto. Y por supuesto porque tiene que ver con los que critican (y criticamos) decisiones de terceros a nivel personal, de negocio o político casi a diario.

Hay por supuesto profesiones en las que en general se necesita hacer preguntas básicas constantemente de forma directa o indirecta, como en medicina (¿le duele aquí?, ¿puede caminar?), donde cada prueba médica es una forma de pregunta y cada mirada o toque está orientado a obtener una respuesta (el ojo clínico). Supongo que haber tenido un padre médico ayuda a ver ciertas cosas de cierta manera.

No obstante, la mayoría, durante la mayor parte del tiempo observa, juzga y condena sin conocer el “por qué” de una decisión. Pocos se molestan en hacer preguntas la mayor parte del tiempo. Mucho menos una tan básica como “¿por qué?“. Y desde luego nunca seguida de otro “¿por qué?” como en el método Toyota-Lean-Kaizen-Six Sigma de los 5 por qué para la mejora de procesos.

Me temo que hemos cogido miedo a hacer preguntas básicas, las más importantes, por miedo a parecer ignorantes y menos valiosos en nuestro entorno personal y puesto de trabajo, e irónicamente eso nos hace más ignorantes y menos valiosos.

Pero no acaba ahí el problema: como nadie hace preguntas para entender un contexto todos acabamos dando por sentado que este no importa y/o que todos tenemos la misma idea en la cabeza, lo que provoca errores y dificultad en la comunicación. Un desastre.

En fin, que las dos palabras que creo que todos deberíamos usar más son evidentemente “¿por que?”. Aunque hay otro par de palabras que, si se usasen con sentimiento real, también deberíamos usar más y mejoraría mucho nuestras vidas: “por favor”. Porque es sorprendente lo bien que responden algunas personas a un poco de interés y educación y como redunda eso en un win-win de libro.

Así que tras quejarme un poco y habiendo dejado algunos enlaces (espero) interesantes, solo puedo cerrar este post invitando a todos a preguntar más y mejor. Con inocencia y abiertos a escuchar.

Android 6.0: Impresiones tras 6 años de Android. 2010 – 2016

motoxplay

Hace casi 6 años compré mi primer Android. Hasta entonces había empleado el tándem Sony Ericsson + Palm TX con mucha efectividad, pero el probar el HTC Magic de un colega me animó a pasarme a Android. Renovarse o morir que dicen.

Creo recordar que alrededor de un 2 años después volví al tandem Sony + Palm debido a los problemas de autonomía, rendimiento y limitaciones del software en cuanto usabilidad y capacidades del Samsung Galaxy que había adquirido. Había intentado usarlo pero había acabado siendo un lastre insoportable.

Durante los últimos 3 años he vivido felizmente en el ecosistema Microsoft, primero con un Nokia 520 y después con un 630 que duró hasta que, por razones en parte comentadas en otro post, decidí volver a Android.

Una vez descrito mi periplo pensaba comentar mis impresiones sobre la plataforma de Google, pero releyendo lo que escribí entonces me he dado cuenta de que hay poco que añadir sobre Android.

Entre las versiones 1.5 y 2.1 que probé con Samsung y la 6.0 con Motorola, han pasado unos cuantos años, pero aparte de una muy necesaria mejora visual y un upgrade brutal de hardware, el sistema sigue siendo el mismo: complejo de usar, orientado totalmente a las apps (no a los usuarios) y con un desprecio total por la privacidad. Supongo que los incentivos hacen al producto, y en el caso de Google el vender publicidad lleva a esto.

Lo que sí puedo confirmar es que el objetivo de Google de ser el Windows para móviles puede darse por completado. Tan es así que Microsoft sigue la senda que tomaron Palm y Blackberry con desigual resultado: orientarse a los usuarios profesionales. Y no es extraño porque lo que más noto al volver a Android es que el sistema en sí, y el ecosistema que hay alrededor, están constantemente compitiendo por atraer mi atención. Es algo que hace tan bien que apenas se nota y el “golpe” se olvida en unos días, pero habiendo visto el efecto, veo claro que tengo que usarlo lo menos posible si quiero hacer algo que no sea perder el tiempo en un bucle de entretenimiento y ocio sin fin.

Quizá ese sea el secreto del éxito de Android. Que el ocio vende más que la productividad personal. Solo espero que Microsoft no abandone y sigamos manteniendo una tercera vía al ocio de Android y el postureo de Apple: un verdadero dispositivo con vocación de asistir a la persona. O al menos que este Android me dure más que el anterior, que no sería poco.

Para no cerrar el artículo de forma negativa diré que el reconocimiento de audio funciona fantásticamente bien (como entrada de texto o como asistente) y que tener todas las aplicaciones de Microsoft ayuda en cierta forma a minimizar el enfoque lúdico del sistema. Además la existencia de un monopolio “gratuito” y duradero como el que ha conseguido Google se traduce en una relación precio que parece excelente a día de hoy.

 

Menos es más. Personas, problemas y herramientas

WP_20151225_001

Disclaimer: Este post no pretende ser divertido, ni entretener. Se trata de mis reflexiones más o menos estructuradas acerca de productos, gestión de proyectos, implantaciones de software, escalar procesos, mejorar organizaciones y en definitiva, cómo trabajar mejor.

Simplicidad

Cuantos más objetivos hay en un proyecto, más complicado es cumplirlos.

Cuantas más personas haya implicadas, más difícil es coordinarlas y más opiniones deben ser tenidas en cuenta.

Cuantos más largos son los periodos entre desarrollo y producción, menos feedback recibimos, menos útil resulta y por tanto más difícil es cumplir los objetivos del proyecto.

Cuanto mayor sea el presupuesto de un proyecto, mayor número de personas tendrán que implicarse en él y más objetivos necesitará para justificar su arranque.

Cuanto mayor sea el presupuesto gastado más difícil (políticamente) se hace cancelar un proyecto fallido o innecesario.

Con estas premisas, suposiciones o experiencia, podemos deducir que en los proyectos de software, menos es más, y por lo tanto tener claro estos consejos, best practices o máximas, para mejorar nuestros resultados:

  1. Focalízate en un único objetivo.
  2. Entrega un MVP lo antes posible al menor número de personas posible.
  3. Itera en base al feedback y amplía el alcance.
  4. Evita lastre, reduce la inercia: personas, presupuestos, objetivos, tiempo.

Variabilidad

Si puedes hacer algo siempre de la misma manera o buscando el mismo resultado, puedes llegar a perfeccionar tus procesos hasta el punto de acortar tiempo y coste cada vez que hagas lo mismo o busques el mismo resultado.

No importa lo complejo del proceso: siempre y cuando no varíe puedes automatizarlo, convertirlo en un hábito, en un acto reflejo. Eso significa que reducir la variabilidad conducirá a mejorar el resultado de tus procesos y por extensión de los proyectos que los requieran. También se deduce que la variabilidad afecta negativamente a los procesos y por extensión a los proyectos que los requieran.

Un proceso automático es un proceso optimizable (es repetible, medible, comparable y se puede cambiar) y uno que no necesita a nadie para realizarse por lo que además puede escalar (no importa si tienes que ejecutarlo 1 vez o 1 millón de veces). Si está completamente automatizado ni siquiera necesitas que nadie lo entienda por lo que tampoco requiere formación o esta es mínima.

Para reducir la variabilidad necesitas reducir opciones, simplificar: menos objetivos, menos personas, menos tiempo, menor coste, todo debe ser lo mínimo posible.

Para lidiar con la variabilidad restante, necesitas entender la naturaleza de esta, sus causas, y así tratar con esta en su origen, ya sea eliminándola, resolviéndola o minimizando su impacto.

Productos

Uno de los motivos por los que el software como producto dé en general mejores resultados que el software a medida (buy vs build) es que la variabilidad es menor. Se “estandariza” todo lo posible y el resto se deja fuera o se trata mediante integración, plug-ins, desarrollos, etc. Esto permite focalizarse en menos objetivos e implicar a menos gente.

Un producto de software resuelve un problema o conjunto de problemas bien definido mediante un número finito de funcionalidades que no puedes modificar a capricho y que siempre actúan de la misma forma (automatismos, estandarización). Esa limitación hace que escale mejor (por estandarización) y esté más optimizado que un desarrollo a medida (por ejemplo: se le hace más y mejor testeo).

Lo anterior deja de ser cierto cuando retorcemos un producto para adaptarlo a un problema para el que no está diseñado. Y pasa mucho, particularmente en productos complejos. Tampoco sucede en “productos” para un solo cliente, que se mire como se mire, son proyectos a medida.

Comprensión

Cuando al tratar de resolver un problema, o no tenemos éxito, o el problema reaparece, o se provoca una sucesión de efectos secundarios al “solucionarlo“, debemos darnos cuenta de que:

  1. No entendemos el problema.
  2. Hay más de un problema.

A partir de aquí tenemos dos opciones:

  1. Nos paramos a analizar los problemas.
  2. Lanzamos “soluciones” (tiempo y dinero de alguien) al problema hasta que estos desaparezcan.

La segunda opción puede no funcionar, o funcionar solo temporalmente o provocar una sucesión de problemas en cascada, así que voy a dar por hecho que continuamos por el camino de pararnos a pensar para entender el problema y elementos adicionales que no hayamos visto antes. Aquí corremos el riesgo de “parálisis por análisis” por lo que deberíamos intentar focalizarnos en objetivos que puedan producir feedback rápido.

Una vez entendido e identificado el problema y sus causas (variabilidad), deberíamos automatizarlo. Digo esto, porque la única forma de demostrar que hemos resuelto un problema es automatizarlo. De otro modo puede que solo hayamos resuelto un único caso particular de un problema. Esto no tiene nada de malo per se, pero no podemos escalar esa solución (aprovecharla en otros casos). También hay que intentar no retorcer los problemas para que nuestra solución sea válida, ni tratar de resolver todos los problemas posibles. Es complicado saber dónde parar para no generar burocracia y sobre-ingeniería.

Por todo esto, deduzco que tratar de resolver un problema (no un caso concreto) sin entender su naturaleza resultará en un fiasco, ya sea reconocido o envuelto en marketing. En el primer caso habremos aprendido algo, en el segundo solo habremos desperdiciado el tiempo y el dinero de un montón de gente.

Conclusiones

Si no entendemos el problema a resolver, tendremos que enfrentarnos a una gran variabilidad y por lo tanto emplearemos una gran cantidad de tiempo y recursos en algo que va a acabar mal, por lo que es mejor que vayamos preparando el marketing.

Esto aplica tanto a tratar de resolver nosotros el problema, como a comprar una herramienta o proceso que resuelva el problema. Este último caso es muy habitual y transcurre del siguiente modo:

  • Fulano tiene un conjunto de problemas que desconoce: X, Y, Z.
  • Mengano tiene un producto que resuelve un problema concreto X.
  • Fulano compra el producto de Mengano pero su conjunto de problemas no se resuelve.
  • A partir de aquí, pueden pasar dos cosas:
    1. Que Fulano se dé cuenta de que tiene problemas que desconocía y trate de aprender más sobre estos para resolverlos.
    2. Que se recurra al látigo, el marketing y cursos de formación para ñapear con el producto de Mengano hasta que la gente se canse o se acabe el dinero.

Si todo lo anterior es correcto, es posible que una forma de detectar cuándo no se entiende un problema en un proyecto de software sea observar lo siguiente (vago y subjetivo, pero identificable si se cuenta con experiencia):

  • Un numero amplio de objetivos.
  • Un número elevado de personas implicadas.
  • Feedback escaso y espaciado (implantación Big Bang).
  • Presupuesto elevado.

Mi última reflexión al hilo de todo esto es que me parece mucho más importante disponer de las personas adecuadas (con experiencia, buena actitud, cultura sana, curiosidad…) que cualquier tecnología. Quizá no sea una gran reflexión, pero creo que es importante recalcar de vez en cuando que la tecnología es la parte menos importante de cualquier proyecto o producto de software.

A veces la experiencia nos cambia a peor

WP_20150929_002

Hace unos días, en la cola para el control de equipajes de la estación de Atocha observé la siguiente escena: Una mujer mayor con apariencia bastante cansada pasaba las maletas en la máquina de rayos X. El operario, un guardia de seguridad que se encontraba sentado mirando el monitor, increpó a la señora en relación al peso del equipaje y añadió una expresión bastante impertinente en ese contexto aclarando que el AVE no era un servicio de mudanzas.

En aquel momento el guardia de seguridad me pareció inoportuno y desagradable, siendo el último comentario algo que podría haberse ahorrado por el bien de todos, pero reflexionando un poco más he empezado a pensar en cómo la experiencia en el puesto de ese guardia de seguridad en particular influyó para llegar a ese comentario.

Ese guardia de seguridad debe tener una experiencia que incluye, al margen de la formación que le hayan podido dar, la vigilancia de miles de pasajeros diarios, el control de la máquina de análisis de equipajes, horas de tratamiento cara a cara con pasajeros difíciles. Todo eso sumando a una falta de actividad del puesto, la idea de que hasta cierto punto es responsable de que no se repita un 11M y a un más que probable efecto psicológico derivado del uso de una máquina altamente invasiva de la privacidad de hombres, mujeres y niños (¿sensación de impunidad? ¿amplificación de tendencias machistas? ¿objetivización de las personas?).

Debido a mi propia experiencia como consultor informático, veo un paralelismo con muchos técnicos de gran experiencia en su campo, miles de horas de trabajo, decenas de empresas y soluciones empresariales para todas ellas. La relación entre el técnico con gran experiencia y el guardia de seguridad que observé hace unos días es que ambos son susceptibles de dar respuestas que pueden sonar bordes (y serlo de hecho) ante determinadas acciones de los clientes o usuarios de los sistemas.

En este caso el guardia estaba enunciando un hecho: que el objetivo del servicio del AVE no es el de transporte de mercancías, sino de personas. Además informaba de ciertas reglas establecidas sobre el peso del equipaje y de forma implícita acusaba a la usuaria de ser descuidada en el uso del servicio cuya responsabilidad le había sido confiada.

He visto ese tipo de mensajes en muchas otras personas, técnicos, gestores, comerciales… bajo circunstancias similares. En informática es de hecho un tema recurrente, ya sea en tiras cómicas de Dilbert o en expresiones como luser (mezcla de looser, “perdedor” y user, “usuario”), aunque mucho más asociado al perfil de técnico de sistemas que de desarrollador de aplicaciones.

El caso es que creo que este es un ejemplo de cómo determinados contextos (responsabilidad de un servicio, mal uso por parte de los usuarios, mucha experiencia real, baja realización personal…) pueden hacer que personas que probablemente serían normales y amables en otro momento, lancen puyas contra una persona despistada de una forma no demasiado correcta. Como dice Zimbardo, el sistema en el que vivimos, nos cambia. Y aunque no se le preste atención, esto es algo que tiene importancia tanto en un área clásica como es la seguridad física, como en una puntera como es la colaboración con herramientas informáticas en la nube. Nadie está a salvo.

Así que la próxima vez que veas a alguien comportarse de forma brusca, desagradable, deshonesta… pregúntate hasta qué punto es un problema de selección de personal o derivado del propio trabajo, bien por cultura empresarial o bien por las características del propio puesto.

Hace algunos años escribí sobre el burnout a raíz de mi experiencia personal y para recomendar un libro aun interesante para cualquiera que esté en el mercado laboral y que junto con la literatura de Zimbardo hacen una buena lectura para reflexionar sobre el impacto de las organizaciones en las personas que la componen; y en el impacto de determinados tipos de trabajo sobre la psicología de personas por lo demás normales.

Algunos post relacionados: Contexto y degradación del trabajo IContexto y degradación del trabajo II, Capitalismo Caníbal.

Analogías y desarrollo de software III (fin)

Crónicas de Islandia I: GPS

Llegamos la última parte de esta serie sobre analogías e informática. En este post voy a exponer las metáforas y modelos mentales que suelo encontrar asociados a sistemas informáticos y su evolución. Esta es la parte más “avanzada” de la serie así que si no te interesa el mundillo como profesional, probablemente puedes ahorrarte el ladrillo.

Paso a producción como proceso explosivo

Este modelo mental trata las entradas a producción de un sistema como algo inmediato y de alto impacto. Eso significa que seguramente estamos ante un proyecto waterfall (en cascada) que incluye montones de elementos nuevos y poco o nada probados (procesos, sistemas, integraciones, herramientas…).

Entre los sinónimos encontramos “Big Bang“, lo cual resulta irónico al pensar en la astronómica cantidad de tiempo que se necesita dejar transcurrir entre un Big Bang y un Universo habitable. Y eso sin pensar en los ajustes.

Normalmente este proceso falla en proyectos grandes. A veces incluso antes de llegar a intentarse, dado que impacta en demasiadas áreas a la vez como para que todo el mundo esté de acuerdo en una fecha y funcionalidad. Por eso aunque este modelo se usa, acaba mutando a un proceso de paso a producción incremental o algo intermedio, pero en cualquier caso mucho más humilde en el impacto producido.

La ventaja de este modelo es que todo el mundo está encantado con la idea de no tener que hacer nada hasta un día concreto: nada de formación, evolucionar el producto, recabar feedback, pensar… Por eso es fácil que el cliente lo acepte (o exija) y el proveedor lo ofrezca. Y por eso es fácil que fracase: no es una solución, es una patada adelante a un conjunto de problemas que acabarán apareciendo igualmente.

Seguramente ahora estés pensando que has visto una buena entrada en producción de este tipo y que estoy exagerando. Puede que tengas razón, pero deberías pensar si ese proyecto que recuerdas no habría tenido mucho mejor resultado si se hubiese abordado como un desarrollo incremental, iterativo, con mejoras continuas de los procesos y usuarios involucrados en aprender y dar feedback. De eso va la agilidad, el Lean, los MVP… así que vuelve a pensar.

El entorno tecnológico como ecosistema

Hace unos años pensaba que este modelo mental estaba más extendido pero he podido comprobar que aunque se usa mucho por parte de técnicos, no parece tan habitual entre otros perfiles de la profesión.

La idea es que, al igual que una selva o una cueva son sistemas con ciertas características, límites, fauna y flora, los sistemas informáticos son entidades vivas de un entorno con ciertas características y límites que funcionan unidos. Lo más interesante de este sistema es que instintivamente se entiende que hay que mantener un equilibrio entre las partes para que el ecosistema no se derrumbe. Y que cualquier modificación del mismo requiere ciertos cuidados y no pueden realizarse a gran escala y de una sola vez si queremos conservar el ecosistema.

Podemos ver las diferentes piezas de hardware, software y servicios como elementos de ese ecosistema y podemos entender fácilmente la necesidad de vigilarlo y cuidarlo, interviniendo regularmente para mantenerlo sano.

El único “pero” que le veo a este modelo es que se le puede coger cariño al ecosistema o pensar que es un ente endeble que no debe cambiar. Y eso puede hacernos difícil ver cambios necesarios. Por ejemplo, aunque vivamos en un desierto y estemos perfectamente adaptados al mismo, quizá sería bueno evolucionar a algo diferente. Y aunque estemos muy cómodos en nuestro bosque, deberíamos empezar a cambiar algo para adaptarnos a la glaciación que viene.

Evolución y versiones de software

La Evolución es una idea que apenas tiene 300 años, y en mi opinión el público en general aún tiene (y seguirá teniendo) problemas para entenderla debido quizá a que los seres humanos tenemos capacidades muy limitadas para entender los efectos acumulativos, los periodos mayores a un puñado de años y las matemáticas.

Aun con esa falta de entendimiento la idea es seductora, potente, y se emplea para hablar de modelos de desarrollo incrementales, MVP (mínimo producto viable) y versiones de producto.

La idea es que una evolución del software, una nueva versión, un… evolutivo, es una versión diferente, mejor y más adaptada del software que tenemos en manos actualmente. En realidad la idea es fácil de transmitir y en general creo que funciona bien. Sin embargo la analogía no es correcta del todo y eso puede llevarla por un mal camino.

Se supone que la Evolución se produce poco a poco a lo largo de mucho tiempo, mientras que los desarrollos evolutivos son conjuntos de cambios normalmente bastante mayores en relación y que se introducen a saltos. Me recuerda mucho a la disputa sobre la que leía hace casi 2 décadas en los libros de Richard Dawkins acerca de si la evolución era “continua” apoyada por él mismo o si era “a saltos” apoyada por Stephen Jay Gould.

En resumen, aunque creo que la idea está bien, no parece que realmente llegue muy lejos por los problemas que tiene entender la Evolución, con lo que aunque se usa mucho esta analogía, me temo que su utilidad es muy limitada si no tenemos un interlocutor adecuado.

Selección sexual y testing A/B

Ahora que se ha puesto de moda el testing A/B, estoy empezando a ver el uso de la analogía con la selección sexual. Si entiendes como funciona esta técnica y qué es la selección sexual, verás la relación evidente y podrás anticipar que es una técnica interesante para evolucionar el software (ver analogía anterior: Evolución). En otro caso, me temo que no tengo espacio suficiente en este artículo para tratar sobre ambos conceptos por lo que recomiendo unas horas de navegación y estudio.

En resumen, la idea del A/B testing es que si entiendes cómo funciona la selección sexual (organismos compitiendo entre sí por reproducirse con una pareja y producir descendencia de características similares) puedes ver como conecta eso con la idea de poner 2 versiones diferentes de un mismo software con características similares y pequeñas diferencias para que compitan por un mismo grupo de usuarios. Al cabo de algún tiempo y muchos usuarios, tendremos una tendencia clara (en el mejor de los casos) que nos indicarán qué característica merece sobrevivir y evolucionar en nuestro software.

Esta analogía no suele ser necesaria para explicar los conceptos, pero si para explorar las limitaciones de la técnica. Lamentablemente requiere de conocimientos sobre Evolución, que como he comentado no son demasiado comunes, por lo que esta analogía y sus críticas solo la estoy viendo en entornos profesionales de discusión sobre la técnica, no en comunicaciones cliente – proveedor.

Como nota adicional es interesante ver que esta técnica se ha copiado de otro contexto, el de márquetin de productos si no he entendido mal, lo que resulta irónico: alguien entendió la similitud entre ambos mundos y decidió emplear la técnica, como Henry Ford en su día con la cadena de montaje…

Y hasta aquí llegamos con esta serie de artículos sobre analogías y software.

Analogías y desarrollo de software II

Crónicas de Islandia IV: Consejos a viajeros

En el post anterior comentaba algunas analogías comunes en informática. En este post voy a comentar algunas un poco más avanzadas sobre desarrollo de software pero también muy comunes.

Desarrollo de software como construcción de objetos físicos

Aunque insisto en que el desarrollo es un proceso de diseño y no de construcción, esta analogía es un clásico y te encuentras la idea en casi todos lados.

Se considera que construir una aplicación es una actividad similar a construir un edificio o un avión. Se necesitan arquitectos, montones de documentación y maquetas, ingentes cantidades de dinero y numerosas cuadrillas y material especializado. Además se considera que el diseño es barato y la construcción cara. Por último este modelo mental invita a pensar en soluciones que permanecerán más o menos invariables a lo largo de muchos, muchos años.

Lo más importante que hay que decir sobre este modelo es que está completamente equivocado. Si lo veo asomar en un proyecto, sé que vamos a tener problemas, que el producto será inferior a lo que podría ser y que va a costar mucho más de lo que debería. Pero al menos es un modelo que puedes usar para comunicarte con el cliente. Y si demuestras que sabes más de construcción (estilos, historia, materiales, anécdotas sobre grandes obras…) que el interlocutor y haces una intensa labor de comunicación y pedagogía puede que consigas sacar el proyecto adelante en unas condiciones decentes. Pero en cualquier caso es un modelo terrible.

Desarrollo de software como viaje

En este modelo mental, el desarrollo es como un viaje. Sabes de donde sales, marcas un destino y estableces un presupuesto, tiempo y recursos a emplear. Con esos parámetros estableces los parámetros del viaje: Bussines, low cost, escalas, duración, fechas, extras…

Lo bueno de este modelo es que se entiende que cambiar de ruta o destino puede ser costoso o barato en diferentes etapas del viaje. Que un medio de transporte (tecnología, recurso) puede ser necesario en algunos casos. Que habrá retrasos en algunas etapas y eventos inesperados (tormentas, retrasos acumulados, accidentes). Pero creo que lo más interesante es que ofrece la posibilidad de aprender durante el viaje y cambiar de rumbo o quedarse en una etapa concreta si el cliente lo considera útil.

Lamentablemente este modelo mental no es muy común y tiende a despreciarse al parecer menos “definido” (lo cual es una mera percepción, pero es difícil convencer a alguien sin experiencia de esto), pero puede dar mucho juego si entendemos que algunos clientes quieren un viaje al África salvaje (grandes riesgos, incógnitas, mucho que ganar, caro…) y otros meramente quieren un crucero con todo pagado por el Mediterráneo (barato, en masa…). Con esta analogía entendemos que diferentes proyectos deben gestionarse, venderse y realizarse de manera radicalmente diferente. Que no hay una bala de plata.

Desarrollo de software como guerra

En este modelo mental el cliente es el enemigo y cada proyecto es una campaña militar que solo puede acabar en victoria o muerte. Es habitual encontrar este modelo en muchas grandes empresas, tanto como cliente, como proveedor. Y en esos entornos hostiles (las grandes empresas tienden a convertirse en reinos de taifas, grupos de presión e interés, cada uno con sus rencillas) es fácil transmitir esta visión y creérsela.

Lo interesante de este modelo es que es divertido. Me explico: Poder lanzar una ofensiva bélica contra el frente enemigo y conquistar cada una de las ciudades importantes en tiempo record y sin bajas, es mucho más interesante que poder entregar el módulo de gestión de inventario de una factoría de tornillos en tiempo y coste. Cada paso a producción produce héroes y gloria en lugar de trabajadores quemados y resultados mediocres. Y el fin de proyecto significa la vuelta a casa con medallas y desfile, en lugar del papeleo de cierre de esa web de abogados que acabamos de terminar.

La verdad es que este modelo solo me parece útil para motivar a la gente a continuar trabajando, o como forma de tratar con un cliente/proveedor realmente malo. Por eso, si necesitas recurrir a él significa que, o bien estas en un contexto de trabajo pésimo, o bien te estas convirtiendo en un sociópata muy competitivo que busca ganar por encima del resultado a largo plazo del proyecto. En cualquier caso, el uso de este modelo es una señal bastante clara de que deberías buscar otro lugar de trabajo lo antes posible.

Continuará…