Felicidad de 9 a 5
Escrito el 16 de Junio de 2008 a las 21:33
Me pasa José Luís Marina, cuya bitácora tengo tan abandonada como el resto que languidece en mi pobre agregador (ay de mí), un enlace muy interesante: la bitácora “director de felicidad“, del autor del libro “la hora feliz es de 9 a 5“, que he anotado en mi pila de lecturas deseadas (a ver si llegan las vacaciones de una vez). Todo un blog curioso, la verdad. En primer lugar, se trata de una traducción al castellano de un blog con 2400 subscriptores, the chief happiness officer. La traducción, por lo que veo, está realizado por la misteriosa compañía contentspanish.com, que también representa “la semana de 4 horas” de mi admirado Tim Ferris. Habrá que vigilarlos.
Por otra parte, me ha encantado ver que alguien ha escrito un libro argumentando sobre algo que ya estuve comentando hace tiempo en un post que fue bastante celebrado: la jornada de 9 a 3. En este caso, el autor defiende que una jornada más reducida (32 horas, llega a exponer en un post) no reduce necesariamente la productividad y sin embargo reduce los costes de la empresa y, típicamente, los empleados lo prefieren a ganar algo más pero trabajar más horas. Al fin y al cabo, algo que llevo repitiendo de diferentes maneras desde que empecé con este blog: la productividad no es un sumatorio de horas, sino que se consigue a base de optimizar el flujo productivo. Y para optimizar un flujo uno no puede sobrecargarlo.
Alexander Kjerulf escribe sobre motivación, política de recursos humanos, salarios, y algo que parece un tabú en muchas empresas o, directamente, poco más que un eslógan: la felicidad en el trabajo. Algo que para mí es fundamental, ya que paso un porcentaje muy alto de mi vida currando (qué le vamos a hacer 
), por lo que me rebela la idea de pasar ese porcentaje del tiempo que me ha sido dado haciendo algo que no me llene, me satisfaga, me realice… Me haga feliz.
Así es. Al igual que el corredor exhausto y a ratos dolorido, pero que en el fondo disfruta de la carrera y se regocija cada día cuando mejora su marca, así yo me considero feliz en el trabajo. Así que si estas leyendo a esto, tengo dos consejos para tí: lee a gente positiva que ha encontrado formas de ser feliz, y calcula ahora mismo si eres todo lo feliz que podrías ser en tu trabajo. Si no es así, ya puedes ponerte manos a la obra: probablemente te lleve años mejorar tu nivel de felicidad laboral. Hoy es un día estupendo, mucho mejor que mañan o pasado, para empezar a construir el camino a la felicidad.
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
Cita
Escrito el 12 de Junio de 2008 a las 20:30
- Hay quien dice que un buen programador puede aprender cualquier lenguaje en dos semanas y escribir buen código a partir de ahí, y eso no es cierto.
- Bueno, depende… Conozco gente que puede programar C en cualquier lenguaje”
Xp2008, Dave Snowden y Joseph Pelrine
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.
Master en Networking
Escrito el 3 de Junio de 2008 a las 19:03
(artículo originalmente enviado a la revista Networking Activo)
Entre mis actividades de networking favoritas se encuentra el desayuno. Casi todo el mundo desayuna, por lo que no estás robándole tiempo al día sino aprovechándolo de otra forma, y en cualquier caso un desayuno de trabajo no debe prolongarse más allá de media hora. Desayunando hace poco con un buen amigo me comentaba su intención de realizar un Master en Dirección de Empresas, el tan ansiado MBA, a pesar de que esta persona cuenta ya con una impecable y envidiable trayectoria profesional. Personalmente, le comenté, siempre he considerado que un MBA proporciona una importante ventaja competitiva y una visión global de negocio considerable cuando uno está empezando, acaba de salir de la Universidad y se enfrenta por primera vez a la selva de la empresa. Pero hay expertos que consideran que un MBA es el equivalente a tres o cuatro años de experiencia empresarial relevante, por lo que no tiene demasiado sentido emprenderlo cuando uno ya lleva doce años en empresas de primera línea con puestos de responsabilidad. A menos qué, claro.
A menos qué lo que andemos buscando en un Master sean los valiosos contactos que proporciona. Todos habremos escuchado alguna vez esta reflexión: lo importante del Master no es lo que aprendes, son los contactos. Y ahí tuve que darle parcialmente la razón a mi amigo. Parcialmente. Aunque sea cierto que los círculos de Networking surgidos a partir de haber compartido aulas, sumado al esfuerzo que las escuelas de negocio, conscientes de la importancia de esta factor, realizan para mantener y aumentar estas redes de networking (seminarios, encuentros de antiguos alumnos, revistas, eventos), no es menos cierto que el coste de un Maste, en tiempo y dinero, es bastante elevado, sobre todo si queremos asistir a “ese” o “aquel” Master, que son los que más contactos proporcionan.
Pero pensémoslo: si lo que valoramos realmente son los contactos, ¿no hay formas más eficientes, eficaces y efectivas de conseguir esos contactos? Comparemos la inversión en un master con el coste de asistir regularmente a los eventos de Networking profesional que se organizan en varios lugares del país, como por ejemplo los Thursday Internet en el marco de las nuevas tecnologías o los eventos Networking Activo para los que buscan contactos en el area de los negocios. Curiosamente, en muchas ocasiones estas mismas personas que valoran la posibilidad de endeudarse para hacer un Master y dedicarles las tardes de los viernes y los sábados completos durante dos años, a veces consideran que “no tienen tiempo” de asistir una vez al mes a un evento de Networking o que “es demasiado caro”.
Hay muchas formas más de ir construyendo nuestro “MBA Personal” en Networking: congresos, cursos, seminarios… Todos ellos con un coste menor que el de un master, y con la posibilidad de centrar los contenidos (y, con ello, a los asistentes) en función de nuestras áreas de experiencia o interés. Luego están todas las herramientas que Internet está poniendo a nuestra disposición: redes On-Line como LinkedIn o Xing, la blogosfera, foros, wikis…Comunidades profesionales, asociaciones, colegios, incluso ONG’s. Las posibilidades son realmente increibles. Pero claro, requiere un esfuerzo de organización personal, que comienza por ser consciente de cuáles son nuestros objetivos concretos cuando emprendemos un proyecto de Networking personal, qué podemos ofrecer a los demás y cuáles son los medios óptimos para lograr nuestros objetivos con los recursos con los que contamos. Quizá por eso el “Activo” de Networking Activo.
Si con todo ello no os convencéis de lo importante que es el Networking y lo asequible que realmente resulta, pensad una cosa: el año pasado, Antonio Calvo-Armengol, de la Universidad Autónoma de Barcelona, publicó un estudio en el que diferenciaba entre contactos fuertes, los más cercanos y personales, y contactos débiles, los que se consiguen en primera instancia vía Networking. Las conlusiones del estudio demostraban que los contactos débiles son más utiles a la hora de, por ejemplo, encontrar un nuevo trabajo o nuevas oportunidades de negocio, ya que los contactos más cercanos sólo nos aportan información que ya solemos tener, mientras que los débiles actúan como puentes entre las islas que forman los grupos de amigos más cohesionados. Estos puentes que nos brinda el Networking favorecen así el flujo de información entre las islas cotidianas. Los trabajos de Antonio sobre redes sociales y mercado laboral se basan en las más modernas teorías económicas y podéis encontrarlos en la red. Os los recomiendo como vuestro primer paso en pos del Master Personal en Networking.
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:-)
Innovación
Escrito el 20 de Mayo de 2008 a las 7:54
A ver si nos enteramos, señores: la innovación no es algo que simplemente ocurre, como la venta no es algo que simplemente ocurra, o la facturación, la limpieza de la oficina o la formación. La innovación, señores, es un proceso más de la empresa y como tal debe ser gestionado. Me encuentro con demasiada frecuencia con empresas en las que el concepto de “innovación” consiste en decirle a los empleados que deben ser creativos e innovadores y luego abrir un buzón de sugerencias o una intranet que languidece y duerme el sueño de las herramientas en las que se puso demasiada fe. Porque esa es otra, señores, ya esta bien de poner tanta fé en las herramientas. “Necesito una herramienta para implantar Scrum”, leía hace poco en un foro. “Recomiéndame una herramienta para gestionar mi tiempo”, me pedía hace tiempo un compañero. Que no es eso, señores. Que no.
En General Electric, por poner un ejemplo, tienen un evento llamado GE Workout, en el que mandan a 30, 40 o 50 trabajadores fuera de la empresa tres días: nada de trabajo, nada de correo, nada de teléfonos móviles. Durante esos tres días, los trabajadores piensan en formas de hacer mejor su trabajo, producir mejores resultados o introducir mejoras en los productos, y compilan una lista con todas las sugerencias. El compromiso de GE es que en 48 horas un ejecutivo revisará la lista de propuestas y aprobará una serie de ellas (no todas). Y a partir de ahí se espera que sea el propio equipo de trabajo el que implemente dichas mejoras (que esa es otra: proponer está muy bien, pero luego hay que estudiar, aprobar e implementar…¿Váis viendo como sí que es un proceso?).
En Toyota, el templo del Kaizen (mejora continua), cuentan que Taiichi Ohno increpó un día a un responsable de zona porque los estándares que tenía colgados bien visibles (otra de las prácticas magníficas de Toyota) habían amarilleado con el tiempo. Ohno le dijo “es usted un ladrón: usted roba su sueldo todos los meses. Su trabajo es mejorar los estándares constantemente, y estos estándares tienen por lo menos un año y medio. ¿Para qué le pagamos a usted?“. De hecho, la gente que empieza a leer sobre el sistema de gestión del talento en Toyota y el tremendo foco que hay en cuidar, formar y delegar en los empleados y en los equipos de trabajo pueden formarse una imagen equivocada del Taiichi-San: por lo visto era un ogro de cuidado. Pero tenía las cosas muy claras.
En 3M todos los empleados tienen un 15% de tiempo para dedicarlo a proyectos de investigación y desarrollo, tengan que ver con su area de competencia o no. Todos los empleados, desde el CEO hasta el conserje. Todas las ideas son bienvenidas, y nunca se coharta la creatividad de nadie con comentarios tipo “menuda chorrada” o “nosotros no hacemos eso”. En Google, si no recuerdo mal, hay un 20% de tiempo para proyectos “personales”, ya sean un blog, una web, una nueva aplicación… Tened en cuenta, jefes tiranos del mundo, que el cerebro humano estándar no tienen más de seis horas realmente productivas al día cuando hablamos de tecnologías de la información (programación, creatividad) y no de apretar tuercas. Así que nada de llevarse las manos a la cabeza: vuestros empleados probablemente ya están dedicando esas una o dos horas al día a temas personales (messenger, web, correos electrónicos, café con los compañeros…). Y perseguir un 100% de productividad es inutil y dañino, como os contará cualquier administrador de servidores. Por encima del 80%, solemos entrar en trashing, algo de lo que hablaré otro día, pero que podemos resumir como abarcar mucho y apretar poco.
Así que ya sabéis: si queréis innovar y competir en el mundo 3.0 que se nos viene encima, es mejor que empecéis a pensar en cómo vais a institucionalizar un proceso de innovación en vuestra empresa. Por supuesto, podéis buscar quién os eche una mano… O:-)
Tapar
Escrito el 11 de Mayo de 2008 a las 19:50
Vaya. Que ocupado estoy y que poco escribo. Fin del apartado apologético.
Escuchaba esta mañana en la radio de un taxi (uno de mis pocos contactos con la realidad cotidiana últimamente) que en Madrid, en un hospital, hay un pollo montado a cuentas de una colonia de bacterias asesinas en la UCI que se han llevado por delante a varias decenas de enfermos. Los profesionales sanitarios consultados han dicho que llevan meses denunciando esta situación ante los correspondiente órganos competentes del hospital y de la administración sanitaria y que no han recibido respuesta alguna a sus quejas.
Es más, me atrevo a postular que más que no recibir respuesta lo que han recibido ha sido la directriz de taparlo todo. Que no se sepa. Que no salga “la mierda”, que es el término técnico al que recurren habitualmente las empresas cuando se refieren a los problemas que no se solucionan. Lo juro, en casi todas las empresas por las que he pasado he llegado a escuchar lo de “que no salga la mierda a la luz”. O yo he tenido muy poca suerte, o esto ya es cultural.
Curiosamente, cuando uno estudia empresas excelentes, en el sentido de la búsqueda continua de la excelencia, se encuentra con que, instaurada en la cima de los principios, prácticas y valores corporativos, se encuentra la confianza absoluta en los equipos de trabajo y en su habilidad para resolver los problemas al ser los que mejor conocen el trabajo que desempeñan, así como la instauración de un proceso constante e inexorable que saque a la luz los problemas, no con ánimo de buscar culpables y cortar cabezas, sino con el objetivo de analizar las causas raices y proponer las líneas de acción que se encaminen a la erradicación permanente de dicho problema. Al fin y al cabo, el Kaizen, la mejora continua, no deja de ser simplemente eso: exorcizar demonios, para lo cuál lo primero es, como sabe todo buen exorcista, jugador de rol o aficionado a la literatura gótico-fantástica, nombrarlos.
Sin embargo, cuando nos dedicamos a “tapar la mierda”, el conjunto de valores y mensajes que estamos transmitiendo no ya a los empleados en cuestión, sino a toda la organización, es brutal. No te preocupes de estas cosas. Tu a lo tuyo. No valoramos tus sugerencias. No toques las narices. No te dediques a chinchar y señalar problemas. Estas cosas son así y punto. Siempre han sido así. No hay soluciones.
A corto plazo “tapamos la mierda”. Pero a la larga, este tipo de estrategias solo tienen consecuencias negativas. Al final las cosas salen, y magnificadas. Encima se sabe que los problemas eran conocidos pero no se ha hecho nada por solucionarlos. Y por el camino nos hemos cargado la confianza en las personas y la cultura corporativa. Sin contar con las pérdidas potenciales por las mejoras que no se instauraron en su momento y que llevarían tiempo cundiendo. Comentaba antes lo de las empresas excelentes, pensando precisamente en el Kaizen, la mejora continua nacida en el seno de Toyota. Pues bien, otro de los principios básicos de estas empresas es el foco constante en el largo plazo, incluso a costa de pérdidas en el corto. Otra de las cosas que no hemos interiorizado aun en según qué empresas y según qué entornos.
Y luego a estas organizaciones se les pide que instauren un proceso de innovación (porque, a ver si nos enteramos de una vez en este país, la innovación es un proceso y como tal debe ser gestionado) todo lo que se les ocurre es poner un “buzón de sugerencias” o hacer “concursos de ideas”. Pero a ver quién tiene ideas cuando, durante añós y de forma sistemática, nos hemos dedicado a machacar a todos los que han apuntado un área de mejora (buen principio para la innovación, por ejemplo). Y es que la cultura se acaba comiendo con patatas cualquier estrategia. Así nos luce.
Pair PowerPointing
Escrito el 27 de Abril de 2008 a las 10:44
Hace unos días estuve preparando una presentación para el kick-off de un proyecto en el que colaboro con otra empresa. Faltaban tres horas para la reunión y aun no había terminado, así que el jefe de proyecto de esta empresa y yo nos sentamos ante el portatil y le dimos los toques finales a la presentación entre los dos.
Pues bien, no solo produjimos la que a mi juicio es una de las mejores presentaciones que he realizado hasta la fecha, sino que ambos aprendimos varias cosas sobre cómo realizar un power-point. Hoy mismo estoy haciendo otro y me he sorprendido utilizando intensivamente un par de herramientas y consejos que hasta ahora no había tenido en cuenta.
Al fin y al cabo, lo que estuvimos haciendo es el equivalente a la práctica de programación por parejas que describe XP (programación extrema) y, efectivamente, lejos de ser un desperdicio por tener a dos personas haciendo lo que en teoría podría hacer una, la inversión en calidad que supone tener cuatro ojos y dos cerebros revisando lo que se hace realmente paga cuando se revisa la visión global del proyecto. Item mas: el nivel de conocimiento del equipo aumenta drásticamente, ya que se produce una transferencia de mejores prácticas de forma natural.
A los que todavía no hayáis introducido prácticas de pair programming en vuestros equipos ágiles, os animo realmente a que empecéis a hacer algún experimento, porque estoy seguro de que si lo implementáis correctamente los resultados os van a sorprender mucho más allá de lo que pensáis.
actualización: me doy cuenta de que todavía no he referenciado en el sitio las estupendas “death by powerpoint” y “how to: visual effects in power-point”.
Bean Counters vs Marketing guys
Escrito el 23 de Abril de 2008 a las 13:00
By their very nature financial analysts tend to be defensive, conservative, and pessimistic. On the other side guys in sales and marketing are aggressive, speculative, and optimistic. They’re saying let’s do it, while the bean counters are cautioning why you shouldn’t. If the bean counters are too weak, the company will spend itself into bankruptcy. But, if they are too strong the company would not meet the market or stay competitive. In a company you need both sides of the equation.
Lee Iacocca, uno de los grandes de la industria del automovil. Extraido de su autobiografía, que ha vendido algo así como siete millones de ejemplares sólo en los EE.UU. Dice la Wikipedia que sólo la biblia y Juan Salvador Gaviota han vendido más, pero claro, eso debió ser antes de Harry Potter :-/
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…
Language Shyness y cultura corporativa
Escrito el 14 de Abril de 2008 a las 19:09
Sequía creativa, señores, acompañada de alta carga de trabajo (¡ole!). Me estoy obligando a escribir este artículo por aquello del comer y rascar, a ver si funciona, así que espero que seais benevolentes.
Al lío del título: no me acabo de acostumbrar al problema de idiomas que tenemos en España. No se trata ya de que la formación en idiomas sea nefasta, que lo es. No se trata de que nos parezca normal que un presidente del Gobierno (el de ahora y el de antes, ojo, que aquí no hacemos política) no sean capaces de mantener una mínima conversación de cortesía en la ONU sin un intérprete por medio. Es que es peor. Es que encima el que habla bien Inglés nos da risa.
Me jacto de hablar inglés bastante bien. Quien me conoce sabe que gusto poco de ponerme medallas, pero las que me corresponden me corresponden, y aparte de haberme formado en un colegio bilingüe en su día me tocó hasta lidiar con negociaciones de contratos bastante importantes con multinacionales en inglés, cosa que le curte a uno. Pero incluso siendo el que le sacaba las castañas del fuego a la empresa a la hora de negociar con los americanos, cada vez que tenía que hablar por teléfono en inglés mis compañeros de departamento se descojonaban partían de la risa y se dedicaban a imitarme en plan wachu-wari-wari. No me extraña que algunos compañeros, al hablar en inglés, bajasen la voz (con lo cual la comunicación, ya de por sí complicada por teléfono, se volvía poco menos que dantesca… De chiste de chiquito, vaya).
En normal entonces que muchos compatriotas sufran de language shyness: vergüenza a la hora de hablar en otro idioma. Incluso algunos que (me consta) tienen un buen nivel de comprensión y a los que no he oido pronunciar una palabra de inglés, ya dependiera de ello su sustento. Magnifico. Eso en un mundo en el que, nos guste o no, la información en Internet, los libros técnicos más punteros, los discursos de personalidades de nivel internacional y demás recursos de crucial importancia están en inglés.
Como reflejaba hace poco en una cita, una cultura sólida se come con patatas cualquier estrategia, pero esto funciona en los dos sentidos. Ya podemos subvencionar todos los cursos de idiomas en la empresa que queramos, que mientras la cultura imperante sea la de reirse del que prospera…
Linus Torlvalds On KDE vs Gnome
Escrito el 25 de Marzo de 2008 a las 22:11
I personally just encourage people to switch to KDE. This ‘users are idiots, and are confused by functionality‘ mentality of Gnome is a disease. If you think your users are idiots, only idiots will use it. I don’t use Gnome, because in striving to be simple, it has long since reached the point where it simply doesn’t do what I need it to do. Please, just tell people to use KDE.”
Es un crack, no se puede negar. Os recuerdo esta otra entrada memorable del creador de Linux. Más info por aquí.
-
Artículos recientes
-
Categorías
-
Archivos
-
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.m (arroba) presionblogosferica.net. También puedes seguir el blog a través de su Feed RSS
¿Un café?
Buscar:
Suscriptores:
Tags
2.0 3G 2008 actitud Agile andalucía apple artículos asesor aspecto atrevete autoayuda autonomo autonomos ayuda backup Blogs blogueros Boris Gloger buddha burbuja business angel business plan C++ calendario cambio capital carrera cerveza cervezas clientes colaboración comentarios comunicación conciliación consultoría contactos conversaciones covey crack Creatividad CRM CSM cultura curriculum curso customer care David Allen diodo diseño EBE07 economía efectividad einstein ejercicios empleo emprendesur empresa empresarios empresas encuesta equipos estadísticas estrategia Eventos facturable facturas feedback flickr Formación freelances FUD funky business futuro garajes gente Gestión GMail GNU Google GTD guy kawasaki hábitos henrik kniberg Herramientas horarios IBM independencia financiera infojobs infoq ingenieros Iniciador innovación inversores ishikawa iweekend java jefe de proyecto Jeff sutherland jornada laboral kaizen karma Ken Schwaber lean liberlabor Libros Linus Linux málaga Madrid mailing manifiesto Marketing mente mercado laboral micropost microsoft miedos Mike Cohn mision mochila motivación muebles navidad negociación negocio negocios networking objetivos ofertas oficina oficinas ONG pareto pathsync peopleware personas php pizarra plan de negocio planhq PMBOK PMI PMP positivismo proactividad problemas productividad producto programación programadores proyectalis proyectos proyecto vital rails rentabilidad responsabilidad social reuniones richdadclub riesgo ruby scrum scrum & xp from the trenches ScrumMaster Scrum y XP desde las trincheras servicios sevilla sistemas SL social start-up startup Stephen Covey suerte SugarCRM tecnología Telefónica teletrabajo tema tercer sector tiempo time tracking toyota transparencia twitter VC ventas venture capital viaje viajes video videos vision web wii wordpress wozniak xp yahoo zona de confort
Que se dice por aquí:
- danieltellez: Eso es como el “just say no” pero del lado contrario, no ? … (es broma)
- danieltellez: Yo necesito un tatuaje de esos también… :$
- Jose Luis de la Rosa: Por dios!!! No estoy solo en el mundo… es desalentador encontrarse con ese tipo de...
- Rafa: Aytorn Senna (uno de los más grandes pilotos de Formúla 1) dijo: “Si tengo todo bajo control, es que no...
- Jordi Bufí: Voy a tatuarme este post en la barriga (pero al revés, para poder leerlo cada mañana cuando me...
Qué se dice por ahí:
- externalidades: Don Patrón
- Negociando los plazos: información | Presión Blogosférica En Pymes y Autónomos | La importancia de la liquidez y...
- ChemaHoyos.es: Me interesa (6)
- Presión Blogosférica: Felicidad de 9 a 5
- lboisset’s Ruminations: Y más y más tareas
