¿Por qué prefiero las Historias de Usuario a los Casos de Uso?

o

Los casos de uso como fuente de insatisfacción entre analistas, desarrolladores, testers y usuarios

--

Por mucho tiempo expliqué y empleé los casos de uso con todos sus elementos:

·         Precondiciones

·         Postcondiciones

·         Flujo básico

·         Flujos alternativos

·         Flujos de excepción

·         los misterios de los include y extend

·         Y variaciones de acuerdo al autor y la empresa

Pero lo que siempre notaba es que:

·         Los diferentes autores lo explican distinto la documentación de los casos de uso

·         El mismo caso de uso queda escrito de forma diferente por diferentes personas
·         En muchas ocasiones no quedan bien escritos

·         Y lo que es peor los clientes/usuarios NO LOS ENTIENDEN - sabiendo que fueron creados para ellos y supuestamente están en lenguaje de usuario - (he notado que los casos de uso no los entendemos muchas veces entre los mismos ingenieros de sistemas)

Luego, tiempo después, con el agilismo aprendí dos lecciones importantes:

·       la comunicación escrita tiene baja efectividad (ver imagen de Alistair Cockburn)  

·       De la comunicación solo el 7% es transmitido en las palabras, el 38% corresponde al tono de la voz y el 55% a la comunicación no verbal (ver más aquí)

Pero el punto que quiero presentar no es que los casos de uso hacen parte de la práctica de levantamiento de especificaciones funcionales donde el usuario aparece, se levanta información y luego desaparece por un tiempo hasta que por fin regresa a validar el sistema, lo que quiero evidenciar es que los Casos de Uso llevan consigo un problema de comunicación que genera una cantidad de insatisfacciones, reprocesos y hasta de bugs, miremos como sucede:

1.       Se levanta el Caso de Uso por el Analista y se identifican 5 escenarios de uso.

	Especificado por el analista
Flujo básico	FB1
Flujo Alterno 1	FA1
Flujo Alterno 2	FA2
Flujo Alterno 3	FA3
Flujo de Excepción	FEx1
Flujos identificados	5
Flujos adicionales	0
Flujos totales	5

2.       El desarrollador es creativo e identifica 6 escenarios adicionales que funcionan perfectamente dentro de los flujos identificados. El desarrollador tiene gran satisfacción por su proactividad y es posible que hasta su gerente de proyecto lo felicite.

Escenarios	Especificado por el analista	Desarrollados e identificados por el desarrollador
Flujo básico	FB1	FB1
Flujo Alterno 1	FA1	FA1 FA1.1
Flujo Alterno 2	FA2	FA2 FA2.1 FA2.2
Flujo Alterno 3	FA3	FA3 FA3.1
Flujo de Excepción	FEx1	FEx1 FEx1.1 FEx1.2
Identificados	5
Adicionales		6
Flujos totales	5	11

3.       El tester, que es alguien que es experto en encontrar escenarios de fallo, encuentra adicionales a los especificados y los 6 adicionales hallados por el desarrollador. En este punto el dialogo del  tester y desarrollador es en el mejor de los casos el siguiente:

·         Tester: Mira encontré 5 incidentes, me toca devolverte el caso de uso

·         Desarrollador: ¿Cómo así? No los vi, identifique 6 escenarios adicionales, pero bueno pásamelo y déjame reviso, si es del caso los corrijo.

(Para ser sensatos no son incidentes, ni bugs, ese golpe no lo veía venir el desarrollador(ni el especificador, ni el gerente de proyecto) por ningún lado, pero empezó a pagar los platos rotos de cuenta de esta cadena de errores involuntarios de cuenta de la metodología de trabajo)

Escenario	Especificado por el analista	Desarrollados e identificados por el desarrollador	Probados y otros nuevos identificados por el analista
Flujo básico	FB1	FB1	FB1
Flujo Alterno 1	FA1	FA1 FA1.1-	FA1 FA1.1-
Flujo Alterno 2	FA2	FA2 FA2.1- FA2.2-	FA2 FA2.1- FA2.2- FA2.3- FA2.4-
Flujo Alterno 3	FA3	FA3 FA3.1-	FA3 FA3.1- FA3.2- FA3.3-
Flujo de Excepción	FEx1	FEx1 FEx1.1- FEx1.2-	FEx1 FEx1.1- FEx1.2- FEx1.3-
Identificados	5
Adicionales identificados		6	5
Flujos totales	5	11	16

Nota: por lo general el Flujo básico es el que queda mejor especificado y no tiene lugar a malas interpretaciones

4.       El cliente recibe el caso de uso y al probarlo se da cuenta que el producto está muy bien construido pero encuentra que 5 escenarios no especificados “pero obvios” no fueron considerados y al revisar la documentación junto con el analista, el cliente y el gerente de proyecto del equipo del proveedor concluyen que deben ser elaborados. Estos 5 escenarios son 5 incidentes que se le suman a los 5 anteriores detectados por el tester. A este punto tanto desarrollador como tester tienen cuestionada su “reputación” tanto con el cliente como con el gerente de proyecto.

Escenario	Especificado por el analista	Desarrollados e identificados por el desarrollador	Probados y otros nuevos identificados por el analista	Cliente usuario
Flujo básico	FB1	FB1	FB1	FB1
Flujo Alterno 1	FA1	FA1 FA1.1-	FA1 FA1.1-	FA1 FA1.1- FA1.2- FA1.3-
Flujo Alterno 2	FA2	FA2 FA2.1- FA2.2-	FA2 FA2.1- FA2.2- FA2.3- FA2.4-	FA2 FA2.1- FA2.2- FA2.3- FA2.4- FA2.5- FA2.6-
Flujo Alterno 3	FA3	FA3 FA3.1-	FA3 FA3.1- FA3.2- FA3.3-	FA3 FA3.1- FA3.2- FA3.3- FA3.4 -
Fujo de Excepción	FEx1	FEx1 FEx1.1- FEx1.2-	FEx1 FEx1.1- FEx1.2- FEx1.3-	FEx1 FEx1.1- FEx1.2- FEx1.3-
Identificados	5
Adicionales identificados		6	5	5
Flujos totales	5	11	16	21

A este punto 5 escenarios identificados por el analista, se han convertido en 21 debido a la ambigüedad y falta de precisión de los casos de uso, generando gran insatisfacción y reprocesos en toda la cadena.

---

Aquí es donde los comparo con las historias de usuario (ver más acá - la magia de las historias de usuario-) donde estas tienen:

·         Una pequeña descripción funcional

·         Y unos criterios de aceptación los cuales tiene la gran ventaja de:

o   Discutirse hasta el completo entendimiento  (hasta la saciedad) con el cliente (recordemos CCC – Card-Conversation-Confirmation)

o   Si se olvida un criterio de aceptación se realizará el próximo Sprint o iteración (que comenzara a lo sumo en un mes)

o   No hay lugar a bugs por “omisión funcional” o escenarios “obvios” no identificados, por lo tanto la probabilidad de éxito de un desarrollo satisfactorio es altísima pues no hubo lugar a ambigüedades, ni olvidos no intencionales

·         Si hay algo que aclarar se resolverá durante la iteración o sprint con el cliente, el cual estará disponible para resolverla.

Por esta razón es que prefiero hoy en día las historias de usuario a los casos de uso.

Queda abierto el espacio para  la discusión y las experiencias. 

Saludos ágiles

Jorge Abad

Listado de Desperdicios - Sobre Lean Software Development

Recordando los principios del Lean Software Development

1. Eliminar desperdicios
2. Amplificar el aprendizaje, cree conocimiento
3. Decidir lo más tarde posible
4. Entrega lo más rápido posible
5. Capacitar, potenciar, al equipo. Empodere, energize al equipo y crea en el.
6. Construir con integridad y incluya la calidad
7. Ver el todo, la meta. No pierda de vista la meta y trabaje en alcanzarla.
8. Enfóquese en el cliente
9. Siga mejorando, (lo mejorado o aprendido puede cambiar y se puede mejorar)

El primero es "eliminar el desperdicio", revisando un post de Javier Garzas ( La velocidad de un equipo depende del rozamiento y del desperdicio ) , extraje esta lista de desperdicios típicos:

• documentos que nadie leerá jamás, 
• las especificaciones de cosas que nadie jamás implementará,
• las especificaciones de casos de prueba que nunca nadie ejecutará,
• las reuniones eternas sobre temas en los que nunca nadie se pondrá a trabajar, 
• las funcionalidades programadas en una aplicación que ningún usuario utilizará, etc.

Unos que se me ocurren a mí:

• documentar escenarios de uso que nadie usará
• realizar diagramas de UML innecesarios y no mantenibles
• reuniones desenfocadas, sin timebox

¿Cuales más se nos ocurren?¿pueden ayudarme a aumentar la lista? ¿que crees que hace perder tiempo y genera desperdicio en tu equipo de trabajo?

Saludos ágiles

Jorge Abad

¿Compras / vendes /licitas proyectos problemáticos de software? – Un pequeño deja vu

Usted o su empresa siendo el CLIENTE:

• ¿Formula proyectos que sabe de antemano que NO se van a ejecutar en el tiempo que tiene pactado?
• ¿Se busca quien haga su proyecto a pesar de tener expectativas irreales en cuanto tiempo y costo?
• ¿Argumenta que si hay un proveedor que es capaz de postularse es porque la solución es posible?
• ¿tiene reuniones afanosas donde todos se miran, sonríen, estrechan manos  diciendo que sí vamos a ser  capaces, vamos a poner todas las condiciones para que sea así?

Usted o su empresa siendo el PROVEEDOR:

• Le jura a su cliente que va a cumplir aunque no tiene ni las personas, ni la expertise para hacerlo
• Su gerente  general le dice a usted como gerente de proyecto:  tienes que hacer ese proyecto con las personas que tiene, pues el "no voy a contratar mas gente / - o mal llamados recursos -  "
• Se mienten entre sí en el posible equipo ejecutor diciendo:” tranquilo yo sé que ustedes lo van a lograr, ustedes son muy buenos” aunque no falta el pesimista que dice – “hombre esta es la misma historia de siempre, vamos a caer en lo mismo”, lo ignoran y siguen adelante…
• Se diseñan estrategias super-apretadas para cumplir algo irrealizable (el Project, el Gantt y el Power Point pueden con todo)
• Estima proyectos grandísimos sin la participación del equipo ejecutará.

A ustedes dos (cliente y proveedor) ya lo saben:

El proyecto será:

• un fracaso
• o un eterno desgaste  muy difícil de cerrar
• Reuniones y reuniones
• Actas firmadas
• Revisión de documentación
• Y hasta invitación a revisión de los abogados

Alguien pagará los platos rotos

• Lo más seguro es que sea el proveedor 
• Estos platos los pagan los trasnochos del equipo de trabajo, de esta forma se pagará la “mala planeación” que si somos sensatos fue la mala venta o presentación a un proyecto problemático.
• Y pasará a engrosar la lista de proyectos problemáticos que harán que nuestro valor hora de venta hacia el mercado aumente.
• Su reputación estará nuevamente en juego.
• En muy pocos casos los pagará el cliente, pero si es así, con seguridad le costará su puesto, o su reputación.

Se verán abocados (cliente y proveedor - gerente del lado del cliente y gerente del proyecto) a realizar reuniones continuas y constantes de re-planeación de proyecto donde se pasarán horas reformulando el proyecto, creando nuevos cronogramas  (donde el tiempo lo sacarán del tiempo de descanso correspondiente  a los desarrolladores) y firmando con sangre nuevas fechas (a ratos no sé de dónde sacan tanta sangre cierto tipo de empresas) y lo peor al no cumplirlas usted (ya sea cliente o proveedor) perderá credibilidad y la palabra dada ya no servirá.

 En esta circunstancia es probable que su Jefe o Gerente (los CEO, o plumas blancas como le decimos en mi país) tengan que ir a reuniones a repactar todo nuevamente.(y lo peor es probable que las reputación y palabra de ambos también se desgaste en este tipo de círculos viciosos)


Si usted es el cliente:

• Su jefe le estará preguntando por qué eligió ese proveedor y tendrá constantes reuniones de seguimiento y de estrés con él.
• Usted pensará de nada me sirvió haberme desgastado en la elección o haber confiado en la empresa “x” o en mi amigo “y” que trabajaba en esa empresa.

Si usted es el proveedor

• El comercial dirá: “yo solo cumplí con vender el proyecto, acá lo aceptaron, nadie dijo NO, ni nadie me detuvo, además yo logrando otro estoy en otro proyecto si quieren me invitan a una reunión a ver que hacemos”. (la caricatura que sigue es.. inspiradora.)

(pero bien..sigamos con el tema)

• Al gerente de proyecto le dirán
• mire como planea mejor ese proyecto, para que salga adelante
•  otras veces le dirán: Nos va tocar hacer ESO aunque no esté en el alcance para calmar al cliente (léase ESO como una nueva fuente de problemas pues va a estar muy seguramente mal especificado y como siempre este tipo de regalos salen caros).
• El gerente hablará con los desarrolladores y todo su equipo.
• "Muchachos tenemos que trabajar fuerte, el proyecto es un lío, ustedes saben que yo no lo vendí, pero estamos acá para sacar las cosas adelante. Vamos a trabajar duro, les daremos pizzas y pollo para que trabajen de noche y fines de semana. Yo sé que lo vamos a lograr, yo confío en ustedes, y si lo logramos voy a buscar como logro una bonificación de la gerencia general."

----

Y a todas estas, todos dicen en su interior… este es el mismo deja vu de siempre, repetimos y repetimos los mismos errores, acá en esta organización no aprendemos. De nada nos sirve tener procesos definidos y/o rigurosos como CMMi, certificados o no, todo es el mismo desgaste (por no querer decir todo es la misma m…).

Muchas veces el desarrollador o el gerente de proyecto  se va para otra empresa y allá vuelve y encuentra la misma historia.

---


La verdad no entiendo la industria de software, ni los clientes, ni los proveedores, no acogen muchas veces Procesos Ágiles que son transparentes porque les da miedo, pero ¿acaso todo este recurrente deja vú no es peor que una película de terror que se repite y reinventa con nuevos y/o los mismos protagonistas?

Esto es cómo jugar a la ruleta rusa entre 4 personas y con 5 balas en el tambor.

No entiendo ¿por qué los Clientes (aclaro "los malos Clientes") no quieren pagar el costo de un buen proyecto?, y  ¿por qué los que son/somos proveedores no aprendemos a decir que NO?

Hasta acá esta pequeña diatriba y desahogo... hasta la próxima.


----

¿Quieres jugar un juego?

Hagamos un proyecto a la forma tradicional con una metodología robusta, mirarás el RFP (la convocatoria, la licitación) y sabes que no lo lograrás, si no lo haces saldrás del mercado, pero si lo haces cortaré la libertad de tu equipo de trabajo y trabajarán horas y horas, perderás tiempo y dinero sin lograr el alcance, ni cerrar el proyecto. Tienes 3 días para presentar la propuesta… tic tac.. tic tac

Tres frases

Dos que leí por ahí

Procesos no implica capacidad / habilidad / maestría

Documentación no implica entendimiento

y una muy cierta, dada por la experiencia

Agilidad no implica éxito

(también se puede fallar en ágil, pero tiene más probabilidad de éxito que el esquema tradicional)

__

Historias de Usuario y Scrum para Equipos de Ingeniería Electrónica

Muchas veces me he topado en las charlas de Scrum, en los dojos de historias de usuario  ( dojo = lugar de entrenamiento) con amigos agilitas que me han preguntado: ¿cómo hago historias de usuario y Scrum si mi equipo es de ingeniería electrónica y trabajamos adaptando dispositivos electrónicos de los más diversos protocolos para nuestras soluciones? La verdad algunas veces respondía:

•      Debe ser lo mismo que en software
•      Estas construyendo un producto tiene que ser posible aplicar Scrum
•      Invítame y miramos (la verdad no me invitaban)

Lo bello de la vida es que te da la respuesta a las preguntas que le haces (o por lo menos así me funciona a mi), hace unos meses trabajo en una empresa donde en efecto, tenemos una solución hardware-software, y tenemos dos equipos:

• Uno de ingenieros de software que trabajan desarrollo web sobre php.
• Y otro de ingenieros electrónicos que trabajan adaptando dispositivos electrónicos y generando firmware respectivamente.

En esta empresa me desempeño como Director de Operaciones y Scrum Master, el gerente que es quien tiene la visión de los productos y es nuestro Product Owner (decidimos estos roles luego de pensar como adoptar Scrum en la organización).

En realidad lo que hicimos fue disciplinar un poco a ambos equipos, firmware y software pues ya contaban con varias reuniones:

• Planning
• Review
•  Listado de requerimientos en un backlog

y hubo un tiempo hacían juiciosos el daily, práctica que habían perdido, pero lo recordaban.

Luego de trabajar un tiempo con el equipo de firmware comprendí varias cosas:

•  Invierten un buen tiempo  entendiendo el protocolo de funcionamiento de un dispositivo, luchando en el terreno de la anarquía o caos (ver imagen anterior) hasta que por fin des-encriptan, logran comunicarse y hacer que el dispositivo haga lo que ellos quieren.
• Este tempo en la anarquía o caos es un tiempo  en efecto de ensayo y  error, este tiempo no es estimable, se ponen una meta de lograr algo retándose para “X” fecha (por lo general lapsos mayores a 5 días), pero realmente no saben si lo van a lograr, a veces dicen: es probable que me demore menos o más pues se parece a algo que ya había trabajado, pero no es responsable comprometerme con una fecha.
• Luego de des-encriptado el componente electrónico y su protocolo, los ingenieros  SI son capaces de hacer estimaciones, pues caemos en el terreno conocido de lo “complejo” y Scrum aplica perfectamente allí.

Después de entender esto, estuvimos mirando cómo escribir las historias de usuario, he aquí unos resultados interesantes (y que actualmente usamos):

Historia de usuario Título: Cambio de Contraseñas del panel Descripción: Crear un menú que permita personalizar las contraseñas del panel Escenario 1:  Si no se han personalizado las contraseñas el panel debe aceptar solo las contraseñas por defecto Criterios de Aceptación: DADO:  Que no se haya personalizado contraseñas CUANDO: Ingresen al nivel 1 ó 2 del panel ENTONCES: Debe validar solo con las contraseñas por defecto Escenario 2: Si se ha personalizado la clave de un nivel, debe validar con esta clave personalizada y con las por defecto. Criterios de Aceptación: DADO:  Que se haya personalizado la contraseña del nivel CUANDO: Ingresen al nivel personalizado ENTONCES: Debe validar con la contraseña personalizada o con las contraseñas por defecto

Historia de usuario Título: Memoria SD- crear archivos en el interior de cualquier carpeta. Escenario 1:   la memoria SD tiene la carpeta ya creada pero en su interior está vacía. Criterios de Aceptación: DADO:  el encendido a la tarjeta CUANDO: verifique por la existencia de los archivos ENTONCES: si no existen los crea y guarda información de una venta en el mismo formato en el que se guardaría en el servidor. Escenario 2: la memoria SD ya tiene el archivo con el nombre válido creado pero está vacío. Criterios de Aceptación: DADO:  La tarjeta SD en el sistema CUANDO:  el encendido a la tarjeta        ENTONCES : verificar la existencia del archivo en la ruta ya especificada. Y: se verifica que el archivo esté vacío y guardar información en el principio del archivo como una venta completa en el formato en el que se manda al servidor Escenario 3: la memoria SD ya tiene el archivo con nombre válido creado y ya tiene ventas o cualquier tipo de información almacenada. Criterios de Aceptación: DADO:  el encendido a la tarjeta CUANDO:  va a guardar la información. ENTONCES : verifica si el archivo existe, Y: se posiciona al final del archivo Y: guarda la información en el formato adecuado para que el servidor la reciba.

Historia de usuario Título: XXXXXX y YYYYYYY utilizando el gps obtener datos. Escenario 1:   iniciar el programa sin tener conexión con el gps Criterios de Aceptación: DADO:  El encendido a la tarjeta CUANDO: la tarjeta  recibe respuesta del gps ENTONCES: Colocar el mensaje en pantalla "ok" Escenario 2: Hacer los cálculos matemáticos para el XXXXXX y YYYYYYY Criterios de Aceptación: DADO:  el encendido a la tarjeta y la señal de "ok" CUANDO:  la obtención de los datos por el puerto serial ENTONCES : Calcular con los datos del gps la distancia y el tiempo Escenario 3: almacenar los datos del XXXXXX y YYYYYYY Criterios de Aceptación: DADO:  el encendido a la tarjeta y la señal de "ok" CUANDO:  son calculados los datos  de XXXXXX y YYYYYYY de forma matemática ENTONCES : enviar los datos del XXXXXX y YYYYYYY a la memoria del microcontrolador MMMMMMM. Escenario 4: Enviar por medio del  protocolo ZZZZZZZZ los datos del XXXXXX y YYYYYYY Criterios de Aceptación: DADO:  el encendido a la tarjeta y la señal de "ok" CUANDO:  sean calculada la distancia y el tiempo de forma matemática y sean guardados en el micro ENTONCES : enviar los datos del  XXXXXX y YYYYYYY por medio del protocolo ZZZZZZZZ Nota para los lectores: Creo que entienden que MMMMMMM, XXXXXX, YYYYYYY y ZZZZZZZZ, son nombres reservados de las tecnologías que usamos

He observado varias cosas:

·         El equipo prefiere tener pocos criterios de aceptación

·         Los eventos por lo general corresponden a eventos de hardware:

o   Envíos

o   Lecturas

o   Encendidos

o   Apagados

o   Estímulos de otros componentes

o   etc

·         Las respuestas son igualmente comportamientos de los componentes, ya sean en forma de :

o   Encendido de bombillos, leds, etc.

o   Mostrar datos en un panel visualizador

o   Enviar datos

o   Registro y almacenamiento de datos

o   Entre muchos otros

Respecto a las historias, estas  son estimadas en puntos, donde:

·         Un punto =  es un DÍA FELIZ  (Léase: día enfocado trabajando sin desconcentraciones

Por lo general estimamos los puntos basados en la métrica del “clima del día anterior”, pero nos comprometemos unos cuantos puntos más para ver si podemos alcanzar a hacerlos.

Y Scrum…

El equipo a pesar que realizaban ciertas prácticas el hecho de involucrar Scrum y otras técnicas más en su día a día les ha reportado beneficios:

·         Compromiso y foco con lo que se va a realizar en el sprint

·         Las retrospectivas dan elementos de mejora para el siguiente ciclo

·         Se han percibido grandes ganancias en las:

o   Uso de criterios de aceptación, pues ya no sabe lo que esperan del desarrollo y no comienzan a trabajar de forma “desordenada” como se hacía antes

o   Pruebas pares, pues ya no se escapan tantos escenarios, y permiten distribución del conocimiento

o   El daily, Les sirve para sincronizarse y ayudar al compañero que esta “enredado” resolviendo una historia de usuario.

o   El Kanban y el Burndown les ha permitido enfocarse y comprometerse más como equipo para lograr metas comprometidas.

o   El Scrum Master trabaja en la solución de los impedimentos, permitiendo foco al equipo.

Espero este post, le se ayuda a mis amigos los ingenieros electrónicos y vengan muchos más similares. Si conocen de alguno similar o lo escriben ustedes, no duden en participármelo para linkearlo en este post.

Postdata: La verdad no estaba tan perdido cuando daba la respuesta “Debe ser lo mismo que en software” pero definitivamente la experiencia es la mejor maestra y ya puedo dar una mejor respuesta cuando me pregunten sobre Scrum e historias de usuario en ambientes de ingeniería electrónica.

Saludos ágiles

Jorge Abad.

Problema o Impedimento, una duda frecuente en Scrum

Hola a todos

Uno de los conceptos que con más recurrencia explica uno como Scrum Master al equipo después de un daily, es el concepto de IMPEDIMENTO

Generalmente se confunde Impedimento con Problema, veamos la definción de los dos bajo el contexto de Scrum y Equipos Ágiles:

Problema:

Dificultad que puede ser solucionada en el tiempo, ejemplo:

• una validación compleja
• incorporar un componente de software nuevo a la solución
• Un error que le esta saliendo a la persona que esta haciendo la tarea y le esta tomando tiempo resolverla
• etc

Impedimento:

Son eventos que bloquean la construcción de una o varias historias de usuario,  funcionalidades o ítemes del Sprint Backlog comprometido. Los impedimentos dependen demasiado del contexto, pero por lo general están asociados a una falta de información.

Ahora una cosa es cierta, cuando un problema lleva mucho tiempo sin resolverse, se convirtió en impedimento y es necesaria la intervención del Scrum Master.

Muchas veces luego del daily pregunto: "¿consideras que el problema X sabes/saben como resolverlo o definitivamente requieres/requieren ayuda?" y de acuerdo la respuesta entra o no en mi backlog de impedimentos a gestionar.

Bienvenida la discusión y aportes


Saludos ágiles
Jorge Abad

_

Dos Post que Leí a Ricardo Colusso sobre Contratos Ágiles / Contratos Colaborativos

Estos son los links

• http://rcolusso.tumblr.com/post/91949163403/trabajo-en-equipo-con-proveedores-y-contratos
• http://rcolusso.tumblr.com/post/94950801633/formas-y-contenido-de-los-contratos-colaborativos

Los copio a continuación
--------

Trabajo en Equipo con Proveedores y Contratos Colaborativos

si tus proveedores trabajan bajo máxima presión hay mayor probabilidad de que no puedan cumplir con la calidad exigida o los tiempos de entrega

El paradigma de “comandar y controlar” que guió la gestión y dirección de las empresas y organizaciones humanas en general hasta hace pocos años —y que va dejando lugar a modelos más colaborativos, sinérgicos, ágiles e innovadores—, incluye a veces elementos de presión desmedida y hasta cierto destrato hacia los proveedores.

Probablemente conozcas empresas que siempre buscan extraer de cada proveedor lo máximo posible —exprimirlos hasta la última gota!—, tratando además de retrasar los pagos a través de ardides y estratagemas que, si bien legales, distan de ser justos. En estos casos aparte de la posible ventaja económica que puede obtenerse demorando los pagos por algunos días, puede detectarse también la intención de demostrar quién es el que tiene más poder …

Pero empíricamente vemos que una presión desmedida hacia los proveedores, aparte de generar conflictos y pérdidas de tiempo, generalmente resulta en un pésimo negocio porque:

- si los proveedores trabajan bajo máxima presión hay mayor probabilidad de que no puedan cumplir con la calidad exigida o los tiempos de entrega, lo cual finalmente genera problemas y mayores costos al cliente

- cuando los proveedores no pueden cubrir bien sus costos y tener una ganancia razonable debido a que fueron sometidos a negociaciones duras, ni bien encuentran la oportunidad aumentan sus precios, demoran las entregas, o reducen calidad para cubrirse del daño que le causa un cliente abusivo

- la creación de situaciones de “suma cero” —donde la ganancia de una parte ocurre a expensas de lo que pierde la otra parte— crea un contexto hostil y poco propicio para mejorar, cooperar y prosperar.

- también en estos casos los empleados de la empresa cliente reciben un mensaje negativo acerca de los valores de la organización, el cual resulta mucho más impactante que cualquier slogan o declaración escrita sobre la importancia de las personas y su trabajo

Como ejemplo de los beneficios de crear y mantener relaciones de confianza y colaboración intensa con los proveedores podemos citar el caso de la supremacía lograda por la industria automotriz japonesa sobre la norteamericana durante la década de 1980.

En esos años Toyota y Honda —entre otros— alcanzaron niveles de eficacia en la fabricación y mejoras en la calidad nunca antes vistos, además de reducir el tiempo de desarrollo de nuevos productos de 5 a 3 años. Esto ocurrió en parte porque incorporaron a todos los proveedores a sus sistemas de mejora continua (kaizen) y de just-in-time, convirtiéndolos así en aliados estratégicos.

Aprovechando la experiencia de transformación de la industria automotriz japonesa, la idea de crear y mantener relaciones de ganar-ganar (win-win) con proveedores se extendió a muchas otras industrias, materializándose en la creación de contratos colaborativos, acuerdos-marco ágiles y programas conjuntos de capacitación, mejoras de calidad e innovación.

En caso de que percibas que en tu organización no están manteniendo relaciones de confianza y aprecio mutuo con la mayoría de los proveedores, te invitamos a que pienses en cuál podría ser tu próximo paso para intentar mejorar la situación. Para esto te sugerimos avanzar en un ajuste inicial bien pequeño que pueda marcar una diferencia importante —tal como estar más atento y activo para entender mejor qué es lo que ocurre.

En la segunda parte de este artículo exploraremos formas de contratos colaborativos que pueden ayudarte a crear y mantener relaciones comerciales más fructíferas con tus proveedores.

-----

Formas y Contenido de los Contratos Colaborativos

En un artículo anterior ( “Trabajo en Equipo con Proveedores y Contratos Colaborativos”) comenté sobre las ventajas de suscribir contratos colaborativos que ayudan a clientes y proveedores a crear contextos de trabajo más ágiles e innovadores.

Continuando con el tema, hoy vamos a avanzar en la definición de este tipo de contratos mencionando 4 formas básicas de acuerdos entre clientes y proveedores:

1) Contratos de precio y alcance fijos: los utilizamos cuando la contraprestación es cierta y directa. Por ej: queremos comprar sillas a un fabricante que ya vendió miles, o un servicio de limpieza, o una maquinaria que se fabrica en serie

2) Contratos de precio y alcance variables: también llamados “time & material”, sirven usualmente para organizaciones que contratan servicios de terceros, como los casos en que una empresa provee a otra de personas capacitadas que realizan tareas operativas y continuas

3) Contratos de precio variable y alcance fijo: se utilizan para casos de proyectos muy innovadores o de estimación muy difícil, como el diseño de una nueva máquina compleja

4) Contratos de precio fijo y alcance variable: utilizado en proyectos complejos donde se deben cumplir objetivos (generalmente definidos a nivel alto o medio) dentro de un presupuesto fijo

La recomendación es que siempre pensemos muy bien el tipo de contrato a utilizar para los diferentes tipos de prestaciones, ya que por ejemplo utilizar un contrato del tipo 1 (precio y alcance fijos) en proyectos donde pueden requerirse luego múltiples cambios nos puede dar muchos dolores de cabeza. Ejemplos de estos proyectos incluyen el desarrollo de software y la remodelación de un edificio.

Además, para los tipos de contrato 2, 3 y 4 te proponemos explorar la inclusión de:

a) Una definición de alcance que contenga: visión detallada y los objetivos del negocio. Esto es especialmente valido cuando puede ser ilusorio (o muy costoso) disponer de una definición ultra- detallada de todas las tareas

b) Una definición de complejidad y esfuerzo como referencia:Utilizando estimaciones relativas que permitan reaccionar a cambios de necesidades, expectativas y dolores de los clientes, reemplazando tareas originalmente planeadas por otras muy importantes que no se hayan tenido en cuenta y se detecten durante el trabajo activo en el proyecto.

c) Un modelo cooperativo que incluya formas de evaluar performance y colaboración.
Clientes y proveedores pueden acordar los lineamientos básicos de colaboración para que el proyecto no se trabe o detenga, y cómo revisar frecuentemente si se cumplen objetivos parciales. Para esto se definen gráficos y tableros para visibilizar el trabajo realizado, el trabajo en curso y las próximas tareas

d) Una fase de verificación para ver si se cumplen las hipótesis de performance y colaboración

e) Siempre que sea posible, condiciones de rescisión simples y que no acarren prejuicios serios a ambas partes. Para esto, a intervalos regulares debe proveerse de productos o servicios completos y utilizables.

Adicionalmente, es recomendable comenzar la relación cliente-proveedor con contratos cortos y de alcances pequeños que puedan renovarse automáticamente con el acuerdo de ambas partes.



--------

Un link adicional

Por acá al final pongo unos slides que preparé junto con un gran amigo Leonardo Agudelo - @sweepnoise  hace un tiempo sobre el tema, que pueden son complementarios - http://es.slideshare.net/jorgeabad1/un-resumen-sobre-contratos-giles-por-jorge-abad-y-leonardo-agudelo-agile-contracts



-----