¿Qué hago ahora? Planificar los cambios de diseño

Con bastante frecuencia me toca conversar con personas sobre sus diseños de sistemas, planes y arquitecturas. Y muchas veces esa conversación ocurre demasiado tarde, cuando los diseños ya están implementados o lo están parcialmente. Esto puede resultar muy frustrante si se ha determinado que el diseño en curso no es el ideal para la situación.

Comprendo la sensación de frustración que surge de una situación como esta, pero es algo a lo que quienes trabajamos en TI debemos enfrentarnos de manera muy habitual, y gestionar esta reacción de forma constructiva es una habilidad clave en TI. Debemos convertirnos en maestros de esta situación, tanto en lo técnico como en lo emocional. No debemos quedar paralizados por ella; es una situación natural que todo profesional de TI vivirá de forma periódica. No debería ser desalentadora ni paralizante, pero es muy comprensible que pueda sentirse así.

Una razón clave por la que experimentamos esto tan a menudo es que la TI es un campo enorme, con un gran número de variables que considerar en cada situación. También es un campo sumamente creativo, en el que puede haber numerosos enfoques viables para cualquier problema dado. Que exista siquiera una única opción «mejor» rara vez es cierto. Normalmente hay muchas opciones que compiten entre sí. A veces están muy relacionadas; a veces estas opciones son drásticamente distintas, lo que hace muy difícil compararlas de forma significativa.

Otra razón clave es que los factores cambian. Puede ser que salgan a la luz nuevas técnicas o información, que se lancen nuevos productos, que se actualicen productos, que cambien los precios o que cambien las necesidades del negocio cerca del momento, o incluso durante, los procesos de toma de decisiones y de diseño. Este ritmo de cambio no es algo que nosotros, como profesionales de TI, podamos aspirar a controlar jamás. Es algo que debemos aceptar y afrontar lo mejor que podamos.

Otra cosa que con frecuencia veo que se pasa por alto es que una solución que era ideal cuando se concibió puede no serlo si la misma decisión se tomara hoy. Esto no constituye, de ningún modo, una deficiencia del diseño original; sin embargo, he visto a muchas personas reaccionar como si así fuera. El escenario más común con el que me encuentro y en el que veo a la gente exhibir esta conducta es en el rechazo al uso de RAID 5 en el diseño de almacenamiento moderno, siendo RAID 6 y RAID 10 las alternativas populares por buenas razones. Pero este rechazo a RAID 5, común desde aproximadamente 2009, no existió siempre, y desde mediados de la década de 1990 hasta casi el final de la década de 2000 RAID 5 no solo era viable, sino que con mucha frecuencia era la mejor solución para las necesidades técnicas y de negocio dadas (el aumento del rechazo hacia él fue mayormente gradual, no repentino). Sin embargo, muchas personas ven RAID 5 como una opción comprensiblemente mala hoy en día, pero aplican este nuevo rechazo a sistemas diseñados e implementados hace mucho tiempo, a veces hace casi dos décadas. Esto no tiene sentido y es puramente una reacción emocional. Que RAID 5 fuera la mejor opción para un escenario en 2002 no implica en absoluto que vaya a seguir siendo la mejor opción en 2015. Pero, de igual modo, que RAID 5 sea una mala opción en 2015 para un escenario no menosprecia ni anula en modo alguno el hecho de que muy a menudo fue una opción excelente hace varios años.

Me han preguntado muchas veces qué hacer una vez que se han tomado decisiones de diseño menos que ideales. «¿Qué hago ahora?».

Aprender qué hacer cuando la perfección ya no es una opción (como si alguna vez lo hubiera sido realmente; toda la TI consiste en compromisos) es una habilidad muy importante. Lo primero que debemos abordar son los problemas emocionales, ya que socavarán todo lo demás. Debemos hacer todo lo posible por dar un paso atrás, aceptar la situación y actuar de forma racional. Lo último que queremos hacer es tomar una situación no ideal y empeorar las cosas tratando de justificar retroactivamente decisiones equivocadas o dejándonos llevar por el pánico.

Aceptar que ningún diseño es perfecto, que no hay forma de acertar siempre por completo y que lidiar con esto es simplemente parte de trabajar en TI es el primer paso. Dé un paso atrás, respire hondo. No es tan grave. No es una situación única. Todo profesional de TI que se dedica al diseño pasa por esto continuamente. Debe esforzarse al máximo por tomar las mejores decisiones posibles, pero también debe aceptar que eso rara vez puede lograrse: nadie tiene acceso a recursos suficientes para poder hacerlo realmente. Trabajamos con lo que tenemos. Así que aquí estamos. ¿Qué sigue?

Lo siguiente es evaluar la situación. ¿Dónde estamos ahora? En muchos casos la implementación está terminada y no hay nada más que hacer. La situación no es ideal, pero ¿es mala? Muy a menudo, el mayor error que veo enfrentar a las personas ante un diseño ya implementado es que resulta demasiado costoso: por lo general, las soluciones «mejores» no lo son porque sean más rápidas o más fiables, sino porque son más baratas, más fáciles o más rápidas de implementar. Es una situación desafortunada, pero apenas es paralizante. Cualquiera que fuera el tiempo o el dinero invertido, debió de ser una cantidad aceptable en su momento y debió de ser aprobada. Lo mejor que podemos hacer, ahora mismo, es aprender del proceso de decisión e intentar evitar el sobregasto en el futuro. No significa que la solución existente no vaya a funcionar, ni siquiera que no vaya a funcionar de maravilla. Simplemente puede que no haya sido una elección perfecta dadas las necesidades del negocio, principalmente financieras, involucradas.

Hay situaciones en las que un diseño que se ha implementado no cumple adecuadamente con los requisitos de negocio establecidos. Afortunadamente esto es menos común, según mi experiencia, ya que es una situación mucho más difícil. En este caso necesitamos realizar algunas modificaciones para satisfacer nuestras necesidades de negocio. Esto puede resultar costoso o complejo. Pero las cosas pueden no ser tan malas como parecen. A menudo las reacciones ante esto resultan engañosas y la situación con frecuencia puede salvarse.

El primer paso, una vez que nos encontramos en una posición en la que hemos implementado una solución que no cumple con las necesidades del negocio, es reevaluar las necesidades del negocio. Esto no implica que debamos manipular las necesidades para amoldarlas a lo que nuestro sistema sea capaz de cumplir, en absoluto. Pero es un buen momento para volver atrás y ver si las necesidades originalmente planteadas son verdaderamente válidas o si simplemente no se examinaron lo suficiente o, aún más probable, para ir a comprobar si las necesidades del negocio han cambiado durante el tiempo que tomó la implementación. Puede ser que la solución implementada sí cumpla, de hecho, con las necesidades reales del negocio aunque originalmente se hubieran planteado mal o porque las necesidades hayan cambiado con el tiempo. O puede ser que las necesidades del negocio hayan cambiado de manera tan drástica que incluso una planificación perfecta se habría quedado corta originalmente frente a las necesidades existentes, y el hecho de que la solución implementada no rinda como se esperaba sea de menor importancia. Me ha sorprendido mucho la frecuencia con la que esta verificación de las necesidades del negocio ha convertido una solución que se creía inadecuada en una solución «sobredimensionada» que en realidad costó más de lo necesario, simplemente porque nadie cuestionó las exageraciones de las necesidades del negocio ni nadie puso en duda el valor financiero de ciertas inversiones tecnológicas.

El segundo paso es crear una nueva línea base tecnológica. Este es un paso muy importante para ayudar a evitar que TI caiga en la trampa de la falacia del costo hundido. Es extremadamente común que cualquiera —esto no es exclusivo de TI en modo alguno— mire el tiempo y el dinero invertidos en un proyecto y asuma que seguir por el camino original, por insensato que sea, es la mejor manera de proceder porque ya se han gastado tantos recursos en ese camino. Pero esto no tiene sentido, por supuesto: cómo llegó a su estado actual es irrelevante. Lo relevante es evaluar las necesidades actuales del departamento y de la empresa y hacer un balance de las soluciones, tecnologías y recursos disponibles en la actualidad. Dado el estado actual, puede determinarse el mejor camino a seguir. Cualquier consideración que se dé al esfuerzo invertido en llegar al estado actual no hace más que inducir a error.

Un buen ejemplo de la falacia del costo hundido se da en el juego del ajedrez. Con cada jugada es importante volver a evaluar todas las jugadas, riesgos y estrategias disponibles, porque qué jugadas se usaron para llegar al estado actual no influyen en qué jugadas tienen sentido de aquí en adelante. Si se trajera al mejor ajedrecista del mundo o a un asombroso algoritmo informático de ajedrez a mitad de una partida, no necesitarían conocimiento alguno sobre cómo se llegó al estado actual: simplemente evaluarían el estado actual y crearían una estrategia basada en él.

Así es exactamente como deberíamos comportarnos en TI. Nuestro estado actual es nuestro estado actual. Para la planificación estratégica no importa qué se desarrolló para llevarnos a ese estado. Solo nos importan esas decisiones y costos cuando realizamos un proceso de análisis posterior con el fin de determinar dónde pudo haber fallado la toma de decisiones, para así aprender de ello. Aprender sobre nosotros mismos y sobre nuestros procesos es muy importante. Pero esa es una tarea muy distinta de hacer planificación estratégica para la iniciativa actual.

Lo desafortunado aquí es que debemos comenzar de nuevo nuestros procesos de planificación, pero esta vez, suponemos, con más elementos con los que trabajar. Pero esto no puede evitarse. En el peor de los casos, los presupuestos ya no están disponibles y no hay recursos para corregir el diseño defectuoso y alcanzar los objetivos de negocio necesarios. A veces los compromisos son necesarios. Apañarse con lo que tenemos es a veces lo mejor que podemos hacer. Pero, en la inmensa mayoría de los casos según parece, alguna combinación de presupuesto adicional o de reutilización creativa de los productos existentes puede bastar para remediar la situación.

Una vez que hemos alcanzado un estado en el que hemos abordado nuestras carencias, ya sea simplemente aceptando que hemos gastado de más, entregado de menos o que nos hemos ajustado para satisfacer las necesidades, tenemos la oportunidad de volver atrás e investigar nuestros procesos de toma de decisiones. Es haciendo esto como esperamos crecer como individuos y, de ser posible, a nivel organizativo, aprender de nuestros errores, o determinar si siquiera hubo errores. Toda empresa y todo individuo cometen errores. Lo que nos diferencia es la capacidad de aprender de ellos y de evitar esos mismos errores en el futuro. El crecimiento proviene principalmente de experimentar el dolor de esta manera y, aunque a menudo resulta desagradable afrontarlo, es aquí donde tenemos la mejor oportunidad de crear un valor real y duradero. No posponga ni omita esta oportunidad de revisión, ya sea una revisión dura y personal que haga usted mismo, o una revisión formal y organizativa dirigida por personas capacitadas para ello, o algo intermedio. Cuanto antes se evalúen los procesos de decisión, más fresca estará la memoria y antes podrá surtir efecto la corrección de rumbo.

El paso final que podemos dar es iniciar el proceso de decisión para diseñar un reemplazo de la implementación actual tan pronto como sea posible, una vez completada la revisión del proceso de decisión. Esto no significa necesariamente que debamos tener la intención de gastar dinero o de cambiar nuestros diseños en un futuro próximo. En absoluto. Pero al ser extremadamente proactivos en la toma de decisiones de diseño podemos intentar evitar los problemas del pasado dándonos más tiempo para planificar, más tiempo para la recopilación de requisitos y la documentación, una mejor visión de los cambios en los requisitos a lo largo del tiempo al revisar periódicamente esos requisitos para ver si se mantienen estables o si están cambiando, más oportunidades de obtener el respaldo y la implicación de la dirección y de los colegas en la decisión, y una mejor comprensión del dominio del problema, de modo que estemos mejor preparados para modificar el diseño previsto o para saber cuándo desecharlo y empezar de nuevo antes de implementarlo la próxima vez. También podría, potencialmente, darnos una mejor oportunidad de codificar el conocimiento organizativo que podría transmitirse a un sucesor en caso de que usted mismo no esté en la posición de toma de decisiones o de implementación cuando llegue el próximo ciclo.

Con procesos buenos y racionales y una buena comprensión de los pasos que es necesario dar en un caso de diseño o implementación de sistemas menos que ideal, podemos recuperarnos de los pasos en falso y no solo, en la mayoría de los casos, recuperarnos de ellos a corto plazo, sino que podemos blindar a la organización frente a los mismos errores en el futuro.