Día mundial de abrazar a un programador
Escrito el 4 de Septiembre de 2008 a las 11:44
Vía Planet Mysql, Beer Planet . La realidad misma… 
Curso de Scrum en Madrid
Escrito el 1 de Septiembre de 2008 a las 13:15
actualización: ya hay fechas definitivas para el curso
En la primera quincena de Octubre estamos planteando la posibilidad de celebrar un curso abierto en Madrid. Tenemos a varios interesados, por lo que es más que probable que podamos cerrarlo pronto. Duraría dos días e incluiría ejercicios prácticos como complemento a la teoría, con el aliciente de conocer a personas de otras empresas interesadas en el mundo del desarrollo de software, Agile, la gestión de proyectos… El coste será muy reducido, para facilitar la asistencia de todos aquellos que quieran plantearselo a nivel personal, y el temario aproximado es el siguiente:
- Introducción a la gestión de proyectos
- Scrum 101
- Principios de Agile y Lean
- Planificación en Scrum
- Estimación en Scrum
- Control en Scrum
- Gestión de equipos en Scrum
- Implantando y Escalando Scrum
- Herramientas y referencias
El mínimo de asistentes será de seis y el máximo de doce. Como es habitual, se atenderán las inscripciones por orden de pago. Para más información, correo a info (arroba) proyectalis (punto) com o comentario en este vuestro blog 
… Y yo no estoy.
Escrito el 5 de Agosto de 2008 a las 9:40
Este año no toca. Todo llegará… :_(
Frase real en conversación telefónica
Escrito el 17 de Julio de 2008 a las 19:10
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?
Bananas
Escrito el 17 de Julio de 2008 a las 9:37
Ummmmmmmm….Baaah-naaah-naaaasssss….
Kung Fu Panda on Agile, Scrum and the Illusion of Control
Escrito el 16 de Julio de 2008 a las 8:56
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.
Vacaciones blogueras (de vuelta)
Escrito el 16 de Julio de 2008 a las 8:48
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 
).
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…
Cita
Escrito el 13 de Junio de 2008 a las 10:12
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
Just say no
Escrito el 12 de Junio de 2008 a las 12:16
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 , 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 . 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…
“No podemos hacerlo”
Escrito el 4 de Junio de 2008 a las 19:43
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.
Scrumsourcing
Escrito el 22 de Mayo de 2008 a las 15:57
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:-)
Orcos a las puertas
Escrito el 19 de Abril de 2008 a las 10:52
Reflexionaba esta semana, junto con los jefes de proyecto de una de las empresas con las que estamos trabajando actualmente, respecto al problema histórico de comunicación entre las áreas de negocio y las áreas técnicas, tantas veces reflejadas, por ejemplo, en los chistes de Dilbert. Es un problema comprensible: las motivaciones muchas veces están enfrentadas (el área de negocio quiere más cosas en menos tiempo, el área de sistemas quiere más tiempo para dedicar a menos cosas) e incluso los lenguajes y el bagaje personal y profesional son tan difererentes que lo raro es que surja una buena comunicación.
Scrum, como sabéis, establece un artefacto (la pila de producto) que permite a la gente de negocio (Dueños de Producto) manejar a la gente técnica (Scrum Master y equipo). Sin embargo, uno de los problemas típicos que nos encontramos en las implantaciones de Scrum en las que trabajamos es el de involucrar a la gente de negocio en el proceso. La implantación de Scrum suele surgir por iniciativa de los técnicos, cosa rara si pensamos que la gente de negocio debería tener una formación y un foco más “humanista” y deberían haber sido los primeros que planteasen formas de colaborar y comunicarse con las áreas de producción (notese el matiz respecto a “áreas productivas”, que esas deberían ser todas, negocio y sistemas).
Al surgir desde el área técnica, las áreas de negocio tienden a veces a considerarlo “cosas de frikis” y pasar muy mucho del tema. Por eso nuestro enfoque de implantación conlleva muchas acciones dirigidas a las áreas de negocio. El objetivo final es que las áreas de negocio nombren un determinado número de Dueños de Producto que sean los que canalizacen y prioricen las peticiones de todos los interesados, clarificando al equipo lo que deben hacer en cada momento. Con eso evitamos también el bombardeo de peticiones “no oficiales” a las que típicamente se ven sometidos los equipos de desarrollo, peticiones cuya prioridad no está clara y que la mayor parte de las veces ni cuentan con una justificación de negocio sólida ni computan luego en la productividad del equipo, ya que se hacen “de tapadillo”.
Lamentablemente, el enfoque de envagelización y colaboración no siempre funciona, y los equipos de desarrollo se enfrentan a peticiones y negociaciones que les llueven por todas partes. Es como enfrentarse a un enemigo muy superior en número y recursos. ¿Y qué podemos hacer en una situación así?
Reflexionabamos sobre esto, como os decía, y tratando de explicar el enfoque que nosotros proponemos como siguiente nivel de presión hacia el cambio corporativo se me ocurrió la metáfora de los “orcos a las puertas”: La batalla del abismo de Helm.
En la batalla del abismo de helm, los humanos se parapetan en un fortaleza que cuenta con un único punto de acceso: un estrecho puente que obliga a los miles de orcos que los asedian a formar casi de uno en uno, con lo que en las puertas de la fortaleza se monta lo que los KODT llaman una “conga de la muerte”, una estrategia perfecta para lidiar con un enemigo muy superior en número y que ya fue utilizada por los 300 espartanos en el paso de las termópilas.
¿En qué consistiría la estrategia “orcos a las puertas”? En primer lugar, en blindar el área de sistemas. Kniberg lo describe muy bien en su libro. Esto se puede hacer a un nivel organizativo o discilplinario, aleccionando a todo el mundo para que no atiendan peticiones de ningún tipo que no vengan del Dueño de Producto de Sistemas, o incluso físicamente, co-alocando a todo el equipo y dejando pocas vías por las que los extraños puedan acceder y pulular. Incluso sentar al Dueño de Producto de Sistemas al lado de la puerta para que actue como guardián del área.
El segundo paso es precisamente ese: nombrar a un Dueño de Producto de Sistemas encargado de lidiar con los orc…Digooo…Con la gente de negocio. Nada fácil, os lo aseguro. En la mayoría de los casos una estraegia pasivo-agresiva como esta suele acabar en el despacho del CEO, pero a veces es precisamente esto lo que hace falta. Por eso es también muy importante preparar documentación sobre todos los intentos previos que se hayan hecho para que el área de negocio asuma la responsabilidad y la competencia que le toca sobre la definición y priorización de los proyectos. Eso nos permitirá justificar el movimiento defensivo.
A veces lo que ocurre es que el área de negocio está encantada con tener un interlocutor único en sistemas, y la estrategia “orcos a las puertas” se convierte en una mejor práctica corporativa. Pues estupendo. De hecho, no se vive tan mal en el abismo de Helm, siempre que uno tenga un puesto calentito, dos buenas pantallas TFT y unas cuantas herramientas de desarrollo…
Cosas curiosas que llevar en la mochila (The Agile Coach Toolkit)
Escrito el 15 de Abril de 2008 a las 20:12
Podéis considerarlo un meme si queréis, me encantaría cotillear en vuestras mochilas
- Una barra de limpiador de gafas, muy util cuando uno se confunde y pinta con rotulador indeleble en una pizarra velleda (por cierto, ¿¿¿no os da mil patadas que la gente las llame pizarras villeda??? )
- Una navajita mulitusos (deshauciada desde que empecé a coger más aviones)
- Cuaderno tamaño cuartilla
- Post-its… Lot’sa post-its
- Rotuladores, en sus variedades: marcador fluorescente, edding de escribir post-its, edding indeleble para papelógrafos, ikea para velledas (punta fina) y bic para velleda (punta gruesa)
- Papel celo y blu-tac (moco/chicle adhesivo, vaya)
- Kleenex
- Cámara de fotos digital
- Reproductos MP3 cargado de audiolibros y algunas canciones de las de conducir (niños, no lo hagáis en casa ).
- Ocasionalmente, un proyector LG y un trípode de cámara digital
- Un limpiador de pantalla de portatil (pequeño artefacto con un borde de gamuza retractil)
- Marcapáginas adhesivos (utiles para realizar votaciones en ausencia de sticky dots)
- Montones de tarjetas de visita, profesionales y del blog
- Una mini-linterna de leds
- Un peine… Lo siento, pero a veces va uno con la moto a ver a un cliente y si no se atusa un poco al quitarse el casco parece el primo treintañero del neng de castefa
- Ocasionalmente, latas de caramelos del LIDL
Ah, sí… Y el portatil con su cargador, claro… ¿Que si pesa? Como un palet de ladrillos, la condenada…
Ni chapa
Escrito el 24 de Marzo de 2008 a las 13:31
Una de las muchas y alarmantes constantes que me encuentro en los cursos y demás actividades que hacemos relacionadas con la gestión de equipos y proyectos es que siempre hay alguien que pregunta algo así como “Todo esto de la motivación está muy bien, pero ¿qué hacemos si un empleado se pasa el día sin dar un palo al agua?“. 
He de confesar que las primeras veces que me enfrenté a este tipo de cuestiones no me lo podía ni creer. Mi reacción fue la ya conocida por estas páginas como “conejo alumbrado por faros de camión“: no sabía si saltar a la derecha, saltar a la izquierda o encomendarme al Sagrado Monstruo Volador de Espagueti (alabado sea su tallarinesco apéndice). Vamos, que me pensaba que me estaban filmando con cámara oculta. Pero meditándolo posteriormente me di cuenta de que también ha sido una constante en mi devenir laboral la existencia de algún que otro (a veces multitud de ellos) elemento nichapante. El típico tío que no se suele meter con nadie, pero que nadie sabe muy bien a qué dedica su día ni cuáles son sus funciones, y que en cuanto se le intenta sorprender con un passing-brown despliega un envidiable arsenal de excusas y justificaciones para, en última instancia, seguir haciendo nichaping.
Ahora en serio, en mi humilde opinión este tipo de personajes son como un cancer para la empresa. Y digo cancer porque los jodíos metastatizan. Se extienden. Mucha gente se harta de partirse el lomo luchando por la empresa para ver como a final de mes el vago de turno se lo lleva igual de calentito que ellos (a veces más), e incluso en multitud de casos que conozco, les toca la misma cantidad de bonos o incentivos que al resto. La única explicación que se me ocurre para esto último, y es algo en lo que abundaré en un par de párrafos, es que los jefes huyen del enfrentamiento o la confrontación y piensan que “café para todos” es la política más democrática, pacifista y buenrrollista. Error. Craso error. Postdata para mi mismo: hablar un día del buenrrollismo como estrategia de gestión
Así pues, hecha la desagradable metáfora, ¿cómo enfocamos un cancer en la empresa? Bien, de nuevo en mi humilde opinión, habría que empezar por una serie de sesiones de radioterapia y quimioterapia. A veces ocurre que el compañero nichapante o conflictivo manifiesta los síntomas de una falta de confianza, un exceso de perspectivas al respecto de su rendimiento, falta de preparación o la falta de compromiso con el equipo, el proyecto o la compañía. A veces se trata simplemente de que la persona no sabe lo que esperan de ella. En estos casos se pueden diseñar tratamientos: definición correcta de las responsabilidades, objetivos y expectativas del cargo, formación de la persona para que alcance el rendimiento esperado, coaching, team-building… No se puede empezar con las medidas de presión si primero no hemos agotado las vías constructivas. Es de cajón.
Pero a veces ocurre que si quieres arroz Catalina. Que no. Que nasti. Que no hay manera. Y en estos casos, sorpréndome, todavía la gente se pregunta “¿qué hacemos?”. Bien, la siguiente fase del proceso oncológico es la extirpación quirurgica. Esto no siempre quiere decir a la puñetera calle. A veces basta con reasignar esta persona a otro departamento, grupo de trabajo o proyecto en el que se sienta más a gusto. En este tipo de movimientos es necesaria una elevada dosis de comunicación con la persona para que entienda que no se trata de un castigo o una penalización, pero que también entienda que es el primer toque de clarines. Si con todo esto seguimos mal… Pues señores, ¿a qué estamos esperando?
La empresa es un ente que funciona en un mercado determinado. Y los mercados son, por definición, eficientes. La propia empresa es de hecho un mercado y debería ser tan eficiente como fuera posible. Las personas trabajan para la empresa, en vez de dedicarse a la contemplación de la naturaleza y a hablar con Diox, porque les pagan por ello. Si no reciben la suficiente cantidad de dinero por su trabajo, rendimiento y talento, probablemente acaben encontrando otras empresas que sí les paguen lo suficiente, y así se van creando los niveles salariales en función de la disponibilidad del perfil y el rendimiento de la persona. Ahora bien: ¿Qué pasa si el empleado no aporta la cantidad de trabajo esperada por el salario ofrecido y sin embargo la empresa no prescinde de él? Pues señores, es de libro: se produce una pérdida de eficiencia que, en última instancia, paga la empresa, o sea todos los demás, que son los que van a tener que cargar con el hueco de trabajo no generado o, en el peor de los casos, con el cierre de la empresa por poco competitiva.
Y si esto está tan claro, ¿Por qué los gerente sistemáticamente se enfrentan a la duda sobre qué hacer con estas personas? Típicamente, por miedo o aversión a la muy desagradable tarea de echarse a una persona a la cara y decirle que está en la calle. Que lo entiendo. Que a nadie le gusta a menos que sea un sociópata (que los hay, oiga, yo los he visto ). Pero que alguien tiene que hacerlo, y no puede uno aceptar la carga de la dirección pero limpiándole las partes que no gustan. Yo mandar sí, y cobrar también, pero responsabilidades desgradable no, mirusté. Pues magnífico.
En otros casos ocurre que el gerente en cuestión se enfrenta a la tarea de rellenar el hueco que dejaría esta persona, y se le antoja una tarea imposible o suficientemente dura como para preferir el “mal menor” de aguantar con el elemento nichapante (también conocido en el argot de un buen amigo como “saco terrero” ). Pues error. El “mal menor” es aguantar dos o tres meses sin esta persona y echarle horas al proceso de selección. O incluso apechugar con una persona menos y repartir su salrio en forma de bonos e incentivos entre el resto del equipo. El mal mayor es que esta persona siga minando la productividad de la empresa y la moral de sus compañeros, estableciendo además un mensaje muy claro para todos los trabajadores: “no passsa nada si no das ni chapa, aquí no echamos a nadie”.
Más razones: el buenrrollismo. Que no se estrese la gente pensando que la pueden echar. Vease el argumento anterior.
Otra razón más: la estrategia aerostático-maquiavélica. En estos casos (pocos los que he visto, pero notables todos ellos) uno se carga de una cierta cantidad de lastre para que, cuando lleguen los periodos de vacas flacas (que en ciertos sectores son cíclicos), poder desprenderse de los mencionados sacos terreros justificando por un lado el recorte de personal pero sin perder por el otro productividad y capacidad.
Y otra más: “no depende de mí”, estrategia reactiva, también conocida como lloriqueo vulgar. El gerente en cuestión no tiene autoridad para despedir al elemento nichapante. Esta es fácil: comuníqueselo a quien sí tenga la responsabilidad. Si no reacciona, comience a disminuir sus previsiones de producción, justificándose en la influencia negativa de esta persona. Si aun así no passsa nada, búsquese otra empresa, esa no le conviene.
Por último, una salvedad: if you pay penauts, you’ll only get monkeys. O lo que es lo mismo: si pagas por debajo del mercado, obtendrás perfiles por debajo del mercado. Pero tener a gente a precio de mercado y produciendo por debajo…Pues mire usted, no.
Testing
Escrito el 18 de Marzo de 2008 a las 13:40
MWAA-HAHAHA!! ROTFLASTC!!
Vía Sebastian Bergmann, encontrado en Flickr buscando “Agile Software Development”.
-
Artículos recientes
-
Categorías
-
Archivos
- Agosto 2010
- Mayo 2010
- Abril 2010
- Marzo 2010
- Febrero 2010
- Enero 2010
- Diciembre 2009
- Noviembre 2009
- Octubre 2009
- Septiembre 2009
- Agosto 2009
- Julio 2009
- Junio 2009
- Mayo 2009
- Abril 2009
- Marzo 2009
- Febrero 2009
- Enero 2009
- Diciembre 2008
- Noviembre 2008
- Octubre 2008
- Septiembre 2008
- Agosto 2008
- Julio 2008
- Junio 2008
- Mayo 2008
- Abril 2008
- Marzo 2008
- Febrero 2008
- Enero 2008
- Diciembre 2007
- Noviembre 2007
- Octubre 2007
- Septiembre 2007
- Agosto 2007
- Julio 2007
- Junio 2007
- Mayo 2007
- Abril 2007
- Marzo 2007
- Febrero 2007
- Enero 2007
- Diciembre 2006
- Noviembre 2006
- Octubre 2006
- Septiembre 2006
- Agosto 2006
-
Blogroll
Bienvenido
Presión Blogosférica es un blog en el que almaceno mis reflexiones sobre negocios, empresas, emprendedores, gestión de proyectos, Internet... Pero también es un espacio plural en el que discutir sobre dichas ideas. Puedes dejar un comentario o contactar conmigo en angel.medinilla (arroba) presionblogosferica.net. También puedes seguir el blog a través de su Feed RSS
¿Un café?
Buscar:
Suscriptores:
Kisei Dojo Aikido
Pastafari!
Tags
2.0 3G 2008 actitud Agile agile spain andalucía apple aspecto atrevete autentia autonomos ayuda bancos barcelona Biko2 Blogs burbuja business angel C++ calendario calidad cambio charla charlas clientes coaching colaboración comentarios comunicación conciliación congreso consejos consultores consultoría contactos contratos contratos ágiles control costes Creatividad crecimiento crisis crédito CSM cultura curriculum curso curso de scrum curso madrid cursos curso scrum diseño diversión dueño de producto EBE07 economía einstein ejercicios empleados empleo Emprendedores emprendesur empresa empresarios empresas encuesta equipos España estrategia estudiantes Eventos exito externalización facturas feedback financiación finanzas flickr ford Formación fracaso funcionarios funky business fábulas gente GMail Google GTD Herramientas horarios ideas impuestos Iniciador innovación IT iweekend jefe de proyecto Jeff sutherland jornada laboral kaizen Kanban karma lean Libros liderazgo Linus Linux liquidez Madrid Marketing Matrix mejora mercado laboral mercados metodologías microsoft miedos mision mochila motivación muebles málaga navidad negociación negocio networking oferta ofertas oficina oficinas ONG Open Space outsourcing pagos pamplona pareto perseverancia personal personas plan de negocio planificación estratégica PMBOK PMI PMP positivismo power point precios presentaciones presentación proactividad problemas productividad producto programación programadores project management proveedores proyectalis proyectos pruebas rentabilidad responsabilidad social reuniones richdadclub riesgo salarios scrum selección sevilla silicon valley sistemas SL Slideshare social start-up startup subvenciones tecnología teletrabajo tema tercer sector tests TI tiempo tim ferris toyota transparencia twitter usuarios VC ventas venture capital video vision wii wordpress xp xp2008 zona de confort
Que se dice por aquí:
- Miguel: antes de todo, como estudiante de Ing.Informática, gracias por dar un poco de luz a este mundo que a veces...
- karina: esta nuy buena la informacion es presisa, gracias
- paloma: hOLA , perdona que te haga esta pregunta por aqui , pero creo que tienes el PRINCE2 y me gustaria saber si el...
- Ángel: Faldo, es que no es el tema que se discute, solo hablamos de costes imputables. El argumento de motivación...
- Faldo: Tampoco se tiene en cuenta el echo de que una persona contratada por la empresa deberia ser mas productiva y...
Qué se dice por ahí:
- Burbuja Econmica: La crisis dispara la externalizacin de servicios un 55% en el ltimo ao
- Blog name: La era de la información… de la iniciativa y la colaboración
- Califica-t: La era de la información… y de la iniciativa y la colaboración
- Lo que los gurús nunca te cuentan sobre Kanban y SCRUM: Aquí todo normal. El escenario es bastante favorable para...
- Mostofreddy un blog de tecnologia y arte: Apuntes sobre Kanban
Fotos
www.flickr.com
|
