Steve Johnson on Product Management and Agile (a.k.a. ‘Friends build products, enemies build documentation’)

Escrito el 28 de Septiembre de 2009 a las 12:41 

La mayoría ni os plantearéis verlo porque dura una hora y está en inglçes. Shame on you! Por si consigo engatusaros, aquí van algunas perlas anotadas:

- Demasiadas compañías comienzan centrándose en la tecnología y el producto, entonces se centran en las ventas, entonces pasan a centrarse en el marketing y la marca, entonces están gastantdo mucho y se centran en las finanzas para que entonces alguien diga “tenemos que volver a nuestros origenes y volver a la tecnología y el producto”. Entonces el ciclo comienza de nuevo, pero la respuesta no está dentro de la empresa: hay que escuchar al cliente.
- No hay documento de requisitos, por muy exquisito que sea, que un desarrollador no pueda malinterpretar
- Nada parece complicado para la persona que no sabe de lo que está hablando
- Típicamente, más documentos, más requisitos, más especificaciones, más reuniones = menos desarrollo
- “Mientras más aprietes tu puño, más sistemas se escaparán entre tus dedos”” (Princesa Leia). Tremenda cita y tremenda aplicación.
- Comparación de las empresas con Star Trek: desarrollo sería Spock: muy técnico, muy centrado en su labor y tratando por todos los medios de parecer humano; Marketing sería el doctor ‘Bones’ McCoy, quejándose constántemente de lo que NO es (’Por el amor de Dios, soy un médico, no un….”); y el Capitán Kirk sería ventas, constantemente comprometiendo la nave más allá de sus posibilidades. :-D :-D :-D
- El feedback que obtenemos desde soporte técnico está basado en clientes que tienen problemas, y ni siquiera en todos ellos (¿cuantos de vosotros habéis llamado a Microsoft para quejaros de MS Project?) :-D
- Tus actuales clientes nunca te van a pedir que sustituyas por completo su actual instalación convirtiéndola en obsoleta, aunque eso sea exáctamente lo que necesiten.
- Que una idea no tenga una evidencia de mercado no quiere decir que no sea una innovación y proporcione al mercado algo que necesita pero no ha pedido.
- De todas las reuniones que has tenido en la última semana, ¿Cuántas han sido sobre el cliente y cuántas han sido “blame management” (gestión de la culpa, echarse la culpa de todo unos a otros)?

Categorías: Gestión, Gestión de Proyectos, Marketing, Negocios y empresas
Tags: ,,,,,,
Deja un comentario | Compártelo

El horno de las magdalenas

Escrito el 14 de Septiembre de 2009 a las 14:57 

Esta es una historia que cuento en mis cursos y suele gustar bastante. Tanto que ya me han pedido alguna vez que la escriba e incluso tengo un dibujo dedicado que reproduzco al final del artículo (gracias, Juanjo, iremos poniendo el resto poco a poco ;-) ). La cosa va así:

Supongamos que tenemos una fábrica de magdalenas que consta de las siguientes partes:

.- Una cinta sin fin en la que se van colocando los moldes de magdalena con la masa
.- Un horno en el que se van introduciendo los moldes de cinco en cinco y son horneados durante 5 minutos
.- Una salida del horno, por la que las magdalenas ya horneadas salen en dirección al cliente

Tenemos a dos personas operando la fábrica. Una opera la cinta y va colocando los moldes. La otra opera el horno. La primera se llama Don Dueño de Producto, y la segunda se llama Don Equipo. Lo vamos pillando, ¿no? :twisted:

La fábrica de magdalenas funciona muy bien y los clientes están contentos con el producto. Tan contentos que empezamos a tener más clientes, más demanda, y a Don Dueño de Producto le entran las prisas.

Entonces, en medio de una hornada, Don Dueño de Producto se dirige a Don Equipo y le dice “oye, abreme el horno que quiero ver cómo va todo”. Don Equipo le responde “no hombre, no… Si abrimos el horno se va toda la temperatura, y las magdalenas no suben”. Y Don Dueño de Producto, refunfuñando, se aguanta.

Pero entonces entra corriendo un mensajero con un encargo: un bizcocho urgente. El bizcocho ocupa el espacio de tres moldes de magdalenas. Y Don Dueño de Producto dice “parad la hornada, que hay que meter un bizcocho urgente”. Don Equipo dice “mira, la hornada lleva dos minutos… ¿No puedes esperar tres minutos más para que metamos el bizcocho?”

“¡No! ¡No lo entiendes! ¡Es urgente! ¡El cliente lo demanda!”. Don Equipo mira al cielo resignado y dice “ok, ok, paramos la hornada y tiramos estos moldes para empezar una hornada nueva de cinco minutos”.

Y entonces, para asombro de Don Equipo, Don Dueño de Producto le mira con cara de horror y dice “¡No! no lo has entendido… Hay que hacer el bizcocho en esta hornada y *además* de las magadalenas“. Cuando Don Equipo logra salir de su asombro le dice “pero vamos a ver… Lo primero es que te vas a cargar las magdalenas que estan metidas, pero incluso aunque aceptes eso, ¿dónde quieres que meta el bizcocho si el horno ya esta lleno?”.

Entonces Don Dueño de Producto se enfada de verdad. “¡Estoy harto de quejas! No entendéis los malos tiempos que vivimos y lo importante que es este encargo, el cliente siempre tiene la razón. Hay que hacerlo y hay que hacerlo. Si no se puede, pues se tiene que poder. Y punto. Y si no hay sitio, pues lo colocais encima de esos tres moldes de magdalenas, y como escuche mas quejas voy a empezar a escribir cartas de despido a la voz de ya”.

Ante la amenaza, Don Equipo abre el horno (con lo que se va la temperatura), coloca el bizcocho encima de tres moldes (con lo que el bizcocho queda cerca de la resistenci superior del horno y las magdalenas aplastadas), cierra el horno y espera tres minutos a que termine la hornada, también conocida como Sprint. El resultado es el lógico:

Horno Magdalenas Scrum

Claro, al realizar el envío al cliente, este lo devuelve indignado. Así que ahora tenemos que hacer cinco magdalenas, un bizcocho y las cinco magdalenas que tocaría hacer ahora. Suponiendo que hagamos bien las cosas, generamos ahora mismo un retraso de ocho magdalenas: tenemos que parar la linea, meter cinco magdalenas y luego meter el bizcocho, y aprovecharíamos el segundo turno para meter al menos dos magdalenas nuevas, así que en dos turnos produciríamos dos magdalenas nuevas además de todo el trabajo rechazado.

Si desde el principio hubieramos hecho las cosas bien y hubieramos esperado al segundo turno para meter el bizcocho, solo habríamos generado un retraso de tres magdalenas (las que ocupa el bizcocho). Ahora sin embargo hemos generado deuda técnica, y típicamente Don Dueño de Producto ser irá poniendo cada vez más nervioso y seguirá pieiendo que metamos más cosas de las que caben en el horno

Moralejas (algunas ;-) ):

1.- Los equipos necesitan su temperatura adecuada. Ni tan frío que no cueza ni tan caliente que se queme. La sopa, por ejemplo, tiene su temperatura de cocción a la que todos los ingredientes dan su punto. Más frío y no sabrá a nada, más caliente y se quemará. Esta temperatura adecuada de equipo es lo que yo denomino un “estrés saludable” o, en términos Agile, el “paso sostenible”, es decir, el ritmo que podemos mantener indefinidamente sin cansarnos.

2.- El Dueño de Producto debe de manejar la Pila de Producto, no la Pila de Sprint. Si el Dueño de Producto se dedica a interferir en el espacio de trabajo del equipo (Sprint), no podemos esperar que emerja la autogestión ni los estados hiper-productivos asociados a Scrum. Eso no quiere decir que el equipo no informe diariamente del progreso, proporcione toda la visibilidad posible y acepte el criterio del Dueño de Producto en las entregas (si el Dueño de Producto dice que no vale, es que no vale). Esto también aplica a cualquier entorno jefe-empleados, no necesariamente a Scrum: los equipos tienen que tener su espacio y su margen de maniobra, y la microgestión solo conduce a la suboptimización y al bajo rendimiento.

3.- Ante una situación de deuda técnica cualquier momento es mejor que el siguiente para decir “alto” y aplicar el principio Lean de Jidoka. Dicho de otra forma, cuando uno está en el fondo de un pozo lo primero que tiene que hacer es dejar de cavar. Tened en cuenta que, como otros tipos de deuda, crece a interés compuesto (por cierto, es falso que Einstein dijera que se trata de la mayor fuerza del Universo o el mayor invento del siglo veinte ;-) ).

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

Orcos a las puertas

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

Reflexionaba esta semana, junto con los jefes de proyecto de una de las empresas con las que estamos trabajando actualmente, respecto al problema histórico de comunicación entre las áreas de negocio y las áreas técnicas, tantas veces reflejadas, por ejemplo, en los chistes de Dilbert. Es un problema comprensible: las motivaciones muchas veces están enfrentadas (el área de negocio quiere más cosas en menos tiempo, el área de sistemas quiere más tiempo para dedicar a menos cosas) e incluso los lenguajes y el bagaje personal y profesional son tan difererentes que lo raro es que surja una buena comunicación.

Scrum, como sabéis, establece un artefacto (la pila de producto) que permite a la gente de negocio (Dueños de Producto) manejar a la gente técnica (Scrum Master y equipo). Sin embargo, uno de los problemas típicos que nos encontramos en las implantaciones de Scrum en las que trabajamos es el de involucrar a la gente de negocio en el proceso. La implantación de Scrum suele surgir por iniciativa de los técnicos, cosa rara si pensamos que la gente de negocio debería tener una formación y un foco más “humanista” y deberían haber sido los primeros que planteasen formas de colaborar y comunicarse con las áreas de producción (notese el matiz respecto a “áreas productivas”, que esas deberían ser todas, negocio y sistemas).

Al surgir desde el área técnica, las áreas de negocio tienden a veces a considerarlo “cosas de frikis” y pasar muy mucho del tema. Por eso nuestro enfoque de implantación conlleva muchas acciones dirigidas a las áreas de negocio. El objetivo final es que las áreas de negocio nombren un determinado número de Dueños de Producto que sean los que canalizacen y prioricen las peticiones de todos los interesados, clarificando al equipo lo que deben hacer en cada momento. Con eso evitamos también el bombardeo de peticiones “no oficiales” a las que típicamente se ven sometidos los equipos de desarrollo, peticiones cuya prioridad no está clara y que la mayor parte de las veces ni cuentan con una justificación de negocio sólida ni computan luego en la productividad del equipo, ya que se hacen “de tapadillo”.

Lamentablemente, el enfoque de envagelización y colaboración no siempre funciona, y los equipos de desarrollo se enfrentan a peticiones y negociaciones que les llueven por todas partes. Es como enfrentarse a un enemigo muy superior en número y recursos. ¿Y qué podemos hacer en una situación así?

Reflexionabamos sobre esto, como os decía, y tratando de explicar el enfoque que nosotros proponemos como siguiente nivel de presión hacia el cambio corporativo se me ocurrió la metáfora de los “orcos a las puertas”: La batalla del abismo de Helm.

Abismo de Helm

En la batalla del abismo de helm, los humanos se parapetan en un fortaleza que cuenta con un único punto de acceso: un estrecho puente que obliga a los miles de orcos que los asedian a formar casi de uno en uno, con lo que en las puertas de la fortaleza se monta lo que los KODT llaman una “conga de la muerte”, una estrategia perfecta para lidiar con un enemigo muy superior en número y que ya fue utilizada por los 300 espartanos en el paso de las termópilas.

¿En qué consistiría la estrategia “orcos a las puertas”? En primer lugar, en blindar el área de sistemas. Kniberg lo describe muy bien en su libro. Esto se puede hacer a un nivel organizativo o discilplinario, aleccionando a todo el mundo para que no atiendan peticiones de ningún tipo que no vengan del Dueño de Producto de Sistemas, o incluso físicamente, co-alocando a todo el equipo y dejando pocas vías por las que los extraños puedan acceder y pulular. Incluso sentar al Dueño de Producto de Sistemas al lado de la puerta para que actue como guardián del área.

El segundo paso es precisamente ese: nombrar a un Dueño de Producto de Sistemas encargado de lidiar con los orc…Digooo…Con la gente de negocio. Nada fácil, os lo aseguro. En la mayoría de los casos una estraegia pasivo-agresiva como esta suele acabar en el despacho del CEO, pero a veces es precisamente esto lo que hace falta. Por eso es también muy importante preparar documentación sobre todos los intentos previos que se hayan hecho para que el área de negocio asuma la responsabilidad y la competencia que le toca sobre la definición y priorización de los proyectos. Eso nos permitirá justificar el movimiento defensivo.

A veces lo que ocurre es que el área de negocio está encantada con tener un interlocutor único en sistemas, y la estrategia “orcos a las puertas” se convierte en una mejor práctica corporativa. Pues estupendo. De hecho, no se vive tan mal en el abismo de Helm, siempre que uno tenga un puesto calentito, dos buenas pantallas TFT y unas cuantas herramientas de desarrollo… ;-)

Categorías: Gestión de Proyectos
Tags: ,,,,,,,,
2 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