Las cosas son lo que se llaman

José Luis Marina, director de I+D de Peopleware, me ha pasado una referencia al post Job Titles vs. Job Descriptions vs. The Job del blog de Krugle en el cual John Mitchell reflexiona sobre la repercusión que el nombre de un cargo tiene sobre las funciones que se le atribuyen a posteriori.
Me ha llamado la atención porque cada vez estoy más preocupado por las palabras que empleamos y su significado. Las cosas que repetimos verbalmente una y otra vez las interiorizamos hasta el punto que pasan a formar parte de nuestro esquema de pensamiento.
He perdido la cuenta de las ocasiones en las que le he suplicado a los programadores que no digan palabrotas delante de los clientes, me refiero a cosas como «ñapa», «pete», «casque» y toda la pléyade de jerga informática para describir los inumerables errores de los programas.
Me pregunto en qué momento de la historia el Departamento de Personal se metamorfoseó en el Departamento de Recursos Humanos. Quizá intentaron enmendar la imagen de departamento que sólo se usa para pagar la nómina y despedir gente, cuando se puso de moda el coaching y la gestión por competencias. Pero a mi me gustaba más el termino «de Personal», me da la impresión de que la palabra «persona» lo hacía más humano que la palabra «recurso». Quizá por eso ahora las ETTs encubiertas de subcontratación de informáticos los tratan amenudo como recursos porcinos más que como recursos humanos.
Personalmente, hace tiempo solía tener un pequeño grupo de trabajo llamado Testeo y control de versiones. Como rara vez nos daba tiempo de probar en profundidad y había bastantes parches (±1 por semana) frecuentemente nos metíamos en problemas porque los implantadores se quejaban vehementemente de que no habiamos testeado nada. Luego le cambiamos el nombre a Control de Calidad para ver si dejaban de fastidiarnos con la monserga del testeo. Conseguimos convencer a los implantadores de que nosotros no estábamos alli para probar nada, pero el problema empeoró porque la gente empezó a quejarse de que los entregables eran de mala calidad. Cambiamos nuestro nombre de nuevo a Control de Calidad de Software para dejar claro que si el programa no hacía lo que se había pedido en las especificaciones no era nuestra responsabilidad sino la del jefe de proyecto. Al final, un tipo más listo que yo se hizo cargo del grupo y lo rebautizó como SQA (Software Quality Assurance). Lo bueno de SQA es que la gente de la calle no suele saber bien lo que significa; de modo que cuando reclaman es más fácil despacharles diciéndoles que se han equivocado de extensión. El jaleo de los sufridos usuarios continuó, por supuesto, pero desde entonces el departamento funcionó mejor y pudo ocuparse más eficientemente de sus tareas prioritarias con menos malentendidos externos.