Chess - antoniomartel.com

Archivos de Autor: Antonio Martel

Preferimos programadores que trabajan hasta las tres de la mañana

Hay un dilema que nos explica Gerald Weinberg en su libro Becoming a Technical Leader. Nos dice: si tuvieras que hacer un viaje con alguien que conduzca, ¿con quién preferirías ir?

  1. Con alguien que nunca ha tenido un accidente, pero probablemente estaría indeciso en caso de tener uno.
  2. Con alguien que tiene un accidente de media por semana, pero es muy resolutivo en soluciones de emergencia.

Aunque parezca mentira, mucha gente suele preferir la opción 2. La guerra es más heroica, nos gusta el drama y que nos salven de apuros. El programador que está hasta las tres de la mañana arreglando asuntos se convierte en nuestro héroe, al que recompensamos y estimamos por habernos salvado el pellejo una vez más.

¿No sería mejor recompensar programadores y mánagers que nos mantienen fuera de las crisis? Será más aburrido, y no tendrás que organizar gabinetes de crisis o war-rooms que nos mantenga en el foco de atención, pero mantendremos un mejor estado de salud en nuestra organización (y no solo allí).

Bugs vs. Features

Corrige los errores primero, resuelve la deuda técnica y esas incidencias que se repiten con frecuencia y que hacen que tengas que dejarlo todo porque el sistema está caído otra vez. Haz un ranking de los bugs que más dolor de cabeza te dan y atácalos por prioridad (comienza por las migrañas, continúa luego con las jaquecas, y termina por último con las cefaleas).

Los errores en producción te quitarán la concentración que tenías en lo que estabas haciendo y causarán múltiples incidencias. Harán además que los clientes se quejen y no estén satisfechos con tu producto. Es tiempo que bien podrías estar dedicando a desarrollar nuevas funcionalidades que mejoran el servicio a los usuarios.

Por otro lado, a nadie le gusta trabajar en productos que fallan a menudo o tratar con clientes enfadados. Los desarrolladores suelen preferir evolucionar sistemas robustos de los que están orgullosos y que tienen una tasa baja de tiempo entre fallos o de tiempo necesario para resolverlos o en responder (échale un vistazo a MTBF, MTTR, MTTA y MTTF y asegúrate de calcularlos y tenerlos bajo control).


Referencias:

Ley de Gall o por qué fallan las grandes iniciativas

La ley de Gall nos dice que: “Un sistema complejo que funciona se encuentra de manera invariable como el resultado de un sistema simple que funcionaba. La proposición inversa también parece correcta: Un sistema complejo diseñado desde cero no funciona y no se conseguirá hacerlo funcionar. Tienes que empezar de nuevo con un sistema simple que funcione”.

Por esto, los grandes proyectos que parte de cero con un gran presupuesto y que están años construyéndose, fallan estrepitosamente. No han validado sus suposiciones con los usuarios, no saben si son válidas o no, pero siguen construyendo sobre esas ideas hasta que después de miles de euros gastados, se abre al público y nadie lo usa o te dejan comentarios negativos.

Es mejor construir un sistema sencillo que te permita validar tu propuesta, dejar que lo prueben, y mejorar luego con lo aprendido. Seguir construyendo a partir de ahí con lo que te demanden ahora y no con el plan predeterminado que alguien pensó un par de años atrás.

Si con tu pequeño proyecto inicial no consigues despertar interés, cambia el enfoque y haz alguna otra prueba. Si aún así no consigues que prenda la llama, quizás sea mejor destinar el presupuesto a otro producto de tu porfolio (evita seguir profundizando aún más en los costos hundidos, y ten cuenta el coste de oportunidad de trabajar en otro proyecto que sí dé sus réditos).


Referencias:

El estrés y la toma de decisiones

Creo que era el libro Factfulness de Hans Rosling el que mencionaba un experimento en una zona de agricultores. Se les pasó tests de inteligencia cuando acababan de recoger sus cosechas y sus resultados eran altos cuando tenían dinero en sus manos y todo iba bien.

Casi un año después, justo antes de recoger las cosechas, y cuando ya habían agotado sus recursos, se les volvió a hacer el test. Su CI era significativamente más bajo. El estrés hacía que no pudieran pensar con claridad y tomaran decisiones equivocadas. Muchos recurrían a créditos de usura para intentar llegar al siguiente cobro, pero esos préstamos les mantenían irremediablemente enganchados a deudas eternas.

A todos nos pasa esto en reuniones en la que se nos comunica una urgencia y se nos apremia a tomar una decisión. Si además tenemos que negociar y expresar nuestras ideas en un idioma como el inglés, que no es nuestra lengua materna, aún podemos parecer un poco más tontos (de hecho, en ese momento o durante esos días, somos en realidad algo menos inteligentes).

Evita tomar decisiones en caliente. Discute luego con el equipo los pros y los contras. No te comprometas a soluciones drásticas por querer parecer enérgico, porque te dejarán enganchado a una deuda (quizás técnica) interminable.

Cómo completar antes tus proyectos

Según la web de Eliyahu Goldratt, la evidencia prueba que puedes completar tus proyectos (y productos) más rápido si:

  • Pasas menos tiempo planificándolos. Evita la parálisis por análisis y utilizar mucho tiempo intentando adivinar lo que solo sabrás cuando te pongas manos a la obra.
  • Usas estas tres reglas en su ejecución:
    • Retrasa lo más que puedas el inicio de los proyectos (conseguirás así terminarlo antes: para cuando lo inicies tendrás más conocimiento del mercado o de las incertidumbres por resolver).
    • Elimina la multitarea: cada persona debería tener solo una tarea concreta a la vez.
    • Pon en cuarentena las tareas que generan dudas o incertidumbre y gestiónalas adecuadamente (incluyendo la Ley de Murphy).

Referencias:

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad