¿Las compañías de ingeniería de software necesitan gerentes?

¿Qué quiere decir con “tonto”? ¿Hacen elecciones con las que no está de acuerdo? ¿Tienen un puntaje bajo en las pruebas de coeficiente intelectual? No conocen los mismos detalles tecnológicos que usted y todos los demás en su grupo, porque enfocarse en la tecnología por largos períodos?

El conjunto de habilidades para un gerente es diferente al de un desarrollador. Es muy parecido a ser padre. Sus responsabilidades incluyen:

• Proporcionando dirección, asignando trabajo
• Tratar con interrupciones constantes
• Llevarse bien y mediar entre desarrolladores, evaluadores y administradores
• Contratación, evaluación, despido.
• Motivador
• Resolviendo disputas
• Orientación de nivel superior
• Organizar entrenamiento
• Administrar recursos, incluyendo tiempo y dinero.
• Negociaciones con la alta gerencia sobre cronograma y presupuesto.
• Pasar sus días en reuniones

Un gran problema es que las personas con habilidades de desarrollador se tocan con una varita mágica: ¡prang, eres un gerente! Sin entrenamiento ni aptitud.

En “The Peter Principle” hay una historia sobre el mejor mecánico de una tienda de automóviles, que es ascendido a gerente de tienda. Por lo general, se lo podía encontrar con la cabeza debajo de una capucha. Mientras tanto, los otros mecánicos se quedaron esperando el trabajo.

Es un trabajo duro.

Sí, algunos gerentes de proyecto son tontos. No saben qué diablos está cocinando en los programas que en realidad son los productos que le dan pan y mantequilla a la empresa, pero aún así se sientan en posiciones altas.
Los gerentes en las compañías de software deben ser de antecedentes técnicos, siempre. Si no es así, seguramente los desarrolladores de software serían más inteligentes. En el desarrollo de software, es importante conocer el proceso de desarrollo para hacer cualquier cosa relacionada.

Los gerentes en general son inútiles sin el conocimiento y la experiencia de dominio adecuados.

Tengo una frase para ingenieros no administrados … “Reclusos que dirigen el asilo”.

Hace mucho tiempo, en el primer boom de las punto com, trabajaba para una empresa que estaba haciendo terminales de internet por hardware. Phoenix BIOS para nuestras placas base habría sido un dólar por placa. Como un grupo de programadores, pensamos que esto era indignante … ¡podríamos escribir un BIOS nosotros mismos arrancando un kernel de Linux desde el chip del BIOS en unos pocos meses-hombre, y ahorrar MILLONES! WOO HOO! ¡INGENIEROS BRILLANTES AHORRAN A LA COMPAÑÍA UNA FORTUNA!

El proyecto llegó a su fin cuando descubrimos que no podíamos arrancar un kernel de Linux con una imagen inferior a 720k, demasiado grande para un chip PROM de 512k. Hubiera costado más ir a una PROM de 1M que simplemente usar Phoenix BIOS.

Pero aquí está la verdadera idiotez … perdimos varios meses hombre en este ejercicio de arrogancia y machismo del programador. Todos sabíamos que el reloj avanzaba, que el dinero de las punto com no estaría para siempre. Arriesgamos todo el negocio para ahorrar un poco de dinero en el futuro. Eso es estúpidamente estúpido. ¡Y lo hicimos porque no teníamos un gerente “tonto” para intervenir y decirnos que dejáramos de perder el tiempo y hiciéramos un trabajo que realmente nos llevaría a un producto que funcionara!

Existe la ilusión de que inteligentes y estúpidos son opuestos. No son. Felizmente coexisten en un solo cerebro.

Tal vez que ninguna gestión es mejor que la mala gestión. En algunas circunstancias, al menos, es posible que un grupo de programadores decentes trabaje cooperativamente para construir un sistema común a través de sus propias iniciativas y sin interferencias externas. En el pasado, ciertamente he visto a algunos de estos gerentes despistados apartarse del camino y centrarse en tareas administrativas como la facturación y el filtrado de interrupciones en nombre del equipo de trabajo. Las cosas se hicieron, pero muchos problemas no se abordaron. Cada programador siguió su propio camino a través de su propia visión de túnel, se compartieron o estandarizaron muy pocas prácticas, cada persona tuvo que abrirse camino por sí misma … El más pequeño de los éxitos dependió del esfuerzo heroico de cada individuo, que tuvo que hacer demasiado muchas decisiones para realizar su trabajo profesionalmente en todos los niveles. La libertad conduce a la arrogancia y la arrogancia a un desastre de trucos cuestionables improvisados ​​y a menudo inacabados. Algunas personas discutirán sobre las virtudes de trabajar de esta manera, y se ha logrado mucho en ausencia de las clases gerenciales. Se puede hacer, pero ¿qué tan óptimo podemos esperar ser al deshacernos de la administración?

El software es un proceso de colaboración, y cada vez que las personas trabajan juntas, hay que administrar algo. Se deben distribuir los roles, se deben compartir las normas y prácticas, se deben acordar las instrucciones, se deben cumplir las buenas condiciones de trabajo, etc. Un buen gerente puede trabajar para asegurarse de que todos y todo funcionen bien juntos. Podemos elegir distribuir estas responsabilidades entre el equipo de producción, pero tal vez a costa de aumentar la carga cognitiva de los programadores y con el riesgo de dejar que las cosas sucedan como pueden. El software y la documentación pueden ayudar a enmarcar la forma en que las personas trabajan juntas, pero tener a alguien para centrarse en facilitar una gran cooperación puede ser una contribución valiosa. Quizás la clave no sea deshacerse de la administración, sino asegurarse de que exista para apoyar a la tripulación y al proyecto.

Los gerentes se enfrentan con el ejecutivo y asumen la responsabilidad de si el proyecto va en la dirección correcta o incorrecta. Ingeniería de software no tendrá que tomar tanto.
Si está trabajando con Scrum, entonces usted y el equipo serán los dueños de lo que entregan. En ese momento, no necesitará un gerente, sino un Scrum Master para evitar que todos los demás lo distraigan de cumplir lo que se ha comprometido.
En resumen, el gerente o los ingenieros de software de Scrum Master ayudan a centrarse en lo que son buenos.

Supongo que está hablando de gerentes de proyecto, por lo que responderé en función de eso.

1. Dudo mucho que la mayoría de los pms sean tontos. Pueden o no tener un buen conocimiento del lado de la ingeniería de las cosas y eso definitivamente puede afectar su capacidad para administrar de manera efectiva.

2. No todos los ingenieros de software odian sus pms. Y estaría dispuesto a apostar que su inteligencia rara vez es un factor en sus sentimientos. Estoy dispuesto a apostar que en la gran mayoría de los casos esa capacidad de hacer su trabajo es un factor mucho mayor. Y sé lo que estás pensando, si son tontos, entonces no pueden hacer su trabajo. Así que lo remito a mi respuesta para 1.

3. Las herramientas y la tecnología son tremendamente útiles. Los buenos pms los usan cuando corresponde. Pero si no hay pm, ¿quién está monitoreando el progreso? ¿La alta dirección? Dudoso ya que tienen otras cosas que hacer y casi con certeza tienen una comprensión aún menor del lado de la ingeniería que los pms, en promedio. ¿Los propios ingenieros? Una vez más, es poco probable porque están demasiado ocupados haciendo el trabajo frente a ellos.

La última tarde con la que trabajé me dijo que su trabajo era ayudarme a hacer mi trabajo mejor. Y creo que la mayoría de los buenos reflejarían ese sentimiento. Actuó como la interfaz entre la alta dirección y los ingenieros. Pudo decirles cuánto trabajo podíamos hacer en cuánto tiempo y asegurarse de que no nos presionáramos demasiado. Pudo filtrar todo el gobbledy corporativo y realmente decirnos qué necesitaba la alta gerencia para que pudiéramos ver si se podía hacer.

Los PM tienen valor. Pero como todas las cosas, las buenas mejoran la vida y las malas empeoran las cosas.

Desde que dirijo una empresa de desarrollo de software, diré un sí fuerte. Organizamos nuestra empresa en equipos. Un equipo de desarrollo como desarrollador senior y dos desarrolladores junior. Reportan y son administrados por el CTO, que también es el arquitecto de software. Somos una tienda ScrumDo. Agregaré un gerente de producto para cada uno de los productos principales que desarrollamos, pero funciono como gerente de producto que representa a los clientes y posibles clientes.

Siempre desconfío de que los desarrolladores se queden solos. Puede pensar que estaba obteniendo un pura sangre pero terminó con un camello. Ambos tienen cuatro patas y pueden correr.