¿Cómo seleccionar una herramienta de software?

Ya sea que deseemos implementar una herramienta para eliminar planillas, o procesamiento manual, o decidimos que la herramienta actual en uso ya no satisface nuestras necesidades, no nos enfrentamos a una tarea sencilla. Y no se dejen engañar… porque no es nada sencillo!

Es muy importante no dejarse llevar. Las funcionalidades que describen las propias herramientas, a veces parece que son suficiente para lo que queremos hacer, pero luego resulta que existen limitaciones, ciertas funciones están disponibles en versiones pagas, o sólo en la versión en la nube, o viceversa, etc. O peor aún, algunas aún ni siquiera fueron liberadas!

Tampoco es suficiente decidir en base a las recomendaciones de amigos, colegas, consultores. (Obviamente, según el vendedor, su herramienta esta la mejor!). Lo que le sirve a uno, no necesariamente le sirve a todos. Por lo tanto, debemos tomar las recomendaciones, tanto positivas como negativas, y preguntar por qué dan dicha evaluación.

Y esta es la clave: tenemos que identificar y definir  para qué queremos usar la herramienta. Esta es la parte más difícil del proceso. Sentarnos y … “escribir requisitos”. Somos nuestros propios clientes. Tenemos que saber escucharnos, aplicar esas técnicas que les recomendamos a los equipos para elicitar requerimientos, y escribir los requerimientos.

Para ello podemos apoyarnos en las características que ofrecen las diferentes aplicaciones, y preguntarnos si queremos o necesitamos eso, y para qué.

Si es una herramienta de gestión, qué metodología voy a aplicar? quiero poder gestionar las tareas, los insumidos… necesito flujos fácilmente adaptables? Qué restricciones de seguridad tengo? la herramienta debe permitir monitorear el estado de avance, notificar vencimiento de tareas, métricas? etc etc…

Dependiendo de nuestra necesidad, podremos delimitar la lista a un conjunto de herramientas.

El próximo paso es probarlas a todas. Sí, todas las del conjunto seleccionado. La mejor forma es usarla como esperamos usarla, la forma ideal, es definir casos de prueba que respondan a los requisitos que escribimos, y ejecutarlos.

Si llegaron hasta este punto, se habrán dado cuenta que no estoy inventando la pólvora, simplemente les recomiendo aplicar prácticas de desarrollo de software que ya conocemos, excepto que el desarrollo fue realizado por un tercero.

La frutilla del postre, es enmarcar esta evaluación bajo un proceso de decisiones formales, (DAR en CMMI, GDE en MPS) donde además de los requisitos, casos de prueba, definimos algunos criterios adicionales como costo, performance, soporte, facilidad de uso, capacidad de crecimiento (puedo empezar chico, pero avanzar a multiples proyectos con muchos usuarios, por ejemplo) y algún otro que se les ocurra. Evaluamos los criterios, y tomamos una decisión fundamentada.

En este viejo post, hay un ejemplo de cómo aplicar DAR: CMMI: ¿Para qué sirve DAR?

Espero que les sirvan estas recomendaciones. Es un proceso tedioso, pero es mucho más barato que el costo de cambiar una herramienta una vez que está en uso, donde tenemos todos nuestros proyectos en marcha, porque nos dimos cuenta tarde que no era lo que necesitábamos …

Leave a Comment

Your email address will not be published. Required fields are marked *