Mostrando entradas con la etiqueta humor. Mostrar todas las entradas
Mostrando entradas con la etiqueta humor. Mostrar todas las entradas

sábado, 24 de mayo de 2014

24h - El complejo de Jack Bauer

Ocurre en muchas ocasiones: más de las que nos gustaría y más de las que queremos admitir. En esta profesión de desarrollo de software, en la que tenemos metodologías, métricas, procesos, calidad, más de una vez nos habremos encontrado sufriendo el complejo de Jack Bauer.

Ocurre de forma progresiva: primero tenemos todo planificado y bajo control, todo parece ir sobre la seda, y cuando menos te lo esperas, salta un problema para el cual no tenías un plan de contingencia. La cuestión no es tanto si sabemos o no planificar, sino más bien cómo afrontar los problemas. Esos problemas que se suelen manejar en un comité y que en más ocasiones de las que nos gusta admitir, tememos escalarlos a ese comité por no asumir responsabilidades.

¿La consecuencia? Pues que trasladamos a nuestros equipos esa responsabilidad, enmascaramos la culpa con una falsa urgencia (o no tan falsa), y movilizamos nuestros ejércitos para afrontar lo que parece ser un capítulo de la serie de televisión "24". Con un plazo imposible de cumplir, nos embarcamos en una tarea sobrehumana, y sustituimos la culpa, la gestión y las metodologías por un compromiso y resolución que nos lleva a ser protagonistas de esa serie, donde hay que salvar el mundo, hacer tareas imposibles, recorrer varias veces toda la ciudad y todo ello en 24 horas.

¿Os suena? Pues sí, esto es el complejo de Jack Bauer, personaje protagonista de esa serie de televisión, y que representa muy bien las situaciones de "bombero" o "apagafuegos" en las que nos vemos inmersos.

Esta forma de afrontar los problemas, la podéis encontrar en la red con otros nombres. Uno que me ha gustado es el antipatrón "apagafuegos". Os recomiendo leer esa web de antipatrones.

Hay que tener mucho cuidado con esta forma de actuar, porque lleva a ser estimulante. Nos podemos sentir héroes salvando el mundo, apagando fuegos constantemente, en ese complejo de Jack Bauer. En lugar de afrontar los problemas como lo que son, no podemos tratar de resolverlos todos a la primera de cambio, en ese ciclo de subida (esfuerzo heroíco de resolver el problema) y de bajada (bajón inevitable que tenemos cuando la situación ya es estable y la adrenalina se agota...hasta el siguiente fuego).

Hay quien ve esta forma de actuar como una adaptación al cambio. Pero adaptarse al cambio no significa afrontar los problemas con sesiones a lo Jack Bauer (es decir 24 horas sin dormir y con esfuerzos histéricos para resolver las cosas). Hay que atajar los problemas de base, porque distraer al equipo de esa forma significa alejarlo del objetivo del proyecto. Esa distracción no supone 24 horas, sino mucho más: el coste de recuperar el ritmo, y también de recuperarse de ese esfuerzo.

Los cambios los gestionamos nosotros, no al revés.

sábado, 11 de enero de 2014

MasterDev, el MasterChef del software

Hala, por fin se ha acabado en España la versión infantil o "Junior" de un conocido concurso internacional de televisión llamado "MasterChef".

Yo, personalmente, os propongo hacer uno parecido llamado "MasterDev". Los objetivos de este nuevo concurso serían más o menos los siguientes:
  • Los concursantes, tendrían una sección inicial del programa en el que se mostraría el lado humano: cómo han convivido, cómo han aprendido las últimas técnicas de programación, frameworks, lenguajes, etc. Se les vería su día a día encerrados en "la casa", donde tendrían sus momentos de roce, tensiones internas, se formarían grupos...
  • Por supuesto, habría un apartado de "expulsados" en el que los concursantes elegirían a los 3 nominados. De entre ellos, uno sería expulsado por votación del público.
  • Finalmente, el plato fuerte del programa sería el desarrollo "en directo" de una aplicación, basada en los requisitos y exigencias de los chefs (bueno, en este caso, scrummasters o similar). En este apartado, unos famosos programadores harían de estrellas invitadas y propondrían los casos de uso a desarrollar. Serían los jueces que elegirían a los mejores programadores cada semana. Éstos "Master-Dev" podrían salvar a uno de los nominados, tal y como se hace en otro conocido concurso: "Gran Hermano". Durante esta parte del programa, se nos estaría mostrando a los programadores llevando a cabo las tareas encomendadas, con la tensión de ver el reloj. Para darle mayor realismo, podría ser un reloj marcando la hora de salida del  trabajo, lo que aportaría una tensión increíble.
  • Finalmente, el momento culmen del programa sería cuando los jueces irían diciendo los puntos fuertes y débiles de cada programador, y se elegirían los "Master-Dev" de la semana.
No sé lo que os parece, pero yo creo que no tendría la misma tensión que el programa original "MasterChef". Ver 20 minutos a una serie de programadores, sentados en sus sillas, tecleando como si les fuera la vida en ello, no se si sería digno de ocupar el prime-time de las principales cadenas de televisión.
En el cine, "Swordfish" (2001) ha sido una de las películas en las que más tensión se ha podido observar mientras se mostraba a un programador (Hugh Jackman) tecleando en sus teclados y observando con pasión sus múltiples monitores. Sin embargo, veo difícil el llevar esto a la televisión, especialmente recordando el motivo que hace que Hugh Jackman salve su vida cuando es sometido a presión por John Travolta (sí, se trata del trabajo realizado por cierta señorita). Por cierto, ver a Hugh Jackman programando un peligroso virus simplemente "pegando" cubos entre sí en pantalla, es un puntazo. No tendría la misma tensión si "Swordfish" tuviera un diálogo más realista:
- "A ver...mierda. Me he dejado un punto y coma"
- "Compilo...y a ver....15%....40%....mierda. Dos warnings y 1 error. Pues vaya."
- "A ver...busco el error en google, pero ¿esto que es?"
- "Ah ya lo tengo. Venga, cambio el tipo de la variable....añado el parámetro que faltaba..."
- "Compilo...y a ver...15%...40%...(dios que lento)...60%...mierda. Otro error."

Tal vez se le podría dar algo más de emoción. Y no, no me refiero al trabajito que le hacen a Hugh Jackman en SwordFish para motivarle. Me refiero a comentarlo como si fuera....no sé...un partido de fútbol:
- Atención, John recibe el código, lo compila yyyyyyyyy Uyyyyyy. Un erroooor. Sí señores, un error ha entrado de llenoooooooo. Neumáticos Martinez, los mejores. Compreeeee neumáticos Martínez.
- Señoras y señores, qué tensión! John todavía no ha corregido su error, y Anthony ha compilado con éxito atencióoooooon que ha compiladoooooo.
- Cuidado, cuidado, que un tercer programador está a punto de terminar, es Juan. Recuerden que Juan no había destacado en otros programas, pero ha terminado sólo 1 segundo y 3 décimas por detrás de Philips. Cuidado, todavía no han hecho checkin! Beba Rock-cola, burbujeante, maravillosa!
- Increible! Philips ha perdido el código! Error de aplicación, eso lo deja fuera del concurso! Qué tensión, John está terminando de depuraaaaaar yyyyy gana Juan!  Por tan sólo unas líneas de código por delanteeeeee.

¿Y vosotros? ¿Os gustaría ver un "MasterDev" como concurso?
En fin. Feliz año nuevo.

Update: Gracias a Julián Gómez por la idea de cambiar el titular, y por leerme. Me había quedado muy simplón como "MasterDev" sin más.

viernes, 8 de noviembre de 2013

No te olvides de poner el Where...

Si alguna vez has programado, creo que tienes que ver y oír esto.

http://www.youtube.com/watch?v=i_cVJgIz_Cs

Ha pasado un mes sin publicar anda en este blog, y ya era demasiado tiempo. Y al ver esta entrada de forma fortuita en linkedin, no me he podido resistir. Merecía la pena ponerlo y guardar este momento. Que aproveche...

Gracias a Jorge Eduardo Olaya Perdomo por compartirlo y permitirme conocer la existencia de este vídeo. Y a Jorge Rubira, por publicarlo en YouTube. Saludos.


lunes, 29 de abril de 2013

El vendedor de motos

El vendemotos, es otro de los integrantes de la fauna que podemos encontrar en cualquier empresa de software. El vendemotos no tiene porqué ser siempre el comercial de turno. Hay también vendemotos en otras categorías laborales, aunque suelen estar relacionados íntimamente con otro miembro de la fauna laboral: "el trepa". De éste hablaremos otro día.

El vendemotos te venderá (si es comercial) o tratará de que se use (si es técnico) la última moda tecnológica, supuestamente consiguiendo con ello la mejor eficiencia, mayor productividad, accesible desde el móvil, con soporte para la nube, etc, etc.

El comercial vende-motos

Si es un comercial, se lo ofrecerá al cliente, para mayor horror y desengaño del vilipendiado equipo de desarrollo, que se verá obligado a tratar de implantar tecnológicas poco probadas, de escaso impacto en valor real para el cliente, pero por supuesto, con un coste y un sobre-esfuerzo que pondrá al límite tanto al equipo de desarrollo como a la economía de la empresa. Claro, esto al cliente le dará igual, porque el precio cerrado conseguirá que esto no se le transmita al cliente, que sólo verá con horror como se producen retrasos en unas funcionalidades que para él eran triviales.

El técnico vende-motos.

Si el vendemotos es un técnico, se tratará de un miembro del equipo que tratará de influir en el resto, bien por categoría (analista, jefe de equipo o de proyecto), o bien por insistencia (el auténtico pesado que te está dando la paliza para que uses el nuevo hibernate-struts-mvc-loquesea). Claro, este técnico de pacotilla, auténtica piltrafa tecnócrata, trata de colocar estas novedades...¿pero por qué? Analicemos este punto:
  • Habrá leído unos días antes de las bondades de la nueva tecnología
  • Querrá impresionar a sus responsables o subalternos con estas novedades, atrayendo hacia sí una falsa sensación de profesionalidad.
  • Quizá se aburría, y busca una forma de desarrollarse a sí mismo y a su currículum a costa de sus compañeros y empresa actuales.
  • Quizá lo usó en otro proyecto, que no se parecía a este en nada, y lo que allí le salió bien (o vio a otro que le salió bien), cree que ahora puede encajar. Me encanta cómo se desprecia el valor de la experiencia y de un buen análisis que compruebe realmente lo adecuado de las cosas en relación a los objetivos buscados.  
Después de todo, para cuando se implante la tecnología, o bien le habrá dado tiempo a aprenderlo...o bien ni siquiera la termine implantando él (ya pringará otro), o bien ni siquiera estará ya él en la empresa/proyecto. Cuántos habré visto abandonar los proyectos que ellos mismos han empezado torpedeando con arquitecturas demasiado novedosas.

El mantenimiento, también se verá gravemente afectado. Las nuevas tecnologías, en cuanto maduran, empiezan a ser realmente mantenibles y productivas, pero pobres de los proyectos que las hayan implantado cuanto aún eran novedades tecnológicas: esos proyectos serán difícilmente mantenibles, porque las arquitecturas creadas alrededor de esas novedades para poderlas "sostener", serán reduntantes. Cuántas veces hemos visto implementar en los frameworks (struts, mvc, EF,...) funcionalidades que en sus primeras versiones se han tenido que implementar "a pelo" (es decir, con sufrimiento y dolor).

¿Quién pierde?

  • Pierde el cliente, que ve tirado a la basura su tiempo y dinero, y que con suerte ve una solución cara e inadecuada que podría haberle salido mucho más barata (a corto plazo por el precio, y a largo plazo por el mantenimiento que va a tener).
  • Pierde el equipo de desarrollo, que ve cómo sus horas se disparan al tratar de hacer funcionar cosas imposibles, complejas, bizarras. Sí, habrán aprendido mucho. Me encanta ver cómo los defensores de las novedades se escudan en el aprendizaje. Para aprender, vete a la autoescuela. Cuando sepas correr, coges el Ferrari. Los peatones te lo agradecerán.
  • Pierde la empresa, que ve cómo los costes se disparan al inicio del proyecto, y se tiene que comer con patatas el precio vendido. Al final, o pone a los recursos más baratos para no arruinarse, o todo el mundo a hacer horas extras.

¿Quién gana?

  • El dueño de la tecnología, que ve cómo se usa algo inmaduro y fuera de contexto, proporcionándole un beneficio a través de los vendemotos que han caído en la trampa.
  • El vendemotos, suele ganar, ya que su enorme habilidad de escaquearse, hace que no le afecten los negativos resultados de sus gestiones o falta de habilidad.

¿Y tú? ¿Has visto recientemente a algún vende-motos?

lunes, 15 de abril de 2013

Influencia de la carga de trabajo en el ángulo del monitor

Hoy os voy a relatar hechos verídicos y contrastados. Se trata de una nueva teoría científica que creo que va a revolucionar el mundo de la tecnología. Seguramente pueda vender esta teoría y jubilarme. A ver qué opináis.

Vengo observando una correlación bastante acusada entre el ángulo de los monitores de los programadores, y su carga de trabajo, que voy a ir desarrollando a continuación:

Caso 1: alta carga de trabajo.

La experiencia muestra que cuando el empleado tiene una fuerte carga de trabajo, el monitor se encuentra situado justo enfrente del mismo, de forma que éste forma una línea paralela con el eje de los hombros, y habitualmente, también con la mesa, como muestra la figura siguiente.

Además, resulta interesante destacar que esta posición es independiente de la posición en la que se encuentre sentado el responsable/supervisor del empleado.

Caso 2: baja carga de trabajo durante un corto lapso de tiempo.

La gran mayoría de casos observados permiten notar un aumento en el ángulo del monitor, que ya no se encuentra paralelo al eje de los hombros, como se muestra en la figura. Lo que resulta ya sorprendente, es que el ángulo del monitor puede ser a un lado u otro, y esta vez, sí que hay una dependencia a la posición del jefe, de forma que el jefe parece tener la manía de situarse justo donde su posición impide ver correctamente la pantalla del empleado.

Caso 3: nula carga de trabajo durante largo tiempo

De nuevo, los datos empíricos muestran que en la mayoría de casos, el monitor del empleado que lleva mucho tiempo sin recibir trabajo, acaba como muestra la figura siguiente: prácticamente perpendicular al eje de sus hombros. Para evitar el bizqueo o el colapso del empleado, éste tiende a colocarse "ladeado", corrigiendo de esta forma la postura del monitor.

Otro punto a considerar es que como ocurría con el caso 2, el jefe del proyecto tiende a situarse en el lado del empleado desde el que no se puede ver su pantalla, hecho que hemos atribuido a la mera casualidad.

Influencia de la hora.

Otro hecho sorprendente, es que especialmente en los casos 2 y 3, al principio de la jornada, y cuanto más nos acercamos a la hora de salida, el ángulo del monitor se hace todavía mayor si cabe. Sin embargo, en las horas centrales del día el monitor tiende a volver a su posición normal. De nuevo, hemos de suponer que esto es mera casualidad.

Influencia del número de monitores.

Si en lugar de un monitor, analizamos las situaciones anteriores con empleados que tengan dos monitores, ocurre algo muy curioso. El primer monitor, al que llamaremos "1", permanece siempre frente al empleado (esto es, paralelo a lo que hemos llamado su "eje de hombros"). Sin embargo, el segundo monitor, sí parece verse afectado por los casos anteriores, de forma que sufre ángulos escandalosamente extraños en función de la carga de trabajo.
De nuevo, el número de monitores y la hora del día parecen tener una correlación, de forma que el monitor "1" parece usarse en las franjas centrales del día, y es el segundo monitor (el que hemos llamado "2"), el que recibe mayor carga de trabajo en las horas tempranas, y en las horas cercanas al final de la jornada.

 

Influencia de la distancia al jefe.

Otro punto interesante digno de estudio, es que el ángulo aumenta cuanto menor sea la distancia con el jefe. Es decir, el jefe muy alejado, hace que el ángulo del monitor sea pequeño. Pero si el jefe se acerca, el ángulo se hace mayor.

¿Y tú? ¿Has observado también en tu trabajo este extraño fenómeno?

sábado, 23 de marzo de 2013

El síndrome de Estocolmo

Podemos encontrar en Wikipedia la definición de este tipo de desorden:

Wikipedia: El síndrome de Estocolmo es una reacción psicológica en la cual la víctima de un secuestro, o una persona retenida contra su voluntad, desarrolla una relación de complicidad, y de un fuerte vínculo afectivo, con quien la ha secuestrado. Se debe, principalmente, a que malinterpretan la ausencia de violencia contra su persona como un acto de humanidad por parte del secuestrador.

Esta definición, que nos parece tan fuera de nuestro ámbito de empresas de desarrollo de software, ocurren en nuestra industria mucho más de lo que creemos.

 

El equipo de desarrollo con el Jefe de Proyecto.

Cuántas veces hemos oído a los programadores o analistas excusar al jefe de proyecto que gestionó algún conocido desarrollo o implantación.

Por desgracia, cuanto mayor es el sobre-esfuerzo, cuanto mayores y más largas son las semanas o meses de brutal agotamiento, mayor es el síndrome de Estocolmo. Se llega a oír cómo las más peregrinas excusas surgen de los labios de quienes han sufrido de primera mano las malas decisiones, la pésima gestión (o la total carencia de la misma) de ese jefe de proyecto.

Es normal que aceptemos las imperfecciones de la gente, es correcto. Pero ya no es normal olvidarnos de las responsabilidades y trasladarlas a otros, como si un jefe de proyecto fuera una imagen de un mártir, un inocente de las circunstancias.

El programador con el Analista/Arquitecto.

Tampoco es extraño oír cómo el equipo defiende a su analista responsable, al arquitecto que definió la estructura, a quien pensó (con tan mala fortuna) las pantallas...

Pues sí, el síndrome de Estocolmo también aplica a los perfiles técnicos altos, pues tantas horas con ellos, tantas excusas ofrecidas, acaban por minar la resistencia moral. Después de todo, están con nosotros en las largas semanas (días y noches incluidos) que necesitamos para hacer funcionar sus incompetentes diseños y sus incongruentemente desorganizadas y sobrecargadas arquitecturas.

El programador con el cliente.

No nos engañemos. También podemos sufrir este síndrome con un programador. Si se trabaja mucho tiempo en las oficinas del cliente, llega a establecerse un vínculo entre el equipo de desarrollo y el cliente. Sin embargo, al pasar el tiempo y si el equipo de desarrollo sigue trabajando en las oficinas del cliente, este equipo pierde su vínculo con su propia empresa.

En este tipo de situaciones, nos encontramos con casos en que los desarrolladores obedecen al cliente, aún en situaciones en que saben que están desobedeciendo o contradiciendo las órdenes recibidas de su jefe de proyecto.

Ocurre en desarrollos, pero también en mantenimientos. En un mantenimiento, es típico ver cómo un programador sale corriendo a resolver una incidencia sin esperar a que sea notificado su registro, sin esperar a que sea revisada, escalada, etc. En estos casos, el equipo de desarrollo se preocupa solamente de contentar al cliente, y acaba trabajando como si formara parte del equipo del propio cliente.

En estos casos, llega a perderse el control de lo que se trabaja. El equipo de mantenimiento está muy ocupado, pero sus responsables no son conscientes de ello. Se registran menos incidencias de las que realmente se resuelven...incluso de llevan a cabo evolutivos a escondidas que con suerte se quedan como simples correctivos.

¿Y tú? ¿Has observado también en algún proyecto el Síndrome de Estocolomo?

viernes, 15 de marzo de 2013

De novato a experto en 10 minutos. Manual de gurupollas.

Esto es una guía de cómo actuar como un auténtico gurupollas, y está inspirada, antes de continuar, en el enlace: "De profesión experto. Manual exprés." A los que lean el artículo original, les aviso de que como siempre, aquí hay buena parte de mi cosecha. Vamos allá.

1. Escoja un tema difícil de verificar.

Si no lo puede crear, únase al último de moda. Asegúrese de que sea algo novedoso y poco conocido, de forma que nadie pueda rebatir sus escasos o inexistentes conocimientos. Cuanta más prisa se de en aparecer como referente en ese tema, más fácil será que sus círculos acaben asumiendo que usted efectivamente forma parte de esa nueva corriente de pensamiento.


2. Invente un concepto y nómbrelo en no más de tres palabras.

Una de ellas debe ser un sustantivo sonoro y contundente de no más de cuatro sílabas. Algo así como burbuja o mariposa. No trate nunca de explicarlo. Ya tratarán los demás de darle sentido. Piense en títulos de libros o películas para inspirarse.


3. Abra un blog y escriba a diario contenidos inspirados, agudos e ingeniosos sobre la materia.

Abuse de términos como sinergias, implementar y proactivo. Trate de incluir espasmódica y sistemáticamente referencias a algún libro famoso del término nuevo. O mejor: diga que participó como co-autor de dicho libro y que está en disputas legales con el autor reclamando sus derechos.


4. Tuittee intensivamente y solicite sin pudor que le retuitteen.

Cree hashtags como si no hubiera un mañana (pero nunca diga "como si no hubiera un mañana"). Retuitee cualquier twit en el que se hable del tema en que quiere venderse como experto. Se trata de que por cansancio, le acaben relacionando con ese tema.

5. Haga circular información sobre su omnipresencia digital.

Cuente a todo Dios las veces que ha sido retuitteado.  Exagere detalles y circunstancias del hecho. Siempre alguien se lo creerá. Hable de los muchos blog que escribe, libros, participación en revistas, foros, etc. Tiene que parecer que de cada 10 palabras que se escriben en internet, usted ha escrito al menos 3... y al menos otras 6 están inspiradas en las suyas.

6. Escriba un libro.

En breve será considerado  "la biblia de …" y usted "el gurú de …". Esto enlaza con una de mis últimas entradas sobre los gurupollas. Siempre puede pagar a otro para que escriba el libro...o tomar uno existente y afirmar directamente que ¡usted lo pensó primero! Deje caer en los medios sociales que va a tomar medidas legales y represalias contra el autor del libro por robar su idea. Por supuesto, no haga nada de esto en realidad.

7. Hágase con un buen enemigo. Alguien famoso e intelectualmente disfuncional que ponga en duda su teoría.

No le tema, él lo necesita más a usted. Difunda las opiniones contrarias. No hay corriente sin contracorriente. Es la llamada "dicotomía gurupóllica" (ok, me lo acabo de inventar): es cuando dos gurupollas, cada uno se inventa un término opuesto y lo defiende. En lugar de contradecirse, acaban apoyándose y logrando crear dos escuelas de pensamiento opuestas.

8. Adquiera la última versión del Ipad o IPhoney póngalo en cualquier superficie visible durante sus charlas.

Representa solvencia técnica, intelectual y económica. Vincule toda opinión humana o divina al espíritu de Silicon Valley. Si puede, lleve además otros dos o tres móviles de alta gama para apoyar que usted está metido en tantos proyectos que es capaz de necesitarlos.

9. Contrate por un módico precio a un experto anglosajón que le cite con frecuencia … en Inglés.

Mejor aún: pague a alguien en Linkedin para que haga comentarios positivos y exagerados sobre sus cualidades y participación en los proyectos. Asegúrese mencionar que en sus proyectos ha tenido alrededor de 4 o 5 veces más gente a su cargo que en la realidad. Si ha estado en algún proyecto de pasada, diga que usted fue el arquitecto y principal responsable, con todo el resto de gente a su cargo. Difícilmente nadie se lo va a contradecir, y sin embargo impresionará a mucha más gente. Además tiene que parecer que usted escribe inglés con naturalidad. De hecho, debe quedar patente que los principales diccionarios en inglés le piden a usted que los revise y los valide. Usted no es responsable de anglicismos en el castellano, sino de castellanizar la lengua de Shakespeare.

Si te ha gustado, puedes seguir con el artículo original, algo distinto, pero con muchos más pasos para convertirte de novato a experto. Enhorabuena a su autor.

Conforme lo escribía, me asustaba porque me encontraba a mí mismo tentado de usar varios de ellos en  alguna que otra ocasión. En fin. Ya se sabe que el lado oscuro poderoso es.

viernes, 7 de septiembre de 2012

Darth Vader: el mejor Jefe de Proyecto

Programador, tu falta de fe en Scrum me resulta molesta
Esta entrada está inspirada en otra bastante antigua, y que nombro al final. Recientemente, he visto otro blog en el que salía  el tema, y me ha parecido gracioso, interesante...y espeluznantemente real. Veamos porqué repasando los 10 motivos principales:

Número 10: Darth Vader prioriza de la forma más brutal.

Cuántas veces vemos a los jefes de proyecto priorizar de forma que si bien nos acerca al éxito, también supone un brutal esfuerzo y sacrificio por parte de todos...incluido (aunque no siempre) el propio jefe de proyecto.

Número 9: Vader toma decisiones basadas en datos objetivos, no rumores.

Un jefe de proyecto como Vader no se preocupa de lo que dicen, él prefiere verlo por él mismo. No escucha, y su liderazgo se basa en la escasa confianza en su equipo.

Número 8: Vader adquiere compromisos, y trabaja duro para cumplirlos.

Así es, el problema es que muchas veces obliga a trabajar a todo el mundo para que los compromisos que ha adquirido, se cumplan. Por desgracia, no todo el mundo sabe tomar la medida de los compromisos que toma...y se mete en más de lo que puede abarcar (en realidad, en más de lo que SU EQUIPO es capaz de abarcar).

Número 7: Vader, cuando es necesario, se aleja para recuperar la perspectiva y descansar.

Ocurrió en las películas, y ocurre en tu proyecto. Tranquilo, si en el momento más crítico, no le ves el pelo a tu jefe de proyecto...es que está "recuperando la perspectiva".

Número 6: Vader gestiona riesgos y expectativas...¡de forma preventiva!

También vimos en la saga galáctica a Vader gestionando riesgos preventivamente. Los buenos jefes de proyecto piensan en sus proyectos a la defensiva, pero los protegen de forma agresiva.

Número 5: Es un tío persuasivo.

Darth Vader lo es. Para eso tiene el poder de la fuerza. Y muy mal genio. Esto también lo comparten muchos jefes de proyecto, que confunden la persuasión con la agresión, la amenaza y la extorsión.

Número 4: Vader elige una metodología, y se mantiene con ella...hasta que no funciona.

Esto es también un perfil de un buen gestor, ser consecuente con las decisiones tomadas, y cuando los métodos no sirven, reevaluar la situación y modificar la estrategia para afrontarlo de forma distinta, cambiando toda la metodología si es necesario. Eso sí, quedaos lejos porque alguien ha de tener la culpa de sus decisiones.

Número 3: Para Vader, no hay problema grande que no pueda enfrentar.

Bueno, y así ocurre con muchos jefes de proyecto. Que abordan problemas y proponen soluciones que dejan perplejos a sus equipos.

Número 2: Nunca es demasiado tarde para hacer lo correcto.

Igual que Darth Vader, que se arrepintió en el último momento, un jefe de proyecto puede decidir en el último instante cambiar y evitar el desastre total tomando la decisión correcta (a veces, precisamente la decisión que su equipo lleva todo el maldito proyecto diciéndole que tome). Por suerte, este cambio del jefe de proyecto en la estrategia, salvará el proyecto y le dará todo el mérito y la gloria.

Número 1: Vader nunca tiene miedo de ensuciarse las manos.


Y tampoco lo tienen muchos jefes de proyecto. Algunos, se las manchan picando código, o rellenando documentos de todo tipo para aliviar a su equipo. Otros, se las manchan de otra forma: culpando a quien no se puede defender, o alejando del proyecto a los que pueden hacerle quedar mal. Después de todo...¿para qué buscar soluciones si pueden encontrar culpables?

Y nada más. Bueno, creo que mis comentarios se han desviado bastante del artículo original, así que podéis leer los dos enlaces que os copio sin que se os repitan mucho los conceptos.

Fuentes:
http://www.geekwire.com/2011/top-10-reasons-darth-vader-amazing-project-manager/
http://www.genbetadev.com/trabajar-como-desarrollador/darth-vader-el-jefe-de-proyecto-definitivo

lunes, 4 de junio de 2012

Comando Scrum



Me ha gustado. Un compañero me ha facilitado el link que voy a comentar, y donde vais a poder disfrutar con todo detalle del contenido, que me parece brillante. Aquí va un resumen:

El sargento

Esta figura la podemos asimilar al Scrum Manager, el responsable de mantener al equipo enfocado y motivado, de forma que los grupos de desarrollo actúen como unidades eficientes. Luchará encarnizadamente por eliminar cualquier impedimento u obstáculo a este fin.

Comunicaciones

El product owner, realiza esta función de mantener al equipo bien informado de los requisitos del producto, y asegura que la información fluya bidireccionalmente.

Infantería

En Scrum representado por el equipo de desarrollo. Sin estos tíos, no existiría el ejército, ni sería posible ninguna batalla. Representan la fuerza necesaria, que hay que cuidar y mantener, entrenar y no agotar nunca.

Médicos

Los especialistas en aseguramiento de calidad (QA), son responsables de saltar las alarmas cuando la salud del proyecto no es la adecuada. Verifican el cumplimiento de estándares, y dan soporte en su consecución.

Reconocimiento

En todo proyecto suele haber una parte del equipo que realiza un prototipo, o que investiga una tecnología para identificar si es plausible o no implantarla en el proyecto. Estos investigadores (equipo de reconocimiento), hacen las labores de preparar el camino al resto, y de identificar problemas. En todo proyecto hay "zonas minadas" que hay que evitar, y que esta avanzadilla de héroes nos ayuda a anticipar.

¡ El día de la victoria!

Este día, es el día del despliegue. El pase a producción habrá sido más o menos complicado, pero con las dosis adecuadas de esfuerzo, planificación, gestión y suerte, la victoria habrá llegado. Es el momento de celebración, liberar a los rehenes, y pasar a la reconstrucción del país...quiero decir...al mantenimiento del producto.

domingo, 4 de marzo de 2012

Excusitis: otra enfermedad del desarrollo de software

Igual que existe la profesión más antigua del mundo, hoy hablamos de una de las más antiguas enfermedades en el desarrollo de software: la excusitis.

Parece que tenemos excusas para todo. Somos ingenieros. Tenemos la más alta formación, sin embargo, las más estúpidas excusas parecen salir una y otra vez de nuestras bocas de forma habitual. ¿Cuál es el problema? Como siempre, la causa más probable es el error humano.

Hay gente, que consigue prosperar a base de dos máximas:
  • Si algo sale bien, les falta tiempo para dar la cara para conseguir reconocimiento y fama.
  • Si algo sale mal, echan mano de la lista de culpables (que siempre tienen a mano), para conseguir su chivo expiatorio. De hecho, a veces consiguen incluso culparlos en la distancia (frases del estilo "yo no he trabajado con él, pero...<poner aquí cualquier frase que desprestigie al chivo expiatorio>")
Como ya comentaba en mi anterior artículo "¿Por qué fallan los despliegues en producción?", no debemos buscar los culpables muy lejos. Sin embargo, resulta mucho más fácil buscar culpables, que soluciones. Y las soluciones, están siempre en el mismo sitio: formación, buenas prácticas, usar tecnologías y métodos seguros y probados, y ser sobre todo, profesionales.

Veamos las excusas más habituales:
  1. Reinicia, y si sigue pasando..vuelve a llamarme
  2. El análisis funcional estaba mal
  3. Es que alguien no está a la altura del resto y está haciendo que mi equipo no rinda bien.
  4. Pero...¿y eso para qué lo quieres?
  5. Ya se que no lo pidió nadie...¿pero te gusta?
  6. Funciona...pero no lo he probado
  7. ESTO...no puede ser la causa de ESO.
  8. Es solo una desafortunada coincidencia
  9. Pero si ese módulo no se ha tocado en meses!
  10. Es que ese módulo está sin terminar
  11. Esto siempre ha funcionado bien...
  12. Yo no he tocado nada...
  13. En mi equipo sí que funciona...
  14. Pero si yo ya lo probé!
  15. Pero si esto pasó todas mis pruebas unitarias!
  16. Estás usando la última versión?
  17. Este no es mi último código...¡alguien lo cambió!
  18. Nunca había visto este error antes...
  19. Ese no es mi código!
  20. Creo que esto nunca había funcionado antes...
  21. Creo que todavía no se han hecho los cambios en la base de datos.
  22. Pero...¿eso estaba incluido en el diseño funcional?
  23. Nadie me lo dijo.
  24. Pero...¿no estarás usando el Internet Explorer?
  25. No es un fallo...¡es una característica!
  26. Seguramente hiciste algo mal para que fallase así.
  27. Nadie me dijo que debía hacer pruebas unitarias.
  28. Eso no estaba en mi plan de pruebas
  29. Ayer funcionaba
  30. ¡Ya os dije que no me iba a dar tiempo de probarlo!
Fuente: http://whizzodev.blogspot.com/2008/02/top-13-excuses-for-software-developer.html

jueves, 23 de febrero de 2012

Cuando la culpa es del usuario

Muy bueno. Estoy leyendo un  artículo en variablenotfound, donde el autor presenta varias situaciones históricas en que puesto que los programadores han asumido que la culpa de los fallos es del usuario, se vengan de él de alguna forma:
  1. ID-10-T: es una forma de llamar al usuario IDIOTA (del inglés IDIOT, resultado de concatenar los caracteres el código de error "ID-10-T")
  2. PEBCAK: Problem Exists Between Chair And Keyboard
  3. PICNIC: Problem In Chair, Not In Computer
  4. Layer 8 Error: en el año 1984, la organización ISO publicó el Open Standard Interconnection, donde se hablaba de 7 capas del software. La 8ª capa, como imaginaréis, corresponde al usuario.
  5. RTFM: Read The  Fucking Manual
  6. Luser: término despectivo para usuarios poco (o nada) técnicos, y que deriva de la fusión entre USER (usuario) y LOSER (perdedor). Tiene su origen en una broma en el MIT nada menos que en 1975.

Al final, vemos que los programadores, hemos dedicado desde siempre una gran parte de su esfuerzo en criticar y ridiculizar a los usuarios. Vamos, que no os vayáis a creer que es algo de ahora. A todos nos molesta que los usuarios nos hagan consultas estúpidas. Como el tono del artículo original es de humor, dejo para más adelante otro artículo para criticar este tipo de posturas. Porque sí, el usuario tiene derecho a no compartir nuestra visión de la tecnología, y sí: el usuario tiene derecho a cometer errores. No se trata de que nos dobleguemos y aceptemos que cualquier cosa que diga el usuario es Ley. Se trata de que aceptemos que el cliente puede tener una visión diferente de la nuestra, o incluso equivocarse, y debemos:
  • Localizar la causa de la discrepancia.
  • Analizar y entender la postura del usuario
  • Aprovechar ese conocimiento para reenfocar nuestro servicio en un mayor beneficio mutuo

miércoles, 22 de febrero de 2012

Frases célebres sobre la calidad

A continuación, algunas frases célebres sobre la calidad:

  • "¡No me importa si funciona en tu máquina! ¡No estamos vendiendo tu máquina!" (Vidiu Platon)
  • "Programar es como el sexo: un único error y tienes que estar soportándolo toda la vida" (Michael Sinz)
  • "Hay dos formas de escribir programas sin errores; sólo la tercera funciona" (Alan J. Perlis)
  • "Puedes tener un software de calidad o puedes tener aritmética de punteros, pero no puedes tener ambas cosas al mismo tiempo" (Bertrand Meyer)
  • "Si McDonnalds funcionara como una compañía de software, uno de cada cien Big Macs te envenenarían, y la respuesta sería 'lo sentimos, aquí tiene un cupón para dos más'" (Mark Minasi)
  • "Codifica siempre como si la persona que finalmente mantendrá tu código fuera un psicópata violento que sabe dónde vives" (Martin Golding)
  • "Cometer errores es humano, pero para estropear realmente las cosas necesitas un ordenador" (Paul Ehrlich)
  • "Un ordenador te permite cometer más errores y más rápido que cualquier otra invención en la historia de la humanidad, con las posibles excepciones de las pistolas y el tequila" (Mitch Radcliffe)
Están extraídas de este blog de José M. Aguilar. Si os han gustado, en su blog hay muchas frases.

martes, 21 de febrero de 2012

La carga de trabajo

Este artículo está inspirado en un nuevo plugin que ha salido para JIRA, y que podéis ver en detalle en este link.

Lo interesante del tema, está en la imagen con que se muestran los distintos niveles de carga de trabajo:


Es decir, de lo que se trata es de repartir la carga de trabajo, para mantener a los dos primeros iconos ocupados (por su expresión, parece que se están durmiendo), mientras que a los dos últimos...pues eso, con verlos ya se ve que están algo agobiados y conviene quitarles faena. Esto de repartir la carga, tiene poco que ver con socializar el trabajo y conseguir el equilibrio, y mucho con el proceso ITIL de "Capacity Management".

Una reflexión interesante sobre la carga de trabajo, la podemos encontrar en este link, donde se establece la ecuación:
Productividad = Motivación - Procrastinación - Carga de Trabajo

domingo, 11 de diciembre de 2011

Chistes de Testers

Os traigo unos chistes que me han parecido buenísimos, y que están relacionados con el mundo del testing. Los que hayáis trabajado en testing, espero que os guste. Los que no...no os vendría mal dedicar algo más de tiempo a probar vuestros propios productos! . Fuente: Link.

Optimistic Developer: The glass is half full
Pessimistic Tester: The glass is twice as big as required

Optimistic Developer: This code hasn’t yet been tested. It’s not known if it has any bugs.
Pessimistic Tester: This code hasn’t yet been tested. It’s not known if it works.

Optimistic Developer: We are 90% done.
Pessimistic Tester: We don’t know when we’ll be done, if ever

Optimistic Developer: We will refactor the code to make it better
Pessimistic Tester: They are throwing out the working code and replacing it with an unknown quantity

Optimistic Developer: I only changed one line of code
Pessimistic Tester: The entire system must be retested

Optimistic Developer: The code is the design
Pessimistic Tester: There is no design

Optimistic Developer: We’ll fix those bugs later, when we have time
Pessimistic Tester: We never have enough time to fix the bugs

Optimistic Developer: This build is feature complete
Pessimistic Tester: The features exist; some are completely broken

Optimistic Developer: Anything is possible, given enough time
Pessimistic Tester: Everything has flaws, and given enough time I can prove it

Optimistic Developer: Of course it will work
Pessimistic Tester: It might work, but probably won’t

Optimistic Developer: One last bug fix, and we can ship tomorrow
Pessimistic Tester: Fixing this one bug will likely lead to two more

Optimistic Developer: Stop finding bugs, or we’ll never be done
Pessimistic Tester: Stop creating bugs, so I can find them all

Optimistic Developer: There’s no need for more tests
Pessimistic Tester: Let’s just run a few more tests to be sure

Optimistic Developer: There is no I in TEAM
Pessimistic Tester: We can’t spell BUGS without U

Optimistic Developer: That’s an “undocumented feature”
Pessimistic Tester: That’s a bug

Optimistic Developer: I like to build things
Pessimistic Tester: I like to break things

Optimistic Developer: Sure, we can use the Beta version of this component in Production
Pessimistic Tester: We should wait until version 2.1

sábado, 12 de noviembre de 2011

Personal Brand Online

Como respuesta a toda la fiebre de estar conectados y crear una "marca personal" online, Dilbert ataca de nuevo como sólo él puede hacerlo. Nuestra tira cómica favorita se sigue superando. Podéis seguirla como siempre en www.Dilbert.com



Hay otro problema que vengo observando recientemente, y es que en la práctica, hoy en día hay mucho más interés en aparentar, y tener una "marca personal", que realmente realizar ningún tipo de aporte. Es por eso que encontramos tantos blogs, twitters y facebooks repetitivos y amiguismos por doquier.

viernes, 14 de octubre de 2011

Así no se puede trabajar

Esto no es serio. Así no se puede trabajar. Hoy traigo un mensaje (cuadro de diálogo) de Microsoft Powerpoint, que me ha hecho desear asesinar a alguien. Esto no está sacado de ningún sitio web, ni na. Lo he sufrido en mis carnes. Aún sigo sin saber el motivo ni la información perdida. El mensaje es:


Para los que no estéis puestos en inglés, os traduzco lo que pone tal y como lo he sentido:
  • Powerpoint ha encontrado contenido en este fichero, que no entiende.
  • Por tanto, Powerpoint ha decidido borrar este contenido, y no se puede recuperar. Ole, ole y ole tus...pues eso.
  • Te interesaría revisar esta presentación POR SI ACASO detectas algo cambiado o borrado
Pero si no es mía la presentación! Pero qué narices me está contando! Pero cómo voy a saber si algo falta o no! Y ni siquiera puedo contactar con su autor!!!!!

Queridos desarrolladores de Microsoft Powerpoint: GRACIAS. Gracias por hacerme sentir idiota. Gracias por dejarme alucinado con mensajes tan retorcidamente creativos.
En fin, que así no se puede trabajar.

jueves, 13 de octubre de 2011

Chuck Norris Exception

He encontrado en este link esta pequeña perla (aunque me suena, quizás sea vieja):


Instalación

$ npm install ChuckNorrisException

Uso

var ChuckNorrisException = require('ChuckNorrisException');

var imFeelingLucky = true;
try {
  if (imFeelingLucky) throw new ChuckNorrisException();
} catch (e) {
  // FAIL: You cannot catch a ChuckNorrisException
}

Si intenta lanzar una ChuckNorrisException resultará en un fallo y se cerrará su programa.
¿El motivo? Porque usted no lanza a Chuck Norris....Chuck Norris le lanza a Usted!!!
Los siguientes errores se producirán si se intenta tamaña estupidez.

  • Usted no lanza a Chuck Norris....Chuck Norris le lanza a Usted!!!
  • Chuck Norris escribió "Hola Mundo" una vez...y se llamó Unix.
  • Chuck Norris le pateará el culo asíncronamente
Original: http://criso.github.com/ChuckNorrisException/

martes, 4 de octubre de 2011

Gestión de equipos: la teoría del caballo muerto

Hoy, a falta de algo más elaborado, tengo que echar mano de otro guiño de humor.

Para los que trabajáis en este mundillo del desarrollo de software, os arrancará algunaque otra sonrisa. Para los gestores de equipos y de proyectos que no lo hayáis entendido...manteneos alejados de mí.

Por cierto, haciendo clic en la imagen la veréis "en grande", ¿ok? pues ale.. a disfrutar

lunes, 3 de octubre de 2011

El gerente del turno de noche

A continuación, adjunto una imagen, que vale por cien palabras. Yo suelo decir una frase sobre los malos gestores y jefes de proyecto que reza que "mantienen los recursos lejos de los objetivos".

Vendría a ser similar esta iniciativa, en la que nuestro gerente favorito se encarga de poner los medios más inadecuados para las necesidades del proyecto.

Que aproveche.

lunes, 19 de septiembre de 2011

La importancia del análisis

Un análisis (funcional o técnico), es un punto importante, en el que el analista de turno "se moja" y decide implementar los requisitos de una forma implementable. El problema, como se ejemplifica a la perfección en la imagen siguiente, es que hay que tener antes la experiencia suficiente para (entre otras cosas), saber identificar si hay componentes o incluso sistemas enteros que implementan nuestra misma solución.



Fuente: http://www.nosololinux.com/2009/03/27/la-nosolotira-grandes-ideas/