¿Cuántos desarrolladores/as necesito? Esta pregunta se la hacen muchos directivos, sobre todo teniendo en cuenta que los retos macroeconómicos ejercen presión sobre los presupuestos. Sin embargo, determinar el tamaño adecuado de tu equipo técnico no es sencillo. Incluso si el instinto te dice que ampliar -o reducir- es el enfoque correcto, es importante profundizar en el papel que el trabajo de desarrollo está desempeñando dentro de tu organización y cómo interactúa y apoya a otros equipos y flujos de valor.
Hacer esto te ayudará a ganar confianza en que no sólo tus equipos tecnológicos están orientados hacia los objetivos de la organización, sino que también están bien equipados y respaldados para trabajar con eficacia. Para llegar a este punto, es importante formular las preguntas adecuadas que aborden el impacto tecnológico y la eficacia de la ingeniería. A veces eso requiere que nos replanteemos por completo las preguntas que queremos hacer; otras veces, esas preguntas sólo necesitan matización y aclaración. En cualquier caso, lo importante es que te ayuden a alinear mejor la actividad de los desarrolladores con los objetivos de la organización.
Pregunta #1:
¿Tenemos suficientes desarrolladores/as?
Preguntarte si tienes suficientes desarrolladores es una cuestión que muchas organizaciones probablemente se hayan planteado en algún momento de la última década, especialmente aquellas que han experimentado una transformación digital significativa. Aunque es una ansiedad comprensible, es el lugar equivocado para comenzar una investigación o debate. Esto se debe a que inmediatamente enmarca el problema en términos de números. A su vez, esto podría llevar a decisiones de contratación innecesarias. Esto no sólo tiene graves implicaciones financieras, sino que también puede perturbar la eficacia organizativa existente. Como señala Josh Bersin en el artículo al que hemos enlazado, cuando se contrata a gente nueva, inevitablemente hay que formarla e incorporarla. Incluso los equipos más productivos y eficaces tienen que hacer ajustes y cambios para integrar a los nuevos miembros del equipo, lo que merma su eficacia.
En lugar de preguntar si tienes suficientes desarrolladores, obtendrás resultados más productivos si replanteas el problema. Pregunta, por ejemplo:
¿Los equipos de desarrollo actuales cumplen eficazmente los resultados empresariales deseados?
Para ser más eficaces, ¿existen palancas adicionales que puedan ayudarnos a mejorar estas métricas, sin añadir más desarrolladores/as?
Estas palancas son cualquier cosa que ayude a los equipos de desarrollo a hacer más con menos. Una opción es centrarse en mejorar la eficiencia de los procesos de desarrollo. ¿Existen, por ejemplo, formas alternativas de trabajar que puedan garantizar que las decisiones se tomen con mayor rapidez? ¿Podría remodelar las estructuras de los equipos para garantizar que la información llega a ellos de forma más eficaz, dándoles el contexto y el enfoque que necesitan? Otra opción son las herramientas. Una plataforma interna de desarrollo, por ejemplo, puede eliminar tareas repetitivas y sin valor añadido.
Pregunta #2: ¿Estamos pagando más de lo necesario por nuestros esfuerzos de desarrollo?
Los equipos de liderazgo deben prestar siempre mucha atención al ROI: es su responsabilidad. Sin embargo, es importante que las preocupaciones sobre el ROI no se conviertan en debates inútiles sobre si se está pagando demasiado a los empleados. El talento técnico -especialmente el talento técnico senior- es escaso. La rotación puede ser costosa; los despidos no solucionarán este problema. Una cultura de desconfianza sólo conseguirá que las personas con talento se marchen a otra parte, agravando los problemas que estabas intentando resolver.
Entonces, ¿qué es lo que realmente se plantea aquí? Puede ser útil dejar de lado por un momento la cuestión de los costos y centrarse en la cuestión de la velocidad de entrega y el despilfarro. Teniendo esto en cuenta, considera la posibilidad de replantear la pregunta inicial de dos maneras diferentes:
¿Dónde se produce el despilfarro en nuestros procesos y operaciones de ingeniería de software? ¿Cómo podría reducirse ese despilfarro?
¿Están capacitados los equipos de desarrollo para añadir valor de forma autónoma y priorizar su propio trabajo?
Como en el caso anterior, estudiar los procesos y sistemas existentes es un punto de partida útil. Aunque esto puede hacerse de arriba abajo, también es beneficioso partir de la experiencia de los propios desarrolladores. Es posible que muchos luchen contra la complejidad operativa o la falta de claridad sobre la visión y la intención de un trabajo. Si aparecen este tipo de problemas, es esencial que los equipos de dirección trabajen con los desarrolladores para devolverles la autonomía y permitirles resolver los problemas por sí mismos, en lugar de esperar los edictos de una función de gestión centralizada.
Pregunta #3: ¿Por qué el software que crean nuestros desarrolladores no da el resultado que queríamos?
Incluso en la organización más ágil, la creación y entrega de software puede llevar tiempo. Cuando no parece tener el impacto previsto o esperado, puede ser descorazonador. Cuando esto ocurre, es importante abstenerse del impulso de culpar a los más cercanos al producto. Esto se debe a que las razones del fracaso son siempre polifacéticas y complejas. A menudo hay múltiples causas o explicaciones, que van desde la alineación estratégica hasta la comunicación interna.
Teniendo esto en cuenta, es importante profundizar. Hazte preguntas como:
¿En qué medida nos hemos centrado en las necesidades de los usuarios?
¿Hemos entendido bien esas necesidades y podríamos haber hecho algo diferente?
Si creemos que responde a esas necesidades, ¿estamos comunicando sus ventajas con eficacia? ¿Hemos prestado la debida atención a la incorporación y adopción?
Estas preguntas reconocen que el trabajo de desarrollo se sitúa en una intrincada -y dinámica- red de prácticas organizativas y necesidades de usuarios externos que contribuyen y conforman el éxito de una iniciativa determinada. Teniendo esto en cuenta, es importante prestar atención a las funciones y papeles de apoyo que rodean a los equipos de desarrollo. Explore qué se puede hacer para garantizar que los implicados en las iniciativas puedan trabajar de forma realmente colaborativa e iterativa.
Pregunta #4: ¿Podemos reducir o reconvertir el número de desarrolladores que mantienen algunas de nuestras capacidades de software internas y heredadas?
A menudo, sólo una pequeña parte del trabajo de desarrollo que tiene lugar dentro de una organización se centra en software nuevo ("greenfield") y orientado al cliente. La mayor parte se dedica a la gestión de la deuda técnica de los sistemas existentes o al soporte del software interno. Esto puede ser un punto ciego a la hora de dimensionar correctamente el equipo tecnológico: es demasiado fácil centrarse en los productos en los que el valor añadido es especialmente visible.
Por tanto, es importante prestar atención al valor oculto de los distintos tipos de trabajo de desarrollo. Sin embargo, esto no significa que el trabajo en este ámbito tenga que estar delimitado: preguntarse cómo se puede hacer este trabajo de forma más eficaz (de nuevo, cómo los equipos pueden hacer más con menos) es tan importante aquí como en los proyectos de desarrollo más orientados al producto.
En otras palabras, haz preguntas como:
¿Cómo podría nuestro software interno aportar más valor a la organización?
¿Podría hacernos más colaboradores o ayudarnos a tomar mejores decisiones?
¿Cómo podríamos hacer evolucionar el software heredado para facilitar su mantenimiento? ¿Contiene valor que no hemos sabido desbloquear?
Al plantear este tipo de preguntas, no se trata simplemente de desestimar la importancia del trabajo de mantenimiento o de tratarlo como algo inevitable o intocable.
Siempre hay otras formas de hacer las cosas. El software interno es una parte necesaria del funcionamiento cotidiano de toda empresa, pero es un problema de producto no muy distinto de los que intentas resolver para los usuarios externos. Del mismo modo, la deuda técnica hay que pagarla, pero se puede pensar bien cómo hacerlo.
Pregunta #5: ¿Por qué baja el valor de nuestro software?
El valor de un programa informático suele coincidir con la atención que se le presta. Si notas que empieza a disminuir, centrarte en la atención -tanto en cantidad como en calidad- es un buen punto de partida para poner las cosas en su sitio. Esto no quiere decir que no debas preguntarte por qué está disminuyendo el valor de tu software, sino que esa pregunta en concreto se centra implícitamente en la explicación en lugar de en las soluciones.
En su lugar, hay que replantear la pregunta de forma que ayude a comprender mejor las deficiencias de atención:
¿Cómo han cambiado las necesidades de los usuarios? ¿Ha cambiado el mercado? Si es así, ¿por qué no hemos sido capaces de reconocerlo? ¿Qué podemos hacer de forma diferente?
¿Cómo podemos mejorar los circuitos de retroalimentación entre clientes, producto y diseño y desarrollo de software?
¿Se trata de un problema que podemos resolver con movimientos tácticos o requiere un cambio estratégico más amplio?
Este tipo de preguntas no sólo permiten atacar el problema de forma más exhaustiva, sino que también están orientadas a la solución. En última instancia, si quieres asegurarte de que tus desarrolladores son eficaces, también tienes que ser eficaz a la hora de identificar y resolver retos estratégicos: eso da a los tecnólogos una base desde la que pueden estar seguros de que están añadiendo valor.
Plantear nuevas preguntas para encontrar mejores soluciones
No existe una solución sencilla a la cuestión del dimensionamiento adecuado de los equipos tecnológicos. Pero eso no significa que no pueda responderse. Si te comprometes con los retos a los que se enfrentan tus equipos tecnológicos y consideras detenidamente cómo están alineados con los objetivos de la organización, puedes ayudar a garantizar que estás sacando el máximo partido de tus desarrolladores/as.
Esto empieza con las preguntas que se formulan y su eficacia para descubrir soluciones que mejoren la eficacia de los desarrolladores. Cuando se hace bien, se puede estar seguro de que se dispone no solo del tamaño adecuado, sino también de la plantilla tecnológica con la forma adecuada para ofrecer resultados coherentes.