¿Motivar a los desarrolladores en un proyecto percibido como aburrido?

Como gerente, no siempre puedo terminar generando trabajo que sea de vanguardia. Algunos de los proyectos se ejecutan en modo de mantenimiento y generan un flujo de caja libre saludable para la empresa.

Como desarrollador, ¿qué haría falta para que te quedes en este proyecto? He estado pensando en cambiar el nombre del trabajo, pero podría hacerlo con mucha ayuda aquí.

EDITAR: Gracias a todos por las sugerencias. Hasta ahora, esto es lo que tenemos:

1. Rotación del trabajo según el interés del desarrollador.
2. Ambiente de trabajo flexible
3. Dedicar tiempo a trabajar en proyectos para mascotas
4. Sociales y diversión
5. Marca del proyecto.
6. Use esto como un trampolín para otros proyectos

Para proyectos en modo de mantenimiento, piense en lo que viene después. ¿Qué los hará eventualmente poco atractivos para sus clientes? Para evitar la obsolescencia, ¿necesitan nuevas características, un mejor rendimiento o que se simplifiquen? Si comienza de nuevo, ¿se pueden fusionar algunos proyectos? ¿Deberían construirse con diferentes herramientas, lenguajes o procesos? ¿Hay mejoras o instrucciones que nadie haya considerado? Haga que sus desarrolladores respondan algunas de estas preguntas. Construir prototipos. Prueba un nuevo lenguaje o marco. Dar a un proyecto una nueva interfaz móvil.

Es más fácil experimentar con alternativas cuando no hay una fecha límite inminente. Usa los tiempos aburridos para superar a tus competidores.

Necesitas ofrecerles algo para ocupar su tiempo. Los proyectos en modo de mantenimiento a menudo no requieren 40 horas a la semana de cada desarrollador. Si es así, entonces probablemente haya algo mal con el software, pero en función de la forma en que hizo la pregunta, supongo que está buscando ideas para ocupar a sus desarrolladores, mientras que no hay mucho que hacer. No sé cuál es su presupuesto financiero, pero creo que algunos incentivos, como enviarlos a una conferencia de software, podrían ser útiles. Otra sugerencia podría incluir explícitamente permitirles explorar sus propios intereses durante 15 horas a la semana. Alguien podría estar interesado en explorar, por ejemplo, algoritmos de clasificación o diseño de bases de datos. Puede que no esté directamente relacionado con su negocio, pero no puedo imaginar que al final no se beneficiaría de su mayor conocimiento. Simplemente no los obligue a estar en el trabajo sin nada que hacer. Permítales ocupar su tiempo con otra cosa si no hay mucho trabajo por hacer. Creo que es justo pedir un resumen de lo que están haciendo para asegurarse de que no solo naveguen por la web al azar, sino que les permitan explorar un poco.

Haz que sea divertido trabajar en el proyecto.

De hecho, los proyectos interesantes son bastante raros. Y los estudios muestran que la felicidad de los empleados depende en gran medida de lo social y lo divertido. Mencionan masivamente a sus colegas cuando se les pregunta por qué no abandonarían su trabajo actual.

Es por eso que siempre debes ser feliz cuando escuchas risas en tu edificio en lugar de gritos.

Para mí, el mejor motivador en esa situación son los objetivos muy claros, especialmente en forma de una buena especificación. O, en lugar de lo mejor, es una de las pocas cosas que le quedan para ofrecer. El razonamiento allí es que si el trabajo en sí no es interesante, saber que volveré a trabajar un montón de esas cosas aburridas es un desmotivador enorme. Sin embargo, eso puede depender de que el programador reconozca claramente el valor de una especificación.

Otra cosa es dejar en claro que, por aburridos que sean, los proyectos que generan ingresos son para el bien de todos: no hay ingresos, no hay trabajo, etc. El trabajo debe hacerse, de lo contrario no tendrá suficiente dinero para mantenerlos. a bordo. Señale esto explícitamente, a veces las personas no se dan cuenta.

Luego, divide la carga. Trate de encontrar formas de mantener límites establecidos para el trabajo aburrido y molesto (dependiendo del tipo de trabajo, dividir los días de la semana, dividir las tareas, etc.) para que nadie tenga la sensación de que están atrapados con todo el desorden mientras que otros pueden hacer cosas divertidas.

Luego, trata de igualarlo con cosas divertidas. Y hable con los desarrolladores, pueden tener buenas ideas.

Tienes que cambiar la percepción del proyecto "aburrido". Si está generando ingresos saludables, eso no puede ser muy difícil de hacer.

A menudo, estos proyectos son buenos para sus programadores que son mediocres y felices de ser mediocres. Ya sabes, las personas a las que no les apasiona la programación y que solo la ven como una forma de pagar las cuentas. Ahora, comprende algo: no digo esto porque son programadores más débiles y quieres hacerles la vida imposible. Lo digo porque estos son generalmente los tipos de personas que simplemente no esperan que su trabajo sea una fuente de realización en sus vidas. Por lo que parece, esto suena como baja presión, flujos constantes de ingresos. Es más que probable que estos trabajadores estén más que felices de tomar un trabajo fácil y de baja presión.

Por supuesto, eso no significa que pueda darles tareas aburridas y olvidarse de ellas. Tal vez podría dar a sus "jugadores A" un 80% de tareas divertidas / 20% tareas aburridas, sus "jugadores B" podrían ser 50/50, y sus "jugadores C" podrían ser 20/80.

Permita que sus desarrolladores ganen tiempo remunerado trabajando en sus propios proyectos favoritos / de código abierto / interesantes haciendo un trabajo duro. Ofrézcales algo de apoyo con este tipo de proyectos, especialmente si el trabajo es en un proyecto o programa interno. Creo que esa es una estrategia que utiliza Google.

Debo admitir que nunca he trabajado en un proyecto aburrido y poco interesante, así que no estoy seguro de entender tu pregunta. Y desarrollo sistemas empresariales para vivir. :) En serio, en la práctica he descubierto que a los programadores les molesta el trabajo "aburrido" mucho menos de lo que esperaba. El trabajo inútil, como completar hojas de tiempo que nadie revisa, es un problema mucho mayor. Habiendo dicho eso:

Conozca las preferencias de sus programadores; a algunos programadores no les gusta la GUI, otros se alejan de SQL. Intenta respetar esas preferencias, ya que una tarea aburrida para un programador puede ser divertida para otro. Si por alguna razón no es posible dividir el trabajo de esa manera, hágalo interesante aumentando la competencia: déjelos competir quién será el primero en terminar su parte o haga un marcador en cuya parte del código tuvo la menor cantidad de errores en el control de calidad. Microsoft es conocido por su cultura corporativa que hace que los programadores compitan en diferentes enfoques, y al elegir el mejor al final o incorporar las mejores partes de cada enfoque en el producto final.

Tener una parte del producto y tener control sobre él también aumenta drásticamente el compromiso de uno. Por el contrario, no hay nada más aburrido que hacer que alguien administre tu trabajo. Además, si hay una tarea recurrente que todo el mundo odia, explicar el panorama general: que es algo que hay que hacer y por qué y rotar a la persona que lo hace cada semana suele ser más que suficiente.

He tenido / visto éxito con el uso de este tipo de proyecto como el camino hacia los más interesantes.

Si sus desarrolladores nuevos y de nivel medio comienzan en los proyectos "aburridos" haciendo preguntas a los desarrolladores senior (que están en los otros proyectos la mayor parte del tiempo) y deja en claro que cuanto mejor lo haga en el área de mantenimiento, más es probable que tenga una participación futura en el nuevo trabajo, luego suponiendo que tenga un equipo decente y realmente continúe con el cambio ocasional del equipo y de vez en cuando recurra a los desarrolladores principales en el nuevo trabajo que los equipos se alinearán.

Si tiene un mal equipo, o un muy buen equipo, este enfoque puede no funcionar para usted.