Una sola persona

Escrito el 27 de Mayo de 2010 a las 10:39 

Hace poco hablaba sobre cambio, desarrollo y kaizen en uno de mis cursos, y uno de los asistentes apuntó que “los cambios los tendrían que hacer los de arriba”. Cuando empecé a argumentar que todo el mundo tenía que aportar en su medida y que el cambio es cosa de todos, me interrumpió diciendo “ya, pero es que una sola persona no puede cambiar nada“. Intenté decir que personas solas como Ghandi, Lennon, Buda, Sócrates, Lao Tze, Luther King o Mandela habían creado cambios significativos a nivel mundial, pero se armó una pequeña tangana en la clase y tuve que sacar mi probervial “manguera de butano” y liarme a gomazos con los riñones de los subversivos hasta retomar el hilo del curso :twisted:

Pero la verdad es que me quedé tocado, porque una afirmación como “una persona sola no puede cambiar nada” torpedea drásticamente la línea de flotación de todo en lo que realmente creo. Lamentablemente, o la gente cree en la proactividad, entendida como darse cuenta de que es uno mismo el que tiene las riendas de su propia vida, o no cree en absoluto. Y uno puede ir sembrando argumentos y ejemplos, pero hasta que algo no hce “click” en la mente de la persona, no hay mucho más que se pueda hacer. Y la mayoría de las veces ese “click” no llega a producirse nunca.

Pero incluso si uno no llega a fichar por el bando de los proactivos, los emprendedores, los innovadores, los revolucionarios, los líderes o, llanamente, los luchadores, incluso en ese caso hay un argumento que me faltó en aquel momento, y que aprovecho para archivar aquí: una persona sola puede concienciar al resto. Quizás no puedes enfrentarte solo a la maquinaria corporativa, la cultura imperante o la inercia burocrática, pero a veces basta con que alguien señale el problema públicamente y ayude a que todo el mundo vaya formándose una opinión común sobre la solución necesaria. Y entonces ya no se trata de una persona sola.

Es una versión constructiva de lo que yo llamo “el derecho al pataleo”, probablemente el penúltimo derecho que nos queda ante una situación desagradable en la empresa. ¿Que cuál es el último? El último derecho es pirarse a otro sitio donde sí escuchen a las personas, claro ;-)

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

Conferencia Agile Spain 2010

Escrito el 11 de Mayo de 2010 a las 18:20 

agilev230largo_.png

Ya deberíais etar al corriente, pero por si las moscas: los días 10 y 11 de Junio se celebra la primera conferencia sobre metodologías Ágiles en España, organizada por la Asociación Agile Spain. Tengo el placer y el privilegio de que me hayan seleccionado dos sesiones (sobre itinerario de implementación Ágil y sobre gestión de equipos Ágiles) y un taller conjunto con Xavi Albaladejo sobre dirección de retrospectivas, cosa que me hace especial ilusión porque, aparte de que Xavi es un profesional al que respeto profundamente y del que seguro aprendo muchas cosas nuevas preparando este taller, creo que las retrospectivas son la gran herramienta Kaizen de metodologías como Scrum, y creo que la gente tiene muchos problemas para sacarle todo el partido que debería. También tendré el lujazo de asistir a Henrik Kniberg en su taller sobre mapas de flujo de valor y Kanban, ya que al ser en inglés puede que algunos de los asistentes necesiten algo de atención perrsonalizada.

Las inscripciones a la conferencia ya están abiertas, y el programa disponible. Las plazas son limitadas, especialmente en el caso de los talleres, por lo que os recomiendo a todos que os apuntéis cuanto antes (¡queda un mes y contando!).

Algo que quería hacer desde aquí es felicitar al equipo que está organizándolo todo, al que intento apoyar en la medida de mis posibilidades, porque ninguno vive de esto y sin embargo la dedicación que le están poniendo y la calidad de los resultados creo que hablan por si mismos. Si es que cuando un equipo Ágil se pone… ;-)

Categorías: Eventos
Tags: ,,,,,
Deja un comentario | Compártelo

¿Horas ideales o puntos abstractos?

Escrito el 11 de Mayo de 2010 a las 18:10 

Artículo ladrillaco por encargo, como los escritores de verdad :-D . Es técnico y está muy orientado a las metodologías Ágiles, pero creo que todo el que tenga que realizar estimaciones en un proyecto se puede beneficiar de muchas de las ideas que contiene. Allá vamos.

Me escribe uno de mis clientes-y-a-pesar-de-ello-amiguetes comentándome la dificultad que tiene para convencer a sus equipos de que estimen en “puntos abstractos”, una técnica Ágil empleada, entre otras cosas, para enfatizar que en un buen proceso de estimación el foco no está en la precisión, algo casi imposible de lograr en un entorno complejo como el del desarrollo de software, sino en tener una idea común de cómo de grande y compleja es cada historia y, a partir de esa idea, concentrarse en trabajar con la velocidad del equipo como métrica. De hecho, la velocidad es la métrica Ágil por excelencia, y en mi opinión es la medida última de madurez de un equipo de desarrollo: lo rápidamente que puede satisfacer las necesidades del cliente con un producto de calidad.

Vamos a empezar por lo básico. ¿Por qué inventar cosas raras cuando todo el mundo estima en horas-hombre o en días-hombre, algo intuitivo, lógico y que se basa en un patrón perfectamente conocido como la hora o el día? Bueno, es cierto que las horas son una medida muy bien definida cuando hablamos de lo que tarda una máquina en hacer mil tuercas, pero cuando empezamos a intentar definir lo que tarda una persona en hacer algo, la cosa se complica. Porque las personas no son como las tuercas: no vienen todas en la misma medida. Y si hablamos de campos como el software, en el que según Pilar Jericó contaba en su libro “Gestión del talento”, el mejor de su campo es 50 veces más productivo que la media, entonces lo de la hora empieza a desmoronarse.

Así pues, si un experto tarda ocho horas en hacer algo realmente sutil y complejo, el programador promedio tarda veinte horas y un Junior tarda treinta y cinco… ¿Cuál es la estimación que debemos dar a esa tarea?

La respuesta lógica sería que la estimación dependerá de la persona que vaya a realizar esa tarea. Pero eso nos obliga a definir desde el principio quién va a hacer cada tarea del proyecto hasta el día de su finalización, y a reajustar constantemente esa asignación conforme vaya apareciendo incertidumbre en el proyecto.

Demasiada e innecesaria gestión.

Por ello se deberían estima las tareas contra un “programador mítico promedio e ideal” y lo que este señor tarda en hacer cada cosa. De ahí libros legendarios como “The Mythical Man Month”, que debería leer todo el que esté en este negocio de crear software y, en mi opinión, todo el que gestione proyectos de cualquier tipo. Lo que pasa es que definir las capacidades de ese “programador promedio” no es sencillo: ¿Tarda lo mismo en una tarea de Java que una de .Net? ¿Sabe de bases de datos? ¿Hace el diseño? Y aunque resolvieramos todo esto, seguiríamos teniendo otros problemas.

Por ejemplo, los de medida de la productividad. Hay grandes gurús de esto que predican que no es posible medir la productividad de un programador. Yo no es que discrepe, pero añadiría “aunque se puede aproximar muchísimo, sobre todo si medimos al equipo en lugar de a la persona”. La tesis básica es la siguiente: si tú has programado ocho horas, y yo he programado ocho horas, ¿hemos programado lo mismo? O dicho de otra forma, ¿hemos producido la misma cantidad de funcionalidad?

Y en contra de la lógica que nos indica que no, lo que hace la industria del software es poner un “precio medio” por hora y dedicarse a contar todas las horas que meten los programadores ante sus teclados. Y claro, no me gusta encontrarme al final de la semana con que alguien mete menos de cuarenta horas. Que las reuniones de trabajo, los correos, la gestión del proyecto, la formación, el I+D, el team building, las retrospectivas, las entrevistas a candidatos, la redacción de informes y todo lo demás que no sea programar se supone que lo hacen los programadores en sus horas libres porque les gusta. Sonamos. En fin, prefiero no hablar de las herramientas de seguimiento horario, que luego dicen que soy un sobrao :twisted: .

Seguimos con los problemas: si este año cada programador mete cuarenta horas de programación a la semana, y el año que viene sigue metiendo cuarenta horas de programación a la semana… ¿Ha aumentado la productividad? Alguien diría que no (se facturan las mismas horas), pero a lo mejor ese programador está cometiendo un 1% de los errores que cometía el año anterior, y está entregando cerca del doble de funcionalidades por semana que antes… ¿Y le seguimos cobrando lo mismo a los clientes? Es más, ¿Le estamos pagando lo mismo al programador? Que mal, ¿no?

Más razones, bordeando el campo de Earn Value Management (EVM): si en un proyecto de mil horas llevamos invertidas quinientas horas… ¿está la mitad del proyecto hecha? Respuesta típica: “esperemos por Diox que sí” :-D . Respuesta correcta: no lo sabemos.

Es por todas estas razones y alguna más que los equipos Ágiles maduros estiman las funcionalidades que deben desarrollar en función de su tamaño, no en función de las horas o recursos necesarios para construirlas. Sería, de alguna forma, estimar cuantos “kilos” de software vamos a entregar. O cuantos cientos de líneas de código (por el amor de $deity, no estiméis vuestros proyectos en cosas como ULOC’s , espero que no sea necesario explicar por qué :twisted: ).

Por ejemplo, podríamos escoger una funcionalidad prototipo que nos sirva como patrón. Ésta toma diferentes formas dependiendo del entorno tecnológico y de mercado que tengamos: puede ser un formulario básico de cuatro campos, un login/logout, una pantalla de móvil con una consulta a base de datos, un listado básico de AS400… La idea es localizar un “bloque” de trabajo básico que siempre, o muy frecuentemente, se da en nuestros proyectos, y asignarle a esta idea un valor: por ejemplo, cien. ¿Cien qué? Cien. Cien Chipiklanders, si os sentís mejor (pequeño y sentido homenaje al maestro Fuckowski).

Y ahora comparamos las demás historias del proyecto contra el tamaño de este prototipo. Esta historia es algo más del doble de grande… doscientos cincuenta. Esta es el triple: trescientos.

Ahora veamos qué pasa los primeros días que utilizamos puntos. Cuando sacamos la historia prototipo (un formulario con cuatro campos), el miembro senior piensa “bah, dos horas”, el promedio “cuatro horas” y el junior “ocho horas”. Si se ponen a discutir sobre cuantas horas necesitan, cada uno dice un número. Y todos tienen razón. Y todos están equivocados. Como en la historia del elefante.

Pero ahora es un “cien”, y todos están de acuerdo en que es un cien. De forma que cuando sale una tarea el doble de grande, el senior piensa “ok, cuatro horas”, el promedio “ocho horas”, el junior “dieciséis horas”… Y todos dicen “doscientos”. :-D

Este proceso interno de conversión personal de puntos-horas suele darse al principio. Es lo que lo llamo el “periodo de transición al euro”, en el que al principio nos decían “veinte euros” y pensábamos “ok, 6 euros son mil pesetas, 12 son dos mil, 18 son tres mil, y me quedan dos euros, que son 2 por 166 como algo, o sea algo más de trescientas… Uuuuuh… Tres mil trescientas pesetas”. Pero cuando ha pasado un tiempo suficiente, veinte euros es un cine con palomitas para dos, o dos menús, o una camiseta, o un tercio de depósito del coche… Ese número, que antes era abstracto, ahora tiene sentido para nosotros.

Otro de los problemas iniciales es que todo el mundo está muy acostumbrado a que se les pida precisión absoluta. De hecho, cuando les piden estimación generalmente lo que les están pidiendo es un compromiso, y eso funciona muy, pero que muy mal. Pero el caso es que cuando decimos “dame una estimación para esta historia, sabiendo que esta otra (aproximadamente la mitad) es un cien”, hay quien se bloquea con los detalles. ¿Esto es con patiflux de peristone o sin patiflux de peristone? ¿Los campos tienen que esgorziarse con el tetraconmutador cíclico? ¿Contamos con un condensador de fluzo? Detalles que, casi siempre, no tiene sentido ponerse a detallar en un proceso de estimación siempre que dejemos claro que el objetivo no es la precisión (esto daría para otro ladrillo importante ;-) ). Hay un ejercicio que suelo hacer en estos casos que es preguntar “¿Cuánto vale un adosado?”, sin más detalles. Si la gente no responde, voy diciendo cosas como “¿Un millón de euros? ¿menos? ¿cicuenta mil euros? ¿más? ¿doscientos mil euros? ¿trescientos mil euros? ¿Más trescientos o doscientos?”. Y al final hay un número. Que por descontado habrá que pulir, pero lo que me interesa ahora mismo es tener un primer orden de magnitud (¿diez mil o trescientos mil?), y eso es lo que procuramos al usar puntos. Porque si usamos horas o días, inmediatamente el subsconciente de los que luego van a tener que entregar el proyecto comienza a traducir la estimación en plazos de entrega. Y entonces comienzan otra vez los problemas.

Al grano: poco a poco el equipo comienza a familiarizarse con lo que es un “cien”, un “doscientos” o un “cuatrocientos”, y comenzarán a escoger en cada iteración tantas historias como consideren que pueden terminar totalmente (terminado, terminado) en una iteración (Sprint). Con el tiempo, en media, harán más o menos la misma cantidad de trabajo en cada iteración.

Y las palabras clave son “en media”.

Porque hay semanas buenas y semanas malas. Hay semanas que haremos tres mil puntos y semanas que haremos mil quinientos. Y lo malo es que muchos gestores entonces optarán por planificar de cara a tres mil puntos por semana. Cuando los consigan (semana buena), dirán “¿veis? ¿veis como cuando queréis podéis?”. Y cuando no los consigan (semana mala: muchos Bugs, reuniones, distracciones, retrabajos, peticiones de clientes…) dirán “es que no se os puede dejar solos, hay que estar con la vara encima de vosotros todo el tiempo”.

Lo lógico es no planificar de cara a tres mil puntos por iteración ni a mil quinientos, sino analizar la media sostenida. Si la media es dos mil y planificamos contra esa media, unas semanas andaremos retrasados, otras adelantados y, en media, cuadraremos los proyectos.

Y eso nos permite otra cosa importantísima: analizar cuál es nuestra velocidad media ahora y ver cuál será dentro de un año. Y entonces si podemos aproximar si nuestra productividad ha crecido o no, porque si hace un año nuestra media era de dos mil y ahora es de dos mil quinientos, podemos inferir una mejora de la productividad del 25%.

En resumen: la estimación en puntos cuenta con grandes ventajas para los procesos de estimación y gestión de proyectos, así como para la medida de la productividad y la mejora de los equipos de desarrollo, y el único inconveniente que personalmente he podido encontrarle con el tiempo es que es poco intuitiva de usar al principio… Como cualquier innovación basada en un cambio de paradigmas, por otra parte.

En fin, que espero que este granito de arena anime a algunos a investigar más sobre el tema, y si tenéis dudas o experiencias al respecto serán bienvenidas en los comentarios. ;-)

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

Emprender, crisis, subvenciones, funcionarios…

Escrito el 6 de Mayo de 2010 a las 10:57 

He conocido esta mañana a Susana García. Virtualmente, vaya, pero hay gente a la que ya conoces antes incluso de que te la presenten. Emprendedora, entusiasta, luchadora, incansable, ingeniosa… Y por tanto, rara avis e incómodo forúnculo (perdón, Susana ;-) ) en las mentes de los mediocres pesebreros paniaguados que marcan las políticas de ayudas e incentivos. Con este video viral trata de denunciar una situación que ya hemos vivido muchos en el camino del emprendizaje: comenzar pensando que hay cientos si no miles de líneas de ayuda y promoción del emprendimiento y darte cuenta de que, a pesar de que te consideras joven, innovador, preparado y, en definitiva, candidato perfecto a que alguien al menos te eche algo de cuenta, la realidad es que al final no das el perfil. Los viveros están llenos de empresas fantasma, la subvención TIC es para que te compres un portatil y una impresora, los programas de formación te los imparten cuatro “expertos universitarios” que no han gestionado una empresa en su vida, funcionarios y miembros numerarios del partido que toque, cuando no sindicalistas.

Y casi mejor, Susana, porque como te metas en alguna que otra, acabas toda la vida encandenada a un artificio promocional construido a mayor gloria de la entidad promotora, esperando subvenciones que nunca llegan, pidiendo créditos que se venden como blandos pero que en poco se diferencian de la oferta de cualquier entidad bancaria, encasillada a pequeños proyectos mal pagados para clientes ficticios, como por ejemplo otros organismos o empresas políticamente ligadas a la promotora y, lo que es peor, anudado a los ritmos de una (¿una?) administración que, a juicio de muchos, es la culpable del bajo nivel de competitividad de las empresas Españolas, ya que raro es el sector en el que la administración, en la forma en la que toque, no sea “el gran cliente”. Y encima endurecemos la ley de contrataciones para que solo los grandes monstruos, burocráticos y ministeriales como las administraciones mismas, puedan acceder a la parte del león de estos contratos, no sea que entre algo de aire fresco en un despacho y se nos desmenuzen las momias.

Encadenando pensamientos, a ver si así salgo del bloqueo creativo del blog que ya me dura: ayer en un programa de estos de reporteros-callejeros-viajeros salía una familia, orgullosa gestora de una gran red de academias que el año pasado movió 35 millones de euros preparando a más de siete mil españolitos cuya principal meta en esta vida es sacarse una plaza de funcionario. Chupense ustedes esta, Gautama Buda, Lao Tze, Sócrates, Eduard Punset y Paulo Cohelo, la iluminación y la sabiduría estaban al final en unas buenas oposiciones . Pues la familia en cuestión declaraba sin tapujos que su hija se había podido ir a vivir a un piso porque, a parte del estipendio dispensado por la familia, disfrutaba de una beca de 400 euros al mes. A ver, que tampoco tengo yo todos los datos y a lo mejor la cosa está muy justificada, pero que pensaba yo que el concepto de “beca” está unido semánticamente al de “subvención”, y lo que ha unido el DRAE no voy a venir yo a separarlo. Y subvención viene de “subvenir”: venir en auxilio de alguien o acudir a las necesidades de algo. Pues ya me contarán mis queridos y desatendidos lectores las necesidades de auxilio de la interfecta. Perdonen si me indigno, pero es que ese dinero lo pongo yo. Pero aquí, como dice el maestro Reverte, no passssssa nada. Porque cuando las administraciones tienen, cito a un V.C. extranjero, “way too much money” y poco talento para gestionarlo, al final todo lo que se nos ocurre es soltar la guita a manos llenas. Que además tiene el efecto estupendo de comprar y cautivar votos.

Pasta a manos llenas. Como decía Gomaespuma, “dinero no habrá, pero pa tontás…”. Pues sí. Pa tontás, todo el que quieras. Susana menciona varias. Y aunque sea un cierto ejercicio de catarsis, es verdad que uno, que se considera emprendedor, se siente maltratado por un entorno político hostil que, luego, dedica millones a analizar cómo se puede potenciar el tejido empresarial y el emprendizaje en un ejercicio digno del despotismo ilustrado: todo por los emprendedores, pero sin los emprendedores.

Me bizquea el izquierdo hacia Grecia, porque si no me falla la brújula del Android estoy mirando al sur. Apañados vamos.

PD: mi pequeña ayuda a Susana, aquí estan sus proyectos

-         
www.hazcoaching.com

-         
www.cursosdevoz.com

-         
www.susanagarcia.es

-         
www.ponlevozatunegocio.com

-         
www.regalosparabodasydivorcios.com

-         
www.grabacionesexpress.com

-         
www.lamujerinvisible.es

-         
www.lacasadelaswebs.com

-         
www.5000tarjetas.com

-         
www.regalosparadivorcios.com

Categorías: Emprendedores, Gestión
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