El otro día, Jeremy Keith escribió que los problemas con el trabajo de rendimiento no son solo una cuestión de optimización y corrección de código, sino también de abordar los problemas de las personas:
Me llamó la atención que hay una serie de desafíos de desempeño. En un extremo del continuo, tiene problemas técnicos. Estos se pueden solucionar con soluciones técnicas. En el otro extremo del continuo, tienes problemas humanos. Estos se pueden resolver con discusiones, acuerdos, empatía y conversaciones (a menudo temidas o incómodas).
Creo que, como desarrolladores, tendemos a gravitar hacia los problemas técnicos. Ese es nuestro espacio seguro. Pero sospecho que se pueden obtener mayores ganancias al abordar los incómodos problemas humanos.
Definitivamente fue impactante saberlo cuando me uní a una empresa hace unos años y descubrí que había una montaña de trabajo de desempeño que no podía hacer solo. Empecé a tratar de enseñar a la gente sobre el rendimiento, así como a mantener el horario de oficina y a participar en proyectos y equipos que necesitaban ayuda. Pero me di cuenta de que todo este trabajo no ayudó. El sitio web en el que estaba trabajando en mi tiempo libre se estaba volviendo más lento, a pesar de mis mejores esfuerzos.
Frustrado y exhausto, un día me recliné en mi silla y me di cuenta de que no podía hacer todo este trabajo solo. El verdadero problema era este: no hay ningún incentivo para que la gente se preocupe. Si el rendimiento mejorara mágicamente en un diez mil por ciento, nadie en la empresa se habría dado cuenta. Los clientes se habrían dado cuenta, pero probablemente todos nosotros no. Excepto yo, porque soy un nerd.
En la última charla de Ethan Marcotte, describe este problema de la gente cuando se trata de sistemas de diseño:
La creación de componentes modulares no es el objetivo principal ni el beneficio principal de crear un sistema de diseño. Y lo que es más, un enfoque en los procesos y las personas siempre conduce a sistemas más sostenibles.
Los sistemas de diseño tienen que ver con un código front-end bueno y de calidad, al igual que el rendimiento. Pero si las personas dentro de una organización no están incentivadas para usar los componentes dentro de una biblioteca o hablar con el equipo de sistemas de diseño, entonces es cuando las cosas se vuelven locas rápidamente.
Quizás simplificaría un poco este problema de la gente: el código base es fácil de cambiar, pero los incentivos dentro de una empresa no lo son. Y, sin embargo, son los incentivos los que impulsan el tipo de código que se escribe: qué es aceptable, qué necesita arreglarse, cómo las personas trabajan juntas. En resumen, no se puede esperar que arreglemos el código sin arreglar también la organización.
Los incentivos más obvios son el dinero y las calificaciones de desempeño, o incluso la contratación de una persona o equipo dedicado a esta línea de trabajo en particular. Mejorar la visibilidad de los problemas de rendimiento y celebrar grandes logros es otra cosa que se puede hacer para cambiar el equilibrio y hacer que la gente se preocupe más por esta nueva área de especialización. Pero estas cosas realmente tienen que venir de arriba hacia abajo; no de abajo hacia arriba. Al menos eso ha sido cierto en mi experiencia.
Mi punto aquí es que no existe una solución única para solucionar el problema de los incentivos en las grandes organizaciones. Suena tonto, pero para hacer ese sitio web, los mayores obstáculos que hay que superar son esos incentivos. Si a nadie le importa el trabajo de rendimiento hoy, entonces gritar y gritar y ser un idiota no ayudará en absoluto.
Créame, he sido ese idiota.