Autor en Google+
Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET, ASP.NET Core, MVC, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

10 años online 🎂

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET, ASP.NET Core, MVC, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
domingo, 1 de febrero de 2009
Borrar... borrar...Cuando me topé por primera vez con el término NNPP (siglas de "Net Negative Producing Programmer") no puedo negar que me hizo cierta gracia. Cuanto menos, resultaba curioso pensar que podían existir desarrolladores cuyo saldo en las aportaciones a un proyecto resultara negativo, o lo que es lo mismo, que el valor de su producción fuera superado por el coste de los errores y defectos que introducían en las aplicaciones. Y con el término "desarrolladores" no me refiero exclusivamente a programadores; el concepto es válido para analistas, arquitectos, testers, o cualquier otro rol relacionado con la construcción de software.

Aunque seguro que todos hemos trabajado con profesionales que consideramos desastrosos poco habilidosos en la ejecución de sus tareas, probablemente no hayamos reflexionado lo suficiente sobre el impacto que tiene esto en un proyecto, y el coste final que clientes, nuestra empresa, o nosotros mismos tenemos que asumir en muchos casos. Es en este momento cuanto la existencia de NNPPs deja de tener gracia.

Y eso mismo debió pensar G. Gordon Schulmeyer cuando escribió, a principio de los 90, el paper "The Net Negative Producing Programmer" para la publicación American Programmer (hoy en día Cutter IT Journal), en el que se describía detalladamente qué son los NNPPs, cómo podemos reconocerlos, los motivos de su existencia, y los posibles remedios a aplicar cuando se detectan en un equipo de trabajo.

Según se manifiesta en este documento, los NNPP no son casos extremos. De hecho, en un equipo de diez desarrolladores pueden existir desde uno hasta tres NNPP, lo cual no es ninguna tontería: entre el 10 y el 30% del equipo de trabajo podría estar contribuyendo de forma negativa al éxito del proyecto. En otras palabras, en lugar de desarrollar estarían desdesarrollando, si me permite el amigo Andrés Panitsch que le tome prestado brevemente el nombre de su genial blog.

Aunque pueda parecer lo contrario, la detección objetiva de los programadores con producción neta negativa no es sencilla. Schulmeyer propone la utilización de un modelo de comportamiento donde se evalúen, al menos, las habilidades para:
  • escribir un programa
  • encontrar y depurar errores
  • ampliar un software para adaptarlo a nuevas necesidades
  • adquirir nuevos conocimientos técnicos
  • comprender un determinado problema

Salvo el último punto, de ámbito más abstracto, existen métricas que ayudan a determinar hacia dónde se inclina la balanza cuando comparamos la productividad de un desarrollador con su ratio de introducción de defectos en el software. Sin embargo, además de los aspectos técnicos, existen impedimentos éticos, y a veces incluso legales, que impedirían la obtención de conclusiones directas a partir de registros de actividad.

Pero probablemente, para poder detectar y evitar la aparición o proliferación de NNPPs en las organizaciones es importante conocer las causas de su existencia. Un estudio citado en el artículo revela causas como la insatisfacción en el trabajo, identificación e implicación nulas con el proyecto, percepción de escasa relación entre profesionalidad y recompensa, y falta de profesionalidad. Es obvio que, transcurridos quince años, siguen siendo válidas hoy en día; y curioso que muchas de ellas sean más atribuibles a la compañía y sus gestores que a los propios profesionales sospechosos de producir en negativo, normalmente por utilizar políticas restrictivas, estresantes, opacas y poco motivadoras para su personal.

La solución para estas situaciones pasa, en primer lugar, por realizar un análisis introspectivo de las condiciones de la organización. Mejorar la comunicación y el establecimiento de objetivos claros y comunes para un equipo de trabajo, por ejemplo, es una medida que puede mejorar bastante la implicación en un proyecto; o la recompensa -no necesariamente económica- por la consecución de objetivos puede incrementar la motivación y autoestima del grupo, y redundar positivamente en la producción.

Respecto al desarrollador, salvo en casos donde existen problemas estructurales graves como la falta total de vocación o capacidad, existen diversas vías para reconducir la situación.

TerapiaUna de ellas es mediante la comunicación entre las partes, algo así como organizar sesiones de terapia, reuniones donde la empresa pueda exponer al trabajador los hechos objetivos y los resultados de su comportamiento, y escuchar atentamente las motivaciones y argumentos de éste.

A veces, la producción negativa es un simple reflejo de actitudes desorganizadas, procrastinación, socialización excesiva, no finalización de tareas, estrés constante, falta de información, y otras muchas. Estas sesiones pueden servir para dar con las causas y acabar con la baja productividad de forma rápida.

Otra posibilidad para solucionar los problemas de productividad es la reasignación, el cambio hacia tareas más acordes con las habilidades y puntos fuertes de la persona. Por ejemplo, un NNPP dedicado habitualmente a la codificación podría convertirse en un buen verificador, o documentador, haciendo que sus aportaciones al proyecto pasaran a ser de signo positivo.

El último recurso es la destitución, que debería aplicarse únicamente una vez agotadas alternativas, digamos "menos violentas", como las citadas anteriormente. Lo normal es que un aviso lo suficientemente claro baste para despertar a cualquiera de su letargo, y no sea necesario llegar a mayores.

En cualquier caso, no cabe ninguna duda es del alto coste de los programadores con producción negativa neta. Un retraso en un proyecto o el lanzamiento de productos defectuosos puede tener un impacto terrible en la imagen de una empresa, y en el peor de los casos, hasta puede ocasionar desastres de magnitudes considerables. Y por no hablar de consecuencias internas, como la ruptura de la cohesión en equipos de trabajo, disminución global de productividad, aumento de desconfianza del grupo, incremento de costes, y un largo etcétera.

Semanas atrás Jay Field hablaba también de efectos nefastos para la propia industria del desarrollo de software, porque estos profesionales podían llegar a frenar el avance y la introducción de nuevas tecnologías, e incluso del terrible daño que se puede causar a las próximas generaciones de desarrolladores que durante su proceso de formación y adquisición de experiencia sean puestos a cargo de NNPPs.

Lamentablemente, los desarrolladores con producción neta negativa están aquí para quedarse. Tendrán hueco siempre que existan empresas donde no se cuiden detalles como el ambiente de trabajo, la transparencia, la comunicación, no se fomente la implicación y motivación del trabajador, o cuyos criterios de selección de personal consistan en elegir siempre a los profesionales de menor coste.

Enlaces:

Publicado en: www.variablenotfound.com.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

5 Comentarios:

Julio Trujillo Leon dijo...

Interesante estudio. El remar para atrás en lugar de hacia delante es algo que sucede de una forma mucho más habitual de lo que parece, lo verdaderamente humano es al detectarlo corregirlo (transformar a esas personas(s), no darles una patada, ese es el camino fácil) me imagino que el ambiente entonces es idílico, el pasar por malos momentos para luego todos juntos regresar a los buenos tiempos es algo que debe enorgullecer a sus responsables.

AcP dijo...

¡Uf! Que en principio quería saludar y agradecer el vínculo y el elogio...

Luego comentar el artículo que me ha gustado mucho (buenas referencias sobre todo) y en eso estaba cuando me dí cuenta de que ya había escrito demasiado (suele sucederme cuando comento algo que me gusta)...

Así que te continúo el tema en mi blog. :-) Nos leemos!

José M. Aguilar dijo...

Gracias, Julio, me alegra saber que te ha parecido interesante.

Gracias también, Andrés, por comentar y continuar profundizando en tu blog. Y créeme, el vínculo y elogio son merecidos. :-)

Un saludo.

lboisset dijo...

Muchas gracias! Muy interesante artículo. Me quedo con una duda ¿Cual es la base de tiempo para la medida? Hablas de retrasos es los proyectos, etc. Pero tengo en la cabeza algún caso de cumplimiento de fechas al que luego siguieron 2 años de arreglos del desaguisado. Es el caso del "experto" del equipo que no es que sea malo, es muy bueno, pero trabaja solo.

Aunque quizá eso sea un problema de la organización. ¿no?

José M. Aguilar dijo...

Hola, Luis. Ante todo, gracias por comentar.

En mi opinión, el retraso de un proyecto no tiene por qué ser indicativo de la existencia de NNPP, de la misma forma que el cumplimiento de plazos tampoco implicaría su ausencia. De hecho, las métricas que comentaba Schulmeyer contemplaban la observación tanto de la productividad (líneas de código, documentación, etc.) como de la introducción de defectos (bugs por líneas de código, por ejemplo).

Respecto al caso que comentas, probablemente se trate de un problema organizacional. Si el desarrollador es objetivamente bueno, quizás habría que preguntarse qué tipos de agujeros eran los que salieron después, y analizar sus causas.

Un saludo.