archivo

Archivo de la etiqueta: funcionalidad

El proyecto se queda sin presupuesto, al menos, a corto y medio plazo y los responsables funcionales entienden que existen funcionalidades que son necesarias para que el producto sea de utilidad o para que la productividad en el uso del mismo sea aceptable.

¿El problema? No hay dinero para hacer todo lo que necesitan, ¿cuál es la primera consecuencia? Desgaste, incluso en situaciones donde el desarrollo haya sido fluído. A los usuarios les entra el síndrome de la última versión y el proveedor de servicios de desarrollo por muy flexible que sea tendrá que mirar por los resultados económicos del proyecto.

Gestionar bien esa circunstancia tanto por parte del cliente como del proveedor es esencial ya que se puede tirar por tierra todo el esfuerzo de meses de trabajo. No es sencillo porque todos sabemos lo complicado que resulta cerrar un proyecto.

No existen fórmulas mágicas, solo el sentido común, la búsqueda del beneficio mutuo y un autoanálisis crítico del trabajo que se ha realizado en el proyecto con el objeto de asumir responsabilidades (si existen). Si ambas partes quieren se puede alcanzar un acuerdo satisfactorio, si una de ellas se resiste probablemente terminen perdiendo ambas.

Además de lo anterior, la solución ideal pasaría por dotar al proyecto del presupuesto adicional necesario para terminar de manera adecuada los trabajos, si bien pueden existir circunstancias que lo impidan o, al menos, que lo impidan temporalmente.

Recordemos que lo realmente importante es el valor del proyecto y su relación adecuada con la inversión realizada y no acertar con una estimación inicial que todos sabemos (cliente y proveedor) cómo está hecha. Si tu objetivo es hacer que la estimación sea acertada tal vez te lleves ese logro pero tal vez, también, el proyecto se quede a medias o se entregue un producto deficiente,

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.

La automatización del testing permite ahorrar importantes esfuerzos tanto para el equipo de programación como para los testers. Ahora bien, ¿dónde está el límite?, ¿conviene automatizar todo?.

Sobre esto habrá opiniones de todo tipo. La mía va muy en la línea de la que describe Ron Jeffries en la siguiente cita: “La automatización en el testing es algo bueno, eso es seguro. Pero no podemos y no deberíamos automatizarlo todo. Entonces, ¿por qué pedimos a los equipos que automaticen todos los tests?”.

Automatizarlo todo tiene un coste y además, teniendo en cuenta que el desarrollo de software es evolutivo, en cada evolución necesitaríamos de nuevo realizar ajustes en los tests automatizados. Además, el coste de automatizar la comprobación del funcionamiento de determinadas funcionalidades puede ser excesivo en sí o puesto en una balanza con los beneficios que se obtienen con dicha automatización.

¿Por qué se pide la automatización de todo? Pues porque no se evalúa la dificultad y esfuerzo que tiene realizar esa tarea. Es importante automatizar tests pero sabiendo elegir las áreas del código y del sistema de información donde se puede obtener el mayor aprovechamiento de los mismos (por su impacto y por el esfuerzo que requeriría una verificación manual) con el menos coste posible (elegir bien no es trivial).

No contar con los interlocutores adecuados es una causa muy común de fracaso en un proyecto de desarrollo de software.

Entre los principales errores que se suelen cometer en este sentido se encuentra la selección de interlocutores que no participan en el día a día de la ejecución de un proceso. Esto normalmente lleva a soluciones que están alejadas de las necesidades reales de los usuarios reales del sistema de información.

¿Y si se quiere aprovechar el nuevo sistema para hacer cambios en el proceso? Mi consejo es que esos cambios se realicen siempre que sea posible antes de que la aplicación se haya puesto en marcha, recordemos el mantra de que “la informática y el software no resuelven problemas organizativos” y que en el caso de que sea a la vez, todo el mundo tenga muy claro previamente la dirección a la que nos dirigimos.

En cualquier caso, con cambio de proceso o sin cambio de proceso, en la definición de las funcionalidades de un sistema de información, así como para la transmisión de las expectativas en relación a la experiencia de usuario tienen que intervenir representantes de los que van a utilizar el sistema de manera cotidiana, sin que ello suponga restricción alguna a que puedan intervenir, incluso coordinando todas las consultas a las diferentes áreas usuarias, personas que tengan un perfil orientado más a la gestión, es más, alguien al final tendrá que resolver posibles situaciones de conflicto en cuanto a la visión de los procesos y establecer prioridades, lo que hará necesario a que de manera directa o delegada tenga la suficiente autoridad para hacerlo.

Añadir nuevas funcionalidades no es solo el coste de desarrollarlas (que no es poco), sino que también es el coste de mantenerla en la evolución del producto (efectos colaterales, pruebas de regresión, más deuda técnica, posibles conflictos con nuevos desarrollos, etc…), por eso es siempre conveniente analizar con el usuario la conveniencia o no de implementar una nueva funcionalidad, no se trata de poner obstáculos a su desarrollo, sino de poner racionalidad.

Un sistema de información no es mejor por tener más funcionalidades sino porque las que tengan funcionen correctamente y sean de utilidad.

John Carmack es un programador muy conocido en el mundo de desarrollo de videojuegos por haber creado los motores gráficos que dieron lugar a los primeros juegos de tipo Shooter Primera Persona, como Wolfstein, Doom o Quake.

Sobre la incorporación de nuevas funcionalidaes, tiene la siguiente cita: “El coste de añadir una funcionalidad no solo es tiempo que lleva programarla. El coste también incluye la adición de un obstáculo para una futura expansión.

Otro antipatrón relacionado con la falta de simplicidad en la solución obtenida.

Son ya unos cuantos. Para quienes no crean que las mejores soluciones son las más simples que resuelvan un problema, creo que debería dar lugar, como menos, a reflexión.

Y os lo dice alguien que alguna que otra vez ha provocado este antipatrón por el deseo de agradar al usuario y que después se ha tenido que arrepentir por el esfuerzo invertido en hacer algo que no ha aportado prácticamente nada y que encima ha provocado problemas, es decir, el deseo por agradar a algún usuario provocó, aunque sea temporalmente, desagradar a otros y encima se requirió bastante trabajo para implementar las funcionalidades.

No se trata de no hacer lo que pide el usuario, sino de que este conozca las implicaciones que tiene el desarrollo que solicita y el coste que tiene consigo, con el objeto de que piense bien si realmente va a necesitar lo que está pidiendo.

Este antipatrón, va más allá de añadir funcionalidades que se podrían obviar, ya que hace referencia sobre todo a que esas funcionalidades se incorporen a costa de otros factores, como por ejemplo la calidad (que ya de por sí se ve afectada directamente por el incremento de la deuda técnica que tienen aparejadas esas nuevas funcionalidades que no se van a utilizar).

El desarrollo dirigido por quien prueba se puede producir de diversas formas.

Una de ellas es que el área usuaria no se centre en definir de manera adecuada las funcionalidades, especificando las mismas sin pensar de manera adecuada qué quiere, cómo lo quiere y cuáles son las posibles alternativas.

El feedback es la esencia para conseguir un sistema que cada vez se aproxime más a las expectativas del usuario, sin embargo, el feedback no debe basarse en un prueba y error, sino que cada iteración debe realizarse con una intención. En caso contrario nos habremos gastado el presupuesto inicial del proyecto, situándonos lejos del alcance esperado e incluso de la implementacion de todas aquellas funcionalidades consideradas prioritarias.

También nos podemos encontrar esta situación, cuando ante la inacción del área usuaria en el proceso de desarrollo de la aplicación, nos encontramos con que cuando empiezan a utilizar la solución empiezan a informar de incidencias y mejoras que tratan de aproximar más el producto a lo que necesitan.

Otra posibilidad es que ya sea por la no participación del área usuaria o por el hecho de que el equipo de proyecto y equipo de testing quieran sacar a relucir su creatividad, se extraen conclusiones de cada iteración de testing para incluir nuevas funcionalidades o mejorar las existentes.