archivo

Archivo de la etiqueta: funcionalidad

En muchas ocasiones, considerar algo como una pérdida de tiempo es una cuestión de percepción, es decir, para alguien puede serlo, para otros no (y en medio, toda una escala de grises).

En otros casos, no hay lugar a la interpretación, se trata de pérdidas de tiempo.

Comentan Tom DeMarco y Tim Lister que: “El mayor pecado de la gestión es hacer perder el tiempo a la gente”, esto unido a su reflexión sobre los días de trabajo que se pierden, nos debe hacer pensar sobre algunas decisiones que provocan pérdidas de tiempo (a las que habría que añadir todos los malos hábitos productivos que tengamos a nivel de organización e individual).

Una mala selección de prioridades suponen una pérdida de tiempo, ya que estamos dedicando nuestro esfuerzo y atención (enfoque) a una serie de tareas y funcionalidades que no son críticas, dejando de lado otras que sí lo son. Sobre esto, se podría pensar que al fin y al cabo son cosas que tarde o temprano habría que hacer, sin embargo, la incertidumbre de los proyectos y las limitaciones presupuestarias y de tiempo no aseguran que lo que hemos dejado para después se pueda llegar a hacer, por lo que lo mejor es empezar siempre por lo que realmente es importante y trascendente. A esto, habría que sumar el hecho de lo que se deja de ganar o producir por realizar más tarde las tareas y funcionalidades que realmente tienen un impacto.

Una mala selección de funcionalidades también suponen una pérdida de tiempo. Es importante matizar esto.

El desarrollo de software es de naturaleza evolutiva, donde la aproximación a la solución que satisfaga a las expectativas de los usuarios se llega generalmente (que no siempre) mediante aproximaciones iterativas e incrementales. Bajo esta perspectiva, basada en el feedback del usuario (y de todos los stakeholders en cada iteración), no acertar en la definición de una funcionalidad forma parte en sí de la propia naturaleza del desarrollo y por tanto no se debería considerar una pérdida de tiempo. También es importante matizar esto.

El desarrollo iterativo incremental no es lo mismo que un ensayo y error a ciegas, sino que cada intento debe tener una intención y debe ser resultado de un proceso previo de reflexión. Claro que se puede fallar, claro que pueden ser necesarios ajustes, sin embargo, no se trata de probar por probar porque en este caso sí que estamos perdiendo el tiempo y capacidad para desarrollar otras funcionalidades prioritarias, ya que estamos invirtiendo el esfuerzo en dar vueltas sobre lo mismo.

Es importante también un enfoque minimalista en el desarrollo, evitando funcionalidades que finalmente no se van a utilizar o que van a tener un uso residual. El desarrollo de estas utilidades, también supone una importante pérdida de tiempo (y no solo eso, un lastre para el resto del proceso de desarrollo y el mantenimiento).

La priorización de funcionalidades permite que las primeras versiones del software contengan aquellos módulos que el área usuaria considera que va a tener más utilidad para ellos, de esta manera, además se obtiene el feedback para terminar de realizar los ajustes necesarios, los cuales se van insertando en las siguientes versiones que se van liberando.

En el caso de que haya problemas presupuestarios en el proyecto nos aseguramos de esta forma que las funcionalidades más necesarias y críticas se habrán puesto en marcha y con las diferentes iteraciones se habrá conseguido una mayor alineación entre las mismas y las expectativas del usuario.

Dejando para el principio lo más importante y para el final lo más accesorio, reduciremos también el porcentaje de funcionalidades de la aplicación que se implementan pero que no se utilizan o se usan de manera residual, ya que por un lado los usuarios enfocarán la mayor parte de sus peticiones en mejorar lo que hay ya desarrollado y en otras tareas prioritarias todavía no implementadas.

Es mejor tener una casa con dos bombillas que funcionen que con diez bombillas fundidas.

Antes de continuar desarrollando funcionalidades en un sistema de información hay que intentar consolidar las funcionalidades ya implementadas. De lo contrario se tiene el riesgo de caer en una situación con demasiados frentes abiertos y en donde se tiene la sensación de estar apagando constantemente fuegos.

Steven Rakitin es un experto en calidad del software con más de treinta años de experiencia en el negocio. En la actualidad es presidente de una consultora de calidad y es miembro de diferentes organismos y asociaciones prestigiosas a nivel internacional y ha sido autor de libros y de numerosos artículos.

Me parece interesante su siguiente reflexión: “Sí, las funcionalidades hacen vender productos, pero solo si funcionan”.

Mejor soluciones simples que funcionen, que sean útiles, que consigan la satisfacción del usuario en los módulos que tengan implementados. Soluciones más complejas con múltiples funcionalidades que no terminan de ir bien, cuestan mucho dinero (hacerlas, mantenerlas y explotarlas), frustran a los usuarios y complican las relaciones cliente/proveedor.

En relación con lo anterior, un producto software satisface al cliente no solo si cumple sus expectativas a nivel funcional y no funcional sino si también funciona (se necesitan ambos ingredientes en la receta).

Lo fácil puede ser optar por la estrategia de tú me pides, yo lo hago. Sin embargo, la mejor estrategia es, tu pides, yo lo analizo, te comento los riesgos (si hay), tu decides y yo ejecuto.

Hay veces que el usuario o el cliente pide una funcionalidad, que lo mismo es algo accesorio o que no es importante, que lo mismo puede ser útil pero que al fin y al cabo no es necesaria para que pueda desempeñar sus tareas de manera más o menos eficiente a través del sistema de información. Ellos pagan, luego tienen la posibilidad de pedir, pero lo mismo se piensan dos veces una determinada petición si se les explica las “contraindicaciones” que tienen la realización de la misma.

Porque, ¿cuántas veces ha llevado la realización de una mejora o la implementación de una nueva funcionalidad a una versión peor del producto? si nos ponemos a pensar, es más que probable que cada uno tengamos varios ejemplos.

Tanto si vamos a trabajar con metodologías ágiles, como con otras metodologías como RUP y sobre todo, en ciclos de vida clásicos o en cascada, resulta fundamental delimitar cuanto antes el alcance del proyecto.

Como mínimo hay que llegar a una primera aproximación en la negociación del contrato con el cliente (cuanto mejor sea la misma, más variables se tendrán a favor para hacer una correcta valoración en esfuerzo y plazos del proyecto) y es más que recomendable hacer otra aproximación al inicio del proyecto.

Acotar el alcance no debe ser entendido como poner límites al proyecto, al menos en el sentido estricto, ya que a través de la propia evolución del software, la aplicación tenderá a ir hacia donde van las expectativas del usuario. Pero sí se debe entender como un marco hacia donde enfocar el desarrollo, ya que no todas las funcionalidades que se quieren implementar son iguales de prioritarias o críticas.

El proyecto debe centrarse en lo verdaderamente importante, dejando para más adelante aquello que no lo es. Probablemente no habrá presupuesto (por lo menos en primera instancia) para todo, por lo que lo primordial es cubrir lo que resulta necesario.

Si no delimitamos el alcance, se quedarán demasiadas puertas abiertas por detrás, con el riesgo de que el cliente o usuarios quieran volver a ellas. Es cierto que al final el proyecto va hacia donde quiere el cliente o los usuarios, pero no es lo mismo tener pactado por escrito un alcance que no tenerlo y no es lo mismo hacer pedagogía desde el inicio del proyecto que no hacerla.

¿En cuántos líos nos hemos metido por no dedicar el tiempo suficiente a pensar en un problema o en una funcionalidad o por no decir que no? Y no lo digo por el hecho de tomar una decisión equivocada sino por el simple hecho de tomar alguna diferente a no abordar en un proyecto determinadas problemáticas y funcionalidades que se escapan de los objetivos principales del mismo.

Invertir esfuerzo en algo que no parece llevar a ningún sitio no parece sensato, sin embargo nuestro afán por ejecutar trabajo y dejar satisfecho a clientes y usuarios nos lleva a meternos por caminos que, a priori, tenemos fundadas sospechas de que no llevan a ningún sitio.

¿Es compatible esto con satisfacer las expectativas de usuario? Por supuesto que sí. De la misma manera que no podemos desarrollar un producto de espaldas al usuario, tampoco el usuario puede orientar el mismo sin tener en cuenta a los técnicos. Se trata de consensuar una solución factible en tiempo y presupuesto, que cumpla las expectativas del usuario (por lo que la opinión de los mismos, como es lógico es la que más peso tiene).

A veces será más sencillo alcanzar ese consenso, otras no y en las que no probablemente o el cliente o el proveedor (o ambos) tendrán que asumir las consecuencias económicas de un alcance que supera al esfuerzo previsto inicialmente.

Hay muchos sistemas de información que son inherentemente complejos ya que el proceso o procesos que tratan de informatizar son de esa naturaleza.

Pero incluso en estos casos, encontrarnos con demasiadas funcionalidades complejas sobre las que trabajar en paralelo nos debe hacer reflexionar sobre si lo que estamos haciendo lo estamos enfocando adecuadamente:

¿Hay algo que no estamos entendiendo bien y como consecuencia la complejidad de la funcionalidad crece?

¿Estamos incorporando demasiada complejidad a la inherente del proceso?

¿Estamos tratando de abarcar más funcionalidades que las que realmente podemos en este momento?

Demasiados frentes abiertos no se pueden gestionar adecuadamente. En lo posible hay que intentar que sean los menores posibles en un proyecto ya que cuantas más puertas abiertas haya, resultará más difícil enfocar la atención a aspectos concretos y la complejidad del desarrollo aumentará en la misma medida.