Nadie espera que un programador haga su trabajo sin usar una computadora. Pero al mismo tiempo, muchas empresas esperan que haga su trabajo sin poder pensar con calma. Es igualmente imposible.

Echemos un vistazo a nuestra lista de 12 factores que impiden que sus programadores trabajen cómodamente y sean productivos. Trataré de ordenarlos por orden de influencia: de la más importante a la menos importante.

Si tiene dudas sobre si vale la pena su atención e inversión, solo piense en los salarios de los desarrolladores. Incluso un aumento del 10% en la productividad es MUCHO.

1) Pequeñas pausas y reuniones

Creo que las pausas reducen más la productividad de los programadores. No es tan fácil para un desarrollador volver a lo que estaba haciendo antes de ser interrumpido. Necesita sintonizarse de nuevo y luego seguir lentamente su pensamiento hasta el lugar donde lo dejó. Esto puede llevar fácilmente más de media hora. Y cuantas más pausas, menos ganas de trabajar, menor es la calidad del código y más errores.

“Cuanto más interfieres conmigo al comienzo del trabajo, más descansos entre mis intentos de continuar. Si interrumpes mi trabajo toda la mañana, no te sorprendas de que todo mi día sea improductivo". Desarrollador en Reddit

¿Qué pasa con los planeadores? Se diferencian de las pausas solo en que se planifican con anticipación, lo que solo empeora las cosas. Un programador no puede realizar una tarea normalmente cuando sabe que tendrá que interrumpir pronto. Por lo tanto, si tienen una reunión de planificación en la próxima hora o dos, no podrán avanzar en la solución del problema, ya que la mayoría de ellos tardan mucho más.

Como escribió Paul Graham: “Una sola reunión de planificación puede arruinar un día entero al dividirlo en dos partes, cada una de las cuales es demasiado pequeña para hacer algo complicado”.

¿Cómo evitarlo? Esto se sabe desde hace mucho tiempo, de ninguna manera. Intente realizar dichas reuniones de planificación al comienzo del día o, por ejemplo, justo antes del almuerzo, para evitar pausas innecesarias durante el día.

2) Gerentes quisquillosos

Entre todos los tipos de gerentes, son los quisquillosos los que más reducen la productividad de los programadores. Sí, los gerentes exigentes suelen celebrar más reuniones y distraer a los programadores del trabajo con más frecuencia, pero esto no es lo único. Es más probable que desconfíen de los desarrolladores, quienes constantemente sienten que se cuestionan sus habilidades y capacidad para resolver un problema determinado. Esto destruye toda la motivación de los desarrolladores. Además, un gerente exigente puede ser la razón principal por la que un programador quiere irse, o al menos mudarse a otro equipo.

3) Incertidumbre de las tareas

Hay muchos ejemplos de tal incertidumbre. Informe de errores del tipo "No funciona, ¡arréglalo!" no contiene suficiente información para que el programador trabaje con ella. Por cierto, las plantillas de informes de errores pueden ayudar en este caso.

O una descripción vaga de la tarea, razón por la cual los desarrolladores comienzan a hacer lo que creen que es correcto. Y luego tienen que empezar todo de nuevo, después de que el gerente haya descrito la esencia de la tarea con más detalle.

Aquí también se aplica una priorización poco clara. En ausencia de prioridades claramente definidas, el desarrollador dedicará tiempo a pensar si ha priorizado correctamente el trabajo. Y si también escucha una pregunta del gerente por qué está trabajando en esta tarea en particular (aunque no se han identificado las prioridades) ... Bueno, ya lo entiende, el deseo de trabajar está cayendo.

4) “Gestión de gaviotas”

¿Alguna vez has oído hablar de algo así? Aquí es cuando los gerentes no están involucrados en el trabajo en absoluto, pero... a veces simplemente se abalanzan para arruinarlo todo. “Esto está mal, esto también, y esto se ve mal”, etc., y luego vuelven a volar. Tengo que admitirlo, me gusta lo bien que se junta la imagen, pero, desafortunadamente, esto sucede con mucha más frecuencia de lo que nos gustaría. Este comportamiento dificulta mucho el trabajo de los programadores.

5) Codicia de alabanza

¿Alguna vez has conocido a un gerente o desarrollador que se lleva todo el crédito por el trabajo que has estado haciendo en las últimas semanas? Los desarrolladores valoran la competencia por encima de todo. Si te apropias de los méritos de otra persona, entonces te apropias de la competencia, al mismo tiempo que se la quitas a un colega. Este factor ocupa un lugar bastante alto en la lista porque, en mi opinión, crea tensión en el equipo, lo que mata por completo la productividad del equipo por un tiempo.

6) Entorno - ruido, movimiento, disposición del espacio de trabajo...

Puede parecer extraño para aquellos que no trabajan como programadores, pero el entorno en el que trabaja el desarrollador tiene una influencia muy fuerte en su trabajo. Pequeñas cantidades de ruido blanco, como automóviles y camiones que pasan, ayudan a los programadores a concentrarse mejor. Por lo tanto, ¡muchos de nosotros trabajamos con auriculares! Recientemente descubrí  RainyMood . ¡Es bastante genial!

Además, si el lugar de trabajo está dispuesto de tal manera que alguien está constantemente caminando, se hace muy difícil concentrarse. O si las pantallas de las computadoras están colocadas de manera que el gerente pueda verlas todo el tiempo... Bueno, eso solo aumenta el estrés adicional y aumenta las posibilidades de que te interrumpan mientras estás en el trabajo.

7) Propagación del marco

La fluencia del alcance en la gestión se refiere a los cambios no controlados dentro de un proyecto. Esto sucede cuando el alcance no está claramente definido o a nadie le importa.

¡Esta expansión convierte las solicitudes simples en tareas terriblemente complejas y que consumen mucho tiempo! ¡Y la mayoría de las veces esto ya sucede en el proceso de desarrollo! Por ejemplo:

Versión 1 (antes del desarrollo):  solicitud:  "Mostrar un mapa del área"

Versión 2 (cuando la versión 1 está casi completa):  solicitud: "Mostrar un mapa 3D del área"

Versión 3 (cuando la versión 2 está casi completa):  la solicitud vuelve a cambiar a "Mostrar un mapa 3D del área que el usuario puede desplazarse"

8) El proceso de formación de requisitos técnicos.

A primera vista, esto puede parecer extraño, pero de hecho, este factor es muy fácil de entender. Si un equipo de desarrollo prioriza a un equipo sin evaluar el interés del consumidor en ciertas funciones (a través de comentarios de los clientes o de otra manera), y los programadores ven que la mayoría de las funciones simplemente no se utilizan, pueden pensar que su trabajo es inútil y perder la motivación. Todos queremos sentir que estamos haciendo un trabajo útil, y eso es probablemente aún más importante cuando se trata de programadores.

9) Descuido de la deuda técnica

La deuda técnica es la decisión deliberada de lanzar un producto que no es perfecto o escribir un código que no es el mejor para lanzar un producto más rápido. El uso de la deuda técnica es inevitable y, a corto plazo, puede acelerar el desarrollo de software. Sin embargo, a la larga, esto conduce a la complejidad del sistema, lo que ralentiza el trabajo de los programadores. Los no programadores suelen subestimar la pérdida de productividad en esta situación y siempre quieren avanzar, lo que puede acabar siendo un problema.

Pero si nunca piensa en refactorizar, eventualmente afectará no solo la productividad, sino también la calidad del producto.

10) Variedad de herramientas y equipos aplicados.

Los desarrolladores usan muchas herramientas todos los días para codificar, cargar y fusionar código. Cuanta más automatización, mejor. Todos entienden que el uso de herramientas de desarrollo "antiguas" afectará negativamente la productividad. También importa si el programador trabaja en una computadora con una pantalla grande o en una computadora portátil. Teniendo en cuenta el costo del hardware y los salarios de los programadores, incluso un aumento del 5% en la productividad ya valdría la pena cualquier inversión en esta etapa. Solo proporcione a sus desarrolladores las herramientas y el equipo que necesitan (el equipo es diferente para todos, pero las herramientas son las mismas para todo el equipo).

11) Comentarios

Cuando aprendemos a escribir código, inmediatamente se nos dice que escribamos comentarios con frecuencia. Se nos enseña que es mejor tener demasiados comentarios que muy pocos. Desafortunadamente, muchos programadores se equivocan al creer que deberían comentar cada línea de su código. Por lo tanto, a menudo puede ver código como este:

r = n / 2; // Set r to n divided by 2
// Loop while  r — (n/r) is greater than t 
while ( abs( r — (n/r) ) > t ) { 
  r = 0.5 * ( r + (n/r) ); 
  // Set r to half of r + (n/r)
}

¿Entiendes lo que se supone que debe hacer este código? Yo tampoco entiendo. El problema es que hay muchos comentarios que describen lo que hace el código, pero ni un solo comentario sobre por qué lo hace. Si se descubre que un programa tiene un error y ve un código como este, ni siquiera sabrá por dónde empezar.

12) Plazos increíblemente ajustados

El último factor está relacionado con el hábito de los gerentes de preguntar a los desarrolladores sobre los posibles plazos aproximados para la entrega del proyecto, luego obligarlos a reducir estos plazos tanto como sea posible, y luego sin razón considerarlos como la fecha límite. Además, los gerentes creen que dado que los propios programadores "establecen" dichos plazos aproximados, consideran que este es el plazo del proyecto y, por lo tanto, estos plazos ya pueden transferirse a la alta dirección.

No sorprende que los desarrolladores consideren que estos plazos son irrazonablemente cortos. Esto crea tensión y dificulta la concentración.

¿Qué tan únicos son estos factores para los programadores?

Si observa estos 12 factores, también son bastante aplicables a otras profesiones. Es solo que la influencia de todos estos factores es más importante para los desarrolladores, ya que necesitan una concentración total para hacer su trabajo.

Si reconociste a tu empresa en alguno de los momentos descritos en el artículo, quizás te interese hablar con tus programadores. Habla con ellos, averigua si hay algún problema y cómo se puede solucionar. Digan lo que digan, es muy importante confiar en su opinión y sus comentarios. Y aunque las tecnologías de hoy son muy diferentes a las de hace 30 años, la esencia sigue siendo la misma. Al pensar en la productividad, nunca se debe olvidar el factor humano. Discuta su flujo de trabajo, hábitos y entorno con su equipo y deje que lo guíen sobre cómo lograr la mejor productividad y eficiencia.

Compartir:
Categorías: Opinión

0 comentarios

Deja una respuesta

Marcador de posición del avatar

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.