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: ,,,,,
Deja un comentario | Compártelo

Innovación

Escrito el 20 de Mayo de 2008 a las 7:54 

A ver si nos enteramos, señores: la innovación no es algo que simplemente ocurre, como la venta no es algo que simplemente ocurra, o la facturación, la limpieza de la oficina o la formación. La innovación, señores, es un proceso más de la empresa y como tal debe ser gestionado. Me encuentro con demasiada frecuencia con empresas en las que el concepto de “innovación” consiste en decirle a los empleados que deben ser creativos e innovadores y luego abrir un buzón de sugerencias o una intranet que languidece y duerme el sueño de las herramientas en las que se puso demasiada fe. Porque esa es otra, señores, ya esta bien de poner tanta fé en las herramientas. “Necesito una herramienta para implantar Scrum”, leía hace poco en un foro. “Recomiéndame una herramienta para gestionar mi tiempo”, me pedía hace tiempo un compañero. Que no es eso, señores. Que no.

En General Electric, por poner un ejemplo, tienen un evento llamado GE Workout, en el que mandan a 30, 40 o 50 trabajadores fuera de la empresa tres días: nada de trabajo, nada de correo, nada de teléfonos móviles. Durante esos tres días, los trabajadores piensan en formas de hacer mejor su trabajo, producir mejores resultados o introducir mejoras en los productos, y compilan una lista con todas las sugerencias. El compromiso de GE es que en 48 horas un ejecutivo revisará la lista de propuestas y aprobará una serie de ellas (no todas). Y a partir de ahí se espera que sea el propio equipo de trabajo el que implemente dichas mejoras (que esa es otra: proponer está muy bien, pero luego hay que estudiar, aprobar e implementar…¿Váis viendo como sí que es un proceso?).

En Toyota, el templo del Kaizen (mejora continua), cuentan que Taiichi Ohno increpó un día a un responsable de zona porque los estándares que tenía colgados bien visibles (otra de las prácticas magníficas de Toyota) habían amarilleado con el tiempo. Ohno le dijo “es usted un ladrón: usted roba su sueldo todos los meses. Su trabajo es mejorar los estándares constantemente, y estos estándares tienen por lo menos un año y medio. ¿Para qué le pagamos a usted?“. De hecho, la gente que empieza a leer sobre el sistema de gestión del talento en Toyota y el tremendo foco que hay en cuidar, formar y delegar en los empleados y en los equipos de trabajo pueden formarse una imagen equivocada del Taiichi-San: por lo visto era un ogro de cuidado. Pero tenía las cosas muy claras.

En 3M todos los empleados tienen un 15% de tiempo para dedicarlo a proyectos de investigación y desarrollo, tengan que ver con su area de competencia o no. Todos los empleados, desde el CEO hasta el conserje. Todas las ideas son bienvenidas, y nunca se coharta la creatividad de nadie con comentarios tipo “menuda chorrada” o “nosotros no hacemos eso”. En Google, si no recuerdo mal, hay un 20% de tiempo para proyectos “personales”, ya sean un blog, una web, una nueva aplicación… Tened en cuenta, jefes tiranos del mundo, que el cerebro humano estándar no tienen más de seis horas realmente productivas al día cuando hablamos de tecnologías de la información (programación, creatividad) y no de apretar tuercas. Así que nada de llevarse las manos a la cabeza: vuestros empleados probablemente ya están dedicando esas una o dos horas al día a temas personales (messenger, web, correos electrónicos, café con los compañeros…). Y perseguir un 100% de productividad es inutil y dañino, como os contará cualquier administrador de servidores. Por encima del 80%, solemos entrar en trashing, algo de lo que hablaré otro día, pero que podemos resumir como abarcar mucho y apretar poco.

Así que ya sabéis: si queréis innovar y competir en el mundo 3.0 que se nos viene encima, es mejor que empecéis a pensar en cómo vais a institucionalizar un proceso de innovación en vuestra empresa. Por supuesto, podéis buscar quién os eche una mano… O:-)

Categorías: Creatividad, Gestión, Gestión del Tiempo
Tags: ,,,,,,,,
6 comentarios | Compártelo

Me sale a pagar…

Escrito el 16 de Mayo de 2008 a las 19:42 

Vaya tela con lo de ser empresario… :-(

Categorías: Negocios y empresas
Tags: ,,,,,,,,,
5 comentarios | Compártelo

Tapar

Escrito el 11 de Mayo de 2008 a las 19:50 

Vaya. Que ocupado estoy y que poco escribo. Fin del apartado apologético. :twisted:

Escuchaba esta mañana en la radio de un taxi (uno de mis pocos contactos con la realidad cotidiana últimamente) que en Madrid, en un hospital, hay un pollo montado a cuentas de una colonia de bacterias asesinas en la UCI que se han llevado por delante a varias decenas de enfermos. Los profesionales sanitarios consultados han dicho que llevan meses denunciando esta situación ante los correspondiente órganos competentes del hospital y de la administración sanitaria y que no han recibido respuesta alguna a sus quejas.

Es más, me atrevo a postular que más que no recibir respuesta lo que han recibido ha sido la directriz de taparlo todo. Que no se sepa. Que no salga “la mierda”, que es el término técnico al que recurren habitualmente las empresas cuando se refieren a los problemas que no se solucionan. Lo juro, en casi todas las empresas por las que he pasado he llegado a escuchar lo de “que no salga la mierda a la luz”. O yo he tenido muy poca suerte, o esto ya es cultural.

Curiosamente, cuando uno estudia empresas excelentes, en el sentido de la búsqueda continua de la excelencia, se encuentra con que, instaurada en la cima de los principios, prácticas y valores corporativos, se encuentra la confianza absoluta en los equipos de trabajo y en su habilidad para resolver los problemas al ser los que mejor conocen el trabajo que desempeñan, así como la instauración de un proceso constante e inexorable que saque a la luz los problemas, no con ánimo de buscar culpables y cortar cabezas, sino con el objetivo de analizar las causas raices y proponer las líneas de acción que se encaminen a la erradicación permanente de dicho problema. Al fin y al cabo, el Kaizen, la mejora continua, no deja de ser simplemente eso: exorcizar demonios, para lo cuál lo primero es, como sabe todo buen exorcista, jugador de rol o aficionado a la literatura gótico-fantástica, nombrarlos.

Sin embargo, cuando nos dedicamos a “tapar la mierda”, el conjunto de valores y mensajes que estamos transmitiendo no ya a los empleados en cuestión, sino a toda la organización, es brutal. No te preocupes de estas cosas. Tu a lo tuyo. No valoramos tus sugerencias. No toques las narices. No te dediques a chinchar y señalar problemas. Estas cosas son así y punto. Siempre han sido así. No hay soluciones.

A corto plazo “tapamos la mierda”. Pero a la larga, este tipo de estrategias solo tienen consecuencias negativas. Al final las cosas salen, y magnificadas. Encima se sabe que los problemas eran conocidos pero no se ha hecho nada por solucionarlos. Y por el camino nos hemos cargado la confianza en las personas y la cultura corporativa. Sin contar con las pérdidas potenciales por las mejoras que no se instauraron en su momento y que llevarían tiempo cundiendo. Comentaba antes lo de las empresas excelentes, pensando precisamente en el Kaizen, la mejora continua nacida en el seno de Toyota. Pues bien, otro de los principios básicos de estas empresas es el foco constante en el largo plazo, incluso a costa de pérdidas en el corto. Otra de las cosas que no hemos interiorizado aun en según qué empresas y según qué entornos.

Y luego a estas organizaciones se les pide que instauren un proceso de innovación (porque, a ver si nos enteramos de una vez en este país, la innovación es un proceso y como tal debe ser gestionado) todo lo que se les ocurre es poner un “buzón de sugerencias” o hacer “concursos de ideas”. Pero a ver quién tiene ideas cuando, durante añós y de forma sistemática, nos hemos dedicado a machacar a todos los que han apuntado un área de mejora (buen principio para la innovación, por ejemplo). Y es que la cultura se acaba comiendo con patatas cualquier estrategia. Así nos luce.

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

Pair PowerPointing

Escrito el 27 de Abril de 2008 a las 10:44 

Hace unos días estuve preparando una presentación para el kick-off de un proyecto en el que colaboro con otra empresa. Faltaban tres horas para la reunión y aun no había terminado, así que el jefe de proyecto de esta empresa y yo nos sentamos ante el portatil y le dimos los toques finales a la presentación entre los dos.

Pues bien, no solo produjimos la que a mi juicio es una de las mejores presentaciones que he realizado hasta la fecha, sino que ambos aprendimos varias cosas sobre cómo realizar un power-point. Hoy mismo estoy haciendo otro y me he sorprendido utilizando intensivamente un par de herramientas y consejos que hasta ahora no había tenido en cuenta.

Al fin y al cabo, lo que estuvimos haciendo es el equivalente a la práctica de programación por parejas que describe XP (programación extrema) y, efectivamente, lejos de ser un desperdicio por tener a dos personas haciendo lo que en teoría podría hacer una, la inversión en calidad que supone tener cuatro ojos y dos cerebros revisando lo que se hace realmente paga cuando se revisa la visión global del proyecto. Item mas: el nivel de conocimiento del equipo aumenta drásticamente, ya que se produce una transferencia de mejores prácticas de forma natural.

A los que todavía no hayáis introducido prácticas de pair programming en vuestros equipos ágiles, os animo realmente a que empecéis a hacer algún experimento, porque estoy seguro de que si lo implementáis correctamente los resultados os van a sorprender mucho más allá de lo que pensáis.

actualización: me doy cuenta de que todavía no he referenciado en el sitio las estupendas “death by powerpoint” y “how to: visual effects in power-point”.

SlideShare | View | Upload your own
SlideShare | View | Upload your own
Categorías: Gestión del Tiempo
Tags: ,,,,
13 comentarios | Compártelo

Artículos anteriores:

Pastafaris en los hospitales

Escrito el 26 de Abril de 2008 a las 8:47 

Bean Counters vs Marketing guys

Escrito el 23 de Abril de 2008 a las 13:00 

Orcos a las puertas

Escrito el 19 de Abril de 2008 a las 10:52 

Cosas curiosas que llevar en la mochila (The Agile Coach Toolkit)

Escrito el 15 de Abril de 2008 a las 20:12 

Language Shyness y cultura corporativa

Escrito el 14 de Abril de 2008 a las 19:09 

¿Adsl sí o no?

Escrito el 5 de Abril de 2008 a las 9:01 

Varias novedades

Escrito el 2 de Abril de 2008 a las 11:41 

Linus Torlvalds On KDE vs Gnome

Escrito el 25 de Marzo de 2008 a las 22:11 

Cita

Escrito el 24 de Marzo de 2008 a las 15:18 

Ni chapa

Escrito el 24 de Marzo de 2008 a las 13:31 

Más antiguos →

Buscar:

Suscriptores:

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