Hire Slow
Escrito el 1 de Diciembre de 2009 a las 20:49
Post rápido: anotación y extractos de algunos materiales que ando manejando últimamente sobre formación de equipos:
Esta es bastante conocida. Hace unos años Google puso estas vallas publicitarias por la zona de la bahía de San Francisco (si no recuerdo mal). Al encontrar la respuesta y ponerla en un navegador, uno obtenía instrucciones para participar en un proceso de selección de Google.
El proceso de selección de Google es durísimo, y a pesar de ello han pasado en pocos años de 2.000 a más de 18.000 empleados en todo el mundo. Aun así, mucha gente justifica sus bajos estándares de contratación porque “nos hace falta gente sea como sea”. Y no, el salario no es toda la historia. La gente que deja Google se queja precisamente de bajos salarios comparados con lo que podrían ganar en otros sitios (además de, claro está, gran presión y, por lo visto, exceso de burocracia, OMG! :-O :-O ).
En Vancouver, Canada, Electronic Arts utilizó estas. No se aun si fue primero el huevo o la gallina (Google o EA, me inclino a pensar que Google), pero ordenando los caracteres ASCII de la publicidad se lee “Now Hiring”. Niiiice.
Ya sabeis el dicho, “Hire Slow, Fire Fast”. Lo segundo es mucho más facil que lo primero, claro, pero ni tan gratificante ni tan productivo 
.
Equipos o cirujanos
Escrito el 25 de Noviembre de 2009 a las 11:16
Me encuentro ultimamente con algunas organizaciones que han ido creciendo desde equipos pequeños de personas y, conforme han ido añadiendo miembros al área de desarrollo, han ido evolucionando hacia un modelo de un proyecto - una persona. Se trata (espero) de una adaptación del “paradigma del cirujano estrella” publicado por IBM en los 60-70, en el marco del desarrollo de OS360 (¿alguien ha leido The Mythical Man Month? 
). Según este modelo, los proyectos más productivos que IBM había detectado eran aquellos en los que existía un “cirujano estrella” que tenía en su mente la arquitectura y el diseño y realizaba toda la programación rodeado por un equipo de ayudantes (documentadores, testers, administradores…). Según las mediciones de IBM, un programador estrella aportaba 10 veces la productividad de un programador medio. Pilar Jericó, en “Gestión del Talento” (citada por Juan Palacio en su libro, si no recuerdo mal) va más lejos y afirma que en el mundo tecnológico los mejores lo hacen entre 50 y 100 veces mejor que la media, y la cifra aumenta conforme la tecnología se hace más compleja.
Monos y máquinas de escribir, vaya. Quien no se crea estas cifras, que meta a 100 programadores promedio en una sala y a Alan Cox en la otra, y a ver quién termina antes con la pila TCP-IP del núcleo de Linux 
.
Pero antes de que despidáis a toda vuestra plantilla de programadores promedio (a mi entre ellos, jejejeje) y salgais al mercado a buscar programadores estrella, preguntaos por qué el modelo fue abandonado.
Even though, que dicen los ingleses: suponiendo que el modelo sea válido en todos los casos, el problema es que lo que me suelo encontrar en las empresas con las que trabajo son programadores my buenos, estupendos, con talento… Pero seamos francos y humildes: no somos Alan Cox .
Así que ya tenemos el primer problema de este modelo: encontrar a estas “estrellas” que hacen de todo, que son capaces de enfrentarse a todo tipo de proyectos y productos. Y pagarles. Y fidelizarles. Y que no se conviertan en “Prima Donnas” tecnológicas a la primera de cambio.
Pero incluso obviando el tema de las estrellas, el enfoque de un proyecto - una persona (a veces en relación muchos a uno, jejeje) tiene una serie de problemas considerables, que es por lo que en Agile consideramos los equipos como los bloques de construcción básicos de proyectos, procesos y empresas. Y ojo, que un conjunto de personas que se sientan juntas no es lo mismo que un equipo. Un equipo es una forma de pensar ante todo, y el espacio que comparten no puede ser únicamente físico.
A lo que ibamos, que parezco una abuela divagando. Problemas del enfoque de un proyecto - una persona:
- Escalabilidad: el modelo funciona cuando tenemos cinco o seis personas, puesto que, para ver el estado del portfolio de proyectos, no tengo más que hacer una ronda por estas personas y que me cuenten como va todo. Es el Scrum Diario de Scrum o el stand up meeting de XP. Pero cuando la empresa empieza a ir bien y a crecer el modelo no tarda en colapsarse. Cuarenta personas, todas contándonos el estado de su proyecto (o sus proyectos) todos los días, o todas las semanas… Imposible. No hay más remedio que multiplexar. Cinco grupos de ocho personas, y un responsable por cada equipo. Con eso puedo volver a mis rondas diarias con cinco personas que me resumen el estado de todo. Mejor. Cada proyecto sigue asignado a una persona concreta (por ahora), pero hemos resuelto el problema de la escalabilidad… Formando grupos de personas (aun no equipos).
- Robustez: ok, tengo ya grupos de personas, pero de repente se va Paquito, y hay que traspasar sus proyectos. Como es el único que los conoce, estos proyectos van a sufrir considerablemente. Y lo que es peor: el año que viene nos piden que repasemos algunos proyectos de Paquito y nadie sabe nada de ellos. Relexionamos: en el futuro sería interesante que tuvieramos estándares de como hacer las cosas y documentásemos bien los proyectos para que podamos solucionar estas situaciones de una forma mejor. Pero el problema es que por mucho que le decimos a la gente que documente, como siempre vamos hasta arriba, al final siempre se queda la documentación por hacer. Quizás si las personas estuvieran un poco más al tanto de lo que hacen sus compañeros… Pero es muy dificil, muy dificil. Seguimos haciendo las cosas como siempre y obteniendo los mismos resultados.
- Flujo de conocimiento: cuando alguien comete un error, típicamente lo tapa, lo corrige y listo. Mañana otra persona, en la otra punta de la oficina, cometerá el mismo error. Y pasado otra. Y cada uno da soluciones diferentes. Por otra parte, un día alguien encuentra una solución ingeniosa a una necesidad habitual de los proyectos. Pero nadie se entera. Entonces reflexionamos y decimos que hay que montar un sistema de gestión del conocimiento, y desarrollamos una intranet, un blog, un wiki… Pero nadie los usa. Si hubiera una forma de que las personas se contasen unas a otras sus problemas y soluciones, y que unos revisasen el trabajo de otros… Bah, muy dificil.
- Duplicación: al igual que ocurre con los errores, los desarrollos comienzan a duplicarse. Un día nos encontramos con que dos personas, en dos esquinas de la oficina, han desarrollado dos librerías idénticas para el mismo problema. Vaya por Diox. Si hubiera una forma de sincronizar a todo el mundo…
- Incorporaciones: cuando reclutamos a juniors, sería interesante que pudieran ir aprendiendo de los seniors. Pero los seniors están muy liados con sus proyectos como para andar enseñando a la gente. Sí, ya dijimos antes que deberíamos tener estándares de códificación, sistemas de gestión de conocimiento… Pero no se hacen. Si pudieramos organizar a la gente en equipos, equipos de verdad, no solo grupos de personas, que se sincronicen a diario, compartan tareas y proyectos, programen por parejas de vez en cuando, hagan retrospectivas de grupo frecuentemente, analicen todos los proyectos juntos, distribuyan la carga según ellos mismos convengan… Así sería mas rápido y sencillo que una persona recién incorporada fuera pillando el ritmo y el estilo del equipo.
- Flexibilidad: si una persona está muy cargada y queremos reforzar su proyecto con más personas, significa que esas personas deben coger el proyecto desde el principio y adaptarse al enfoque que el primero ha dado al desarrollo. Si de alguna forma se hubieran hecho revisiones breves del proyecto desde el principio en equipo, no solo se habría podido ir incorporando el feedback de todo el mundo al enfoque del proyecto (¿Crowdsourcing anyone? ), sino que sería más fácil incorporarse al proyecto.
- Estandarización: antes hemos dicho que sería bueno contar con estándares para facilitar el trabajo en equipos, pero los estándares son buenos per se, no solo como herramienta. Permiten, como hemos visto, que las personas que se incorporan se adapten más rápidamente y nos permiten analizar de una forma coherente y estándar el rendimiento de los procedimientos para buscar las mejores soluciones y difundirlas entre los equipos.
- Tribus: asumidlo, los seres humanos somos tribales. Los que no lo eran se extinguieron en la última edad de hielo, muertos de hambre o devorados por los tigres dientes de sable, es una cuestión puramente evolutiva. Y a todos nos gusta pertenecer a una tribu, no ser guerreros cubiculares aislados, por muy romántica que nos parezca la idea del “justiciero solitario”. El problema es que cuando formamos una tribu, lo primero que buscamos es otra tribu a la que declarar la guerra. Y si nuestra tribu es “desarrollo”, le declararemos la guerra a “QA”, a “Infraestructura”, a “Diseño”… Es mejor crear la “tribu equipo”, donde todos colaboramos para sacar adelante los proyectos. E independienteemente de si nuestros equipos son multidisciplinares o no, el pertenecer a una tribu aumenta la motivación, la la motivación aumenta la productividad (quien no crea firmemente en esto debería de reflexionar largo y tendido sobre temas más fundamentales que equipos si / equipos no)
Y se me ocurren varias más, pero entonces este artículo se haría insufrible. ¿Como lo véis vosotros?
El horno de las magdalenas
Escrito el 14 de Septiembre de 2009 a las 14:57
Esta es una historia que cuento en mis cursos y suele gustar bastante. Tanto que ya me han pedido alguna vez que la escriba e incluso tengo un dibujo dedicado que reproduzco al final del artículo (gracias, Juanjo, iremos poniendo el resto poco a poco ). La cosa va así:
Supongamos que tenemos una fábrica de magdalenas que consta de las siguientes partes:
.- Una cinta sin fin en la que se van colocando los moldes de magdalena con la masa
.- Un horno en el que se van introduciendo los moldes de cinco en cinco y son horneados durante 5 minutos
.- Una salida del horno, por la que las magdalenas ya horneadas salen en dirección al cliente
Tenemos a dos personas operando la fábrica. Una opera la cinta y va colocando los moldes. La otra opera el horno. La primera se llama Don Dueño de Producto, y la segunda se llama Don Equipo. Lo vamos pillando, ¿no? 
La fábrica de magdalenas funciona muy bien y los clientes están contentos con el producto. Tan contentos que empezamos a tener más clientes, más demanda, y a Don Dueño de Producto le entran las prisas.
Entonces, en medio de una hornada, Don Dueño de Producto se dirige a Don Equipo y le dice “oye, abreme el horno que quiero ver cómo va todo”. Don Equipo le responde “no hombre, no… Si abrimos el horno se va toda la temperatura, y las magdalenas no suben”. Y Don Dueño de Producto, refunfuñando, se aguanta.
Pero entonces entra corriendo un mensajero con un encargo: un bizcocho urgente. El bizcocho ocupa el espacio de tres moldes de magdalenas. Y Don Dueño de Producto dice “parad la hornada, que hay que meter un bizcocho urgente”. Don Equipo dice “mira, la hornada lleva dos minutos… ¿No puedes esperar tres minutos más para que metamos el bizcocho?”
“¡No! ¡No lo entiendes! ¡Es urgente! ¡El cliente lo demanda!”. Don Equipo mira al cielo resignado y dice “ok, ok, paramos la hornada y tiramos estos moldes para empezar una hornada nueva de cinco minutos”.
Y entonces, para asombro de Don Equipo, Don Dueño de Producto le mira con cara de horror y dice “¡No! no lo has entendido… Hay que hacer el bizcocho en esta hornada y *además* de las magadalenas“. Cuando Don Equipo logra salir de su asombro le dice “pero vamos a ver… Lo primero es que te vas a cargar las magdalenas que estan metidas, pero incluso aunque aceptes eso, ¿dónde quieres que meta el bizcocho si el horno ya esta lleno?”.
Entonces Don Dueño de Producto se enfada de verdad. “¡Estoy harto de quejas! No entendéis los malos tiempos que vivimos y lo importante que es este encargo, el cliente siempre tiene la razón. Hay que hacerlo y hay que hacerlo. Si no se puede, pues se tiene que poder. Y punto. Y si no hay sitio, pues lo colocais encima de esos tres moldes de magdalenas, y como escuche mas quejas voy a empezar a escribir cartas de despido a la voz de ya”.
Ante la amenaza, Don Equipo abre el horno (con lo que se va la temperatura), coloca el bizcocho encima de tres moldes (con lo que el bizcocho queda cerca de la resistenci superior del horno y las magdalenas aplastadas), cierra el horno y espera tres minutos a que termine la hornada, también conocida como Sprint. El resultado es el lógico:
Claro, al realizar el envío al cliente, este lo devuelve indignado. Así que ahora tenemos que hacer cinco magdalenas, un bizcocho y las cinco magdalenas que tocaría hacer ahora. Suponiendo que hagamos bien las cosas, generamos ahora mismo un retraso de ocho magdalenas: tenemos que parar la linea, meter cinco magdalenas y luego meter el bizcocho, y aprovecharíamos el segundo turno para meter al menos dos magdalenas nuevas, así que en dos turnos produciríamos dos magdalenas nuevas además de todo el trabajo rechazado.
Si desde el principio hubieramos hecho las cosas bien y hubieramos esperado al segundo turno para meter el bizcocho, solo habríamos generado un retraso de tres magdalenas (las que ocupa el bizcocho). Ahora sin embargo hemos generado deuda técnica, y típicamente Don Dueño de Producto ser irá poniendo cada vez más nervioso y seguirá pieiendo que metamos más cosas de las que caben en el horno
Moralejas (algunas ):
1.- Los equipos necesitan su temperatura adecuada. Ni tan frío que no cueza ni tan caliente que se queme. La sopa, por ejemplo, tiene su temperatura de cocción a la que todos los ingredientes dan su punto. Más frío y no sabrá a nada, más caliente y se quemará. Esta temperatura adecuada de equipo es lo que yo denomino un “estrés saludable” o, en términos Agile, el “paso sostenible”, es decir, el ritmo que podemos mantener indefinidamente sin cansarnos.
2.- El Dueño de Producto debe de manejar la Pila de Producto, no la Pila de Sprint. Si el Dueño de Producto se dedica a interferir en el espacio de trabajo del equipo (Sprint), no podemos esperar que emerja la autogestión ni los estados hiper-productivos asociados a Scrum. Eso no quiere decir que el equipo no informe diariamente del progreso, proporcione toda la visibilidad posible y acepte el criterio del Dueño de Producto en las entregas (si el Dueño de Producto dice que no vale, es que no vale). Esto también aplica a cualquier entorno jefe-empleados, no necesariamente a Scrum: los equipos tienen que tener su espacio y su margen de maniobra, y la microgestión solo conduce a la suboptimización y al bajo rendimiento.
3.- Ante una situación de deuda técnica cualquier momento es mejor que el siguiente para decir “alto” y aplicar el principio Lean de Jidoka. Dicho de otra forma, cuando uno está en el fondo de un pozo lo primero que tiene que hacer es dejar de cavar. Tened en cuenta que, como otros tipos de deuda, crece a interés compuesto (por cierto, es falso que Einstein dijera que se trata de la mayor fuerza del Universo o el mayor invento del siglo veinte ).
Manuel Fraga y la selección de personal
Escrito el 10 de Febrero de 2009 a las 12:45
El propio Jesucristo tuvo un Judas entre los Apóstoles. E incluso su propio sucesor, el Papa San Pedro, le negó tres veces. Así que si el mismo Jesucristo cometió errores de selección de personal, imagínese usted el resto de los mortales”
Vía Se Lo Que Hicisteis. La noticia se puede ver aquí y en trescientos sitios más, lógicamente. Yo personalmente paso de las implicaciones políticas y me quedo con la frase . Comentarios políticos o religiosos serán inmisericordemente eliminados. Alabado sea Su Sagrado Carbohidrato.
Risto Mejide: que llueva, que llueva…
Escrito el 30 de Enero de 2009 a las 10:35
[…]
Sí, creo en las purgas de mediocres. Qué pasa. Creo que los que sólo se preocupan por salvar el culo lo tienen ahora mucho más difícil, y eso me hace muy pero que muy feliz. Me alegra tanto, porque también me jode de manera desmesurada ver que a veces -como también se dice de los difuntos- son los buenos los que se van.[…]
Pero lo que más me interesa de estar realmente jodidos es la cantidad de oportunidades que, sin querer, empiezan a desfilar por delante de nuestra manifiesta incapacidad para verlas venir.
Cuando las normas de antes ya no valen, el riesgo ya no se tiene, en el riesgo se está. Cuando todas las previsiones provocan poco más que risa floja, atreverse no es una opción, sino gerundio. Y esa combinación, dicen los entendidos, es el abono perfecto para las buenas ideas.
Por eso, quiero acabar con un cariñoso mensaje dedicado a todos los lameculos que siguen lloriqueando para que otro les saque las castañas del fuego.
Tres palabras: no hay otro.
Tres más: jamás lo hubo.”
Artículo de Risto Mejide en ADN.es. De pasta boniato me he quedado. Las acciones de Mejide acaban de subir cien enteros en mi bolsa particular.
Gracias a Xavi por el enlace.
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:
- No quiero hacer Scrum diario: es una forma de control y, como toda forma de control, coharta la libertad del individuo. Idem para el tablón Scrum y el diagrama de Burn Down
- ¿Que qué voy a hacer hoy? Pues estaré “con lo del cliente A”. No puedo dar más detalles, porque eso sería interferir con el equipo. No, no puedo decirte con qué tarea me pongo, ya te hemos dicho que el tablón es microgestión y fiscalización. Las cosas estarán cuado estén. ¿Es que no confías en mí?
- No controles mis entregables: si me corriges, me estás microgestionando. Si yo, que soy el que sabe de esto, digo que el producto está bien, es que el producto está bien. ¿Quién eres tú para contradecirme? Además, ¿por qué hablas tú directamente con el cliente final? Eso es que no confiais en mí. ¿Que el cliente quiere otra cosa? Bah, el cliente no tiene ni idea.¿Que hay que cambiar algo? Haberlo dicho antes, ya no se puede.
- No puedo dar estimaciones. Si doy estimaciones y luego no se cumplen, vendrás a perseguirme. Si me acorralas, triplicaré mis estimaciones para ir sobre seguro.
- Si, vale tu prioridad es la historia uno. Pero la quince es más bonita, la veinticuatro más divertida, la setenta y tres más fácil y la ciento dieciocho simplemente me apetece más. Ah, y hemos metido siete historias que a tí no se te habían ocurrido pero que nosotros estamos convencidos de que son importantísimas.
- Y, bueno, dije que iba a tener tres historias y solo hay una. No ha dado tiempo, que se le va a hacer. ¿Que en qué hemos invertido las horas? Ah, no, eso es control y fiscalización y va en contra de Agile. ¿Que a partir de la semana vamos a cumplir los horarios estríctamente? Eso va en contra de la política de flexibilidad horaria de la empresa. ¿Es que no confías en nosotros? (again)
Como comprenderéis, ante un panorama como este hay muy poquitas cosas que se puedan hacer. ¿Se os ocurren algunas?
Conversaciones
Escrito el 14 de Noviembre de 2008 a las 10:15
- A ver, yo creo positivamente que a la gente le gusta avanzar, progresar, tener una sensación de propiedad sobre sus proyectos… Si te pagasen lo mismo por quedarte en casa mirando al techo, probablemente al principio te haría ilusión, pero a la larga querrías hacer cosas.
- ¿A mi? a mi no. A mi que me bequen. Lo tengo claro, vamos.
- Pero vamos a ver, a lo mejor lo que pasa es que lo que haces ahora es demasiado monótono, poco creativo… ¿No te gusta el trabajado de investigación, aprender cosas nuevas?
- ¿Cosas nuevas? ¿Para qué? Si yo ya se Java, que es lo que necesito para mi trabajo. No se por qué me tendría que poner ahora a aprender cosas nuevas.
- Pero vamos a ver…¿Me dices que la empresa te da tiempo pagado para estudiar, investigar, aprender y no lo aprovechas?
- Hombre, es que estaría bueno que quisieran que aprendamos en nuestro tiempo libre. Yo trabajo mis horas y punto, mi tiempo es mío.
- Pero tío, que no se trata de trabajar, se trata de aprender cosas nuevas, de desarrollarte como profesional… ¿Qué te dice tu jefe de todo esto?
- Mi jefe está siempre muy ocupado, no podemos hablar con él. Además, es el jefe: no se le pueden decir esas cosas.
- ¿Lo has intentado? Por ejemplo, ¿Por qué no quedáis una vez a la semana para comer juntos y charlar sobre estas cosas?
- ¿Otra vez en mi tiempo privado? Mi comida es mi tiempo de relajación y no tengo por qué dedicarlo al trabajo.
- Pero si no es trabajo, es comunicarte con tu jefe, es desarrollar una relación, es…Vale… Olvídalo… ¿E innovar? ¿No te gustaría hacer cosas nuevas, desarrollar nuevos productos?
- A mi no me pagan para pensar.
- Macho, con esa actitud no vas a poder mejorar tu situación nunca.Mira, en Google….
- ¿Google? Menudos explotadores. Te ponen un montón de cositas, guitarritas, pistas de volley, toboganes y cosas así pero es una trampa para que pases más tiempo en la oficina.
- Ya, tronco, pero más tiempo haciendo las cosas que te gustan y relacionándote con gente que tiene tus mismos intereses.
- Yo tengo mis amigos y no tengo por que relacionarme con la gente del trabajo. Eso me pareceríamuy triste. Yo tengo una vida, ¿Sabes?
- Pero… Vamos a ver, ¿A tí te gusta lo que haces?
- No. A mi no me gusta la informática. Estudié informática porque era lo que había, lo que tenía salida. Yo preferiría trabajar en una ONG.
- Pues tío, no te pases el resto de tu vida amargado. Ve trazando un plan que te lleve a trabajar en una ONG dentro de tres años. Ve tomando las decisiones necesarias.
- Yo ya tengo mi plan: jugar a a primitiva.
- […] :-O
TODOS los comentarios son reales y recogidos de diferentes conversaciones y diferentes fuentes en el último mes.
Queda abierta la carnicería de los comentarios. A ver cuanto tardan del menéame en llamarme tirano explotador esta vez…
Actualización: tal como bien apunta Enderteruel en menéame, exáctamente 12 minutos y 10 comentarios…
PD - actualización: Me recuerdan por la ofi que de muchas de ellas tengo testigos, por si no me creeis…
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…
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.
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.
-
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
|
