archivo

Archivo de la etiqueta: inversión

Nuestro objetivo y el del cliente debe ser tratar de conseguir el mayor valor posible para el producto, lo cual requiere que se haga un uso racional de la inversión ya que de esta forma tendremos la posibilidad de obtener un mayor rendimiento de las iteraciones.

Para eso es muy importante desarrollar con intención, lo que requiere una alta implicación de todos los stakeholders del proyecto, sobre todo del responsable funcional, de las personas que colaboran con él y del equipo de desarrollo.

Sin embargo, la falta de intención no es el único factor que puede hacer que no se extraiga el mayor aprovechamiento posible de la inversión, hay otro muy importante que son las actividades de proceso o metodología, ya sea incluidas por el propio equipo de desarrollo o por la organización, que generan entregables que no aportan un valor real al producto y al proyecto.

Este mal es muy común en organizaciones que entienden que la singularidad de los proyectos es algo secundario y que todos deben tener un cuerpo de procesos común. Esto es lo mismo que pretender que una misma talla de ropa sirva para todos los componentes de una familia.

Parto de la base de que la organización necesita armonizar determinadas actividades de los proyectos, requiere recibir unos inputs necesarios para su gestión y para mantener un cuerpo de conocimiento. Soy de la opinión de que la base deben ser unos mínimos, comunes a todos los proyectos, con la mentalidad abierta a crear excepciones si fuera necesario (teniendo en cuenta que la excepción no se debe convertir en la norma) y que a partir de ahí, sea el proyecto quien mande, alcanzándose acuerdos para ampliar esa base de procesos si todas las partes entienden que aporta valor.

El problema lo tenemos cuando no se parte de mínimos y cuando se intenta encorsetar el desarrollo con actividades, sean pocas o muchas, que no solo restan flexibilidad al proyecto sino que originan costes en tareas y entregables cuyos coste de realización (y mantenimiento) son superiores al valor que proporcionan al producto y a la organización.

Llegado un momento se toma la decisión de hacer una nueva versión de un sistema de información porque se entiende que está obsoleto tecnológicamente (resulta complicado encontrar desarrolladores para ese lenguaje de programación, el sistema de gestión de base de datos o el servidor de aplicaciones ha quedado sin soporte, etc…) o porque el coste de mantenimiento es muy alto y es necesario hacer modificaciones sobre funcionalidades ya existentes o el desarrollo de otras nuevas, etc…

Ese producto de partida conseguía su propósito y era utilizado de manera productiva por los usuarios y por la organización (lo cual no quiere decir que todo su camino para llegar a esa situación fuera sencillo o que nunca hubiera problemas).

Este antipatrón surge cuando se quiere aprovechar el nuevo sistema para incluir todas (muchas) las “cartas a los Reyes Magos” que usuarios, gestores y desarrolladores habían estado guardando todos estos años (más otras que se le ocurran sobre la marcha).

Una mala selección de las mismas dará lugar a un nuevo sistema que habrá sobrepasado con creces el presupuesto de partida, sin que exista un incremento de valor proporcional, mucho más grande que el que realmente se necesita, igual o más complejo de mantener que el anterior, en el que que tendrá problemas a la hora de implantarse porque será mucho más difícil de utilizar y administrar y con una más que probable importante tasa de errores y deficiencias funcionales de partida.

Arreglar esta situación es muy complicado, en algunos casos casi que lo más recomendable es empezar de nuevo.

A todo esto hay que añadir que el sistema anterior pesará como una losa sobre los desarrolladores porque los usuarios (los del día a día, más que aquellos que han intervenido en la definición de la nueva versión) siempre lo tendrán como referencia y lo estarán comparando continuamente y además, y sobre todo, los gestores verán como procesos que antes se desarrollaban de manera eficiente ahora cuesta más trabajo hacerlos, con el consiguiente coste económico que eso tiene, y pedirán cuentas por no tener un retorno de la inversión a la altura del desembolso realizado. Todo esto creará una situación de presión y unas prisas que poco bien harán para la mejora paulatina del sistema.

El término “Efecto segundo sistema” fue utilizado por primera vez por Frederick Brooks en su libro “The Mythical Man-Month”.

Este antipatrón surge cuando se ha llegado a un punto en el que la mejoras a realizar en un determinado producto software o tarea requieren un esfuerzo mucho mayor que el valor que se obtiene con las mismas.

Las causas que pueden dar lugar a esto son muy variadas:

– Tareas sobreestimadas en las que los desarrolladores deciden ocupar todo el tiempo disponible en la misma (ver Ley de Parkinson).

– El intento de mejorar ciertos aspectos del producto o de los entregables del proceso que tienen un buen nivel de acabado y en donde introducir mejoras resulta complejo (ver Ley de Pareto).

– Inclusión de funcionalidades por parte de los desarrolladores o perfeccionamiento de las ya existentes, sin haber consultado con el área usuaria y que lo mismo no resultan necesarias o tienen un efecto negativo sobre las ya desarrolladas.

– Tratar de seguir realizando tareas sobre el proyecto para continuar facturando o para demostrar que se está ocupado: creación de necesidades inexistentes, inclusión de funcionalidades que se utilizan en muy contadas ocasiones y por un grupo reducido de usuarios, refactorización sin efecto o prácticamente sin efecto sobre la deuda técnica, etc…

Los efectos de este antipatrón no solo se centran en un mal aprovechamiento de los recursos disponibles (que de por sí ya es importante), sino en la inclusión de una mayor complejidad en el sistema, de nuevos posibles errores, de la modificación o creación de elementos documentales, etc…, cada uno de los cuales añade un coste adicional innecesario al sistema.

En muchas organizaciones hay sistemas de información o herramientas (más de uno, más de dos y más de tres) que tras una inversión importante en tiempo y esfuerzo se quedan en una simple url o en un icono de escritorio accesible por sus potenciales usuarios pero olvidada y abandonada por estos.

Otras veces nos encontraremos con sistemas y herramientas que ni siquiera llegaron a terminar de construirse, quedando en simples ruinas cuyos vestigios puedan ser consultados, con suerte, en un sistema de control de versiones o en alguna máquina de un entorno de desarrollo o de un programador.

¿Qué nos lleva a esto? Generalmente el hecho de que se haya desarrollo o adquirido un sistema que no cumple con las expectativas del usuario a nivel funcional y/o de experiencia de usuario o bien que no cubra una necesidad real en la organización.

Hay aplicaciones que de un número potencial alto de usuarios y de uso, nos encontramos con que están infrautilizadas, para mi son tan ciudades fantasma como las anteriores, solo que en este caso hay unos cuantos héroes que de manera voluntaria u obligada hacen uso de las mismas.

Hay ciudades fantasmas recuperables pero para ello se requiere un esfuerzo importante y un compromiso de todas las partes: desarrolladores y área usuaria. Los primeros para tratar de ir mejorando de manera progresiva las condiciones de habitabilidad y los segundos para ir priorizando sus necesidades y soportar durante un tiempo unas condiciones de vida duras dentro de la ciudad.

Habrá veces donde lo mejor será buscar otro emplazamiento para la ciudad. Esta decisión es muy complicada de tomar ya que hay una inversión importante detrás y otra inversión importante que se tendrá que hacer de nuevo. No obstante si hay una necesidad que cubrir cuanto antes se tome la decisión mejor porque se corre el riesgo de seguir invirtiendo en algo que tarde o temprano se terminará convirtiendo en un montón de escombro.

Estoy harto de ver sistemas de información sobrecargados de funcionalidades que no se utilizan y en las que las funcionalidades realmente esenciales no terminan de funcionar bien y/o ofrecer una experiencia de usuario adecuada. Es cierto que las directrices del área usuaria nos llevan muchas veces por ese camino pero también somos muy culpables de todo esto en cuanto a que muchas veces alentamos a que se realicen esas funcionalidades (ya sea por nuestro “espíritu creativo” o porque interesa económicamente que el desarrollo se alargue y así poder seguir facturando) y a que no hacemos pedagogía con el área usuaria en cuanto a que se centren en lo realmente importante.

Toda funcionalidad de más es esfuerzo innecesario, más deuda técnica y más elementos que mantener. Todo ese esfuerzo no se invierte en lo realmente importante que no es otra cosa que satisfaces las expectativas del usuario y para ello los aspectos principales del proceso o procesos que se informatizan deben tener el mejor acabado posible (funcional y no funcional).

Alan Shalloway ofrece algunos datos de interés que avalan que lo simple y la actuación sobre lo realmente necesario marcan el camino hacia un desarrollo de software que lleve a un producto de calidad en concordancia al presupuesto disponible o que potencialmente se está dispuesto a invertir (traducción libre): “La manera más fácil de construir algo simple consiste en no construir cosas que no necesitas. El 64% del software desarrollado se utiliza muy poco. La aproximación a la construcción del 20% del sistema generando el mayor valor posible (80%) y una vez hecho eso estudiar en qué posición nos encontramos y construir el siguiente 20% tiene grandes ventajas”.

Un gasto tiene como consecuencia una contraprestación económica y/o un esfuerzo a cambio de un servicio, de una actividad o de un producto que no nos va a proporcionar algún tipo de retorno. Esa es la principal diferencia con la inversión, en la cual no sólo se espera el retorno de la misma, sino un valor adicional (que se espere no quiere decir que se consiga, de ahí que haya buenas y malas inversiones).

Por tanto y como es lógico, es mejor una inversión que un gasto, independientemente de que la situación de partida en ambos casos sea la misma: una contraprestación. También es importante indicar que tampoco existe una piedra filosofal que convierta los gastos en inversiones, por lo que en el día a día tendremos que gastar y también podremos invertir.

Desde el punto de vista comercial, es muy importante que cuando se quiera realizar la venta de un producto o de un servicio, ya sea en un trato directo con el cliente o a través de una oferta, se intente enfocar siempre el negocio como una inversión, como las ventajas que le proporcionará al cliente la operación, tanto tangibles como intangibles: mayor eficiencia en la producción, agilización de los procesos de negocio, mejora de las ventas, imagen, etc… A todos nos cuesta menos abrir la cartera si sabemos que más adelante y de alguna manera se recuperará lo invertido. Si el cliente no le ve punta al asunto, le dará la imagen mental de un gasto (aunque no lo sea) y será mucho más complicado realizar la operación.

Si lo comentado en el anterior párrafo se extiende al resto de ámbitos de la vida, en la cual casi siempre se está negociando por algo, enfocar todo hacia la inversión siempre proporcionará mejores resultados que hacia el gasto (que se enfoque, como indiqué anteriormente, no quiere decir que se consiga disfrazar un gasto como una inversión).

La idea de inversión siempre está ligada al factor de riesgo, que puede ser variable y que conforme se incrementa, mayores serán las resultados que se esperan. También, y esto es una opinión muy personal, está ligado al progreso individual o de una organización, ya que, por ejemplo, si se pretende facilitar que una empresa o institución evolucione (que no implica necesariamente crecer) necesitará invertir (en infraestructura, en su personal, en marketing, etc…).

Este término lo podréis encontrar en muchísimos libros.

La diferencia muchas veces entre un trabajo correcto y un trabajo excelente está en dedicarle esa porción de tiempo de más (la milla extra) para cuidar los detalles y minimizar el número de errores.

En mi opinión la diferencia no está solo en el talento, sino en las personas y organizaciones que son capaces de aplicar esta milla extra, ese factor diferencial que permite llegar más allá en el trabajo (en volumen y calidad) y/o en la evolución personal (autoformación).

La milla extra supone un esfuerzo, supone ir más allá del trabajo convencional. Esto implica un sacrificio, ya que estás cambiando tiempo libre por tiempo que estás dedicando a una ocupación. No obstante, esa milla extra es la que marca la diferencia, la que te permite subir escalones más deprisa y la que sin duda te devolverá con creces todo ese esfuerzo y sacrificio de más que has invertido.