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)