Trasteando en archive.org recupero un artículo que escribí en 2004 en mi antiguo blog:
El libro "La cultura norteamericana contemporánea. Una visión antropológica" del antropólogo Marvin Harris dedica un capítulo completo ("¿Por qué no funciona nada?") a buscar una explicación del porqué de la baja calidad de los productos fabricados a partir de la Segunda Guerra Mundial en Estados Unidos (y por extensión, yo añadiría, en todo el mundo occidental).
Desde principios de los años ochenta han proliferado las empresas de creación de aplicaciones informáticas a medida, y desde mediados de los años noventa se le sumaron las empresas que desarrollaban aplicaciones para Internet. Un gran porcentaje de personas que han contratado servicios informáticos para la creación de esas aplicaciones informáticas habrán "sufrido" las consecuencias de la forma de desarrollar dichos proyectos. Otro gran porcentaje de profesionales de la informática habrá comprobado desde dentro el funcionamiento de sus empresas en el desarrollo de dichos proyectos. Todos ellos podrán llegar a una conclusión: las aplicaciones nunca funcionan como el usuario desea .
Volviendo al libro de Marvin Harris, "los artefactos utilizados por las sencillas sociedades prehistóricas tenían un diseño sencillo, incluso primitivo, y, sin embargo, estaban construidos para que cumplieran sin fallos los propósitos a que se destinaban toda la vida." ¿A que se debe esa calidad? ¿Será la tecnología que todavía no está dominada al cien por cien? No lo creo. Según el propio Marvin Harris a que "los productores y consumidores eran los mismos individuos o parientes próximos, lo que garantizaba el mayor grado de seguridad y duración en los artículos manufacturados".
¿Qué significa todo esto? ¿Es un alegato al retorno a la vida prehistórica? ¿Significa que evitemos las especialización y nos dediquemos a realizar todos los trabajos del hogar? ¿Que nos convirtamos en autosuficientes? ¿Que tengamos nuestro propio huerto, nuestra propia panadería, y...seamos nuestros propios médicos? No. Nada de eso. Si lo enfocamos desde la otra perspectiva, y, en vez de preguntar por qué funcionaban las cosas en la prehistoria, retornamos a la pegunta original: ¿Por qué no funcionan las cosas en nuestra época? Una respuesta podría ser: por la alienación de los trabajadores. Es muy difícil que la gente se preocupe de los extraños o de los productos que éstos utilizan. En nuestra época donde predomina la economía terciaria, la de los servicios y de las grandes corporaciones (las multinacionales, los conglomerados, la empresas diversificadas... en realidad oligopolios), y de la consecuente burocracia, no resulta muy complicado que las relaciones productor-consumidor hayan sido sustituidas por las relaciones monetarias no como fin último, sino como medio. La idea de la alienación no es nueva, según Karl Marx la alienación del trabajo asalariado es fundamentalmente un "extrañamiento del obrero frente al producto de su trabajo y frente al proceso de trabajo, y esto lo mismo para el trabajo manual como para el trabajo intelectual".
Actualmente, las grandes empresas de desarrollo de aplicaciones informáticas o las grandes consultoras de tecnología copan casi el 100 por 100 del mercado del desarrollo informático, el otro pequeño porcentaje queda para pequeñas pymes y profesionales autónomos. Según Marvin Harris, "los problemas de la calidad en los Estados Unidos alcanzaron proporciones críticas como consecuencia del aumento, sin precedentes hasta entonces, en el tamaño y la complejidad de las corporaciones industriales, así como el número de trabajadores y directores alienados y negligentes". Las grandes empresas de servicios se han convertido en cadenas de montaje. En esta línea, Corinne Maier, en su obra "Buenos días, pereza", explica que "las profesiones ya no exigen un elevado nivel de competencia técnica o intelectual. Son básicamente una rutina y requieren tan poca iniciativa y espíritu de innovación que cualquier persona con los estudios apropiados se encuentra ya de entrada sobradamente preparada para la mayoría de los puestos de trabajo disponibles".
Además de la alienación de los trabajadores, se ha implantado en estas grandes empresas, y ya en la sociedad globalizada, el márketing (o la "obsolescencia planeada" como lo llama Harris) como un tótem indiscutible. No quiere decirse con lo de "obsolescencia planeada" que se vendan productos con fallos deliberados, pero sí productos con perfeccionamientos paupérrimos sobre sus versiones anteriores con la única intención de implantar los segundos sobre los primeros. Las grandes corporaciones, esas que copan casi el 100 por 100 del mercado de desarrollo informático y cuentan con casi el 100 por 100 de trabajadores alienados, dedican todos sus esfuerzos, no en sacar productos perfectos, sino en crear campañas de marketing perfectas, campañas de venta de humo. Los directivos de esas empresas permanecen en sus puestos como mucho diez años, el suficiente para mejorar las cuentas de la empresa, y cuando los productos están en la calle, ellos ya han salido por la puerta (por la puerta grande, seguramente). Como dijo Goebbels a Hitler: "No hablamos para decir algo sino para obtener determinado efecto". Tras esa fachada de cartón-piedra que es el márketing y la imagen, se encuentran (si la ropa de marca la fabrican niños asiáticos, entonces...) becarios que dedican sus horas de formación y su fuerza de trabajo a sacar adelante productos que el cliente piensa que han sido desarrollados por ingenieros y profesionales altamente cualificados.
Las características de la profesión informática y de los avances técnicos (trabajo a distancia, colaboración con otros profesionales) posibilita que se pueda desarrollar la profesión bajo una forma más manual, más personal, más cercana al usuario final, en definitiva el cliente, como los pequeños orfebres del siglo XV o los pequeños comerciantes de principio de siglo XX. No es necesario que cada profesional sólo pueda ofrecer los servicios de los que es capaz de realizar, sino que se pueden formar pequeños colectivos de trabajo interdisciplinares pero relacionados (programadores, analistas, diseñadores gráficos, analistas de negocio, ingenieros de sistemas, etc.) que puedan ofrecer al cliente un servicio perfecto basado en la cercanía del productor en relación con el consumidor. El productor trabajará directamente para él mismo, se evitará la temida alienación y consecuentemente se pondrán en el mercado mejores productos.
Harris, Marvin. "La cultura norteamericana contemporánea. Una visión antropológica", Alianza Editorial, Madrid, 1984
Maier, Corinne. "Buenos días, pereza", Editorial Península, Barcelona, 2004
Marx, Karl. "Manuscritos económicos-filosóficos de 1844", Editorial Grijalbo, Barcelona, 1975
Mostrando entradas con la etiqueta programación. Mostrar todas las entradas
Mostrando entradas con la etiqueta programación. Mostrar todas las entradas
jueves, 11 de diciembre de 2008
martes, 18 de noviembre de 2008
Cómo crear un aplicación web. Fase IV. Programación.
Fase I. Toma de requisitos
Fase II. Prototipos
Fase III. Diseño gráfico + Diseño software
Cuando ya tengamos las pantallas de la aplicación maquetadas en HTML y la base de datos modelada podemos pasar a codificar (programar) la aplicación.
Dividiremos la aplicación en diferentes capas (N-capas). Cada una de esas capas se comunicará con las demás y será independiente de las demás. ¿Qué son las capas? Simplemente agrupación de clases y funciones.
Mi recomendación es que nuestra aplicación tenga las siguientes capas:
Mi recomendación es ir programando las capas en este orden: primero el acceso a datos y de esa forma crear una batería de pruebas para comprobar si los datos se guardan correctamente en la base de datos. Una vez está testeado, crear la capa de negocio y continuar con las pruebas, para acabar con la capa de presentación. Si hemos realizado las pruebas correctamente y, puesto que ya tenemos los prototipos maquetados en HTML, la programación de capa de presentación será muy sencilla y rápida.
Todo este proceso puede dividirse en partes independientes e ir realizando entregas al cliente y así evitar una entrega única al final del proyecto.
Fase II. Prototipos
Fase III. Diseño gráfico + Diseño software
Cuando ya tengamos las pantallas de la aplicación maquetadas en HTML y la base de datos modelada podemos pasar a codificar (programar) la aplicación.
Dividiremos la aplicación en diferentes capas (N-capas). Cada una de esas capas se comunicará con las demás y será independiente de las demás. ¿Qué son las capas? Simplemente agrupación de clases y funciones.
Mi recomendación es que nuestra aplicación tenga las siguientes capas:
- Capa de acceso a datos: lanzará consultas a la base de datos (o el repositorio de datos sobre el que debamos atacar, ya sea base de datos, archivos de texto o archivos de cualquier tipo). Debemos crear una consulta para cada uno de los casos de uso definidos anteriormente, por ejemplo, crear usuario, añadir fotografía, modificar perfil, etc. Las consultas sobre una base de datos relacional se realizan en el lenguaje estándar SQL, es muy recomendable crear procedimientos almacenados (no son más que funciones con parámetros de entrada/salida) en la propia base de datos y minimizarlos a la mínima expresión (select, delete, update, insert).
- Capa de negocio: Es el lugar donde se lleva a cabo el core de la programación, donde se transforma los datos obtenidos por la capa de datos en datos que podrán ser mostrados por la capa de presentación, y viceversa.
- Capa de presentación: en el caso de las aplicaciones web, la capa de presentación es la que muestra datos en la pantalla y recoge datos introducidos en los formularios.
- Capa de acceso a aplicaciones de terceros: si nuestra aplicación necesita acceder a datos de terceros (APIs de aplicaciones públicas, XML de datos de otra web, servicios web, etc.) es recomendable que lo centralicemos en una nueva capa. De esta forma si cambiamos de proveedor o cambiamos la forma de obtener esos datos, será totalmente transparente a las demás capas.
Mi recomendación es ir programando las capas en este orden: primero el acceso a datos y de esa forma crear una batería de pruebas para comprobar si los datos se guardan correctamente en la base de datos. Una vez está testeado, crear la capa de negocio y continuar con las pruebas, para acabar con la capa de presentación. Si hemos realizado las pruebas correctamente y, puesto que ya tenemos los prototipos maquetados en HTML, la programación de capa de presentación será muy sencilla y rápida.
Todo este proceso puede dividirse en partes independientes e ir realizando entregas al cliente y así evitar una entrega única al final del proyecto.
Labels:
gestión,
programación,
TIC
Suscribirse a:
Entradas (Atom)

