LeanCamp Barcelona

Escrito el 27 de Enero de 2012 a las 11:18 

El próximo sábado 11 de Febrero estaré por el LeanCamp Barcelona dando una charla sobre el lado humano de Lean… En Inglés, of course :-) . Habrá ponencias y debates muy interesantes sobre Lean Startup, UX, Agile, Customer Development y temas relacionados. Además, es un evento conectado internacionalmente (hay ediciones en Nueva York, Londres, San Francisco, Amsterdam…).

Para que vayáis calentando motores, aquí tenéis la charla sobre Lean Startup que dí en Polonia hace unos meses:

Angel Medinilla from e-nnovation on Vimeo.

ScrumWeek

Escrito el 24 de Febrero de 2011 a las 12:33 

La semana del 4 al 8 de Abril Plain Concepts y Proyectalis organizamos la ScrumWeek, una semana de formación con tres tracks separados en los que habrán sesiones sobre Scrum, Coaching de equipos Ágiles, Agile Management (gerentes Ágiles), cultura corporativa Ágil, un Scrum Clinic con Rodrigo Corral y conmigo, unit testing, visual studio, certificación PSD… En definitiva, creo que es una iniciativa bastante pionera en España y una muy buena oportunidad para todos los que ya conocéis los cursos de Proyectalis y de Plain Concepts y queréis ampliar conocimientos o tenéis a alguien en vuestra empresa que se ha quedado “rezagado” y podría ser interesante poder mandarle a un curso de refresco ;-) .

Los precios son también bastante competitivos, incluyendo varias sesiones gratuitas como las de Cultura Corporativa o las de Visual Studio Ágil, y hay plazas limitadas (que ya se están vendiendo), por lo que os animo a que si estáis interesados lo arregléis con vuestras empreasas cuanto antes. Ah, en este sentido, hay cursos de sólo mañanas (como por ejemplo el de Coaching de equipos Ágiles), con lo que debería ser más fácil convencer a vuestra empresa que os deje ir… Si vivís en Madrid, claro :-D .

¡Os esperamos!

Agile Lean Europe

Escrito el 24 de Febrero de 2011 a las 12:12 

Agile Lean Europe Si estáis interesados en Agile y en Lean, vivís en Europa y habéis estado viviendo en una cueva informativa durante la última semana tal vez se os haya pasado el nacimiento de una nueva red de profesionales y pensadores de Agile y Lean en Europa de la mano de Jurgen Appelo.

El propósito de esta red todavía se está discutiendo, pero con toda probabilidad incluirá el proporcionar una mayor visibilidad del proceso de transformación Ágil y Lean en Europa, actuar como centro de soporte, recursos y colaboración para todos los profesionales de Agile y Lean y organizar algún tipo de gran evento europeo en el que todos los que trabajamos en este tipo de entornos podamos intercambiar información (aunque algunas ya han apuntado que eventos existentes como la XP o Lean Kanban Europe podrían proporcionar este marco).

Ahora mismo la red se ha creado en LinkedIn y, en pocos días, ha alcanzado casi 350 miembros. ¡Enhorabuena, Jurgen :-D ! La verdad es que espero que grandes cosas y grandes ideas surjan de esta iniciativa, y tengo muchas ganas de comentarlas con varios de los miembros de esta red en el próximo XP2011 (Madrid, Mayo).

Saraos, extremistas, fotos, videos y presentaciones

Escrito el 27 de Noviembre de 2010 a las 10:14 

Octubre y noviembre han sido dos meses ajetreados. A los habituales proyectos de formación y consultoría se han unido dos eventos interesantes: El Agile Open Spain 2010 y el Amsterdam Scrum Gathering.

Del Agile OPen Spain 2010 tenéis un par de fotos aquí. Me volví con una sensación agridulce, la verdad. Por una parte, es patente como ha subido el nivel del evento, con mucha más gente dispuesta a aportar experiencia real y con preocupaciones más relacionadas con la implementación y práctica de metodologías Ágiles que con descubrir de qué tratan. Bien por la comunidad Ágil española. Pero por otra se pudo respirar muy evidentemente algo que ya se intuye por los espacios virtuales: se están creando dos corrientes de pensamiento, y una de ellas está de alguna forma enfrentada a la otra.

Concretamente, existe un nucleo duro de “Anarco-sindicalistas del teclado;-) que han creado un espacio extremista en el que “lo único” importante es la programación, el código bonito, TDD, disfrutar programando, la excelencia técnica y las camisetas con chistes en binario. Que no es que no sea importantísimo. Pero no es “LO” importante, en plan “todo lo demás es malignmo y debe ser descartado de la faz de la tierra”. Para ellos, “Scrum es cosa de gerentes” y los procesos son algo a ser destruido junto con la documentación, las herramientas, los contratos y los planes. Es decir, realizan una lectura extrema del manifiesto Ágil y se olvidan de la parte de “aunque valoramos los elementos de la derecha, valoramos más los de la izquierda“.

Son gente que dice cosas como “no se puede programar sin TDD” (aunque productos como Linux o Apache se hayan hecho sin TDD), “no se puede ser Ágil si no haces programación orientada a objeto” (aunque haya gente haciendo Agilidad en Cobol o, ya puestos, en Marketing o en equipos que hacen televisión) o “no se puede hacer Scrum sin técnicas de programación Ágil”. Que no es que “La excelencia técnia no mejore la agilidad”, por citar un principio Ágil, pero en ninguna fuente autorizada sobre el universo Ágil se citan estas técnicas como condición “sine qua non” o “necesaria y suficiente” para ser Ágil.

De hecho el manifiesto cita cuatro valores, ninguno de los cuales se refiere directamente a la ingeniería, y 12 principios, de los cuales solo uno cita una “mejora” de la Agilidad mediante la aplicación de la excelencia técnica.

Insisto: me paso la vida evangelizando sobre cosas como la automatización de tests, la propiedad colectiva de código, los estándares de programación, la integración continua e incluso los repositorios de código y el control de versiones. Creo que en pleno siglo XXI un equipo que busca la mejora continua acabará tarde o temprano enfrentado al estado del arte. Pero si de buenas a primeras te atrincheras en un elitismo taliban y, además, condenas cualquier cosa que huela a proceso u organización, luego no te quejes de lo dificil que es que te dejen ser Ágil en la empresa. Porque para empezar, no has entendido nada.

El problema es que muchas masas oprimidas en las trincheras de la programación se están arremolinando en torno al ideal libertario de los verdes pastos de la comuna digital y se están creyendo cosas como “si el código está bien hecho, lo demás no importa”. Hartos de entornos viciados, compañeros tóxicos y jefes incompetentes, creen que la salida es echarse al monte compilador a cuestas y entonar cánticos de integración continua y refactorización en torno a la hoguera comunitaria del subversion.

Bueno. Tiempo al tiempo. :-(

El otro grupo (en el que me auto-alineo, claro), discute frecuentemente sobre aspectos culturales de la Agilidad, el comportamiento de las personas, la frontera entre disciplina y auto-organización, los procesos que no se anteponen a los individuos, la mínima documentación que debe existir con cada incremento de código funcionando, negociar y colaborar con el cliente, crear equipos de alto rendimiento, las retrospectivas, los planes de mejora, la adaptación al cambio, el concepto de valor, el diseño emergente, la definición de set mínimo de funcionalidades con valor de mercado, el coaching de equipos, personas, gerentes y clientes, los contratos que reflejan nuestra forma de trabajar, la gestión de proyectos, los sistemas complejos… Y no condenamos las prácticas de ingeniería ($deity nos libre). De hecho las recomendamos. Y sin embargo existe un cierto interés en hacernos aparecer como “el enemigo”. Dejo a criterio del lector el decidir por qué, que bastante me estoy mojando ya con este rant.

He estado también como decía en el Amsterdam Scrum Gathering, del que tenéis varias fotillos aquí. Será porque “Scrum es cosa de gerentes”, pero ni aquí ni en la Lean Kanban Europe pude respirar este mismo clima de “talibanismo técnico” que me pareció respirar en la #aos2010.

Tuve la oportunidad de hacer una lightning-talk o “charla relámpago”, de la que pude grabar este video (la presentación está aquí):

Sustainable Pace: The Boxer, The Aikidoka and the Katana Suburi from Proyectalis on Vimeo.

También pude hacer un Ideacamp sobre Scrumban parecido al que hice en a Agile Open Spain. Gustó tanto que varias personas me pidieron que hiciera un “whitepaper” sobre esta aproximación, pero como eso es muy aburrido en su lugar he hecho esta presentación que espero que pueda ayudar a los que intentan compaginar Scrum con un entorno de alta incertidumbre en el que, en el día a día, siguen surgiendo muchas otras cosas que también deben ser atendidas:

La experiencia del Lean Kanban Europe y la del Scrum Gathering han sido tan buenas que me he decidido a abrir un blog en inglés dedicado específicamente a la Agilidad. Seguiremos informando ;-)

Actualización: borraré inmisericordemente cualquier comentario en la línea de “para ti las prácticas de ingeniería no son importantes / son secundarias / son optativas”, ya que no es eso lo que he dicho como cualquier lector con dos dedos de frente podrá interpretar ;-) ;-) ;-)

Resaltado en Slideshare

Escrito el 1 de Octubre de 2010 a las 9:06 

No hay como hacer los power point en inglés y hacer un poco de Marketing… Pero el caso es que los de Slideshare han colocado una presentación mía entre los destacados de Business & Management durante 16-20 horas, a ver qué sale de esto :-D

Slideshare Business and Managemente

Por qué digo que no hay una industria del software en España

Escrito el 30 de Septiembre de 2010 a las 10:56 

Bueno, la primera razón es que me gusta el rollo “profeta del apocalípsis” :twisted: : me da muy buen resultado en las charlas, como en esta de la Conferencia Agile Spain 2010, en la que solté esta perla y fue ampliamente comentada:

Pero en serio, el caso es que llevo tiempo queriendo escribir sobre el tema siguiendo con la línea de mis dos post anteriores (consultoría Don Simón, Chapatas calentitas), y el hecho de que Xavi me haya remitido hoy un enlace a este artículo referenciado en barrapunto me empuja a hacerlo. La verdad es que coincido en gran mayoría de los aspectos y argumentos comentados por el autor, y específicamente la diferencia fundamental y no entendida entre los procesos de fabricación industrial (Taylorismo / Fordismo) y la naturaleza intrínseca del desarrollo de software es algo que se ha comentado ampliamente en la comunidad Ágil y que podéis ver en algunas de las presentaciones que he realizado al respecto (verbigratia, esta slide).

Naturalmente, cualquier afirmación grandilocuente, generalista y extrema como “No hay una industria del software en España” es tremendamente injusta, ya que al fin y al cabo se trata de un recurso retórico ;-) . Por supuesto que hay empresas dedicadas al software. Pero el promedio de la industria no es ese, y la dispersión respecto a la media no es muy grande que digamos. Si nos preguntamos cuál es la industria media del software en España, habrá poca gente que piense cosas fuera de un circuito “consultoras, banca, administración…”. Y ahí es donde digo que eso no es una industria del software, porque este tipo de empresas no te venden un software: te venden “horas de programador”. Como si una hora de programador fuera una commodity, es decir, algo perfectamente intercambiable por la hora de cualquier otro programador, y cuyo único valor reside en la cantidad de producto que poseemos o negociamos.

Oh. Dios. Mío. Las cosas pueden estar algo más rotas, pero no mucho, la verdad.

Pensamientos como este conducen a desastres organizativos como las “líneas de montaje” consultor-analista-desarrollador-tester en las que diagramas UML, mapas entidad-relación, modelos de datos y documentos de requisitos viajan por correo electrónico entre personas que no hablan nunca entre ellas. Como si un programador fuera una máquina a la que alimentamos con UML y escupe código. Y claro, en algún momento acabamos por pensar si no habría forma de diseñar algún tipo de máquina o herramienta (no se, llamemoslas CASE) para librarnos del incordio de los programadores, que son unos tíos raros que llevan camisetas frikis, huelen mal y protestan por todo. Bloody programmers. :-D :-D

¿Veis lo roto que llega a estar todo?

Claro, si al final la oferta se basa únicamente en “horas de programador” y no en producto, la discusión comercial ya no va en términos de funcionalidad, calidad, rendimiento… Si discutimos cobre una commodity, como por ejemplo el petroleo, solo discutimos el precio del barril y dónde me lo vas a entregar. Y cuando de repente vendo diez mil barriles, da igual si cojo dos mil de aquí, tres mil de allá, cuatro mil de acullá y luego voy “sisando” otros mil barriles poco a poco de otros sitios: el proyecto ha sido un éxito.

Pero cuando intento hacer una operación a corazón abierto, a nadie se le ocurre que la primera hora la haga un cirujano, la segunda otro distinto y la tercera ya veremos si pillamos a alguien por el pasillo para que la termine. La ventaja con la que cuentan los médicos es que ya llevaban miles de años gestionando hospitales antes de que los industriales del automovil se alzaran como adalides de la producción en cadena, las economías de escala y los sistemas MRP.

Lo mismo ocurre con los equipos de desarrollo. Nadie que de verdad conozca cómo funciona la creación de un producto sofwtare puede pretender que enfoques como el “pool de recursos” proporcionen mejor rendimiento que un modelo basado en equipos comprometidos, autogestionados y capacitados. Tendré que hacer otro articulo para hablar de los factores de motivación inherentes al trabajo en equipo y su efecto en el rendimiento cerebral de una persona a la que, en realidad, no pagamos por calentar un asiento o imputar horas de “farmville” al proyecto, sino por resolver problemas complejos y únicos de la forma más eficaz y eficiente posible.

¿Alguien puede creerse aun que las economías de escala funcionan necesaria y directamente en el mundo del software? Si eso es así, y teniendo en cuenta que una consultora puede considerarse afortunada si genera entre 60.000 y 200.000 euros por empleado, ¿Cómo es posible que compañías como Craiglists, con 30 empleados, generen un ratio de más de tres millones de dólares por empleado? ¿Cómo consigue 37Signals, creadores de Basecamp y Ruby on Rails, dar soporte a más de tres millones de clientes con una plantilla de en torno a 18 personas?

Y seguimos sin entederlo. Medimos los proyectos por el número de horas que imputamos, y claro, si te acercas a una de estas empresas y les dices “puedo enseñarte cómo hacer ese proyecto de doce años en solo uno” te miran con cara de susto y te responden “¿tú eres idiota? ¿por qué debería cobrar sólo por un año si puedo cobrar por doce?”.

Y tienen razón. Y ganan pasta. Mucha.

No vendemos software: vendemos servicios. Vendemos disponibilidad, horas suboptimas de bajo rendimiento pero en gran cantidad y baratas, muy baratas, más baratas. Las primeras compañías que se dieron el batacazo con el offshoring ya se dieron cuenta que externalizar el trabajo a una compañía que te vende las horas a mitad de precio no es tan buen negocio si luego las horas crecen al cuádruple porque no sabemos gestionar bien proyectos con el “ruido” que introduce un entorno offshore o porque los programadores tan baratos que nos han vendido no distinguen un ordenador de un piano. El panorama ha cambiado y después de décadas de offshoring los proveedores de estos servicios han descubierto muchas cosas respecto al negocio en el que operan, y ahora mandan a gente al origen para que haga de puente entre sus clientes y ellos, forman a sus trabajadores, protegen a sus equipos… Y usan metodologías Ágiles de desarrollo, pero esa es otra historia.

Tengo muy pocas esperanzas puestas en que el negocio de las “cárnicas” cambie, pero las pocas que existen están en el lado del cliente más que en la capacidad de los equipos y miembros de estas empresas para cambiar una mentalidad directiva que solo ve los resultados desde la perspectiva del dividendo y la cifra de negocio. Las consultoras comienzan a llamarme para que las forme porque sus clientes empiezan a exigir enfoques Ágiles de los proyectos, y esto es una gran noticia. Esperemos que la cosa prospere a partir de ahí: mucho más bajo no podemos ir… ;-)

Proximos saraos

Escrito el 22 de Septiembre de 2010 a las 10:03 

Un poco de Spam, que para eso el blog es mío: aparte de todo el trabajo privado que ando haciendo en empresas, tenéis oportunidad de asistir a cursos y charlas en los siguientes “saraos”:

Tenéis las convocatorias de CEIN aquí y la información del Agile Open Spain aquí. Ah, estaré el viernes en Lean & Kanban Europe 2010, pero creo que a esta ya no llegáis… :twisted: . También estoy intentando que me inviten al Scrum Gathering de Amsterdam, para lo cual me vendría bien que votaseis esta charla…Anda, venga, promocionemos internacionalmente el producto patrio… :-D

Charla sobre Lean y Kanban

Escrito el 27 de Abril de 2010 a las 22:41 

Un par de líneas para dejaros esta charla realizada en el marco de las presentaciones sobre Itinerario Ágil organizadas por CEIN en Pamplona. Gracias a todos los asistentes, a los que espero ver en las próximas citas que tenemos dentro de este ciclo de charlas.

Scrum: El Señor de los Pardillos

Escrito el 29 de Marzo de 2010 a las 8:57 

En realidad me pidieron que diera una charla sobre Scrum y desarrollo Ágil, pero con ese título iba a sonar un poco fuera de lugar en un evento como el XGN, así que al final decidí echarle un poco de fantasía y… Bueno, dejo que lo veáis vosotros mismos. En breve el video y la presentación en Inglés ;)

Actualización: primer video subido. Hay que trabajar el tema del sonido en el futuro, me veo comprándome una petaquita de esas de ponente serio (tendré que ver si mi cámara tiene entrada de audio, que espero que sí…) . En breve el segundo video.

Actualización 30/3/2010: La presentación está disponible en Inglés gracias a la colaboración de Jaime Buelta… Espero que sirva para evangelizar allende fronteras (y espero que a Peter Jackson no le de por ponerse medieval con mi c…. :-D ).

Actualización 1/4/2010: Segunda parte del video

Próximas charlas

Escrito el 18 de Marzo de 2010 a las 16:34 

En los próximos meses tengo varias charlas programadas, por si alguien tiene interés y posibilidad de asistir a alguna:

Videos de charla en Biko2

Escrito el 13 de Marzo de 2010 a las 21:26 

Como intuís por la (baja) frecuencia de publicación, voy hasta arriba desde que empezó el año, ¡que vivan los brotes verdes! No obstante intentaré ir subiendo algunas de las muuuuchas cosas interesantes que tengo cuasi-listas para publicar: muchos videos, algún white-paper, un ejercicio de Scrum para simulación de sprints, una aplicación de XP a la realización de documentos, una traslación de 5S a software, una aproximación a “Lone Scrum” (Scrum como herramienta de productividad personal)… como os digo, muchas cosas. Como muestra, un par de videos montados por los amigos de Biko2 en los que cuento algunas de mis metáforas clásicas como el horno de las magdalenas, los orcos a las puertas o “imprimir la wikipedia”:

Actualización 13/3/2010: Me he precipitado un poco y los videos están aun en modo privado, calculo que el lunes los amigos de Biko los publicarán. Atentos a sus pantallas. ;-)

Kanban vs Scrum en castellano

Escrito el 28 de Enero de 2010 a las 10:49 

Como algunos sabéis, hace ya un par de añitos traduje desde Proyectalis el magnífico libro “Scrum y XP desde las trincheras” de Henrik Kniberg, uno de mis heroes Ágiles de todos los tiempos. Las razones que me llevaron a ello fueron varias. Fundamentalmente, mi consideración sobre la estupenda calidad de la obra, el caracter abierto de la misma (podéis descargarla gratuitamente en InfoQ o en Proyectalis) y el convencimiento de que uno debe devolver algo a la comunidad de vez en cuando. Esto vale para el software libre, las presentaciones de Slideshare, los libros abiertos, los wifi sin contraseña y cualquier otra cosa de la que os estéis beneficiendo de forma gratuita: si creeis en los mecanismos de retribución Kármica, y ya sabéis que yo lo hago a pies juntillas, hay que ir compensando lo que uno recibe o se genera una deuda, y las deudas es lo que tienen, que crecen exponencialmente. Total, que la cosa fue bien, porque conseguimos bastantes enlaces, tráfico y el pagerank de Proyectalis mejoró. Karma wins again.

Ahora Kniberg ha sacado un nuevo trabajo comparando Scrum con una aproximación nueva que se está realizando a los procesos de desarrollo: Kanban. Kanban no es nuevo para nada, surge como todas estas herramientas y disciplinas en el seno del sistema de producción de Toyota, “la máquina que cambió el mundo”. Consiste en la generación de una serie de tarjetas que representan los productos que se están desarrollando y que actuan como testigos de una carrera de relevos a lo largo de la línea de producción, disparando los eventos de fabricación conforme van siendo necesarios. La ventaja que pregonan los partidarios de Kanban para el desarrollo de software es la reducción del número de reglas y obligaciones respecto a otras metodologías: nada de planificación de producto, nada de scrum diario, nada de retrospectivas; sólo flujo productivo, priorización y limitación del número de tareas en curso en un momento dado (WIP o Work In Progress).

Es un planteamiento muy positivo para equipos que ya han “disuelto la regla” de Scrum y han interiorizado muy bien el proceso, o bien para equipos de mantenimiento u operaciones en los que los “tickets” deben ir atendiéndose conforme van generándose y no es factible realizar planificaciones ni predicciones a medio o largo plazo. El problema estiba en que equipos sin experiencia previa en Ágile se vean atraidos por la simplicidad de Kanban y entonces no lleguen a interiorizar los importantes conceptos contenidos en los roles, procesos y artefactos de Scrum. Por ello este trabajo de Kniberg, en colaboración con Mattias Skarin, es tan importante para todos aquellos que quieran iniciar una experiencia con Kanban, ya que en él resumen tanto las diferencias como los parecidos y la manera de combinarlos ambos de la forma más efectiva posible.

Hay que reseñar que esta vez la traducción ha sido coordinada por Proyectalis pero realizada por el equipo de contenidos de Agile Spain. Concretamente hay que agradecer la colaboración desinteresada de Rodrigo Corral, Teo Sánchez, Gregorio Mena, Laura Morillo Velarde, Ángel Agueda (Legnita), Jorge Uriarte, Agustín Yague, Juan Palacio, Xavier Quesada, Javier Sánchez, Jorge Jiménez y Juan Carlos Quijano.

Así que aquí lo tenéis. A la fecha de redacción, y por culpa de as múltiples versiones de MS Word y el puñetero filtro PDF de Mac, la versión PDF pesa unos 74Mb (OMG!), pero procuraremos bajar esa cifra en los próximos días. Si alguien no tiene tanta paciencia, lo podéis ir bajando ya de aquí.

Actualización 29/01/10: nueva versión, con un peso mucho más razonable aunque con mayor margen… Gracias a Xavi Albaladejo y Antonio Kobashikawa por liarse con el PDF (es probable que subamos una versión con márgenes correctos pronto, ¡Beta perpétua!). Ah, por cierto, lo lamento por todos los que se han “fusilado” este artículo en sus sitios en vez de enlazar aquí, pero el enlace anterior ha dejado de funcionar… ¡Oooh, que mala suerte! :twisted: . Esto os pasa por enfadar al enanito del Karma… :-D :-D

Scrum Multiproyectos, Métricas y Agile EVM

Escrito el 16 de Enero de 2010 a las 15:33 

He subido a Slideshare un pequeño extracto de nuestro seminario de gestión del portfolio de proyectos aliñado con unas pocas slides de nuestro curso de introducción al PMBOK desde una perspectiva Ágil, en el que introducimos el concepto de Earn Value Managemente aplicado a proyectos Ágiles y Scrum Multiproyectos (oh yeah!). No se, ayer en la ducha (suele ser mi momento más creativo e inspirado del día, qué cosas… :-D ) se me ocurrió que tenía sentido reordenar este conjunto de slides en esta forma y dar un poco de vidilla a un concepto que está poco trabajado tanto en la literatura como en el material disponible on-line: que pasa cuando salimos del típico ejemplo de libro de “un cliente, un equipo, un proyecto” (Ein Volk, ein Reich, ein Führer! :twisted: ), al auténtico carajal que vivimos todos en las trincheras reales: múltiples clientes, múltiples proyectos en distintos momentos del ciclo de vida (unos cerrándo, otros en preventa, etc.) y múltiples equipos, a veces compartiendo proyectos (relaciones “muchos a muchos” y esas cosas). Y nada, que aquí lo dejo. Ya sabéis que estoy disponible para montar saraos y hablar de estas cosas si os ape ;-)

Nota: que pasada como abuso de los paréntesis… Y de los puntos suspensivos :twisted: . Propósito de año nuevo al saco. ;-)

Charla en Pamplona

Escrito el 28 de Noviembre de 2009 a las 13:13 

Ayer viernes dí una charla-desayuno en Pamplona invitado por mis clientes y a pesar de ello amigos de Biko2 ;-) . Asistieron mayoritariamente gestores de IT de empresas como (así de memoria), Caja Navarra, Microsoft CEIN, Aranzadi, Tracasa y representantes del Gobierno de Navarra y el Gobierno Vasco (por cierto, gracias a los que vinísteis de lejos).

Visto lo visto en twitter, y sin falsas modestias, parece que oficialmente lo hemos petado :-D :

Como había poco tiempo, organizamos la charla en sprints, de más prioritario a menos, y lamentablemente no nos dio tiempo a arrancar el sprint 3 (contratos). Para los que os quedásteis con las ganas, tenéis la presentación completa de contratos en Slideshare y la charla de Autentia grabada en video aquí y aquí.

La presentación que usamos ayer en Pamplona fue esta (es un poco refrito de las que ya conocéis los que seguís mis pobre-poings, pero bueno… Tendré que empezar a renovar un poco el repertorio para los habituales :-D :-D ):

¿Quién dirige y quién paga?

Escrito el 20 de Noviembre de 2009 a las 19:57 

El cliente, of course. Fin del artículo, estoy muy liado.

Bueeeeeeno, vaaaaale, es verdad, llevo un montón de tiempo sin escribir, vamos a darle un mínimo de literatura.

La cosa surge hace unas semanas en un proyecto con un cliente en el que estoy proponiendo, como ya he hecho con éxito en otros muchos sitios, montar una tarde de viernes de cada dos como “tarde de laboratorio”. La idea no es mía directamente, la tomo prestada de Henrik Kniberg, y como está en Internet a disposición del respetable sería tontería guardármela en plan “secreto de empresa” o “know how”. Ala, el que quiera ya puede ponerse a ello, que el mercado es de todos. Arrieritos somos :-D .

Suponiendo una tarde cada dos semanas, la inversión total de I+D de la compañía estaría por debajo del 5%, algo que considero peligrosamente bajo en una empresa que depende fundamentalmente del capital humano y del conocimiento y capacidad de sus desarrolladores, pero por algo hay que empezar. Total, que el cliente a priori acepta bien la idea, pero hay una cosa que no acaba de ver claro. ¿Cómo le dice al cliente (al suyo) que los desarrolladores no están a piñón con el proyecto, que están “jugando” en el laboratorio?

Ahí es donde yo me quedo a cuadros claro. Quien me conoce sabe que no creo que los desarrolladores puedan sacar más de seis horas buenas-buenas de programación al día, y eso defendiéndolos a saco de interrupciones y context-switching. Lo que nos deja dos horas al día para slack (relajación, desayuno, café, facebook, twitter, blog ;-) ), gestión del proyecto, actividades de la empresa (informes, reuniones), I+D (incluiría la formación aquí) y, lo que hay que perseguir, gasto, el enemigo en Lean: re-trabajos, esperas, errores y mantenimientos, pérdidas de tiempo, procrastinación, charlitas de pasillo…

Todas esas cosas nadie las cuestiona. Se hacen. Cuando los desarrolladores reportan otra estupenda semana de 40 horas dedicadas al proyecto dormimos tranquilos, pero la verdad, la terrible verdad, es que muchas veces ni siquiera han salido 20 horas buenas en la semana. Que demonios, a veces no salen ni diez. Pero reportamos 40, el Jefe de Proyecto contento porque se factura y el cliente preocupado porque no entiende cómo leches después de 40 horas con el proyecto apenas tiene una pantallita de bienvenida a la aplicación. “Es que esto es muy complicado, Jefe”. Facturita al canto.

A lo que vamos: que podríamos ser honestos y, si cobramos 1.500 euros por consultor a la semana, reportar 20 horas a 1.500 euros. Pero entonces los chapuceros de nuestra competencia dicen que ellos son más baratos, que ellos cobran 1.500 euros por una semana de 40 horas. Sus consultores no desyunan, no van al baño, no asisten a reuniones, no responden correos, no leen en Internet, no tienen Facebook… O eso, o pasan 80 horas a la semana en la oficina, claro.

Y entonces somos poco competitivos. Así que subimos las horas y ponemos ese “100% de dedicación al proyecto” que al cliente le gusta tanto. Y todo el que ha estado en una consultora sabe que luego la gente está cargada al 200%, al 300%… Y lo que es peor: el cliente lo sabe también, pero hace como que no y baila el juego. Las cosas son así, siempre lo han sido.

Bueno, eso está bien para los que aun vivis en Matrix y dependéis del sistema tanto que matareis por defenderlo. Pero los renacidos en Sión, los que hemos estado en el otro extremo de la realidad, los que tenemos clientes con los que se puede colaborar, crecer y pasarlo bien… Nosotros vemos las cosas de otra forma.

Por lo pronto seguimos y asimilamos el dicho de Tom Peters : ¿Quién dirige la compañía? Los clientes. Los habitantes de Matrix oyen esto y dicen “el cliente quiere muchas horas gratis”, y crean una realidad en la que solo van a comprarles ese tipo de clientes. El que vaya a pedir un proyecto a una de las grandes “cárnicas” ya sabe a lo que va. Pero el estado mayor de Sión se reune y cuelga en la web (en la más fea de la Internet, eso sí) un manifiesto en el que declaran que el cliente lo que quiere es producto funcional, adaptación a los cambios, colaboración y trato personal. Y eso es en lo que creemos.

¿Quién paga las horas de I+D? El cliente. ¿Quién paga la fiesta de la empresa? El cliente. ¿Quién paga las nóminas, incluyendo la de la limpiadora? El cliente. Todo lo que no sale puntualmente de una ampliación de capital o un préstamo es, tarde o temprano, pagado por el cliente. Costes de infraestructura, maldita sea, repercutidos directamente en el coste del producto o en la tarifa horaria. Lo que el cliente quiere no es saber cuanto gastamos en donuts. Quiere un producto cojonudo muy bueno, a muy buen precio y muy rápido. Y eso se consigue siendo muy bueno y muy rápido. Y a eso se llega desarrollándose y mejorando.

Y para poder ser competitivos está bien que intentemos reducir el gasto (Muda, en la terminología Lean) y que los costes de gestión sean lo más eficientes posibles. Pero ponerse a recortar en I+D, y más con los vientos que corren… Y encima usar para ello la excusa de que el cliente es lo que quiere… En fin, no puedes salvarlos a todos, Neo.

Más antiguos →

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