Lo peor de desarrollar software

Imagínate que quieres ir a comer a un restaurante.

Después de buscar un poco, te decides por una arrocería que tiene una pinta estupenda. Cuando llegas, un atento camarero te trae la carta y eliges un arroz con bogavante que, según te aconseja el solícito camarero, es magnífico.

- Tardará unos 10 minutos en prepararse, queremos asegurarnos de que todo está a su gusto – te advierte.

Te resulta extraño porque sueles cocinar bastante arroz y sabes que tarda unos 20 minutos en estar listo, pero prefieres pensar que aquí son muy eficientes, porque la alternativa de que tengan el arroz hecho y lo vayan a recalentar te pone un poco nervioso.

Cuando pasados más de 20 minutos allí no ha aparecido arroz alguno, se lo reclamas al camarero. Éste, disculpándose amablemente, te explica que ha habido algunos problemas pero que ya casi está. Empiezas a enfadarte: estaba claro que no podían preparar el arroz en 10 minutos y, una de dos, o te están engañando o no tienen ni idea de hacer arroz, pero bueno, prefieres no pensar mucho en ello y disfrutar de tu arroz cuando llegue.

Y por fin llega el arroz. Con pollo.

- Esto es pollo. ¿Y el arroz con bogavante que había pedido? – preguntas al camarero.

- Vaya, lo siento. Tiene que haber sido un error. Le preparamos un bogavante y se lo añadimos a este arroz, así no tiene que esperar otra vez y podemos aprovechar parte del trabajo que hemos hecho ya.

Respiras profundamente mientras vas asumiendo que vas a comer arroz con pollo y bogavante. No suena muy bien, pero tienes suficiente hambre como para aceptarlo.

Cuando llega el bogavante, te mira con ojos desafiantes mientras avanza hacia ti chasqueando sus pinzas.

- ¡Está vivo! ¿Me ha traído un bogavante vivo?

- Verá, señor, vamos justos de tiempo, teníamos que haber terminado con su mesa hace un rato, pero su proyecto, digo, su comida, está resultando más complicada de lo que esperábamos y…

- Quiero mi bogavante. Y, por supuesto, lo quiero cocinado.

- Sí, señor, no se preocupe que esto lo solucionamos enseguida. Pondremos a nuestros cocineros certificados en bogavantes a trabajar en ello para asegurarnos de que reconducimos su proyecto, digo, comida.

Ahora sí, el bogavante tiene un aspecto mucho más apropiado y, por fin, puedes empezar a comer tu arroz (ya frío) con pollo (bastante reseco) y bogavante… ¿dulce? ¿Han cocido el bogavante en agua con azúcar? ¿A qué clase de experto certificado en bogavantes se le ocurriría hacer eso?

- Perdone, pero este bogavante está cocinado con azúcar. ¿Es que sus expertos no comprueban lo que están haciendo? ¿Por qué siempre me traen cosas sin sentido?

- Verá, nosotros creemos en trabajar estrechamente con el cliente durante la fase de testing y control de calidad para asegurar que la comida ofrece el valor añadido esperado. Además, habíamos reservado unas determinadas horas para atenderle y esto se está alargando más de lo previsto, por lo que comprenderá que tenemos que facturarle…

La realidad del desarrollo de software

Por desgracia, así funciona la mayoría del desarrollo de software, al menos en España.

Casi siempre que nos juntamos unos cuantos desarrolladores y nos quejamos de nuestro trabajo acabamos hablando de comerciales que sólo se preocupan por vender, de clientes que no saben lo que quieren (y tampoco están dispuestos a pagar un precio justo por ello) y de usuarios empeñados en “romper” nuestros preciosos sistemas.

Pero sobre todas esas cosas, si echo la vista atrás, lo que más frustración me ha producido ha sido la relación con otras empresas de desarrollo o con los departamentos de desarrollo de otras empresas.

Pocas veces he sufrido tanto como cuando yo he sido el cliente de un desarrollo.

Y eso que, se supone, algo sé del tema y debería estar preparado. O a lo mejor es justo por eso, porque sé algo del tema y sé que hay otras formas de hacer las cosas. En cualquier caso, cuando pienso en lo que debe de sentir alguien que contrata un desarrollo de software a la típica empresa del sector, me da lástima.

La mayoría del software que te entregan tiene una calidad ínfima.

Comprendo que definir correctamente la funcionalidad de un sistema no es una tarea fácil, requiere una buena comunicación y estoy dispuesto a asumir mi culpa como cliente por no haberla expresado bien o incluso por no haber sabido lo que realmente necesitaba, pero hay cosas que claman al cielo.

Aplicaciones que nadie se ha molestado en probar. No digo ya probar a fondo y cubrir cada caso extraño que pueda producirse, sino simplemente ver que se ejecuta y hace algo mínimamente lógico. No puede ser que se entregue una aplicación que a duras penas funciona en el caso más simple, y que, por supuesto, en cuanto fuerzas un poco, explota por mil sitios diferentes.

Los fallos de regresión están a la orden del día, y conseguir estabilizar un sistema se convierte en una auténtica labor de malabaristas; por cada cosa que se arregla se rompe otra.

Interfaces de usuario diseñados a patadas. No todos contamos con un excelente equipo de diseñadores para hacer interfaces de usuario atractivos y originales, pero qué menos que molestarse en mantener los controles alineados, revisar errores tipógraficos, ser consistente en los patrones de interacción. No hace falta ser un experto diseñador, con aplicar un poco de sentido común y poner algo de interés basta.

Usabilidad inexistente. ¿Que hay que obligar al usuario a dar 40 pasos para hacer una tarea que tiene que repetir 30 veces al día? ¿Que los mensajes de error son incomprensibles? ¿Que dejamos que el usuario destruya toda su información por no validar lo que introduce en el sistemma? Da igual, es su problema. Que aprenda a hacer las cosas bien y ser eficiente.

Gestión del ciclo de vida del producto nula. Lo he dicho antes: desarrollar es sólo el principio y entregar una aplicación es sólo un primer paso. Estoy cansado de que nadie haya previsto un plan para actualizarla, que no haya forma de diagnosticar errores en producción o que, ni siquiera, sea posible saber qué versión se está ejecutando en producción.

Y ojo, que en ningún momento estoy hablando de la calidad del código o la metodología empleada. Como cliente, me da igual la calidad del código, me importa el resultado que obtengo.

Me gustaría decir que estos problemas sólo se dan en determinados tipos de empresas, pero me los he encontrado trabajando con empresas grandes y con empresas pequeñas. Con empresas que tenían un organigrama tradicional, con una separación muy clara de roles entre comerciales, analistas, programadores, etc., y con empresas mucho más planas. Con empresas waterfall y con empresas agile. Con empresas desconocidas y con empresas “Business Golden Partner of the Century” del fabricante de turno. Con empresas caras y con empresas baratas.

Mi experiencia es que, desde el punto de vista del cliente, el panorama a la hora de contratar un desarrollo de software es desolador. No creo que se trate de un problema técnico. Tampoco de un problema comercial o de negocio. Es una cuestión cultural.

Y, sin embargo, funciona

Lo sorprendente de todo esto es que, al final, el mundo funciona. Y funciona a base de software. ¿Cómo?

Ha llegado un punto en que se asume que contratar un desarrollo de software será algo que requiera un esfuerzo enorme por parte del propio cliente para obtener un resultado final dudosamente aceptable. Como decía antes, es una cuestión cultural: hemos asumido que esto es lo que hay. Los clientes no son conscientes de que hay otra forma de desarrollar software.

Así, todos esos problemas que mencionaba antes y que a mi me parecen tan graves, no los son tanto para otros clientes. Están dispuestos a asumir que tendrán que perder mucho tiempo en conseguir que el proyecto arranque. Que, es cierto, nunca funcionará como las aplicaciones “de verdad”, porque, claro, es una aplicación “que nos hicieron a nosotros, y tiene sus cosillas“.

No sé en qué punto decidimos los clientes y usuarios que no importaba que el software fallase, pero es algo que tenemos bastante interiorizado. En otros productos esperamos que el funcionamiento sea siempre perfecto y predecible. En el software aceptamos que a veces “pasan cosas”.

Esa idea de que es normal que el software falle la hemos llevado a la contratación de un proyecto. Si contratases a un pintor para que te pintara la casa, no permitirías que te dejara las paredes mal acabadas, con manchas y ronchones. Tampoco verías normal que la pared que habías pedido azul acabase de color rojo. He visto muchos clientes de desarrollos de software que, cansados de luchar para que la pared fuese azul, acaban quedándose con la pared roja. O verde. O lo que sea, con tal cerrar de una vez el proyecto y acabar con esa pesadilla.

Esta gestión de expectativas entre empresas de desarrollo y clientes es lo que permite que el sistema siga funcionando. Sí, te he entregado un producto deficiente, pero es lo que hay. Todas las empresas somos iguales y esto funciona así. A veces me recuerda al mundo de las operadoras de telefonía. Todas te tratan mal, pero saben que pueden hacerlo porque son todas iguales y, vayas donde vayas, acabarás en la misma situación.

¿Todas? No. No todas las empresas son iguales.

Hay empresas que intentan cambiar esto. Que intentan actuar con profesionalidad y responsabilidad. Por desgracia, estas empresas tienen que luchar con la inercia de un mercado en el que cuesta mucho vender calidad porque, simplemente, el cliente no cree que eso exista.

Por eso me frustra especialmente esta situación.

Porque, además de afectarme como cliente, me afecta como desarrollador. Llega un punto en que lo podría convertirse en una ventaja competitiva (intentar hacer bien las cosas), queda anulado por el escepticismo de un cliente demasiado acostumbrado a que eso no existe.

No sé cuál es la forma de cambiar esto. A mi me resultaría más agradable vivir en un mundo en el que la gente se responsabilizase de su trabajo y actuase con profesionalidad, pero hay que ser realista y asumir que los incentivos económicos son los que mandan.

Mientras los clientes estén dispuestos a convivir con este tipo de desarrollos, estas empresas seguirán existiendo. Aun así, no pierdo la esperanza de que, algún día, si hay suficiente gente actuando con un poco de sentido común, alguien se dará cuenta de que se puede trabajar de otra manera, mucho más productiva y satisfactoria.

Hasta entonces, siempre podré seguir escribiendo rants absurdos como éste. No solucionan nada, pero al menos ayudan a desahogarse.


6 comentarios en “Lo peor de desarrollar software

  1. “Verá, nosotros creemos en trabajar estrechamente con el cliente…”

    Ja, ja, … me has matado, sí, de vender la moto saben bastante.

    Pero:

    ¿”Aplicaciones que nadie se ha molestado en probar”?, ¿”fallos de regresión”?, ¿”Interfaces de usuario diseñados a patadas”?, ¿”Usabilidad inexistente”?, ¿”Gestión del ciclo de vida del producto nula”?

    Esa lista son síntomas, como el sabor dulzón de tu bogavante (por cierto, puedes aprovecharlo para una ensalada), el problema es la incompetencia (de quienes sea en cada caso dentro de la cadena de responsabilidades) y la hijoputez, características ambas que se aplican igualmente en otros sectores (en que también pasa todo lo que comentas).

    No concuerdo para nada con la referencia a la España cañí, para nada, en mi sector al menos, no veo menos chapuzas en megaempresas (USA, Alemania, Holanda, … por decir las que se supone son “éxquisitas”) que en otras mucho más pequeñas españolas (que también). Mi relación con ellas son siempre conectar extremos, por lo que el único problema debería ser definir el mejor acople entre modelos de negocio pero no, te encuentras con cosas surrealistas como por ejemplo, una de éstas mega, te entrega incorrectamente codificado X mensaje ¡aleatoriamente! (hipótesis, balacean entre servicios que no funcionan igual) así, cuando repites la operación de lectura, puedes recibir “Wolfgang Schäuble” o “Wolfgang SchAnuble”; respuesta “Sí, lo sabemos, pero de momento no lo vamos a arreglar” u otras que en lugar de empaquetar en una petición con 1k cambios te envían 1k peticiones de 1 cambio :/ (migración de costes: obviamente porque a ellos les resulta más cómodo, allá tu te apañes…); otras en que tienes que replicar ¡sus operativa de negocio! para calcular información que obviamente deberían darte (imagínate un total que depende de datos y eglas internas de ellos); hay muchas…

    En cuanto a “Por eso me frustra”, “No sé cuál es la forma de cambiar esto”, … pasa, haz como que no te importa mucho y vivirás mucho mejor, realiza tu trabajo lo mejor que puedas (te dejen), piensa en la mejor estrategia dentro de tu radio de acción, olvídate sobre lo que no puedas actuar y por supuesto, desahógate cuando lo necesites xD xD xD

  2. Estoy de acuerdo, lo que menciono son síntomas. Trato de ponerme en el lugar del cliente, que realmente sólo ve eso, sin ser capaz de entender el origen.

    En cuanto a ceñirlo a España, es el mercado que conozco, pero supongo que no será una excepción y probablemente pase en todas partes.

    Por cierto, tengo por norma no comer cosas con exoesqueleto, así que no he probado un bogavante en mi vida, pero gracias por el consejo culinario ;)

  3. Jose Alonso dijo:

    “…no pierdo la esperanza de que, algún día, si hay suficiente gente actuando con un poco de sentido común, alguien se dará cuenta de que se puede trabajar de otra manera, mucho más productiva y satisfactoria..”

    El Principio de Peter está en tu contra: “Todo profesional asciende hasta alcanzar su máximo grado de incompetencia”.

    Yo nunca he sido cliente de un desarrollo software (trabajo para una de esas “Business Golden Partner of the Century”, aunque también he trabajado en empresas pequeñas) pero siempre intento ponerme en el pellejo del cliente y, la conclusión a la que llego en la mayoría de los casos es siempre la misma: son unos angelitos. No sé como aguantan y se comen las aberraciones de desarrollos que se les hacen (quizás por lo que comentas, porque “saben”.

    Yo en este aspecto veo una analogía con la política. Si estás preparado y tienes buenas intenciones, entonces tienes muy pocas posibilidades de llegar alto y poder cambiar las cosas. Además también considero que nuestro sector está corrupto. Empresas que te cobran precios desorbitados por entregarte software con retraso (siempre) y sin ninguna calidad.

    Lo que importa, como casi todo en esta vida, no es la calidad, sino el marketing.

  4. Estoy de acuerdo con el escenario! Hay muchas formas de desarrollar Software y realmente es bastante normal que el mismo tenga fallas en su creación e implementación. Tener un equipo de I+D y testers es lo más adecuado para el desarrollo.

    Yo he probado Flexxus (www.flexxus.com.ar)
    y es excelente!!

    Saludos

    Emilio Acosta

  5. Hola a todos,

    Estoy de acuerdo con lo que comentas pero también hay un tema también muy importante y creo que es uno de los puntos clave en la relación cliente-empresa en el mundo de la informática.

    En la actualidad existen varios puntos a tener en cuenta:
    - El usuario no sabe lo que quiere, no explica lo que quiere y/o cambia constantemente los requisitos, con lo que es realmente muy complejo saber las tareas que entran en el sistema. Esto es como ir a una ciudad y pedir una paella valenciana, posiblemente cuando me la sirva le diga esto es arroz con cosas, no una paella valenciana.
    - Es muy complejo estimar en coste y tiempo una tarea, con lo que los desarrolladores suelen aplicar un porcentaje para cubrir posibles derivaciones. Hay lugares donde cierto tipo de arroces no tienen precio fijo porque depende del día por ejemplo el bogabante fresco va a un precio y por tanto no se puede poner un precio al arroz del bogabante de antemano.
    - El cliente intenta apretar al máximo el coste y tiempo de la aplicación con lo que junto a los puntos anteriores suele ser muy complejo ajustar el coste/tiempo al real de la aplicación. El cliente tiene prisa y quiere la paella en 10 minutos aunque sabe que la cocción del arroz son 20 min más el sofrito, …
    - Los usuarios no quieren o no entienden que la programación no solo es programar, sino que que hay reuniones, elaboración del presupuesto, elaborar la documentación para que lo que entra en el sistema sea lo que el usuario quiere, … El cliente quiere pagar por los 40 minutos de hacer la paella, pero falta limpiar la paella, comprar, la seguridad social, …
    - Los usuarios no quiere asumir el coste de formación para realizar su sistema. Entiendo que la formación para elaborar algo global que luego se puede reaprovechar debe correr en gran medida a cargo de la empresa que desarrolla, pero conocer como conectar con su CRM concreto y que nadie más usa, … es un coste que debe asumir sólo él. Al final el conocimiento o se paga por lo que se sabe (en muchas ocasiona hemos comentado el tema) o se paga a formación o tiempo para aprender algo.

    Aunque parte de estos puntos los he llevado al extremo… Todo esto hace que no se llegue a tiempo, los costes empiecen a hacer no rentable el sistema, que el cliente se mosquee, que el programador se cree que le toma el pelo… Esto se suma al tema de que mi primo me ha dicho que la aplicación me la hace en una semana y no me cobra dos gintonics.

    Esto se resume en que esta relación es muy compleja y aunque creo que gran parte, como comentas, es culpa de la empresa desarrolladora porque no es suficientemente profesional hay que ver todos los puntos de vista y también he sufrido clientes que me han llevado hasta la extenuación.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

*

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>