De esto me temo que podemos estar hablando años para finalmente no llegar a ninguna parte, y como siempre me ha gustado meterme en jardines de los que es jodido salir pues ahora voy y entro al trapo.
De todas formas y por si alguien quiere ahorrarse este rollo hago el siguiente resumen: producto = un conjunto de procesos adecuados finalizados con éxito Y ahora el rollo: Personalmente tengo una cosa muy clara, y es que para construir un producto hay que pasar por una serie de procesos. Éstos formarán parte de una metodología más o menos pesada o ligera - desde eXtreme Programming hasta METRICA 3 - y serán llevados a cabo de una manera más o menos concienzuda, pero vamos, que plantearse un desarrollo sin basarse en una serie de procesos es algo que está por ver. Otra cosa muy distinta es cómo afronte una empresa los proyectos y cómo aligere la carga que inevitablemente los procesos depositan en los individuos. Una empresa podrá optar por centrarse en el producto final y pasar los procesos por encima y otra podrá centrarse en seguir a rajatabla los procesos metodológicos y confiar en que finalmente obtengan el producto deseado. A mi me da tanto miedo una empresa como la otra. Como siempre en el término medio encontraremos la virtud. Prefiero contar con una empresa que sigue los procesos aunque sólo sea a modo de Mapa de Ruta, que documenta lo necesario, ni más ni menos, y que siempre, repito, siempre tenga en mente que al final del camino lo que tienen que crear es un producto. Lo que nos aseguramos siguiendo una serie de procesos es un control sobre lo que estamos haciendo y esto es muy importante en cualquier proyecto. Y esa importancia es directamente proporcional al tamaño del proyecto. Para mí sólo hay una forma de hacer una intranet repleta de funcionalidades con enganches con SAP y Meta 4, con algunos contenidos que tienen que estar en SharePoint y otros en FatWire y que además esa intranet sirva informes estratégicos en tiempo real que utiliza una Dirección General para tomar decisiones en mercados continuos. Seguir escrupulosamente los procesos que estén definidos en la metodología de desarrollo. Y si en este proyecto no empleas una metodología relativamente pesada, amigo mío estás vendido. Y aquí podemos comenzar a hablar del cliente, y es que como creo que ya se ha mencionado antes, no es lo mismo que el proyecto lo lidere Comunicación que RRHH que Sistemas. Pero eso no debe alterar la esencia de la metodología (o metodologías) que empleemos, alterará sin duda el resultado final, pero si hemos hecho las cosas bien tendremos un producto bien balanceado (servirá como herramienta de comunicación, cubrirá las necesidades de RRHH y de los empleados y será fiable, escalable, seguro....). Pero aquí nadie debe perder de vista algo que se suele olvidar y es que la tecnología en una empresa está al servicio del negocio (salvo empresas de IT) y no al revés. Otra cosa es qué procesos se estén manejando y sobre todo, cómo se estén manejando. No puedes pedirle a un Director de Arte que haga un análisis funcional de la misma manera que no puedes pedirle a un Analista que haga una propuesta de Look & Feel. Y desde luego que si no cuentas con uno o varios procesos que impliquen a los usuarios en el desarrollo de esa intranet no puedes esperar que tu producto cubra sus necesidades y mucho menos sus expectativas. De todas formas el problema yo creo que está muy por encima de todo esto, y es que en la mayoría de los casos el cliente no es consciente de que está creando un producto - digital, virtual o como quieras llamarlo, pero producto al fin y al cabo -. Para intentar paliar esto, nosotros en proyectos complejos con mucha carga de HCI incluimos una figura que denominamos "Consultor de Definición de Producto" cuya misión no es otra que: - Ayudar a que el cliente tome conciencia de que está construyendo un producto - Definir el producto como tal - Velar por la integridad del producto resultante Esta figura siempre acaba siendo la mano derecha del Jefe de Proyecto ya que éste suele desconocer nuestros ámbitos de actuación y le resulta de gran utilidad tener a una persona que coordina los trabajos de: - Diseño de Interacción - Arquitectura de Información - Look & Feel - Desarrollo gráfico - Programación de Interfaz (aunque aquí el Jefe de Proyecto ya comienza a enterarse de algo) - Interlocución con cliente en caso de no provenir de Sistemas ¿habéis presenciado alguna vez una reunión entre un responsable de Mk o Comunicación y un Jefe de Proyecto de una empresa puramente tecnológica? es algo digno de ver y sobre todo de escuchar. Un saludo y perdón por el tostón desestructurado, Sacha. _______________________________________________ altas, bajas y modificaciones: http://www.cadius.org/lista/opciones.html
