Fauna actual: El gurupollas

Mezcla de gurú y de gilipollas, ha habido ya algún artículo al respecto: recientemente Alejandro Suárez Sánchez-Ocaña, hablaba de este nuevo vocablo como nuevo término que se refiere a los "gurús" del social media. Sí, estos tipejos que buscan su minuto de gloria sin objetivos concretos, o a veces sin más objetivos que sacar cualquier beneficio personal, rápido y sin rubor a base de atribuirse actitudes postulantes, evangelizadoras sobre los términos de moda.

Nada más apropiado para ser un auténtico gurupollas que subirse sin el adecuado sentido crítico en alguno de los trenes mediáticos actuales:

• La nube
• TDD, DDD...
• Metodologías ágiles
• Web 2.0, marketing 2.0,..."loquesea" 2.0
• Uso de patrones ("Patronitis")
• etc.

En este sentido, el gurupollas entrará en los grupos sociales relacionados, o escribirá en su blog, o incluso escribirá un libro en el que aparecerá como el apadrinador y gurú de estos trenes mediáticos. Y todo esto sin sentido crítico. Aquí como suelo decir: si estáis a favor de algo, yo prefiero empezar negándolo, o poniéndolo en duda. Es esta dialéctica de búsqueda de la verdad la que realmente aporta algo positivo, no dar la razón como a los tontos para conseguir "+1" en la red social de turno.

El colmo de la cuestión viene cuando estos individuos se auto-atribuyen términos que son de otros, éxitos ajenos, como si su paso por los proyectos o las empresas hubieran esparcido la semilla del éxito y la guru-calidad.

Alejandro en su artículo insiste en lo del "minuto de gloria". Yo más que eso, entiendo que se trata de algo más. Cuando no hay fondo, cuando no hay empaque, se trata de destacar de alguna manera. Cuántos nos hemos encontrado en las empresas con este tipo de actitud:

• "Yo soy power" (vale, ¿y?)
• "Yo soy el arquitecto de la solución" (o sea, que no has pegado palo al agua, no?)
• "He recibido un excelente reconocimiento"

Lo siento, pero soy de la opinión de que antes de intentar que hablen bien de ti, el mejor primer paso es que no hablen mal de ti. La coherencia, rectitud y un criterio claro y sostenible son la mejor carta de presentación. Además, los éxitos se miden y deben contar por el valor aportado: al cliente, a la propia empresa, a los compañeros...y no por el reconocimiento o la subida de sueldo o categoría recibida.

Las estrellas de un día, sin embargo, cada vez no sólo tienen su momento, sino que con esa exhibición de gurupolleces, consigue ganarse algún que otro adepto. Y ahí es cuando el gurupollas, con sus acólitos, es realmente peligroso. Porque ya no tiene que esconder su incapacidad: ya tiene otros que a base de su sudor, y a cambio de alguna falsa promesa de reconocimiento futuro, consiguen sacar el trabajo que el gurupollas no ha podido. Es cuando se forma la "manada del gurupollas".

Alejandro Suárez hace especial mención a los gurupollas de las redes sociales. Pues bien, yo quiero reclamar que también hay gurupollas fuera de las redes. En cualquier departamento. Es una especie que lejos de estar en peligro, aflora en cualquier parte.

Ojo, el gurupollas más peligroso, no sólo es el que trata de estar siempre en el candelero. El peor es el que sabe ocultarse cuando no puede brillar:

• Cuando hay trabajo y puede llegar a notarse su inutilidad.
• Cuando hay cerca un acólito que puede currar por él (siempre que no haya posibilidad inminente de echarse una medalla)
• Cuando haya cualquier riesgo o problema en curso.

De hecho, este último punto merecería todo un artículo exclusivo dedicado a él:

• Gestión de riesgos para gurupollas. En este caso, el gurupollas tien un olfato inherente y sorprendentemente desarrollado para detectar el riesgo. Si bien en cuanto hay alguna posibilidad de que haya un premio o reconocimiento el gurupollas sabe estar en primera fila (y si es posible, pisando alguna cabeza), cuando hay riesgos, es el rey del disfraz. ¿Que hay un pase a producción? Pues el gurupollas se ha ido de vacaciones. ¿Y si el cliente pide un sobre-esfuerzo? Pues el gurupollas le pide a su equipo un esfuerzo aún mayor: le echa al cliente o al jefe superior del esfuerzo extra, y si algo sale mal, de cara al cliente siempre tendrá un chivo expiatorio al que echar la culpa también. Hay que recordar que este espécimen lleva la gestión de riesgos de forma anticipativa: siempre tiene un culpable listo para cualquier problema que pueda anticipar. En caso contrario, tiene el poder de la desaparición, como ya hemos comentado.
• Gestión de problemas para gurupollas. Cuando el riesgo ya ha ocurrido, y se ha convertido en problema, el gurupollas ejecuta su plan de contingencia: ¿para qué buscar soluciones si podemos buscar culpables? El gurupollas es el rey de la dialéctica, y será capaz de manejar las reuniones con sus responsables y clientes, echando la culpa bien a quien no esté en la reunión (y no se pueda por tanto defender), o bien al eslabón más débil de la cadena, a quien le habrá previamente dejado en alguna sutil pero inapelable situación de peligro.

Al intentar completar el artículo, me he encontrado con otro (siempre se me adelanta alguien, no importa) que ha hecho ya un inteligentísimo desglose de características de este tipo de fauna gurupollística. Leed también si podéis el más que artículo de Andrés Toledo, que amplía muy bien lo que Alejandro había iniciado en el suyo.

Precisamente en este artículo, Andrés Toledo creo que tiene la clave del gurupollas más temible: no ya el de las redes (que también), sino el de cualquier empresa, el que trata de vender motos y alejarse del trabajo real para dedicarse a "gestionar" o a ser "arquitecto" o "asesorar" a los proyectos. Aquí es cuando se siente en su salsa, a base de repetir gastados mantras copiados de libros y redes tecnológicas, en las que ha conseguido destacar. O dedicándose a ser consultor freelance, dando conferencias y cursos a precio de oro de cualquier tema del momento, siempre en reducidos grupos y de un modo exclusivo.

Finalmente comentar un rasgo inherente en el gurupollas: es un pelota. Siempre te dirá lo que quieras oir. Nunca terminará una conversación, sino que iniciará otra con cualquier tema que entienda que te va a enganchar. Y si ya ha obtenido lo que quería de ti...adiós. No le verás el pelo. O como mucho te dará las migajas de la red: algún "me gusta" en Linkedin, Twitter, Facebook o en la red corporativa de la empresa y poco más.

Recordad: al igual que los aliens, los gurupollas ya están entre nosotros...y tú puedes ser su siguiente víctima.

¿Y tú, ya has identificado algún gurupollas?

Los derechos de los programadores

Para que un proyecto tenga éxito, el primer paso a tomar es hacer que cada una de las partes tenga respeto por los derechos de los demás. En la última entrada vimos los derechos del cliente. Hoy vamos a ver los derechos de los programadores.

#1 Conocer los objetivos del proyecto y tener unas prioridades claras.

Efectivamente, nuestra vida sería mucho más fácil si nos proporcionaran al principio (o lo antes posible), los objetivos priorizados.

#2 Conocer en detalle el producto a construir y aclarar y definir sus detalles si es necesario.

Por supuesto, los detalles del producto han de conocerse de forma suficientemente anticipada (podéis ver cómo lograr esto en mi serie de entradas sobre cómo hacer una toma de requisitos).

#3 Tener acceso al cliente, gerente, comercial o cualquier otra persona que tenga responsabilidades sobre la funcionalidad del producto.

Cuántas veces, las personas que toman decisiones funcionales están totalmente alejadas del equipo de desarrollo. Suele ocurrir que dicho equipo se ve bombardeado por cambios, funcionalidades, y se siente completamente alejado de la toma de decisiones. No es tanto tomar decisiones de forma activa (aunque tampoco estaría mal), sino simplemente poder participar en las decisiones y tener acceso directo a las personas que han definido las funcionalidades o son sus responsables, para aclarar dudas, conceptos y poder corregir definiciones incoherentes.

#4 Poder trabajar en cada fase del ciclo de vida de una forma técnicamente responsable (y especialmente no ser forzado a picar código desde el minuto cero).

¿Cuántas veces nos habremos visto obligados a escribir código desde el primer minuto? Esto, que es tan frecuente, es a la vez tan absurdo como una de mis frases favoritas:
- "Tú ves corriendo, que cuando sepamos hacia adónde hay que ir, te lo diremos"

Esta frase, tan frustrante como poco ilusionadora, es el pan de cada día en el desarrollo de software durante los últimos...¿50 años?

#5 Aprobar estimaciones de esfuerzo y entrega para cualquier trabajo que se le asigne. Esto incluye el derecho de tener el tiempo necesario para hacer estas estimaciones, y poder revisar dichas estimaciones si se producen cambios durante el proyecto.

Pues sí, es necesario cada vez más involucrar a los programadores en estimar o en aprobar y asimilar las estimaciones realizadas. Es estúpido hacer que los analistas o responsables estimen, y se aparte de esta tarea a los programadores, porque llega el día en que un programador es ascendido a analista...y tenemos un nuevo problema: no es capaz de estimar porque nunca se le ha dejado, y encima hemos quitado de programar a una persona que estaba muy preparada (¿porque le hemos ascendido al ser  bueno, verdad?)

Aunque se está volviendo al paradigma de tener equipos de desarrolladores de alto nivel, que toman también decisiones funcionales, ha habido una época en que se prefería una segmentación diferenciada entre programadores, analistas técnicos y analistas funcionales (u orgánicos). Por encima de ellos, los arquitectos tomaban decisiones de alto nivel, estructural (y cuántos arquitectos de boquilla aprovechaban para limitarse a decisiones obvias que aportaban poco a los problemas existentes, y eran totalmente inoperativos cuando tenían que enfrentarse a problemas reales...sobre esto creo que también tenemos para escribir otro día).

#6 Reportar el estado de mi trabajo de forma detallada a mis responsables y clientes.

Ya que somos responsables de nuestro trabajo, permitidnos informar y transmitir clara y detalladamente la situación. No hace falta hablar directamente con el cliente, pero al menos sí elaborar los correos o informes de estado, que además, nos prepararán para el siguiente nivel de nuestra carrera profesional.

#7 Trabajar en un entorno productivo, libre de interrupciones frecuentes y distracciones, especialmente durante las fases más críticas del proyecto.

Mmm esto, que también sería digno de otra entrada, es una causa frecuente del fracaso de los proyectos. ¿Acaso no recordamos la típica situación cuando vamos en el coche con nuestros hijos?:
- "Papá, hemos llegado ya?"
- "No, cariño, pero falta poco"
- (a los 2 minutos) "Papá, hemos llegado ya?"
- "Que no, cariño, que falta poco"
- (a los 2 minutos o menos) "Ya? Papá, ya?"
- "¡Que no, que te he dicho que no!"
- (a los 30 segundos...) "¿Papá, hemos llegado ya, ahora si verdad?"
- (Aquí el padre, ya está a punto de estampar el coche, asesinar a su hijo, vamos, le da todo igual)

Pues esta misma situación, pero cambiando al padre por el programador, y al hijo por el responsable/gerente/cliente, es el pan de cada día. Las empresas tienen comunicados internos, los proyectos tienen reuniones, informes, comités...Pero hay que definir períodos y horarios claros para ser productivos y sin interrupciones. Hagamos las reuniones, y comunicaciones internas (correos, preguntas, etc) en unos horarios establecidos (y mejor al final o al principio del día).

¿Y tú, estás de acuerdo con estos 7 derechos fundamentales de los programadores?

Los derechos del cliente

Hoy vamos con algo ligero y no por ello menos importante: los derechos del cliente. Y no penséis que vamos a revisar leyes y decretos, ni mucho menos.

Hablamos de fomentar una relación profesional de respeto y confianza, basada en unas normas conocidas y simples que permitan a nuestros clientes seguir trabajando recursivamente con nosotros en proyecto tras proyecto. Empecemos.

#1: Fijar los objetivos del proyecto, y que éstos se sigan.

Desde luego, el cliente tiene derecho a establecer qué hay que hacer (requisitos), pero no sólo eso. También tiene el derecho de establecer los objetivos generales del proyecto, la visión del mismo que hay que cumplir y que debe terminar no sólo con un software que funciona, sino además, con unos objetivos corporativos satisfechos.

#2: Conocer cuánto tiempo va a costar hacer el software, y cuánto dinero me va a costar.

Aquí ya lo siento por los talibanes del agilismo. Pero es uno de los puntos que hay que respetar del cliente: tiene este derecho inalienable.
Por supuesto, si el cliente nos permite hacer el desarrollo mediante sprints, usando métodos ágiles, y  está dispuesto a no saber cuándo estará terminado ni el precio final...estupendo. La gente se entiende hablando.
También hay que decir, que ser ágiles o usar metodologías ágiles, no tiene que estar forzosamente relacionado con una fecha de entrega fija y precio fijo.

#3: Decidir qué funcionalidades se incluyen, y cuáles se quedan fuera del software.

Aquí las técnicas ágiles pueden ayudar: entregas frecuentes, identificación de funcionalidades prioritarias...etc. Lo que hay que tener claro, es que la última palabra, la tiene el cliente. Es nuestro problema si nosotros hubiéramos preferido dejar esa otra funcionalidad fuera de esta versión...

#4: Poder hacer razonables cambios en el software durante su construcción, y conocer sus costes antes de llevarlos a cabo.

De nuevo, las metodologías ágiles nos pueden permitir asumir los cambios de forma práctica. Pero un buen procedimiento de control de cambios no está de más. No sólo eso, sino que al cliente hay que aclararle cuánto le va a costar de más (o de menos, no seamos ladrones, que también existe esa posibilidad) el añadir o quitar cosas, el hacer cambios durante la construcción. Por supuesto, también hay que aclararle al cliente el impacto en la fecha de entrega (que puede adelantarse o retrasarse).

#5: Conocer el estado del desarrollo de forma clara y concisa.

El cliente tiene derecho a estar informado claramente del estado: funcionalidades en cartera (backlog en terminología ágil), en desarrollo, desarrolladas, etc.

#6: Ser avisado regularmente de los riesgos que afecten al coste, la calidad o la fecha de entrega, y ser informado de qué opciones hay para evitar o resolver los problemas anticipadamente.

Esta es una de las partes más flojas que he observado durante mis muchos años en el mundo del desarrollo de software. Se suele hacer una gestión pésima de riesgos y problemas. En muchas ocasiones limitada a mostrar obstáculos obvios e inmediatos, y cuando hay problemas o riesgos inminentes, las opciones y planes de contingencia son desproporcionadamente pobres y carentes de credibilidad.

#7: Tener acceso a los entregables durante todo el proyecto.

Para terminar, el cliente debe tener acceso a los entregables. Y sí, me refiero a la documentación, a esos documentos que tanto nos cuesta realizar y que para el cliente son la prueba de que sabemos trabajar, y de que el estado de nuestro trabajo da credibilidad de que somos capaces de terminar.
Además, esa documentación deberá ser altamente práctica y muy ágil, para facilitar el cambio y servir a otros grupos de trabajo: proveedores que se integran con nosotros y que han de ver en esos documentos una información mínima pero suficiente, personal de mantenimiento, de sistemas (que deberán tener claro cómo instalar, desinstalar, etc.).

¿Y tú, estás de acuerdo con estos puntos? ¿Añadirías alguno o quitarías alguno? Gracias por vuestros comentarios.


¡Ah! y en el próximo artículo, veremos los derechos del equipo de desarrollo (aquí hay pan para todos). Un cordial saludo.

Fuente: Adaptación libre de: Software Project Survival Guide (Steve McConnell, Microsoft Press)

Mantenimiento software: ¿qué modelo de procesos usar?

Si te dedicas al mantenimiento del software y te interesa saber más sobre qué estándares o modelos de referencia de procesos hay en el mercado, puedes consultar el siguiente enlace:

http://www.berriprocess.com/es/todas-las-categorias/item/30-cmmi-svc_proyectos_mantenimiento

En él, Teodora Bozheva da un rápido vistazo al modelo más adecuado, identificando las diferencias principales entre los proyectos de mantenimiento y desarrollo.

Tanto si eres experto, como si estás empezando, creo que ese artículo está muy bien enfocado a ambos perfiles. No te pierdas, al final del  artículo, el apartado "Referencias".

Saludos.

La doctrina del comentario

Hoy voy a hablar del comentar o no comentar el código, que parece que se está convirtiendo en una doctrina.

¿Qué es lo que ocurre? Vengo observando un tiempo la tradicional defensa del comentario como algo necesario, pero que hay que controlar en tamaño (nº de comentarios respecto al código), forma (estándares), etc.

Por otro lado, está la defensa a ultranza de la total ausencia de comentarios. Ojo, porque aquí sí que se suelen excluir los comentarios JavaDoc o NDoc que suele haber al principio de las clases y que se utilizan principalmente para documentar el código. Esto, menos mal, parece que nadie lo pone en duda (o al menos, no he identificado un grupo que esté por la labor de eliminarlo).

A continuación, veremos algunos argumentos o doctrinas que la gente utiliza en sus blogs en internet, y que me parecen interesantes. No los copio aquí para ensalzar ni tampoco ridiculizar a sus autores, sino sólo para intentar entender este tipo de argumentos y poder entender de qué hablamos. El objetivo no es tanto quitar la razón a los que están en contra de los comentarios, sino más bien entender el porqué de su postura, y tratar de ir un poco más allá. Yo de momento, sí me declaro abiertamente defensor de comentar el código, aunque luego hablaremos de con qué matices (mmm veo que de aquí tengo material para otro artículo de enfermedades del software: la "comentaritis"). Siempre creo que "menos es más".

Frases en contra o a favor de los comentarios que podemos encontrar por la web:

• Usar comentarios va en contra de mis principios.
• los comentarios son siempre "el patito feo" del código fuente, cuando en realidad son tan importantes como el resto
• comentar antes de programar, es lo que todo programador debe hacer. No puedes lanzarte a programar sin saber lo que quieres lograr.
• al desarrollador por lo general no nos gusta "perder el tiempo" comentando y mucho menos documentando
• si lo he hecho yo, ya sabré porqué lo he hecho
• los comentarios en el código son algo completamente inútil que no hacen más que entorpecer y causar problemas
• Cuando el código es modificado, tenemos que modificar también los comentarios, pues corremos el riesgo a explicar algo que no es lo que estamos haciendo. Ya bastante trabajo resulta mantener un código para también tener que mantener un paquete de oraciones.
• Provocan problemas culturales, ya que muchas veces los comentarios están en un idioma diferente al que es capaz de leer el desarrollador actual, o en la mejor intención de hacerse entender, el "escritor" dejó una lista de oraciones sin concordancia, sentido, y con cientos de faltas de ortografía y errores gramaticales.
• El que un comentario parezca necesario es signo de que el código no es lo suficientemente claro. Un buen código debe siempre explicarse por sí mismo sin necesidad de un "bastón" (o comentario).
• Reducen la claridad en el código. ¿Alguna vez han visto un método con 50 líneas de las cuales menos de 10 son de código y lo otro es todo un tratado científico? Yo sí, y resulta un verdadero dolor de espalda descubrir las líneas reales ejecutables entre tantas palabras
• Esta técnica de crear métodos para aislar secciones de código y dejar bien clara su función es extremadamente útil para aumentar la claridad. En vez de tener un módulo con 500 líneas ejecutables, podemos dividirlo en varios métodos cuya responsabilidad esté bien delimitada. El resultado final será mucho más claro y flexible.
• los comentarios son la prostitución de las incapacidades de un programador.

¿Qué radicales son algunos de los comentarios, verdad? Y no es para menos. Por desgracia, es frecuente encontrarse programadores poco experimentados en los equipos que acaban sufriendo de "comentitis": lo llenan todo de comentarios por su inseguridad y falta de método. Aquí os recomendaría los que a mi modo de ver son dos libros indispensables tanto para programadores que se creen experimentados, como para los que empiezan. (Creedme, nunca seremos suficientemente experimentados, y lo que es peor, el paso del tiempo, la destreza se pierde). Los libros son:

• Code Complete, de Steve McConnell
• Clean Code, de Robert C. Martin

Dejaremos para otro día unas recomendaciones sobre qué y cómo comentar, y porqué. Ahora vamos a dar un breve repaso a algunos consejos para evitar que nos afecte:

• No podemos controlar todo lo que hacen los demás. No podemos exigir que respeten nuestra forma de trabajar si no respetamos la de los demás. No todo el mundo tenemos el mismo nivel técnico.
• Si algo te molesta, dilo. Pero ten respeto por las personas y su trabajo. Además, te encontrarás con que quizás a ese programador le obligaron a hacerlo así, o quizás era su primer trabajo (todos hemos tenido un primer trabajo, y un segundo trabajo).
• Controla tu ego. No puedes imponer a todo el mundo trabajar como te gusta. Porque se trata de eso: tu gusto.
• No confundir lo anterior con normas de codificación. Si el proyecto o la empresa (o el cliente), tiene unas normas de codificación, hay que seguirlas. Peor que ver código mal hecho, es ver código hecho de dos formas distintas en función de miembros del equipo disciplinados, y los "libres y ajenos a toda norma".
• las normas de codificación, y sobre todo, las relativas a los comentarios, han de ser muy simples. Un comentario no es tan importante como para perder tiempo con 200 páginas de normas y un curso intensivo de 3 días.
• El comentario no nos va a dar de comer: el código sí. Dicho esto, no significa que debamos ignorar y eliminar los comentarios. Si cada palabra clave o sintaxis del lenguaje que no nos gusta o "nos parece" poco útil se eliminara, os aseguro que entre unos y otros, sólo dejaríamos en el código líneas en blanco.
• Todos dejamos código basura. (unos más que otros,es cierto). Pues también hay comentarios basura. Y contra ambos hay que luchar.
• En tu empresa, en tu proyecto, adopta una forma de comentar simple y efectiva, minimalista. Usa sólo lo imprescindible y haz que todos lo adopten. Si trabajas solo, ten en cuenta que tu código o lo pueden usar en otros proyectos, o ya se está integrando en otros proyectos. Recuerda: hazte respetar respetando tú antes la forma de trabajo de los demás.

¿Estáis de acuerdo? ¿O sois defensores de los comentarios? ¿O abogáis por su más absoluta erradicación?
Por cierto, habrá que acuñar el término "Genocida de Comentarios", si esto llegara a ocurrir ;)
Y bueno, creo que ya vale para una entrada un tanto improvisada.
Un saludo a todos.

5 puntos que te salvarán de los cambios (y 3 que te hundirán si no los evitas)

En todo proyecto software, hay cambios. El cambio, hay que aceptarlo como lo que es, y entender su motivación y circunstancias. Hoy nos vamos a centrar en estar preparados para el cambio en el desarrollo de software, mediante 5 puntos clave que hay que conseguir. Además, otros 3 puntos clave que hay que evitar, para que no nos "hundan el chiringuito". Vamos Allá.

1. Puntos Clave a cumplir

1.1. El proyecto tiene designado un equipo/comité responsable de los cambios.

No hace falta que sea un comité sofisticado, ni pensemos en un comité como 20 personas serias y  estiradas reunidas en una sala gigante durante horas. Un comité simplemente es una reunión formal o informal, en la que se revisan temas (cambios en este caso), y donde todas las partes están representadas. Una persona puede representar a varias partes. Por ejemplo, sería interesante que al menos hubiera participantes por parte de:

• Cliente (responsable que defiende los intereses del cliente).
• Equipo de desarrollo (responsable funcional/técnico)
• Dirección del proyecto (responsable económico/planificación)

Puede ser suficiente un foro, un blog, o una lista de correo (ni siquiera se tienen que reunir físicamente esas personas).

1.2. El proyecto tiene un plan o procedimiento escrito y aceptado de gestión de cambios.

Aquí, de nuevo, menos es más. Me  hace gracia cuando en una reunión planteo cómo se van a gestionar los cambios. Todo el mundo asume que los cambios se van a hacer. Ese no es el tema. La gestión del cambio está para decidir qué/cuándo/cómo. De eso hablaremos en detalle otro día.
Como siempre, lo importante es aclarar el funcionamiento y acatar las decisiones tomadas en consecuencia.

1.3. Las peticiones de cambio se evalúan por todas las partes implicadas en el proyecto, antes de resolverse.

Esto es importante, si nos dejamos a alguien fuera al resolver un cambio, tenemos todas las probabilidades de que esa parte decisoria será la que nos haga echar el cambio atrás. De hecho, hay gente que lo hace por el mero placer de ejercer el poder de hacerlo.

1.4. El equipo/comité responsable de cambios, se asegura de que todas las partes implicadas están adecuadamente informadas de cómo se resuelven los cambios.

Otra vez un punto crítico: no nos dejemos a nadie fuera. ¿Te gusta que tu pareja tome una decisión o haga algo sin decírtelo? (no, ya sé que tu pareja lo hace, te estoy preguntando si te gusta!).

1.5. El equipo/comité responsable de cambios evalúa los cambios por paquetes, evitando distraer al equipo de desarrollo de forma constante.

Bastante tienen/tenemos los desarrolladores con lidiar con las complejidades técnicas, las dificultades de las distintas arquitecturas, la definición funcional, etc, etc....como para que encima nos interrumpan cada poco tiempo con cosas nuevas. Hay quien dice que es mejor interrumpir con los cambios, ya que éstos pueden afectar al trabajo en curso. MENTIRA. Déjame acabar lo que estaba haciendo, y luego ya veré cómo aplico el cambio. ¿A alguien se le pasa por la cabeza reformar su casa mientras los albañiles están levantando los pisos y poniendo ladrillos?.

2. Puntos clave a evitar.

2.1. Las decisiones del comité de cambios pueden contradecirse por la dirección, marketing o el cliente.

A ver, hay que ser serios. Respetemos los acuerdos alcanzados.

2.2. El equipo de desarrollo no tiene tiempo suficiente para seguir el plan.

De nada sirve montar un comité ni toda esta fiesta, si el equipo de trabajo está con sobreesfuerzo. Si no hay tiempo, y el plan no se puede seguir, menos aún podremos abordar cambios. Hay técnicas para eso, pero mejor lo dejamos para otro día.

2.3. Los productos del trabajo no siguen el control de cambios.

Esto que dicho así suena muy sofisticado, no es más que hacer el maldito check-in, anotar los cambios, y asociarlos a alguna tarea. Lo mismo cuando estemos preparando una versión al final de un sprint. Etiquetemos adecuadamente las versiones, su estabilidad, etc. Pocas cosas hay más divertidas que después de que nuestro equipo de sufridos testers pierda días y días probando la versión N, ahora vamos nosotros y entregamos al cliente la versión N+1. Manda huevos.

Comida con Ricardo Serna

Ayer estuve comiendo y compartiendo café y charla con Ricardo Serna, escritor Zaragozano. Aunque ya lo había conocido anteriormente, no era consciente de su obra como artista literario, así que he aprovechado para subsanar este hecho y curiosear algo de su blog, y con él, de su bibliografía. Es curioso, porque mi contacto con él en principio se limita a un buen amigo común.

Resulta interesante que conozcamos tan poco de las personas que tenemos cerca y su aportación a las artes y la cultura, y en este caso concreto, a la literatura. Me ha sorprendido su buen hacer y sobre todo, lo bien que hablan de él los entendidos en estas lides (léase otros reconocidos escritores españoles).

Que sea para muchos años, maestro.

"Escribir es una forma de aprehender la vida" [Ricardo Serna, escritor]

Para más información:
Ricardo Serna en Wikipedia: http://es.wikipedia.org/wiki/Ricardo_Serna
Blog de Ricardo Serna: http://ricardo-serna.blogspot.com.es/

Cómo no hay que comunicar un despido

Esta entrada estaba pendiente hacía mucho tiempo. Y en realidad ha cambiado diversas veces de nombre. Empezó siendo un tema de comunicación en la empresa, y le acabé dando la vuelta, y la vuelta, y al final no quedó nada de la idea original. Quizá algún día la desarrolle. Al final, ha quedado un tema no menos importante, pero que además es muy peliagudo: cómo no comunicar un despido. Además es que tenía que colocar en algún sitio este chiste de Dilbert y no sabía cómo.

También me gustaría que no lo tomarais como un reproche. Al gestionar un proyecto, al formar parte de una empresa, hay muchas funciones que hay que cubrir. Por desgracia, en ocasiones, no todo es maravilloso, y puede llegar a ser necesario prescindir de un puesto de trabajo, y con ello, despedir a quien lo ocupa.

Este tema ha sido ya tratado en muchos sitios, pero hoy me apetecía darle algo de humor. Y humor realmente negro. Vamos a relajarnos un poco, y exploraremos cómo hay que hacer estas cosas, tratando de justificar los argumentos contrarios. Es decir, vamos a explicar COMO NO DEBE DESPEDIRSE.

Dar rodeos.

Es importante no ser claro ni conciso. Si vas a comunicar un despido, lo mejor es que des rodeos y dejes pistas. Como decía aquel humorista "alguien va a despedir a alguien..." o un "...alguien va a ser despedido..." Después de todo, lo importante es la empresa. Que matemos de un infarto al pobre infeliz no es relevante. Nada de sentarlo en una silla y comunicar claramente la noticia. Mejor incluso: extendamos rumores de que va a haber un gran número de despidos. Así sólo uno se sentirá mal (el despedido), y el resto saltará de alegría al saber que no han sido los perjudicados. Es la técnica de la alegría por comparación. Me quedo igual que estaba, pero como me había hecho a la idea de que iba a recibir una mala noticia....

Poca claridad.

Nada de decir las cosas claritas y sencillas. Mejor un:
- "...tu proyecto acaba el mes que viene, yo estaría preocupado..." o también:
- "...eres demasiado caro, no sé qué pasará contigo..."
Después de todo, a la gente le gusta vivir la emoción, el riesgo, el "no saber qué ocurrirá mañana". Qué mejor técnica gerencial que la sorpresa y la incertidumbre.

Poca elegancia.

Saber dar una mala noticia es un arte. Como lo es un piropo. ¿Qué puede haber más grato para una mujer que algo como "te lo comía todo" o un "ay si te pillo te..." (mejor no sigo)? Pues en esta línea, dar un despido a alguien no requiere elegancia. Mejor empezar con reproches, humillaciones y cualquier otra técnica que haga pensar al despedido que es su culpa. Y si es posible gritando o en público mejor. De su escarnio público algo se podrá sacar. Además, ya que le estamos despidiendo, es el momento de sacar todos los trapos sucios que tengamos (sean de él o no, y sean verdad o no). Total no es un juicio. Hagámosle un favor, y que se vaya pensando que mejor nunca haber estado aquí.

No saber escuchar.

Nunca des pie a que se explique un despedido. ¿Para qué? Tras la sarta de injurias y trapos sucios, no le van a quedar ganas de hablar. Aquí los únicos que tenemos que hablar somos nosotros. Que para eso estamos despidiendo (y esto, quieras que no, cansa mucho y requiere de concentración).

Falta de intimidad.

Como habíamos comentado anteriormente, lo mejor es hacerlo en público. Que todos se enteren. Así nos temerán, y verán que no nos andamos con tonterías.

Cuándo despedir.

La mejor hora es a primera hora. Nada más llegar al trabajo. Así le haces sentir que además de perder su empleo, ha perdido el día: ha madrugado tontamente, y ahora  va  a perder la mañana en papeleos inútiles, pues total, ya está despedido. Tiene todo el día para pensar porqué lo hemos hecho (recordad la poca claridad), y que la falta de elegancia y de empatía (no saber escuchar), hagan el resto. Además para el que despide, es un revulsivo de energía. Oiga, anda que no es mejor que el mejor café expreso: humillar y fastidiar a la persona despedida, hacerle sentir mal, inútil y saber que tiene todo el resto del día para regodearse en su desgracia. Además si es posible, hagámosle permanecer en su puesto de trabajo con alguna excusa del estilo:
- "Quédate un poco para ceder tu conocimiento" o también:
- "No te vayas sin zanjar papeles y devolver el material, etc".
Así, de nuevo, nos aseguraremos con dar ejemplo al resto de compañeros, que verán cómo nuestra autoridad y liderazgo priman sobre cualquier cosa.

Hazlo sin tiempo.

No se te ocurra dar un preaviso. ¡No vaya a ser que el pobre incauto trate de buscarse otro trabajo! En España existe un preaviso de 15 días, pero no es orientativo y además las leyes están equivocadas. Además, dar tiempo a una persona puede significar que trate de conocer sus derechos. Y eso sí que no.

No des explicaciones.

No expliques al despedido porqué, ni quién, ni cómo ha tomado la decisión. Ni cómo va a afectar a la organización.

Promete cualquier cosa, aunque sepas que no la vas a poder cumplir.

Da falsas promesas al despedido. Insístele que se trata de algo coyuntural, y que seguramente podrán volver a contratarlo más adelante, incluso con mejor sueldo. Y al resto de los empleados, asegúrales que no va a haber más despidos. Aprovecha para dejar claro porqué has despedido a esta persona insistiendo en una humillación pública (hazlo mientras aún está presente el despedido, claro).

Siempre que sea posible, no lo hagas cara a cara.

Lo mejor es un correo. O mejor aún: desactivar el acceso del empleado. No hay nada más agradable que un guardia de seguridad que nos impide el acceso a nuestro centro de trabajo (de nuevo, esto es mucho mejor si ocurre mientras nuestros ya ex-compañeros lo ven todo).

Pues nada, espero que os haya gustado este "artículo inverso" en tono de humor negro.

Fuente:
http://www.20minutos.es/noticia/350842/0/como/comunicar/despido/
http://podemoshablar.blogspot.com.es/2008/11/comunicar-despidos-difcil-y-odiosa.html