domingo, 5 de julio de 2009

Confusión en el tren.

Un joven programador y su Project Manager abordan un tren que atraviesa una zona montañosa, pero lamentablemente la locomotora había hecho una parada anterior y casi no encuentran lugar donde sentarse a excepción de dos puestos justamente al frente de una mujer joven que viajaba con su abuelita. Después de estar un rato sentados, tanto la mujer como el joven programador empiezan a intercambiar miradas, pero este juego se acaba cuando el tren pasa por un túnel que deja el interior del ferrocarril absolutamente oscuro.

En ese momento se oye un sonido de un beso seguido por otro de una cachetada.

Apenas el tren abandona el túnel los cuatro se quedan como si nada y nadie dice ninguna palabra, sólo se quedan pensando:

La abuela piensa: “Ese joven fue muy descarado al besar a mi nieta, pero me contenta que ella se haya desquitado con esa cachetada”.

El Project Manager piensa: “No sabía que mi programador fuera lo suficientemente valiente como para besar a esta chica, pero que malo que falló su golpe y terminó pegándome a mí”.

La joven mujer piensa: “En realidad sí me gustó mucho el beso de este tipo, ojalá mi abuela no le hubiera pegado”.

El joven programador quien está sentado con una enorme y envidiable sonrisa de satisfacción piensa: “La vida es buena. ¿Qué tan seguido una persona como yo tiene la oportunidad de besar a una hermosa mujer y a la vez darle una cachetada a su Project Manager al mismo tiempo?”.

Leído en LíderDeProyecto.com.

sábado, 4 de julio de 2009

El tiempo también pasa para los superhéroes.

Donald Soffritti se ha puesto a imaginar y dibujar (con maestría, por lo menos para mi gusto) la decadencia madurez de los superhéroes de ayer y hoy y las ha ido publicando junto con otros materiales en su blog (son las entradas tituladas “Decadence”).

Llegué a él vía @Cerebrado, que vio en Izismile.com una recopilación de las 27 imágenes publicadas hasta ahora.

superheroes_19 superheroes_02 superheroes_08

viernes, 3 de julio de 2009

Top 100 de las frases cortas más graciosas en internet.

smilyA continuación algunas de las que más me gustaron, pero están todas muy buenas (se pueden votar):

- War does not determine who is right - only who is left.

- A clear conscience is usually the sign of a bad memory.

- Artificial intelligence is no match for natural stupidity.

- I want to die peacefully in my sleep, like my grandfather.. Not screaming and yelling like the passengers in his car.

- A bus station is where a bus stops. A train station is where a train stops. On my desk, I have a work station..

- I like work. It fascinates me. I sit and look at it for hours.

- Did you know that dolphins are so smart that within a few weeks of captivity, they can train people to stand on the very edge of the pool and throw them fish?

- Going to church doesn't make you a Christian any more than standing in a garage makes you a car.

- It's not the fall that kills you; it's the sudden stop at the end.

- My opinions may have changed, but not the fact that I am right.

- My psychiatrist told me I was crazy and I said I want a second opinion. He said okay, you're ugly too.

- You do not need a parachute to skydive. You only need a parachute to skydive twice.

- Why do Americans choose from just two people to run for president and 50 for Miss America?

El resto en OnelinerZdotNET (gracias @Cerebrado).

jueves, 2 de julio de 2009

Gatitos manchados.

white-kitten white-tiger Black_Panther_on_mud_hill

¿Lindo el gatito, no? Sí… es adorable, tan inofensivo. Es increíble que sea tan parecido a un tigre, apenas le faltan un par de manchas y un poco de tiempo para crecer. El tigre, más que lindo, diría que es imponente. Es un animal enorme… y sí, claro tiene algunas manchas… pero no hacen más que resaltar su majestuosidad. Por otro lado, la pantera, sin perder belleza y majestuosidad, transmite por sobre todas las cosas… peligro. También es blanca, pero tiene muchas manchas negras.

Qué bueno sería poder sacar y poner manchas a voluntad. Imaginemos por un segundo que es sólo cuestión de estirar la mano y acomodar o retirar suavemente un par para transformar a uno en otro. El problema, me imagino, es que cualquiera se acerca al gatito, y supongo que algunos no tendrían problemas para arrancarle algunas manchas de la cola al tigre… ¿pero quién le saca las manchas a la pantera?

Cambios de contexto.

¿Qué pasaría si sacásemos de contexto algunas de esas situaciones tan comunes entre clientes y vendedores (y ni hablar dentro de lo que es el desarrollo de software) y las ubicásemos en otros más… cotidianos, digamos?

La gente de Scofield Editorial estuvo jugando con esa idea y el resultado es este video que me sigue haciendo reír después de incontables repeticiones.

Visto en {codesqueeze}.

PD: al cocinero grandote y con cara de pocos amigos lo quiero en mi equipo.

Del desarrollo de software como proceso industrial.

tm A aquellos que siguen pensando el desarrollo de software como un proceso industrial les diría que puede ser, sí… siempre y cuando consideren a los programadores como la máquina que produce y a los managers como el operario que la conduce. Es verdad que hay mejores y peores máquinas y operarios y que la velocidad de producción depende en buena medida de la habilidad de éstos últimos… pero el producto, la calidad… y la magia… está en la la máquina.

Sólo quería decir eso.

miércoles, 1 de julio de 2009

Sistemas administrativos, software y poder.

forcejeo_poder El poder juega un papel central en la conformación de un sistema administrativo. Yendo un poco más lejos, estoy bastante convencido de que el sistema administrativo mismo no es más que el reflejo de la distribución del poder en la organización en un momento dado. Las modificaciones en la estructura o en la ubicación de las personas que la integran son en realidad fluctuaciones en la distribución del poder subyacente en la organización, y no al revés.

Es un buen momento para aclarar que hablo de sistemas administrativos y distribuciones de poder reales. Todos sabemos que los elementos formales (el organigrama, los manuales, las normas, el software de soporte) no siempre reflejan (rara vez reflejan, en realidad) el sistema administrativo real de una organización. Se dan casos extremos (y los he visto) en donde incluso las declaraciones de los integrantes de la organización sobre “cómo se hacen aquí las cosas” tampoco tiene mucho que ver con cómo se hacen realmente.

Los que participamos en el desarrollo de sistemas informáticos de gestión (software aburrido, bah) lo sabemos mejor que nadie, ya que el software que construimos pretende ser un soporte a ese sistema administrativo o  incluso el reflejo total de éste, en los casos más ambiciosos. Así que el proceso de desarrollo es extremadamente sensible a estas fluctuaciones que son, recordémoslo, fluctuaciones en la distribución de poder de la organización para la cual trabajamos. Los proyectos se paquequean, una y otra vez, se cancelan, se aplazan, se retrasan, se abandonan.

El problema radica en que el software es un elemento mucho más rígido, mucho menos maleable una vez establecido que el sistema administrativo al que pretende soportar o reflejar. Esta rigidez es un arma que utilizarán o contra la que lucharán los diferentes actores en pos de acumular poder o mantener el que han obtenido. En efecto, una vez plasmados en código determinados circuitos de información, autorización y sectores de discrecionalidad éstos se vuelven mucho más difíciles de modificar.

Así, tenemos al que ocupa una posición dominante dentro de la estructura de su organización, que desea que “todo siga igual, pero informatizado” y que en realidad ve al proyecto con cierta desconfianza y prefiere seguirlo de cerca y con mano de hierro. Otro que, percibiendo la implantación como una oportunidad, desea “establecer un sistema más racional en la distribución de las actividades” y lucha por introducir modificaciones (sabemos que la racionalidad poco y nada tiene que ver con esa distribución, aunque una racionalidad aparente ayuda a apoyarla). Y también tenemos al que, viendo el proyecto como una amenaza declarada, pone palos en la rueda retaceando tiempo, recursos e información.

resistencia_al_cambio A los usuarios finales, generalmente fuera del círculo de decisiones formales respecto del software, les queda la chance de evaluar su posición final dentro del circuito propuesto y apoyar o rebelarse según el resultado de esa evaluación. Se les llamará entusiastas y dinámicos a unos, estáticos o reacios al cambio a otros, o arribistas e imprudentes a unos y expertos a otros, según el lugar que ocupe el interlocutor, favorecido o amenazado por los cambios.

Pero cuidado porque, ya lo dijimos arriba, las estructuras formales poco y nada tienen que ver con las reales. Detrás de los puestos más insignificantes se esconden armas poderosas… puede ser que la empleada que ve su posición amenazada por el nuevo sistema comente al gerente general durante el viaje en que éste la acerca a su casa (en el mejor de los casos), una y otra vez, lo poco conocedores de la empresa que son los analistas del proveedor, y cómo el gerente de tal está influenciando las decisiones a su favor para quedar mejor ante los dueños.

Vemos que la “resistencia al cambio” puede ser feroz y provenir de los lugares más inesperados. Tal vez lo más difícil para el proveedor, pobre pajarito en este nido de serpientes, sea determinar de qué lado debe ubicarse, es decir, a quién escuchar y a quién no. Pero para complicar más la situación, el “pobre pajarito” puede que no lo sea tanto, que existan conexiones fuertes entre actores por fuera de las estructuras y no siempre entre los más altos representantes de ambos. Podría ser el analista funcional el que lleve a la secretaria a su casa escuchando la cantinela sobre la inutilidad del puesto de su jefe (el de la secretaria… o el del analista).

Si las estructuras de poder reales se pareciesen a los organigramas y los circuitos administrativos reales a los cursogramas programar sistemas de gestión sería juego de niños y las metodologías ágiles una verdadera pérdida de tiempo. Pero nada de eso es así, y por eso la agilidad en el proceso de desarrollo es una herramienta imprescindible para satisfacer siempre los deseos de aquél al que le toque estar (hoy) arriba y seguir cobrando… por cierto, tal vez el que está hoy arriba prefiera un contrato más tradicional y un ciclo de vida clásico, ya que éste compromete más a la organización con el diseño inicial, que es el que él puede influenciar… la idea de que todo puede cambiar en cualquier momento no es tan agradable cuando se mira el mundo desde arriba.

Es ante todo por estas lindas y por demás mensurables y calculables cuestiones que los proyectos de software de gestión suelen transitar senderos tortuosos. Cuestiones que, dependiendo del papel que juguemos dentro del desarrollo, nos quitarán más o menos el sueño, pero estarán siempre presentes ya que son las que dan origen a aquello que modelamos: sistemas administrativos. Cuando diseñamos una base de datos o codificamos estamos representando, finalmente, relaciones de poder. ¿Lo habían notado?