[Las cosas que no interesan]
domingo sep 30, 2007
La Brecha
Ha existido desde siempre una línea que nos
separa los ingenieros de nuestros usuarios, una línea construida sobre la
diferencia en lenguajes y en la forma de pensar; en el caso del desarrollo de
software, nos separa a quienes diseñamos y construimos las aplicaciones de
aquellos usuarios que las van a usar o que de una u otra forma se van a ver
beneficiados por ellas.
Que exista esta diferencia está bien, la
hay en todas las ciencias, artes, deportes, etc. El mundo funciona por que a
todos nos gustan cosas diferentes, hay quienes diseñan casas, hay quienes las
construyen, otros se especializaron en hacer cemento y los otros en
transportarlo, esto no es un problema en sí, es una condición. Sin embargo para
que este mismo mundo funcione, debe haber comunicación entre las diferentes
especializaciones: quien diseña la casa le debe explicar al que la va a
construir para que éste pueda hablar con los que hacen el cemento y hacer el
pedido exacto, pero eso no implica que quien hace el cemento, deba ser un
experto en el diseño y/o construcción de casas.
Lo que me inquieta y me trae a este punto
es que en los ingenieros que tenemos que ver con la informática hemos hecho
todo lo posible por aumentar la brecha. Hemos vivido desde hace años con la
ilusión de ser y hacer como hackers, de usar un lenguaje ininteligible para los
“demás idiotas”; soñamos con cuartos oscuros, llenos de módems, computadores
portátiles y un montón de geeks hablando de los temas que “realmente importan”
(stuff that matters) y absolutamente aislados de ese mundo donde está el
monstruo a vencer, ese monstruo que nos hace la vida más difícil con sus
preguntas tontas, con su manejo torpe del teclado, con su odiosa indiferencia
cuando le hablamos de Linux, ese monstruo que llamamos “usuario final”.
Los ingenieros (al menos los informáticos)
somos unos pedantes, somos capaces de presumir con un pregrado y 10 años de
experiencia aún sin conocer un pito sobre UML y programación orientada a
objetos, nos encanta sentirnos diferentes con nuestro idioma lleno de
tecnicismos, nos encanta hablar rápido para hacer que las cosas parezcan más
complejas de lo que son, nos encanta el estrés para demostrar cuan importante
es lo que hacemos, nos encanta odiar a nuestros gerentes por que no saben nada
de programación. Nos encanta despreciar a nuestros usuarios por que no saben lo
que se puede hacer con la tecnología, usamos sobrenombres tan divertidos como
“el idiota aquel” para referirnos a ellos, creamos caricaturas y usamos nuestro
gran ícono universal para representarlos: el pobre tipo o tipa dándole golpes a
un teclado a ver si su aplicación funciona. Y lo peor de todo es que nos
sentimos orgullosos de ser así, nos mantenemos aislados de lo no técnico, de lo
administrativo, del negocio que estamos modelando.
Una de las características de los que
desarrollamos software, es mirar con desprecio hacia las estimaciones. Cuando
vemos los tiempos asignados para desarrollar un módulo se dibuja una sonrisa
maléfica en nuestra boca para recordarle al gerente lo poco que sabe de
desarrollo y cuando nos preguntan el tiempo que nosotros estimamos, siempre
explicamos lo difícil sino lo imposible que es estimar, es eso, nos encanta
retratar nuestro complejo mundo.
Pero no, el usuario no es tan torpe, el
gerente no es tan inepto y nuestro mundo no es tan complejo. Es cierto, somos
una ciencia nueva, con mucha incertidumbre, con muchas cosas por descubrir e
inventar. Estamos en una situación que nos exige humildad, nos exige mirar con
cara de niño curioso hacia otras ciencias, nos exige respetar al usuario que es
quien más sabe sobre lo que hacemos, por que es él quien lo usa. Debemos
acercarnos a él, preguntarle como se siente lo que hicimos, que hay de bueno,
que hay de malo; por que el mundo no se divide entre lo que funciona y lo que
no. Hay demasiados factores subjetivos que son clave en el éxito de una
aplicación, al usuario no solo debería importarle si funciona o no, el usuario
es humano y como tal hay cosas que le gustan por que sí o por que no
Sabemos que no se puede garantizar que una
nueva aplicación sea 100% libre de errores, los bugs son el pan de cada día y
de hecho la ingeniería de software existe para darle mantenimiento a las
aplicaciones con errores. Cuando no podemos dar esta garantía, deberíamos por
lo menos procurar una experiencia agradable en el uso de nuestros productos,
por que no es justo que aparte de soportar una aplicación con errores, el
usuario deba usarla y sentirla como el ingeniero lo ordena, no es justo que se
sienta idiota por que las operaciones son como las pensó el ingeniero y no como
él cree que deberían ser. Claro, eso tampoco debe llevarnos a implementar
cuanta cosa se le ocurra a la gente, pero si debería llevarnos a un
acercamiento que facilite el trabajo en equipo, dejar de ver a nuestros usuario
únicamente como el receptor de lo que hacemos, debemos convertirlo en una ficha
clave en lo que hacemos. Debemos hacer que aprenda UML (que para eso se
diseñó), que comprenda como se hace una aplicación, debemos escucharlo, quizá
la diferencia entre un botón azul o amarillo sea la clave para la aceptación de
una nueva aplicación, en fin, debemos darle al usuario la importancia que se
merece, seguramente haciéndolo vamos a encontrar muchas de las respuestas que
necesitamos para que los proyectos de desarrollo de software fracasen menos,
para tener más claridad en el camino a seguir. Al fin y al cabo, ¿Qué es lo que
hace que MAC OS sea tan exitoso?, ¿Por qué sus usuarios lo sienten como una
religión?, ¿Por qué aunque Linux sea ahora tan fácil como Windows, los usuarios
prefieren este último aunque tengan que pagar mucho más?
Posted at 11:37PM sep 30, 2007 by Carlos Alexander Zuluaga in General | Comentarios[12]
Subscribe!
"Los ingenieros (al menos los informáticos) somos..."
Habla por ti o por los que conozcas :). Tambien estamos los que no somos caricaturas.
Dicha separación existe igual en muchas otras profesiones, con los mismo sintomas y resultados. No es una disculpa, pero mas bien parece indicar algo común en el caracter, en vez de algo exclusivo de los "ingenieros".
El primero paso para afrontar un problema es reconocer que existe, asi que algo es algo :P.
S!
Enviado por GreenEyed en octubre 01, 2007 a las 01:13 AM COT #
Claro, hablo por mí y por algunos de los que conozco, no son todos, pero tampoco somos pocos, las cosas siempre se cuentan basadas en lo que uno ha vivido y es imposible hacerlo de otra forma :-).
Claro, la brecha existe en todas las profesiones, la diferencia que veo en esto es que los ingenieros siempre hacemos cosas para ampliarla, contrario a lo que sucede en otras profesiones mucho más maduras. Cuando vas al médico el siempre trata de explicarte con sencillez lo que padeces, cuando vas a construir una casa te sientas con el arquitecto a revisar los planos; me refiero a eso.
Saludos.
Enviado por azuluaga en octubre 01, 2007 a las 10:23 AM COT #
Perdonad que me meta, eso pasa en todas las disciplinas cuando uno sale de estudiar:
- Primero piensas que lo sabes todo y que con lo que te han explicado puedes comerte el mundo.
-Luego, te vas dando cuenta de que hay gente que hace lo mismo que tu, que no tiene tus estudios, y que además, sabe muchísimo más de todos los temas que conoces.
-Y al final, con el tiempo, si eres una persona normal, te das cuenta de que no hay lumbreras, ni sabelotodo. Hay gente que tiene más experiencia en determinadas cosas y que algunos días tiene la mente más despierta que otros.
Por último, no es cuestión de brechas. Cualquiera puede entender lo que hace un informático si es un poco listo. Nosotros, a veces, realizamos proyectos muy complejos, con una funcionalidad enrevesada, orientada específicamente a técnicos, y mi jefe, que es bastante espabildado, con una explicación lo suele entender todo, y no es ingeniero informático.
Por cierto, yo ya me he comido unos 10 ingenieros de los que tu comentas.
Enviado por jorgeyrosi en octubre 01, 2007 a las 11:21 AM COT #
--- Cuando vas al médico el siempre trata de explicarte con sencillez lo que padeces, cuando vas a construir una casa te sientas con el arquitecto a revisar los planos; me refiero a eso. ---
No se a que médico irás, pero te aseguro que no siempre es así, y mi padre es médico y por eso conozco bastantes. Ocurre lo mismo de que te dicen que lo que tienes es una xxxclastia blabla y está el comprensivo que te explica que no es más que una afección común que pasa sola, y el que te deja así con el miedo en el cuerpo de si lo que tienes es gordo o no, pero para que explicartelo "si no lo vas a entender".
Y lo mismo con los fontaneros que te miran con sorna cuando pones cara de tonto si te dicen que lo que hace falta es ponerle el aparato X para la presion, o el mecanico... como si todo el mundo naciera aprendido.
Para mi, va dentro del caracter y la empatia de cada uno el saber o no ponerse en el lugar del otro, que no sabe ni tiene por que saber lo que nosotros hemos estudiado. Y no creo que sea exclusivo de ninguna profesión, o al menos yo lo he visto en muchas.
Saludos
PD: De todas formas reitero que es bueno reflexionar sobre un problema que, en nuestro caso, puede afectar bastante al producto final.
Enviado por GreenEyed en octubre 02, 2007 a las 06:11 AM COT #
Perdon que me olvidaba, en lo que no estoy de acuerdo es en lo de que cualquiera puede entender lo que hacemos los informáticos si es un poco listo.
Es como si yo digo que "entiendo" lo que hace un mecanico cuando me dice que va a "hacerle una puesta a punto al coche" o un medico cuando dice que va a "extirpar tal cosa". Una cosa es que en lineas generales sepas de que te hablan y te hagas una idea, y otra muy distinta entender todo lo que conlleva, lo que cuesta y tener todos los conocimientos que hacen falta para poder resumir una tarea compleja en una frase simple.
Y esa erronea idea de que en realidad se entiende lo que hacemos es una de las fuentes de problemas a la hora de evaluar costes, plazos; y de valorar algunas de las tareas que se hacen.
Pero lo de siempre, cada cual tendrá su opinion :).
Enviado por GreenEyed en octubre 02, 2007 a las 06:18 AM COT #
Ok, retiro el ejemplo del médico, como dices eso es bastante subjetivo y depende del que uno visite. Aunque el que tu padre sea médico hace que seas mucho menos objetivo para hablar de ello.
A lo que voy se acerca más al del arquitecto, aunque inicialmente uno no entiende los planos de su casa, con un esfuerzo y unas pocas explicaciones empezamos a hablar el mismo idioma, no digo que se tengan los mismos conocimientos, pero si entendemos de que se trata. No hay que conocer todo el proceso en detalle, solo entender los planos.
Y el punto es ese, que entre los ingenieros de software hay un concepto tan despectivo del usuario final que ni siquiera nos deja intentar explicarle de que se tratan todos nuestros "dibujos", nuestra forma de modelar el sistema.
Y entiendo GreenEyed que no estés de acuerdo con lo que digo, entiendo también que estés molesto, cuando escribí esta entrada no esperaba aplausos y comentarios reforzando mis ideas, yo se lo incómodo que es ser cuestionado en lo que se hace, pero eso es una muestra más de nuestra pedancia.
Y no, reflexionar o mencionar el problema no es suficiente, tampoco es que sea el primer paso para solucionarlo, solo mira, la negación es lo primero que ha surgido en todo esto. Si queremos llegar a algún punto tenemos que aprender a cuestionarnos, pero de verdad, y argumentar por que sí o por que no. Claro que solo puedo hablar por lo que he visto, pero te aseguro que no es una idea mía, no es algo infundado, es una cosa delicada, crítica en nuestro negocio.
¿Alguien se ha detenido a mirar quienes son los que hacen productos más exitosos?, ¿quienes ha escrito los libro más influyentes en nuestro medio?. NO son ingenieros, son antropólogos, sociólogos, o gente que ni siquiera tiene formación universitaria; esto ya es una evidencia clara de que algo estamos haciendo mal, sí, puede que estemos empujando el mundo hacia un situación mejor, pero no de la mejor forma.
Un saludo.
Enviado por azuluaga en octubre 02, 2007 a las 10:48 AM COT #
¿Molesto yo? No, hombre :). Sólo que prefiero quitarle algo de "pesimismo y elitismo simulateno" a eso de que nososotros somos "especiales" en la consideración al cliente/usuario.
Y no, no lo estoy negando ni me considero un pedante por saber que intento hacerlo mejor que muchos de mis colegas con la misma formación.
Y sigo sin estar de acuerdo, aunque me cambies de medico a arquitecto. Una cosa es entender por encima lo que te explican y otra cosa es que realmente sepas que dentro de lo que te explican hay toda una ciencia de resistencias de materiales, legislacion y ordenacion urbana, seguridad, materiales con su relacion precio/calidad/duracion... Y entonces me parece igual de ingenuo pensar que por "saber de que habla" entonces podría hacer yo de arquitecto, como que un neofito crea que si entiende lo que es una "aplicacion que accede a una BDD", entonces ya sabe todo lo necesario.
Lo que pasa es que en nuestro caso la gente se lo cree, con ayuda de opiniones como esta, y se mete a ello, y salen las cosas como salen.
Y respecto a lo de que quienes han hecho los productos más exitosos, habria mucho que decir. En cuanto a libros... no creo yo que la ingeneria te prepare especialmente para escribir libros y no se que tiene que ver que tengan o no tengan formacion universtaria.
Una carrera es un intento de garantizar oficialmente que tienes unos conocimientos básicos, los cuales puedes haber obtenido de otro lado y no tener esa titulacion, pero no quita que sepas mas, menos o que seas mas listo. Si me dices que alguien que estudia antropologia acaba la carrera sabiendo mas de informatica que un ingeniero informático, pues algo falla.
Si me dices que un antropologo despues de 20 años trabajando sin titulo en informatica sabe mas de algunas cosas que un recien licenciado, pues me parece de lo mas normal.
Y por supuesto que lo mas normal es que el antropologo escriba mejores libros sobre, por ejemplo, trabajo en equipo, llevar un proyecto..., despues de 20 años de experiencia y con una preparacion para entender las relaciones humanas.
Yo simplemente creo que en estas discusiones la gente todavia tiende a irse a los extremos, supongo que a medida que la cosa vaya madurando ya iremos tendiendo menos a las visiones apocalipticas :)
S!
Enviado por GreenEyed en octubre 04, 2007 a las 01:36 AM COT #
Hola.
Nos hemos desviado un poco del tema, yo no he argumentado que cualquiera que conozca un poco sobre el tema puede desempeñar el papel de arquitecto u opinar en lo que no le concierne. El punto mío es que debemos enseñar a los usuarios que nos definen los requerimientos a leer diagramas, no todos, quizá un modelo de casos de uso, un modelo de dominio, por que no, un diagrama de despliegue y algo similar a uno de componentes. Esto no es para que tomen decisiones técnicas con nosotros, es para que nos ayuden en el diseño, para que opinen sobre lo que estamos haciendo, sobre como modelamos sus ideas, es llevarlos a ellos a estructurar bien su mundo antes de contárnoslos a nosotros.
Y está bien, no hay que ser apocalíptico, pero insisto en que el ser tan despectivos (ok, no todos) con el usuario, nos impide creer que el pueda ayudarnos en estas labores, no nos creemos que un usuario no sea capaz de leer un diagrama de secuencia.
Eso sí, estamos de acuerdo en que a veces sucede lo contrario, alguien llega, cree que lo entiende todo y luego hace un cronograma de 5 minutos por que "lo que hacemos es muy fácil", eso si que es peligroso.
En cuanto a lo de la gente más influyente tampoco digo que un antropólogo sepa más de materia técnica que un ingeniero de software, lo que digo es que nosotros conocemos muy poco de interrelaciones humanas, estamos muy encerrados en nuestro mundo técnico y aún no hemos comprendido la relevancia que tiene una mejor relación con el usuario o los afectados por el sistema (stakeholders). Por eso es que estamos viendo el nacimiento de un montón de estudios enfocados en alinear el software con el objeto del negocio al que estamos sirviendo, hay muchos ingenieros "geniales" para programar, hacer diseños espectaculares y aplicaciones con un rendimiento de ensueño, pero hay muy pocos que conozcan sobre la parte humana de todo esto.
Espero hacerme entender mejor :-).
Un saludo y gracias por el comentario.
Enviado por azuluaga en octubre 04, 2007 a las 08:43 AM COT #
Totalmente de acuerdo excepto en la primera parte, lo de "educar al usuario" pero ahí no por pensar que esté bien o mal, ya que creo ahí es algo personal.
No creo que debamos pedirle al usuario que entienda lo que hacemos, como lo hacemos, nos organizamos, nuestra jerga, diagramas etc. Personalmente creo que una parte de nuestro trabajo, que es en la que muchas veces fallamos, es en entender al usuario en su terreno, sin obligarle a entender lo que hacemos pero dandole lo que quiere/necesita.
Cuando mejor me he entendido con los clientes/usuarios ha sido cuando los dos teniamos claro quien sabia de que y poniendo de nuestra parte nos entendiamos. Yo no le enseño un diagrama de secuencia, le hago un prototipo que el pueda ver y tocar y me muestre/diga si la "secuencia" de eventos es la correcta. No le enseño el caso de uso version UML, se lo explico de forma que lo entienda. Y a veces hay que lidiar con las inexactitudes del lenguaje, pero asi es la vida.
Y aunque si es cierto que iria todo mejor si el lenguaje comun fuera tecnico y preciso como lo que usamos nosotros, pues no lo es. Y en mi caso las veces que he visto intentar hacer eso, los resultados han sido peores ya que como realmente no entienden lo que hay, pues te dicen que "si, todo bien" sin saber o te miran con cara de "que me preguntas a mi?" :).
Y no lo evito por que piense despectivamente que ellos no son "capaces", es que creo que no es su parte del trabajo.
De la misma forma que un arquitecto te puede enseñar los planos pero tu no ves todo lo que hay, y en muchos casos apenas entiendes una parte. Pero te enseñan la maqueta de como quedará y sobre eso seguro que tienes opinion :). Y no es por que seas mas tonto, es que tu trabajo no es saber si una cruz es una viga maestra, si la linea esa significa tuberia, cable o es de adorno etc.
Pero vamos, si encuentras usuarios que esten dispuestos y te funciona, adelante. A mi me funciona mejor de la otra forma, aunque lleve más trabajo.
S!
PD: De todas formas, conste que me parece peor la postura opuesta de "el usuario es tonto y yo se lo que necesita", hacer el software encerrado en una torre de marfil y luego lanzarselo a la cara y alla te las compongas. Parece mentira pero a estas alturas todavia hay gente que trabaja así, auch.
Enviado por GreenEyed en octubre 04, 2007 a las 03:19 PM COT #
Ok, ahora sí estamos de acuerdo!.
De nada sirve intentar compartir un diagrama o una especificación con el usuario sino la va a entender, es cierto, hay un trabajo que es de nosotros y no hay ningún motivo para que él tenga que ponerse en esos líos.
Pero debe haber un punto medio, así como no tenemos que entender todo el diagrama del arquitecto, el usuario no tiene que entender todo o todos los diagramas, solo lo más importante: una relación de uno a muchos o la composición interna de una aplicación, por ejemplo el diagrama de paquetes y el de dominio.
No tienen que ser esos, es cualquier cosa que represente de forma precisa y sencilla su negocio, solo tiene que aprender una notación si es que no la conoce. Insisto, no tiene que aprender a hacerlo, eso es trabajo nuestro, solo tiene que entenderlo y nosotros entender al usuario para plasmar sus ideas correctamente en el diagrama.
Pero bueno, lo importante es que ya estamos de acuerdo. Ahora el punto es: ¿Cuál es la forma más adecuada para comunicarnos con el usuario? ¿De las cosas que hacemos cuáles puede entender él? ¿Hay que crear un lenguaje común?
Un saludo.
Enviado por azuluaga en octubre 04, 2007 a las 04:55 PM COT #
Uffs, he ahi la pregunta del millon :). Yo creo que cualquier cosa que suponga que el usuario, que puede ser cualquiera, deba aprender algo que no sabria normalmente, es mucho pedir. Así que nos toca a nosotros bajar hasta donde el sea capaz de entender. Y si lo que entienden es "lenguaje natural", "prototipos" etc. pues así sea.
Cuando vas al mecanico no te hacen hacer antes un cursillo de "aprenda jerga mecanica en 10 minutos", ni antes de hablar con un abogado te da un libro de "law for dummies", jejeje.
El problema es tambien que las carreras tecnicas no te preparan bien para eso (al menos cuando yo la hice y por todo lo que se sigue igual), así que ya depende mucho de la empatia de cada uno el saber comunicarse y entenderse con usuarios no tecnicos o no.
Tampoco seré yo el que diga que se como enseñar eso o que es fácil hacerlo.
S!
Enviado por GreenEyed en octubre 05, 2007 a las 01:21 AM COT #
Sí, es complicado pedir al usuario que aprenda ciertas cosas solo para que se pueda comunicar mejor con nosotros, y ese es mi punto GreenEyed. Cuando dices que es mucho pedir estás siendo pedante, el usuario no es tan bruto, solo hay que intentarlo, no se como, no se que diagramas son mejores, no se que tipos de usuario son los que hacen eso, pero así es todo: tenemos que probar.
Y ahora lo digo con mucha más fuerza, hoy, precisamente hoy, logramos eso, que el cliente adoptara como política una capacitación para los usuarios que van a definir junto con nosotros el sistema. Ahora ellos deberán aprender sobre lo nuestro, vamos a tratar de hacer que se comuniquen en nuestro idioma y todo sea por que la aplicación quede mejor implementada, que la experiencia de usuario sea mucho más satisfactoria.
Es obvio que no estamos exentos de un pequeño fracaso, digo pequeño por que si esto no funciona pues volvemos a la antigüita hasta encontrar algo mejor.
Pues bien, esto es una invitación a que tratemos de hacer algo que nos acerque al usuario, hay que probar, hay que buscar hasta encontrar algo que nos ayude, por que lo estamos haciendo realmente mal, quizás no tú GreeEyed, quizás no yo, pero lo cierto es que las estadísticas hablan de un porcentaje muy dramático de proyectos que fracasan.
Solo una cosa por pedir, aunque suponga un gran esfuerzo, ¿cuáles creemos que son los diagramas que podríamos pedirle al usuario que entendiera?, diagramas que sean sencillos pero significativos.
Para mí por ahora, son los casos de uso junto con su especificación y el modelo de dominio, aunque me da un poco de desconfianza el explicar la cardinalidad, quizá empezaré por explicar "uno a uno" y "uno a muchos", ojalá que esto me funcione.
Un saludo e insisto, gracias GreenEyed por mantener la discusión, sobre todo por los buenos términos.
Enviado por azuluaga en octubre 05, 2007 a las 01:37 AM COT #