Pluses y Deltas

Siempre que acabo un curso de formación dedico unos quince o veinte minutos a realizar una retrospectiva del mismo con los asistentes. Es una de las prácticas más importantes de Agile, y entronca directamente con el concepto del Kaizen de los sistemas Lean: la mejora continua y constante a lo largo del tiempo en busca de un estado perfecto que, más que una meta, traza un “norte verdadero”, el camino que debemos seguir día tras día. Hoy mejor que ayer. Mañana, mejor que hoy.

En fin, que me lío: en este ejercicio “post mortem” analizamos lo que ha ido bien y lo que necesita mejorar, lo que ha sido divertido y lo que ha sido más pesado, lo que es esencial y lo que se ha echado en falta. Lógicamente, a lo largo de varias decenas de retrospectivas el curso va mejorando, y amparándome en el hecho de que muchos de los asistentes a los cursos son lectores del blog me atreveré a afirmar que el índice de satisfacción y de éxito que estamos alcanzando con los cursos es muy alto, y en un porcentaje interesante de ocasiones conduce a proyectos más intensos o específicos.

Curiosamente, conforme se fueron puliendo las aristas más evidentes, han quedado un grupo de “deltas” que son casi una constante, y ante los que estamos replanteando incluso nuestra estrategia de comercialización. Lo cuál quiere decir que las retrospectivas están siendo una importante fuente de innovación.

La constante mas evidente es pedir un mayor grado de personalización en los cursos: atacar las cuestiones específicas de la organización y proponer soluciones. Pero claro… Eso tiene un nombre (consultoría) y un precio diferente a la exposición más o menos participativa y creativa de un mismo tema (recurrencia, señores, recurrencia… Hay que productizar ;-) ). No obstante, en lugar de limitarme a señalar este hecho (que la consultoría se paga) lo que estamos haciendo es diseñar un nuevo paquete de servicios que consiste en una consultoría previa, unas sesiones de formación y un roll-out workshop, es decir, un día de trabajo en el que los participantes se traen sus proyectos debajo del brazo y trabajamos en la definición de los mismos, el enfoque de desarrollo, las herramientas de visibilidad y control… En el caso de Scrum, creamos o mejoramos las pilas de producto, calendarizamos los sprints, preparamos un release plan, creamos los tablones de sprint, establecemos la mecánica y duración de las diferentes reuniones…

Así, cada cliente puede optar en cada momento por uno de los productos, combinaciones de dos o el paquete completo de consultoría + formación + taller. Hay quien pensará que me hago un flaco favor publicitando a los cuatro vientos nuestras innovadoras estrategias ;-) , pero en el fondo creo en esto, en difundir el conocimiento, las mejores prácticas y las lecciones aprendidas. Al fin y al cabo yo me he beneficiado de la experiencia de muchos que han avanzado antes que yo, y mi creencia firme en los mecanismos del Karma no puede empujarme a otra cosa que a compartir. Además, la experiencia me dicta que las personas que han compartido sus conocimientos recogen frutos a la larga. Al fin y al cabo, es un marketing excelente.

En cualquier caso, tanto si productizais como si no, tanto si paquetizais como si no, lo que sí es muy importante es mantener constantemente un mecanismo de revisión crítica y mejora que permita, sobre todas las cosas, escuchar al cliente, y mantener en todo momento una actitud constructica y positiva al respecto de las opiniones del cliente. Incluso cuando, según nuestro criterio el cliente se equivoca, es mucho más productivo pensar “¿por qué habrá llegado el cliente a esta conclusión? ¿En qué estará fallando mi mensaje?” que enfrascarnos en demostrar al cliente lo equivocado que está (frustrándole además por el camino).

Publicado en Formación, Marketing | Etiquetado , , , , , , , , , , | 9 comentarios

John Lee, el chino de la Wii

Lo de chino está dicho desde el cariño, que conste ;-) , pero cada vez que hablamos de este tío (y he hablado de él con muchísimas personas) siempre es “el chino de la Wii” ;-) ;-) ;-) .

Para los que piensan que la Innovación es algo que cuesta mucho dinero. Por cierto, ya tardan muchos en inventar aplicaciones para esto:

Esta es, probablemente, una de las presentaciones más eficaces que nunca he visto (cinco minutos):

Startuperos del mundo, vuestros speech deberían parecerse a este… :-)

Publicado en Herramientas, Ideas de negocio, Internet | Etiquetado , , , , , , , | 2 comentarios

Michael Bloomberg, Larry Page, el general Petraeus y los CEO de empresas como HP, Pepsi, Disney, IBM… La lista es bastante impresionante y sólo podía lograrla, claro está, alguien del calibre de la CNN / Fortune. La idea era preguntarle a algunos de los empresarios de mayor éxito del mundo cuál era el mejor consejo que les habían dado nunca, y he de reconocer que hay auténticas perlas, como por ejemplo:

  • Solicita siempre el pedido. Cuando el cliente ha dicho que sí, no sigas hablando.
  • Enfocate en lo que haces mejor que el resto
  • Huye de tu zona de confort
  • Sé siempre la única persona que puede firmar tus cheques
  • Es dificil parecer inteligente con malos números: produce buenos números y obtendrás la audiencia adecuada
  • Asume siempre una intención positiva
  • No intentes mantener siempre una posición de protagonismo
  • La carrera profesional no se desarrolla de forma lineal, sino a saltos
  • Hay que anticiparse a las oportunidades, antes de que se hagan demasiado obvias
  • No merece la pena hacer las cosas mal y perder así una sola noche de buen sueño
  • Sé honesto contigo mismo
  • Aumenta las ventas y diminuye los gastos (hahaha…Este se ha roto la cabeza :twisted: )
  • Pasa todo el tiempo que puedas con tus clientes
  • El mundo de los negocios es pequeño, y las carreras profesionales largas: se siempre integro y no quieras llevarte el último dolar sobre la mesa
  • Que no te entre el pánico
  • Obten un nivel fluido de inglés: es el sistema operativo del mundo
  • No tomes la opinión de nadie como sagrada ni descartes por sistema las opiniones de nadie: manten siempre en guardia las puertas de tu mente
  • Haz lo que debas hacer: no sigas a la masa
  • Durante los primeros años de tu carrera no vayas tras los títulos rimbombantes: busca jefes que puedan enseñarte algo
  • Si tienes algo bueno que decir, ponlo por escrito, pero si tienes algo malo que decir díselo a la cara a la persona en cuestión
  • Ten un punto de vista sobre el futuro que se base en tus clientes

También me ha gustado un mal consejo que le dieron a Elon Musk, fundador y CEO de Spacex: “mis padres me dijeron que ignorase a los abusones… Eso no funciona: hay que darles un buen puñetazo en las narices” :-D

En cuanto a mi, hay dos muy buenos que me vienen a la cabeza: uno, que es tu mente la que crea el mundo, y el otro que no aceptes consejos de nadie que, por lo menos, no lo haya intentado primero (este último, si no me equivoco, es del Libro Negro del Emprendedor de Fernando Trías de Bes).

Más información | Best advice I ever got
Vía | Luis Sancho

Publicado el por Ángel | 9 comentarios

A veces creo que me tendría que grapar uno de estos en la frente… Qué le voy a hacer… :-)

Free Consulting

Y es que lo que no sepa Raul de esto…

Publicado el por Ángel | 4 comentarios

Somos Proyectalis. Somos proyectos sin estrés. ¿Qué proyectos? Tus proyectos. Vivimos en la frontera del caos. Divertirnos con lo que hacemos nos convierte en imparables.”

¿A que mi gente mola todo? :-D :-D :-D

Publicado el por Ángel | 4 comentarios

Bananas

Bananas

Ummmmmmmm….Baaah-naaah-naaaasssss…. :-D

Publicado en Gestión de Proyectos, Herramientas, Internet | Etiquetado , , , , | 2 comentarios

Kung Fu Panda on Agile

Oogway: That is bad news, if you do not believe that the dragon warrior can stop him.
Shifu: Panda ?! Master that panda is not a dragon warrior, he wasn’t even meant to be here ! It was an accident !
Oogway: There are no accidents.
Shifu: Ahhh, yes I know, you’d said that already, twice.
Oogway: Well, that was no accident either.
Shifu: Thrice.
Oogway: My dear friend, that panda will never fulfill his destiny nor yours, until you let go of the illusion of control.
Shifu: Illusion ?
Oogway: Yes, look at this tree Shifu. I cannot make it blossom when it suits me, or make it bear fruits before it’s time.
Shifu: But there are things we can control. I can control when the fruits will fall. And I can control where to plant the seed. That is no illusion Master.
Oogway: Ahhh yes, but no matter what you do, that seed it will grow into a peach tree, you may wish for an apple or an orange, but you will get a peach.
Shifu: But a peach cannot defeat Tai Lung !
Oogway: Maybe it can, if you are willing to guide it, to nurture it, to believe in it.
Shifu: But how ! How !? I need your help Master !
Oogway: No, you just need to believe. Promise me Shifu, promise me you will believe.
Shifu: I will try.

Publicado el por Ángel | Comentarios desactivados

Vacaciones blogueras (de vuelta)

El título creo que lo resume bien. Casi sin proponérmelo, me he tomado unas vacaciones blogueras de un mesecito. Empezaba a estar un poquito cansado y acumulaba algo de estrés creativo, lo cual es hasta cierto punto justificable por los dos añitos, dos, que cumple este blog vuestro dentro de muy poquito.

Ha coincidido además con un punto de inflexión en el crecimiento de mi empresa y un pico de trabajo interesante. Lo cachondo es que tengo otro punto de inflexión en ciernes a la vuelta de las vacaciones… En fin, será lo último de lo que me queje viendo los buenos resultados que estoy obteniendo del primero.

Proyectos en Sevilla, Mallorca, Madrid, Barcelona, Coruña, Munich… Muchas horas de vuelo que quitan fuerzas y tiempo blogosférico. Lo siento, no me concentro en los aeropuertos. Gran parte de la culpa la tienen los turistas sevillanos que, dicho sea desde el cariño que le profeso a mi patria chica, son los mas ruidosos, horteras y catetos de todos los aeropuertos por los que he transitado hasta ahora (crear polémica siempre sube las visitas al blog :twisted: :twisted: :twisted: ).

No todo ha sido curro a expuertas en este periodo. He tenido el privilegio de asomarme a algunas de las mentes más brillantes en el campo del desarrollo de software, la gestión de proyectos y las pautas organizativas, tanto en vivo aprovechando el XP 2008 como a través de obras seleccionadas y recomendadas por estos mismos expertos y que voy devorando lenta, pausada pero inexorablemente, notando a cada página transcurrida, a cada conversación de pasillo, a cada café compartido, como se acumulan los niveles de experiencia y el poder de una generación de mentes privilegiadas dedicadas a crear un mundo mejor para los que vivimos en las tecnologías de la información y las telecomunicaciones . Todo un viaje que recomiendo a exploradores de las simas de la estupidez corporativa y buscadores del norte verdadero. Más pistas en breve.

En fin, que sirva este pequeño post para anunciar a la blogosfera mi vuelta y pedir a asiduos y no tan asiduos que no me abandonen, que los echo mucho de menos ;-)

The show goes on… ;-)

Publicado en General, Gestión de Proyectos | Etiquetado , , , , , , , | 7 comentarios

Felicidad de 9 a 5

Me pasa José Luís Marina, cuya bitácora tengo tan abandonada como el resto que languidece en mi pobre agregador (ay de mí), un enlace muy interesante: la bitácora “director de felicidad“, del autor del libro “la hora feliz es de 9 a 5“, que he anotado en mi pila de lecturas deseadas (a ver si llegan las vacaciones de una vez). Todo un blog curioso, la verdad. En primer lugar, se trata de una traducción al castellano de un blog con 2400 subscriptores, the chief happiness officer. La traducción, por lo que veo, está realizado por la misteriosa compañía contentspanish.com, que también representa “la semana de 4 horas” de mi admirado Tim Ferris. Habrá que vigilarlos.

Por otra parte, me ha encantado ver que alguien ha escrito un libro argumentando sobre algo que ya estuve comentando hace tiempo en un post que fue bastante celebrado: la jornada de 9 a 3. En este caso, el autor defiende que una jornada más reducida (32 horas, llega a exponer en un post) no reduce necesariamente la productividad y sin embargo reduce los costes de la empresa y, típicamente, los empleados lo prefieren a ganar algo más pero trabajar más horas. Al fin y al cabo, algo que llevo repitiendo de diferentes maneras desde que empecé con este blog: la productividad no es un sumatorio de horas, sino que se consigue a base de optimizar el flujo productivo. Y para optimizar un flujo uno no puede sobrecargarlo.

Alexander Kjerulf escribe sobre motivación, política de recursos humanos, salarios, y algo que parece un tabú en muchas empresas o, directamente, poco más que un eslógan: la felicidad en el trabajo. Algo que para mí es fundamental, ya que paso un porcentaje muy alto de mi vida currando (qué le vamos a hacer ;-) ), por lo que me rebela la idea de pasar ese porcentaje del tiempo que me ha sido dado haciendo algo que no me llene, me satisfaga, me realice… Me haga feliz.

Así es. Al igual que el corredor exhausto y a ratos dolorido, pero que en el fondo disfruta de la carrera y se regocija cada día cuando mejora su marca, así yo me considero feliz en el trabajo. Así que si estas leyendo a esto, tengo dos consejos para tí: lee a gente positiva que ha encontrado formas de ser feliz, y calcula ahora mismo si eres todo lo feliz que podrías ser en tu trabajo. Si no es así, ya puedes ponerte manos a la obra: probablemente te lleve años mejorar tu nivel de felicidad laboral. Hoy es un día estupendo, mucho mejor que mañan o pasado, para empezar a construir el camino a la felicidad.

Publicado en Gestión | Etiquetado , , , , , | Comentarios desactivados

Cada vez que siento que tengo las cosas bajo control, se qué tengo un problema: no estoy en contacto con la realidad”

Xp2008, Katti Vilkki, Nokia Siemens Networks

Publicado el por Ángel | 3 comentarios

– Hay quien dice que un buen programador puede aprender cualquier lenguaje en dos semanas y escribir buen código a partir de ahí, y eso no es cierto.
– Bueno, depende… Conozco gente que puede programar C en cualquier lenguaje”

Xp2008, Dave Snowden y Joseph Pelrine

Publicado el por Ángel | Comentarios desactivados

Just say no

Es un tema con el que choco recurrentemente en los últimos tiempos, posiblemente porque estamos enfrascados en varios proyectos de implementación de Scrum y es algo que, por lo que he visto a lo largo de mi carrera y como confirma la literatura, ocurre constantemente en todas las industrias y en casi todos los equipos: no saben decir que no.

Típicamente comenzamos a diagnosticarlo cuando los gerentes, jefes de proyecto o dueños de producto encargan algún tipo de iniciativa de mejora. Puede ser la adopción de Scrum o la introducción de cualquier otro tipo de práctica o herramienta. El caso es que en muchas ocasiones, pasado el impulso inicial, se va abandonando la iniciativa. Cuando hacemos exploraciones retrospectivas e intentamos ver por qué se ha abandonado, los equipos se quejan: “los jefes nos marcaron otras prioridades“. Y efectivamente, el equipo está sobrecargado de trabajo y no tiene tiempo para mantener una pila de impedimentos, realizar retrospectivas o planificar sus sprints. Pero entonces suelo preguntar: “¿Os han pedido explícitamente que abandonéis estas prácticas?“. Y los equipos suelen reconocer que no, que no ha sido una petición explícita, pero que cuando te piden que atiendas urgentemente algo y que tienes que hacerlo para mañana no pueden hacer otra cosa que atenderla.

Dependiendo de la tolerancia al interrogatorio y la tortura del equipo :twisted: , prosigo con la exploración: “¿Avisásteis al Jefe que si teníais que atender estas tareas urgentes, debíais dejar de hacer el resto de cosas que os pidieron?“. “No…Pero se sobreendiende“. “No, no hace falta porque ya sabemos lo que nos diría“.

Y así, el equipo tiene su parte de culpa en la prolongación del esquema irreal de la carga de trabajo, lo que en Agile se conoce como “la creencia en la magia” (algo ocurrirá que hará que todo encaje en tiempo y presupuesto), simplemente porque no es capaz de decir que no. En algunos casos, pocos, que me haya encontrado, realmente no se le permite a los equipos decir que no, pero en otros muchos se trata de un problema de habilidad de comunicación, negociación y persuasión por parte de los equipos. Al fin y al cabo, predecible y comprensible: nadie se ha tomado su tiempo en enseñar a un programador a negociar, y de todas maneras muchos de ellos ni siquiera llegan a ver la utilidad de algo que no compile :twisted: . Por supuesto, esto no exime de culpa a los jefes que quieren todo hecho para ayer, ya hablaremos otro día de ellos. De hecho, probablemente ellos no han sabido tampoco decirle que no al cliente, al comercial que ha vendido la moto o a su propio jefe que pide las cosas acostumbrado a la “barra libre”.

Y así logramos lo que en Lean Software Development se conoce como Trashing. Es lo mismo que le ocurre a un ordenador por encima del 100% de carga: pasa más tiempo gestionando el intercambio de tareas que realmente ejecutando las tareas, y al final nada funciona. Solo que en el cerebro humano esto ocurre en cuanto superamos más o menos el 80% de capacidad, algo parecido a lo que ocurre en carreteras y autopistas. Al fin y al cabo, cuando hay un atasco o tráfico lento, en realidad cabrían más coches entre coche y coche, ¿No? Efectivamente, no hay que llegar al 100% para provocar un atasco.

Me he encontrado con empresas que tienen listas de 300 implementaciones o mejoras pendientes, cuando su capacidad de producción es de en torno a 3, 4 o 5 historias al mes, lo que significa que tienen una lista de trabajo de seis o siete años (verídico), y eso sin contar conque la lista sigue creciendo y actualizándose constantemente. Todo por no seguir una simple práctica: decir que no. Para aquellos que quieren conservar las peticiones a título informativo o como recurso de lo que al usuario le gustaría, basta con establecer una lista de “Nunca”, como sugería Mary Poppendieck en un seminario al que asistí esta semana.

Al fin y al cabo, cuando Google ofrece a los empleados un 15% de tiempo para asuntos libres y personales, en realidad hace algo de trampa. En realidad, todos dedicamos en torno a una hora al día a desayunar, ir al baño, mandar correitos chorra, leer un blog, chatear por el messenger con un compañero, revisar la cuenta del banco y demás asuntos personales. Una hora al día representa en torno a un 13% de tiempo. Lo único que Google dice es “esta bien, SABEMOS que hacéis estas cosas en jornada laboral y nos parece bien, siempre que el restante 85% lo dediquéis a esta compañía, y lo hagáis al máximo nivel”.

Otra de las cosas que Google hace, como muchos sabéis, es reservar otro 20% de tiempo para proyectos de innovación. Y este tiempo debe ser respetado. El riesgo de esta política es que los equipos se queden más tiempo del que les toca para atender a una demanda siempre creciente de tareas, incapaces de atenderlas todas en el 65% de tiempo que les queda para el desarrollo. Muchas de estas tareas, por cierto, caerán en ese 60% de funcionalidades que, según Standish y según mi experiencia directa y la de todos los desarrolladores con los que he trabajado hasta ahora, se usan rara vez o nunca. YAGNI. Quemar recursos, dinero y tiempo de la empresa y de las personas.

Así pues, dear teams in the way of Agilehood: Just Say No. No a más trabajo del que razonablemente se puede desarrollar. Y os prometo una cosa: cuando los equipos tienen responsabilidad y se les da cierta holgura en la dedicación, la productividad se dispara. Se escribe mejor código, más limpio, con menos errores que atender y corregir en los próximos meses. Hay tiempo para aprender mejores prácticas y nuevas tecnologías. Hay tiempo para refactorizar, implementar arquitecturas mejores, mejores herramientas… Y esto, junto con un equipo motivado por el avance, es el motor del aumento de la productividad en Agile. Implementar únicamente el scrum diario, un tablón y seguir sobrecargando al equipo no llega siquiera a atisbar las mejoras reales que pueden lograrse en una implementación completa de los principios que operan tras Scrum.

Y por hoy ya vale, que me está saliendo un ladrillo considerable.

Actualización: Ofú, meneado… Mejor voy cerrando los comentarios… :-D :-D :-D

Publicado en Gestión, Gestión de Proyectos | Etiquetado , , , , , , , , | 14 comentarios

Como decía Ford, “Tanto si crees que puedes hacerlo como si no…Tienes razón”. Esto es algo que deberían grabarse a fuego algunos de los jefes de proyecto con los que trabajo de vez en cuando. Típicamente estamos en medio de un proyecto de implantación metodológica o de consultoría organizativa, y desde Proyectalis proponemos algún cambio que, a nuestro juicio, proporcionaría una mejora significativa en los equipos y la empresa. Entonces surge el “no, eso no podemos hacerlo”, seguido lógica e indefectiblemente por nuestro perenne “¿por qué?”.

En ese instante suelo observar que nuestro interlocutor eleva los ojos un instante, sígno de que está pensando, construyendo, artículando y argumentando su respuesta, y comienza la lucha: “es que blablabla uno”. Y nosotros, “bueno, pero eso, blablabla solución uno”. “Ya, pero es que además blablabla dos”. “Si, pero blablabla solución dos”. Así ad infitum (o ad nauseam, lo que primero llegue ;-) ).

El caso es que cuesta el mismo trabajo ponerse a pensar las razones por las que no podemos hacer un determinado cambio o esfuerzo que pensar en cómo podría realizarse dicho cambio, o cuáles serían las condiciones en las que dicho cambio sería viable. Posiblemente incluso se detecten los mismos impedimentos que en el enfoque anterior, pero al mirarlos desde la perspectiva de “qué tendriamos que hacer para solucionar esto” los resultados son más constructivos, más positivos y sobre todo existen más posibilidades de que consigamos descubrir una manera de implementar el cambio o incluso definir y trazar el plan de acción.

Pensad además que cada “pero” suele encerrar un paradigma amenazado.

Publicado el por Ángel | 10 comentarios

Master en Networking

(artículo originalmente enviado a la revista Networking Activo)

Entre mis actividades de networking favoritas se encuentra el desayuno. Casi todo el mundo desayuna, por lo que no estás robándole tiempo al día sino aprovechándolo de otra forma, y en cualquier caso un desayuno de trabajo no debe prolongarse más allá de media hora. Desayunando hace poco con un buen amigo me comentaba su intención de realizar un Master en Dirección de Empresas, el tan ansiado MBA, a pesar de que esta persona cuenta ya con una impecable y envidiable trayectoria profesional. Personalmente, le comenté, siempre he considerado que un MBA proporciona una importante ventaja competitiva y una visión global de negocio considerable cuando uno está empezando, acaba de salir de la Universidad y se enfrenta por primera vez a la selva de la empresa. Pero hay expertos que consideran que un MBA es el equivalente a tres o cuatro años de experiencia empresarial relevante, por lo que no tiene demasiado sentido emprenderlo cuando uno ya lleva doce años en empresas de primera línea con puestos de responsabilidad. A menos qué, claro.

A menos qué lo que andemos buscando en un Master sean los valiosos contactos que proporciona. Todos habremos escuchado alguna vez esta reflexión: lo importante del Master no es lo que aprendes, son los contactos. Y ahí tuve que darle parcialmente la razón a mi amigo. Parcialmente. Aunque sea cierto que los círculos de Networking surgidos a partir de haber compartido aulas, sumado al esfuerzo que las escuelas de negocio, conscientes de la importancia de esta factor, realizan para mantener y aumentar estas redes de networking (seminarios, encuentros de antiguos alumnos, revistas, eventos), no es menos cierto que el coste de un Maste, en tiempo y dinero, es bastante elevado, sobre todo si queremos asistir a “ese” o “aquel” Master, que son los que más contactos proporcionan.

Pero pensémoslo: si lo que valoramos realmente son los contactos, ¿no hay formas más eficientes, eficaces y efectivas de conseguir esos contactos? Comparemos la inversión en un master con el coste de asistir regularmente a los eventos de Networking profesional que se organizan en varios lugares del país, como por ejemplo los Thursday Internet en el marco de las nuevas tecnologías o los eventos Networking Activo para los que buscan contactos en el area de los negocios. Curiosamente, en muchas ocasiones estas mismas personas que valoran la posibilidad de endeudarse para hacer un Master y dedicarles las tardes de los viernes y los sábados completos durante dos años, a veces consideran que “no tienen tiempo” de asistir una vez al mes a un evento de Networking o que “es demasiado caro”.

Hay muchas formas más de ir construyendo nuestro “MBA Personal” en Networking: congresos, cursos, seminarios… Todos ellos con un coste menor que el de un master, y con la posibilidad de centrar los contenidos (y, con ello, a los asistentes) en función de nuestras áreas de experiencia o interés. Luego están todas las herramientas que Internet está poniendo a nuestra disposición: redes On-Line como LinkedIn o Xing, la blogosfera, foros, wikis…Comunidades profesionales, asociaciones, colegios, incluso ONG’s. Las posibilidades son realmente increibles. Pero claro, requiere un esfuerzo de organización personal, que comienza por ser consciente de cuáles son nuestros objetivos concretos cuando emprendemos un proyecto de Networking personal, qué podemos ofrecer a los demás y cuáles son los medios óptimos para lograr nuestros objetivos con los recursos con los que contamos. Quizá por eso el “Activo” de Networking Activo.

Si con todo ello no os convencéis de lo importante que es el Networking y lo asequible que realmente resulta, pensad una cosa: el año pasado, Antonio Calvo-Armengol, de la Universidad Autónoma de Barcelona, publicó un estudio en el que diferenciaba entre contactos fuertes, los más cercanos y personales, y contactos débiles, los que se consiguen en primera instancia vía Networking. Las conlusiones del estudio demostraban que los contactos débiles son más utiles a la hora de, por ejemplo, encontrar un nuevo trabajo o nuevas oportunidades de negocio, ya que los contactos más cercanos sólo nos aportan información que ya solemos tener, mientras que los débiles actúan como puentes entre las islas que forman los grupos de amigos más cohesionados. Estos puentes que nos brinda el Networking favorecen así el flujo de información entre las islas cotidianas. Los trabajos de Antonio sobre redes sociales y mercado laboral se basan en las más modernas teorías económicas y podéis encontrarlos en la red. Os los recomiendo como vuestro primer paso en pos del Master Personal en Networking.

Publicado en Emprendedores, Gestión | Etiquetado , , , , | 3 comentarios

Scrumsourcing

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:-)

Publicado en Gestión, Gestión de Proyectos | Etiquetado , , , , , | 9 comentarios