Nadie requerirá que el desarrollador escriba código sin acceso a una computadora, pero muchas compañías creen que de alguna manera debe trabajar sin la capacidad de utilizar plenamente sus capacidades mentales. Y esto es casi tan poco realista.
Entonces, revisemos una lista de doce cosas que evitan que los desarrolladores entren en un estado de flujo y brinden la máxima productividad. Intentaré pasar de lo más importante a lo menos significativo. ¡Sugiere tus opciones y comentarios!
Si alguien duda de si vale la pena gastar dinero y esfuerzo en esto, es suficiente recordar cuánto pagan los programadores. ¡Incluso un aumento del 10% en la productividad es mucho en efectivo!
1) Reuniones y otras distracciones
En mi opinión, distraer al desarrollador es la forma más segura de matar su productividad de raíz. No puede simplemente tomar y continuar desde el lugar donde fue interrumpido. Primero necesita involucrarse nuevamente en el proceso, y luego pasar por toda la cadena de pensamientos hasta el momento correcto; esto solo puede llevar media hora o más. Y cuanto más ocurren tales interrupciones, más irritación se acumula, menor es la calidad del trabajo, más a menudo aparecen los errores, y esta lista puede continuar.
“Cuanto más me distraigo cuando trato de comenzar una tarea, más tiempo comienza a transcurrir entre intentos. Si me han detenido toda la mañana, no hay nada de sorprendente que el día haya resultado improductivo "- Desarrollador anónimo con Reddit
¿Y qué hay de la reunión? Su única diferencia con otras distracciones es que se planifican por adelantado. Y eso solo empeora la situación. Es difícil para un programador avanzar en la resolución de un problema si espera una interrupción en el trabajo por adelantado. Por lo tanto, si en una o dos horas tiene que ir a la reunión de planificación, lo más probable es que no pueda hacer nada significativo para ninguno de sus proyectos; después de todo, la mayoría de las tareas de ingeniería requieren más tiempo.
Como dijo Paul Graham: "Una reunión puede matar medio día: el tiempo se divide en dos períodos, durante los cuales no se puede hacer nada serio".
¿Cómo evitar este estado de cosas? Todo se ha pintado en esto durante mucho tiempo, por lo que no hay excusas. Solo necesita colocar los cepilladores al comienzo del día o, por ejemplo, justo antes de la cena, para no tener que distraer a las personas del trabajo sin necesidad.
2) nitpicking
De todas las variedades de gerentes, aquellos que intervienen por cualquier motivo, quizás el peor impacto en la productividad de los empleados. Por supuesto, esto también se ve afectado por el hecho de que este tipo en particular está especialmente inclinado a organizar un montón de reuniones y exige la atención de los desarrolladores por razones imprevistas. Pero este no es el único punto. Tales acciones muestran una falta de confianza y, como resultado, las personas tienen la sensación de que se les considera incapaces de cualquier cosa y ponen en duda sus habilidades profesionales. Incluso si el programador todavía tiene algo de motivación para trabajar a pesar de las interminables interrupciones, esa actitud la desanimará por completo. Las consecuencias no se limitan a una caída en el rendimiento. Los gerentes intrusivos a menudo obligan a los empleados a abandonar la empresa, o al menos el equipo.
3) poco claro
La falta de claridad puede ilustrarse con muchos ejemplos diferentes. Por ejemplo, un informe de error en el espíritu de "No funciona aquí, ¡arréglalo!" obviamente, no brinda a los desarrolladores toda la información necesaria para el trabajo. Por cierto, en este caso particular, la introducción de una plantilla para informes de errores puede ayudar.
U otro caso: requisitos vagos para alguna parte del producto. Con tales desarrolladores introductorios, simplemente comience a hacer lo que ellos mismos imaginan, y luego un gerente viene con una descripción más detallada del comportamiento esperado del usuario, y todos tienen que comenzar de nuevo.
Las prioridades establecidas indistintamente pertenecen a la misma categoría. Los programadores pasan mucho tiempo haciendo estallar sus cerebros con lo que deberían comenzar, aunque evitar esto sería muy simple. Bueno, si alguna vez tienen que informar al gerente por qué están involucrados en esto y no en esto (a pesar de que nadie estipuló la orden), puede estar seguro de que esto los hará geniales.
4) Gerentes de gaviotas
¿Has oído hablar de esto? Hay gerentes que no participan en absoluto en el flujo de trabajo ... excepto en los momentos en que de repente deciden zambullirse en alguien y cometer un error. "Esto no es bueno, y esto también, pero no se ve en absoluto", y continuó. Debo admitir que me gusta la comparación, pero el fenómeno detrás de esto es mucho más común de lo que nos gustaría. Este comportamiento afecta muy mal a los desarrolladores: muchos tienen que trabajar durante horas y alguien abandona la transmisión durante días completos.
5) Robo de laureles
¿Te ha sucedido alguna vez que uno de los gerentes u otros programadores se atribuyeron a sí mismo lo que luchaste durante varias semanas? Los desarrolladores ponen su profesionalismo por encima de todo. Robar los méritos de otras personas es como negarle a una persona la competencia para inflar la suya. Puse este punto lo suficientemente alto porque creo que tales cosas conducen a una situación muy tensa, que puede durante mucho tiempo "disminuir" el rendimiento de todo el equipo.
6) Mobiliario: ruido, movimiento, diseño del espacio de trabajo ...
Puede parecer extraño para personas de otras profesiones, pero para los programadores, el entorno decide mucho en el curso del trabajo. Digamos que el ruido blanco, el zumbido del aire acondicionado, el zumbido de los automóviles y camiones de la calle, les ayuda a concentrarse mejor. ¡Es por eso que muchos de nosotros trabajamos con auriculares! Por cierto, recientemente descubrí RainyMood, ¡una gran cosa!
Sin embargo, si la oficina está diseñada para que siempre haya algún movimiento alrededor de la persona, esto tendrá el efecto contrario. Y si, además, los monitores se instalan de tal manera que los gerentes ven constantemente lo que está en la pantalla, esto crea un estrés innecesario y razones innecesarias para distraer a los desarrolladores de los negocios.
7) Límites de proyecto compensados
En la gestión de proyectos, este término se utiliza para situaciones en las que los volúmenes de proyectos están creciendo de manera incontrolable. Esto generalmente ocurre cuando inicialmente no estaban estrictamente definidos y documentados o no fueron monitoreados en el proceso.
Debido al desplazamiento de las fronteras, las consultas relativamente simples se convierten en monstruos confusos que consumen mucho tiempo. Y en la mayoría de los casos, esto comienza cuando el producto ya está en desarrollo.
Tomemos por ejemplo una función simple:
- Primera versión (antes de la implementación): la función se define como "Mostrar mapa de ubicación"
- La segunda versión (cuando la primera iteración está casi terminada): la descripción cambia a "Mostrar mapa de ubicación 3D"
- Tercera versión (cuando la segunda iteración está casi terminada): la descripción cambia a "Mostrar un mapa de ubicación 3D en el que el usuario podría moverse"
8) Proceso de determinación de características del producto
Puede parecer incomprensible a primera vista, pero de hecho, todo es simple. Si las personas a cargo del producto priorizan sin probar sus hipótesis (a través de comentarios o de cualquier otra manera) sobre el interés de la audiencia en ciertas oportunidades, y los desarrolladores ven que estas oportunidades simplemente no se están utilizando, entonces tendrán la sensación de que su trabajo no tiene sentido y la motivación colapsará. Todos queremos sentir que estamos dejando una marca en el mundo, ¡y esto es especialmente importante para los desarrolladores!
9) Ignorando la deuda técnica
El deber técnico es una decisión consciente de permitir cierto estiramiento en la elección de soluciones y la escritura de código para implementar el producto más rápido. Una cierta cantidad de deuda técnica surge inevitablemente en cualquier proyecto y puede ayudar con los plazos en distancias cortas. Sin embargo, a la larga, aumenta la complejidad del sistema y, por lo tanto, ralentiza a los desarrolladores. Las personas lejos de la programación a menudo subestiman el impacto de estos procesos en la productividad y requieren avanzar sin parar, en esta situación comienzan a surgir problemas. Si la refactorización siempre permanece fuera de la lista de prioridades, no solo se verá afectada la productividad de los empleados, sino también la calidad del producto.
10) Una variedad de herramientas y equipos
Los desarrolladores usan diariamente muchas herramientas para escribir, empujar y fusionar código. Cuanto más logran automatizar procesos, mejor. No hace falta decir que las herramientas antiguas tendrán un impacto directo en el rendimiento. También decide mucho sobre el trabajo que se está haciendo: en una computadora portátil o también en una pantalla adicional. Si comparamos los precios del hierro con los salarios de los programadores, ¡incluso un aumento del 5% en la productividad definitivamente pagará todos los costos! Solo necesita proporcionar al equipo los equipos y las herramientas que prefieran usar (para los equipos, la solución debe ser individual, para las herramientas colectivas).
11) Documentación de procedimientos
En el proceso de enseñanza de la programación, todos aprendimos que debe comenzar a agregar comentarios al código lo antes posible y con la mayor frecuencia posible. La idea era que sería mejor si hubiera demasiados comentarios que no suficientes. Desafortunadamente, muchas personas malinterpretaron esto y decidieron que cada línea necesitaba explicación. Es por eso que tenemos muestras como esta, del
artículo de Jeff Atwood "Código sin comentarios":
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 hace este código en general? Así que no entendí nada. El problema es que aquí se dice mucho sobre cómo funciona todo, pero ni una palabra sobre por qué esto es necesario. Si suponemos que se produjo un error en el programa y encontró un fragmento de código de ese tipo bajo el capó, no le habría ayudado a descubrir la situación.
12) Plazos extremadamente ajustados
El último punto está relacionado con la tendencia de los gerentes a pedirles a los desarrolladores que estimen aproximadamente cuánto tiempo necesitarán, luego los presionen para subestimar esta estimación, ¡y luego igualen mágicamente la fecha final con la fecha límite! Al mismo tiempo, los gerentes incluso creen que dado que los desarrolladores "establecen los plazos ellos mismos", significa que se inscribieron en el plazo correspondiente y deberían considerarse una opción finalmente aprobada que puede transferirse a la alta gerencia.
Los desarrolladores creen que ese plazo es una locura total y es imposible cumplirlo; Hay discordia en el equipo y nadie puede concentrarse.
¿Pero se trata solo de desarrolladores?
Si observa todos estos 12 puntos, notará que son, en su mayor parte, relevantes para todos los involucrados en proyectos. Es solo que en el caso de los programadores, son especialmente críticos, ya que su trabajo requiere una inmersión profunda en el proceso.
Si observa que algunos de los puntos mencionados son típicos para su empresa, sería bueno seguir esta lista con el equipo de desarrolladores, establecer un diálogo con ellos, averiguar dónde surgen los problemas y cuál es la mejor manera de resolverlos. Digan lo que digan, es extremadamente importante tomar en serio esta retroalimentación y comentarios. Durante los últimos treinta, mucho ha cambiado en términos de tecnología, pero el principio básico del trabajo en equipo sigue siendo el mismo: cuando se habla de rendimiento, es necesario tener en cuenta el factor humano. Mejore sus procesos de trabajo, entorno, hábitos de equipo y bríndeles la oportunidad de decirle cómo lograr la máxima productividad.