Diseño de la Propuesta de valor

Es interesante ver como modelos y herramientas que tienen su origen en el “negocio” se adaptan a nuestra forma de descubrir, diseñar y probar la viabilidad de productos de software. 

Entre el cliente, inversor, usuario (interesado en general) y quien diseña y crea la solución, comienza a surgir un lenguaje común a través de modelos visuales que son comprendidos y compartidos por ambos. 

La intervención cada vez más importante de aspectos que ya no son sólo funcionales, sino emocionales –social y personal– que la solución debe contemplar es también un desafío para quien explora y diseña nuevos productos y servicios.

Nada de esto es nuevo, simplemente que ahora la tecnología y la inundación de propuestas que recibe el interesado nos lleva a la “nueva normalidad”: mejor, más barato, más rápido, más pequeño, más conveniente, más personalizable, hace que sea mucho más necesario tener estos temas en cuenta. 

Vamos despidiéndonos del famoso "usuario cautivo" de décadas atrás para construir soluciones para las personas que pueden elegirnos a nosotros o a otros. 

Ganará el mejor, quien comprendió más íntegramente los trabajos para los cuales el cliente "contrata" nuestro producto. 

Ya en la entrada de este blog Value Proposition Design - Comentarios sobre el nuevo libro de Alex Osterwalder comenté acerca del contenido del modelo propuesto por el autor.

Ahora, en la presentación más abajo mostrada amplío la descripción del modelo con algunos de los pasos que este recorre y las herramientas que utiliza.

Value proposition design (brief presentation of A. Osterwalder new model) from Raúl Martínez

Las láminas 15 y 17 del pdf corresponde a este video: https://www.youtube.com/watch?v=NMacTuHPWFI

Espero sea de utilidad y genere en Uds. inquietud y curiosidad para seguir explorando.

Saludos,

Raúl

@RaulMartinez582

¿Encajar una pieza cuadrada en un hueco redondo? El Jefe de Proyecto y la Organización no orientada a proyectos

Varios de Uds. se habrán encontrado con este tema. Yo también.

¿Es posible desarrollar una organización por proyectos, práctica de Administración por Proyecto, el rol de Jefe de Proyecto, en una Organización no orientada a proyectos?

¿La típica matriz es viable en estas organizaciones?

¿Se puede asignar responsabilidad sin dar autoridad?

Organizaciones no orientadas a proyecto

Las organizaciones funcionales típicas, no orientadas a proyecto, y presentes en gran cantidad de empresas, representan a primera vista, como explica Kerzner⁽¹⁾, un desafío para desarrollar la práctica de Administración por Proyectos y el rol del Jefe de Proyecto.

Como lo demuestran la teoría y la práctica 

• Las personas residen en las áreas funcionales que llevan adelante la producción, cada uno con una serie de tareas asignadas normalmente por especialidad.
• Los proyectos son disruptivos en esta rutina ya que reasignan los recursos hacia otras actividades.
• Si bien los proyectos implementan la estrategia de la Compañía en áreas de interés, la producción es lo que la mantiene operando y genera los ingresos del día a día. De allí podrían provenir los primeros problemas de prioridad.

¿Qué inconvenientes se presentan con los proyectos en este tipo de organizaciones?

• El ya conocido problema de los silos funcionales.
• La inexistencia de la visión de proyecto como un todo con un objetivo único, o la visión del mismo a través de los silos funcionales, con sus objetivos particulares.
• La posible demora de las tareas del proyecto en estos silos, debido a prioridades sobre los recursos, en conflicto con las tareas funcionales ⁽²⁾ . 
• Priorización del día a día sobre el calendario del proyecto (la producción tiene urgencias que no pueden esperar y el proyecto aún no las vive y se cree que las puede recuperar).

¿Qué problemas se presentan con el rol de Jefe de Proyecto?

• El rol del Jefe de Proyecto es muchas veces informal.
• Es un trabajo de tiempo compartido. Un Jefe de Proyectos administra 7 proyectos (¿son proyectos?).
• Tiene escaso o nulo control del presupuesto del proyecto. 
• Tiene poca o ninguna autoridad sobre la asignación de recursos (el típico “el equipo ya me llega armado”). 
• Tiene en general poca autoridad debido a su posición en la estructura, en muchos casos subordinada a los mismos jefes funcionales que deben asignarle las personas. 
• Los responsables de las áreas funcionales tienen poca voluntad para aceptar la autoridad del Jefe de Proyecto.

 Pero… ¿En qué casos una Organización no orientada a proyectos necesita trabajar por proyecto?

Una pregunta interesante es por qué necesitaríamos esta organización, si puede traer tantos inconvenientes.

Un buen resumen ⁽³⁾ confirmado por la práctica es el siguiente:

• Al desarrollar un tema nuevo, debe intervenir más de un área de la Organización, siendo crítico que trabajen coordinadas, por ejemplo, el rediseño de un sistema central a la empresa con nuevas tecnologías y criterios de calidad más estrictos, el desarrollo de nuevos procesos, la instalación de un ERP que cambiará la forma de operar de la Compañía, u otros casos similares. 
• Cuando hay dudas acerca de la conveniencia de una tecnología y conviene probar en un ambiente controlado (el del proyecto). 
• Cuando hay restricciones económicas o de recursos importantes para desarrollar una nueva idea, que exigen un estricto control de estas variables. 

Como vemos, estas pueden no ser tareas rutinarias en las organizaciones.

Finalmente… ¿Podremos hacer encajar las piezas?

Las siguientes ideas tratan de ayudar a aclarar algunos de estos temas, a evitar que el rol de Jefe de Proyecto esté “pintado” en la Organización y también a que se comprenda el sentido de la organización "proyecto":

• No engañarse y aceptar que no todo emprendimiento es un proyecto ni puede organizarse como tal. Llamar a algo proyecto, no lo convierte en uno.
• Tener en cuenta que la organización por proyecto puede convivir con la funcional para cierto tipo de emprendimientos, por ejemplo como los mencionados en el apartado anterior. 
• Si se encara esta organización de proyecto, formalizar los roles a través de definir su autoridad y responsabilidad, pudiendo incluirlo en el Plan de Carrera o su equivalente.
• Ubicar el rol de Jefe de Proyecto en la estructura de modo tal que acceda a los mismos niveles de decisión que los Jefes Funcionales, ya sea en forma directa o a través de un sector que los agrupe.
• Capacitar en la práctica de Administración de Proyectos.
• Comunicar, comunicar y comunicar a todos los interesados la idea de este tipo de organización, el rol del Jefe de Proyecto y la práctica de Administración de Proyectos.
• Evitar en todo lo posible la continua injerencia de los Jefes Funcionales en los trabajos del Proyecto y sobre las personas asignadas.
• Asignar la responsabilidad completa del Proyecto al Jefe de Proyecto y la correspondiente autoridad.
  
• No desperdiciar el nombre "Jefe de Proyecto", si no lo es. Hay alternativas que proponen la literatura y la experiencia que definen mejor la posición. "Coordinador de Proyectos", "Asistente de Proyectos", etc..Es muy común sobre todo en empresas y proyectos de tamaño importante una multitud de “jefes de proyecto”, algunos cuya labor es el registro administrativo de las variables del proyecto (fundamentalmente tiempo, costo y alcance) pero sin decisión sobre ellas. Es decir efectúa el seguimiento pero las actividades de control y decisión de cambios está fuera de su responsabilidad. Convendría entonces revisar los nombres para no crear confusión.

Volviendo al título, si la pieza es cuadrada y el hueco redondo, obviamente será difícil el encaje. Pero si adecuamos ambas partes, aunque no sea en forma perfecta, explicando las diferencias y mostrando resultados, seguramente lo lograremos.

Nota: Este entrada es una revisión de un artículo oportunamente publicado en nuestro blog Excelza en marzo de 2010.

Referencias

1. Project Management, H. Kerzner

2. PMBOK 4th Edition, PMI

3. Problems of Matrix Organizations, Davis and Lawrence, HBR

“Herding cats”(*)

Nuestro producto tiene gran cantidad de interesados. Muchos de ellos colaboran, mientras otros bloquean el logro de algo útil y exitoso.

La pregunta es entonces cómo los organizamos? Qué es lo que los alinea?

Pensemos en ese universo de interesados, positivos y negativos, existente alrededor de un producto de software:

Desarrolladores, Testers, Personal de mantenimiento, Operadores, Dueños de plataformas, Personal de seguridad, Gerentes de producto, Auditores externos, Auditores internos, Instructores, Evaluadores, Adquirentes, Proveedores, Competidores, Hackers / atacantes, Clientes / Usuarios / Consumidores, etc.

Son muchos. Pero uno de ellos es el Cliente, para el cual trabaja la mayoría de los otros tratando de proveerle, cada uno en su tema, una buena experiencia

con el producto^(**), o bien tratando de frustrarla.

Partiendo de satisfacer la expectativa del cliente como guía para alinearnos, debemos ir construyendo un producto de calidad.

Todos las partes interesadas verán la calidad en relación a cómo el producto, o la parte en la que el interviene, se “adecúa a su propósito” para hacer su tarea, pero sin perder de vista que la experiencia del cliente sea superior para que quede deleitado y sorprendido al utilizar el producto.

Esto nos muestra además que esa experiencia de cliente es mucho más que la usabilidad.

Por supuesto que no sólo el producto de software es lo que genera la experiencia del cliente, sino que concurren a ella todo el resto de la Organización. Pero será un eslabón importante para lograr esa calidad que genera clientes fanáticos y leales, que estarán dispuestos a pagar un precio superior en un mundo donde todo se transforma en commodity.

Tendremos entonces una herramienta para “alinear a nuestros gatos”.

------

Algunas referencias de cómo encontrar a estos interesados están en:

1.     Understanding Your Users - Courage and Baxter

2.     Mastering the Requirements Process - S. Robertson, J. Robertson

3.     BABOK® - Business Analysis Body of Knowledge®

------

^(*)Herding cats se refiere a una expresión idiomática que habla del intento de control u organización sobre una clase de entidades que son incontrolables o caóticas.

^(**) Ya que el foco de la entrada es otro y para evitar entrar en la polémica sobre UX, CX, UCD, dejo algunas definiciones de CX:

Wikipedia: Suma de todas las experiencias que un cliente tiene con un proveedor de bienes y/o servicios, mientras dure la relación con él. Desde la toma de conciencia, el descubrimiento, la atracción, la interacción, la compra, el uso, el cultivo de la relación y su recomendación.

Gartner: Percepciones y sentimientos relacionados del cliente causados por el efecto,  de única vez y acumulativo, de la interacción con los empleados del  proveedor, canales, sistemas o productos.