Picacodigos

Muchos de los desarrolladores que conozco llevan programando desde el instituto. Tanto si era construyendo juegos en modo texto en un Apple IIe o creando una aplicación para el banquillo del equipo de fútbol de la escuela en Visual Basic, es algo que hacían por el desafío y, claro, por las chicas. Las mujeres aman a un hombre que puede hablar en BASIC con su Apple.

Los graduados universitarios se enfrentan a una triste realidad cuando abandonan el vientre protector de la universidad y tienen que conseguir su primer empleo. Muchos de mis amigos encontraron trabajos que les suponían unos 250.000 dólares al salir de la universidad, y les asombraba que los salarios iniciales en trabajos de ingenierías e informática eran casi el doble. Pero la mayoría de los ingenieros en mi clase no se hicieron ingenieros por el dinero; lo hicimos porque teníamos un profundo deseo de trastear e impresionar a nuestros amigos. ¿Ya os he dicho lo de las chicas?

El dinero es un factor de motivación para la mayoría de nosotros, pero asumiendo una paga comparable, ¿qué es lo que hace que ciertas compañías atraigan y mantengan a los desarrolladores mientras que otras los reciclan como si fueran papel higiénico?

Higiene y Motivación
En la década de los 50 un investigador llamado Frederick Herzberg estudió a 200 ingenieros y contables de los Estados Unidos. Mediante una serie de preguntas simples obtuvo las que es una de las teorías más ampliamente aceptadas sobre satisfacción en el trabajo llamada Teoría de los Dos Factores.

Su teoría divide la satisfacción laboral en dos factores:

• Factores de higiene tales como las condiciones laborales, calidad de la supervisión, salario, seguridad y políticas de empresa
• Factores de motivación tales como los logros, reconocimiento, responsabilidad, el trabajo en sí, desarrollo profesional y personal

Los factores de higiene son necesarios para asegurar que los empleados no se encuentren insatisfechos, pero no contribuyen a obtener niveles altos de motivación. Los factores de motivación son los que crean satisfacción laboral proveyendo a los empleados de sentido y crecimiento personal.

Piensa en grandes compañías financieras como Countrywide o IndyMac. Aunque nunca he trabajado para ninguna de ellas, las historias que he oído indican que sus factores de higiene son buenos: las condiciones de trabajo son buenas, los supervisores son razonables, los salarios decentes, tienen buenos beneficios adicionales, etc...

Sin embargo, los factores de motivación son, cómo decirlo, inexistentes. Como vió Herzberg, este escenario conduce a que los empleados vean el trabajo como poco más que un salario, lo que probablemente es perfecto para compañías como Countrywide o IndyMac.

Tomemos el extremo opuesto: una pequeña startup en una sórdida oficina sin ventanas, los beneficios son nulos, prácticamente sin supervisión (porque el Consejero Delegado está en la calle, vendiendo el producto) y sin políticas de empresa (porque el Consejero Delegado está en la calle, vendiendo el producto). Pero el subidón constante del aprendizaje, el ser responsable, en ocasiones directo o único, del éxito o fracaso de la empresa, y la creencia en el crecimiento futuro de la empresa hacen a este trabajo mucho más deseable para muchos desarrolladores.

Uno de mis primeros trabajos de programación fue para una pequeña consultoría web durante la burbuja de las punto com. Éramos 7, y crecimos hasta 17 en el pico de la burbuja; disparándonos con pistolas de agua, tirándonos balones de fútbol americano Nerf y produciendo cantidades exageradas de código propulsado por cafeína. Aprendíamos un lenguaje nuevo con cada proyecto y siempre estábamos a la última.

Recuerdo haber pensado que una empresa podría haberme ofrecido un aumento de quince mil dólares y no lo hubiera aceptado. Los factores de motivación eran dominantes.

Lo malo era que los beneficios eran horribles, la oficina consistía en una serie de cubículos diminutos, grises tras años de abandono, cables azul pitufo colgando del techo, y la gerencia era... bueno... inexistente. Y aunque nos faltaban factores de higiene, los desarrolladores venían en manada a trabajar con nosotros y sólo uno se marchó mientras estuve allí. Estaba interesada en mejores beneficios y un entorno de trabajo más estable, y se fue a trabajar a una gran empresa financiera muy parecida a IndyMac.

El criterio de Rob para mantener a tus desarrolladores felices
Si quieres ganarte un sueldo durante 25 años y retirarte con un reloj de oro y una pensión ponte a trabajar en una empresa que tenga los factores de higiene bien estudiados. Entra a las 8, vete a las 4:59 y cuenta los años hasta que estés estirando las piernas en un bar playero en Costa Rica.

Pero si estás leyendo esto, es más probable que no seas el tipo de persona que no piensa sobre código después de las 5:01; es más probable que tengas una colección de DVDs que salga en una búsqueda en Amazon por "Silicon Valley." Probablemente seas una de esas personas que necesita factores de motivación o te vuelvas loca de agitación, y cuando tienes dichos factores trabajarás en horarios absurdos por poco dinero sólo porque es divertido de narices.

He hablado con unos cuantos colegas y vertido mis propias experiencias para obtener esta lista de nueve factores de motivación para el desarrollo de software - Los criterios de Rob para mantener a tus programadores contentos.

Sólo hay una regla para determinar tu puntuación: tu voto no cuenta a no ser que seas programador. Si no estás en las trincheras escribiendo código entonces reenvíale este artículo a alguien que sí lo sea y pregúntale su opinión. Mi gran esperanza es que esto provoque conversaciones y fuerce a los desarrolladores y gerentes a hablar acerca de estas cuestiones para que podamos sacarlas a la luz.

Sin más introducción, aquí están:

1.- Planear para tener éxito
Es una triste realidad, pero la mayoría de los proyectos de software están preparados para fracasar. Todos los programadores tienen sus historias de miedo, los anti patrones de la gestión de proyectos de software.

He visto a un arquitecto al que se le proporcionó la documentación de un sistema antiguo, y estuvo sudando tinta con ella durante una semana mientras diseñaba un nuevo interfaz para el producto. Después de que el diseño estuvo terminado supo que la documentación estaba tres años obsoleta y no reflejaba ciertos cambios importantes en el sistema.

He pasado horas preparando una estimación técnica detallada solo para encontrarme con que la fecha límite real, ya fijada por los gerentes, me daba la mitad del tiempo necesario.

Un conjunto de fechas límite realistas son una parte inmensa de la preparación para el éxito. Los programadores quieren desarrollar software que no sólo funciona, sino que es mantenible; algo de lo que puedan sentirse orgullosos. Esto no concuerda con los objetivos de los gerentes, que quieren que los desarrolladores produzcan software que funciona, y nada más.

Lo primero en obviarse cuando el tiempo es limitado es la calidad y la sostenibilidad. Lo peor que se le puede hacer a un artesano es obligarlo a construir basura. Presentar un proyecto a tiempo pero sabiendo que es un montón de mierda se parece muchísimo al fracaso para alguien que se enorgullece de su trabajo.

Es vital tener tiempo para hacer las cosas del modo correcto, y no sólo del módo rápido. Como me dijo un desarrollador, "La calidad es tan importante como la lista de características o el presupuesto."

Los tiempos no son la única manera en la que un proyecto puede estar preparado para fracasar, pero es la más común. Otras incluyen: estar obligado a usar herramientas malas (tanto en hardware como en software), trabajar con un compañero que no hace su parte, mala gestión de proyectos (ver número 2, más abajo), cambiar el alcance del proyecto, y las expectativas no declaradas, entre otras.

2. Tener una gestión excelente
Una gestión excelente, tanto de proyectos como de personal, es un factor de motivación obligatorio. Esto significa nada de micro-manejo, alentar el pensamiento independiente, saber qué hace falta para desarrollar software de calidad, toma rápida de decisiones, y la voluntad de defender a muerte al equipo cuando los jefes intentan acortar el tiempo de desarrollo.

Éstas son las cualidades de un gran gerente de software; las cualidades de un gerente cuyo equipo se bañaría en aceite hirviendo por defenderlo, y trabajarían noches enteras para probar que estaba en lo cierto. Cuando un gerente recibe palos por el equipo, los buenos programadores tienden a devolver el favor con propina. Crea una lealtad casi de culto, y los resultados no son sólo programadores motivados, sino software increíblemente bueno.

3. Aprender cosas nuevas
Las investigaciones sobre la conducta indican que somos más felices cuando aprendemos nuevas habilidades o ponemos a prueba las que ya conocemos. Un reciente artículo cita el estudio de dos investigadores de la Universidad de Columbia que sugiere que los trabajadores podrían dejar pasar tranquilamente un aumento del 20% del sueldo a cambio de un trabajo con más variedad o en el que fuera necesario más de una habilidad. Esta investigación sugiere que estamos dispuestos a cobrar menos por un trabajo que sea más interesante, divertido y que nos enseñe cosas nuevas.

Esta es la razón por la cual las compañías que usan Ruby pueden encontrar programadores experimentados que deseen trabajar por menos de sus salarios normales. El factor de aprendizaje es enorme a la hora de negociar las compensaciones.

A todos los programadores que conozco les encanta jugar con tecnologías nuevas y relucientes. Perl y HTML a mediados de los 90, ASP, PHP y Java a finales, ASP.NET y XML hace un par de años y hoy es AJAX y Ruby (y en algunos círculos ASP.NET 2.0). Dale a alguien la oportunidad para usar estos juguetes y no sólo serán capaces de impresionar a sus amigos, pero cumplirán ese deseo interno de aprender.

Haz que un programador siga aprendiendo y lo tendrás feliz trabajando en un sótano sin ventanas, comiendo pan rancio de una bandeja en la puerta. Y nunca te pedirán un aumento.

4. Ejercitar la creatividad y resolver el tipo adecuado de problemas
Los desarrrolladores aman los desafíos. Sin ellos nos aburrimos, nuestras mentes vagan, comprobamos nuestra cuenta bancaria, comprobamos el correo, miramos Digg y Barrapunto, leemos blogs, nos vamos a la máquina de cafe, y miramos si alguno de nuestros amigos está online a ver si de una vez por todas podemos finalizar el debate sobre nuestro tío, Java contra .NET, o el último episodio de Perdidos.

Muchas veces he visto a programadores quedarse a trabajar hasta el amanecer para resolver un problema técnico sin que se lo pidan y sin cobrar horas extra. Los mejores desarrolladores son adictos a la resolución de problemas. Tírales un Sudoku en medio de un grupo de ellos y observa cómo lo atacan.

Enfrentados a la clase correcta de desafío, muchos desarrolladores no pararán hasta que esté resuelto, especialmente si requiere de una solución particularmente creativa. Enfréntalos a la clase errónea de desafío y se vuelven instantáneamente al Messenger a hablar sobre los números chungos.

El tipo correcto de desafío es un desafío técnico que les enseña una nueva habilidad, preferiblemente una que esté de moda. Un ejemplo podría ser: "Conéctate a estos cinco servicios RSS, agrega los datos, y muestra los titulares en una página Web... teniendo en cuenta cómo usar AJAX para que tenga una pinta molona."

Los tipos erróneos de desafío son cosas como: "Arregla el código de este otro tío. Ya sabes, ese al que no despedimos porque teníamos miedo de que nos diera problemas, o porque salía demasiado caro en compensaciones. Pues programó un sistema que es una auténtica chapuza y ahora nos hace falta arreglarlo y hacer que sea de buena calidad y mantenible. Ah, y tienes hasta mañana para hacerlo."

Si tienes una empresa que no proporciona trabajo excitante a sus desarrolladores, piensa en cómo puede empezar a hacerlo. Si no hay ninguna oportunidad de que alguna vez puedas ofrecer desafíos, encuentra a programadores que prefieran los factores de higiene, porque los programadores que necesiten factores de motivación no se van a quedar mucho en tu empresa.

5. Tener voz
Los desarrolladores están en las trincheras, y son los primeros en saber cuando un sistema o proceso no funciona. Un programador me contó:

"Quiero que alguien escuche mis problemas y se los tome realmente en serio. He trabajado en sitios donde más RAM, más espacio en disco, o CPU más rápidas o duales sencillamente no eran prioritarias para la compañía, y lo que teníamos era lo suficientemente malo como para impedirme trabajar. En otro sitio en el que trabajé, cada vez que quería compilar tenía que limpiar todos mis archivos temporales porque necesitaba más espacio en disco. Es estúpido. Que te obliguen a trabajar con tecnología obsoleta es realmente frustrante."

Cuando un programador habla, alguien debería escuchar. Cuando varios programadores están diciendo lo mismo, alguien debería escuchar y actuar... y deprisa.

6. Que reconozcan el trabajo duro
Como ingenieros nos encanta construir cosas que nos impresionen a nosotros y a nuestros amigos. Al menos a aquellos que sepan lo duro que es escribir un compilador de Perl. Desde cero. En FORTRAN. En un Vic 20.

Construir algo grande es divertido, pero es mucho más divertido cuando hay alguien para palmearte en la espalda, hacerte una fiesta, cantar tus alabanzas o pagarte una cena. La mayoría de los programadores disfrutan de los cumplidos y el recibir el reconocimiento por el trabajo duro, pero incluso aquellos que no lo necesitan se sienten algo frustrados cuando no lo reciben (o peor aún, cuando alguien más recibe el reconocimiento por tu trabajo).

El reconocimiento es uno de los factores de motivación centrales de Herzberg y se aplica tanto a los desarrolladores de software como a los ingenieros que él entrevistó originalmente.

7. Construir algo importante
Incluso aunque no seamos médicos en Bosnia o transportemos comida en Sudán, la mayoría de la gente quiere sentir que de alguna forma estamos contribuyendo a hacer del mundo un lugar mejor, tanto tecnológica como socialmente. Algunos de nosotros podemos pensar que lo hacemos sólo por la tecnología, pero en el fondo de nuestras mentes nos vemos como parte de un gran plan.

Por ejemplo, un amigo mío trabaja para una compañía financiera y disfruta cada vez que lanzan un producto que ayuda a la comunidad financiera.

Un programador del sistema de inventario de una cadena de supermercados disfruta yendo a trabajar todos los días porque su trabajo garantiza, mediante algoritmos complejos de suministro y demanda, que los cereales infantiles estén siempre disponibles en las estanterías.

El construir algo que importa hace que un ingeniero del L.A. Times sea muy feliz, ya que gracias a su software de búsqueda de caminos los camiones que distribuyen el periódico ahorran un 30% de kilometraje y combustible.

Por otra parte, construir un interfaz para una API repleta de errores que se usará un total de quince veces el año próximo no parece que importe demasiado.

Copiar y pegar una aplicación entera y cambiar un puñado de etiquetas no es tan excitante como puede parecer.

Y meter unas cuantas sentencias CASE en un procedimiento almacenado ridículamente complejo para apañar a otro cliente más sin crear una estructura apropiada de datos por alguna razón no sirve para satisfacer a esa parte de nosotros que quiere construir cosas que importen.

8. Desarrollar software sin actas parlamentarias
Desde el 2001 fui un consultor durante tres años, y durante ese tiempo hice un montón de aplicaciones web. Me acostumbré a escribir código realmente rápido una vez que sabíamos qué había que hacer. Entre otro programador y yo escribimos una cantidad ingente de software durante dos años.

Cuando entré en mi siguiente trabajo a tiempo completo me sentía como si arrastrara pesas de 25 kilos. Por cada página que quería desarrollar tenía que tener una reunión con seis personas. Cualquier cambio en la base de datos requería de la aprobación de otras tres. Era una locura, y las aplicaciones tardaban cinco veces más en construirse. Frustrante.

La autoridad de hacer decisiones relativas al proyecto sin necesidad de convocar reuniones es importantísima.

9. Tener pocas limitaciones heredadas
A nadie le gusta desarrollar contra interfaces con errores, código basura, y modelos de datos mal diseñados. Un exceso de limitaciones heredadas mata la creatividad, requieren actas parlamentarias para modificarlas, y generalmente le quitan toda la diversión al desarrollo de software.

Si tu empresa tiene muchos sistemas malos que deben heredarse, intenta averiguar un modo de minimizar su impacto en los futuros desarrollos. Si no puedes, busca a gente que valore los factores de higiene, porque los desarrolladores con factores de motivación no van a mantener las mismas aplicaciones de baja calidad por mucho tiempo.

Calcular tu puntuación
Afrontémoslo, la línea está muy baja cuando se trata de motivar a los programadores. ¿Cuántas compañías conoces que cumplan siquiera tres de estos puntos? La mayoría de las empresas que yo conozco tendrían suerte de sacar un 1. Google probablemente tendría un 8 o un 9.

Consideraciones finales
Si eres un gerente, ¿cuándo fue la última vez que les preguntaste a tus programadores sobre estas cosas? Si eres un desarrollador, ¿cuando fue la última vez que planteaste respetuosamente alguna de estas cuestiones, dando ejemplos y posibles soluciones?

Si la respuesta es "hace mucho tiempo" o "nunca", entonces ambos tenéis trabajo que hacer. Manda este artículo a algunos de tus compañeros y empezad a hablar sobre cómo efectuar cambios.

Artículo Copyright © 2006 Rob Walling

Este artículo aparece originalmente en el blog Software por Rob: El lado humano del desarrollo de software.

Sobre el autor
Rob Walling es un programador .NET que vive y trabaja en Los Ángeles. Su blog, Software by Rob, es leído por 50.000 personas todos los meses; y habla sobre la contratación de programadores, técnicas de entrevista, técnicas de motivación, gerencia de proyectos de software y características de personalidad de los mejores programadores. Su empresa de consultoría, The Numa Group realiza desarrollo en ASP.NET para compañías en todos los Estados Unidos. Se puede contactar con Rob aquí.

---

Hasta aquí el artículo de Rob Walling, que he traducido con su permiso, y con el que estoy de acuerdo en casi todo. En un próximo post, mi punto de vista al respecto. Rodarán cabezas.