Arquitectura de la Información en la Ingeniería de Software

Hace unos días tuve el privilegio de poder participar en el Barcamp 2011 donde pude compartir una visión respecto a la Arquitectura de la Información aplicada al proceso de Ingeniería de Software.

Básicamente la exposicion se trato de la metodología que hemos trabajado y depurado en el equipo de trabajo que me desempeño, para enfrentar proyectos Web.

A continuación comparto mi presentación.

Arquitectura de la Información en la Ingeniería de Software

Como la Arquitectura de la Información potencia la Ingeniería de Software al desarrollar para la Web.

¿Y que tengo para contar?

Resultados de la aplicación de la A.I en el ciclo de desarrollo de software:

• Al momento de modelar procesos de negocio.
• Al momento de diseñar un flujo de trabajo.
• Al momento de desarrollar.
• Al incorporar a nuevos miembros al equipo de desarrollo.
• Al incluir al usuario final desde la etapa 0.
• Al tener que enfrentar cambios drásticos en el producto.

¿Que hacemos de novedoso?

• La verdad es que nada.
• Recolectamos técnicas de desarrollo existentes y generamos un set de pasos mínimos para aplicar a nuestros proyectos.
• Estos pasos tienen carácter obligatorio e involucran, consiente o inconscientemente al usuario final.
• Lo más importante, quitamos el foco de la tecnología y lo pusimos en la metodología para beneficiar al usuario final.

¿Y podemos conocer los pasos?

• Diseño del flujo del negocio.
  Para esto realizamos un flujo de los procesos de negocio.
• Entrevistamos al usuario final, con énfasis en la mejora que debería contar el proceso.
• Modelamos los procesos de negocio con sus correspondientes actores.
• Como en todo proceso comenzamos el modelamiento con una simple pregunta: ¿que quieren?
• Luego buscamos cuestionarlos: ¿pero estás seguro que es mejor así?

Diagrama de Interacción

• Del diagrama de procesos generamos la navegación del sistema, o sea, el diagrama de interacción.
• El usuario participa en este punto tanto para mantenerlo al tanto del proceso como para evitar desviarnos de la necesidad de este.
• Nos basamos en el modelamiento propuesto por Jesse James Garret

Modelamiento de la Base de Datos

• Luego pasamos a preguntar: ¿y que quieren registrar?
• Ante la respuesta: “Todo”, preguntamos ¿y te sirve?
• Con la fase anterior y el modelo relacional tenemos suficiente para hacer una gran pregunta que nos sirve para generar un hito: ¿que es lo que más te urge en este momento?

Wireframes y algo más

• Wireframes de baja calidad para revisión y correcciones internas
• Wireframes de media calidad para revisión con el usuario.
• Maquetas del sitio (opcional).
• Aprovechamos la potencia de los mocks (mockflow), para fusionar dos etapas el Wireframe y los casos de uso, así la especificación de la interfaz es una guía completa tanto para el desarrollador y como el diseñador.

¿Que tenemos hasta aquí?

• Alto nivel de involucramiento del usuario final.
• Documentación de todo el proceso de diseño tanto de negocio como estructural del sitio Web.
• Especificaciones más precisas para los desarrolladores y diseñadores gráficos.
• Nuevamente, el foco deja de estar en la tecnología y se situá en el usuario.
• Por lo mismo el usuario es “evangelizado”, conoce de mejor forma las funciones de sus compañeros y siente que su participación es importante para el éxito del proyecto.

Planificación

• Al tener ya la estructura de la base de datos, la navegación, el diseño de interfaces con sus casos de uso; se hace mas precisa la estimación de esfuerzo para la planificación del proyecto.
• Se plantea un primer entregable que consiste en atacar aquel requerimiento más urgente.

Construcción

• Nuevamente privilegiamos la metodología por sobre la tecnología.
• Uso del Modelo/Vista/Controlador
• Desarrollo mediante prototipos, los que van en sintonía con las fases del proyecto.
• Uso de FrameWorks tanto para abstracción de capa de datos como gestores de templates de la capa de presentación.
• Ahhhh... opensource ;)

¿Y las pruebas?

• Aparte de las pruebas unitarias y de integración, es muy importante objetivizar la satisfacción del usuario.
• Pruebas heurísticas y Think aloud... de forma casi invisible, el usuario ayuda aun más cuando no sabe que está siendo encuestado ;) .

Analítica y visualizacion de datos

• Casi tan importante como la captura de datos es la actividad de visualización de datos.
• Sobre todo cuando se manejan sistemas comerciales, se privilegia el reporte gráfico por sobre listas de datos.
• Un buen trabajo de interpretación de datos libera la dependencia del “excel” lo que se traduce en optimización del tiempo de los usuarios.

 

¿Y los resultados?

• Los efectos de aplicar un ciclo de desarrollo de Software, donde el foco es el usuario nos ha permitido:
• Ganar credibilidad para el equipo.
• Evitar situaciones de cambios de especificaciones por el motivo de: “no era lo que dije”
• Desarrollo ágil, económico (tanto en recursos de hardware como licenciamiento)
• Rápida capacitación de nuevos integrantes del equipo, facilita la rotación.
• Una mejor calidad de la documentación del proyecto.
• Este proceso es fácilmente integrable a otras metodologías de desarrollo como CMMI o ISO.
• Mejora de la etapa de Q.A, al poder medir la experiencia de usuario dentro del sistema.
• Proceso de diseño y estructuración rápido.
• Mejores resultados al reutilizar proyectos anteriores.

Para terminar

• La Arquitectura de la Información ofrece nuevas herramientas para los desarrolladores.
•  Mejora la comunicación dentro de un equipo de desarrollo al permitir que el programador y el diseñador convivan sin la clásica disputa “funcionalidad sobre gráfica”.
• Devuelve al informático al origen: Metodología.
• Pone como principal actor del proceso de desarrollo al usuario.

¿Es importante tener analítica Web en una intranet?

imagen de desenchufados.net

Con el tiempo he visto mucho de estadísticas de sitios en Internet, es lógico los dueños de un portal o una tienda desean  saber si su inversión, vitrina o vendedor virtual esta cumpliendo con sus objetivos y por sobre todo adelantarse a la competencia para ofrecer mejores y variados servicios para fidelizar a sus visitantes.

Pero ¿en una Intranet?

Cierto es que la Web es la Web tanto en Internet o una Intranet (también en una Extranet) pero como bien sabemos una Intranet no compite con otros sitios u otras empresas, además esta la "obligación" impuesta por tener que emplear estos recursos y por lo tanto suelen quedar relegados a un segundo plano (con suerte).

En Chile contamos con otro mal que afecta a nuestros sistemas corporativos: En casa de herrero, cuchillo de palo. Pues si las grandes empresas que se dedican a la venta e integración de tecnologías de punta no cuentan con sistemas internos amistosos o no explotan la ya mentada Web 2.0 en su ADN  corporativo... ¿que se le puede pedir al resto del empresariado o instituciones del estado?

Por lo general las intranet no cuentan con estudios de usabilidad, una adecuada arquitectura de información, estadísticas de uso o mecanismos de retroalimentación formal... dentro de una organización su gente se las arregla como puede mientras que para el mundo se muestra otra cara.

Pero como todo sitio, una Intranet o servicio en una Intranet también tiene una encarnizada lucha que quizás es más dura que la lucha de un sitio en la Internet, pues un sitio público puede justificar su existencia por los negocios, imagen o beneficios adicionales como fidelización que puede lograr con ella. Mientras que una Intranet vive con el eterno estigma de Para que me sirve.

Un servicio en una Intranet tiene que demostrar un difícil beneficio corporativo, que su construcción y operación no es un gasto sino una inversión y además luchar contra otros servicios que pueden quitarle presupuesto.

Es aquí donde el registro de información de uso, acceso y comportamiento de los usuarios gana importancia pues si existen millones de sitios en Internet que nadie los visita, en una empresa este es un lujo que no se puede dar; por ello se debe justificar con números concretos la utilización de dicho servicio.

Existen muchas soluciones para Intranets como plataformas integradas que ofrecen el oro y el moro a cambio de que uses una tecnología de la cual no podrás escapar nunca del sistema de pago de licencias... aunque hoy por hoy empresas como Microsoft regalan amablemente parte del costo de las licencias para que uses sus productos (solo para grandes empresas). Pero la letra chica es que necesitas una arquitectura de hardware monstruosa: por ejemplo para Sharepoint 2010 necesitas Windows 2008 Server R2 x64 bits con 32 Gigas de RAM mínimo, o sea casi US$10.000 solo en maquinaria.

Estos requisitos hacen que los dueños de una empresa, que al fin y al cabo quieren ver maximizada sus ganancias, no vean con muy buenos ojos el invertir en recursos de Intranet que al final no redituan utilidades... Claro que hay algunas excepciones que luchan contra esta costumbre.

Lo cierto es que para implementar una Intranet y sus servicios a un bajo costo tienes software libre para cada una de las necesidades de una empresa y se pueden desarrollar integraciones de múltiples tecnologías gracias a estándares como SOAP. El uso de sistemas como Linux logran abaratar el costo de implementación y casi no hay nada que un sistema basado en el Opensource no pueda hacer igual o mejor que la plataforma ofrecida por Microsoft (a casi 1/5 del costo).

Pero esto no basta, pues se debe acompañar con números concretos de utilización de dichos recursos y beneficios a la operación de la compañía, es por ello que la analítica debe acompañar también a aquellos desarrollos destinados a funcionar en una Intranet.

PD: Resistance is futile.

Redes sociales y empresas

Mucho se dice de las ventajas que pueden presentar las redes sociales para una empresa: visibilidad de productos, llegada directa a los clientes, capacidad de segmentar a sus clientes y potenciales clientes a través de sus intereses, etc.

Pero todos los potenciales beneficios de una red social que he mencionado, y que muchos documentos y publicaciones que se encuentran hoy en la web toman estos y muchos más; pero siempre desde el punto de vista externo, o sea, que sea la empresa que se suma o utiliza una red social para poder sacar provecho de ella.

¿Y hacia adentro de una empresa?

Si miramos la organización de una empresa, sobre todo las nacionales, vemos que su estructura jerárquica no cambia y a pesar de las implementaciones de Intranets soportadas por sistemas que tienen elementos de redes sociales estos son tomados casi como accesorios.

Una pregunta que surge ¿Que beneficios tiene una red social o la filosofía de un sistema basado en Web 2.0 tiene para una empresa?¿Que ganaría una empresa en empezar a integrar dentro de si estos conceptos? y por sobre todo ¿donde aplicarlos?

Existen muchos elementos de las áreas comerciales de una empresa que se pueden nutrir positivamente  de la aplicación de una filosofía de Web 2.0 en sus sistemas internos, uno de ellos son los contactos de negocios. Estos contactos pueden ser relacionados a través de matrices o redes que brindan información contundente y relevante para tanto fidelizarlos, como para crear nuevos contactos que a la larga generaran nuevos negocios para la compañía. También se logra otro beneficio, pues al estar esta información dentro de un sistema centralizado del que es propietario la compañía, la información no se pierde cuando un ejecutivo comercial emigra de su puesto y además empleando las características colaborativas de la filosofía 2.0 se logra mejorar la calidad de la información al permitir que no solo sean los ejecutivos comerciales quienes aporten información al respecto, sino también otras áreas técnicas que también interactuan con un contacto.

Otro foco de información extremadamente relevante para una empresa es poder contar con los perfiles y competencias de su propia fuerza de trabajo. Es aquí donde las áreas de recursos humanos se pueden ver extremadamente beneficias al tener información fresca y actualizada de primera mano de las competencias y especializaciones de sus empleados, logrando conformar equipos multidisciplinarios más productivos según sea el requerimiento.

En resumen, para mi, los beneficios de una red social no solo están en poner una organización o empresa en un Facebook, Twitter, Tuenti, Linkedin, etc. Con el objetivo de mejorar la visibilidad o la imagen de modernidad de una organización, sino en la aplicación de estos conceptos hacia el interior de la organización para aumentar el conocimiento de nuestros contactos de negocios, que son nuestros clientes actuales o potenciales, incluyendo además a los proveedores; también para mejorar el conocimiento de nuestra fuerza de trabajo y saber reconocer donde poder realizar una mejor inversión en adquisición o actualización conocimientos.

 En fin... Resistance is futile.

Fuerza Japón

Así como en otros escritos, no puedo dejar de enviar mis mejores deseos para que nuestros hermanos teluricos puedan pasar este trago amargo.

Tengan otro abrazo, consuelo y toda mi fuerza espiritual centrada en que puedan pasar rápidamente este momento.

La importancia de un laboratorio

Si le preguntamos a un químico que ocurre si mezclo tres moléculas de cloro con dos partes de hidrógeno y lo batimos a unas 18.000 revoluciones por minuto. Lo más probable es que nos diga que primero debe hacerse una simulación o una prueba en el laboratorio.

¿Habré dado alguna formula altamente volátil y destructiva con los ingredientes que dije?

Si a un ingeniero calculista, le pedimos realizar una demostración del comportamiento del un diseño de un rascacielos frente a la fuerza de un monzón. Nuevamente nos llevará al laboratorio para poner en practica el diseño a escala del rascacielos.

¿Moraleja?

Conversando con mi buen amigo Sergio del blog http://blog.crazyrobot.net/, bueno más que conversación era una acalorada discusión... que nuevamente le gane por K.O ^^.

Bueno, sin desviarme.

Teníamos la clásica discusión Planificación v/s  ejecución, en donde uno de los puntos vitales que tocó era que en vista de las capacidades humanas, el poder prever todas las alternativas es virtualmente imposible.

Por lo que un esquema tipo XP (Programación Extrema) es el más adecuado para ir trabajando y generando una visión del sistema que se construye.

Desde muchos puntos de vista tiene mucha razón, pero como bien nos dice la trampa del sentido común también no la tiene.

Una de las gracias de las ciencias de la construcción, me permito llamarla así, es que tienen unos 12mil o 15mil años de experiencia... desde el mismo instante en que uno de nuestros antepasados decidió hacer una ampliación a su cueva a solicitud amable de su pareja.

La ciencia del Software tiene a lo mas sesenta años, lo cual no es excusa para repetir una y otra vez los mismos errores.

Una de las características de la construcción es que ninguna es igual a otra, pues si traigo un ingeniero italiano a diseñar y construir a la usanza italiana a Chile, sus casas o edificios se caerían al primer temblor grado 6... notese que en Chile le llamamos temblores a eventos que en el resto del mundo son terremotos catastróficos.

Pero ese ingeniero Italiano puede fácilmente aprender de la escuela chilena leyendo la normativa vigente y revisando los casos de éxito de otras construcciones y hacer un diseño que resista un terremoto grado 8,5 como lo exige la norma.

En su proceso de construcción pasará inevitablemente por un ... LABORATORIO.

En el mundo del Software, en especial en Chile, tenemos dos problemas:

• No hay una escuela de desarrollo de Software, por lo que cada empresa reinventa la rueda.
• Las empresas no publican sus casos de éxito para que no les copien su metodología.

Con la irrupción de conceptos tan "revolucionarios" y "heréticos" como Diseño centrado en el usuario, tests de usabilidad y arquitectura de la información, se ha logrado romper con el esquema actual de construcción de software.

Claro que todavía falta para contar con una biblioteca real de casos de éxitos y fracasos, que ayude a los diseñadores a tener recursos a los cuales echar mano para evitar o cubrir situaciones conflictivas a futuro. Y ojo, que esto no significa en contar con proyectos completos y hacer copy/paste.

Las empresas no gastan recursos en laboratorios, en eso estamos claro, pero si los diseñadores/analistas/programadores necesitan contar con un campo de pruebas para probar no solo tecnologías sino que además metodologías y técnicas que afecten a los usuarios.

Pues como toda actividad mientras más práctica se tenga, mejor se es.

Creo que si tu empresa no te da el tiempo ni los recursos, y es muy difícil que lo haga sobretodo si es chilena, un diseñador/analista/programador puede  (y debe) contar con su campo de pruebas y un grupo de usuarios/victimas  para realizar mejoras en su forma de trabajo y visión de como ven los usuarios nuestros sistemas.

Yo tengo el mio por si acaso, esto no es de Padre Gatica, el mio es un juego Rex-draco y el mundo de Mul-sabbuth... ¿que? acaso todos los laboratorios tienen que ser "serios".

Programación Usable y Accesable

Parece nombre de asignatura desconocida de una carrera desconocida, pero la verdad que en un ataque de creatividad post almuerzo se me vino a la mente este concepto... ¿que? ¿acaso no me creen que aparte de la modorra que se produce después de la hora de almuerzo no tengo visiones iluminadas?

Si bien es cierto que un programador/analista/ingeniero/mesa de ayuda/instalador/operador (no se me ocurren cuantos roles más cargar aquí), participa de la construcción de un sitio Web como último elemento de la cadena de producción; bueno en aquellos proyectos bien definidos pues en los otros los mandan a trabajar incluso antes de saber que demonios quiere el cliente. Existen una serie de recursos y/o aplicaciones comunes que se van repitiendo en casi cualquier tipo de sitio Web.

Por ejemplo, ¿cuantos estilos de solicitud de RUT vemos normalmente en la web?, tenemos de todos los tipos:

• Los que te obligan a poner el formato de forma estricta con puntos y el guión
• Los que te ponen por separado el dígito verificador.
• Los que le da lo mismo como lo escribas pero te formatean en el mismo input, lo que provoca que si recargas la página o vuelves a ese formulario la memoria del navegador hace que el algoritmo se caiga y te aparece un hermoso "NAN" 
• Los que te limitan el tamaño del input y además te formatean el dato.
• Y algunos que le da lo mismo lo que pongas y guardan lo que ingresaste sin validación alguna.

Otro ejemplo de dato común es el famoso select box de comunas (me centrare en el caso chileno).

Lo más, pero más común es que las comunas estén ordenadas alfabéticamente, poseen un filtro primario que te relaciona la comuna a la región. Existe una variación que te liga a la provincia, pero siendo justos con la realidad ¿cuantos de nosotros están conscientes de en que provincia viven o trabajan?

Mi favorito, el tema Origen - Destino en los sitios de aerolíneas en donde te piden seleccionar la ciudad de origen y evidentemente el destino. Algunas te ponen por defecto la ciudad donde estás, pero si accedes desde otra ciudad te das cuenta que es un dato forzado al país de origen, el cual no es detectado sino que se toma por defecto cuando entras al sitio mediante un enlace que te hace seleccionar el país en el que estas.

Una visión que tiene el usuario y que es diametralmente opuesta a la visión del equipo de codificación de una Web, hago la salvedad del equipo de programación pues como sabemos se tiende a dejar todo lo técnico al programador (lo que considero un error). Es que todo lo que se pide cambiar y agregar, o eliminar, es fácil y rápido de lograr.

Pero siendo justos, muy pocas veces un cambio es sencillo a no ser que te pidan cambiar la fuente de una página... algo que se encarga raudamente de hacer el diseñador, dicho sea de paso, y el resto al programador.

Pero tampoco es excusa para no hacerlo o irse por el camino más fácil, puesto que para lograr un alto indice de Usabilidad de un sitio Web se deben brindar todas las facilidades de diseño, contenido y programación para que la experiencia del usuario sea placentera y el usuario se transforme en cliente fidelizado.

Cierto es que construir una facilidad para el usuario final toma tiempo y esfuerzo, tan solo para hacer un misero select box de comunas, pero la verdad es que (como nos dijo un profesor de Calidad de Software hace un tiempo), "Se programa una vez, se usa millones de veces".

Para el caso del select box de Rut, no es más usable el crear tu librería para que el usuario ingrese lo que quiera y sea tu código el que valide que:

• Sea un RUT, o sea no contenga código malicioso.
• Si al usuario le gusta escribirlo con puntos y guiones, sea el código quien limpie estos elementos
• Si el usuario le gusta escribirlo de corrido, o sea, sin puntos y guiones, sea el código quien se encargue de formatearlo en la base de datos de ser necesario.
• El input del RUT sea solo un elemento y no dos.

Para el caso del select de comunas, este es un poco más complejo, pero considerando la distribución de la densidad poblacional en Santiago de Chile (y se tiene la distribución por cualquier ciudad de Chile), puesto que las comunas más densas son Maipu, Puente Alto, La Florida y Providencia; no es más probable que un usuario viva en dichas comunas y no en Alhue (donde viven menos de 5000 personas). En rigor estamos haciendo un ordenamiento por cantidad de población y no alfabéticamente.

Claro que hay que recordar dejar un aviso o una opción para que el usuario pueda ver su combobox ordenado alfabéticamente... pues nunca se sabe.

Respecto a la ciudad de origen de los sitios de aerolíneas:

• El método para reconocer el país desde donde estas accediendo es bastante vetusto y consiste en capturar la IP de tu conexión, algo que ya se hace dicho sea de paso en todo sitio Web.
• Ya existen varios sitios que además capturan la ciudad en la que establece la conexión, también mediante la IP; otros sitios ofrecen georeferenciar tu conexión, como Google Maps.

¿No sería bastante practico ofrecer de esta manera dinámica los datos para el origen del vuelo por defecto?, evidentemente dejando siempre la opción de cambio por si el cliente quiere comprar pasajes para otro destino.

Programación Usable trata de eso, en como visualizar recursos que requieren bastante análisis y esfuerzo en donde el resultado prácticamente pasara inadvertido a simple vista, pero que impactará positivamente en la experiencia del usuario; lo que finalmente se traduce en beneficios para la compañía.

 Otro punto importante es el nivel de accesibilidad del producto final que desarrollamos, y esto si que es de interés desde el punto de vista comercial de un sitio Web.

¿Cuantos clientes se pueden perder, porque la programación de las interfaces de comprar un producto o servicio?¿Cuanto podríamos aumentar nuestro mercado potencial si nuestras interfaces están en sintonía con los lectores para ciegos?¿que imagen queda de la compañía si se transforma el sitio Web en compatible con personas que discapacidad motora que no pueden usar un mouse?

Y otro punto tan relevante como los anteriores: ¿cuanto tendrá que desembolsar una empresa por un estudio de accesibilidad y una posterior implementación de las conclusiones del estudio?... todo porque en la etapa de construcción el programador no encontró nada mejor que hacer que todos los enlaces funcionaran 100% solo con javascript/ajax solo porque en alguna parte leyó que hoy por hoy si no tienes javascript/ajax/jquery eres un Neardenthal tecnológico.

Cuan útil para un equipo de desarrollo Web, sería que sus programadores sepan que la Web no se trata de poner recursos tecnológicos, lineas de código solo porque se ve "bonito", porque es la tendencia o simplemente porque le pareció que al usuario le podría gustar; todo esto sin tener que "adaptar" y capacitar adicionalmente (con el costo en tiempo que significa esto) a cada nuevo programador que incluya en su equipo.

Justificación para Programación una Usable y Accesable hay muchas, y hoy por hoy estos conceptos si bien se están arraigando en el mundo del diseño gráfico, en lo que es programación/informática se está bastante atrasado. Quienes dominan dichos conceptos o los entienden en una profundidad práctica son profesionales con una experiencia considerable que han torcido sus perfiles hacia esta orientación.

No sería lucrativo, practico y beneficioso para todos que las nuevas generaciones de profesionales de la informática que quieran dedicarse al mundo Web vinieran con estos conceptos grabados a fuego desde la facultad... ¿no les parece?

PD: Resistance Is Futile

¿Por que un informático debería interesarse en el contenido?

Buena pregunta, pero vamos por partes como dijo Jack.

Primero que nada dejemos de hablar en genérico o en general para caer en las minucias de lo particular.

Así como el mundo del diseño esta dividido en varias áreas: Diseño gráfico, industrial, de vestuario, etc... tenemos también que los periodistas también tienen sus focos de especialización: reporteros, columnistas, investigadores, deportivos, espectáculos... documentalistas y arquitectos de información entre otros.

Aunque no lo crean los informáticos también tienen especialidades: los hay expertos en técnologia e instalaciones, bases de datos, programadores, analistas, arquitectos de software, ingenieros de software, soporte y jefes de proyecto.

La industria en general, tanto en empresas chicas como las que se dicen grandes... y las que lo son, te piden o mejor dicho exigen que te peines con todos los roles.

Pero la ley del equilibrio te dicta que por mucho que lo intentes para algunas cosas serás bueno y para otras no tanto.

Visto el detalle de la especialización, me centro en los programadores y los Ingenieros de Software... que para el mercado chileno son lo mismo.

¿Por que un Ingeniero de Software debería interesarse en el contenido?

Buena pregunta... por no decir la mejor volada desde que escribo este blog :p


Bueno contrapreguntemos: ¿Un arquitecto debería interesarse en como vivirán las personas de las viviendas que conceptualiza?¿Los cerebrutos que diseñaron el transantiago debieron interesarse en que condiciones iban a viajar los usuarios?¿El chef debiera interesarse en la sensación que producen sus comidas en sus comenzales?

Respondamos cada una de las preguntas:

1.- Sabemos que hay casas construidas con menos de 40 mts cuadrados donde "sobreviven" familias de hasta 8 personas... Ya, me dirán que son sociales en programa de auto construcción y bla bla bla... Pero que pasa cuando un departamento de mas de 2000 UF tiene un baño de 1,5 mts cuadrados vendido como baño de visitas... ¿ah?

2.- Cuando se lanzó el Transtortuga, con Zamorano incluido, e calculo en base a 7 personas por metro cuadrado; resultado muchas personas de edad se vieron afectadas por falta de oxigeno y mas de una fallecio producto de esto... y hasta el día de hoy moverse en hora punta es una odisea.

3.- A quien no le ha pasado, que la comida ha resultado una decepción mayuscula por resultar incipida o con exceso de condimentación?

Estos casos son homónimos a cuando el Ingeniero de software (alias maestro chasquilla profesional), trabaja sin preocuparse en como sera la experiencia del usuario con su producto. Nótese dije experiencia de usuario, lo que es válido para una aplicación de IVR, un proceso de consolidación financiero, un sitio web, una api XML para intercambiar información o una simple aplicación para el Iphone.

Si no nos preocupamos del contenido que tendrá nuestro sistema, de la forma en la que el usuario interactuará con el, de como el usuario accede a la aplicación y posteriormente a los datos. Si nos despreocupamos de una correcta Arquitectura de la Información, dejándola para el final donde eventualmente quedara mal implementada por el exceso de modificaciones que tendriamos que hacer al sistema que esta "listo"; si no nos volvemos usuarios de nuestros propios sistemas, y ojo que digo usuarios a nivel productivo porque para hacer QA es en realidad tomar unos casos de uso creados con las funciones "tipicas" que alguien imagino que podría hacer un usuario en un sistema... Perderemos el control del resultado buscado pr el sistema.

En otras palabras, cometeriamos los errores de las tres contrapreguntas hechas anteriormente.

Tener en cuenta el contenido que circulará por nuestro sistema nos permite:

1. Determinar de mejor forma la arquitectura física necesaria para brindar un servicio estable y en niveles de rendimiento adecuado.
2. Generar la arquitectura de servicios de apoyo necesarios para lograr soportar los requerimientos del sistema.
3. Generar un diseño del sistema acorde a las necesidades de nuestros usuarios y no a suposiones creadas por un Rol que finalmente no explotará el sistema.
4.  Retroalimentar el modelo circular que exijen los sistemas de aseguramiento de calidad.
5. Reducir el nivel de insatisfacción del usuario final

Suenan a muchos roles involucrados, ¿no estaremos concentrando mucho en muy pocos?

Pues nuevamente la realidad del empresariado general de Chile, y por lo que he visto en el Máster también en otros países.

Exceptuando algunas empresas especialistas donde los roles están definidos con claridad, pero que igual se tiende a la integración de dos o mas roles en un mismo individuo, se termina entregando a un Programador o ingeniero de Software la misión completa de:

1. "bajar los requerimientos del cliente a tierra", esto significa entender que quiere el cliente y tal vez si se tiene tiempo o suerte hablar con el usuario.
2. generar la documentación del proyecto
3. realizar la planificación del proyecto
4. diseñar el sistema
5. generar el producto
6. testear el producto con el usuario
7. dar soporte al producto (casi de por vida)
8. entregar la "documentación" del sistema, generalmente es un correo con las claves de acceso y uno que otro tip "tipico"

Entonces como resultado, se encarga todo a dos individuos: un Jefe de Proyecto y un programador (llamese PHP,NET,JAVA,C da igual).

Ocurre que el programador es seco para ... programar y el Jefe de Proyecto es seco (para el cafe) para gestionar y/o chicotear y cambiar en cada aparición las definiciones del proyecto.

Para ambos, incluyendo al Jefe de ambos, solo se trata de una página Web, que es un tramite y que me falta tiempo para cumplir con un acuerdo comercial que un vendedor tomó a nombre de la empresa sin preguntarle la opinión a nadie.

Entonces, si se toca trabajar bajo este esquema (que es mas común de lo que se cree, el que tanto el Jefe de Proyecto como el Programador o Ingeniero de Software esté consiente del contenido que albergará el sistema logrará que el producto resultante sea no solo de mejor calidad, sino que además le sea útil al usuario.

Y al final es de lo que se trata todo... que sea un producto ÚTIL.