¿Y si soy caro?

Escrito el 30 de Septiembre de 2008 a las 23:27 

¡Movidita de la que me gusta! Escribí hace unos días un artículo en el que hablaba del síndrome de la barra libre, es decir, la tendencia de las distintas áreas de la empresa a sobrecargar al Área de IT al no percibir que eso cause un gasto a la empresa o que esos recursos deban ser compartidos con otros usuarios.

Pues bien, el maestro Luis ha pegado un pedasso de rúbrica al artículo desde su sitio explicándo, desde su experiencia personal, no solamente que efectivamente el fenómeno se produce con cierta frecuencia, sino que además esboza lo que fue su estrategia para luchar conta el mismo.

El planteamiento de Luis, absolutamente defendible, enfoca una progresiva imputación de los costes a los consumidores internos, llegando a funcionar como una unidad de negocio interna o “centro de beneficio”, como el propio Luis lo llama.

Pero en los comentarios, Rafa (interesante blog, por cierto) ha dado con un punto clave que yo mismo iba a comentar: el miedo de muchos CIO a que, una vez hecha la factura, los servicios de IT resulten más caros que los que prestan otras compañías del mercado. Y claro: todo el área de IT a la calle y la función en outsourcing. Zas, en toda la boca.

Lo que me maravilla es que se opta por la estrategia del avestruz. Curioso. Justo cuando te das cuenta de que no eres eficiente, de que otros lo hacen mejor que tu, de que incluso sin necesidad de montar una infraestructura totalmente independiente y sin una necesidad real de arrojar un beneficio cuantioso (cosas con las que tienen que convivir las empresas de Outsourcing) tus costes son mayores, justo entonces decides esconder las cifras. No hacerlas. No medir. Y como dice el adagio, no se puede controlar lo que no se puede medir.

Así pues, aun coincidiendo totalmente en que lo que Rafa describe en su comentario (es decir, que es bastante complicado y hasta peliagudo instaurar un sistema de control de costes de IT), considero que es un paso necesario si queremos hacer Kaizen: mejora continua. Hoy mejor que ayer, mañana mejor que hoy. ¿O es que realmente ya hemos alcanzado el mejor estado posible? Y si es así, que lo dudo, ¿de qué tenemos miedo?

Señor CIO: si tiene usted miedo de que externalicen su área, por algo será. Mejor nos vamos poniendo las pilas y atacamos las principales fuentes de gasto y desperdicio en el área, tratando de hacer que el flujo de valor sea lo más eficiente posible. Lean en estado puro, ¿no?

Categorías: Gestión
Tags: ,,,,,,,
9 comentarios | Compártelo

Scrumsourcing

Escrito el 22 de Mayo de 2008 a las 15:57 

Me lanza Luís (al que añoro leer más a menudo, pero ando hasta arriba) un guante que recojo encantado esperando que pueda seros de utilidad. Luís describe la típica situación de un cliente que va descubriendo lo que en realidad necesita conforme va avanzando en el proyecto. Es la típica situación que los técnicos describen como “el cliente no sabe lo que quiere” y que los profesionales de Agile, Lean y Scrum describimos como “en un sistema de dimensión compleja, los requisitos son emergentes”. No es culpa del cliente (aunque de todo hay en la viña del Señor): es que no hay otra forma de asegurarse de acertar en el resultado de un proyecto que incrementar los ciclos de feedback cliente-proveedor mediante un desarrollo iterativo e incremental, con entregas de producto funcional y testable al final de cada iteración, algo que va en contra de lo que académicamente se ha postulado durante los últimos treinta años en el mundo de la gestión de proyectos software, que se ha basado típicamente en la aciaga herencia de los desarrollos industriales en cascada.

Hay soluciones basadas en Scrum que funcionan en entornos como el que comenta Luís (os lo aseguro), pero el cliente debe estar dispuesto a un modelo más colaborativo. Me ocurre con frecuencia que, cuando comento a un cliente la posibilidad de que contrate a sus proveedores en un modelo de “fixed time-fixed money” con funcionalidad variable (es decir, contrato al equipo por seis meses y a ver cuánto somos capaz de hacer) me dicen que estoy loco, que entonces el proveedor se dedicará a tocarse las narices todo ese tiempo y que no entregará casi nada al final del proyecto. Pero sin embargo cuando se lo comparo con los contratos de outsourcing o bodyshopping comienzan a verlo más claro: el principio es el mismo, y la forma de controlar el progreso es involucrarse en el mismo de forma diaria.

De hecho, los contratos “fixed time, fixed money, fixed functionality”, es decir, contratos basados en un supuesto conocimiento perfecto del futuro y la evolución del producto a lo largo de meses y meses de trabajo, son una aberración en un mundo de productos complejos como el software y los sistemas, de forma que lo que ocurre en realidad es que el cliente trata de trasnferir todo el riesgo tecnológico y de “mutación” al proveedor, y este se blinda metiendo más colchones que pikolin. Así expresado no parece muy colaborativo, ¿Verdad? Pues por eso no funciona. ;-)

Algunas fórmulas intermedias que suelo recomendar incluyen lo que llamo el contrato de “scrumsourcing”, en el que los objetivos se dividen segun MOSCoW (Must, Ought, Could, Wish) y se firma, por ejemplo, hacer un 100% de los Must, un 80% de los Ought y un 50% de los Could en un tiempo determinado por el proveedor. Cualquier funcionalidad o historia en el que no se haya empezado a trabajar puede ser cambiada en cualquier momento por otra de valor / peso similar. Y en caso de que el cliente esté satisfecho con el nivel alcanzado en cualquier punto del proyecto, o al contratio, piense que el proveedor no avanza al ritmo adecuado, puede cancelar el contrato en cualquier momento por un coste equivalente al 20% de lo que quede por hacer. Así, dividimos el riesgo entre todos.

La típica queja que suelen elevar los proveedores es que un enfoque de este tipo les obliga a diseñar el sistema de una forma altamente modular y flexible para soportar los cambios de funcionalidades futuras. Típicamente lo expresan como “no se puede”, pero el caso es que miles de empresas de todo el mundo trabajan así, o sea que se puede, pero requiere un esfuerzo y una disciplina. Y por otra parte, ¿no es más valioso para el cliente contar con una arquitectura modular y flexible que permita incorporar cambios y nuevas funcionalidades en el futuro? ¿No es incluso mejor para el proveedor, de cara a la recurrencia del cliente?

En este tipo de enfoques, lo ideal es comenzar contratando a proveedores para proyectos de bajo riesgo y corta duración, seleccionando a los que mejor funcionan para proyectos a mayor duración y con un impacto mayor en la compañía. Esto tiene dos ventajas: por una parte, como comentaba, podemos seleccionar a los proveedores que funcionan bien con un modelo ágil. Y por otro podemos comenzar a acostumbrarnos al proceso con proyectos de bajo riesgo e ir perfeccionando los mecanismos de control, visibilidad y feedback.

Que por cierto, para este tipo de cosas hay una consultoría que… O:-)

Categorías: Gestión, Gestión de Proyectos
Tags: ,,,,,
9 comentarios | Compártelo

Buscar:

Suscriptores:

Kisei Dojo Aikido

Pastafari!

Tags

Que se dice por aquí:

Qué se dice por ahí:

Twitter

    Fotos

    www.flickr.com
    angel.medinilla fotos Más fotos de angel.medinilla
    Cerrar
    Enviar por Correo