Desarrollar no es solo empezar, parte I

Tanto si te has iniciado recientemente en el desarrollo de aplicaciones como si ya llevas un tiempo o incluso eres un desarrollador avezado, sabes que siempre llega un momento que para todos los “maestros del código” representa un viacrucis: la documentación y el soporte. Muchas veces, preparar esa documentación y sobre todo, el soporte asociado a una aplicación supone una cantidad de tiempo que no se suele valorar económicamente en un principio y que muchas veces podría reducirse notablemente si desde el principio de proyecto se hubiera tenido en cuenta estos puntos. Hoy hablaremos de la documentación y posteriormente, del soporte.

El error más común que cometen los desarrolladores independientes es dedicar todo el tiempo al código y olvidarse de la documentación asociada al mismo. No hablamos en si de las notas internas de desarrollo, sino de la información (o ayuda) que recibirá el usuario final con la aplicación o tendrá en línea para consultar. Esta tarea, que suele realizarse en muchos casos al final del proyecto, se crea cuando el desarrollador o grupo de desarrolladores está ya exhausto y tiene mucha o relativa urgencia por lanzar su desarrollo lo que implica indefectiblemente que la documentación acaba siendo poca, poco eficiente o deficiente y en algunos casos inexistente.

Para el usuario final la falta de la documentación es, sin embargo, un problema, ya que al enfrentarse a un nuevo software es normal que surjan dudas y que quieran despejarlas. Ten en cuenta, y esta es una regla de oro, que la falta de una documentación correcta implica un considerable aumento de consultas a Soporte Técnico, y esas consultas llevan tiempo y el tiempo es dinero.

Entonces, ¿cuándo se escribe la documentación?

Lo ideal es dedicar una persona al proyecto que se encarga de forma específica de escribirla conforme se vayan cumpliendo los diferentes hitos de programación y que adicionalmente podrá encargarse de las consultas realizadas a Soporte Técnico de primer e incluso segundo nivel. Acabará conociendo el programa tan bien como el desarrollador y tendrá la posibilidad de generar retroalimentación sobre qué puntos son los fuertes de la aplicación y sobre todo, cuales son los más débiles en función de las consultas realizadas. Pero esto es Soporte Técnico y hablaremos de el en la segunda parte del artículo.

Claro que no siempre es factible dedicar una persona a esta tarea, así que debe realizarla el mismo desarrollador, que suele resultarle una tarea bastante fastidiosa. El mejor truco para evitar esa animadversión a escribir la documentación es realizarla al principio de la jornada laboral, documentando los hitos cumplidos el día anterior. Y luego seguir “codeando”

“Lo mío no es escribir, es programar”

Esta es la excusa más vieja del mundo para autoengañarse y no documentar eficientemente el proyecto. No vas a crear una novela, sino documentación técnica con lo que no tienes que plantearte ser un Benito Pérez- Galdós, sino escribir textos claros, concisos que expliquen los diferentes puntos de la aplicación de forma que los pueda entender todo el mundo.

El 80% de la documentación es inútil

El gran problema de todas las aplicaciones es que los desarrolladores no las crean con el usuario final en mente y dan por sentado que aquellos que (encima) van a pagar por su software tienen una serie de conocimientos de ciertos aspectos técnicos sobre los procesos de la aplicación que en la realidad  los compradores no conocen, empezando por los términos técnicos utilizados (el maldito Glosario).

La absoluta y total “madre del cordero” de esta situación se define perfectamente cuando un usuario final accede a las preferencias de la aplicación. Si este  usuario, incluso con conocimientos sobre las tecnologías subyacentes que manipula el software, es incapaz de entender como parametrizar el software a través de las preferencias, puede darse por sentado que el desarrollador ha fracasado en su intento de transmitir cómo funciona su software y esto se traduce en un aumento espectacular (en magnitudes de dos dígitos) de solicitudes de soporte técnico. El desarrollador cree entonces que la información escrita es insuficiente y tiene que crear grandes cantidades de documentación adicional para explicar ciertos aspectos técnicos del software en un momento crítico en el que debería enfrentarse a solucionar los primeros errores derivados de una nueva release o versión. Se multiplica el trabajo y el tiempo disponible no aumenta proporcionalmente. Un fracaso.

Muchos desarrolladores solucionan este problema ofreciendo de sets de preferencias: el “sencillo” en el que los comportamientos de la aplicación se parametrizan con un reducido set de opciones y el avanzado, en el que está disponible el “gran mogollón técnico”. Aunque esta aproximación es válida y se reducen las peticiones de soporte, al final el usuario se debe enfrentar al mismo problema: si desconoce ciertos aspectos técnicos será incapaz de enfrentarse a la aplicación y acabará teniendo que “tirar de soporte”.

Perfiles

Algunos desarrolladores han optado por una solución bastante limpia a este problema: los perfiles de preferencias. Previo al desarrollo han investigado  cuales son las opciones que más van a utilizar los usuarios orientadas a los resultados finales (“quiero exportar esta película para mi iPod Touch”) y han creado perfiles en las preferencias, de forma que al elegir uno de estos perfiles, automáticamente todo el comportamiento de la aplicación se modifica para realizar la tarea solicitada sin la necesidad de reajustar todo el set de preferencias en múltiples cuadros de diálogo una y otra vez. Esta opción, destinada específicamente a aquellos usuarios con menos conocimientos técnicos reduce espectacularmente las solicitudes de soporte ya que el usuario final obtiene los resultados que busca de una forma sencilla.

Que los usuarios me ayuden

Muchos desarrolladores confían que la comunidad aglutinada alrededor de un software puede sustituir la falta de documentación (y de paso, hacer de soporte técnico usando un foro). En el caso de la documentación es una muy mala idea, porque no todos los usuarios se expresarán en los mismos términos o lo que es peor, deberás validar cada una de las explicaciones convertidas en documentación para que no induzcan a error a otros usuarios. Y este trabajo supera con mucho al de escribir la documentación por el desarrollador, que conoce la aplicación y maneja de forma consistente a todo lo largo de la misma el mamo glosario de términos.

En la segunda parte de este artículo hablaremos de cómo organizar eficientemente tu pequeño departamento de soporte técnico aplicando una serie de criterios industriales de forma que la gestión de problemas no sea algo que te quite el sueño.

0 0 votos
Article Rating
Subscribe
Notify of
0 Comments
Opiniones Inline
Ver todos los comentarios
0
Me encantaría saber tu opinión, por favor, deja un comentariox
()
x