No te incendies, análisis de riesgos para proyectos que son para ayer.

Una entrevista con Tim Lister, Consultor Senior de Cutter Consortium

Tim, a través de tu experiencia ¿cuáles son las tendencias que observas al visitar a tus clientes en tu práctica de análisis de riesgos?

Uno de los principales factores que veo es lo apretado de la programación de los tiempos: "debimos haber tenido este sistema para ayer..." En el equipo de desarrollo, la presión por el tiempo es un asunto realmente impresionante. Uno de mis clientes es una compañía relativamente nueva, creada en enero de este año. El Director de Ingeniería fue quien me contactó; él por su parte fue contratado en abril, y de acuerdo a su plan de trabajo la liberación de su primer producto deberá efectuarse el próximo 16 octubre. Ellos planean emplear 50 desarrolladores de software para fines de año (actualmente son 24). De algún modo, presentarán un conjunto muy sofisticado de herramientas para Internet en forma inmediata. Sin embargo, y al menos hasta la semana pasada, ellos seguían aún discutiendo los requerimientos.

Dentro de los llamados proyectos críticos, siempre hay conflicto en la programación de tiempos. Sin embargo, no puedes sentarte, demostrar matemáticamente que el tiempo no alcanza y decir que no puedes hacerlo, entonces se convierte en un asunto emocional. Las personas entran en conflicto al plantearse si realmente pueden o no desarrollarlo en ese tiempo. Así, la parte inicial del proyecto es un poco efímera: anotamos los requisitos, discutimos los puntos, hablamos sobre las opciones, etcétera. Esto muestra como es que estás desarrollando el proyecto (porque efectivamente, lo estás haciendo), pero nadie dice, "como sabes, mantuvimos una conversación acerca de lo que debió haber sucedido hace tres meses". Por ejemplo, estuve con el cliente que mencioné en un principio para realizar una revisión de requerimientos, y le dije, "sabes, esta conversación hubiese resultado realmente trascendente en mayo del 2004, pero desafortunadamente estamos en mayo del 2005. Hablamos acerca de lo que no se había realizado… así que finalmente llegamos a la conclusión de que, o posponíamos estos puntos hasta la próxima liberación, o bien nos enfocábamos a la importancia de cumplir con ellos, moviendo la fecha de liberación." Yo sé que hago bien mi trabajo cuando los clientes regresan posteriormente y me dicen, "gracias por haber dicho eso." Es muy desafortunado que aún en organizaciones sanas, no puedas plantear estos puntos de manera directa y por ti mismo. Esto es algo que todossaben, pero es un hecho que nadie puede llegar y decir, "hey, aquí estamos todos como locos", y no lo pueden decir porque es demasiado lo que está en juego; es por ello que se vuelve un asunto altamente emocional. Incluso esto puede convertirse en un asunto verdaderamente infernal, –así, si no lo logran- podrán al menos decir que lo intentaron hasta sus últimas consecuencias."

En la mayoría de los casos, las personas no reconocen en forma oportuna que hay una probabilidad muy pequeña de que todo caminará de acuerdo al plan. Para cuando lo admiten, sus opciones se han cerrado. Si ellos dijeran hoy, "bueno, no podemos entregar toda esta funcionalidad para fines de año pero al menos podremos entregar una parte", y esta discusión debería suceder de inmediato, no hasta octubre, porque entonces será irrelevante y ya habrán hecho el despliegue de sus tropas, estarán tratando de construir la aplicación y todo para alcanzar al final sólo dos tercios del proyecto.Esto significa que no has obtenido realmente nada. Esto es parte de la Administración del Riesgo, plantear en forma oportuna tanto a los directores como al personal técnico involucrado, admitir y reconocer a tiempo ¿cuáles son realmente nuestras opciones? todos queremos alcanzar la meta pero ¿qué sucede si no lo logramos?

¿Has comprobado una mejoría notoria en aquellas compañías que aplican la Administración del Riesgo?

La mayoría de las organizaciones, especialmente las grandes, no lo van a adoptar en toda la organización y aún así resulta efectivo. Pero las personas lo hacen, lo aprenden y lo practican. Por ejemplo, un Director de Proyecto aprende que las técnicas de administración del riesgo traen una brisa de aire fresco a los proyectos que él supervisa. Ellos plantean toda una serie de buenas preguntas y no amonestan a su personal por llevar malas noticias; analizan las opciones y ayudan a los líderes del equipo a pensar dentro del proceso mismo “¿Cuáles son nuestras opciones? ¿Cómo puedes estar tan seguro que nosotros lo haremos? Muéstrame por qué esto es una cosa segura."

Desafortunadamente, la mayoría de las compañías no ven la importancia de la Administración del Riesgo hasta que las llamas comienzan a arder. He estado en algunas organizaciones donde he dicho literalmente, "Usted no hará esto hasta que el asunto no comience a arder. Puedo ver lo que sucederá: usted continuará cruzando los dedos y arrojando los dados de la suerte." Es entonces cuando sucede que un gran proyecto que realmente pudo haberse concretado no se consolida, generando en consecuencia un gran desconcierto y una dolorosa pérdida financiera. Surgen así planteamientos que señalan, "¿Cómo fue que sucedió esto, y cómo podemos cercioramos que no se repetirá otra vez?"

¿Qué otros aspectos relevantes has detectado?

En los últimos cinco años, a menos que la situación absolutamente así lo demande, las organizaciones continuarán reacias a emprender grandes proyectos que requieran de la participación de cientos de personas. Las organizaciones están al acecho de tomar asuntos realmente trascendentes pero con grupos más pequeños.

No obstante, esto es un arma de doble filo. Cuándo desarrollas proyectos con equipos más pequeños, has apostado por personal altamente capacitado. El problema es que careces de mandos intermedios que estén en un continuo proceso de aprendizaje y capacitación.Pese a ello, el trabajar con grupos pequeños hace definitivamente las cosas más prácticas, más manejables. Liderear un equipo de seis o siete miembros es un asunto infinitamente más maleable que conducir un equipo de sesenta o setenta individuos.

Sobre este tema, el autor Kent Beck describe maravillosamente esta clase de desarrollo evolutivo. Su libro Extreme Programming Explained (Addison Wesley, 2000), es sin duda uno de los mejores que he leído últimamente. Sus ideas son radicales pero sumamente sensatas. Miro a las personas construir sistemas; yo he construido sistemas, y no hay cosa más emocionante que construir algo juntos. Considero que Beck ha identificado una verdad maravillosa para nuestro negocio. Así, pensábamos que realmente optimizábamos al hacer que cada cual tomase su propia pieza y se dedicara a trabajar en ella. Pero creo que son esos pequeños y participativos equipos (especialmente en aquellos proyectos que tuvieron que haberse concretado el día de ayer), en los que debemos depositar hoy nuestra mejor esperanza.

¿Están los clientes preparados para enfrentar este tipo de desarrollo?

Me parece que es un asunto de cultura. Sin duda, algunas personas tienen problemas, pero muchas otras ya lo están realizando y no lo reconocen. Si eres un desarrollador realmente bueno, tendrás sin duda un par de amigos a los que puedes decir “trabajo con”, “estamos del mismo lado”. Así si les dices "¿hey, pueden venir aechar una mirada a este asunto?".Ellos suponen que realizan su labor al enfocarse en su pedacito, pero cuando ambos acuden y se unen, en realidad han empezado a trabajar en la construcción de tu pedazo.

Cuándo hablas acerca de contar con dos personas que escriben un mismo código, te encontrarás con que la mayoría de los directores dirá, "Espera un segundo, eso duplicará el costo del código." Pero la noción de Beck de tener a dos personas que se sienten a construir juntas tiene mucha validez. Ante todo, la calidad del producto es impresionante. Segundo, te asegurarás que dos personas conocen el código. Nosotros siempre nos quejamos de la forma en que nos afectan los sistemas idiosincrásicos, pues bien, es mucho más fácil de construir un producto que es entendible para dos personas que lo construyen juntos. Mi predicción es que el gasto se aplicará de otra manera: es decir, probablemente no costará más debido a que usted ahorra en términos de prueba y error; y esto es algo que nosotros sabemos, la depuración de cualquier código demanda siempre una fortuna.

¿Qué recomendarías a las compañías para obtener mayores beneficios en su implementación de la Administración del Riesgo?

Existen dos niveles en los que se puede aplicar la Administración del Riesgo. El primero de ellos está dentro del equipo del proyecto. Cierras la puerta de una sala en la que todos pueden hablar libremente.Así el director de proyecto, el líder del equipo y el personal técnico, a través de un análisis de riesgos y una identificación de los mismos, determinan que probabilidades tienen, delimitan cuáles serían los costos en caso de presentarse problemas, etcétera.

Sin embargo, aunque discusiones de este tipo pueden ayudar, el punto clave es lograr el involucramiento de la gerencia en una escala mayor a la del administrador del proyecto. Esto podría ser a través de la participación del cliente mismo o bien con la incorporación de un gerente, digamos del área de mercadotecnia, es decir alguien que pueda observar el proyecto en diferente sentido, lo cual le permitirá conocer los problemas potenciales que observa desde esta óptica. La idea de trabajar juntos en forma temprana, no es otra sino la de determinar los riesgos oportunamente y poder en su caso, hacerles frente.

Idealmente, debe empezarse con la Administración del Riesgo aún antes de definir el proyecto mismo, lo cual ayudará a definir el proyecto en su conjunto. Digamos que hay ciertas funcionalidades que técnicamente son muy difíciles de manejar, lo cual no es precisamente una ventaja. Puedes decidir desarrollarlas en una versión posterior o resolverlas de una manera menos elegante (probablemente esto no funcionara bien para todos los casos).

El punto es encontrar la fórmula que permita efectuar un canje que se vea a su vez reflejado en un plazo de entrega más corto, en una etapa de prueba más exitosa, etcétera.

Mi conclusión es que la Administración del Riesgo realmente inicia antes del proyecto mismo, y que se va enriqueciendo dentro de su proceso (y no cuando el proyecto concluye). Yo nunca he visto o participado en un proyecto que haya contemplado todos los riesgos y/o que no haya sufrido modificación alguna dentro de su proceso de implementación.Aún cuando hallas efectuado las pruebas, surgen una gran cantidad de imprevistos y factores desconocidos... es así cuando los problemas comienzan a manifestarse y cuando te preguntas: ¿Ok, debí haber previsto este problema antes de su envió? O bien ¿Tengo manera de remediarlo? Esto es a lo que yo llamo realmente una Administración del Riesgo, factores que cabe mencionar, lamentablemente no se resuelven a través de la fe o la mano de Dios.

Cutter Consortium ||Tim Lister || Leer otros aticulos

Cutter Consortium México, Acceso directo con los pensadores más sobresalientes en el campo de las TI.