Hoy estaba twiteando con Juan Macias, he respondido a un mensaje, donde pedía que en la carrera de Informática se impartiesen clases de diseño. Yo le he replicado indicándole que no está el problema en el Plan de Estudios de Ingeniería Informática, sino en la falta de separación de papeles, entre diseñador, analista y programador. En la réplica Juan me indica que tiene un caso donde el programador no le ha hecho caso al trabajo previo del diseñador.
Y eso es diferente. Aquí lo que deberían explicar bien a los futuros programadores, es que ellos deben hacer que el software se comporte conforme a lo solicitado en el análisis y con el aspecto final que indique el diseñador si lo hay o el encargado de usabilidad de la aplicación. Pero el problema que tenemos en nuestras empresas patrias, es que el que pica el código al final es el que manda. Como no hay forma humana (ni divina, aquí me gustaría a mi ver a Hércules) de que un proyecto se termine a tiempo, pues lo primero de lo que todos se olvidan es del diseño. Lo segundo la usabilidad (a al revés que da lo mismo) luego el orden de los campos, el tamaño de los mismos, su colocación en pantalla, la gestión de teclas rápidas… y así podría seguir.
Al final se obtiene una aplicación que malamente hace lo que debería hacer. Pero eso si, el usuario tarde el doble en realizar su tarea. Y eso en aplicaciones que son de uso interno, pues todavía tiene un pase (por más que los grandes jefes no entiendan que 5 minutos de ahorro al día en 1.000 empleados… es mucho tiempo). Pero hoy en día, cuando muchas aplicaciones van a ser usadas por clientes finales… pues es un suicidio.
Y los programadores se aprovechan además de la estupenda política de subcontratación y externalización en cadena que se ha impuesto. Antes, cuando aparecía una cagada en la web de la empresa, uno sabía a quien llamar para resolverlo. Ahora, vuelve a ser otra misión imposible. Eso se subcontrató a Diseños y desarrollos integrales, pero estos a su vez la parte de Internet lo encargaron a Webs Veloces, pero como iban mal de tiempo, traspasaron a la división argentina: PampaNet, y parece que allí alguien contrató a un peruano con contactos en China que es el que escribió finalmente el código (no sabemos si el peruano o un primo chino suyo).
Y por supuesto, las pruebas también están subcontratados, por lo tanto que más les da a los probadores el diseño y la usabilidad.
Así que al final, lo mejor como siempre es tener cerca al que toca el código, y a la vez que todo el mundo sea consciente de la importancia del diseño y la usabilidad.
Se me olvidaba, luego esos que subcontratan y subcontratan, por supuesto que te sacan su megateléfono y te dicen que mires la interfaz tan limpia y tan usable de la última App que se han instalado.
Anterior y Posterior
8 Comentarios
Comentarios Cerrados
Es que además lo habitual es que el programador sea también el diseñador (eso de contratar mucha gente no gusta en las empresas españolas, el trabajo de dos personas ya lo hará una sola y por el sueldo mas ínfimo posible), por no hablar de que la fase de análisis y diseño suele ser casi inexistente y los plazos que se manejan en los proyectos apenas las tienen en cuenta lo que deberían. Así salen luego las cosas.
Lo malo es cuando si hay análisis… pero no se le hace ni caso. Te lo cuenta alguien que se pasó 15 años haciendo análisis, generando prototipos, estudiando la usabilidad… para nada
Supongo que cada caso es diferente, pero yo soy programador y me cansé de pedirles a los insgnes analistas (mis jefes, además) una y otrz vez que para las especificaciones del interfaz se contactara directamente con el usuario final.
Pues no, se hacían a la española. Es decir, como querían mis jefes y el jefe del usuario. Y en la explicación de las posibilidades y funcionamiento del programa jamas intervenía yo, como es lógico, eran mis jefes los responsables de enseñar cómo funcionaba el programa que “ellos habían desarrollado”. Resultado: La única, única persona que de verdad sabía manejar el programa era yo. Y el usuario final desconocía mas de la mitad de las posibilidades del mismo.
Y, como es lógico, para el mantenimiento, también se contactaba con mis jefes. Y como ellos no querían que nadie controlara excesivamente ninguna parcela, pues lo hacían ellos o otra persona… Trplicando los tiempos de resolución de problemas.
Tengo que darte la razón en que si hay un análisis se debería seguir, ya que esa persona se supone que sabe lo suficiente de diseño y programación para saber qué es y qué no es posible por cada parte.
Eso sí, en el mundo real, muchas veces los problemas vienen porque las cosas no se hacen en el orden que se debe: primero se programa, luego se intenta apañar el diseño y luego se hace el análisis para entregar algo al cliente. Esto ha ocurrido SIEMPRE en la primera empresa que estuve (Matchmind).
Otras veces ocurren porque entre el programador y el diseñador no hay comunicación, y ya si el analista está “missing” pues apaga y vámonos. Esto sigue pasando, y cada dos por tres lo veo en proyectos grandes.
Y luego el mayor problema es, simple y llanamente, que a la gente le importa una verdadera mierda la aplicación. Es decir, yo tengo compañeros cobrando poco más de 800€, ¿de verdad crees que no saben hacer las cosas bien? sí, perfectamente. El problema es que si estás pagando a todo el mundo cuatro duros no vas a motivar a nadie. Y más viendo que los jefes no tienen muchas veces ni puñetera idea o les importa menos que a ti. Lo que vas a tratar es de evitar marrones y solventarlos de la forma más rápida cuando te toque.
Este es el país que nos ha tocado vivir.
En fin.
Al final coincidimos, con programadores mal pagados y peor motivados y con una cadena de mando y totalmente descoordinados, pues sale lo que sale.
tambien esta el caso de que un programador se encuentre un “genio” del diseño, que presente unas propuestas inasumibles a nivel de programación (que se adapten al presupuesto, que se puedan crear en el tiempo predefinido, y que sean de acorde con la empresa, o con las posibilidades de programación actual).
Conozco muchos diseñadores que se dedican a presentar unas propuestas en papel que para el programador standard se las pasa canutas para intentar aproximarse a la visión psicodélica del diseñador (más próxima a una película de pixar que a la realidad)
Opino que es más necesario que un diseñador sepa de programación y lo que cuesta integrarla, que no un programador tenga que saber de diseño.
Ese tema lo he sufrido, pero más cuando yo era el programador. Es lo malo de estar en los dos lados… siempre venía el primo del cliente, con un diseño hecho directamente en Photoshop y te pedía que lo metieras en la aplicación a pelo….
En empresas más grandes, como era el caso cuando yo era analista, partíamos ya de un marco fijo de diseño y de unas pautas comunes. Recuerdo, que los problemas más graves solia tenerlos sobre todo en los “campos de ayuda”. Vamos que si el usuario tenía que teclear un código de una lista de 900 códigos… pues hacíamos un algoritmo para que según que estuviese haciendo esa lista de 900 códigos se redujese a 20 además mostrábamos en pantalla el nombre de la opción, no el código a pelo… y venga pelearnos. Claro, al programador le era más sencillo poner un capo de texto, que el usuario supiese que valor poner y luego al final de la transacción, como mucho, enviarle un error… y hablando de errores, eso de que nadie sepa que significa un error.. podria seguir, pero me va a salir un comentario largísimo.
[…] via Facebook https://changlonet.com/blog/2013/05/el-interfaz-es-mo-y-si-no-te-gusta-trata-de-encontrarme/ […]