viernes, 24 de enero de 2014

El modelo Usuario-programador

La ingeniería del software es aún una disciplina algo inmadura.  Aunque hay que reconocer los avances de los últimos años, creo que le faltan algunas décadas para consolidarse a un nivel similar al de disciplinas como la física, medicina o arquitectura por poner algunos ejemplos.  Me cabe el consuelo de que otras como la psicología andan más atrás.  Uf, cuando lea esto un psicólogo me va a protestar, pero estoy dispuesto a argumentarlo. Me encantan las discusiones constructivas.

Hoy voy a hablar de un modelo de elaboración de software que aunque algo primitivo, abunda más de lo que parece.  Muchos además piensan que es el modelo ideal. Le llamo Usuario-Programador  y consiste en que unos programadores son mandados por los usuarios futuros de la aplicación para elaborarla.  Imaginemos una librería.  Pues bien, el librero como buen conocedor de su negocio, contrata unos programadores y con ello hace... ¡el mejor programa del mundo para librerías!, como me dicen algunos defensores de este método. De la misma forma un mecánico con unos programadores puede hacer ¡el mejor programa del mundo para talleres!.

He visto aplicar este método en multitud de ocasiones.  En la mayoría de las veces con resultado negativo.  Bueno, voy a ser sincero, todas las veces.  El resultado era a veces una aplicación intratable que no servía para nada. En otros una aplicación mediocre que resolvía algunos problemas inmediatos. No he visto ningún caso que me motive una opinión positiva sobre esta forma de desarrollar aplicaciones.

Mi opinión es que es un método malo y voy a intentar argumentarlo.

El primer problema es resolver los problemas inmediatos para eludir sus consecuencias.  Este problema consiste en dar soluciones a los problemas del día a día creando problemas a medio y largo plazo.  Lo que popularmente se conoce como pan para hoy y hambre para mañana.  Ni el usuario ni el programador están para estudiar la repercusiones futuras. No son responsable de una visión holística de los problemas.  Por eso es normal que actúen de una manera.  Voy a citar dos ejemplos.  Uno exagerado y otro más sutil

El ejemplo exagerado, pero que me ha ocurrido en varias ocasiones, es que el usuario de un TPV pide poder escribir un artículo a mano.  Razona de la siguiente forma: Tengo en mis manos un artículo, que sé lo que vale y no encuentro su código, así que pongo el nombre, el precio y ... ya he resuelto el problema. Me pasó la primera vez en una empresa de pinturas.  Hace de esto muchos años y aún no estaban los códigos de barras tan impuestos como lo estuvieron al poco tiempo. Eran aficionados a usar un artículo genérico y ponerle el precio.  Ellos hubieran suspirado por esta solución.  Pero claro, basta con pensar un poco para ver que crea más problemas de los que resuelve.  Es imposible controlar así las existencias.  De hecho en esta empresa que cito solucionamos mucho cuando pusimos en marcha el sistema de código de barras. ¡Conseguimos controlar el inventario!.   Este ejemplo ilustra una petición que un usuario pide a la ligera, que cree que le va a ayudar y lo que hace es crear un problema serio.  Por suerte, muchos usuarios no caerían en este caso, porque no es difícil darse cuenta del error.  Pero ahora viene otro ejemplo en el que caerían más.

Es un caso real.  Un cliente nos pidió un formato de etiqueta. Le instalamos uno de los que incluía la aplicación que le venía, opinión mía, como anillo al dedo.  Pero resulta que al poco pidió un cambio y, debido a que era fácil, a que  no se cumplieron los procedimientos como estaban previsto (esto es una autocrítica) y a que el cliente presionó, se hizo el cambio... para dejarlo contento.   En la etiqueta se sustituyó el código del artículo (que no era significativo y no lo sabían manejar) por la referencia de proveedor (que les permitía buscarlo más fácilmente en catálogo).  Una petición del cliente que mejoraba la aplicación en contra de mis indicaciones.

¿Mejoraba?  Menos mal que llegué a tiempo de pararla.  Pero cuando llegué ya tenían unos cientos de artículos etiquetados.  Claro que dos semanas después habrían sido miles.   ¿Dónde estaba el problema?  Pues fue fácil que el cliente lo viera.  Pasamos varios artículos por el TPV y dijo que una mesa era un cuadro.  ¿Cómo que el ordenador confundía una mesa con un cuadro? Pues porque ambos proveedores tenían el mismo código.  Pasaba en pocos casos, pero los suficientes para organizar un buen problema.  El cliente desconocía los criterios técnicos que tiene que cumplir un código.  Hay otro hecho más, pero ese prefiero comentario en otra ocasión porque es más profundo. Esa petición de que el código fuera más 'humano' es un error.  Se busca una seguridad falsa que solo sirve para generar problemas.  Ya lo justificaré.