Valor de Negocio

De qué hablamos cuando hablamos de Valor.

Uno de los factores que nos motivan a los seres humanos, luego de tener satisfechas nuestras necesidades básicas, es el valor que podemos aportar al mundo que nos rodea. Necesitamos que el resultado de nuestro trabajo tenga una retribución o reconocimiento. Además de eso, a muchos nos gustaría que ese trabajo genere valor. Es más: en muchas ocasiones, el trabajo que hacemos no tendría sentido si no aporta valor.

Antes de entrar de lleno a darle un enfoque más cercano a la agilidad o la entrega de valor desde un producto/servicio no sobra abordar el término desde las ciencias del comportamiento humano, que habla de cuatro ejes sobre los que los seres humanos contemplamos el valor: desde el dinero, el tiempo, el impacto y la perspectiva. Aparentemente, después de estudiar la valía que le damos a las cosas, esos cuatro caminos definen en buena medida lo que consideramos como valioso o que tiene valor.

El valor se pone en marcha dentro de un contexto y nuevamente, desde esa mirada comportamental, se habla de dos sistemas sociales donde el valor se puede medir: Sistemas de Retorno (de Valor) Inmediato y Sistemas de Retorno (de Valor) Diferido. En la medida que podamos comprender el marco de ese sistema podemos abordar el valor como un punto de partida para comprender el porqué de muchas de las acciones que ponemos en marcha. Desde la creación de soluciones y en un contexto laboral, la lectura de valor puede ser distinta.

El ciclo de de vida productos se divide en diversas etapas: prototipado, introducción, crecimiento, maduración, declive. La definición de valor y el (los) KPI medido(s) depende en qué etapa se encuentra dentro del ciclo de vida y del tipo de producto (por ejemplo, e-commerce, B2B, B2C, SaaS, etc).

A veces se puede medir o calcular y otras veces sólo se puede estimar.

¿Qué significa valor?
¿Cuánto valor entregó el proyecto?
¿Para qué lo queremos medir el valor generado?
¿Cómo se puede medir o calcular ese valor?
¿Cuánto valor entregará este equipo durante el próximo es?
¿Podemos estimar el valor que obtendremos?
¿Cómo se puede estimar ese valor?

Si alguna vez te hiciste alguna de estas preguntas, este artículo es para vos.

El concepto de valor es lo que intentaremos comprender más profundamente en este artículo. Intentaremos visualizarlo y analizarlo desde diferentes perspectivas: Qué, Para Quién, Para Qué, Cuándo y Cómo.

Pretendemos que el análisis aplique tanto a desarrollo de productos de software como también a otro tipo de proyectos.

Qué

“El concepto de Valor de Negocio (Business Value) representa el beneficio al cual accede una empresa, institución o grupo de usuarios cuando se disponibiliza una nueva funcionalidad del software para su uso productivo”, de Thomas Wallet.

Los usuarios del producto construido o del servicio diseñado valoran el trabajo de un equipo cuando les permite realizar mejor su trabajo, por ejemplo: más eficientemente.

Las personas de negocio que decidieron invertir (tiempo, dinero, capacidad productiva) también valoran el trabajo de un equipo cuando les permite recibir un retorno de la inversión realizada. Este retorno es el valor que pretendemos conocer, cuantificar, medir, entender. A veces tiene forma de ahorro de tiempo o dinero, otras veces tiene forma de ganancias de dinero o de cantidad de usuarios, por poner algunos ejemplos concretos.

El valor entregado será consecuencia del impacto (o los impactos) que se genere(n).

Para quién

Negocio

Sponsors / Inversores / Stakeholders

Product Owners “Estratégicos”, más orientado a ayudar a definir la visión, el roadmap del producto basado en el valor de negocio, apoyándose en enfoques más experimentales y trabajando más del lado del negocio.

El Product Owners “Operacionales” que trabaja más cerca del equipo refinando el Backlog, aclarando y detallando las Historias de Usuario.

Usuarios – Consumen producto o servicio.

Lo que construye el equipo debería ser algo que le sirva al usuario final, que le sea de utilidad, que termine adorando. No solamente es lo que se quiere o desea, sino lo que se necesita. Posiblemente no sea lo que exprese en los requerimientos. En estos contextos son útiles las técnicas de descubrimiento (Discovery) y de User eXperience (UX).

Equipo

Los equipos de trabajo valoran que su entregable sea valorado. Además les ayuda a entender los criterios de priorización del Backlog.

Para qué

  • Para priorizar (iniciativas; proyectos de una cartera o portfolio; o requerimientos de un Product Backlog).
  • Para decidir si considerar o descartar el proyecto o funcionalidad.
  • Motivacional (un equipo que conoce sus impactos trabaja mejor).
  • Un punto de referencia (para saber cómo venimos con respecto a nuestros desafíos y nuestro pasado inmediato).

Cuándo

Determinar cuándo medir el valor entregado depende de las características del proyecto.

Un proyecto aporta valor al ser liberado el producto, el servicio o el aprendizaje que busca obtener. El momento en el que se genera la liberación de ese resultado es una buena instancia de medición. Hay proyectos en los cuales hay entregas intermedias y otros en los cuales se ven resultados solamente al final. Cuanto antes ocurra la liberación, antes se podrá medir o calcular el valor entregado, a partir del impacto generado.

Sin embargo, muchas veces no se puede esperar hasta el final para medir o calcular el valor entregado. Es para eso que se recurre a técnicas que permiten estimar dicho valor.

Cómo

Un punto inicial para medir o estimar el valor de negocio es hacerlo lo más simple posible, esto se puede realizar cuantificando los beneficios en dinero. Para esto se podría considerar: optimización de un proceso, ahorro de tiempo, impacto generado (cantidad de nuevos usuarios a partir de la liberación, cantidad de transacciones) y otros indicadores que puedan aplicar en cada caso.

El siguiente paso es experimentar con otras formas de medir el valor e incluso crear una técnica propia de medición.

Algunas técnicas que permiten medir el valor de negocio:

  • Asignar rangos de valores (oro, plata, cobre, madera)
  • Priorizar con naipes o billetes
  • Ponderando criterios
  • Matriz de comparación
  • Estimar el valor relativo en $ comparándolo con otro producto que conocemos su valor
  • Modelo Kano: para entender qué es lo que el cliente quiere
  • WSJF (Weighted Shortest Job First): costo del retraso

Dos técnicas (más amplias y abarcativas que las anteriores), que nos permiten aprender qué aporta valor a nuestros clientes y usuarios, son Design Thinking y Lean Startup, pues proponen tener interacción temprana con ambos públicos y realizar experimentos con prototipos simples, en ciclos cortos, con feedback frecuente y de calidad.

Más allá de las técnicas existentes, cada organización deberá encontrar su mejor forma para estimar y medir el valor: “Necesitamos mapas (modelos) y necesitamos recorrer el territorio. Una de cal y una de arena“. Organizaciones que aprenden en base a crear ambientes de trabajo seguros donde se dan equipos empoderados que se permiten experimentar.

 

img_4880

Este artículo fue escrito en equipo por Roberto Mejías, Pablo Lischinsky, Pablo Tortorella, Leo Barrientos y Juan Daza Arévalo.

Es un resultado tangible y una suerte de resumen de una valiosa conversación que ocurrió en el grupo de Telegram de participantes del evento Agile Open Camp 2016 (AOC) realizado en Bariloche.

En ella también aportaron sus preguntas, referencias, opiniones y ánimos unos cuantos colegas latinoamericanos, a saber: Tommy Christie, Florencia Rossi, Hiroshi Hiromoto, Lina Jervés, Diego Sánchez, Mauro Strione, Andrés Herrera, Juan Manuel Relloso, Deiby Od, Fernando Claverino, Alejandro Faguaga, Thomas Wallet, Felipe Talavera, Elias Molini y Sebastián Ghelerman.

Referencias acerca de Kanban

Los tableros visuales “kanban” son una de las técnicas que más fácilmente potencian a los equipos. Estos tableros dieron nacimiento al método Kanban, muy difundido y reconocido en el mundo de las ahora famosas “Metodologías Ágiles”.

Decimos que potencian fácilmente a los equipos porque su adopción inicial no requiere grandes cambios en la dinámica de trabajo… aunque las consecuencias de su utilización a consciencia, podrían (y deberían) traer aparejados, una buena cantidad de observaciones, reflexiones y mejoras (léase cambios e impactos) en el equipo y en cada persona involucrada.

Se trata de un método basado en la visualización del flujo de trabajo y la búsqueda de su mejora continua siguiendo ciertas prácticas y principios que están muy bien resumidos en este video de nuestros amigos de Fuerza Tres:

Quienes estén interesados en conocer más acerca de Kanban, encontrarán valiosos conocimientos en estos libros que recomendamos:

Dos libros disponibles gratuitamente online:

El libro original, pago, muy claro y también traducido al español:

  • Kanban por  David J. Anderson

Adicionalmente, Kanban se complementa muy bien con Value Stream Mapping, sobre el cual escribimos juntos* un breve capítulo en el libro Herramientas Ágiles; y está muy relacionado con Lean y sus 7 principios.

¡Los invitamos a que compartan en los comentarios de este artículo, otras referencias que encuentren de utilidad relacionadas con Kanban!

* Escrito en pares por Pablo Tortorella y Pablo Lischinsky, Agile Coaches de Kleer.

 

Sobre contratos para freelancers

Seguramente sería de gran ayuda para muchos freelancers entender cómo son los diferentes esquemas de contratos ágiles y cómo ir hacia el esquema de Time&Materials.

En mi opinión es importante entender el balance de los riesgos entre el cliente y el proveedor de cada uno de los esquemas existentes e ir nutriendo una relación basada en la confianza. Pronto más información sobre este interesante tema.

Blog de NicoPaez

Muchas veces cuando trabajamos como ingenieros/programadores en un esquema de relación de dependencia no le prestamos mayor atención a las cuestiones contractuales. “Alguien” consigue los proyectos ya sea canalizando pedidos/necesidades de otras áreas (si desarrollamos software in-house) o bien vendiendo a algún cliente (si somos una software factory). Pero si vas a trabajar por tu cuenta deberías al menos tener algunos puntos presentes para encarar tus proyectos.

En términos generales y de forma muy simplificada existen dos tipos de contratos: los llave en mano y los Time&Materials.

En un contrato llave en mano, se define el proyecto completo antes de comenzar fijando el alcance del software a entregar y uno cobra un monto fijo también establecido al comienzo del proyecto por entregar la pieza de software en cuestión. Esta forma de contratación es muy común en construcciones civiles pero llevada al software muchas veces suele traer algunos inconvenientes por el simple hecho…

Ver la entrada original 235 palabras más

Mejorá las prácticas técnicas en tus equipos de desarrollo de software.

Las prácticas y técnicas de desarrollo ágil de software son esenciales para lograr equipos de alto desempeño.

CSD
Foto de Matias Gorostegui: Certified Scrum Developer @FDV Solutions

Scrum aporta en la gestión de proyectos, importantes beneficios para el cliente, entre ellos:

  • la posibilidad de manejar mejor cambios en las prioridades
  • mayor productividad
  • mayor visibilidad

Estos beneficios se obtienen trabajando en equipos multifuncionales incluyendo testers, desarrolladores, analistas de negocio y representantes de stakeholders. Los equipos trabajan con mayor autonomía, colaboración y transparencia, en iteraciones con entregables periódicos, con un backlog mejor definido, priorizado y constantemente actualizado. Asimismo aprenden a reflexionar sobre cómo trabajan y a implementar la mejora continua de sus procesos.

Ahora bien, para subir un escalón en la mejora de los resultados de nuestros equipos debemos prestar atención a las prácticas técnicas de desarrollo de software, ya que éstas serán uno de nuestros mayores cuellos de botella en la búsqueda de la mejora continua: mayor productividad, mejor calidad, equipo más consolidado y cliente más feliz con los resultados entregados regularmente.

La pregunta es: ¿Cómo puede hacer el equipo para comenzar este camino de mejoras? Una manera que acelera este camino es mediante la capacitación en Scrum y las prácticas técnicas con el curso de Certified Scrum Developer. sigue leyendo

Talleres Pre-Ágiles 2015 en Montevideo

En muchas conferencias se realizan cursos y talleres previos o inmediatamente después de los eventos dictados por referentes que asisten a la misma.

He asistido a los últimos 3 eventos de las Jornadas Latinoamericanas de Metodologías Ágiles llamadas Ágiles (2012 en Córdoba-Argentina, 2013 en Lima-Perú y 2014 en Medellín-Colombia) y lamentablemente no se han organizado este tipo de actividades. La única vez fue para el Ágiles 2013 en Lima cuando Jurgen Appelo, quien sería Keynote en ese evento, hizo una parada previa en Bogotá para dictar un taller de Management 3.0. Tuve la suerte de poder viajar desde Caracas a Bogotá y realizar ese taller y luego seguir a Lima para el Ágiles 2013. sigue leyendo