Promociones

Escrito el 17 de Septiembre de 2009 a las 9:33 

La verdad es que la presentación de Netflix sobre la que hablé el otro día da para una saga. Uno de los aspectos que me gustó fue su política sobre las promociones internas: para que una persona sea promocionada, debe ser una super-estrella en su puesto actual. De hecho, debe reunir suficientes cualidades como para ser contratada para el nuevo puesto en caso de que se presentase desde fuera de la compañía. Y sus compañeros deben corroborar la aptitud de esa persona para el puesto.

Este es un principio básico de Lean Leadership: para ser promocionado, usted debe de ser excelente en su actual puesto. El objetivo es que usted pueda tutelar, guiar, mentorizar, apoyar y formar a personas que desempeñarán el trabajo que usted hace ahora. Así que ¿cómo pretende hacerlo sin conocer perfectamente los entresijos del mismo?

Esto va totalmente en contra (yet again) de lo que los occidentales hemos hecho tradicionalmente: el principio de Peter. Cada persona es promocionada hasta alcanzar su propio nivel de incompetencia. Usted es un programador fuera de serie y promociona. Entonces es un analista excelente y promociona. Entonces es un buen jefe de proyecto y promociona. Entonces es un jefe de departamento deplorable, y ya no lo promocionan más. Y por el camino hemos perdido un programador fuera de serie (que a lo mejor sólo quería programar) y hemos ganado un jefe de departemento deplorable.

Scott Adams hizo la situación peor en los 90 enunciando el principio de Dilbert: los buenos tiempos del principio de Peter, en los que usted tenía un jefe que había pasado por etapas previas de competencia se terminaron. Ahora los incompetentes salen directamente de las escuelas de negocios con su MBA debajo del brazo y son puestos directamente en puestos de responsabilidad. Antes tenías a un jefe que te decía “en mis tiempos era capaz de tirar 800 líneas de cobol solo en una mañana, así que menos quejarse ya te puedes poner con esto“. Ahora no saben lo que es cobol, pero repiten slogans revenidos como “trabaja de forma más inteligente, no de forma más dura” mientras meten bizcochos sobre nuestras magdalenas.

Alguien puede confundir el principio de Peter con la política de Netflix, pero hay una diferencia fundamental. En Netflix, promocionan al programador excelente a analista bueno, pero no será Jefe de Proyecto hasta que sea un analista excelente. And so on. Por el camino, debemos ir aportando a los empleados que deseen promocionar la ayuda y el estímulo suficiente para que persgan ese camino de mejora continua (Kaizen.. Si es que todo encaja al final, ya lo veis ;-) ).

En algunos casos esto podría parecer injusto, ya que otra conocida ley de Dilbert establece que las personas de fuera de la empresa siempre parecen tener más talento que las de dentro (hasta que las vamos conociendo, claro). Esto es cierto y lo he visto ocurrir en algunas ocasiones: se ficha a un gerente estrella que viene de Chachi&Sons donde ha sido Superb Manager of Everything Cool y seis meses despues nos damos centa de que es solo otro puñetero inutil con un papá rico que le pagó un master por una universidad extranjera prestigiosa y le proporcionó una pila de contactos (si no habéis leido aun a Fuckowski, reserváos una tarde y poneos con ello ahora). El lado malo de esta política es que un empleado interno que puede ser mejor que esta persona (probablemente incluso aunque fuera sometido a una lobotomía previa) puede ser rechazado por algunos compañeros o gerentes porque “me pegó la bronca en aquel proyecto”, “cometió un falló con aquel enfoque” o “hace molestos ruiditos al masticar”, cosas que a priori no sabemos ni conocemos del recién llegado del exterior. Nuevo punto a favor de reforzar una política de promoción interna frente a la contratación externa (siempre que alguien cumpla con las condiciones de excelencia previa).

Otra crítica posible es que un operario puede ser un crack haciendo tuercas pero no saber nada de dirección de equipos, liderazgo, comunicación, negociación… La respuesta es simple: ¿es más barato traer a un gerente de fuera y que sea un inutil que no entiende nada de lo que está gestionando o formar y desarrollar a este operario en técnicas de gestión si realmente quiere seguir esa línea de promoción?

Recordatorio: Scrum Barcelona - 29 y 30 de Junio

Escrito el 28 de Mayo de 2009 a las 17:38 

Un par de líneas para recordaros que el 29 y 30 de Junio estaremos en Barcelona impartiendo un curso de Scrum. El lugar definitivo se comunicará a los inscritos al menos dos semanas antes. Como siempre, recomendaros que si estáis interesados lo mováis cuanto antes, ya que en los dos últimos cursos en Madrid al final se ha quedado gente fuera…

Sobre el curso, tal vez queráis leer algunos comentarios de asistentes. Os esperamos.

Agile Hitler

Escrito el 27 de Mayo de 2009 a las 17:29 

Y es que hay gente que no lo pilla… :-D

Gracias Luís por el impagable enlace… :-D . Por cierto, si os molan estas cosas hay como tres mil subtitulos de la geniál escena de la película “El hundimiento”, incluyendo “Hitler hace tests unitarios“,”Hitler baneado del World of Warcraft“, “alguien robó el coche de Hitler“, “Hitler pide una pizza” y “Hitler o Bill Gates“… Todo un fenómeno de Internet.

Charla Scrum

Escrito el 26 de Mayo de 2009 a las 10:26 

Siguiendo con la publicación de documentos relacionados con Scrum, aquí va una presentación pensada para charlas de 2-3 horas sobre Lean, Agile y Scrum. Como siempre, se agradecerán los comentarios y críticas constructivas.

Comentarios sobre el curso de Scrum

Escrito el 15 de Mayo de 2009 a las 13:19 

En Adictos Al Trabajo:

El pasado 11 y 12 de mayo tuve el privilegio de asistir en Madrid al curso que imparte Ángel Medinilla sobre “Scrum: metodología ágil de gestión de proyectos”. Y si digo privilegio porque el curso es realmente interesante, y Ángel es un comunicador como hay pocos.

Se explican los conceptos, principios y prácticas de Scrum de forma clara y muy completa. Y por si fuera poco Ángel dota a todo este contenido con un enfoque práctico de como funciona Scrum en el mundo real, y de una visión empresarial de la aplicación de Scrum como he visto en pocos sitios (señores, sí, Scrum está muy bien, pero no olvidemos que hay que seguir ganando dinero con ello ;)

Yo soy Certified ScrumMaster (y no me arrepiento de ello ;) y sin duda puedo decir que los dos días intensos que he pasado con Ángel y el resto de compañeros del curso, han sido más productivos que cualquier otro curso o documentación o libro que haya leído hasta el momento.

Por todo esto os animo fervientemente a que, si tenéis oportunidad, asistáis a uno de sus cursos sobre la materia.”

Os recuerdo que el 29 y 30 de Junio estaremos en Barcelona y que aun hay plazas (las de Madrid se agotaron algo así como un mes antes de las fechas, así que os recomiendo que os deis prisa ;-) ). Ya sabeis: correo a info (arroba) proyectalis.com

Curso de Scrum en Sevilla

Escrito el 25 de Marzo de 2009 a las 20:27 

Pues no. No tengo fechas para un curso de Scrum en Sevilla :twisted: , porque creo que no habría quorum suficiente. Pero como todo es proponerselo y hay por lo menos dos personas que me consta que tienen interés, vamos a abrir la lista en los comentarios a ver si juntamos las seis personas mínimas que hacen falta para montar un curso. Si es así, podemos intentar plantear unas fechas en torno a principios de Junio. Ala, comentarios abiertos ;-)

Nuevos cursos de Scrum en Barcelona y Madrid

Escrito el 25 de Marzo de 2009 a las 19:02 

Sois varios los que habéis preguntado a traves del blog y su correo si ibamos a celebrar algun próximo curso en Madrid o Barcelona así que, aunque tenemos el semestre francamente complicadete, hemos movido Roma con Santiago y hemos despejado un par de fechas en ambas localizaciones. Finalmente se celebrarán los cursos en:

Como siempre, confirmaremos el lugar al menos dos semanas antes, y tenéis información sobre el contenido en la web de proyectalis (además de algunos comentarios de asistentes aquí, aquí y aquí). Para reservar plaza, por favor, poneos en contacto con nosotros en info(arroba)proyectalis.com. En nuestro último curso en Madrid se nos quedó gente fuera al final, por lo que os aconsejo que, en caso de estar interesados, lo hagáis cuanto antes.

Aprovecho para comentar, por si alguno aun no lo sabe, que también hacemos cursos de formación in-company para grupos de 6 a 12 personas que son más ventajosos economicamente que el curso “abierto” en caso de que tengáis suficientes personas interesadas en la empresa. Hemos publicado además hace poco un catálogo de cursos 2009 en el que podéis encontrar propuestas formativas en torno a la gestión de proyectos y temas afines como planificación estratégica, Lean, gestión del tiempo, gestión del portfolio de proyectos, creatividad y gestión de la innovación…

Ala, fin del spam por hoy ;-)

Los resultados de un curso - hablan los clientes

Escrito el 10 de Febrero de 2009 a las 10:05 

Herme se autodefinía como informático vocacional (a pesar de ser “teleco”), que defiende el aspecto artístico (yo prefiero decir artesanal) de nuestra profesión. Y efectivamente, se le ilumina la cara cuando me explica algunos problemas que durante estos años le han surgido y que quedan lejos del típico CRUD (”altas, bajas, modificaciones y listados”) al que desgraciadamente solemos empujar a los usuarios de nuestras aplicaciones. También me comentó cómo después de asistir al curso de Scrum que impartió Ángel Medinilla en Barcelona, dieron la vuelta “como un calcetín” a un proyecto y consiguieron que fuera todo un éxito. Escucharon a los usuarios y se dieron cuenta de que el enfoque “ingenieril” era inadecuado. Escucharon a los usuarios y consiguieron enfocarse hacia el éxito del proyecto.”

Vía el blog de JM Beas.

Demistifying Agile

Escrito el 28 de Enero de 2009 a las 19:39 

A riesgo de repetirme, el último artículo que escribí ha desencadenado una ola de reflexiones bastante interesante, tanto en los comentarios como en el correo y en la creciente comunidad de Agile Spain, que recomiendo a los que estéis interesados en este tema.

Concretamente, he entendido perfectamente uno de los comentarios en el que se decía “Esa es la sensación que tenemos nosotros desde hace tiempo, que decir “ágil” es dar puerta abierta a “hago lo que me da la gana y encima tengo excusa“. Efectivamente, hay equipos e implantaciones concretas en las que uno acaba teniendo esta sensación. ¿Paternalismo de los gestores? ¿inmadurez de los equipos? ¿Mala implementación?

También ha caido en mis manos un artículo sobre el supuesto fallo de Scrum y las metodologías ágiles en “enganchar” con la psicología humana. Curioso por lo menos, tratándose de una metodología que parte de los principios ágiles y que siempre presento en los cursos como la aproximación humana a la gestión de proyectos. ¿Por qué unos la vemos como la forma más humana de trabajar y otros precisamente como lo contrario? Una vez leido el artículo, la cuestión clave es: ¿confias en el equipo de trabajo? O en algunos casos, ¿se puedeconfiar en el equipo de trabajo? Si, como defiende el artículo, vives en la creencia de que el “factor humano” consiste en que las personas siempre antepondrán sus propios intereses a los del grupo, son egoistas y nunca conseguirás que se pongan de acuerdo, pues vale, Agile no es para tí. Esto vale tanto si crees esto como si tienes la certeza absoluta aplicada al conjunto de personas que te ha tocado (o has seleccionado, en cuyo caso mucho peor y debes revisar tu proceso de selección).

Partiendo de la base de que yo no pienso así, ¿qué provoca que a veces Agile desemboque en una situación de “hago lo que me da la gana y encima está justificado”? Es más que evidente que Agile, como decía en mi anterior artñiculo, no es “hacking institucionalizado” o “buenrollismo institucionalizado”. Pero creo que se hace mucho “hype” de los aspectos más “hippies” de Agile (comunidad, equipo, personas, comunicación, autogestión, no interferencia) y bastante menos reflexión sobre los nativos de la gestión de proyectos (disciplina, ritmo constante, entregas, producto terminado, visibilidad diaria, priorización, estimación, compromiso, deadlines). Es lógico, a todos nos gustan los primeros y no a todos los segundos, por lo que la estrategia de marketing de Agile (sobre todo en una implantación up-bottom, o “golpe de estado” como la bautizó genialmente hace poco un contertulio) pasa por vender lo bonito y pasar “la pildora” con el azucar.

Lo malo viene cuando solo queremos el azucar. En Scrum, concretamente, quitas un sólo tornillo y se descuajaringa todo el método, lo tengo comprobado. Jeff Sutherland ha defendido en múltiples ocasiones que no hay nada en el método que esté ahí por casualidad, que todo tiene un sentido muy específico y que el método no necesita optimizaciones, ya que es el resultado de la experiencia directa de miles de los mejores desarrolladores del planeta, la teoría de sistemas y la aplicación de las técnicas más eficaces de gestión (Lean) al mundo del software.

Pasa también que utilizamos esta estrategia de maquillaje del método (diga lo que diga algún pope del Scrum, a mi siempre me ha parecido más un método que un marco) para, como decía, hacer una venta up-bottom y, cuando el equipo se huele algo lejanamente similar a una estructura de control, se sienten engañados una vez más por los de arriba. Decepción, desmotivación, resistencia pasiva y toda la pesca.

Así que ahí va mi consejo a navegantes: si tu scrum, tu scrum. Si tu no scrum, tu no scrum. Pero scrum “mas o menos” (también conocido como “MyScrum” o “ScrumLite” o “bueno, nosotros hacemos una versión simplificada de Scrum”)… Tarde o temprano tu aplastado como uva. Scrum Master Miyagui Dixit (long ago).

Por cierto, no es casualidad que una de las dos metáforas recurrentes en cualquier curso de Scrum que se precie se la de que Scrum no es una bala de plata. El exceso de “hype” está siendo bueno para Scrum en el corto plazo (popularización), pero a la larga puede hacer mucho daño si la gente empieza a decir “esto no funciona”.

Actualización: olvidé mencionar el magnífico artículo de Management From Scratch

El compromiso del equipo

Escrito el 26 de Enero de 2009 a las 13:06 

A lo largo de todo el pasado año hemos trabajado con muchas empresas relacionadas más o menos directamente con el mundo del desarrollo del software. Así, hemos pasado por operadores de telecomunicaciones, grupos editoriales, software factories puras, desarrolladores de videojuegos, empresas de contenidos, empresas de comercio on-line, “serenos” (de portal en portal ;-) ), desarrolladores de productos software, empresas de software libre, integradores, consultoras… Y en ellas nos hemos encontrado todo tipo de equipos, lo que nos ha proporcionado una visión privilegiada de lo que funciona y lo que no, lo que va bien y lo que va mal, los denominadores comunes y las singularidades maravillosas.

En tal panoplia de escenarios hemos implantado con difrerentes niveles de profundidad y éxito muchos tipos de herramientas y metodologías, siendo nuestro “producto estrella” la consultoría ágil y la implantación de Scrum como metodología de gestión de proyectos. Aquí, señores, debo decir que hay equipos que lo pillan y equipos que no. A nivel individual, Ken Schwaber estima en “The enterprise and Scrum” que un proyecto de implantación corporativa de cualquier iniciativa “Agile” debería estar dispuesto a dejar ir hasta al 20% de la plantilla. Mi experiencia confirma la cifra a partir de determinado tamaño de empresa (típicamente 40-50 desarrolladores o más).

Una importante parte de este 20% de seres impermeables a la filosofía Agile suele estar compuesta de inmobilistas, tradicionalistas y escépticos, es decir, lo normal en cualquier proceso de gestión del cambio. Pero hay otra parte que comienza con cierto entusiasmo en esto de Agile, por aquello de la autogestión del equipo, que el Dueño de Producto no deba intervenir en los Sprints, que las fechas más o menos las pongan ellos (ya que son los que dan las estimaciones y deciden cuánto puedes hacer por Sprint), que no se puedan introducir cambios “al tun-tun” sino que deban hacerse al principio de los nuevos Sprints (y generalmente a cambio de otras funcionalidades o compromisos), la comunicación cara a cara… Guay.

Pero señores, no nos engañemos: Scrum y Agile no son “buenrollismo institucionalizado”, al igual que XP no es “hacking institucionalizado”. Me viene a la mente la anécdota del autor del libro “Balancing Agility and Discipline” (creo que fue este), al que, en la presentación del mismo, se le plantaron los Popes y Gurus de Agile a preguntarle que quién le había dicho a él que Agile no era disciplinado. De hecho, somos los tíos mas disciplinados del mundo. Planificamos a diario. Reportamos a diario. Entregamos continuamente. Nos comunicamos constantemente. Progresamos en orden de prioridad… ¿Sigo?

Y eso es lo que algunos equipos no pillan: que todos estos componentes de “buenrollismo” tienen un precio. A saber: desarrollaréis el trabajo en el orden que yo, cliente o Dueño de producto, determino. Me reservo el derecho de aceptar o rechazar el resultado del trabajo, pues yo soy quien tiene la visión y debo deciros si nos acercamos o no a lo que tengo en mente. Debéis reportar y aportar visibilidad a diario sobre el estado del proyecto, pues si no deberé intervenir e interrumpir para saber qué está ocurriendo. Y debo ver compromiso, rendimiento, en definitiva: entregas. Es un precio que muchos pagamos con gran satisfacción y convencidos de que merece la pena el esfuerzo.

Pues bien, cuando ponemos la ecuación completa en juego (que es lo que funciona de verdad), en estos equipos de los que hablábamos comienzan los problemas:

Como comprenderéis, ante un panorama como este hay muy poquitas cosas que se puedan hacer. ¿Se os ocurren algunas? ;-)

Cuesta arriba y cuesta abajo (II): la entropía

Escrito el 15 de Enero de 2009 a las 21:56 

Si hablaba en el post anterior de los principios, hay pocos más inexorables que los de la termodinámica. Se obtienen de la observación directa de la naturaleza y son absolutamente simples, bellos en su simplicidad, y sin embargo la extensión de los mismos vibra y puede sentirse en casi todos los demás campos de la física y en la naturaleza mísma del universo. Julio Díaz, mi Gran Maestro, lo sabía, vaya que sí.

Una de las conclusiones que se obtienen del estudio de la termodinámica es que el desorden de un sistema en el que no introducimos energía externa (sistema cerrado) siempre crece. Para una demostración práctica de esta conclusión, dejad de limpiar vuestra casa una temporada hasta que tropecéis con las pelusas (funciona mucho mejor si, como es mi caso, el perro está mudando el pelaje :-D ). Este desorden siempre creciente, esta cuesta de Sísifo, este desgaste infinito se conoce con el nombre de entropía, y su concepto se introduce en el segundo principio de la termodinámica.

Algunas de las cosas que implican estos principios incluyen la imposibilidad de crear móviles perpétuos, ya sean de primera o segunda especie. No se pueden crear sistemas que producen más energía de la que consumen. Ergo si queremos mantener un movimiento indefinidamente, debemos aportar energía.

Ese es el quid de la cuestión a la que quiero llegar: si queremos que las cosas funcionen, si queremos que progresen, si queremos que mejoren, si queremos que cambien… Debemos aportar energía. El universo así lo establece, y a los que van contra el universo les suelen pasar cosas malas, no se si me explico ;-)

Por eso nunca deja de hacerme sonreir el que, al explicar determinadas técnicas, procesos, metodologías, ideas, innovaciones, herramientas o demás tricks of the trade, alguien en la audiencia diga “ya, pero es que eso no es tan fácil…”. Cuando, por cierto, yo no he mencionado en ningún momento que lo sea.

Suelo usar siempre una frase: “¿Esto es mejor o peor que lo que hacemos ahora? ¿Es mejor? ¿Es bueno? Hagámoslo. Aunque sea cuesta arriba.

Cuesta arriba y cuesta abajo (I): los principios

Escrito el 2 de Enero de 2009 a las 9:18 

Creo que si algún día escribo un libro lo titularé de esta forma (”Cuesta arriba y cuesta abajo”) o con alguna variante más ingeniosa. Lo explico en varios pasos. Hoy comienzo con el paso uno, que si no esto es un ladrillaco incomestible: los principios.

Cuando uno empieza a estudiar una materia en profundidad, ya sea las matemáticas, el Aikido, el desarrollo de software o la gestión de proyectos, llega un momento en el que empiezas a sentir como encajan todas las piezas. Muchas cosas que parecían inconexas empiezan a tener un sentido común, como si todas resonaran a una frecuencia muy concreta. Y esa frecuencia de resonancia suele ser un principio o una serie de ellos de una belleza y simplicidad esenciales. Poder destilado. La materia de la que se hacen los sueños. Lo cachondo de la historia es que si, en vez de estudiar la materia en profundidad, uno se ve confrontado con el enunciado del principio a secas, el resultado suele ser “menuda memez”.

Un mini ejemplo: la economía. Uno empieza a estudiar economía y, cuando lleva un tiempecito, se da cuenta del poder de la ley de la oferta y la demanda y las implicaciones resonantes del mismo en casi todos los aspectos, macro y micro. Otro buen ejempo relacionado con la economía es el consejo que Kiyosaki da a todos los que le abordan en los aeropuertos para preguntarle cómo hacerse ricos rápidamente. Robert les dice “incremente su inteligencia financiera“, y ellos se le quedan mirando con cara de “pero tío, que yo lo que quiero es apretar un botón, no estudiar, y además no se cómo me va a hacer más rico leer libros”. Necios.

Pongamos el ejemplo de Lean aplicado al software. Durante dos décadas ha habido personas intentando aplicar al mundo del software las técnicas derivadas de Lean, la filosofía de gestión emanada desde el sistema de producción de Toyota y de la que han surgido una plétora de herramientas ampliamente adoptadas como los estándares de la industria como el Just In Time, Kanban, Kaizen, 5S, TPM, Visual Management… El fallo que cometieron todos los que lo intentaron y quedaron por el camino fue intentar migrar las herramientas, no los principios. Mary Poppendieck lo vio claro porque ella interioriza perfectamente esos principios, momento en el que todo se vuelve fluido y natural. Es lo que Toyota sabe y General Motors aun ignora (impagable artículo, seguid el enlace).

Ocurre también con muchos libros de gestión. Lees el principio que defiende el libro (como ya he comentado alguna vez, suelen contener muy pocos pero muy novelados) y al principio dices “pues anda que se ha exprimido las meninges el colega”. Pasa el tiempo, experimentas, aprendes y te dices “joroba, la razón que tenía este libro y lo enraizado que está el principio con la realidad misma”. Lo dicho: no vale con leer el principio, hay que interiorizarlo, y eso lleva su tiempo.

Así pues, reto para empezar el año: ¿cuales son los principios que rigen vuestras empresas? ¿Y vuestros servicios? ¿Vuestros productos? ¿Vuestra vida? Yo ten¡go un par por ahí anotados;-)

Scrum Barcelona: lugar de celebración

Escrito el 3 de Diciembre de 2008 a las 10:02 

Como todos sabéis, el 17 y 18 de Diciembre celebramos en Barcelona un curso sobre metodología SCRUM de gestión de proyectos. Se trata de una metodología muy eficaz en entornos complejos como el desarrollo de proyectos informáticos, pero que se emplea con éxito en otro tipo de entornos en los que los requisitos son emergentes y cambiantes, la tecnología compleja y no existe un proceso predefinido y optimizado para la ejecución de los proyectos.

Finalmente lo celebraremos en el hotel Zenit Borrel, en la calle Comte Borrell 208, muy cerquita de la Escuela de Ingeniería Técnica Industrial y del metro del Hospital Clinic. El costel del curso incluye el almuerzo de los dos días, y puede ser una buena oportunidad para conocer a personas con las mismas inquietudes. Para información y matriculaciones, escribid a info (arroba) proyectalis.com.

¿Y si soy caro?

Escrito el 30 de Septiembre de 2008 a las 23:27 

¡Movidita de la que me gusta! Escribí hace unos días un artículo en el que hablaba del síndrome de la barra libre, es decir, la tendencia de las distintas áreas de la empresa a sobrecargar al Área de IT al no percibir que eso cause un gasto a la empresa o que esos recursos deban ser compartidos con otros usuarios.

Pues bien, el maestro Luis ha pegado un pedasso de rúbrica al artículo desde su sitio explicándo, desde su experiencia personal, no solamente que efectivamente el fenómeno se produce con cierta frecuencia, sino que además esboza lo que fue su estrategia para luchar conta el mismo.

El planteamiento de Luis, absolutamente defendible, enfoca una progresiva imputación de los costes a los consumidores internos, llegando a funcionar como una unidad de negocio interna o “centro de beneficio”, como el propio Luis lo llama.

Pero en los comentarios, Rafa (interesante blog, por cierto) ha dado con un punto clave que yo mismo iba a comentar: el miedo de muchos CIO a que, una vez hecha la factura, los servicios de IT resulten más caros que los que prestan otras compañías del mercado. Y claro: todo el área de IT a la calle y la función en outsourcing. Zas, en toda la boca.

Lo que me maravilla es que se opta por la estrategia del avestruz. Curioso. Justo cuando te das cuenta de que no eres eficiente, de que otros lo hacen mejor que tu, de que incluso sin necesidad de montar una infraestructura totalmente independiente y sin una necesidad real de arrojar un beneficio cuantioso (cosas con las que tienen que convivir las empresas de Outsourcing) tus costes son mayores, justo entonces decides esconder las cifras. No hacerlas. No medir. Y como dice el adagio, no se puede controlar lo que no se puede medir.

Así pues, aun coincidiendo totalmente en que lo que Rafa describe en su comentario (es decir, que es bastante complicado y hasta peliagudo instaurar un sistema de control de costes de IT), considero que es un paso necesario si queremos hacer Kaizen: mejora continua. Hoy mejor que ayer, mañana mejor que hoy. ¿O es que realmente ya hemos alcanzado el mejor estado posible? Y si es así, que lo dudo, ¿de qué tenemos miedo?

Señor CIO: si tiene usted miedo de que externalicen su área, por algo será. Mejor nos vamos poniendo las pilas y atacamos las principales fuentes de gasto y desperdicio en el área, tratando de hacer que el flujo de valor sea lo más eficiente posible. Lean en estado puro, ¿no?

Scrum Madrid: lugar de celebración

Escrito el 29 de Septiembre de 2008 a las 14:37 

Finalmente, como ya se ha comunicado a los inscritos, el curso de Scrum se celebrará en el hotel Catalonia Moratín, en la C/ Atocha 23, muy cerquita de la estación y de varias paradas de metro:


Ver mapa más grande

Recordamos que se celebrará los días 14 y 15 de Octubre y que aun quedan algunas plazas disponibles. Más información aquí.

← Más recientesMá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