Logo de La Coctelera

The Mixer

Enlaces, ideas y apuntes sobre el consumo digital.

18 Noviembre 2006

Proceso vs. Producto

Hay empresas centradas en el proceso, y empresas centradas en el producto. Lo que más me marco de trabajar en TV es que solo importa el producto final. Puedes haber trabajado mucho o poco, con tal o cual método, con cariño o sin él, pero lo único que cuenta es la audiencia del producto final. El resto no justifica un fracaso. Y a veces tampoco explica un éxito.

Las grandes consultoras de tecnología serían el ejemplo opuesto: sólo les importa el proceso. 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. 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. De hecho uno de los síntomas más claros de que se lleva mucho tiempo en una de estas empresas es la total desvinculación emocional con los productos que generas cuando trabajas ahí.

En las agencias de publicidad el producto final es tan importante que se convierte en una pesadilla. No existe proceso, solo el briefing y la fecha de entrega. Y entre ambos, el vacío. Eso permite conseguir resultados espectaculares, pero también destrozar el equipo humano, que por eso es sustituido de forma regular en todas las agencias cada cierto tiempo (como si no pasasen una ITV secreta ...)

Una de las cosas que me obsesionan en The Cocktail es hacer diseño de producto. Y muy bueno. La forma de conseguirlo ha sido pasar por una etapa donde prestábamos mucha atención al proceso (porque es dónde creas equipo, metodología y defines la sintaxis creativa y conceptual), a los entregables perfectamente diseñados, a la metodología de trabajo. Y en cuanto sentimos que estaba dominado, empezamos a romper los procesos, probar nuevas formas de trabajo, pasar del desarrollo en cascada a las iteraciones ... es decir, a pensar solo en el producto final y utilizar nuestra experiencia y conocimiento para llegar a él de la mejor forma posible de acuerdo a las características del proyecto, del equipo humano y de las restriciones del contexto. Porque a un buen cliente no debería procuparle tu forma de trabajo, sino la calidad de lo que le entregas, y si se ajusta a sus demandas o no.

El correcto proceso de trabajo es un factor de higiene, pero debería venir de serie, no ser algo diferencial. Si eres bueno en lo que haces se supone que sigues un proceso de trabajo óptimo. Pero éste no es tu motivo de existencia.

Estar centrado en producto implica también una forma diferente de hablar de uno mismo. Hace un par de años contábamos nuestras fases, enseñábamos entregables, cvs del equipo y metodología. Ahora enseñamos resultados obtenidos, productos hechos por nosotros que han alcanzado objetivos y cosas que hemos hecho que nos gustan.

En esta profesión muchos se enamoran de sus entregables, de los ppts llenos de frases inteligentes y de prototipos que luego no se parecen nada a lo que aparece en la web. Pero la verdad es que en diseño de interacción lo único que importa es precisamente la interacción final que el usuario tenga con tu producto. Y ya está.

Nota para historiadores: Las empresas que desarrollaron la Web 1.0 se centraban en el proceso (desarrollos en cascada largos, integraciones complejas, plataformas enormes ...); las que hacemos la Web 2.0 nos centramos en el producto final (sin documentar y utilizando el software funcionante como única medida de progreso). Por eso a las grandes empresas les cuesta tanto estar en el 2.0 Porque supone un cambio total de mentalidad.

servido por Alberto 21 comentarios compártelo favorito

21 comentarios · Escribe aquí tu comentario

Carlos Manuel

Carlos Manuel dijo

A tu frase:

"De hecho uno de los síntomas más claros de que se lleva mucho tiempo en una de estas empresas es la total desvinculación emocional con los productos que generas cuando trabajas ahí."

Respondería que el enfoque de diseño de producto sólo puede funcionar si hay alineamiento en lo que es un producto. Las empresas "de proceso" sólo crean sistemas bastardos dominados por comités políticos o por la tecnología.

19 Noviembre 2006 | 10:36 PM

Martín Fernández

Martín Fernández dijo

En ocasiones, el fin justifica los medios... o no?

20 Noviembre 2006 | 02:06 PM

macadamia

macadamia referenció

Proceso vs. producto

Sin que sirva de precendente, y sólo por esta vez, voy a recomendar un articulito del Prof. Knapp: Proceso vs. Producto. Y lo recomiendo porque me consta que es verdad todo lo que dice...

20 Noviembre 2006 | 06:25 PM

torresburriel

torresburriel dijo

De acuerdo en que la metodología 'per se' no soluciona las necesidades del cliente. Pero la metodología, estrictamente seguida, si se entiende su por qué, debe inyectar el compromiso necesario en el equipo que asegure tener siempre presente el producto.

Desde mi experiencia. Corta, pero mia :-)

20 Noviembre 2006 | 07:45 PM

Juan Manuel Caicedo

Juan Manuel Caicedo dijo

De acuerdo con la entrada, excepto con la última parte.

Me parece que la relación entre las versiones de la web (sea lo que eso signifique) y los dos modos de trabajo es, de cierto modo, arbitraria. Es probable que sea cierta, pero no por por las razones que se mencionan.

En primer lugar, hay varios contraejemplos de lo que mencionan. Hace unos años trabajé en varias empresas '1.0' que se centraban más en el producto que en el proceso, ya sea por los plazos cortos que existían en los cronogramas (y, por tanto, la necesidad de entregar algo) o porque la novedad del desarrollo web impedía integrarlo con una metodología/proceso de desarrollo de software más 'tradicional'. Por lo que conozco, mi caso no era propiamente una excepción, sino más bien una regla.

Por otro lado, como la mayoría de los sitios 2.0 son hechos por grupos pequeños que se dedican _sólo_ a eso, pues lo más natural es que trabajen centrados en su producto. Sin embargo no veo la diferencia con las empresas 1.0, la mayoría de las punto-com también eran pequeñas que dedicaban su tiempo a su (único) producto, ¿no?.

Ahora bien, el único punto en común que encuentro entre la web 2.0 y la manera de trabajar es la constante actualización o "Release Early, Release Often", como dicen en el software libre. ¿Esta 'agilidad' es exclusiva del diseño orientado al producto o se puede conseguir también cuando se lleva un proceso de desarrollo más ligero?

Me queda una duda acerca de la falta de documentación en el modo de trabajo centrado en el producto ¿de qué tipo de documentación se está hablando? ¿de la documentación de la metodología o del software? Tal vez al enfocarse en el proceso la documentación se convierte en papeleo innecesario y burocracia, pero no veo por qué su ausencia deba ser algo característico del trabajo centrado en el producto.

Finalmente creo que en este caso la metodología de trabajo y el tipo de producto que se desarrolle pueden ser, más o menos, independientes.

20 Noviembre 2006 | 08:48 PM

Lucas Rodriguez Cervera

Lucas Rodriguez Cervera dijo

Estoy de acuerdo en que no se debe perder el foco del producto y obsesionarse con el proceso, pero también creo que ha habido un movimiento pendular excesivo y ahora se tiende a demonizar el proceso.

Yo creo que todo pasa por trabajar con procesos que se adecúen a las características del producto que deben generar. Por lo tanto para una aplicación Web 2.0 puede ser adecuado un proceso ágil definido a grandes trazas y para una aplicación crítica para un banco un proceso más estricto, detallado y controlado.

20 Noviembre 2006 | 11:56 PM

Tripix

Tripix dijo

Destaco una cosa de este post... en The Cocktail teneis un enfoque más centrado en el producto pero, tal y como dices, y esto es lo importante, después de haber pasado una fase en la que estabais centrados en el proceso.

Sin asumir y haber mamado a fondo esa primera fase dudo que un equipo de desarrollo pueda sobrevivir y llegar a centrarse en el producto final. Podeis hacer eso ahora que, probablemente, habeis interiorizado y automatizado una metodología de trabajo.

Ahora se entrará en la polémica uno vs otro y hablaremos mucho... pero no se llega ser capaz de centrarse en el producto sin haber pasado por el rigor metodológico.

21 Noviembre 2006 | 08:36 AM

César Astudillo

César Astudillo dijo

¿ proceso = 1.0 = esclerosis
producto = 2.0 = talento ?

un poco esquemático, ¿no? Suena más a eslógan que a hipótesis.

Seguro que en TCK usáis metodología y proceso por un tubo. Será orgánico, será flexible, estará más en vuestras cabezas que en especificaciones escritas, pero haber metodología, habrála.

Creo tanto en ti que a veces no me creo lo que dices :-D

21 Noviembre 2006 | 10:38 AM

Agustín Casado

Agustín Casado dijo

Sospecho que con un equipo de 50 personas, sin metodología no hay producto

21 Noviembre 2006 | 11:21 AM

sasa eh

sasa eh dijo

Creo que está contemplado en algunos de los comentarios, pero ahí va mi parte.

El primer error, a mi entender, es considerar enfrentados Proceso y Producto. Si en lugar de "Proceso vs. Producto" se titulara "Proceso >> Producto", i.e., que el Proceso nos lleve al Producto, seguramente el artículo habría quedado diferente.

No voy a meter a las consultoras, que son harina de otro costal, pero a la hora de definir y conseguir un Producto, en el que puede participar gente muy variopinta y que puede estar entrando y saliendo del proyecto, más vale que exista método y metodología, porque si no vamos a ir listos.

Si lo que comentas es que la metodología te está impidiendo centrarte en el producto, lo más probable es que uses una metodología inadecuada o simplemente no la estés aplicando bien.
Inventa, adapta, trapichea... lo que quieras, pero es mejor asegurarse de que todo el mundo conoce los pasos a dar y la forma de darlos. De nuevo, si tardas más en crear un documento explicativo que en 'pensarlo' es que algo falla.

P.ej. si tardas 2 días en hacer un prototipo con la herramienta X, échale la culpa a la herramienta, elige otra, hazlo en papel, pero no "pases" de hacer el prototipo... porque ese prototipo es parte del Proceso que lleva al Producto.

21 Noviembre 2006 | 08:29 PM

alberto k.

alberto k. dijo

No me expliqué con claridad: el proceso (metodología) es vital, pero jamas debe ser más importante que el entregable final.

Y ponía como ejemplo cierto tipo de consultoría, que ha perdido su razón de ser por prestar más atención a la gestión del proceso que a la calidad del producto final.

Pero, obviamente, solo con una buena metodología puede garantizarse un buen nivel de producción.

22 Noviembre 2006 | 08:40 AM

Hernan

Hernan dijo

No entiendo cuando se habla de las bondades de Procesos y Productos como si fuesen intrínsecas a los mismos: yo opino que más bien vienen determinadas por el talento de quienes los crean.
Por otra parte, no creo que un buen producto pueda salir de un mal proceso, ni que un buen proceso pueda dar lugar a un mal producto.
Además, en ocasiones podemos considerar que el proceso es en sí mismo un producto: es el caso de muchas consultoras, empresas que buscan una certificación de calidad "únicamente por el sello", o muchas empresas que trabajan para terceros. Muchas veces, en la práctica, lo que estas están "vendiendo" es un modo de trabajar más que el "producto" en sí mismo.

22 Noviembre 2006 | 11:29 AM

Ana Álvarez

Ana Álvarez dijo

Una (GRAN) consultora con la que trabajé en un proyecto (como cliente), al hacer el control de calidad final, nos obligaba a rellenar unos impresos de "Incidencias" con N campos de texto:
Titulo de la incidencia, ID, Departamento, Persona que lo solicita, Descripción, Solución, Prioridad.

Sólo podía hacerse en esos impresos, osea, en papel. Luego se remitía a una persona encargada de archivarlos, ordenarlos e insertarlos en un excel. A su vez, esta persona recibía por parte del equipo técnico las prioridades en soluciones, rellenaba una nueva hoja (en papel) con estas consideraciones y comentarios y volvía a remitirlo al emisor inicial (a mi) quien, a su vez, procedía a contestar (en papel) y así sucesivamente.

Resultado: Después de rellenar cientos de hojas de incidencias se te pasaba por la cabeza mandar el producto final al carajo.

Moraleja: Una metodología tan mal planteada sólo sirve para ver cada vez más lejano el producto y, con ello, acrecentar la consiguiente desmotivación.

23 Noviembre 2006 | 01:20 PM

Alejandro Andre

Alejandro Andre dijo

Simplificacion, simplificacion! Hay multiples ejemplos de casos en los que refugiarse en un proceso considerado bueno es un error, si se pierde de vista el resultado que se pretende obtener.

Pero que me enseñen un solo producto que no haya sido confeccionado sin un proceso más o menos formal. Hasta los pintores, escultores y artesanos tienen su método.

Es una cuestion de aplicación, no de concepto.

24 Noviembre 2006 | 01:50 PM

Ariel Guersenzvaig

Ariel Guersenzvaig dijo

Que me enseñen un sólo *gran* producto producido de acuerdo a los métodos de dinosaurio con corticoides que se crítican en el post!! Al menos un ejemplo donde a partir de un proceso formal dogmático seguido a rajatabla, se haya llegado a lograr un *muy buen* producto. Con uno me conformo.

El proceso es un factor higiénico, obviamente debe haber un proceso, al fin y al cabo se trata de un proyecto donde hay que tomar una serie finita de decisiones. Pero no puede primar por sobre el producto final, el proceso es un medio.

28 Noviembre 2006 | 06:38 PM

alberto k.

alberto k. dijo

totalmente de acuerdo !!! eso es lo que quería decir ;-)

28 Noviembre 2006 | 07:08 PM

Ivan

Ivan dijo

Miremos a otras ingenierías más maduras, ¿cómo lo hacen?. Por ejemplo, pensemos en un fabricante de coches (producto) y su cadena de producción (procesos/metodología)....

29 Enero 2008 | 10:45 AM

Alejandro

Alejandro dijo

Ivan, la comparación no me parece buena, por mucho que sea la más habitual. Cada producto software es único, es decir, no tenemos cono en la fabricación de coches (o aviones) la Design phase (diseño) y la Series phase (producción), sólo la primera de ellas.

A mi me gusta más comparar con la construcción de casas. Cada una es única, aunque se hagan urbanizaciones en serie basándose en los mismos planos. Y en este caso la metodología ayuda al diseño, pero para la fabricación hacen falta albañiles (y muchos).

Ariel. Un ejemplo: El Airbus 380.

1 Febrero 2008 | 11:47 AM

Escribe tu comentario


Sobre mí

Avatar de Alberto

The Mixer

Madrid, España
ver perfil »
contacto »
El blog de Alberto Knapp Bjerén.

Sobre diseño de interfaz, consumo, tendencias y modelos de negocio, por ejemplo. Un archivo público de mis Favoritos.

Trabajo en The Cocktail, empresa creadora de la herramienta que hace este blog posible. Si quieres saber más, busca.

Joost™

Buscar

suscríbete

Selecciona el agregador que utilices para suscribirte a este blog (también puedes obtener la URL de los feeds):

¿Qué es esto?

Crea tu blog gratis en La Coctelera