¿Reemplazar un desarrollador?

Scrum, cuando se utiliza incorrectamente, es una experiencia lamentable. Esta situación lleva al desarrollador a padecer un bucle de decepciones desde que se levanta, comenzando su jornada con angustia, esforzándose por cambiar esa espiral diaria que le lleva a terminar cada día mucho más tarde que el anterior. A medida que el progreso del sprint se estanca y la línea de progreso se mantiene preocupante, por encima de la curva ideal esperada, el desarrollador empieza a culparse a sí mismo. "No estoy trabajando lo suficientemente duro/rápido/eficaz, mi cliente/Jefe se va a enfadar". Así que trabaja más horas, desarrollando una fuerte adicción a la cafeína y descuidando sus necesidades básicas de cuidado personal (el equipo del gimnasio está cada vez más polvoriento...). Cuando por fin el sprint termina, con las historias (HU) casi culminadas, nos encontramos con un Propietario de Producto (Product Owner , PO) un poco decepcionado que tiene que explicar a su cliente porque no tiene todo lo comprometido y a un desarrollador cansando, desmotivado y recordando la última oferta que le hizo una empresa la tarde anterior por linkedin... valorando si quizá debería contestarles...

Un Product Manager (PM) poco inteligente pensará "¿Y qué? Este desarrollador fue contratado para entregar resultados, y se espera que haga precisamente eso. Si no puede cumplir los compromisos del sprint, lo reemplazamos con algún otro que sí pueda, que tengo varios cv de chavales de un bootcamp que participé el otro día que son unos cracks". Lo que este "profesional" no entiende es lo tremendamente cara que puede resultar la gran rotación de los desarrolladores. La mayoría de los estudios sobre el coste de reemplazo de un desarrollador calculan un coste de 0,75 a 2 veces su salario anual. Por tanto, para un desarrollador que gana 40.000 euros, el coste de reemplazar realmente su valor oscila entre los 30.000 y 80.000 €. ¿Por qué los costes de rotación son tan altos?

Conocimiento es poder

En el desarrollo de software, el conocimiento es realmente poder, y este conocimiento se extiende mucho más allá de ser un "hacker". Alcanzar un nivel alto como desarrollador significa dominar múltiples aspectos que son la barrera principal entre un buen desarrollador y alguien que sabe programar.

Conocimientos de ingeniería

La característica más obvia de un buen ingeniero (un desarrollador es un ingeniero, crea soluciones) es su capacidad para desarrollar soluciones seguras, usables, mantenibles, ampliables, escalables, viables, eficaces, integrables, eficientes y comprobables para satisfacer requisitos complejos en cualquier lenguaje o tecnología que se adapte a su misión. Esto requiere una serie de habilidades que van desde tener una sólida visión arquitectónica, a aplicar soluciones eficaces de forma reflexiva, pasando por probar a fondo la respuesta del sistema a cualquier escenario imaginable (porque si un usuario final puede romperlo, lo hará), hasta comprender y reparar rápidamente la causa raíz de los errores. Por eso la ingeniería es un campo tan bien pagado.

Por suerte para muchas empresas que "tiran de talonario", los ingenieros llevan estas habilidades de una  a otra, perfeccionándolas a lo largo de su carrera. Casi siempre puedes encontrar otro buen ingeniero si tu oferta es lo suficientemente buena. Por desgracia para este tipo de empresas, estas habilidades sólo representan una parte de lo que hace a un gran ingeniero.

Conocimiento de Negocio

La mayoría de las empresas intentan que con una breve explicación de negocio el desarrollador sea capaz de crear una solución que cubra sus expectativas. Cosa que nunca ocurre y se producen las desconfianzas, creándose un muro insalvable entre IT y negocio. Los Product Managers (no son generalmente PO) conocen las necesidades de los usuarios finales, sueñan con una visión del producto, pero no son capaces de redactar requisitos detallados, con los escenarios y datos suficientes para que el desarrollador pueda dimensionar y dar un alcance estimado como para definir una arquitectura viable, sin embargo estos PM son el Jefe y mandan sobre el equipo de desarrollo.

Este enfoque tiene su "lógica" pues parece ofrecer al PM un control mas directo sobre el desarrollo, sin embargo es pura ignorancia de lo que supone el proceso de creación de un producto software. Este método es también el preferido de desarrolladores con grandes habilidades de persuasión, con fama de gurus, y de muchas empresas de Proyectos o consultoría, que acaban redirigiendo el proyecto hacia su propia visión personal, obligando al cliente a asumirlas.  Por desgracia, un proyecto tras otro ha demostrado que este enfoque no suele funcionar (80% de fracaso).

El lenguaje de negocio es drásticamente diferente del lenguaje de código, y aunque las herramientas BDD como Cucumber han intentado mitigar este problema, siempre hay requisitos implícitos que los Product Managers no expresan en palabras, y se convierten en requisitos malinterpretados por el desarrollador.  Aquí es donde el rol del Product Owner adquiere toda su importancia. El conocimiento del negocio es una tarea para la que está preparado, y posee las herramientas para transmitir esas necesidades en un formato apropiado para facilitar al desarrollador cuyo expertise debe ser el técnico.

Los problemas asociados a desarrollar el Conocimiento de Negocio representa el principal coste de la rotación de desarrolladores. Las buenas prácticas de desarrollo / ingeniería se transfieren de una empresa a otra, y cualquier desarrollador cualificado puede aprender nuevos lenguajes/frameworks/ tecnologías/sistemas. Sin duda, el Conocimiento de Negocio que un buen desarrollador adquiere durante su tiempo en la empresa pueden hacer maravillas a la hora de aportar valor en el futuro. Sin embargo, esto supone un esfuerzo que los expertos miden en 18 meses... por tanto, sabiendo que la rotación media de un desarrollador es de 6-9 meses... ¿Compensa?

Un desarrollador experto en un negocio no sólo es mejor que un recién contratado a la hora de interpretar con precisión los requisitos, sino que también puede ayudar a asesorar al propietario del producto sobre cómo ofrecer valor de forma eficaz, ya que conoce tanto lo que quieren los usuarios como el trabajo necesario para ofrecerlo. Perder a estos desarrolladores es perder una gran parte de conocimientos útiles. Pero difícilmente alcanzará el conocimiento de negocio que un PO adquiere en el mismo periodo y con menor rotación.

Habilidades interpersonales

Esta habilidad o Conocimiento también se adquiere con las experiencias y vivencias al pasar de empresa en empresa y es parte fundamental de la labor de un buen desarrollador establecer contactos y conexiones en el campo del software que le ayuden a mejorar tanto técnica como profesionalmente.

Nuestra sociedad describe a los programadores como bichos raros con sobrepeso, aversión a la luz natural, adicción enfermiza al café e incapacidad para relacionarse normalmente (perfil asperger). Aunque esto puede representar a muchos miembros de nuestra comunidad, pero el desarrollo atrae a todo tipo de personas, pues en un proyecto se requieren múltiples perfiles y roles, y hay mucha comunicación interpersonal en la vida diaria de un desarrollador profesional. Sí, para muchos demasiada. Además de trabajar eficazmente con un equipo de personas muy cualificadas y de orígenes muy diferentes, en muchas empresas los desarrolladores tienen que acudir constantemente a otros departamentos, en algunos casos por temáticas ajenas totalmente a su actividad. Sin duda establecer vínculos con esas personas puede ser muy ventajoso en algún momento pero es un esfuerzo (innecesario en su opinión) que el desarrollador puede no requerir (no tienen problema de empleo) y robarle ese tiempo precioso que requiere para terminar el sprint comprometido.

La rotación es cara

Las organizaciones deben tener en cuenta la presión a la que someten a estos profesionales con familias, aficiones, gatos, perros y musarañas (la afición a las mascotas es terrible). Así que, aunque no estoy diciendo que mimemos a los desarrolladores más que a los demás, si que hay que ser consciente que su actividad en el negocio es vital, aunque sea por un tiempo determinado, y que un manager no suele poseer los conocimientos para comprender en qué consiste el esfuerzo en un proyecto de desarrollo. Y la costumbre es: donde no domino, entonces presiono. Este modelo de gestión de personal "churn-and-burn"  no es la práctica más aconsejable en el desarrollo de software.

Nuestra experiencia en los Squads de nuestros clientes es contundente: es mejor contratar a una persona más, que facilite esa actividad al desarrollador, que echarlo y buscar uno nuevo que sea capaz de cumplir todas las funciones que el proyecto requiere. Al final el proyecto termina antes y con mejor calidad y el desarrollador se siente agradecido de haberle ayudado a suplir esa carencia tan importante, y la habrá aprendido o mejorado para el siguiente proyecto.