En su artículo Set your priorities Joel Spolsky habla de como establecer las prioridades a la hora de decidir que funcionalidades se van a incluir en una nueva versión de una aplicación. Como siempre propone un método particular para ello, pero antes dice dos cosas que no debes hacer:
- No implementar una funcionalidad simplemente porque alguien se la ha prometido a un cliente
- No hacer algo porque parece que sea inevitable
La explicación la da en su artículo, pero dedica una sóla linea a explicar que el primer punto no debe ir reñido con escuchar a los usuarios.
Cuando eres un micro-isv no hay departamento de ventas. Tu eres el departamento de ventas, asi que llevas mucho cuidado en qué le dices a un usuario acerca de una determinada funcionalidad requerida para el programa. Y tienes que pensar siempre en lo que te va a costar implementar esta funcionalidad y la mejora que va a suponer para el programa.
Muchas de las funcionalidades de el Puchero están hechas gracias a una usuaria del mismo que me ha ayudado muchísimo a mejorarlo. La primera vez que contactó conmigo me envió una relación de funciones que le faltaban a mi programa para estar a la altura de otros que ella conocía. A partir de ahi fui añadiendo opciones al programa y la verdad es que el programa sería muy pobre si no hubiera sido por ella. Así que tienes que llevar mucho cuidado en no soltar un *NO* cuando te piden algo para un programa y lo que debes hacer es tirar de la lengua a quien te lo pide. ¿ Porque se necesita esa funcionalidad ? ¿ En que mejora el programa ?
Muchas veces los desarrolladores no comemos nuestra propia comida para perros y eso se nota. Llega un correo de alguien interesandose por tu programa y la respuesta es *NO*. Ahi es cuando se tienen que encender las bombillas rojas. Acabas de perder la oportunidad de mejorar tu software.
Es muy diferente el escuchar a los usuarios, que hacer caso al departamento de marketing o ventas sobre lo que creen que dicen los usuarios. Muchas veces las personas de estos departamentos cuidan más sus intereses ante un cliente que los del producto de la organización. Y entonces meten en un embolado al departamento de desarrollo únicamente por que a alguien se le ocurrió firmar un contrato absurdo con una absurda funcionalidad.
Cuando eres tú sólo (o ayudado de alguien) y estás abriendote camino entre muchos como tú y otros que son tremendamente superiores en recursos, el decir *NO* a una funcionalidad que te pide un usuario puede convertirse en una puerta cerrada de forma inmediata, mientras que si no sabes decir *NO* a tiempo a peticiones nimias terminas trabajando por amor al arte.
Está claro que hay que preguntar al peticionario cuales son los motivos de su petición, pero también hay que valorar desde dentro si determinado cambio añade valor al producto.
Personalmente pienso que hay que saber dar «una de cal y otra de arena» y manejar a los usuarios con mano izquierda y no cerrarse en ese *NO* que muchas veces se fundamenta en el miedo a hacer cambios a una trabajo terminado.
Comparandonos con empresas productoras de software enlatado, creo que lo bueno que tenemos los que nos dedicamos libremente a programar es que podemos ofrecer adaptaciones de nuestros programas a determinados clientes previo estudio de viabilidad de esos cambios, cosa que a esas empresas les cuesta muchísimo hacer.
En cuanto a lo de comer nuestra propia comida para perros, estoy totalmente de acuerdo…. Ya sabes el dicho aquel «en casa del herrero, cuchara de palo», ¿por qué será? Una de las prácticas habituales en mis diseños de software es la de imaginarme que soy el usuario, que estoy en el momento de mayor aglomeración de público y que voy a usar mi software de TPV…. Así he conseguido depurar la parte crítica de mis programas hasta límites insospechados, incluso en algunos casos he tenido que sacrificar el entorno visual y hacer el modulo de ventas en modo texto y en otros he tenido que prescindir de los adornos para obtener un buen rendimiento.
Un saludo,
No siempre puedes comer-tu-propia-comida-de-perro.
Hace un par de años, cuando diseñamos un portal web para gestionar la red de nuestra empresa, tuve -literalmente- que espiar a nuestros operadores para averiguar cómo reaccionaban a las incidencias, y cuándo necesitaban información (estado de interfaces, carga de tráfico, sesiones BGP, etc…).
En éstas situaciones *no* puedes utilizar internamente tu programa porque no tienes estas necesidades.
Eso sí, siempre te puedes poner en la piel del usuario y pensar cómo hacerle la vida más fácil… con o sin ayuda del usuario.