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.

domingo, 10 de marzo de 2013

La gestión por falsa presión

Hola, tras el éxito del último post sobre los gurupollas, vamos a retomar la temática del desarrollo de software y la calidad.

Hoy el tema versa sobre la metodología de gestión basada en crear una falsa presión en el equipo. Hay varias formas de hacerlo. Repasaremos algunas, y creo que así me entenderéis mejor:

1. Falsa fecha de finalización.

Esta técnica, consiste en trasladar al equipo de desarrollo una falsa fecha de fin de proyecto. Es decir, si por ejemplo sabemos que el proyecto ha de estar entregado el 15 de Junio, podríamos decir al equipo que debemos entregar el 15 de Mayo. Con esto, conseguiremos trasladar una falsa presión, pedir más compromiso, bla bla bla.

¿Y qué ocurre si se llega con éxito a la falsa fecha? Pues tendríamos casi un mes para añadir funcionalidad o corregir errores y preparar documentación.

¿Y si no llegamos a la fecha de fin? Pues no hay problema, porque contaríamos con un mes de margen. Y siempre les podemos decir al equipo que somos nosotros, gracias a nuestra maravillosa gestión, quienes hemos conseguido un mes más de plazo.

Así matamos dos pájaros de un tiro: conseguimos que el equipo se esfuerce desde el minuto cero como si fuésemos retrasados antes de empezar. Y además, podremos defender que gracias a nuestra maravillosa gestión (¿qué gestión?), hemos conseguido un mes más de tiempo para que se pueda terminar con éxito.

En resumen: (a) esfuerzo desde el principio, y gratis. (b) Logramos quedar como los salvadores del proyecto gracias a nuestra gestión. (c) El cliente, consigue tener algo funcional y operativo mucho antes, y hay tiempo asegurado para cambios de última hora, documentación, etc. Eso sí, luego hablaremos del coste humano que tiene.

2. Falsa fecha de entrega parcial.

Este caso es una variante del anterior. Basta que le digamos al equipo que el cliente quiere tener una entrega funcional parcial de la solución final.

Si alguno de nuestros programadores conoce la fecha de fin de proyecto, será el truco que tendremos que usar, ya que no podremos mentirles con una "falsa fecha de finalización".

Los resultados son los mismos, pero por desgracia, los costes (más adelante hablaremos de ellos), también.

3. Funcionalidades falsas por exceso.

Hay ocasiones en que hay funcionalidades extras, que o bien interesan al jefe de proyecto, o bien estaban en el contrato como "extras" o "valor añadido".

También es posible que sean funcionalidades que detectemos que pueden venir bien de cara a la imagen del producto final, aunque realmente no estuvieran identificadas como requisitos.

Si en lugar de tratarlas como requisitos, nos limitamos a decir que son "obligatorias" y estaban "pactadas" desde el principio, tendremos una variante de los casos 1) y 2): logramos trasladar presión al equipo para empezar a esforzarnos al límite desde el principio pero no por una fecha falsa, sino por unas funcionalidades falsas.

4. Funcionalidades falsas por defecto.

Esta es una variante de la anterior (nº3), en la que el jefe de proyecto decide trasladar a su equipo sólo un subconjunto de los requisitos, pero normalmente se combina con las técnicas 1) y 2) para de nuevo, lograr una falsa presión en el desarrollo, y de esa forma, lograr con sobreesfuerzo y sacrificios lo que no somos capaces de hacer mediante nuestra capacidad de gestión.

¿Beneficios?

A continuación, veamos qué hemos logrado con todo esto:
  • Esfuerzo del 120% del equipo, desde el minuto 0
  • Trasladar un sentido de culpa al equipo de desarrollo, trasladándoles la culpa y la presión. Después de todo, el jefe de proyecto no es que no gestione porque no sepa, sino porque la falsa presión creada hay que justificarla también con una locura organizativa, falta de planes, calendarios y objetivos. Se trata de correr a toda costa para lograr los falsos objetivos parciales.
  • El jefe de proyecto consigue reconocimiento, pues es más fácil lograr el éxito, a costa del equipo y su salud.
  • El jefe de proyecto consigue quedar bien, pues aparenta que las nuevas fechas y funcionalidades son gracias a su gestión con el cliente y sus enérgicas habilidades negociadoras, y no por haber ocultado y tergiversado los objetivos en fechas y funcionalidades.
  • El cliente observa avance, esfuerzo y tiene una falsa percepción de compromiso.

Costes de esta mala praxis

¿Y esto sale gratis? ¿Tiene alguna consecuencia?
Pues claro. Veamos algunos de los costes derivados:
  • El equipo se quema muy pronto. Es fácil perder empleados que se van a otras empresas, bajas por depresión o enfermedad, etc.
  • El producto conseguido necesita corregirse, bien en el tiempo "extra" conseguido, o bien en una fase de mantenimiento. El producto suele funcionar más o menos, pero suele ser insostenible, del tipo "mírame pero no me toques". La calidad se ve penalizada, y creedme que lo lamentará el pobre mortal que se atreva a mantener este inmundo código.
  • El esfuerzo necesario para hacer la aplicación es mucho mayor, ya que la falta de documentación y la tensión necesaria lograr los falsos objetivos hacen que luego haya que retocar todo para que realmente funcione.
¿Te ha pasado alguna vez algo parecido? ¿Has observado en tus proyectos o en proyectos de conocidos alguna de éstas técnicas y/o sus consecuencias?