Seguro que a menudo tenéis que hablar con ejecutivos y directivos de empresa que son clavaditos al jefe de Dilbert, que piensa que sabe mucho de tecnología y desarrollo software cuando no tiene ni p*** idea.

- Dilbert by Scott Adams

Y esto,  cuando el software domina el mundo (de momento, hasta que lo haga la IA) es un problema para él y para todos los pobres programadores que tenga en su equipo.

Cuando el jefe (o aún peor, el que vende los proyectos a clientes externos) no entiende como de complejo y variable es el proceso de desarrollo y empieza a prometer lo imposible, después pagamos todos.

Es por eso que me ha encantado el artículo: “The Top 10 things executives should know about software” donde el autor presenta la lista de las diez cosas más importantes que todo directivo debería saber sobre el mundo del software. Yo si fuera tú, imprimiría la lista y la pegaría en la nevera comunitaria, a ver si así se dan por enterados… Os hago un resumen de lo que cuenta. Empecemos:

  1. El software no es magia. A veces parece que haga magia pero es el resultado de un proceso de desarrollo. Y a diferencia de la magia, no se puede crear software del aire.  Hay que planificarlo, diseñarlo y crearlo. Una lástima que no sea un truco pero es así.
  2. Un software se entrega pero nunca está terminado. Requiere muchas iteraciones (ejemplo, requisitos ambiguos). Además, siempre habrá actualizaciones, nuevas peticiones, adaptaciones a cambios en servicios externos… Hay que tener en cuenta toda esta actividad futura cuando se vende el proyecto y no venderlo como algo que se va a tener list en X meses.
  3. El desarrollo es un trabajo en equipo. Nadie puede hacerlo todo. Podemos tener ingenieros 10x  o con un perfil en T pero aún así hace falta un equipo (y el presupuesto para mantenerlo, entrenarlo,…)
  4. El diseño no es solo la apariencia del software, es también el cómo funciona. El diseño de la interfaz dirige el flujo de trabajo y de interacción con el programa. Al mostrar ese diseño al usuario no le estamos preguntado qué color le gusta más sinó como quiere interaccionar con el software.
  5. La seguridad depende de todos. La seguridad no es algo booleano sino algo que tiene que empapar todos los aspectos del desarrollo. Y que hay que diseñar desde el inicio. No será el aspecto más “sexy” de tu propuesta al cliente pero es algo que dará por supuesto.
  6. El tamaño de una funcionalidad (según la perciben los usuarios) no es un buen predictor del tiempo de desarrollo. Sólo los ingenieros software pueden estimar el coste de implementar una funcionalidad. Ni su importancia ni su tamaño son buenos indicadores de la complejidad de su desarrollo Querido manager, nunca prometas al cliente una nueva funcionalidad sin consultarlo antes con tu equipo de desarrollo. Click To Tweet
  7. La grandeza es el resultado de miles de pequeñas mejoras. Y para estar seguro que los pequeños cambios son de verdad mejoras hay que definir cuales son los indicadores que nos van a permitir medir el progreso del proyecto y discutirlos con el cliente
  8. La deuda técnica es inevitable. La deuda técnica es el trabajo extra que te llevará en el futuro arreglar cosas para las que hoy estás tomando un atajo. El cliente tiene que entenderlo y puede escoger entre minimizarla a día de hoy o pagar un precio más alto en el futuro. En todo caso, como con toda deuda, hay que pagarla
  9. El software no se ejecuta solito. Hay que enseñar a los usuarios y “cuidarlo”. Lo que sería la parte “Ops” del DevOps. Y esta parte más operacional (ej. backups automáticos) hay que también tenerla en cuenta al preparar los presupuestos.
  10. Todo software complejo necesita de DevOps. Un poco resumiendo muchas de las anteriores, nada mejor que tener en marcha un plan de DevOps que se encargue de optimizar el proceso de mejora continua del software, tanto para la parte más funcional como para la parte más operacional.

Seguro que podríamos hacer una lista casi infinita pero tampoco queremos ocasionar un “buffer overflow” a nuestros queridos directivos, ¿no?.

¿Cuáles serían las vuestras? ¿Qué errores gravísimos veis cometer a los directivos o comerciales de vuestra empresa que luego os tenéis que comer vosotros?