Grancomo

¿Puede la metodología perjudicar un producto? Definitivamente, sí. Y es que, a veces, directamente no hay producto. Pero, ¿porqué tiene que haberlo siempre?

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.

En este post, voy a comentar mi perspectiva basada en experiencias pasadas (que como sabéis no garantizan la fiabilidad de las futuras). Y de paso discrepar un poco de mi jefe en directo, que es lo que le da la gracia a esta Gran Corporación.

Lo primero: no demonicemos. Ni uno ni lo otro son malos per se, sólo es necesario saber cuándo conviene un enfoque u otro. Creo que lo de la Web 2.0 y los Getting Real de 37 Signals están haciendo daño cuando se aplican en entornos inadecuados, a.k.a. “mundo real”.

Empresas de proceso y Empresas de producto

Las empresas de servicios suelen ser un reflejo de sus clientes, y como tales, se adaptan a sus necesidades, adoptan sus formas de trabajo, códigos y desarrollan y aplican métodos para trabajar con ellas. Pocas tienen la capacidad de “moldear” a sus clientes.

Tradicionalmente, las áreas de tecnología son empresas dentro de empresas. Con la adopción de tecnologías de la información por las grandes organizaciones han ido cobrando un protagonismo decisivo en el funcionamiento de las compañías, creciendo, subcontratando personal para nuevos proyectos y el mantenimiento de los sistemas que hacen que la empresa funcione. Sus objetivos “de negocio” son optimizar procesos, ahorrar costes de operaciones a la compañía en un entorno seguro, fiable y de alta disponibilidad.

Como resultado, hacer un proyecto para la misma empresa cambia notablemente si se aborda como proveedor de un área de negocio frente a un área de tecnología. Y así sucede, que las grandes empresas de tecnología sirven a objetivos de negocio diferentes. Lógico.

Así, en banca online, mientras un área de negocio tiene como objetivo aumentar sus clientes y el valor de los mismos, el área de tecnología tiene como objetivos la seguridad, el rendimiento, la disponibilidad y optimizar costes de desarrollo y mantenimiento, ah, y quedar bien en “el índice de los robots”: AQMetrix. La consecuencia lógica es que la tecnología puede ser un “no a todo por defecto” convirtiéndose en una losa para el negocio. ¿Cuál es la explicación? Que aunque lo lógico parezca “todos vamos dentro de un mismo barco” dentro de una misma empresa, en grandes organizaciones, no hay nada más lejos de la realidad.

Un ejemplo:la usabilidad aplicada al proceso vs. producto

El enfoque cambia depende de para qué área trabajes. Mucho.

Usabilidad en áreas de tecnología y sistemas: lo que denominamos usabilidad desde el lado de la tecnología no es tal. No nos engañemos. Es un método para controlar el desarrollo, ahorrar en costes, complementar los análisis funcionales y comunicarse mejor con áreas que no son tecnológicas. Y como fin último, la industrialización del desarrollo: crear Guías de Estilo (que nadie lee), patrones y estándares para integrar en un proceso de desarrollo industrial (o aquello del “valor añadido” que no queda muy claro). Del usuario se habla en tercera persona. No hay producto, sino procesos.

Usabilidad en áreas de negocio: aquí cambia, porque un área de negocio puede ser un área de Recursos Humanos, cuyo proyecto suele ser un portal de empleado que ahorre costes administrativos y de comunicación mediante el autoservicio por parte de los empleados; de Márketing quienes pueden crear un sistema que permita hacer llegar su producto al mayor número de clientes posible y generar ingresos; un equipo de comunicación, que persigue estar más cerca del mercado y de la sociedad o uno de atención al inversor, que debe cumplir normativa legal relacionada con la transparencia.

En estos casos, la usabilidad si no se enfoca adecuadamente en cuál es el verdadero valor para el negocio, corre el riesgo de convertirse en diseño y política: cumplir objetivos que van no se dirigen al usuario o cliente como adaptarse a leyes y normas, salir en prensa.

Cuando se trabaja con empresas grandes y áreas con intereses tan contrapuestos es muy difícil hacer producto, cuando se trabaja con áreas de tecnología es casi imposible: demasiadas personas, factores y limitaciones (porque en las grandes empresas, la tecnología actúa como límite). En estos casos, la metodología debe basarse en la planificación, ser “predictiva”, con una partitura clara y definida y es un camino para asegurar que se cumplen los requerimientos de todos los implicados muchas veces con intereses contrapuestos.

Métodologías centradas en el proceso, el usuario, el jefe, la tecnología

¿A quién pensamos agradar realmente cuando hacemos un proyecto? Medio en broma, medio en serio se dice que “la metodología es para el que no sabe”. Sí y no. Hay que saber cuándo prescindir de ellas y usar la intuición.

Una anécdota: un responsable de negocio de una gran empresa, al que le han encargado “vender un 20% más durante el 2007″, comentaba lo difícil que es trabajar con su nuevo proveedor de tecnología, una empresa grande experta en sistemas. Sus reuniones y el coste administrativo que le estaba suponiendo el proyecto, que seguía una “metodología rigurosa, exitosa y comprobada” (que incluía usabilidad) les estaba haciendo perder el foco último del proyecto y su intención de implantarles “esa solución de CRM” conectada a “esa solución de gestión de contenidos” argumentada como una solución a sus problemas de negocio, no le convencía: los argumentos que daba el proveedor eran los que les gustaría oir a un responsable de su área de tecnología.

No era sólo el enfoque lo que le preocupaba, sino el tono de trabajo de carácter “militar” ejecutado por un grupo anónimo de consultores bajo la supervisión de un jefe de proyecto que no hacía más que generar voluminosos entregables que había que “aprobar en plazo” sin estar seguro de comprender la jerga empleada para que el proyecto avanzara.

Preguntaba: ¿y qué pasa con mis clientes? ¿Para qué quieren ellos un CMS o un CRM o un ERP?. Y es que al final, estaba empleando procesos para diseñar procesos que automatizaban procesos. Pero “el producto” no existía, y en parte, no tenía que existir: crear esos procesos era clave, pero se olvidaban del contacto con el cliente.

Pero es que era así: para ganar esa guerra necesitaba por un lado la acción de un ejército preparado para largas marchas y asedios compuesto por veteranos y novatos, delgados, gorditos, torpes, eficientes pero bien dirigidos (son procesos críticos y pesados que se ganan por volumen) y por otro, la agilidad de un comando ágil y eficiente con misiones claras, bien entrenado y de confianza (el producto se gana por innovación e ideas). Misiones diferentes, equipos diferentes. (Y 37 Signals está en este segundo “mercado”, no te dejes fascinar).

Centradas en el proceso: Predecibilidad, minimizar costes y riesgos

El objetivo es controlar el proyecto, su alcance, costes. Que el proyecto “no se vaya”, porque todos los elementos juegan en contra del producto final. Organizaciones desalineadas entre sí por motivos políticos, saturación de trabajo de los implicados, desconocimiento (normal) de las posibilidades de la tecnología, ineficiencias de la organización, ecosistemas tecnológicos complejos.

Aquí, la planificación y metodología sirven (y mucho) para detectar y minimizar riesgos que amenacen el buen fin del proyecto y se contemplan aquellos pasos necesarios para terminar en presupuesto y plazos con un mínimo de calidad. Y todo en un equipo grande con perfiles diferentes en experiencia.

Orientación a producto: adaptividad, agilidad, maximizar valor

El valor está en el resultado final deseado: porque empieza por ahí. El argumento es dotar a las áreas de negocio de armas de seducción para que sus usuarios se conviertan en satisfechos o apasionados, dar a las áreas de sistemas material y criterios para desarrollar los productos de manera que se adapten y satisfagan a los clientes, razón última de ser de una empresa. La tecnología viene después (si se deja).

Pero trabajar en producto depende mucho de la cultura y organización del cliente, así como su cercanía a su mercado de la experiencia del proveedor y de la confianza que haya en él. En este caso, la comunicación, entender que el objetivo último es maximizar el valor a través de la experiencia de usuario (no de procesos internos).

En resumen:

Estamos en el clásico debate de organizaciones tecnocéntricas y aquellas centradas en el cliente. Hay que comenzar por el verdadero valor para tu negocio, puede no ser diseñar un producto, sino mejorar un proceso.

La metodología no asegura los resultados, sólo ayuda. Si no hay comunicación y alineamiento entre equipos del proveedor y cliente no hay metodología que salve un proyecto.

Pero hay algo que no cambia: si no es bueno para tus usuarios, no es bueno para tí: es muy diferente decir que no por no estar dentro del alcance de la propuesta que decir que no porque no es bueno para el producto.

Nota final: sí. Me he dedicado a trabajar en procesos de día y productos por la noche y prefiero lo segundo.