Los roles en el desarrollo de software

A raíz de mi reciente incorporación al incipiente Centro Experimental del Conocimiento me ha venido a la mente el recurrente tema de los roles y las jerarquías en el desarrollo de software.

En developer.com han hecho una serie de artículos sobre los roles en el desarrollo de software. Una frase es especialmente reveladora sobre lo que creo que debe ser cualquier clasificación:

Developer (Dev) - The heart and soul of the process
Es una serie de artículos bastante interesantes, hablando no sólo de en qué consiste cierto papel sino en qué debes hacer si aspiras a ciertos puestos.

Al menos en mi alrededor a la gente que toma parte en el desarrollo de software se la clasifica en programadores, analistas, diseñadores y jefes de proyecto (obviando las divisiones transversales de becario, junior y senior). En paralelo a esta jerarquía existe la nube de comerciales.

Problemas

Esta división jerárquica tiene, en mi opinión, innumerables problemas. Primero enunciaré los problemas que veo, para acabar con mi propuesta.

El Principio de Peter
Las personas que realizan bien su trabajo son promocionadas a puestos de mayor responsabilidad una y otra vez, hasta que alcanzan su nivel de incompetencia.
A largo plazo se acaba en puestos para los que no se vale, símplemente porque el inferior se hacía bien. Sí, hay formas de mitigarlo, pero denota un problema de esencia en una organización jerárquica.

Ser programador no es fracasar

Hace poco me contaban de un ingeniero informático que se refería a otro prácticamente en términos de fracaso, símplemente porque está trabajando como programador. En la carrera muchos profesores nos educan que programar es una tarea de bajo nivel, sin interés, mecánica, indigna para ingenieros, apropiada para "la gente de módulos". Sólo estoy de acuerdo en una cosa: programar puede ser inadecuada para ingenieros, sí, pero porque han salido de la carrera sin saber programar ni hacer nada por intentarlo. Obviamente a esos les pondría delante de unos libros y un teclado, y les haría trabajar hasta que corrigiesen eso.
Hay autores que opinan que programar es automatizable (coincidencia o no, suelen ser vendedores de herramientas CASE). Yo me alineo con Robert L. Glass, que dice que el 80% del trabajo de programar es intelectual. Programar no es una tarea mecánica ni menor. Ser programador es un trabajo de responsabilidad, intelectual, que requiere dedicación, esfuerzo, autoexigencia y constante renovación. Tener buenos programadores es crítico para el desarrollo de un proyecto.
La jerarquía promueve la visión de que "lo que hay que conseguir" es salir de los puestos "inferiores" (programador) lo antes posible y "ascender" a puestos de mayor "responsabilidad" (y sueldo). Esto es simplista, erróneo e indeseable. Conozco programadores incapaces cuya único plan profesional es hacer tiempo en puestos de codificador hasta que el contador sea suficientemente grande como para que el mercado le promocione a analista. Yo no le quiero ni de programador, ni de analista.

Quiero desarrolladores, no programadores

La jerarquía hace que los programadores se conviertan símplemente en recursos que pican código, ¡tanto desde su punto de vista como desde el de sus "superiores"! La jerarquía les hace convertirse en personas sin responsabilidades, sin iniciativas propias, que no se implican en el trabajo de los demás, que no cuestionan los planteamientos...

Quiero trabajo en equipo, no delegación de la responsabilidad

El trabajo de un programador se limita a implementar la especificación de un diseñador. ¿Qué se consigue con esto?
  • Los programadores no se sienten con la responsabilidad de corregir el código de otros.
  • Los errores cometidos por los diseñadores no son corregidos, ya que nadie lo considera parte de su trabajo.
  • El trabajo de diseño lo hace una persona diferente al que realmente lo implementa (hecho #29 de "Facts and Fallacies of Software Engineering").
  • Se subcontrata el trabajo de programación, porque parece que no es importante, aunque al final lo que sucede es que las organizaciones dependen de subcontratas en sus herramientas clave, y el conocimiento adquirido se pierde al acabar el subcontrato.
  • Se acaba produciendo una separación entre los programadores, que se sienten minusvalorados, que no perciben formar parte de la organización, y el resto.
Si el modelo en cascada es erróneo, ¿para qué insistir en él?

Lo primero que te cuentan en Ingeniería del Software es el modelo en cascada, y lo segundo es que no vale como método de desarrollo. ¿Por qué insistimos en usarlo, directa o indirectamente? La jerarquía inicial no es más que el reflejo de esta metodología en el organigrama de la empresa.
En mi opinión, el proceso mental de desarrollo de software es en cascada, pero no se requiere de explicitación, de la misma forma que cuando se hace un modelo de datos se tienen en cuenta las formas normales pero no se explicitan.

¿Realmente respetas lo que implica la jerarquía en cascada?

Este tipo de jerarquías llevan implícito un orden numérico que suele obviarse. En un desglose tradicional del trabajo en cascada se asume que el nivel directamente inferior es numéricamente mayor: un jefe de proyecto, dos o tres analistas, cinco o seis diseñadores, diez o doce programadores... Esta organización puede tener un sentido cuando esto se respeta, y puede dar unas garantías que no dan otras, como que los analistas o diseñadores "firmen" partes del trabajo, asumiendo su corrección y adquiriendo su responsabilidad. Pero... ¿tu organización lo puede mantener? ¿Tiene sentido un proyecto en el que sus integrantes son un "analista" y dos "programadores"?

Reduce la versatilidad del equipo dificulta la gestión

Si alguien es programador no le pidas que haga de analista:
  • Le estarás pagando como programador pero estará asumiendo la responsabilidad de analista.
  • No tiene por qué asumir ese trabajo: no es analista.
  • Tendrá una visión de temporalidad de su trabajo.
Su uso refleja la inmadurez de la organización

Adoptarlo es una decisión que se adopta sin pensar. En mi opinión se adopta por los siguientes motivos:
  • Uso de metodologías en cascada (que no queremos, ¿no?).
  • Facilita la definición de la carrera profesional y salarial.
  • Situa a los comerciales en un punto muy elevado (cosa deseable, en mi experiencia, desde el punto de vista de los jefes).
Mi propuesta

No size fits all, así que un buen punto de partida es tirar a la basura la precondición de que la jerarquía es esa. Partiendo de eso...

Desarrolladores, no programadores, ni analistas, ni diseñadores

Un mismo miembro del equipo debe desarrollar su habilidad en todas las técnicas implicadas en el desarrollo. Además, adoptando el principio de desarrollo ágil de propiedad colectiva del código y extendiéndolo a cualquier otro producto del desarrollo, todos deben implicarse en el desarrollo, corrección y evolución del código, análisis y diseño.
Por otra parte, no me valen analistas que no saben programar. Deberíamos estar en una de esas condiciones que "nunca suceden", pero en la práctica sí hay analistas "puestos". Aunque el rol de analista funcional está ahí y es importante, sólo es un rol, no una responsabilidad ni una persona concreta. Lo mismo ocurre con el de arquitecto de soluciones (diseñador).
PD: aquí "análisis" y "diseño" no son las fases del modelo en cascada, sino las técnicas que se llevan a cabo para la resolución de ciertos problemas funcionales o técnicos ;)

Separa las condiciones contractuales de tu rol en los proyectos y en la organización

Si alguien es un buen desarrollador y está a gusto en ello, debe poder desarrollar toda su vida profesional como tal. Haz que un desarrollador pueda comenzar en tu empresa como becario o junior pero que pueda desempeñar ese mismo trabajo durante años, y que su contrato mejore en consecuencia. ¿Por qué un gran programador que lleva muchos años en la empresa no puede cobrar más que cualquier comercial? Permite un cambio de rol si él quiere y realmente vale, pero no lo impongas como necesario para mejoras contractuales. Esto conseguirá que los desarrolladores estén realmente motivados: verán su trabajo recompensado, tendrán responsabilidades...

Implica a las personas, no a los roles, en las decisiones clave de la organización

¡Haz que él también lo sepa! Tenle en cuenta a la hora de tomar decisiones técnicas. Que sepa que su papel en la organización no es sólo codificar.

¿Es esto válido en cualquier caso?

No, no size fits all. En el fondo estas ideas están fuertemente influenciadas por mi trabajo en aplicaciones web y de gestión, y en mi convencimiento de que una metodología de trabajo ágil es lo mejor en la mayor parte de los desarrollos. Siempre digo lo mismo: algo así no vale en todos los casos. Por ejemplo, si piensas desarrollar el software para poner un satélite en órbita, necesitarás un proceso muy estricto en el que las especificaciones pasen por muchas manos para asegurar su validez y determinar las responsabilidades.
Pero no ponemos satélites en órbita a diario. Creo que por defecto la organización debería reflejar las tendencias de los últimos años, y relegar las tradicionales a campos en los que son más adecuadas.

Posted by Juan Ignacio Sánchez Lara 17:07  

6 Comments:

  1. Blaxter said...
    ¡Muy buen post! Siempre he opinado que el sistema piramidal no tiene ni pies ni cabeza, y a pesar de ello es el más usado por muchísimas empresas (las cuales en su mayoría suelen llamarse cárnicas :P). Lo que me sorprende es que consigan sacar proyectos adelante con esa filosofía.
    Nacho said...
    Cierto, un montón de veces comentamos que "el problema es que al final salgan las cosas".
    Estoy convencido de que haciendo las cosas bien se puede ganar mucho más dinero, pero dando a la gente un buen trabajo, un buen contrato y una buena carrera...
    Joserra said...
    Estoy bastante de acuerdo contigo. La mejor organización por roles surge directamente de los equipos autogestionados. El que más sabe se lanza a tomar decisiones en su nivel, los demás aprenden. Cada uno sigue su propio camino, ganando experiencia en areas diferentes, y ganandose el respeto del resto del equipo.
    Alberto Domínguez said...
    Totalmente de acuerdo con la problemática que expone en su artículo, sin embargo creo que la solución planteada es pobre -sin ofender. Sería excelente que trabajara un poco más en el tema de la dignificación de la labor de programación.
    Nacho said...
    Sin duda la solución es pobre en muchos aspectos, no pretendía realizar un ensayo concienzudo. De todas formas, concretamente he escrito tanto sobre dignificar la labor del programador (no sólo en "dignificarla", realmente, sino en decir que es lo más importante) que no me quería repetir. Muchos de los posts escritos con anterioridad se centran precisamente en eso. Para la próxima meteré más enlaces, por aquello del DRY ;)

    PD: ¡no me ofendo! Muchas gracias por el comentario, ¡se agradecen las críticas!
    cocorossello said...
    Ufff que cierto es todo esto y que rabia me da que se hagan las cosas piramidales.

    Siempre he opinado que un desarrollador tiene que estar implicado en todas las fases... desgraciadamente es muy difícil encontrar un trabajo así. Normalmente todo se simplifica a "comerte todos los marrones" que te sueltan los analistas o arquitectos de software (categoría inventada en mi opinión).

Post a Comment