archivo

Archivo de la etiqueta: usuario

Hay una diferencia importante entre lo que son las restricciones en el proceso de desarrollo de software (algo inherente por otra parte ya que no todo es posible y siempre tenemos por delante un presupuesto y unos plazos, que aunque sean flexibles, no pueden ser infinitos) y la imposición de requisitos.

Imponer requisitos por parte de desarrolladores a los usuarios, algo que es más frecuente de lo que parece, sobre todo en aquellos casos donde el desarrollador cree conocer o dominar el negocio con el que se está trabajando (es posible que lo domine o que incluso sea un gran experto pero siempre debe tener en cuenta el contexto en que se desarrolla el negocio y esa información solo te la va a dar con precisión el usuario) y que piensa que nadie mejor que él para especificar determinadas funcionalidades del sistema.

A veces se hace porque efectivamente lo cree así y otras porque le conviene que la aplicación tome una determinada deriva.

Es importante trabajar con personas que conozcan el negocio pero la línea de desarrollo del producto debe estar siempre en manos del usuario. El papel del desarrollador en este sentido debe ser aconsejar y poner su conocimiento y experiencias al servicio de los usuarios, informar de las restricciones existentes y gestionar con ellos aquellas que puedan ser flexibles o modificadas.

Cuando vemos que bases de datos ofimáticas completamente desnormalizadas han dado servicio durante años a departamentos completos no terminamos de entenderlo. Tal vez lo vemos desde la perspectiva de la calidad del dato, de la explotación de la información para obtener conocimiento o desde la integración con terceros sistemas y por eso nos resulta complicado comprender cómo han podido trabajar así todo este tiempo.

Después sustituimos esa forma de gestión por sistemas más avanzados y nos damos cuenta de lo complicada que resulta su implantación, cuando no se convierte finalmente en un auténtico fracaso.

Y muchas veces no se tratan de malas decisiones de carácter funcional, sino de complejidad y falta de fluidez en el uso de la solución por parte de un usuario medio.

El estilo Nueva Jersey es una técnica de desarrollo de software (más bien una estrategia) basada en el principio “peor es mejor”, en la que se prefiere sacrificar determinados aspectos del producto final a cambio de conseguir un sistema mucho más sencillo de utilizar y de mantener (sobre todo esto último ya que permite adaptar de forma más rápida el sistema a las necesidades del usuario).

Este enfoque está fundamentado en el principio de que la mejor solución es la solución más simple que permite satisfacer las necesidades del usuario (menos es más). Muchas veces, el usuario o nosotros creamos necesidades que no lo son en realidad y complican el producto y el desarrollo de tal manera que lo hace más complicado de utilizar y más caro de mantener.

El estilo Nueva Jersey es simplemente una idea, para que no olvidemos que los sistemas complejos de ser necesarios deben proceder siempre de una evolución de un sistema más simple que haya sido aceptado por los usuarios.

Ambos enfoques tienen en común las personas y en ambos juega un papel esencial el responsable funcional, product owner, área usuaria o como lo queramos llamar, en función de como esté organizado el proyecto y la metodología o estrategia utilizada.

Da igual cómo trates de enfocarlo, da igual que tengas grandes técnicos ya que si el usuario no colabora lo más probable es que la partida esté perdida. Es cierto que queda algún as en la manga, como que haya en el equipo personas con un gran conocimiento del negocio y de la organización y/o que haya algún sistema previo o en otra organización que pueda servir de referencia y se acierte.

No obstante la realidad es que resulta muy complicado acertar de esa manera porque se está trabajando a ciegas, sin recibir un feedback adecuado que permita ir perfilando los resultados.

Generalmente se suele tirar hacia adelante y con las especificaciones que se han podido obtener tratar de conseguir unos resultados: el proveedor quiere facturar y el cliente justificar la inversión realizada (sobre todo cuando ya se ha invertido un porcentaje más o menos significativo del presupuesto).

En este contexto suelen perder los dos y si gana uno es en detrimento claro del otro.

Si gana el cliente es porque al final hay un producto que puede satisfacer sus expectativas y si se llega a eso, tras un inicio nefasto y si no se ha invertido más dinero es porque el proveedor ha terminado tragándose todo el problema, convirtiéndose el proyecto en un agujero sin fondo, que nunca acaba y que solo ocasiona pérdida tras pérdida.

Si gana el proveedor es porque todos asumen que lo importante es conseguir un producto final, quedando en un aspecto secundario que realmente satisfaga las expectativas. No digo que no se quieran obtener buenos resultados, solo quiero decir que llegado el momento, muchos implicados querrán salvar los muebles y verán como única salida llegar a entregar algo.

En estas situaciones, la mejor salida, si no se consigue revertir el problema de la falta de implicación del usuario y no se asume el coste (ya sea inyectando más presupuesto o reduciendo el alcance), es asumir lo que hay y cerrar el proyecto.

Poco importa el enfoque si el destinatario de la aplicación no pone el interés o la dedicación necesaria al servicio del proyecto.

No es posible dar una respuesta generalista ya que depende realmente de lo que impliquen esos plazos.

Si existe una imposición legal, la necesidad de informatizar o cambiar determinados aspectos de un proceso ya informatizado para poder responder o adelantarse a la competencia sí que tiene una gran relevancia los plazos, en caso contrario, los plazos, incluso siendo importantes deberían modularse también a las necesidades del producto (¿conviene, tal vez, esperar algo más de tiempo y poner en marcha un producto más maduro?) y a las contingencias que hayan podido ocurrir en el proyecto.

La gran ventaja que ofrecen las metodologías ágiles es que en cada iteración ofrecen una nueva versión del producto susceptible, en potencia, de pasarse a producción si así se decidiese. Hay que tener en cuenta que en determinados productos, se pueden tardar varias iteraciones en tener un núcleo mínimo que pueda ser totalmente funcional para ser utilizado en un entorno real, lo cual no quita que, ya sea en un entorno de demostración o incluso en producción, se pueda trabajar o prácticar sobre la versión con el objeto de obtener feedback lo más pronto posible.

Al plazo general del proyecto, se suman los plazos individuales de las iteraciones. Con el objeto de tener un ritmo sostenido de desarrollo, es fundamental que los sprints terminen en la fecha indicada, aunque haya algún compromiso que no se haya podido terminar por completo.

El problema de los plazos generales del proyecto lo tenemos en lo complicado que resulta alinearlo con la expectativa de lo que se pretende tener en el mismo y eso trasciende al hecho o no de tener versiones funcionales cada cierto tiempo, es decir, puede darse el caso de que no te sirva de mucho poner en marcha una versión dentro del plazo si la misma no se corresponde con las expectativas que había para ese momento del tiempo.

Pero tampoco se pueden pedir imposibles y si realmente los quieres, sufrirá la calidad del producto porque velocidades de desarrollo sostenidas en el tiempo muy por encima de lo que se puede producen ese efecto.

Cuando se trabajan con ese tipo de plazos es fundamental gestionar de manera adecuada las expectativas del área usuaria, ya que es muy posible que tenga que haber modificaciones del alcance y en más de una ocasión.

Es mucho mejor esa situación que el hecho de que el usuario o nosotros nos mintamos, mucho mejor entregar unos mínimos con calidad que un producto inestable, mucho mejor tratar de cumplir esos plazos que retrasarnos.

Ambas cosas. Una de las máximas de Steve Jobs era que “las funcionalidades esenciales de un sistema tenían que ser sencillas de utilizar por parte de los usuarios”, funcionalidad y usabilidad deben ir de la mano, si bien no siempre van al mismo ritmo, ya que generalmente la funcionalidad va por delante de la usabilidad y es en cierto modo lógico que así sea, porque si bien ambas se realimentan del feedback, hasta que no se va consolidando la funcionalidad, la usabilidad ocupa otro lugar en la escala de prioridades.

Lo anterior no quita que se deba desarrollar con intención la funcionalidad pensando en la usabilidad, si no se hace así, no solo se no se está sacando el máximo partido posible al esfuerzo que se está invirtiendo sino que puede darse el caso de que la funcionalidad tenga que cambiarse posteriormente para adaptarse a una usabilidad que no es posible conseguir con el enfoque inicial.

Esa intención se consigue trabajando con el usuario en la definición del sprint y tratando de aplicar todo nuestro conocimiento y experiencia para asesorarle, teniendo en cuenta que hay que tener la mente muy abierta porque no hay que olvidar que el sistema que estamos construyendo no es para nosotros sino para el usuario y que si el usuario, tras escucharnos, decide tomar un camino, hay que respetarlo por mucho que pensemos que se equivoca.

En un proyecto de desarrollo de software la transparencia es sinónimo de liberación. Es cierto que se siente presión porque los responsables funcionales conocen la realidad del proyecto y no aquella que se le quiera, en un momento dado, vender, pero una vez que se asimila esta forma de trabajar, poder mirar a los ojos a los usuarios y que ellos confíen en tu trabajo crea un clima en el que, si bien no se asegura el éxito, sí que resulta mucho más efectivo.

No es cuestión de metodología, esto no va de eso, es cuestión de una actitud con respecto al proyecto y a los usuarios. Es cierto que ciertos enfoques como el ágil favorecen y a la vez necesitan este tipo de contextos pero en cualquier circunstancia es perfectamente aplicable.

Hacer visible los trabajos, hacer visibles los problemas, reconocer errores, de eso va esto, manteniendo una comunicación fluida con los usuarios y permitiendo que ellos mismos, sin necesidad de tu intervención, puedan obtener parte de esa información cuando ellos quieran. No se trata de microgestión, sino de abrir ventanas y que cuando quieran se asomen, la frecuencia con que lo hagan es cosa suya, si bien, no está de más, si notamos que no lo hacen las veces que debieran, recordarles que tienen esa posibilidad.

Un proyecto requiere la colaboración continua entre equipos y personas, sin confianza todo es más difícil, por lo que es necesario poner todos los medios que sean posibles para crearla y mantenerla (que es lo más complicado), la transparencia es una buena base para ello.

El desarrollo de un producto que satisfaga las expectativas del usuario requiere poner en contraste de manera sistemática las distintas versiones que se van obteniendo en cada iteración, pasen o no a producción, con las ideas que tiene el usuario, las cuales evolucionan de la mano del sistema.

Esto es así porque las ideas no se aclaran hasta que son tangibles, por muy buenas ideas que se tengan y/o muy claro se tenga cuál debería ser el resultado final. En otros contextos como son, por ejemplo, las obras de arte, los mismos artistas que son, además, sus propios usuarios (independientemente de que la creación la adquiera un tercero), necesitan trabajar sobre la solución y en muy contadas ocasiones, todo sale a la primera.

Pensar que la solución no se obtiene a la primera no es una actitud derrotista o una bajada de brazos sino de ver el proyecto desde una perspectiva más realista.

Las ideas son solo hipótesis que cobran forma cuando se materializan en producto. Cuanto más se tarde en corregir las desviaciones entre el producto y las expectativas del usuario más costoso resulta volver a encontrar el camino, por eso el feedback no solo es necesario sino que cuanto antes empiece a aplicarse mejores resultados se obtendrán a la par de un mejor aprovechamiento de los recursos disponibles.

No olvidemos, sin embargo, que se debe desarrollar con intención, el feedback no es un salvoconducto para la programación por permutación o para probar hipótesis que no han sido lo suficientemente reflexionadas. Si se actúa de esa manera se desvirtúan los beneficios del feedback, pasando de un enfoque evolutivo a otro basado en el prueba y error, que no niego que en alguna ocasión para funcionalidades que no se tienen claras pueda ser de utilidad, pero que no debe ser la práctica habitual en un desarrollo de software en el que se trata de adquirir el mayor valor posible con respecto al esfuerzo invertido.