20 noviembre 2006

A través de Macadamia llego a un post de Alberto Knapp que se titula Proceso vs. Producto. Un texto que habla, según entiendo, de la vivencia profesional del autor respecto del hecho de trascender la metodología de trabajo para ahondar en la implicación del equipo en el producto, de tal modo que éste responda a las expectativas del cliente. Todo ello, claro, hablando de diseño de interacción y producción para internet.

No voy a ser yo quien se atreva a poner en duda total lo que se dice en el texto, pero sí que me gustaría exponer mis puntos de vista respecto de algunas de las cosas que allí he leído.

Por ejemplo, cuando se habla de la metodología como referente en el desarrollo de un proyecto, se dice:

El otro día un cliente de una de esas empresas nos contaba que para hacer un site tenía que ir aprobando entregables, cumplimentando requerimientos de cambios, y avanzando por un proceso que prima sobre el producto final. Al final obtuvo un site que no responde a lo que quería, pero justificable desde la metodología y proceso de trabajo seguido. Es decir, el proceso fue el correcto, y el producto no.

Pues sí y no. Sí desde el punto de vista en el que, efectivamente, el seguimiento de una metodología de trabajo está basado, por ejemplo, en la aprobación de una serie de entregables. Pero esa aprobación no hay que olvidar que es un evento bidireccional. Es decir, tanto el proveedor como el cliente acuerdan aprobar tal o cual entregable. Se entiende, por tanto, que ese entregable cumple y satisface los objetivos que en ese punto se han marcado ambas partes.

Si no es así, o no ha habido consenso, o algo falla en la metodología.

Porque un producto final no puede, desde mi punto de vista, cumplir con unas normas metodológicas que, seguidas y controladas en todas sus fases, impidan llegar a un resultado que cumpla con las expectativas del cliente. De nuevo, si no es así, algo está fallando: ya sea en que se está trabajando sobre consensos falsos, o ya sea porque las fases planteadas en la metodología contienen algún fallo en su diseño.

El texto avanza:

Son empresas con jefes de proyecto (no de producto, ja!) dedicados a gestionar la administración del trabajo, de tal forma que nadie en el equipo se siente responsable del producto final.

Esta afirmación contiene una trampa en sí misma. Se está asumiendo que los jefes de proyecto son roles que sólo se preocupan de la gestión y el control del proyecto. Pero si recordamos que el proyecto sigue una metodología, aprobada, consensuada y diseñada para alcanzar los objetivos de cada proyecto que la siga, habremos de concluir que el papel del jefe de proyecto, por muy desvinculado que esté del producto, deberá contemplar, sí o sí, el aseguramiento de que se el proceso se ciñe a la metodología. Por lo tanto, esa falta de responsabilidad en el equipo de la que se habla estará provocada no por el rol que ejerza el jefe de proyecto, sino más bien, de nuevo, por un defecto en el diseño de la metodología. Otra cosa sería que hablásemos de un defecto en el trabajo del jefe de proyecto, momento en el que sí que cabría hablar de él y de que su falta de diligencia profesional puede acarrear un defecto en el producto.

Pero aún así, si la metodología está bien construida, deberá contener los elementos necesarios que aseguren que los procesos intermedios están controlados por roles que no sean el jefe de proyecto.

Estoy, sin embargo, muy de acuerdo en que cuando el equipo ha asimilado perfectamente la metodología, ésta puede verse alterada, o modificada en forma de puntos flexibles que ayuden a pulir los aspectos que en un momento dado puedan encorsetar el proceso de trabajo, y que faciliten y promocionen la implicación emocional del equipo. Por supuesto que sí. Pero de ahí a etiquetar la metodología como elemento contrapuesto al producto me parece que va un trecho.

Como he dicho en un comentario en el citado post de Knapp, esta es mi experiencia. Corta, pero mía 🙂

En Torresburriel Estudio te ayudamos en el proceso de diseño de servicios digitales mediante tests con usuarios, planteando propuestas de solución en base a los resultados del test. También podemos formar a tu equipo mediante una formación in company, para que apliquen metodologías de diseño centrado en el usuario en el día a día de su trabajo. Contacta con nosotros y cuéntanos tu proyecto.

Comentarios

  1. ¿Corta tu experiencia? Me parece que tienes las cosas muy claras.

    Bajo mi punto de vista, el problema en estos ámbitos de tecnología siempre es el mismo: seguimos pensando en tecnología, no en personas.
    Poca gente llega diciendo ¿qué necesita Vd. ? y después, ¿ se adapta mi solución a sus problemas ? sino que llegan como un elefante en una cacharerría y te adaptas o mueres…

    La metodología sólo puede arrancar desde ese punto. ¿ Por qué descuidar a aquellos que van a determinar el éxito de tu proyecto ? Como dice Kathy Sierra, hay que crear usuarios apasionados. La metodología es muy importante para realizar las cosas con unos estándares aceptables en calidad, presupuesto y plazos, pero nunca nunca debería supeditarse al producto final.

  2. […] En su post, Alberto Knapp comenta la diferencia de los “m©todos centrados en el proceso” frente a los “m©todos centrados en el producto” (incluyan Usabilidad o no)y Daniel Torres Burriel le responde Metodolog­a, proceso y producto. […]

  3. […] que comentaba un poco más arriba: Si bien es cierto, que lo es, que la tesis que mantengo en metodología, proceso y productose apoya en el seguimiento de una metodología de trabajo como factor asegurador del éxito de los […]

  4. […] de este blog, en un mundo en el que el trabajo profesional nos empujaba a pensar en las personas y pensar en los proyectos. Y de una forma casi progresiva nos encontramos hablando ya no sólo de usabilidad, sino de […]

En Torresburriel Estudio desarrollamos las capacidades técnicas de tu equipo en temas de usabilidad, experiencia de usuario y diseño de producto a través de nuestros cursos online y presenciales.