lunes, 8 de febrero de 2010

132 - Suposiciones (II)


(para leer la tira sin lupa, pulsa en la imagen)



tira relacionada: 33 - suposiciones


Hace un tiempo, a un amigo, en el colegio, le denegaron un premio en un concurso de dibujo porque el trabajo que presentó lo había hecho "con ordenador" y, como todo el mundo sabe, "el ordenador hace casi todo el trabajo".

Hoy en día, ese chico es director de animación de una empresa española que tiene en su haber un largometraje con un premio Goya y que ha producido un cortometraje nominado a los Goya y a los Oscar. Pero claro, supongo que será porque "el ordenador hace casi todo el trabajo".

Casi na.

Esta anécdota viene a resumir lo que mucha gente piensa:

la tecnología es mágica

Atención: rollo ingeniero a partir de aquí:

Esta es una máxima en la que creen con los ojos cerrados muchas personas que quieren soluciones a sus problemas mágicamente; cuando hay una limitación de tiempo, de recursos y/o de conocimientos, la tecnología, mágicamente, puede suplir todo esto y más; haz "flexible" este proyecto; queremos que este software se pueda "adaptar" a multiples plataformas sin esfuerzo; queremos que este software sea fácilmente "ampliable" a nuestras necesidades futuras...

todo eso es precioso, pero...¿para qué necesitas esa flexibilidad? ¿has pensado en qué plataformas tienes como objetivo? ¿qué necesidades inmediatas tienes? ¿qué te planteas en el futuro? ¿puedes hacer una lista de tus necesidades, de lo que quieres que haga el sistema?

Pero pensar es costoso. Y hay gente a la que le debe doler mucho hacerlo.

La mayor parte de las veces, la gente te argumenta que "no hay tiempo para hacer toda esa engorrosa documentación". Argumentan que no pueden detallarte de manera perfecta todo a la primera. Ya puedes decirles que no es eso lo que se pretende, que lo que se busca es un documento inicial, que se revisa y refina, como el software, en sucesivas iteraciones. Es lo mismo. Ellos tienen en su cabeza lo que necesitan, a veces incluso ni siquiera eso; saben que otros tienen esas ideas y se limitan a exigirte que leas mentes. Es curioso como entienden que puede haber varias versiones de un programa pero no de un simple documento.

Otra excusa que se suele dar es que todo eso son "cosas técnicas"; de nada sirve que les digas que son documentos en lenguaje coloquial, en los que hay que decir qué se pretende del software / hardware; documentos en los que se describe como interactua el usuario con el sistema. En cuanto hay un chupachups con brazos al que llamas 'actor' y un recuadrito que se llama 'sistema', ya es algo técnico.

Otra cosa que suele ser el pan de cada día es recibir requisitos 'mínimos' o 'limitados'. El objetivo, loable él, es que des una estimación de tiempo mínima para las funcionalidades básicas de un software y luego soltarte la otra mitad de la funcionalidad. Esto, la primera vez suele producir tirones de pelos, gritos y probablemente, rehacer una arquitectura o desecharla por completo porque a alguien pensó que era mejor no decirte que el sistema debía ser multiusuario, por si te liabas. No entienden que, en realidad, cuanto más grande es un proyecto, más importantes son los cimientos. Y que sin saber lo que se te va a exigir, sin conocer si te van a pedir añadirle 30 plantas al edificio o simplemente que le pongas unas macetas, no puedes decidirlo todo. Y que la palabra 'flexibilidad' no es mágica.

Ya, cuando tienes experiencia, supones que te van a pedir mil cosas y haces una arquitectura tremebunda, con una flexibilidad de mil pares. Y sobrediseñas. Y acabas perdiendo tiempo.

Las señales que os pueden indicar que estáis ante un proyecto indefinido suelen ser:

- La documentación existente está en formato Powerpoint o en documentos sin organización ni estructura; el efecto "carta a los reyes magos".

- Ausencia de glosario de términos. duplicación de conceptos; dos cosas que se llaman igual y son distintas.

- Reuniones maratonianas de varias horas en las que se hacen 'brainstormings' y se definen los requisitos de manera informal, sin plasmarlos en un documento ni asignarlos a nadie específicamente. Se confía en que los que tengan que hacer las cosas sepan que tienen que hacerlas. Usualmente, estas reuniones se repiten en el tiempo, machacando los mismos temas, dado que nadie parece percibir avances; ni los ingenieros perciben necesidades, ni los comerciales / gestores perciben trabajo enfocado a sus necesidades.

Conclusión; lo que no se ha hecho para ahorrar tiempo, se hace durante sucesivas reuniones, sin plasmarlo en documentación, gastando recursos y energía que no sería necesaria de hacer las cosas bien desde un principio; paradójicamente, a pesar de esto, hay gente que cree que hacerlo así es 'más eficiente', dado que 'parece' más trabajo. Es esa misma gente que cree que hacer varias cosas a la vez es más productivo que enfocarse en ellas una a una.

Y al final, lo único que puedes hacer es confeccionar la documentación tú mismo, desde arrancar la especificación de requisitos al 'cliente' hasta desarrollar los casos de uso, definir la arquitectura, hacer el análisis, el diseño, el desarrollo, el despliegue y el mantenimiento. Ser arquitecto, desarrollador, chico de sistemas y atención técnica. Porque no queda otra.



¿quieres leer más tiras? Entra en el listado de tiras y escoge!

Puedes usar esta tira libremente,
cumpliendo tan solo esta licencia CC:
Creative Commons License

52 comentarios:

  1. Anónimo dijo...
  2. Encima que os dejan ser creativos os quejáis. A poner ladrillos os ponía yo.

  3. Sr. Marrón dijo...
  4. Me ha encantado el tocho(r)* y el cómic. Mañana tengo examen de Proyectos de quinto, me siento identificado en forma futura.



    *Por Monroe, XDComics

  5. Elrohir dijo...
  6. :o

    Me has dejado casi sin palabras. snif Lloro de emoción.
    He visto cosas que no creerías. He visto dar una presentación levantando en alto los folios para que se vean. He visto interfaces especificadas en servilletas de cafetería...

  7. Pablo dijo...
  8. Este comentario ha sido eliminado por el autor.
  9. Pablo dijo...
  10. @elrohir: He visto proyectos donde se picaba código, luego se hacía el análisis técnico y por último el funcional. Y el cliente se sorprendía por la "poca desviación entre el documento técnico y lo implementado". Y mañana a primera hora veré una clase de 11 mil líneas de código, escritas por hindús en el 2000.

    Todo esto me recuerda a los exámenes de la universidad. Cuando te llegaba un compañero el día del examen, cagado de miedo porque la asignatura le parecía difícil, sabías que ese tío había estudiado.
    Cuando te encontrabas con uno que decía que se lo había estudiado y que no le parecía especialmente difícil, que lo tenía todo controlado, sabías que no tenía ni idea del tema.

    Pues lo mismo, chico: los que no tienen ni idea de lo que hay que hacer siempre piensan que todo es facilísimo: total, el Word mismo ya guarda en formato HTML, no?

  11. cousteau dijo...
  12. Y yo tengo pasado mañana un examen de Proyectos.

    ¿Por qué lleva Fred un casco de minero?

  13. fuseprods dijo...
  14. Yo me se de uno que a la espera de los textos que iban en una web, la rediseñó 4 o 5 veces por aburrimiento y, una vez recibidos los textos, casi le crean estrés... (menos mal que los tengo bien grandes y no me estresa ni una bomba a punto de explotar xD)

  15. Dedalo dijo...
  16. A cuento de lo de que "mucha gente piensa: la tecnología es mágica"...

    Obiamente, por la tercera ley de Clarke no hay otra conclusión posible (para los que no la conozcan: "Cualquier tecnología lo suficientemente avanzada es indistinguible de la magia"). Así que yo personalmente te recomiendo que les comentes que tienen que darte mas detalles sobre el aura del objetivo espiritual, para poder refinar las runas místicas que utilizarás en la confección del circulo de invocación para el conjuro arcano que te han pedido a ver si eso funciona mejor

  17. geodiendo dijo...
  18. Pues... no es por hundiros del todo en la miseria pero, desgraciadamente, en edificación ya hace un tiempo que se trabaja así, con cosas del tipo "tú, el ingeniero, ve haciendo algo hasta que me den la licencia de obra y luego ya veremos si hacemos sótanos o no, no me agobies ahora con detalles inútiles..."

  19. Nah dijo...
  20. @geodiendo: pasmado me dejas...

    si eso ya es malo en informática (por todo lo dicho anteriormente y mas) en edificación ya clama al cielo...

    Ender, magnifica tira como siempre ;)

    yo todavía recuerdo con "cariño" cuando me re-definieron un proyecto 18 horas antes de entregarlo...

    cuando digo re-definir me refiero a que cambiaron el 75% del mismo...

    yo me lleve un disgusto (estaba implicado pero no hasta las cejas), pero el jefe de desarrollo se llevo un infarto... casi no lo cuenta

  21. mercastan dijo...
  22. Lo de "algo parecido a Marina D'Or" ha hecho que me acuerde de una oferta de trabajo que he visto recientemente:

    "El candidato deberá tener conocimientos avanzados de programas de diseño web. Dreamweaver, flash... Deberá ser capaz de crear una página web de complejidad similar a la que podría tener youtube."

    http://www.tecnoempleo.com/oferta-empleo/desarrollo-web-creacion-mantenimiento/a5562a127rb68pb84fq9

    Me daban ganas de responder: "No, no tengo experiencia práctica en la realización de milagros".

    Aparte... "a la que podría tener youtube" ¡Eso sí que es precisión!

  23. Nah dijo...
  24. la oferta esa de tecnoempleo debe(ria) ser una coña...

    O_o

  25. Software Libre dijo...
  26. Vaya pues!!!
    Más real que la vida misma.

  27. Miguel Pena dijo...
  28. Justo hoy he visto en Variable not found ( http://www.variablenotfound.com/ ) una recopilacion de leyes aplicables al desarrollo del SW.
    ¿os habeis puesto de acuerdo?
    Genial la tira,lastima que la realidad supere a la ficcion

  29. Miripi dijo...
  30. Ooh! Me has recordado la asignatura Ingeniería del Software, que he de reconocer que por mucha manía que le tuviese ha sido una de las más útiles de mi carrera.
    Esos diagramas hechos con el Dia con funciones que van y que vienen... Ayyyyy, que 'gonito'!

  31. blip dijo...
  32. yupi, Fred disfrazado de Village People! ya sólo faltan el indio, el policía y el funcionario de la SGAE!

  33. Ender Wiggins dijo...
  34. Anonimo:mmmm...¿Jose?

    es curioso, dado que tú das "ingeniería de la enseñanza"...

    Miguel Pena: ¡thanks por la página, no la conocía!

    Dedalo: X-DDDDDDDDDDDDD

    fuseprods: ¡ahí, ahí, poniéndolos encima de la mesa! ¡la banca gana!

    Pablo: vaya, lo del word es una frase que he oído, literalmente, varias veces.

    mercastan: lo de "algo parecido a Marina D'or" es literal, solo que cambiando el "Marina D'or"...es parte de la magia. El daño que hizo el copy-paste al cerebro del directivo medio...

    Blip: venga, supongo que el indio podría ser Fray yuste, el policía podría ser Tonino (por Crom) y el funcionario de la SGAE... a ver... alguien que tenga experiencia con la SGAE...
    ...
    pues no se me ocurre nadie :-D

  35. Silvia dijo...
  36. Casualidad??

    Hace unos meses me veía en esa situación explicándoles el tema a unos amigos no informáticos precisamente con el mismo ejemplo.

    El proyecto por supuesto fue un desastre.

    Real como la vida misma...

  37. www.arquiam.es dijo...
  38. Hola, soy arquitecto y la realidad de la construcción era (ahora está todo bastante parado) un poco más complicada de lo que planteas en la tira. Fred debería ser el arquitecto y no constructor(ya que el arquitecto suele ser el ÚNICO titulado en todo el proceso), para empezar debería ir de negro Prada y en la conversación debería aparecer el promotor(quien pone la pasta y se lleva el pastón), el constructor(el que quiere hacerlo todo muy barato para ganar más y no como tu quieres para que quede bien), el del ayuntamiento y el del Colegio profesional(cobrandote tasas inverosímiles y obligándote a cumplir normativas, CTE, PGOU y Reales Decretos varios) y al lado una pequeña familia todos en paro e hipotecados.
    Aunque conversaciones disparatadas y barbaridades se dan muchas y de muy distintos tipos.

  39. Peludon dijo...
  40. Me has llegado a la patata y eso un Lunes a primera hora es digno de admiración.
    Yo estoy en esa misma situación con el agravante de que es un cliente publico... Que no me pase nada!! XD

  41. Ender Wiggins dijo...
  42. arquiam: thanks por el comentario, se agradece una visión pofesional :-)

    El objetivo de la tira es mostrar que muchas veces, en informática, el arquitecto es también el obrero y que realmente, aunque le dan poder para hacer el proyecto, solo le conceden poderes mágicos. Nada de poder real. Lo que comentas tú es "como sería si los informáticos tuvieran que trabajar como en la construcción", esto es al revés :-D

    Pero te veo con posibilidades de hacer una tira cómica que denuncie estas situaciones surrealistas en tu profesión. Y ya ves que no hace falta saber dibujar mucho :-DDDDD

  43. Mortanauta dijo...
  44. Uy uy uy... me está llegando el tufillo que a algún ingeniero dibujante le han dejado un proyecto enmarronado encima de la mesa....

    Lo que cuentas es normal porque el que te encarga el trabajo no suele tener pajolera idea, no solo de informática (que es lo de menos), sino del producto que necesita...
    Y esto es porque ha celebrado reuniones dentro de su empresa tan productivas como las que nos cuentas y simplemente estás delante del pringado o pringada al que le han cargado el marrón.

    Y mejor que no digas nada, porque sino te sueltan eso de que no solo te han contratado porque seas programador, sino como profesional, para que le des un enfoque...(palabra mágica); lo que traducido significa, que plagies lo que has programado para la competencia.

    Pero tranquilo, esto pasa a en todas las profesiones, sino preguntale a un carpintero al que le encargan un armario para que "entre todo"

  45. Mike Bonales dijo...
  46. Buenísima. Refleja sin dudas lo que vivimos día a día...

  47. Miguel Pena dijo...
  48. por lo que se lee en todas (o casi todas ) las profesiones cuecen habas.Ale una idea para una tira ¿si los informaticos tuvieran que trabajar como los politicos? (¿los politicos trabajan? )
    por cierto,me han reenviado la tira al correo un hamijo no informatico.

  49. Diego Moreno dijo...
  50. Como la vida misma ^_^

  51. beta2k dijo...
  52. muy buena la tira, como siempre XD

  53. siqui dijo...
  54. Esto se relaciona directamente con la primera frase mágica en fotografía: "Esto lo arreglas tú con el Photoshop"
    http://fotosiqui.wordpress.com/2009/06/16/esto-lo-arreglas-tu-con-el-photoshop/
    un saludo

  55. Mariu Sama dijo...
  56. Es que la ingeniería del software se inventó para rellenar créditos en la carrera, porque para lo que se usa... ._.U Luego con decir que un físico puede hacer el trabajo de un informático, y de hecho ponerle en el puesto de un informático, lo tienen todo arreglado... ¬¬U

    Es que a mi este tema también me hace hervir la sangre! >.<

  57. labrujilladelnoroeste dijo...
  58. y la cara que se te pone cuando te mandan información de un programa de un proyecto (programas para entorno bancario no nombrable)
    y que la documentación sean 5 lineas en las que te pongan:
    -abrir fichero
    -leer fichero
    -cojer fecha del sistema
    -escribir fichero
    -cerrar fichero

    Al final se referian a 2 ficheros de entrada y otro de salida (con estructuras de datos distintas cada uno)... un acceso a un programa entre medias y escribir en el fichero de salida el resultado... 650-750 lineas de código por lo bajo que NO crea el ordenador solas...

  59. Jose dijo...
  60. Creo que he soltado un par de lagrimitas... "so true"...

  61. Peibol dijo...
  62. Sabes que es el desarrollo ágil?

    En realidad es siempre así, el problema es cuando el arquitecto se pone a planificar un puente cuando en realidad al cliente le bastaba con una chabola.

  63. Ender Wiggins dijo...
  64. Peibol; no hay que confundir metodologías ágiles con ausencia de metodologías; los documentos de especificación y los casos de uso siguen siendo necesarios:

    "planificación, análisis de requerimientos, diseño, codificación, revisión y documentación"

    lo que tratan las metodologías ágiles es de agilizar procesos obsoletos como RUP. Pero no generan mágicamente los requisitos ni sirven para leer la mente de la gente :-)

  65. Anónimo dijo...
  66. En mi curro tenemos unos formularios para las peticiones de los usuarios muy sencillitos:

    Aplicación: _____
    Causa del problema/incidencia/mejora: _____
    Requerimientos: _____

    Y las firmas del usuario, del director del área y del director de informática.

    Hubo una cambio de normativa que afectó a una de las áreas y el usuario perpetró esto:

    Aplicación: (sin rellenar ... ¿cómo voy a saber la aplicación si hay que hacerla nueva? -dijo-)
    Causa: nueva normativa (sin más)
    Requerimientos: HÁGASE

    Así. Y se quedó tan pancho. Y lo más cojonudo es que los directores de ambas áreas la firmaron. Y lo más cojonudo es que la desarrollamos y la implantamos. Y lo más cojonudo es que está funcionando (y bien)

    Conclusión: si los requerimientos no dan la talla, las aplicaciones tampoco deben darla. Que fallen. Que hagan lo que no deben. Que no hagan lo que deben. Que no anticipen "futuribles" que no estén especificados (con lo que luego costará más hacerlos, obviusly)

    A ver si así aprenden.

  67. Peibol dijo...
  68. Ender, por supuesto que no hacen magia, y cuando un cliente es de lo peor y pide cosas imposibles, simplemente son imposibles. En ese caso el problema grande siempre está en aceptar un compromiso irrealizable.

    Aunque no me refiero a eso puntualmente, sino a temas como encontrar "el ritmo" de desarrollo y saber que compromiso se puede aceptar: evitar quedarte currando hasta las 12 de la noche intentando cumplir con una fecha de entrega imposible, entregando un producto malo malísimo, sin tests y que encima, si se ha hecho utilizando cascada no se aproxima ni por asomo a lo que quiere el cliente (muchas veces porque este no sabe lo que quiere).
    Me refiero a reemplazar tus "casos de uso" donde todo está perfectamente definido y tus "documentos de especificaciones" por "historias de usuario" con funcionalidades simples, directas (testeables), que se puedan redactar en un postit y que se puedan estimar de manera realista y no con un excel "brindis al sol" que calcule automáticamente basandose en "complejidad" y multiplicaciones simples de horas de programación ideal.
    Me refiero a cambiar esa cascada que mencionas por "reunión de planificación diaria, codificación del test que comprueba la historia de usuario, codificación, ejecución (constante, en cada commit) en integración continua, y documentación", pero no como una cascada, sino todo diariamente.

    Me refiero más a utilizar el estilo defensivo de diseñar desde el test, programar poco y entregar pronto (si puede ser todos los días), utilizando integración contínua e involucrando al cliente en la reuniones de desarrollo (esto es fundamental e innegociable) y si puede ser darle una demo (presentación) a la semana para que vea que estais creando.
    Si haces eso y el cliente puede ver como son las cosas y como se van haciendo, sabrá sin lugar a dudas que es lo que se puede y lo que no se puede hacer (así te ahorras los momentos de "hay que hacer un esfuerzo"), y además, el cliente se ira dando cuenta de lo que realmente necesita día a día.

    Te lo comento como un ex-sufridor de RUP + CMMI y actual disfrutador de scrum, lean y kanban, según el estado del proyecto. Además que me estoy convirtiendo en un talibán del TDD :D

  69. Peibol dijo...
  70. Ojo, que se me han quedado cosas en el tintero :-D

    Hay que tener una cosa muy clara con ágil, y es que se tiene que cumplir a rajatabla, cosas como "product owner" o "una sola persona representa al cliente" es fundamental, no pueden venir 10 personas a hablar todas juntas, de hecho en las reuniones diarias el PO solo puede oír y nunca puede decir nada.

    Al igual que las priorización de las tareas, si no hay prioridades o "todo es prioridad alta" (que es lo mismo que media o baja) no funciona, simplemente porque caes en los mismos errores que ya mencionas tu.

    Lo mismo que si no haces tests: tarde o temprano la vagancia o la falta de calidad vendrá a por ti, simplemente porque irás modificando cosas (esto pasa en cascada y en scrum también) y otras se romperán, es inevitable.

    Lamentablemente hay muchas empresas que descubren ágil y deciden quedarse "con lo bueno", hacen sus reuniones de pie y tienen la libertad de cambiar las historias de usuario cuando quieren, o de añadir épicas, pero luego ni priorizan, ni respetan los roles, ni respetan el ritmo de trabajo, y cuando la compilación se vuelve inestable se la deja estar porque "no hay tiempo de arreglar tests", etc. En estos casos estarás igual de jodido con ágil como con cualquier otra metodología.

    Yo simplemente veo el desarrollo ágil como algo mucho más honesto y realista que las declaraciones de intenciones y deseos de cascada.

    Salu2

  71. Ender Wiggins dijo...
  72. Peibol: Totalmente de acuerdo, pero en realidad, los docs de specs y casos de uso son refinables, y no tiene que ser completos a la primera; De hecho, los docs de casos de uso son en realidad, si no sigues RUP y te limitas a definir el curso del caso de uso en lenguaje natural, elementos sencillos de modelación.

    el RUP no es malo en sí mismo, si no obligas a seguir todos y cada uno de los pasos, que es lo que hace el 99% de las empresas, creyendo que generar documentso que no necesitas garantiza la calidad.

    EL problema de utilizar metodologías ágiles es cuando la empresa se mueve en proyectos gigantes con una primera versión plagada de funcionalidad... que solo está imaginada. Hoy he recibido una spec que constaba de una captura de pantalla... y un doc en el que no ponía nada. Dantesco, pero real. Y eso que el cliente somos nosotros mismos...

    thanks por el párrafo. Scrum. por lo poco que he podido trastear, mola. estoy intentando cambiar el chip de la gente en mi empresa; a los desarrolladores, es fácil; pero al resto...

  73. Peibol dijo...
  74. Como bien dices RUP no es malo en si mismo, CMMI si XD

    En mi experiencia, el mayor problema de la cascada es cuando una empresa piensa que la calidad está en generar documentos infumables que nadie jamás leerá, exactamente como lo dices tu.

    En fin, creo que por hacer un resumen muy rápido de scrum, es simplemente que como el usuario no es formal, el desarrollador tampoco tiene porque serlo XD (responsable si, no confundamos conceptos).

    A nosotros también nos mandan "especificaciones" en ppt y pantallazos con lo que quieren, nosotros traducimos eso en entradas en el backlog y posteriormente en historias de usuario (de hecho hay pantallas y ppts que hacen que a mi me dejan flipado de como lo consiguen, impresionantes, es como la aplicación en si misma, solo que hecha a golpe de ppt).

    Pero creo que de todo esto el concepto más interesante que hemos aplicado es el de buscar el ritmo que hace que realmente se pueda ser honesto en el compromiso, y que el cliente sepa que realmente estás siendo honesto en tu planificación (diaria, semanal o mensual, lo que quieras), y lo mejor: que no tengas que quedarte todos los días hasta las 10 de la noche currando.
    Y finalmente: TDD, sin test no hay calidad.

    PD: si quieres ver cosas de agilismo mirate ese blog (dos ideas), muy bueno y muy documentado.

    Salu2

  75. Anónimo dijo...
  76. Meneado:

    http://www.meneame.net/story/la-tecnologia-es-magica

  77. Silvia dijo...
  78. Sólo comentar que esta tira ya rula por varias empresas del sector informática en el País Vasco. Doy fe.

  79. Martín dijo...
  80. Buenísimo!

  81. Jose Manuel Beas dijo...
  82. Sr Wiggins, me permito añadir una cuñita publicitaria dado que habéis comentado algunas cosillas sobre agilismo (Scrum y todo eso). En España, algunos llevamos un tiempo ya intentando hacer que esto del agilismo vaya dándose a conocer. No sé si estáis al corriente de la asociación Agile Spain, pero tenemos una lista de correo donde podéis encontrar mucha información, mucha colaboración y muchas ganas de compartir experiencias. De hecho, ya tenemos varios grupos locales que se reunen frecuentemente (en Barcelona, Madrid, Valladolid, Levante, Galicia y País Vasco) y organizamos eventos donde, entre otras cosas, tratamos de mostrar que "hay mejores maneras de hacer software". Estáis todos invitados.

    Gracias por la cuña y enhorabuena por la tira. Personalmente la sigo (reconozco que irregularmente) desde hace tiempo y me parece un imprescindible. :-)

  83. Ender Wiggins dijo...
  84. Jose Manuel: thanks por la info, se agradece. A ver si consigo convencer a mis comerciales de que esto puede ser buena idea.

  85. harry dijo...
  86. xDDDDD
    me parto en serio
    sigue asi!

  87. El Guerrero del Interfaz dijo...
  88. La razón de todo esto es la misma que la de las últimas paridas de Alierta y Sebastián: la completa incultura tecnológica de los mandamases cuyo conocimiento de las nuevas tecnologías se limita a lo que ven en pelis USAmericanas y a gritarle a su secretaria "Niñaaaa, a ver si me buscas esto en el Gogle éste".

    Y no se solucionará hasta que no lleguen a puestos directivos gente con educación y conocimientos de nuevas tecnologías. Y los jefes de ahora, o se reciclan o a la cola del paro con un pico y una pala. O esto no levanta cabeza nunca...

  89. El Guerrero del Interfaz dijo...
  90. La flexibilidad está muy bien pero no puede sustituir las especificaciones. La flexibilidad no es algo que se especifica sino que tiene que ser utilizada por los propios programadores para cubrirse el culo.

    Un ejemplo que me pasó con el programa de procedimientos del Centro de Control de la Expo'92. Según especificaciones había que programar "n" procedimientos compuestos por "m" instancias de "l" acciones que a su vez contenían "o" campos de "p" tipos. Siendo "n", "m", "l", "o" y "p" números fijos, determinados y especificados.

    Según esto yo habría podido crear la estructura de datos especificadas usando arrays multidimensionales ya que todas las dimensiones eran fijas y especificadas. Pero como conozco el percal, usé listas encadenadas y árboles por si acaso cambiaban esas especificaciones.

    Evidentemente las especificaciones cambiaron aumentando todas las cantidades. Varias veces. Pero, como había usado estructuras de datos flexibles, no tuve que modificar nada. Y cuando añadieron además un nivel más, el cambio fue trivial.

    Así que si *especifican* "flexibilidad", encima nos quitan una de las más importantes protección que tenemos contra los caprichosos cambios de especificaciones.

  91. capynet dijo...
  92. Simplemente genial. es lo mismo que nos pasa en mi trabajo.

  93. An dijo...
  94. Clientes asi...a mares, y lo peor es que despues o no pagan o bien tardan una eternidad. Saúdos e apertas

  95. El Chinchudo dijo...
  96. He me tomado la libertad de citar este "Que pasaría si..."

    http://elchinchudo.blogspot.com/2010/02/si-el-sector-de-la-construccion-tuviese.html

  97. Hawk dijo...
  98. Aun no he tenido "trabajos formales" en mi area (la informatica), pero todos los k han recurrido a mi por ser "computin" preguntan y piden todo pensando enk manejamos todo... y simplemente, no lo sabemos todo, y a eso hay k agregarle el k no nos entregan los detalles de lo k kieren...
    muy buen post, es algo de esperanza para los k aun no salen a trabajar...

  99. rage86 dijo...
  100. Estoy enganchadísima a estas tiras, esque es mi día a día, y ni siqiuera soy ingeniera, si no de módulo XD

  101. Ender Wiggins dijo...
  102. rage86: ¡bienvenida!

  103. Anónimo dijo...
  104. Soy albañil y algo parecido me pasó. Y para cobrar encima me tuve que llevar las ventanas una vez terminada la casa. Casi todos los gremios son igual de tristes.

Publicar un comentario en la entrada