Profesionales extremos.

Columna Tecnológica por José Miguel Santibáñez

En cuanto la computación dejó de ser un espacio propio de científicos y se empezó su uso en distintas empresas, fue evidente que el desarrollo de aplicaciones (aún las que inicialmente eran muy limitadas) requerían de un proceso de desarrollo controlado, con claridad de requerimientos y, siguiendo la tradición de la ingeniería, planificadas, bien diseñadas y construidas según especificaciones. Pero claro, eso no garantizaba que la aplicación desarrollada cumpliera con las necesidades de la empresa, sólo permitía distinguir, en el caso de que no cumpliera, en dónde se había cometido el error, el que generalmente pasaba por el entendimiento de las especificaciones: analistas y diseñadores habían entendido algo diferente de lo que quería decir el cliente. Y esto ocurría, normalmente, cuando el proceso estaba llegando a su término (generalmente, varias semanas después de la última reunión de “análisis de requerimientos”).

Con las mejoras técnicas (particularmente el aumento de velocidad de los computadores) empezó a surgir una tendencia diferente: el desarrollo ágil. Este tipo de desarrollo se caracteriza por tener una gran capacidad para adaptarse al cambio en las especificaciones, es decir, en cuanto se detecta que una especificación no ha sido entendida de igual manera por el cliente que por los profesionales de la informática, simplemente se modifica el requerimiento y se rehace el código necesario.

Si bien las metodologías ágiles terminan desarrollando aplicaciones mucho más cercanas a las necesidades del cliente, hay que entender que su propia lógica (rehacer código) implica una planificación que asume tiempos mayores que las teorías previas. Por ello, una de las metodologías ágiles de mejor resultado, se denominó “Programación Extrema” (XP) que propone que para reducir al mínimo el aumento del tiempo, los programadores deben ser expertos, capaces de codificar un requerimiento en muy poco tiempo y mostrarle los resultados al cliente, para que éste los valide viendo la aplicación como va a quedar en definitiva (o para que se rehaga el código si no lo satisface).

Una metodología así, además es “liviana”, como los requerimientos se validan con los resultados (y no con un “plano de desarrollo” que era poco entendible para quienes no son informáticos) entonces el “plano” se reduce prácticamente a un dibujo a mano alzada. Lo cual resulta muy cómodo para muchos analistas, diseñadores y programadores.

Por ello, las metodologías ágiles han sido adoptadas por muchas empresas de desarrollo (y profesionales informáticos). Pero en el caso de XP, generalmente olvidan que se requiere que la empresa cuente con “programadores extremos” (término similar al de los “deportistas extremos” o “deportistas de alto rendimiento”). Si no se cumple con ese requerimiento, sólo se tiene un desarrollo lento, de baja probabilidad de éxito y con mínima documentación.

Lo curioso, es que pese a los múltiples fallos en proyectos de “programación extrema”, donde al igual que antes, los clientes sólo ven un resultado final al término del proyecto, el esquema no sólo sigue siendo aprovechado por muchos, sino que además, se ha extendido a otras áreas profesionales.

Hoy es posible ver “gerencia extrema” para la administración (prescinden de los procedimientos “engorrosos y burocráticos” en la búsqueda de resultados “rápidos”), “periodismo extremo” (dónde se “golpea” con la noticia y, muchas veces falla la verificación de fuentes o, peor aún, se inventan fuentes y para peor se eliminan las “defensorías del lector”), “educación extrema” (esta incluso promovida desde el ministerio de educación que exige revisar una cantidad de contenidos “mínimos” que en muchos casos no se alcanzan a cubrir, salvo en el papel) y al parecer, hoy tenemos algunas demostraciones de “policía extrema” (con varios ejemplos, pero donde el más evidente, está en la respuesta de Bomberos a la demanda de Mapfre: En el sitio del suceso donde había un vehículo chocado con carabineros atrapados en su interior, al llegar bomberos a rescatarlos, se encuentran con un único carabinero controlando el tránsito, pese a haber un helicóptero de la institución posado en la calle, situación que requiere, por procedimiento definido, de un mínimo de 5 efectivos controlando específicamente, el perímetro de seguridad).

Un viejo dicho hace presente que “la culpa no es del chancho”, pero en términos profesionales (todos salvo el último ejemplo) es un deber profesional el determinar las condiciones reales para poder cumplir con lo requerido. No se trata de simplemente “saltarse procedimientos engorrosos”, y aunque muchas veces puede ser necesario ajustarlos a las nuevas condiciones, esos procedimientos están definidos así por razones que, inicialmente, fueron consideradas válidas.

La gerencia extrema recuerda siempre la historia de aquél reino, donde después de un invierno especialmente crudo, la princesa ve una flor que aparece entre la nieve, emocionada llama a su padre para que disponga un guardia que evite que alguien dañe a la flor, y así el rey emite el decreto que dispone de un guardia punto fijo en medio del patio… El problema es que llegada la primavera y luego el verano, nadie se acuerda de la flor, pero el decreto permanece, y el guardia punto fijo sigue allí… Incluso años después.

Ahora que termina el año 2018, y muchos entramos en un proceso de “revisión de los puntos altos y bajos del año anterior (y previos)” quizá sería bueno darle una mirada a los procedimientos que tenemos definidos, y ver cuales siguen sirviendo, cuales merecen ser adaptados y cuales hay que desechar. La idea no es mala, pero hay que hacerlo con cuidado, asegurándose de contar con la gente idónea para cumplir.