¿Por qué los managers y analistas ganan más que los programadores?

En los sitios de stackexchange.com de vez en cuando aparecen respuestas que son verdaderas joyas. Es el caso de la respuesta a la pregunta título de este post, de la cúal presento a continuación su traducción:

El que los managers tengan mejores salarios que los programadores y el que los analistas de negocio existan depende completamente del mundo de desarrollo software en el que vivas.

Una respuesta simple a esta pregunta sería: “porque en nuestra sociedad, aún pensamos que el salario está sujeto a la posición en la jerarquía”. Pero esta respuesta no explica  por qué los PM (Project Manager) o los BA (Business Analyst) están en la cima de esta jerarquía ni por qué se eligen jerarquías en primer lugar como la manera de estructurar la mayoría de los equipos de desarrollo. Estas son las preguntas en verdad importantes.

Existen, grosso modo, dos tipos de organizaciones de desarrollo de software. Yo les llamo Manufactureras y equipos cinematográficos (film crew).

Las manufactureras nacen de la escuela de pensamiento caracterizada por la teoría X propuesta por McGregor: Los empleados son flojos y requieren de control y supervisión constantes; los trabajos se mantienen solo por la paga; los managers son siempre capaces de hacer el trabajo de sus subordinados incluso mejor que ellos. De esta forma de pensar surge naturalmente la idea de que un equipo entero puede ser fácilmente representado por el manager, después de todo, todos los demás en el equipo son reemplazables y están ahí solo para ayudar al manager a completar tareas. De aquí viene la jerarquía como la forma de organización estándar.

La gerencia en las manufactureras opera bajo el supuesto de que el software puede ser manufacturado a partir de una especificación preparada por un analista de negocio y mediante proceso definido  ejecutado bajo supervisión del manager. El éxito de este proceso se asegura supliendo al proyecto de suficientes recursos calificados aunque intercambiables.

Es fácil identificar este esquema poniendo atención en el vocabulario de las personas. Comúnmente hablan de “recursos”, procesos, eficiencia de la operación, repetibilidad, control estricto en el uso de los recursos, e insumos y productos definidos. De vez en cuando mencionan la metáfora de la “fábrica” cuando tratan de comunicar la imagen de un equipo de desarrollo ideal desde su punto de vista.

También existen los “equipos cinematográficos”. Estos están basados en la noción de que la gente es inteligente, auto-motivada, trabajadora y que realmente disfruta su trabajo. Los equipos cinematográficos, reconocen que, debido a la especialización, las habilidades individuales pueden sobrepasar las habilidades del equipo que coordina y dirige el trabajo. Dado que un manager no puede substituir a cualquiera, la estructura jerárquica ya no funciona. La gente debe cooperar dentro de una estructura más plana para llevar a cabo el trabajo. Los roles en si tienden a ser mucho más verticales, involucrando una amplia variedad de habilidades. Esta escuela es identificada por la teoría Y de McGregor.

El director de un equipo cinematográfico, sabe que su visión acerca de un proyecto solo puede volverse realidad si es capaz de integrar un magnífico equipo y ayudar para que sus integrantes trabajen bien entre sí. Su rol es inspirar, transmitir su visión, proveer dirección y enfocar esfuerzos. Cada persona importa ya que el director cree que el software resulta de la combinación de las habilidades de todos los participantes y la forma única en que el grupo lleva acabo el trabajo conjuntamente. Todo mundo reconoce desde el principio la importancia de que “estrellas” se unan al equipo. Los trabajadores “estrella” incrementan las posibilidades de éxito.

En cuanto a la remuneración, las manufactureras ven en el trabajo del manager y los analistas de negocio el mayor valor aportado al proyecto. El resto del equipo no importa mucho mientras tengan las cualidades para convertir los requerimientos en código. Los PMs y BAs trabajan duro para mantener su posición como líderes restringiendo el libre acceso a las fuentes de información. Sin acceso formal a las fuentes de información primarias, al equipo se le dificulta tomar buenas decisiones o proponer buenas soluciones. Los programadores son relegados a tomar ordenes de arriba y trabajar en el problema como lo definen el PM y los BA. Esta situación refuerza la noción de los programadores como trabajadores de fábricas capaces solo de llevar a cabo tareas que, aunque son técnicamente complicadas, son mecánicas.

En contraste, los equipos cinematográficos actúan con una formación más igualitaria; a los miembros se les da acceso irrestricto a la fuente de información primaria, se les impulsa a hacer aportaciones valiosas y son libres de elegir el curso de las acciones a tomar. La estructura de liderazgo se basa en las habilidades de las personas y no en su rol específico. La compensación económica refleja qué tan deseable es el que una persona específica se una al proyecto. En este ambiente el rol de manager se vuelve menos prominente ya que es difícil que este sea el líder creativo; el rol se vuelve más propio de soporte administrativo y relaciones externas. Los deberes de los analistas de negocio son reemplazados en parte por el visionario (director) y en parte por los demás miembros del proyecto.

No sorprende que la mayoría de los proyectos internos y o a través de consultorías funcionen con el modelo de manufacturera produciendo software monótono de manera constante; son estos ambientes en donde los managers y los analistas son continuamente mejor pagados que los programadores basándose en el supuesto de que ellos aportan el mayor valor,  trabajando con un equipo estructurado de manera tal que les es más difícil a los programadores probar lo contrario.

Las empresas de software exitosas tienden a adoptar el punto de vista de los equipos cinematográficos. Otra filosofía no les permitiría atraer a las personas talentosas en las que se basan para producir buen software. Es difícil ver el rol de analista de negocio en este tipo de proyectos, los managers tienen un rol mucho menos prominente y sus salarios son usualmente más bajos que los de algunos programadores.

Respuesta de Totophil.

23 comentarios en “¿Por qué los managers y analistas ganan más que los programadores?

  1. Si es X o si es Y depende de que tipo de producto se está elaborando.

    Si es una fábrica textil, sería poco razonable esperar que el costurero tenga gran inventiva y acceso irrestricto a los diseños que se están elaborando y/o que ganara tanto o más que el manager.

    Si una agencia de diseño, será natural que el diseñador principal gané más que el gerente del lugar.

    Supongo que será cuestión de saber que tipo de software estamos desarrollando.

    Me gusta

    • Correcto. Desde luego hay casos en donde es muy claro si debe ser X o Y. Pero en desarrollo de software yo creo que debería ser siempre Y. Considera el supuesto de la teoría X de que los managers son capaces de hacer el trabajo de sus subordinados si así lo deciden. En mi experiencia, cuando he tenido managers que son buenos programadores, los proyectos han salido con buenos estándares de calidad. Pero, ¿Cuántas veces sucede esto? La verdad es que casi nunca. Y, aún cuando esto sucede, dichos managers dejan de programar y en unos años ya no tendrán idea de lo que ocurre y se dejará de cumplir esto. Tal vez pudieras defender que en proyectos muy sencillos (que tal vez son la mayoría) se justifica el modelo X, pero la verdad es que aún en proyectos muy sencillos los estándares de la industria de desarrollo en México son pésimos.

      Me gusta

    • Podrías dar ejemplos de tipos de software ¿? en donde la teoría X sería mas adecuada?

      Creo que independientemente al tipo de software ¿? (no me cierra este concepto) el trabajo creativo de los programadores es el mismo por lo que en mi opinión la teoría Y es la mas adecuada en todo sentido.

      saludos!

      Me gusta

      • Armin: Estoy totalmente de acuerdo contigo. En desarrollo de software siempre debería ser Y. Yo me refería a que en otras industrias podría ser más razonable X. Por ejemplo, en una empresa de limpieza si creo que un manager pueda ser capaz de hacer el trabajo el mismo si quisiera, y por lo tanto, considero que puede estar calificado para la toma de decisiones e incluso que pueda ser considerado más valioso que sus trabajadores. Una pregunta fundamental para saber en qué escenario tiene sentido X es: ¿Es el manager capaz de hacer el trabajo de sus subordinados?

        Me gusta

    • No estoy de acuerdo con tu Generalización, hablas de industria textil, o agencia de diseño. Pues bien, en el caso de la industria textil asumimos que la teoría X aplica mejor, en el caso de la “industria del software” podemos asumir que la teoría Y es la mejor, no creo que la distinción de “tipo de software” sea equiparable con el tipo de industría..

      Saludos!

      Me gusta

    • Soy Business Analyst y creo que ganamos mas porque si el proyecto de TI fracasa es responsabilidad del analista ya que no definio bien los requerimientos y no realizo bien su labor (alcance, requerimientos incorrectos, etc), en cuanto al manager, si el proyecto no se termina en tiempo y rebasa presupuesto, etc. es responsabilidad de él.

      En concusión los desarrolladores, tester, etc. solo reciben instrucciones de “QUE” se va a hacer y lo hacen, los Analistas de Negocio tienen que “DEFINIR” la solución y los Manager le dan seguimiento al proyecto para que se cumpla.

      Me gusta

  2. Me ha gustado el artículo y la verdad creo que esto se debe más que nada a que, desde la escuela y familia, nos inculcan esa cultura de un lider de proyecto y donde todos acatamos las órdenes a veces sin preguntar, u otras preguntando (y en el caso de la familia) la respuesta es “porque yo lo digo”, creo que para que pudieramos entrar en la teoría Y, habría que hacer un cambio de cultura en los estudiantes, así como también entre los programadores, sin embargo esto muchas veces depende de los jefes o dueños de las empresas donde, ellos son los que pueden llegar a dictar los lineamientos de desarrollo.

    Me gusta

  3. Excelente. Por eso en el caso de Sistemas, funciona muy bien el desarrollo a traves de proyectos personales. O sea personas con intentiva, que motivadas por la idea, la resolución, el logro personal y el exito financiero, ponen su propia consultoría o empresa y generan un proyecto de empresa y/o ofrecen el servicio por afuera de las estructuras.
    Siempre mientras estés dentro de una estructura se balancea por la mediocridad. La gestión de un proyecto propio te hará trascender del entorno. Facebook, Google, MercadoLibre, Axsoft, son muy buenos ejemplos.

    Me gusta

  4. Por el tipo de mi trabajo yo hago las dos cosas. Mi experiencia es que el analista tiene que hacer el diseño, un diseño que será mejor o peor en función de su experiencia como analista, de su conocimiento del sector al que va dirigido y un largo número de etcéteras que no puedes aprender ni en un módulo, ni en una carrera ni tampoco buscando en google. Y es cierto, tienen la responsabilidad de cara al público si algo sale más es el manager quién da la cara y sino fijémonos en un equipo de fútbol, si las cosas no funcionan cambian al entrenador no a los jugadores.
    Con todo esto no quiero ni por un segundo despreciar la tarea del programador, ya que son las personas que trasladan las ideas a algo tangible y por tanto su labor es tan importante como la del manager, son complementarios.
    Bajo mi punto de vista, dado que el manager es quién se juega el puesto de trabajo si algo sale mal, y en general las retribuciones van en función de la responsabilidad que uno tiene, no me parece descabellado que su sueldo sea superior al de los programadores aunque, pienso que esta diferencia no debería ser desorbitada como ocurre en muchos casos.

    PD: Eso de que en Microsoft no hay managers ni analistas no es cierto 🙂

    Me gusta

      • [Interesante artículo en plan Hobbes-Rousseau]

        Yo si lo sé, porque trabajo en Microsoft. 🙂

        Hay desarrolladores que cobran muchísimo mas que un PM (en nuestro caso Program Manager). Hay una gran carrera dentro de tu disciplina. Puedes ser un Developer toda tu vida y tu sueldo irá aumentando sin techos. Conocemos a muchos Developers que cobran muchísimo mas que un Manager.

        Es mas, en un “proyecto”, el PM no es tu jefe, tu jefe es el Developer Lead, que te evalua y tiene seguimiento de tu trabajo semanal. Este se basa en el feedback de los PM con los que trabajas, de los Developers, Testers, y el suyo propio para evuluar cómo de bien estas realizando tu trabajo. En caso de no trabajar bien, es responsabilidad de tu Lead el ponerte un plan de trabajo y ayudarte a mejorar. Y tu responsabilidad es acatarlo.

        Pero esto es resumiendo mucho, porque el sistema de Microsoft es complejo, pero da gusto trabajar, al menos en EEUU.

        Me gusta

  5. No son equiparables ni de lejos el futbol y el desarrollo software, de hecho no se puede encontrar una comparacion de mundos mas distintos porque en un equipo de futbol si las cosas van mal cambian al entrenador pero en un proyecto de software si las cosas van mal cambian a alguno de los programadores. Ademas en un equipo de futbol es facil encontrar jugadores que cobran mas que el entrenador e incluso a veces mas que el presidente…

    Precisamente la jerarquia establecida en el modelo de las charcuteras permite que cada escalon se cubra las espaldas respecto a sus jefes dejando con el culo al aire a las jerarquias inferiores sin que estas se puedan defender o por lo menos dejar las cosas claras.
    A parte no creo que un programador que sabe leer unas especificaciones no sepa tambien hacer su propia toma de requisitos y sus propios analisis.

    Me gusta

  6. Esto es en respuesta a Vero:

    Yo no se que experiencia tienes, pero claramente no mucha. La analogia con los entrenadores no tiene sentido. Si a los entrenadores se les echa antes, en parte, es porque ganan menos.

    Aparte, cuantos jefes has visto tu que asuman responsabilidades?? Cuantas veces has escuchado un jefe entonar el “mea culpa”?? No lo hacen, porque ellos no tienen “errores”, dado que no escriben código. Y los errores de planteamiento no son visibles a la hora de los pases a produccion, sino que es visible si hace lo que debe, o no.

    en general, la tonica es que el menos responsable es el responsable.

    Me gusta

  7. Excepto en compañías totalmente tecnológicas, los desarrollos se producen por requerimientos del negocio. Estos son identificados por los analistas de negocio que especifican el qué se necesita a los funcionales o técnicos. Los analistas de negocio son los que causan estos cambios, mejoras para que el negocio tire más fuerte y por lo tanto dé más beneficios. Por eso ganan y deben ganar más que los técnicos.
    Los PM, bueno, se encargan de hacer que las cosas ocurran. A veces no se justifica tanto su salario, ya que hay proyectos que salen solos o salen por el esfuerzo de los ténicos, no la motivación promovida por los PM.
    De todas formas, aunque sí, muchas veces los técnicos son más listos que los de negocio,las cosas claras, el negocioes lo que mueve la compañía. Tecnología o desarrollos son supeditados al negocio, por eso por brillante que sea un informático nunca se le valorará como alguien que sepa el negocio.

    Me gusta

    • Me parece que el término “técnico” presupone de entrada lo que se quiere demostrar. Al nombrar “técnico” a un programador, lo equiparas con el técnico que cambia una tarjeta de memoria en tu PC o al técnico que configura tu impresora. Al final, consideras al programador como un recurso intercambiable, por lo que el resto del comentario viene a reforzar esto sin justificar por qué lo consideras como recurso intercambiable.

      Me gusta

  8. En respuesta a dash_27: ni puñetera idea de lo que cobran en Microsoft ni unos ni otros, únicamente lo comentaba porque lo que sí se es que existen esas figuras.

    En respuesta a Mario y Felipe: pues no de momento no mucha, 5 años, que respecto a la vida laboral que nos espera es una miseria. La equiparación con el fútbol no creo que sea tan descabellada, en el sentido de que cuando algo no funciona, cambian al dirigente y no al equipo. Que sea porque eso es más barato pues no lo sé, yo lo que veo de fútbol (que he de confesar que no es demasiado) es que cuando cambian el entrenador, en muchas ocasiones cambia la tendencia que llevaba el equipo y además, siempre lo cambian en malas rachas nunca si van ganando por eso la analogía. Pero vamos que quizá si conociera mejor el mundo del fútbol, a mí la comparación también me pareciera descabellada.

    Respecto al resto, para Mario decirte que la mayoría de programadores son capaces de hacer una elicitación de requisitos. Si has llegado a esa conclusión a partir de mi comentario es que no me he expresado bien. Lo que quería decir es que, al igual que un programador experimentado probablemente trabajará más rápido y mejor que uno menos experimentado, un analista también.

    Respecto a lo que dice Felipe, no he tenido muchos jefes por el momento y hasta ahora todos ellos han sido personas accesibles que han sabido reconocer cuando se han equivocado. A lo mejor, si esta fuera la tónica general nos iría mejor a todos, pero está claro que no lo es.

    Saludos.

    Me gusta

  9. Incontenible leer esto y no comentar, primero, gracias por su traducción y segundo gracias a los que participan en el debate por que es super enrriquecedor.

    Les contaré mi experiencia, yo trabaje en casas de software donde trabajabamos por proyectos y teniamos varios clientes diferentes, conocer mucho de un negocio podia pasar pero era dificil si eras de los que te rotaban siempre. Sin embargo adhiriendome al tema, basicamente eran los analistas de negocio los que sabian con claridad su necesidad, hacian las solicitudes y debian cumplirse como lo decian, por supuesto habian muchas sugerencias de mejora, a veces las aceptaban a veces no.

    Luego trabaje para proyectos internos en software generico en un equipo de investigación y desarrollo. El ambiente genial y aunque habia una estructura chevere tipo Y, los salarios eran como la X y al inicio con el buen ambiente parecia no importar, el mismo jefe sabia y no se involucraba pero generaba un muy buen ambiente y queria sacar lo mejor de cada uno, con el tiempo dar lo mejor y no recibir mejor retribucion se vuelve un problema, cuando todos empezamos a pensar en ello, el equipo se desmembro, la empresa al ver que salimos la mitad, al fin entendio, hoy mis compañeros que se quedaron ganan mucho mejor que antes y tienen muchos beneficios.

    Hoy soy analista de negocio en una empresa grande, llevo mucho tiempo tratando de conocer el negocio y aun no termino de hacerlo, y aunque tengo claro mi gusto e inclinacion por buenos equipos de trabajo (Y), tambien hoy entiendo la diferencia, por lo que si me parece que no es por que sea mas adecuado o no X o Y, si no que segun el escenario eso se da, y los tecnicos son proveedores que si bien deberian involucrarse mas en el negocio, no alcanzan a hacerlo por diferentes factores, situación que a uno como analista de negocio si le toca y aun mas, le toca poner la cara, por que los tecnicos lo hacen y adios, uno es el que queda como responsable, Microsoft, Google por mencionar, no hacen software para nadie, trabajan para si mismos, potenciar todas sus capacidades al maximo, orquestar todo eso, debe ser genial, yo soy astante tecnica, amo la programación y la arquitectura de software, y he querido continuar siendolo a pesar de ser analista de negocio, pero es increible, la forma como el negocio te consume… la operacion, el dia a dia, los problemas, la gestion de proyectos, te consume a un punto donde tu conocimiento tecnico se queda guardado si no lo desenpolvas, y toca conseguir proveedores.

    Esa es mi experiencia, el post esta super, que chevere que la gente que trabaje con uno siempre sea de los que no hay que empujarlos para hacer las cosas, pero eso por ejemplo, con buen dinero beneficios y todo, aunque no lo crean, no se da siempre, parece que hay gente que lo que siempre necesita para trabajar es alguien respirandole encima, y ahi ya no hablamos de tema de empresa, tiene que ver con la personalidad de cada uno.

    Éxitos a todos.

    Me gusta

  10. Siempre es necesario un guionista (Business Analist)que escriba un guión,pueden ser una o dos personas, no más.
    El guión hay que llevarlo a la pantalla y organizar todo el cotarro, es decir , el diirector (Project Manager), luego están los actores (Programadores) que son los que ponen en escena ese guión. Está claro que el director en todas las ocasiones es el que da el visto bueno a cada una de las escenas (Partes de que consta una aplicación), etc, etc.
    Todas las partes son muy necesarias, el problema estriba solmanente en la cantidad de dinero que se embolsan unos y otros y aquí es donde estriban las discrepancias. Bajo mi punto de vista, un PM tiene que tener una serie de cualidades importantes, sobre todo de liderazgo y saber tratar con las personas (siempre seres humanos y no objetos de negocio), además tiene que tener muy claro qué es lo que quiere el cliente para saber ofrecer al final un producto único, fruto del trabajo técnico de los programadores. Por todo esto creo que la pirámided salarial debería ser: 1º el Project Manager, 2º el Programador y por último el Analista. Hay que reconocer que es más difícil encontrar buenos PM que programadores y por tanto hay que pagarlos bien para retenerlos.
    Si alguno de los que navegáis por aquí habéis tenido un buen PM sabréis de qué estoy hablando, el resto no lo sabe, pero el día que trabajen con un auténtio PM, verán que tengo razon.

    Besos y abrazos

    Me gusta

  11. Muy buen articulo. Y aunque la teoría “X” sea (al parecer) mas adecuada en muchas organizaciones, la teoría “Y” debería ser la ‘estándar’. Aunque el gerente pueda hacer todo el trabajo de sus subordinados (que idealmente debiese ser así), de ser así deberían contratar 5 gerentes, en vez de 1 gerente, 2 analistas, y 7 programadores. Es cierto lo que se dice en los comentarios, que es lo ideal. Aunque el gerente pueda hacer el trabajo, ahora es gerente, con otras responsabilidades y probablemente cayendo bajo otras ramas. Ya ha dejado de ser programador, por ende no puede hacer el trabajo del programador eficientemente. Para mi que esas compañías que usan la teoría “X”, no solamente cuando se trata del desarrollo del software, son solo vagas, buscando el atajo, y llegando a la falta de control en la organización e hierarquía.

    Me gusta

  12. Muy interesante! Soy programador y he trabajado en empresas manufactureras. Recientemente me ha estado rondando la idea de convertirme en PM, aunque no me gusta, obviamente porque son mejor pagados. Tengo la esperanza de encontrar una empresa con el modelo cinematográfico, aunque siento que son muy pocas.

    Me gusta

  13. Ampliando el tema, recomiendo la siguiente lectura: “The Hacker Ethic” de Pekka Himanen, y primer capítulo escrito por Linus Torvalds.

    Básicamente, plantea un cambio en el paradigma económico que rige tanto al ambiente laboral del software como en términos generales de la sociedad. En esto, incluye el no ver las cosas desde la perspectiva ni del dinero ni del tiempo que se está empleando para trabajar, sino desde motivaciones diferentes (de ahí el título de ‘ética’, como planteamiento de la ‘escala de valores’ de los hackers).

    Me gusta

  14. Como todo lo relacionado al software la palabra precisa es “depende”, creo en mi humilde opinión, nadie se quejaría que un buen PM, responsable, inteligente y justo, gane más en una escala X o que un analista de negocio bueno y proactivo gane muy bien, es más creo nadie se quejaría si un buen desarrollador (Programador) gane más que un PM si este programador es bueno, tiene experiencia y es muy inteligente. Todos discuten como defendiendo su posición, creo que cada uno debería preguntarse soy un buen PM para ganar más que un desarrollador? soy buen analista de negocio como para ganar más que un PM? o soy un excelente programador para ganar más que el PM? creo que no es dable decir me deben pagar más porque doy la cara, vamos hombre alguien que tenga los huevos necesarios puede dar la cara y ganar mas, no necesariamente un PM, la gran mayoría de PMs no saben ni programar ya que nunca pasaron por eso (que es súper malo) o que quedaron en la vieja escuela (No te actualizaste). Si eres un desarrollador y quieres ganar más que un PM, pues empieza a buscar empresas con una escala “Y”, algo más lineal donde te valoren, si eres un buen PM te va a ir mejor en sitios de escala “X” pero vamos si eres realmente bueno e inteligente siempre sabrás ubicarte en alguna escala así seas PM, analista o programador.

    Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s