¿Por qué los analistas de negocios y los gerentes de proyectos obtienen salarios más altos que los programadores? [cerrado]

Tenemos que admitir que la programación es mucho más difícil que crear documentación o incluso crear un diagrama de Gantt y pedir progreso a los programadores. Entonces, para nosotros que somos ingenuos, sabiendo que la programación es generalmente más difícil, ¿por qué los analistas de negocios y los gerentes de proyectos obtienen un salario más alto que los programadores? ¿Qué es lo que hace que su trabajo sea un trabajo bien remunerado cuando incluso en la mayoría de los casos los programadores son los que llegan tarde a casa?

ACTUALIZAR

Disculpe mi ignorancia, de algunas de las respuestas parece que la razón por la cual los BA y los PM obtienen un salario más alto porque son los que generalmente son responsables del desastre que hacen los programadores. Pero al final del día, son los programadores los que se ensucian las manos para arreglar el desastre y trabajar más duro. Entonces todavía no tiene sentido.

El hecho de que los gerentes de proyecto obtengan salarios más altos que los programadores y los analistas de negocios existe como una clase depende directamente del mundo del software en el que vives.

Una respuesta simple a esta pregunta sería "porque en nuestras sociedades, todavía creemos que el salario está vinculado al puesto en la jerarquía". Pero esta respuesta, si bien refleja el hecho de que a las personas se les paga en función de su valor percibido, no explica por qué PM y BA están en la cima de la jerarquía en muchas organizaciones de software y por qué la administración elige la jerarquía en primer lugar como una estructura de elección para el equipo del proyecto de software. Estas son las dos preguntas que parecen ser realmente dignas de hacer.

En términos generales, hay dos categorías de organizaciones de creación de software. Los llamaré Widget Factories y Film Crews.

Las fábricas de artilugios nacen de la escuela de pensamiento gerencial que gira en torno a la motivación Teoría X propuesta por McGregor: los empleados de rango son perezosos y requieren control y supervisión constantes, los trabajos se realizan en nombre de un cheque de pago, los gerentes siempre pueden hacer sus subordinados ' trabajos al más alto o, al menos, el mismo estándar. Este pensamiento desemboca en una idea natural de que todo el equipo puede ser fácilmente reemplazado y representado solo por el gerente, después de que todos los demás miembros del equipo pueden ser reemplazados fácilmente o simplemente para mejorar la capacidad del administrador para completar las tareas. De ahí la jerarquía como estructura y roles de trabajo más bien horizontales.

La gerencia de Widget Factory opera bajo el supuesto de que el software puede fabricarse a partir de una especificación preparada por un analista de negocios a través de un proceso claramente definido bajo la supervisión cercana de un gerente de proyecto. La fabricación se realiza mediante la dotación de personal del proyecto con suficientes recursos de prueba y programación calificados pero intercambiables. El trabajo está impulsado por un presupuesto preestablecido basado en el caso de negocio inicial preparado por PM y BA.

La administración que ejecuta una fábrica de widgets es fácil de detectar simplemente prestando atención a la forma en que estas personas hablan. Es probable que tengan que ver con los recursos (incluso cuando se refieren a los miembros del equipo), los procesos, la eficiencia operativa, la uniformidad, la repetibilidad, el control estricto sobre el uso de los recursos, los roles de trabajo claros y las entradas y salidas definidas del proceso. Mencionan casualmente la metáfora real de la fábrica cuando intentan transmitir la imagen de la operación de desarrollo de software ideal tal como la ven.

Luego están los Film Crews. Se basan en la noción de que las personas son inteligentes, automotivadas, trabajan muy duro y disfrutan de su trabajo tanto como los niños disfrutan jugando. Film Crews reconoce que debido a la especialización, las habilidades de los contribuyentes individuales pueden superar con creces las habilidades de las personas que organizan, coordinan y dirigen el trabajo. Como el gerente ya no puede sustituir a todos, la estructura jerárquica simplemente no funciona tan bien: las personas tienen que cooperar dentro de una formación mucho más plana y compleja para hacer las cosas. Los roles de trabajo en sí mismos tienden a ser mucho más verticales, de principio a fin, e involucran una variedad más amplia de habilidades. Este pensamiento gerencial está respaldado por la Teoría Y de McGregor .

Una directora de un equipo de filmación sabe que su visión de una pieza de software solo puede hacerse realidad si es capaz de reunir un gran equipo, fascinar la imaginación y ayudar al equipo a unirse y trabajar juntos. Su papel es inspirar, proteger la visión, proporcionar dirección y enfocar los esfuerzos. Cada persona es importante porque el "director" cree que el software es el resultado de la combinación de cosmovisiones y habilidades de todos los participantes y de una manera única en que el grupo realiza el trabajo en conjunto. Todos reconocen desde el principio la importancia de lograr que las estrellas se unan a la tripulación: los artistas estrellas aumentan todas las posibilidades de éxito. La visión impulsa el presupuesto y atrae fondos.

Cuando se trata de compensaciónWidget Factories considera que el mayor valor se deriva del trabajo realizado por el gerente de proyecto y el analista de negocios que residen en la parte superior de la jerarquía y tienen que ser compensados ​​en consecuencia, el resto del equipo no importa tanto tiempo como ellos ' Tengo las calificaciones adecuadas para convertir los requisitos en código de trabajo. PM y BA trabajan duro para mantener su posición en la cima del paquete restringiendo el acceso gratuito a las fuentes de información del proyecto para el resto del equipo. Sin acceso formal a las fuentes de información primarias, el equipo lucha para hacer juicios de valor o encontrar buenas soluciones, los programadores están relegados a tomar órdenes de arriba y trabajar en el problema según lo definido por PM y BA.

En un marcado contraste, Film Crew actúa como una formación más igualitaria; Los miembros tienen acceso ilimitado a la información primaria, se les anima a formar juicios de valor y son libres de seleccionar un curso de acciones para cumplir y contribuir a la visión. La estructura de liderazgo se basa en la habilidad más que en un rol específico dentro del equipo. La compensación refleja lo deseable que sea que una persona específica participe en el proyecto, a menudo vinculada a la percepción de cuánto más valioso será el resultado final si esa persona puede ser convencida de dedicar su energía a crear ese software. En este entorno, el papel de un gerente de proyecto se vuelve menos prominente ya que es poco probable que sea el líder creativo; el papel se reduce principalmente al apoyo administrativo y las relaciones externas.

Ahora, no será una sorpresa que la mayoría de los equipos internos de desarrollo de software y algunas consultoras se ejecuten como Widget Factories, confiando en un proceso para producir software constantemente aburrido; Es en estos entornos donde los gerentes de proyecto y los analistas de negocios reciben rutinariamente más pagos que los programadores, basándose en el supuesto de que aportan el mayor valor al entorno estructurado en consecuencia, lo que dificulta que los programadores demuestren que la administración está equivocada.

Las compañías de software exitosas tienden a adoptar el punto de vista de Film Crew, cualquier otra filosofía obstaculizaría su capacidad de atraer a grandes personas de las que dependen tanto para producir un gran software. Es poco probable que alguna vez vea un rol de analista de negocios en ese entorno y los gerentes de proyecto son menos prominentes y rutinariamente se les paga menos que a los grandes programadores.

Porque en nuestras sociedades, todavía pensamos que el salario está vinculado al puesto en la jerarquía .

Los analistas o gerentes de proyecto son más altos en la jerarquía, por lo que se les debe pagar más.

Déjame contarte una historia real que ilustra por qué esto es un problema.

Un buen amigo comenzó como programador en un gran hospital. Gracias a su arduo trabajo y dedicación, rápidamente se convirtió en Oracle DBA, que era una posición crítica en una empresa donde los datos son sensibles y valiosos.

El hospital trabajó con niveles. Los niveles están vinculados a su posición en la jerarquía, el legado y los diplomas.

Mi amigo recibió una propuesta para convertirse en DBA en otra empresa que no utilizaba los niveles salariales. Su salario podría incrementarse mucho. Como le gustaba y respetaba el hospital para el que trabajaba, decidió hablar con el jefe y pedir un aumento.

El jefe se negó. Era imposible debido a los niveles y los sindicatos no dejarían que eso sucediera.

Mi amigo se fue.

El hospital eventualmente contrató a un consultor externo (no vinculado a niveles) y publicó un trabajo en su sitio web. El consultor no sabía nada sobre la infraestructura existente, por lo que su curva de aprendizaje fue enorme. El hospital perdió mucho dinero por eso.

El hospital perdió mucho más. Al consultor externo se le pagó hasta 5 veces más de lo que pidió mi amigo, y no pudieron encontrar un empleado calificado para reemplazarlo.

Eso fue hace casi tres años. Mi amigo todavía está en su nuevo lugar y sube la escalera de la jerarquía muy rápido haciendo lo que ama.

El hospital todavía paga 5 veces más.

En mi humilde opinión, el salario debe ser relativo al valor que usted proporciona a la empresa .

ACTUALIZACIÓN : cuando te mueves más arriba en la jerarquía, se produce el efecto de palanca. De hecho, se le paga por el valor que aporta. Pero a los programadores brillantes que son 10 veces más productivos se les debe pagar 10 veces más, independientemente de su posición en esa jerarquía (generalmente en la parte inferior). Eso es lo que quería destacar.

Toman más riesgos que los programadores. Tienen que tomar decisiones basadas en la información que les proporcionamos, y luego enfrentar las duras críticas de las partes interesadas cuando no se cumplen sus expectativas. Parte del paquete de pago compensa este riesgo.

Otro factor puede ser los años de experiencia necesarios para preparar un gerente de proyecto que pueda planificar, estimar y mitigar adecuadamente. En cierto sentido, un gerente de proyecto matizado es entrenado a través de fallas, lo que lo convierte en una habilidad costosa de adquirir . Una vez alcanzado el nivel de antigüedad, una empresa puede no estar dispuesta a dejar ir a ese personal tan valioso.

Editar:

Hay más tipos de riesgos que el daño financiero o físico. Por ejemplo, considere el riesgo de ser reprendido por el gerente o el cliente. Aunque no se hace ningún daño real, todavía es lo suficientemente indeseable que adaptemos nuestros comportamientos para evitar este tipo de resultado. Sin embargo, los gerentes deben tomar buenas decisiones todo el tiempo y deben equilibrar diferentes tipos de riesgos en interés de la empresa, no de acuerdo con sus preferencias personales.

La programación puede ser más difícil en cierta medida, pero también es más agradable. Simplemente se sienta allí y resuelve el agradable rompecabezas de programación mientras los gerentes lidian con todo tipo de basura entre sus subordinados, sus clientes, sus propios jefes y partes interesadas. Es por eso que tan pocas personas sensatas realmente quieren ser gerentes, por lo que debe compensar eso pagando más.

La programación es más difícil, pero la gestión apesta más.

Una forma de pensar cuál es el valor de alguien para una empresa es imaginar cómo sería si esa persona dejara la empresa. Por lo general, los gerentes resultan ser más valiosos en ese sentido que los programadores. James Gosling , el creador de Java, recientemente dejó Oracle. Uno podría pensar que es una gran pérdida, pero ¿adivina qué? En realidad no importa. Apenas tiene ningún efecto en Java u Oracle. Los perros ladran, pero la caravana continúa.

Por cierto, (en serio) creo que los limpiadores de polvo y los limpiadores deberían pagar mucho más que los programadores. Limpiar la basura de otras personas es un trabajo que apesta y es indispensable.

Reducir la administración a crear gráficos y escribir documentación es como decir que la programación es escribir.

Para cada uno lo suyo, pero para mí la programación es mucho más fácil que administrar personas.

Todos aquí están enfocados en lo negativo. Nunca he conocido a un programador que le guste la política de la oficina y los buenos gerentes lo protegen de ese tipo de basura. Después de haber interactuado con muchas personas en nuestro cliente principal, la mitad de ellas están locas y me alegra tener mi PM allí para absorber esa locura por mí. Si les pagan mucho, está bien. Él o ella lo necesita para la terapia inevitable.

Es discutible, por supuesto, pero una razón importante detrás de esto es que tienen la responsabilidad del proyecto si falla, no los programadores. Puede que te den ganas de levantar algo, pero se enfrentan a las críticas de poderes aún más altos. Ellos son los encargados de la planificación y la estimación .

La gestión requiere un conjunto de habilidades muy multifacético : habilidades de las personas, liderazgo, capacidad de estimar costos y tiempo. Para hacer todo esto, también necesitan estar en contacto con su lado de las cosas (es decir, tener alguna idea de lo que está haciendo, técnicamente hablando) o ser muy buenos jueces de carácter.

Si los requisitos no se definieron correctamente, es su culpa.

Si los planes de prueba no se definieron correctamente, es su culpa.

Si se va de vacaciones o se rompe la pierna o se desperdicia un sábado por la noche o se va sin avisar con suficiente antelación y tienen que encontrar un reemplazo o <alguna razón aquí> y no puede llegar a hacer su trabajo y el producto no obtiene entregado (a tiempo o en absoluto), sigue siendo su culpa .

También tenga en cuenta que cuando quiero decir que tienen la responsabilidad, impacta a las personas que están por encima y por debajo de ellas . Si arruinan las cosas, podrían ser los trabajos de su equipo los que están en juego. Ese es también el tipo de presión por la que te pagan.

PD: Además, no sé si diría que la programación es más difícil que hacer diagramas de Gantt (para reutilizar el ejemplo que mencionas). No sé sobre usted, pero encuentro que la programación (en general, para el 80% de las cosas que necesita hacer en la industria) es bastante fácil. Si arruinas algo, puedes arreglarlo. Si su jefe arruina su diagrama de Gantt o su estimación de costos, ahora será un problema mucho mayor que invertir un != nulla == null. Los pequeños errores les importan a mayor escala. La mayoría de las veces, por supuesto, si arruinaste una prueba como esta en una aplicación médica integrada que entró en funcionamiento, también es un gran problema. ¡Pero tendrán más problemas que tú!

La oferta y la demanda es un modelo económico de determinación de precios en un mercado. Concluye que en un mercado competitivo, el precio unitario de un bien en particular variará hasta que se establezca en un punto donde la cantidad demandada por los consumidores (al precio actual) sea igual a la cantidad ofrecida por los productores (al precio actual), lo que resulta en un equilibrio económico de precio y cantidad. Las cuatro leyes básicas de la oferta y la demanda son:

• Si la demanda aumenta y la oferta permanece sin cambios, entonces el precio y la cantidad de mayor equilibrio.
• Si la demanda disminuye y la oferta permanece sin cambios, baje la cantidad y el precio de equilibrio.
• Si la oferta aumenta y la demanda permanece sin cambios, entonces el precio de equilibrio más bajo y la cantidad más alta.
• Si la oferta disminuye y la demanda permanece sin cambios, entonces un precio más alto y una cantidad menor.

En este caso, una razón es que hay demasiados desarrolladores.

He cambiado entre los roles de desarrollador y PM a lo largo de mi carrera. Tengo desarrolladores en mi proyecto que ganan el doble que yo y otros que ganan la mitad. A los asalariados altos se les paga lo que son porque: A) Son desarrolladores "rockstar". B) Interactúan con los clientes, explican el producto de una manera fácil de entender para los clientes y son agradables. C) Dirigen equipos de desarrolladores que trabajan en múltiples proyectos. D) Siempre están disponibles y con ganas de agradar.

Realizan los roles de desarrollador, PM y BA en diferentes capacidades. En general, si está gastando el 90% de su tiempo, cortando el código, entonces no es increíblemente valioso y probablemente sea fácilmente reemplazable. Si quieres ganar más dinero, entonces debes asumir más responsabilidad ... y probablemente tengas que encontrar otra compañía que te pague más.

La razón es que el área de responsabilidad de un gerente de proyecto (a menudo) es entregar todo el proyecto a tiempo, con una calidad aceptable, dentro de un presupuesto planificado. A menudo hay mucho dinero en juego, por lo que, naturalmente, los buenos gerentes de proyecto a menudo tienen una mayor compensación que los programadores.

Sin embargo, no creo que los analistas de negocios, en promedio, ganen un salario significativamente más alto que los programadores. Y creo que cada vez es menos común que el nivel salarial en una empresa esté determinado por la jerarquía y no por el valor de un empleado.

Mi experiencia puede ser diferente (o estoy viviendo en un universo diferente con leyes distorsionadas de la física), pero la mayoría de los analistas de negocios y gerentes de proyectos (no gerentes de programas , sino gerentes de proyectos o PMP) que he visto están en o ligeramente por debajo El salario promedio de los programadores.

La brecha salarial comienza a ampliarse más en comparación con el salario promedio de los ingenieros de software (a favor del ingeniero de software). La brecha es aún mayor en comparación con EE superiores o ingenieros de software superiores. Casi ningún analista de negocios senior o PMP senior hará lo mismo que un EE senior o un ingeniero de software senior / principal.

Sin embargo, un gerente de programa (que no es lo mismo que un PMP), esa persona ganará mucho más que cualquier otra persona (y las razones deberían ser obvias).

Lo que más me molesta cuando veo estas quejas sobre los salarios es que, como programadores (especialmente como programadores junior / principiantes en la empresa), somos (o no) tan especiales. En realidad, no hay nada en un programador de nivel básico que salga de la escuela que merezca un salario de científico espacial. No se .

Todos los que trabajamos en software comenzamos desde cero. Todos lo hicimos.

Y SI somos realmente honestos, sabemos bien que no sabíamos basura. Ser capaz de completar nuestra carga de cursos de CS de pregrado es solo el punto de partida. No nos hace tan especial o ZOMG !!!! Uber-Einstenian. ¡Realmente no!

Y sin embargo (y gracias al período desafortunado de la burbuja de las puntocom), esperamos hacer no solo más, sino mucho más que otra persona con educación universitaria solo porque OH WOW, somos programadores y solo somos negocios analistas y PMPs.

¿Puedes deletrear arrogancia? Noticia de última hora: para la mayoría de las tareas de programación en la empresa, ni siquiera necesita un título de 4 años. Realmente, es eso serio.

Dedique tiempo a la rutina y desarrolle la experiencia para pasar de la programación a la ingeniería de software (o ingeniería para el caso) en el nivel superior. Entonces puede exigir ganar mucho, mucho, mucho mucho más que un analista de negocios y PMP.

Termine con esto: algunos de nosotros estamos (o fueron) pagados en exceso. Período.

Dejando de lado: razones para que un analista de negocios y / o PMP reduzca los salarios o sean similares a los programadores que aún no han acumulado el tiempo y la experiencia necesarios para ser ingenieros de software de nivel medio / superior (o que aún no han desarrollado experiencia en un nicho altamente demandado) zona):

Un analista de negocios es el enlace entre la gente de software y sistemas y las personas de negocios / procesos de negocios (que son los que justifican la existencia de su cheque de pago, no al revés). Ellos son los responsables de desglosar los procesos de negocios en forma metódica, modales analíticos, como insumo susceptible de formar requisitos, las cosas en las que trabaja. Se aseguran de que pases la mayor parte de tu tiempo programando y no lidiando con las minucias de los negocios.

Muchos de ustedes piensan que los negocios son una mierda fácil. Si realmente crees que es verdad, que Dios te ayude.

Un gerente de proyecto es la persona encargada de hacer malabarismos con varios proyectos (mientras que solo tienes que hacer malabarismos con uno o dos como máximo en un momento dado). Él es tu paraguas y es el que tiene que hacer el trabajo sucio la mayor parte del tiempo. las masas restantes sin lavar no quieren hacer: perseguir a las personas para asegurarse de que hagan su trabajo o eliminar los impedimentos para su trabajo.

Él es el que le preguntará "¿en qué está trabajando? ¿En qué está trabajando para ayudar a avanzar en el proyecto? ¿Tiene problemas con su trabajo? ¿Cuáles son sus obstáculos, qué necesita? ¿Quién puede dárselo? "...

y luego irá a otras personas haciendo las mismas preguntas difíciles, asegurándose de que se eliminen los obstáculos y asegurándose de que usted esté ejerciendo su peso en el proyecto (si es necesario).

El problema número uno que he visto en muchos proyectos fallidos es la falta de PMP o una falta de respeto hacia los PMP (especialmente por parte de los desarrolladores). Es raro que vea que los proyectos fallen debido a PMP incompetentes, y sin embargo uno debe preguntarse por qué muchos programadores están más que ansiosos por decir que ese es el caso.

Estoy en finanzas, y creo que la mentalidad es similar en la mayoría de los equipos no tecnológicos:

El pago es proporcional al riesgo profesional

Salvo un despido completo de un grupo o equipo, los programadores de bajo nivel siempre mantienen sus trabajos. Es la naturaleza del trabajo, y los programadores lo hacen sabiendo muy bien que corren un riesgo cero. Si hay un error, no son sus cabezas en el tajo.

En los niveles superiores, si algo falla, eres el primero en ir. He tenido muchas experiencias con un subordinado que cometió un pequeño error tipográfico que nos llevó a perder dinero, y tomé el calor por ello (no el programador real que cometió el error).

En pocas palabras, la paga es proporcional al riesgo. Los programadores, por otro lado, no necesariamente tienen ningún aspecto en el juego, por así decirlo.

Si su pregunta hubiera sido "¿por qué X e Y obtienen salarios más altos que los programadores de mi empresa? ", Podría haber respondido "puede que trabaje en la empresa equivocada".

El éxito de una empresa en el negocio del software depende más que nadie de las habilidades de sus programadores. Las empresas que no reconocen esto están automáticamente en desventaja frente a las que lo entienden. Contratar a los mejores programadores y cuidarlos bien es su mejor opción. La diferencia en el trabajo de los grandes programadores frente al resto es enorme; mucho más grande que la diferencia en el salario que mandan. Pero si insiste en pagar menos a sus programadores, obtendrá lo que paga.

Dicho esto, cualquier otro papel en el negocio es importante. Los grandes gerentes tienen un gran impacto. Mucho de eso es conseguir grandes programadores y mantenerlos felices. Algo similar se puede decir sobre análisis de negocios, marketing, ventas, pruebas y soporte.

Si eres un gran programador y no estás siendo recompensado generosamente, ve a otro lugar. Por otra parte, puede que no seas un gran programador. Desafortunadamente, si no eres genial, es difícil ver por qué. Si supieras por qué, podrías cambiar y ser genial, ¿verdad?

He sido programador y gerente de personas. Trabajé con muchos programadores excelentes, pero solo con algunos gerentes excelentes. Cuando era gerente no era genial, pero al menos lo sabía. Mi gente recibió más aumentos que yo, que se merecían.

Tiene poco que ver con las habilidades y el trabajo, quiero decir que poco en la economía está vinculado a cuánto merece la gente ganar.

Merecer ganar más dinero es una idea efímera, todos creen que merecen ganar más dinero.

Si bien puede no ser justo, los gerentes ganan más dinero simplemente porque los dueños de negocios confían más en ellos. Los gerentes a menudo obtienen salarios más altos, simplemente para no tomar un nuevo trabajo de la nada en un momento inconveniente.

Creo que toda su base para esta pregunta es errónea.

La gerencia debe ser pagada más que sus subordinados. La antigüedad en una empresa generalmente se basa en el salario, y no hay forma de que un empleado junior pueda tener los medios para mandar a sus superiores.

Liderar personas es una habilidad especializada. No todos pueden ser gerentes de proyecto (PM). La tarea es cada vez más difícil a medida que aumenta la cantidad de personal. En un rol técnico de PM, el PM necesita tener una buena comprensión de la tecnología para liderar efectivamente, o no tendrán el respeto y el apoyo de sus subordinados.

En muchas profesiones, una habilidad central es la capacidad de vender algo. Y para vender algo, tendrá que venderse usted mismo. Necesita que el comprador confíe en usted y valore el producto o servicio que proporciona tanto como lo desea. Esta habilidad es completamente transferible a las negociaciones salariales.

He leído todas las publicaciones y me atrevo a decir que la mayoría de ellas están tratando de comparar manzanas y plátanos.

En primer lugar, creo que alguien que dice que "administrar es pan comido" nunca tuvo que administrar nada más que su propio horario. Por otro lado, decir que "cualquiera puede codificar cualquier cosa" es una tontería (¡y está en el foro equivocado, por el amor de Dios!).

Me gustaron especialmente las respuestas de rwong y luis.espinal, aunque creo que también hay otros hechos que deben tenerse en cuenta.

No creo que la jerarquía sea una respuesta, no hoy en día, aunque encaja perfectamente durante los últimos 10.000 años. Vivimos durante siglos en una sociedad en la que cuanto mayores son sus ganancias, mayor es su poder (y viceversa). No creo que se aplique a nuestro mundo, tal como es (especialmente en nuestra área).

Volviendo a la pregunta principal, creo que los gerentes generalmente ganan más porque son más valiosos para una empresa, no porque sea más alto en jerarquía, sino que es más alto debido a

• todo el conocimiento que ya obtuvo de experiencias anteriores (generalmente los programadores tienen menos experiencia que los gerentes en general)
• por poder administrar varias cosas a la vez (los programadores tienen una tarea, o una lista de tareas) que cumplir, mientras que los gerentes deben administrar sus propias tareas
• son el contacto principal para el proyecto que gestionan, y por esta razón son el primer 'objetivo' en caso de que algo salga mal. Es más fácil perder tu trabajo si eres gerente; siendo desarrollador, tienes la 'licencia para rehacer algo'. Ese es el factor de "riesgo" que todos mencionaron.
• Los desarrolladores forman parte de todo el ciclo de vida del proyecto. Creo que cuando hablamos aquí de 'programadores' también estamos pensando en los evaluadores, escritores técnicos y todas las demás personas que son muy importantes para el éxito del proyecto.
• y hay algo que solo vi en un par de publicaciones sobre este tema: liderazgo. Ser gerente está a punto de saber cómo estar en contacto con las personas, negociar, mantener a todos motivados, crear sinergia cuando el estado de ánimo de todos está deprimido.

En mi opinión, el factor de liderazgo es la razón principal de los salarios más altos, ya que genera un gran resultado a largo plazo para la empresa y para todos los que están cerca del líder.

Por cierto, solo tuve unas pocas experiencias como líder de equipo (¡lejos de ser un líder de proyecto!) Y por mucho que sé lo que hace un líder, tanto trabajo me doy cuenta que tengo que hacer.

Editar: Olvidé destacar: las habilidades de comunicación no son un punto fuerte para la mayoría de nosotros, pero es imprescindible para un líder. Además, me gustaría compartir una muy buena publicación en Coding Horror, relacionada con buenos programadores y habilidades de comunicación -> http://www.codinghorror.com/blog/2011/02/how-to-write-without-writing .html

Piénselo de esta manera, el número de gerentes calificados es menor que el número de programadores calificados, por lo tanto, los gerentes son más "valiosos" para las empresas.

Eso depende de cómo defina "dificultad". Sin embargo, me pregunto si sabe de qué se trata la gestión de proyectos y qué deberían hacer los analistas de negocios. Leí mucha frustración de su pregunta, así que creo que tiene algunas malas experiencias. Sin embargo, quiero intentar responder a tu pregunta.

Los gerentes de proyecto y los analistas de negocios suelen ser "mayores" cuando cumplen esos cargos. Cuando los desarrolladores comienzan su carrera muy jóvenes (alrededor de los 20 años), la mayoría de los gerentes de proyectos y analistas tienen cerca de 30 años (lo que ya crea una diferencia en el pago solo por la edad). También son los que se enfrentan a la exposición del cliente, lo que significa que tienen que viajar en el lugar, pasar horas de tortura para escuchar al cliente (especialmente cuando un proyecto sale mal) y alistar sus deseos / necesidades. Tienen que tener cuidado con lo que prometen y especialmente dentro de qué alcance (tiempo de entrega). Aunque desde su perspectiva de que lo que hacen es solo documentar, los analistas de negocios están educados para analizar las necesidades del negocio, y los gerentes de proyectos vigilan la planificación de los proyectos.

Actúan como un firewall entre el cliente y los desarrolladores. Una perspectiva técnica es algo diferente a una perspectiva de ventas. La mayoría de los analistas de negocios y gerentes de proyectos también se enfrentan a una gran variedad de clientes: están expuestos y por lo tanto tienen 'clientes potenciales'. Su red consiste en tomadores de decisiones y, por lo tanto, las empresas prefieren mantener a las personas con tales redes a su alcance; Después de todo, una venta es una venta.

En cuanto a la dificultad? Inicie una empresa, tenga diez desarrolladores e intente administrar un proyecto. El dolor de cabeza viene de forma gratuita. Haga esto durante un año y luego vuelva a mirar su respuesta. Para BA? Ve por esa oportunidad. Siéntese con los clientes que tienen una máquina AIX de 1974 y el diseñador de ese sistema está muerto / retirado / muriendo / alzeheiming y el desarrollador necesita saber si se genera un cierto valor o tiene alguna fórmula mística. Intente convencer a 20 personas con un powerpoint sobre su solución dentro de 3 días. Si documentar fuera tan "fácil", Linux ya habría arrasado con el mundo en 1997. Realmente, intente escribir un documento técnico cada mes para personas no técnicas (las que piensan que Facebook es una revolución en informática).

Soy ingeniero de ventas. Lo que significa que desarrollo, pero mi especialidad es para prototipos y demostraciones. Y gano más que un analista de negocios o un gerente de proyecto. No porque tenga una red (aunque sí), sino porque abandoné la actitud y me concentré más en la perspectiva comercial, me certifiqué y me enseñé algunas habilidades blandas. Y la experiencia de aprender que 'no' también es la respuesta, cuando se trata de horas extras.

Respuesta simple: son más valiosos para la empresa que los programadores.

¿Por qué? Porque se aseguran de que los proyectos se completen, incluso si no están haciendo la programación ellos mismos. Eso significa que su valor (puramente en términos monetarios para la empresa) es más que un programador individual. La compañía no cree que los programadores no administrados sean productivos y, por lo tanto, valiosos ... Es solo el gerente el que los hace así.

Es una mierda, y puede que no nos guste, pero es por eso que la compañía les paga más.

Sin embargo, su posición (como han señalado otros) viene con inconvenientes: si no logran completar un proyecto en un momento determinado, es su culpa, no los programadores. Asumen más responsabilidad y es muy probable que sean despedidos por fallar (a menos que haya un cierto nepotismo de la compañía BS).

Entonces, realmente, no se les permite cometer errores, tener más presión sobre ellos y tener un trabajo mucho más volátil ... pero no se confundan: esta no es la razón por la que se les paga más : una empresa no le importa a una rata cuánta presión estás bajo, qué tan volátil es tu posición, nada de eso. Solo les importa el valor que aportes a la empresa. Período.

Eso es capitalismo, amigos.

No sé cuántas veces es necesario actualizar el conocimiento del diagrama de Gantt en un año. Pero para programar, necesita actualizarse con nuevas tecnologías que no serán tan fáciles con su edad.

Aprender una nueva tecnología necesita horas de sudor, eso si eres lo suficientemente inteligente como para absorber.

La habilidad adquirida en años haciendo programación no se valora mucho en la cultura actual de la empresa.

Comparar el salario de los programadores recién graduados con uno con más de 10 años de experiencia es una historia un poco triste.

La comparación de un nuevo PM con un PM de 10 años es una gran historia, el PM podría convertirse en Director después de 10 años de experiencia.

Entonces, ¿por qué todavía hay tanta gente que quiere aprender TI en la universidad? No entiendo. ¿Han sido debidamente informados?

No entiendo cómo la gente valora la habilidad hoy en día.

Por exactamente las mismas razones por las que un CEO puede ganar 263 veces más que su trabajador promedio.

La gerencia no siempre gana más que el personal de ingeniería. El personal de ingeniería de nivel superior debe participar activamente en el análisis de nivel empresarial y la toma de decisiones y trazar la hoja de ruta técnica para la empresa. Cuando este es el caso, el personal técnico superior puede ganar bastante más que los gerentes de negocios con los que trabajan todos los días.

Uno de los mitos populares de los negocios es que al gerente se le debe pagar más que a las personas que maneja. En mi opinión, esta noción está más arraigada en las buracracias que en los equipos funcionales y ágiles.

Para decirlo de otra manera: se supone que la compensación refleja el valor de la contribución de una persona a la empresa. Hay gerentes comerciales estelares y gerentes promedio, y hay ingenieros estelares e ingenieros promedio. Si tiene un ingeniero estelar que produce tecnología para ganar dinero y tiene un profundo conocimiento de las tecnologías de la compañía, ¿no le conviene compensar a esta persona de manera más agresiva que un gerente comercial promedio que está manejando a este ingeniero estelar? ¿Cuál es el costo de oportunidad de perder esa experiencia de ingeniería y conjunto de habilidades porque descuidaste este valioso recurso?

Empecé hace un mes con mi primer proyecto como primer ministro. Antes trabajaba como programador. (Por cierto, obtengo el mismo dinero que antes).

Descubrí que ser un buen PM significa ser un buen programador con una amplia experiencia. Debería poder pasar de un miembro del equipo a otro y discutir los problemas que tienen usando su experiencia práctica para ayudarlos a comprender los problemas al proporcionar un punto de vista diferente. Su tarea es, además de otra, administrar las interfaces. Un PM es como un conductor. Puedes tener los mejores músicos, pero si no tienes un buen director que sepa tocar bien la orquesta de metainstrumentos, solo obtienes un desastre.

La contraparte es el especialista. Este es el programador que puede resolver problemas difíciles porque tiene un conocimiento profundo del dominio del problema. Estas personas experimentadas a menudo también reciben altos salarios si son lo suficientemente buenos en la negociación. Lamentablemente, los especialistas son a menudo nerds y no están tan interesados ​​en el dinero o en hacer un buen negocio ...

Los programadores no ponen el salario como la máxima prioridad (suponiendo que sea a un ritmo razonable). Imagine dos ofertas de trabajo donde una tiene un salario más alto, el mismo compromiso de tiempo, pero requiere soporte técnico, horario comercial estricto, código de vestimenta, redacción de documentación del usuario, manejo del código heredado en un idioma anticuado que esperaba que nunca tuviera que volver a usar, cómo ¿Cuánto más salario necesitarías?

Si trabaja para una empresa que respeta la programación, las matemáticas, la resolución de problemas, cualquier habilidad, puede ganar más por dos cosas:

• Haciendo un trabajo más difícil
• Tomando más responsabilidad

El hecho de que un hospital no pague mucho a su DBA calificado (vea el ejemplo en la primera respuesta) no significa que esto sea lo mismo en todas las empresas.

Muy bien, estoy un poco sorprendido con las respuestas, así que aquí va. Pero antes de eso, me gustaría aclarar que soy un programador y que no hay nada que me guste más que la programación. Dicho esto, tengo un gran respeto y respeto por los PM y BA competentes . Me doy cuenta de que muchos de nosotros estamos resentidos con los PM y los BA porque, a diferencia de la programación, es posible sobresalir en ellos sin el nivel requerido de competencia (política de oficina, trajes agradables, etc.).

Sin embargo, tanto Project Management como Business Analysis son componentes críticos del desarrollo de software.

Cuando pensamos en el desarrollo de software, muchos de nosotros tenemos la tendencia a centrarnos solo en la programación, excluyendo todo lo demás. Sin embargo, hay más que codificación.

Primer objetivo del desarrollo, que es crear un software que realmente aborde y resuelva los problemas del cliente. Esto implica descubrir primero los requisitos del cliente (ya que el cliente puede no estar realmente seguro de lo que quiere), esto solo es posible mediante un análisis detallado del dominio en el que opera el cliente y la estructura de los diversos artefactos (ya sea personas, infraestructura técnica o proceso), y luego desarrollar una solución comercial adecuada (y su integración con la tecnología) para abordar esos requisitos.

Del mismo modo cualquier proyecto de tamaño significativo absolutamente no puede funcionar sin una gestión eficaz. Ahora no sé cómo es en otros lugares, pero hasta ahora mi experiencia ha sido que los PM generalmente son promovidos de filas de programadores, por lo que tienen una idea de lo que se necesita para organizar y ejecutar el proyecto.

Para resumir, tanto los BA como los PM son una capa de abstracción para el desarrollo .

Mucha gente dijo aquí, que la programación es más difícil y es por eso que debería ganar más. Esa es una vista muy romántica. La verdad es que, en una empresa normal y saludable, el pago se realiza de acuerdo con la responsabilidad , eso significa el valor agregado de esa persona y también el riesgo .

El riesgo a menudo será olvidado. Normalmente, si el programador falla en su trabajo difícil de hacer, puede haber un aumento en los costos, pero nada más. No como el 10% de los trabajadores perderán su trabajo o algo así. El riesgo es bastante bajo.

También quiero estar en desacuerdo con la idea de que la mayoría de los empresarios ganan más. Apuesto a que el hombre de negocios normal gana menos de lo que la mayoría de los Licenciados en Ciencias / Ingeniería ganarán. Por ejemplo, como programador de vacaciones de pregrado, gané casi lo mismo que algunos trabajadores de negocios de tiempo completo en la misma empresa.

Y por último, pero no menos importante, ¿por qué el gerente del proyecto no es un ingeniero? Normalmente, el gerente del proyecto es un tipo con muchos años al frente en el tema del proyecto que maneja, lo que significa que en los trabajos de programación será un programador experimentado que es el gerente del proyecto.

Hay entornos corporativos en los que domina el patrón de comando y control o el patrón de comunicación de concentrador y radio . En estas organizaciones, el gerente y el comunicador principal son a menudo la misma persona. Esto convierte al gerente en un punto único de falla : cualquier efecto pésimo de la falta de comunicación o pérdida de traducciones se amplifica. Por lo tanto, estos entornos requieren personas con amplios antecedentes técnicos como gerentes para garantizar la precisión.

Los equipos mejor organizados generalmente designan un comunicador jefe para descargar esta responsabilidad. Las organizaciones que practican la gestión del conocimiento no tienen ningún punto único de fallas en la comunicación. En estas organizaciones, los gerentes y comunicadores principales solicitan información y facilitan las discusiones. Esta información será capturada y procesada para compartir internamente. Se requiere un conjunto diferente de habilidades sociales.

Del mismo modo, los analistas de negocios son a menudo el único punto de contacto entre los clientes y el personal técnico de la compañía.

Este no es siempre el caso. Cuando trabajaba para Computer Sciences Corporation (CSC), la mayoría de los gerentes ganaban menos que las "personas que producían algo útil". En el caso de CSC, creo que este fue el caso porque la compañía había sido iniciada por un grupo de programadores.

En ese momento (1970) había otra compañía de software en Los Ángeles cuyo nombre olvido con un interesante calendario salarial. Los programadores cobraron $ 25,000 / año y el personal de soporte recibió $ 15,000 / año. La idea era que si usted fuera el peor programador allí, no debería sorprenderse de ser reemplazado.