archivo

Archivo de la etiqueta: riesgos

Sea cual sea el enfoque, estrategia o metodología que apliques en un proyecto, van a aparecer riesgos o problemas que pueden afectar en mayor o menor medida al proyecto y al cumplimiento de los compromisos y expectativas y que no deberíamos ignorar, en unos casos porque su materialización puede poner todo patas arriba y en otros porque una vez materializados suponen una resistencia importante en el propio proceso de desarrollo.

La gestión de riesgos en los enfoques ágiles está implícita en la propia dinámica de trabajo y en las prácticas que se vienen a aplicar. Esto no quiere decir que sea menos importante o que se le dedique menor atención, solo que ya se entiende, de base, que es necesario trabajar en ello.

Es importante tener en cuenta que se presta principal atención a los impedimentos o resistencias que son contingencias u obstáculos que bloquean o afectan a la velocidad real del equipo, lo cual no quiere decir que se ignoren riesgos a más alto nivel.

En un enfoque ágil de desarrollo se debe tratar que los problemas, resistencias y errores salgan a la luz lo antes posible porque se entiende que cuanto más cerca de su origen se aplique de manera efectiva cada solución, menos daño provocará al proyecto al ser menor su impacto en el producto y en las personas (si no se hace por eliminar o paliar determinadas resistencias, afectará al ánimo y moral de las mismas, agudizando el efecto que sobre la productividad provocan esos impedimentos) y, por tanto, menor el esfuerzo que se necesitaría para volver de nuevo a una situación de equilibrio.

Un ejemplo de ello lo tenemos en las reuniones diarias o Daily Scrum en las que cada participante, además de indicar lo que hizo la jornada anterior y lo que pretende realizar en esta, comenta qué impedimientos, obstáculos, resistencias o problemas se están encontrando en la realización de sus tareas. Se habla de ello para poner estas contingencias encima de la mesa con el objeto de que se le proporcione una solución que lo mismo puede ser inmediata o requiere de tareas (o incluso sprints específicos) para abordarlas.

No olvidemos que la comunicación entre las personas ni empieza ni termina con el Daily Scrum, por lo que aplicando los principios de transparencia que deben regir en un proyecto ágil, en cualquier momento se puede y se debe levantar la mano para comunicar un riesgo o un problema que puede afectar al desarrollo.

En cualquier caso, tenemos otro punto de sincronización en las retrospectivas, en las que se analiza en qué aspectos se puede mejorar y cómo y qué resultado están dando las medidas aplicadas hasta ahora para tratar otros puntos de mejora detectados en sprints anteriores. Este es otro punto donde se puede y se deben discutir sobre todo aquello que afecte a lo que sería un normal desarrollo del proyecto.

Estas resistencias, se pueden inventariar en una pila de impedimentos o Impediment Backlog con el objetivo de hacerlas visibles y poder hacer un seguimiento de las mismas.

Se pueden enumerar decenas y decenas de posibles situaciones que se pueden producir en un proyecto y que se podrían considerar riesgos, pero hay una que casi podríamos considerarla unánimemente cómo el principal factor de riesgo en un proyecto y es la falta de implicación del área usuaria.

Sin ellos no hay visión de las expectativas de producto por más que el equipo de proyecto cuente con personas con visión y experiencia sobre el negocio, porque una cosa es el proceso de negocio que se quiere informatizar y otra es cómo le gustaría al usuario verla ejecutada. Es posible que se acierte sin el usuario pero es más mucho más probable que se falle.

¿Y por qué el usuario no se implica?

– Se ha designado un responsable funcional o product owner que no quiere asumir sus responsabilidades o el trabajo que implica el mismo y la dirección del área usuaria no hace nada por arreglar esta situación.

– Puede darse el caso de que quiera hacer ese trabajo pero no se le han dado instrucciones precisas sobre qué tareas de las que tiene que atender son más prioritarias, por lo que tenderá a hacer las propias de su trabajo ordinario.

– También puede producirse el hecho de que sean sus propios jefes los que les obliguen a atender otras prioridades.

– Al área usuaria o al departamento TIC se les vendió un proyecto que pretendía cubrir una necesidad no existente y como tal, llegado el momento, se prefiere atender otras necesidades o trabajos más urgentes.

– El área usuaria apostó por el desarrollo ya que era una apuesta personal por parte de la dirección del área afectada y en un momento dado se produce un relevo en la misma que considera que existen otras prioridades.

– El área usuario y/o el responsable funcional se desaniman al no desarrollarse el proyecto según sus expectativas. Esto no quiere decir que se estén haciendo las cosas mal (que es posible) sino que no se han sabido gestionar sus expectativas,.

Causas puede haber muchas, pero el camino siempre debería ser el mismo en el caso de que se produzca esta situación y es que si no se consigue enderezar, lo mejor para todos es que se llegue a un acuerdo para dar por finalizado el proyecto y resolver el contrato (cuando proceda).

Si eres el responsable de una determinada infraestructura tecnológica que sabes que funciona, en la que tienes un soporte de calidad y en la que cualquier incidencia de cierta gravedad (y a veces no hace falta ni eso) con la misma te puede costar tu puesto de trabajo o incluso problemas mayores, ¿te arriesgarías al cambio?.

Imagina que la decisión depende, al menos, en primera instancia de tí. Delante tuya tienes la posibilidad de ahorrar entre un 50 y un 75% los costes pero también tienes la incertidumbre de que se trata de una tecnología nueva. En ese momento puedes poner encima de una balanza el ahorro y en la otra el coste que tendría para tu organización un fallo de la nueva tecnología (que probablemente sea muy superior al ahorro) y el deterioro que sufriría tu carrera profesional. ¿Hacia que lado crees que se inclinará la balanza?.

Incluso si se decantase por el lado de la innovación, es muy posible que el siguiente paso sea exponer los cambios ante otro grupo de personas que solo ven y entienden de números, ¿en qué porcentaje de casos crees que decidirán asumir el riesgo?.

La innovación llega al mundo empresarial porque hay personas, ya sea el responsable de un departamento, un comité ejecutivo o un consejo de administración que deciden asumir riesgos. En aquellos casos en los que la relación coste/beneficio/riesgo sea favorable y evidente el viento soplará a favor, en aquellos otros casos donde la incertidumbre sea mayor el viento soplará en contra, a lo que se sumará probablemente el hecho de que los proveedores de la solución actual, viendo amenazada su posición, no te pondrán las cosas fáciles.

Es muy probable que te soliciten casos de éxito y referencias y eso requiere un cierto tiempo y una inversión importante porque esos primeros pilotos es posible que te cuesten dinero porque si el cliente tiene una cierta entidad minimizará su riesgo en el sentido de que no querrá hacer un desembolso importante por algo que lo mismo no implanta, comenzará con una implantación paulatina en áreas no críticas y/o que estén muy controladas, querrá un soporte de una calidad similar a la que tuviera ya contratada con su proveedor habitual de servicios y una corrección pŕacticamente inmediata de las incidencias.

Incluso podrás encontrarte con situaciones en las que incluso te soliciten determinado tipo de certificaciones antes de hacer el piloto y/o contratarte tu tecnología.

Pero también existirán posibles clientes que encuentren tu solución como una oportunidad o como una salida (ante, por ejemplo, la imposibilidad de mantener determinados costes), poniéndote las cosas más sencillas y siendo más tolerantes, teniendo en cuenta que el tiempo y las oportunidades no serán ilimitadas.

El que fuera CEO de Inter Craig Barret comentó poco tiempo después de asumir ese cargo que: “Vamos por una carretera a 150 millas por hora y sabemos que en algún lugar hay un muro de ladrillos, sin embargo lo peor que podemos hacer es parar demasiado pronto y dejar que alguien nos pueda adelantar”.

Para conseguir determinados objetivos hay que asumir riesgos, en ocasiones riesgos que pueden poner en juego la viabilidad de un proyecto o incluso de la viabilidad económica de una organización.

No siempre se está dispuesto a realizar esa apuesta, dar ese paso al frente, se vive bien en nuestra zona de seguridad y se tienen menos preocupaciones cuando los riesgos están controlados o su materialización produce unos daños asumibles y reparables.

Ahora bien, hay veces donde se te presentarán verdaderas oportunidades (en forma de posibles negocios, soluciones o productos), las cuales no están siempre están llamando a tu puerta y si la dejas pasar habrá otro que ocupe tu lugar, que te la arrebate, siempre habrá otro, no lo olvides.

Otras veces no será cuestión de oportunidad sino de supervivencia o se apuesta por una solución o por una estrategia concreta y ponemos nuestro máximo empeño por llevarla a cabo o veremos como la situación se convierte en irreversible.

En estos casos, quedarte quieto supone perder, tal vez asumiendo determinados riesgos perderás más si la cosa no sale bien, pero al final en una situación y en otra el resultado será el mismo.

Este antipatrón lo tenemos cuando gestores de proyecto o gerentes se centran exclusivamente en que los procesos que orquestan el desarrollo se realizan de manera adecuada sin dedicar tiempo a comprender la naturaleza de los trabajos que se están realizando, de esta forma no pueden evaluar el grado efectivo de avance de un proyecto o tener una comunicación adecuada con el cliente, pudiendo dar lugar a falsas expectativas o a transmitir mensajes que no son acordes con la realidad del proyecto.

Es compatible verificar el cumplimiento de los procesos con tener una cierta información de los objetivos del proyecto, de las contingencias que se están produciendo, de sus posibles riesgos, etc…, es cierto que se necesita bajar a más nivel de detalle, pero de no hacerse así (y es algo que no quita tanto tiempo como parece) no se puede evaluar de manera adecuada cómo van los trabajos y tratar de los mismos con conocimiento de causa con el cliente.

La situación se ve agravada cuando incluso en estas circunstancias, el gestor decide tirar para adelante él solo en conversaciones con directores del área usuaria o del cliente, sin buscar la colaboración de componentes de su equipo que conocen mejor el estado del proyecto, ni que decir tiene que por mucha experiencia que se tenga, lo más normal es que de alguna u otra forma se meta la pata (se acepten responsabilidades o culpas de su equipo de manera injusta, apoye decisiones que no sean las más convenientes para el proyecto, gestione incorrectamente las expectativas, etc…).

Cuando se trabaja en muchos proyectos, este antipatrón puede venir dado de manera casi forzada, pero por poco tiempo que se disponga, en la medida de lo posible es necesario estar informado de qué es lo que se cuece y contar con el apoyo de componentes del equipo cuando sea necesario.