TEMAS DE PRESENTACIÓN

Diseñar la forma en la que una aplicación se verá es una tarea más compleja de lo que a primera vista podría apreciarse. Esta actividad se puede realizar de diversas maneras, algunas fábricas utilizan criterios puramente estéticos y aunque el aspecto es algo fundamental para que una aplicación sea atractiva a los usuarios y comercialmente atractiva es solo una parte del diseño. En esta página no se pretende realizar un análisis exhaustivo ni académico sobre la usabilidad de las aplicaciones pero si pretende exponer algunos temas que algunas veces pasamos por alto en el diseño y desarrollo de nuestras aplicaciones.

Muchas veces vemos aplicaciones que se ven muy bien y consecuente nos resultan impactantes en principio, sin embargo, al comenzar a utilizar el software encontramos aspectos confusos debido a lo heterogéneo de la presentación. Muchas veces encontramos aplicaciones con sofisticadas gráficas y animaciones que crean una barrera al momento de utilizarlas de manera intuitiva. También existen aplicaciones con elementos de presentación que suelen ser muy sencillos pero que tienen una fuerte simbología que nos permite identificar las tareas disponibles de una manera rápida. En esta sección se presentarán aspectos importantes relacionados con la presentación que usualmente pasamos por alto.

Trabajando con Imágenes

Como se suele decir, una imagen vale más que mil palabras y esto en la construcción de aplicaciones sí que es cierto. Las imágenes en las aplicaciones están por doquier y hay una justificación en ello, una imagen puede identificar un concepto relacionado con la aplicación y elimina el esfuerzo de tener que leer por ejemplo una descripción de dicho concepto. Las imágenes suelen utilizarse para aprovechar el conocimiento previo que un usuario pueda tener del software que está utilizando, simplemente el usuario experimentado visualiza la imagen, identifica el concepto relacionado y usa dicho concepto, no tiene que leer de que se trata cada vez que lo va a utilizar. A pesar de brindar ventajas en este sentido, una aplicación debe tener en cuenta que no todos los usuarios son experimentados y que algunos se enfrentan a la herramienta simplemente utilizando su intuición. Teniendo en cuenta esto último, podríamos concluir que una aplicación bien definida debe proporcionar las dos opciones, las imágenes para los experimentados y algún mecanismo de orientación en caso de que no se tenga un conocimiento previo de las funcionalidades, entre estos mecanismos encontramos por ejemplo las barras de estado y los mensajes emergentes y muchos otros.

Las imágenes al igual que cualquiera de los elementos del producto deben ser diseñadas, usualmente por un diseñador gráfico, no debería ser trabajo del desarrollador crear o seleccionar las imágenes de una aplicación. Dicho diseño debe garantizar que existe una coherencia y uniformidad en la simbología utilizada y una clara diferenciación en los elementos visuales y su semántica  Como mínimo se podría esperar que las imágenes de un mismo grupo visual tengan el mismo tamaño, muchas veces las imágenes se construyen con un tamaño diferente al utilizado en la aplicación y luego al ser escaladas se producen distorsiones en las mismas y suelen crear diferencias sutiles que le restan profesionalismo a la construcción. Es necesario considerar que los usuarios no están pensando en imágenes cuando utilizan las aplicaciones, por el contrario su mente que identifica los conceptos de la aplicación espera que dichos elementos estén integrados con la aplicación y esto nos lleva a concluir que las imágenes con colores de fondo no deberían utilizarse en formularios de la aplicación, aunque en algunos casos podrían ser útiles como decoración para elementos emergentes. El color suele ser otro factor importante al momento de diseñar las imágenes ya que colores muy claros tienden a cansar la vista del usuario, en algunas ocasiones pueden relacionarse colores con aspectos como la peligrosidad de una acción, o acciones específicas sobre diversos elementos. Se debe tener en cuenta durante el diseño que si las imágenes utilizadas son muy parecidas el usuario deberá realizar un esfuerzo adicional al identificar la operación que requiere realizar, de manera similar no deberían existir dos elementos iguales con diferentes significados ni un mismo significado con diferentes imágenes ya que esto desorienta al usuario.

Trabajando con Mensajes y descripciones

Una parte importante de la presentación de una aplicación involucra una definición clara de los títulos, etiquetas y descripciones de los elementos de interacción presentados. Títulos poco precisos o ambiguos suelen confundir al usuario respecto a la ubicación u operaciones que desea realizar. Es importante que se examinen los títulos teniendo en cuenta algunos criterios sencillos:

Minimalidad y Simplicidad

Los mensajes presentados deben decir de la manera más simple lo que desean expresar, de igual manera se espera que un mensaje comunique de manera directa su contenido, esto es, las palabras mínimas requeridas para expresarlo. Mensajes muy largos o con más de una idea pueden confundir al Usuario novato y aburrir al usuario experimentado hasta el punto de obviar la advertencia realizada. Respecto a este punto un mensaje similar al presentado a continuación

“Confirma que desea eliminar permanentemente estos elementos?”,

Es preferible a otro como el siguiente:

“La lista de los elementos seleccionados en la aplicación será removida indefinidamente como consecuencia de la ejecución de de la operación en curso. Está seguro que desea realizar la operación solicitada?”.

Coherencia del lenguaje

Se debe tener en cuenta que un usuario normalmente utiliza software como herramienta para realizar de una manera más fácil y rápida un oficio que muy probablemente pertenezca o otra área del conocimiento distinta a los sistemas de información. Por este motivo, los mensajes y las advertencias deben estar en el lenguaje de área de conocimiento del usuario, para ilustrar un poco esto consideremos los siguientes mensajes utilizados para describir la misma situación y evalúe cual se encuentra en el lenguaje apropiado para un cajero de una pequeña tienda o almacén.

“Se ha detectado una inconsistencia de accesibilidad entre los elementos seleccionados para procesar la transacción solicitada. La cardinalidad entre los productos suministrados y sus descripciones debe ser equivalente (Uno a uno)”

“Tenga en cuenta que cada producto debe tener una y solo una descripción”

Contextualización

Los mensajes deben estar en contexto con las tareas realizadas por el usuario aunque deben ser lo suficientemente explicitos (dentro del contexto) para entender la situación. Evalúe los siguientes mensajes e identifique cual está en el contexto indicado para un usuario que se encuentra guardando un archivo.

“Seleccione la ubicación para guardar el archivo”

“Guardar”

Claridad

Por último los mensajes claros son claves para que el usuario se sienta cómodo utilizando nuestra aplicación, un problema en la claridad de un mensaje puede ser una consecuencia de una falla en los conceptos anteriormente descritos ya que un mensaje se puede hacer tan complicado o elaborado como se quiera. Por ejemplo:

“El protocolo de transferencia de archivos ha arrojado una excepción en tiempo de ejecución (0x12345) debido a un desbordamiento de la pila. Si los archivos no se han transferido, entonces se enviarán la próxima ocasión que el mecanismo de conexión se restablezca. En caso de que los dispositivos de red se encuentren disponibles”

“No se pudo establecer la comunicación para enviar los datos, se intentará reenviarlos cuando la comunicación se restablezca.”

Trabajando con opciones

Se pueden definir diferentes estrategias en la presentación de opciones al usuario, por un lado podemos optar por presentar las opciones de manera contextual, es decir en este modelo el usuario descubre las opciones dependiendo de las funciones, el área de trabajo o el contexto en el que se desenvuelve, aunque esta estrategia suele ser muy cómoda para el usuario representa un esfuerzo adicional en la construcción y un exceso de contextualización puede confundir al usuario sobre la localización de las opciones. Por otro lado se pueden agrupar según los tipos de características ofrecidas y visualizar los grupos de manera estática, por ejemplo, podemos colocar todo lo relacionado con la configuración en un grupo de “Opciones” y todo lo relacionado con el manejo de archivos en “Archivo”. Pueden mezclarse los métodos mencionados anteriormente para lograr una eficiencia en la presentación de opciones, esto debe hacerse con cuidado para no saturar al usuario con la redundancia introducida y consecuentemente las opciones definidas en las diferentes formas deben ser representadas visualmente de manera única para evitar confusiones.

Diseñando la usabilidad

Diseñar la usabilidad de una aplicación puede ser todo un reto, a pesar de no tener un impacto en los resultados de la construcción, la usabilidad brinda confort a los usuarios. A medida que simplificamos más los elementos de interfaz de usuario, es decir a medida que hacemos más sencillas de usar a nuestras aplicaciones, la complejidad interna puede aumentar para soportar estos aspectos. Algunas características son claves para incrementar la usabilidad de una aplicación, por ejemplo el número de clics que un usuario debe efectuar para realizar una tarea específica es clave para la usabilidad. Por otro lado hacer que nuestra aplicación tenga la mayor cantidad de información disponible para su uso suele ser otro factor determinante para la comodidad de los usuarios sin incurrir en excesos. La distribución del espacio, la distancia entre los elementos visuales y su agrupación también aportan un gran valor al momento de operar un sistema de información.

Importancia de la Usabilidad

En muchos casos la usabilidad de una aplicación se ve reflejada y dirigida en el rendimiento operativo de los usuarios y es por esto que las características de usabilidad pueden impactar en gran medida la productividad del sistema de información. Para entender un poco más de que hablamos podríamos considerar como ejemplo un centro de atención telefónica que cumple con las siguientes condiciones:

· Los clientes se contactan con asesores por ejemplo para efectuar un proceso de actualización de datos.

· Los clientes suelen ser impacientes y es muy probable que éstos tengan un umbral o límite en el tiempo de espera que asumen es necesario para procesar su solicitud, si esperan demasiado, se aburren y simplemente declinan la operación.

· Considere entonces que un asesor puede recibir muchas llamadas y que utiliza una aplicación para registrar los datos proporcionados por el cliente, mientras más se demore en procesar los datos de un cliente menos clientes podrá atender en un tiempo determinado por ejemplo de una hora.

· Asuma que de manera adicional la compañía de asistencia telefónica realiza su facturación dependiendo del número de clientes satisfechos atendidos o del número de registros actualizados.

· Probablemente la empresa no se haya dado cuenta, pero existe un problema de usabilidad de la aplicación utilizada para ingresar la información en la base de datos.

· El problema consiste en que el usuario debe realizar un clic sobre cada campo cada vez que desea ingresar información para dicho campo y no dispone de una forma directa para llenar la información y continuar con el siguiente.

Teniendo en cuenta las condiciones mencionadas anteriormente podríamos efectuar la siguiente reflexión sobre el funcionamiento de la empresa:

Si para llenar cada valor el usuario gasta un segundo (1) adicional al tiempo de escritura para abandonar el teclado, tomar el ratón y regresar al teclado, y los datos del usuario son por ejemplo veinte campos, el usuario perderá 20 segundos por cada actualización, si la actualización de los datos se estima en promedio en un minuto (60s) el usuario estaría perdiendo la tercera parte del tiempo. Esto nos indica que realizar una simple corrección en la usabilidad de la aplicación nos permitiría triplicar el volumen de clientes atendidos en un minuto. Si la empresa pierde este tiempo en un asesor pasaría inadvertido, sin embargo si el centro de soporte cuenta con un equipo de 40 personas y todas tienen el mismo comportamiento en el uso ya que todos los individuos operan la misma aplicación, la empresa podría estar perdiendo una suma significativa de dinero al momento de realizar la facturación.

En algunos casos la usabilidad puede impactar en el confort de los usuarios y aun así no tener un impacto de esta magnitud, sin embargo un usuario que encuentra difícil de utilizar un producto eventualmente lo abandonará para adquirir otro que le haga las cosas más fáciles.

Definiendo parámetros de usabilidad

Teniendo claro los factores mencionados anteriormente, se debe tener una clara expectativa en términos de usabilidad. Se deben definir al menos los siguientes aspectos respecto a la funcionalidad construida:

¿La productividad del negocio se puede ver directamente asociada con la facilidad de uso de nuestra aplicación? Aunque en muchos casos esta situación puede presentarse, en muchos otros casos la productividad puede estar acotada por los tiempos del proceso del negocio y consecuentemente pasar a un segundo plano, de todas maneras es muy importante que se tenga claro el impacto de la usabilidad de un sistema de información en las operaciones del negocio.

¿Se han identificado las tareas más comunes a realizar por los usuarios? De una aplicación suele esperarse que las tareas más comunes se realicen con mayor rapidez que aquellas que se producen de manera eventual. Si no se han identificado cuales son las operaciones más comunes la construcción de la aplicación puede terminar siendo muy usable en las cosas que no se utilizan con frecuencia por lo que los usuarios tendrán las mismas dificultades que si no se hubiera diseñado el uso.

¿Las funciones más utilizadas están disponibles en localizaciones cercanas al área de trabajo relacionada? La cercanía de las operaciones ayuda al usuario a concentrarse en el trabajo y no a buscar donde se encuentra la función que desea utilizar. Un ejemplo clásico de esto es un editor de texto en el que no se puede obtener un menú de opciones comunes mientras se encuentra ubicado en el área de edición.

¿Existe un comportamiento común para la funcionalidad implementada en otras aplicaciones? En algunos casos los usuarios perciben dificultades al momento de utilizar cierta característica debido a que poseen costumbres asociadas a otras aplicaciones, por ejemplo, un editor de texto en el que no se pueda copiar texto seleccionado realizando clic derecho o presionando CTRL-C, es probable que un usuario lo encuentre difícil de utilizar ya que casi todos brindan esta característica.

¿Se han identificado las preferencias de dispositivos de interacción?Al momento de diseñar la usabilidad de nuestra aplicación debe tenerse en cuenta que no todos los usuarios tienen las mismas preferencias sobre los periféricos de entrada, algunos utilizan en exceso el ratón otros prefieren realizar la mayoría de las operaciones con el teclado, otros lo harán por smartphones o tablets. Tenga en cuenta que abarcar la mayoría de opciones no solamente le ayudará a la aplicación a adaptarse a las costumbres del usuario sino que también brindará opciones importantes al momento de faltar uno de ellos en caso por ejemplo de que se haya dañado el ratón a media noche y se tenga que entregar un informe a la mañana siguiente.

¿Los elementos de interacción con el usuario que se han seleccionado permitirán un mínimo de esfuerzo para su utilización? Muchas veces encontramos aplicaciones que presentan opciones de maneras equivocadas, por ejemplo una lista desplegable que solo tiene dos opciones, si y no lo único que logra además de la reducción del espacio es agregarle trabajo adicional a un usuario de descubrir cuáles son los elementos de la lista, mientras que sería más apropiado tener una casilla de chequeo que presente una sola opción activada o desactivada. Si los valores pueden ser escogidos de una lista, entonces poner a escribir la información al usuario únicamente le agrega más trabajo y si la lista es estática y no supera el número de 5 items entonces es mejor presentar las cinco opciones con una selección excluyente así al usuario no le toca realizar un clic adicional para descubrir el contenido de la lista. Existen muchas formas de equivocarse en la selección de los elementos, y en muchas ocasiones estos ocurren debido a la facilidad de integración de algunos componentes que es atractiva para reducir tiempos en la construcción por parte de los desarrolladores, sin embargo lo que es bueno para los desarrolladores no necesariamente es bueno para los usuarios.

¿Se han considerado los distintos tipos de usuario y sus límites en el diseño? El diseño de la usabilidad de una aplicación podría estar afectado por las expectativas de productividad para distintos grupos de usuarios, por ejemplo se puede definir que el 40% de los usuarios nuevos deben poder instalar el producto en menos de 15 minutos sin ayuda alguna, o puede definirse que el 80% de los usuarios experimentados deben ser capaces de construir un documento pequeño completo en menos de 10 minutos. Este tipo de consideraciones nos permiten direccionar el rendimiento de la aplicación hacia el tipo de usuarios que son más importantes para nosotros.

¿Se han involucrado en el diseño de usabilidad a los usuarios finales de manera previa a la construcción? No hay nada peor que el esfuerzo y el trabajo perdido, y en algunas ocasiones los diseñadores y desarrolladores definen formas de interacción con el usuario que no han sido consultadas ni aprobadas por los mismos, esto redunda en un esfuerzo en vano y un rechazo frente a una funcionalidad esperada de cierta manera por los usuarios de la aplicación. Es importante que una vez se haya diseñado la forma en la que los usuarios interactuarán con la aplicación se someta a la aprobación por parte de los mismos para evitar construir algo que no obedezca a las expectativas de uso de quienes finalmente utilizarán la aplicación.

Construyendo Interfaces intuitivas

Un aspecto fundamental en el diseño de la usabilidad de una aplicación es la capacidad que brinda el software construido para ser comprendido y aprendido por el usuario en una manera eficiente, se espera que un usuario pueda intuir el funcionamiento básico de una aplicación sin un conocimiento previo de los elementos visuales, de igual manera se espera que un usuario experimentado pueda identificar de manera eficaz las acciones a realizar. Para lograr esto de manera eficaz se requiere que se diseñen opciones de presentación de mensajes que le permitan a un usuario novato consultar las funcionalidades, una forma muy común de lograrlo es utilizar mensajes emergentes (tooltips) que se presenten al posicionarse en los elementos visuales, en algunas ocasiones también se pueden presentar descripciones sobre las opciones de la aplicación en barras de estado o con menús emergentes con opciones como“Que es esto?” aunque esta opción personalmente no me gusta mucho. Los mensajes deben ser lo suficientemente descriptivos para que el usuario novato comprenda de qué se trata la opción adecuada. De la misma manera, las acciones que puedan comprometer datos o tener consecuencias irrecuperables deberían presentar mensajes de confirmación que le permitan al usuario nuevo entender las consecuencias de la acción que está por efectuar.

Es importante que una aplicación le permita al usuario comprender el estado y el contexto en el que se encuentra trabajando para que de esta forma pueda tomar las decisiones pertinentes, por ejemplo si un usuario está efectuando una tarea que implica un largo tiempo de procesamiento debe presentarse algún indicador sobre el progreso de la operación, de otra manera el usuario no comprenderá lo que está sucediendo y eventualmente buscará la manera de deshacerse del programa en ejecución lo que para algunos procesos pueden resultar en consecuencias desastrosas. Se pueden presentar barras de progresión o imágenes y mensajes que indiquen que existe una operación en proceso.

Hay que tener en cuenta que a veces es conveniente que las pantallas tengan un comportamiento dinámico, esto debe realizarse con moderación ya que una presentación muy cambiante puede despistar y confundir al usuario sobre la ubicación de las funcionalidades, al momento de dinamizar el comportamiento de una pantalla de captura por ejemplo prefiera presentar componentes inactivos en vez de ocultarlos, si están inactivos el usuario sabrá que no se encuentran disponibles pero tendrán una idea clara de la ubicación de dicha funcionalidad mientras que si se ocultan la mente del usuario no relacionará la funcionalidad oculta con su localización dentro de la aplicación lo cual logrará que en futuros usos tarde mas en identificar donde se encontraba.

Captura de Datos

Algunos desarrollos presentan problemas en la captura de datos, en algunos casos debido al exceso de ventanas modales anidadas durante el proceso de captura de datos específicos de una aplicación. Hay algo que es necesario entender sobre las ventanas modales, estas sirven como instrumento para sincronizar la entrada de la información y evitar estados inconsistentes debido a ingresos paralelos, sin embargo, para capturas de datos jerárquicas esto suele incluir algunos problemas de usabilidad, entre dichos problemas podemos encontrar la pérdida de la visión global de los datos de entrada dentro de la jerarquía. Para entender esto pensemos en el siguiente ejemplo, imagine una ventana modal que tiene dos botones, cada botón presenta una nueva ventana modal que nos impide ver la información en la ventana anterior, en este caso el usuario incurre en un sobre esfuerzo ya que es probable que para tomar una decisión deba consultar un dato de la ventana padre, para esto deberá mover la ventana para visualizar dicha información. Ahora supongamos que esta segunda ventana tiene una tercera anidada o ventaja hija, teniendo en cuenta que cada ventana bloquea las acciones de la anterior, el usuario podrá mover la tercera ventana para visualizar los datos de la segunda, sin embargo, si deseara visualizar información en la ventana principal, el usuario deberá cerrar la tercera ventana y mover la segunda. A medida que se agregan más cuadros de dialogo anidados se hace más difícil utilizar la aplicación. Una solución a este problema es utilizar un modelo coherente de los datos que se están solicitando y diseñar una única forma que permita administrar la jerarquía, por ejemplo con un árbol que presente la jerarquía y una ventana de propiedades cambiante según la posición dentro del árbol, de esta manera si un usuario se encuentra ubicado en a tres niveles y desea saber la información en el nivel superior con un solo click se puede trasladar hasta el nodo principal, en la mayoría de los casos puede presentarse toda la información en la misma ventana sin que se sature mucho la interfaz de usuario.

La captura de los datos suele requerir validaciones para garantizar que los datos solicitados tengan cierto nivel de consistencia. La presentación de errores debería nuevamente minimizar la presentación de cuadros de mensajes en los que no se toma ninguna decisión, esto suele ser incomodo para un usuario ya que debe realizar un clic adicional cada vez que se equivoca debido a la presentación del cuadro de mensaje. Una estrategia que simplifica este tipo de problemas es agregar una etiqueta o lista dentro de la misma ventana que presente todos los errores dentro de los datos ingresados. No utilice mensajes genéricos como el “campo es inválido” el usuario poco experimentado necesitará información adicional para resolver el problema, a cambio de esto puede complementar el mensaje por ejemplo diciendo “El valor del campo XXX debe ser un número válido”.

Espero que las sugerencias plasmadas en este documento por muy sencillas que parezcan sean tenidas en cuenta para poder cada dia mas disfrutar de una mayor comodidad en nuestros quehaceres informáticos. Adicionalmente agradezco su participación en el desarrollo de estos contenidos y espero sus comentarios.

SOBRE EL SOFTWARE Y OTROS PROBLEMAS

Antes que nada, gracias a todos los lectores con paciencia para revisar los conceptos expuestos en las entradas expuestas.  Espero que las mismas sean de utilidad para mis lectores.

SOBRE EL SOFTWARE Y OTROS PROBLEMAS

Una situación muy común en el desarrollo de software que vemos por montones en empresas de tecnología es la ausencia de los propósitos específicos en la construcción, muchas empresas esperan obtener buenos resultados en su construcción, sin embargo sienten que por más esfuerzo que se invierta en el desarrollo, el software resultante carece de calidad o produce errores no previstos, sienten que soportar las funcionalidades existentes es una pesadilla y al mismo tiempo quieren que su software crezca a medida que avanzan las exigencias de los usuarios.  Este tipo de situaciones lo que evidencian es una clara falta de estructura y desconocimiento sobre lo que hacemos, a continuación se presentan algunas preguntas que suelen ser claves en la adquisición de este conocimiento y que pueden representar la diferencia entre alcanzar el resultado que deseamos y fracasar en el intento.

¿Qué es nuestro producto?

Toda empresa debe saber de manera clara a que se dedica, si no sabemos lo que queremos no debe extrañarnos que no obtengamos lo que deseamos.  Esto lo entienden personas sin educación especializada que administra un negocio familiar, si se le pregunta, probablemente su respuesta sea “fabrico zapatos” o “fabrico trajes”.  Aunque el software es un tanto más difícil de definir ya que el concepto toma diferentes significados dependiendo de las soluciones que este brinde a los clientes, el caso de la producción de software no es la excepción, si pensamos que el resultado de nuestras operaciones es un conjunto de líneas de código que implementan diversas funcionalidades, probablemente no hemos definido apropiadamente nuestro producto.  El código fuente de una aplicación es sólo una parte de nuestra fábrica, una parte muy importante ya que nuestro trabajo se ve reflejado de manera directa en su funcionamiento, sin embargo, un código fuente que requiere ser modificado permanentemente  incrementa los costos al momento de hacerlo crecer,  un código fuente que ha sido el resultado de solucionar situaciones particulares de negocio probablemente no tenga la generalidad necesaria para ser extensible a mediano plazo.  Un código fuente que se ha creado de manera tal que no se puedan sacarse conclusiones sobre la forma en la que ejecutamos nuestras tareas es un artículo que únicamente ha generado valor a los usuarios finales y nos ha impedido adquirir un nuevo conocimiento sobre la manera en la que hacemos las cosas. Un código fuente cuya calidad no es susceptible de cuantificarse suele representar un problema frente a futuros cambios.  Un código fuente carente de documentación crea problemas potenciales de dependencias de recursos humanos, mala comunicación y rendimiento frente a cambios imprevistos de personal.  Todos estos aspectos tienen sus consecuencias en los costos de implementación del mismo.

Por las razones mencionadas anteriormente y muchas otras es necesario que tengamos una visión clara de lo que esperamos producir que en el caso de software, evidentemente es algo más que simples líneas de código en un sistema de administración de versiones.  Para definir sin ambigüedades lo que espera que sea su producto tenga en cuenta los siguientes puntos:

·         Qué problema general del mundo real se resuelve con la aplicación del producto realizado?

·         Cuál es el público objetivo beneficiado de la utilización del producto?

·         Que características agregan mayor valor al producto?

¿Con que contamos?

Algo importante para alcanzar el producto definido previamente es tener una idea realista de los recursos con los cuales contamos, muchas pequeñas empresas establecen sus expectativas al nivel de otras empresas que llevan mucho tiempo, años de experiencia en el desarrollo de software y mucho más personal estructurado y trabajando en equipo de manera coordinada.  Esta situación inevitablemente nos llevará a un sobre esfuerzo (posiblemente inhumano) o a un resultado fallido en nuestro proceso de construcción. 

Con lo anterior no queremos decir que deba redefinir su producto por uno con un menor alcance, lo que se pretende es mostrar que existe un conjunto de limitaciones sobre cuanto podemos producir.  Aunque no cuente con los recursos necesarios para asistir a todos los aspectos relacionados con su producto, Usted siempre tendrá la opción de hacer lo mínimo (siempre que se haga bien) y postergar las oportunidades de mejora sobre el producto.  Tenga en cuenta que postergar significa en este contexto que deberá idear un plan y fijarse unas metas para poder alcanzar el objetivo, significa que se ha cambiado la prioridad a estas oportunidades y no que se hayan descartado.  A medida que pase el tiempo debemos tratar de darle una prioridad cada vez mayor de otra manera nunca realizaremos estos trabajos postergados.

Si se le pregunta a un fabricante de zapatos cuantas suelas tiene, cuántos trabajadores tiene, cuanto cuero le queda, si tiene martillo o no, probablemente éste le contestará de manera inmediata y esto se debe a que para la elaboración de sus productos se tiene inventariada la materia prima, las herramientas, y mucho mas, esto nos permite estimar cuantos zapatos es capaz de producir dicha fábrica.  De igual manera en la construcción de software es conveniente contar con un inventario que nos ayude a inferir la cantidad y la calidad de lo que podemos producir en un momento dado.  Para poder realizar esto de manera efectiva, tenga en cuenta que la materia prima de un equipo de desarrollo de software son el conocimiento, las habilidades y el talento humano de los miembros del equipo, hecho por lo cual deberíamos conocer los aspectos mencionados anteriormente en detalle.  Tenga en cuenta que la cantidad y la calidad de las características generadas no son necesariamente proporcionales al número de miembros del equipo de trabajo, esto se puede explicar por el desconocimiento de las habilidades que redundan en malas asignaciones en la construcción o simplemente por los errores introducidos por la interacción y la mala comunicación entre los miembros del equipo de trabajo.  Existen proyectos, por ejemplo, con funcionarios extremadamente calificados que realizan sus asignaciones o tareas de trabajo en tiempo record y al momento de integrar todo en una misma solución el proyecto se alarga de manera estrepitosa,  esto suele ocurrir debido a una distribución inapropiada o a la poca claridad de las responsabilidades individuales teniendo en cuenta su función dentro del desarrollo colectivo. 

De una manera bien estructurada, la fabricación de productos de software puede crecer a medida que se incrementa la mano de obra, de otra forma simplemente se incurre en sobrecostos y se extienden las fechas de entrega.

Pero no solo necesitamos personas y una estructura organizacional, también necesitamos las herramientas, si ya contamos con herramientas especializadas no hay problema, sino, deberemos definir si contamos con recursos económicos para adquirirlas o si podemos hacer uso de herramientas gratuitas disponibles en internet.

¿Cómo lo hacemos?

Definir la forma en la que vamos a realizar nuestras operaciones suele ser inicialmente una tarea ardua y compleja, sin embargo, en el tiempo se mejoraran los procedimientos a medida que se vayan identificando las necesidades de nuestro equipo de desarrollo.  Defina un plan de mejoramiento continuo sobre sus procesos, esto estará allí recordándole que existen oportunidades de mejora sobre dichos procedimientos.  Cada vez que finalice una construcción identifique aquellas cosas que fueron muy útiles  en el proceso y las que causaron problemas, intente darle un orden viendo las actividades como un todo.

¿Qué aprendemos de lo que hacemos?

Pareciera que muchas empresas de tecnología trabajan arduamente y obtienen los resultados esperados en algunas ocasiones, sin embargo, notamos que muchas veces se comienzan a producir errores en los procedimientos que han ocurrido anteriormente.  En algunas situaciones no se cuenta con el tiempo o los recursos suficientes para tomar medidas al respecto, algunas veces es simplemente falta diligencia en la toma de decisiones.  Todos estos temas pueden estudiarse con una simple pregunta ¿Qué aprendemos de lo que hacemos?  Esta parece una pregunta sencilla pero que puede ser muy difícil de responder si no tenemos la disposición suficiente para autoevaluarnos. 

Aprender de lo que hacemos puede ayudarnos  en los siguientes aspectos:

·         Nos brinda posibilidades para mejorar nuestros procedimientos y encausarlos por una dirección que esté alineada con los objetivos de la construcción.

·         Nos ayuda a aprender a detectar donde están las fallas de dichos procedimientos para poder establecer planes para corregirlas.

·         Nos permite agrupar las experiencias y de esta manera identificar áreas de interés común.

·         Nos permite establecer procedimientos claros frente a situaciones particulares para poder invertir nuestros esfuerzos en aspectos importantes del negocio.

·         Nos lleva a cuestionarnos sobre otros aspectos en los procedimientos que anteriormente no hubiéramos tenido en cuenta.

Esta pregunta puede dividirse en muchas otras dependiendo de la naturaleza del negocio.  Por ejemplo, podríamos preguntarnos ¿Qué hemos aprendido de nuestro manejo con los clientes?  Esto nos ayudará a mejorar nuestra relación con los mismos y consecuentemente se reflejará finalmente en su satisfacción y lealtad.  Muchas compañías invierten cantidades significativas de su presupuesto en sistemas de información para la administración de las relaciones con los clientes y aún así fracasan en sus estrategias, esto se debe a que no basta con tener los datos,  no basta con tener la infraestructura sino que adicionalmente toca comprender de manera objetiva la información.  

Otra pregunta que podríamos hacernos es ¿Qué hemos aprendido de nuestros costos?  Muchos proyectos de tecnología podrían verse como “agujeros negros de capital” ya que se invierte en personal calificado, se invierte en recursos, se invierte en tecnología y aun así los tiempos de construcción se alargan hasta el infinito lo que finalmente se refleja en los costos de la construcción.  Este tipo de proyectos suelen consumir todos los recursos invertidos y perderlos sin ningún resultado, esto puede ser consecuencia de un riesgo asumido durante las negociaciones previas a la construcción o a ideas mal definidas o poco claras sobre lo que se espera de dicha construcción.  Una mala o excesiva gestión de los requerimientos podría también impactar significativamente en los tiempos de implementación.  Una fábrica podría operar de esta forma en los desarrollos iniciales, sin embargo si esto se vuelve recurrente probablemente no estamos aprendiendo nada de lo que hacemos con nuestras inversiones.  

¿Qué hemos aprendido del trabajo en equipo?  El trabajo en equipo suele adoptar diferentes formas en una organización, esto se debe a factores externos tales como las relaciones interpersonales,  aspectos culturales colectivos e individuales.  Identificar puntos de falla y buenas prácticas en nuestro trabajo de equipo nos ayudará a ser más productivos, a reestructurar ciertas áreas y a visualizar algunas que antes no se tenían previstas. De manera adicional aprender de nuestro trabajo en equipo nos ayudará a identificar habilidades dentro de nuestros grupos de trabajo y de esta manera tener una base experimental a partir de la cual se puedan asignar de una manera coherente las responsabilidades dentro de los miembros de la organización, de otra forma termina Albert Einstein siendo un secretario de la recepción y personas menos capacitadas o menos interesadas en la administración dirigiendo aspectos fundamentales sin ningún rumbo.

¿Qué hemos aprendido de las negociaciones?  Aparentemente cada negociación es única y depende de muchos factores en la mayoría circunstanciales por lo que es difícil tratar de predecir como resultarán, sin embargo, es necesario que se adopten políticas dependiendo del aprendizaje previo, de no verse de esta forma se corre el riesgo de tener negociaciones que redunden en pérdidas para la fabrica.  Resolver esta pregunta es vital para tener una base sobre el comportamiento de nuestras negociaciones y poder tomar acciones correctivas y definir estrategias  que nos ayuden a crecer en estos aspectos.

¿Podemos medir nuestros productos?

Como podría un zapatero tener utilidades numerosas si no sabe cuánto material gasta en la construcción de un articulo?  ¿Cómo podría el mismo saber cuánto puede producir si no conoce su inventario? ¿Cómo puede establecer el precio del artículo si no conoce las diferencias en calidad y esfuerzo invertido para cada uno de sus modelos?  Estas preguntas nos llevan a entender que mientas más información tengamos de nuestros productos y nuestros procesos podremos darle el valor.  En el caso de la construcción de software una fábrica que no conoce la arquitectura ni el estado de su código fuente, que no puede medir la producción o que no puede cuantificar la calidad de sus desarrollos es una fábrica que trabaja a ciegas, con una incertidumbre muy alta y esperando siempre resultados fantásticos.   Para tener una visión apropiada al respecto, debemos pensar primero en nuestras métricas, saber que deseamos medir y  como repercuten las mejoras a dichas métricas en el objetivo final de nuestra fábrica. 

¿Podemos medir nuestros procedimientos?

En nuestra fábrica podemos medir el tiempo para realizar todas las tareas requeridas para la producción del software?  Probablemente el zapatero si lo sabe. En muchas ocasiones los gerentes de proyectos de tecnología no conciben la idea de no poder estimar cuanto tomará en tiempo por ejemplo la definición de los requerimientos de determinada aplicación, o cuanto tomará en recursos la construcción de un módulo o una funcionalidad. 

¿Podemos predecir los impactos? ¿En cuántos Niveles?

Predecir el impacto que pueda producir un cambio sobre una solución no es una tarea fácil si no se tiene una idea general suficientemente clara de la estructura de nuestros desarrollos, existen relaciones y reglas conceptuales o implícitas entre las componentes de nuestro producto que no se reflejan de manera directa en la programación y mientras menos información se tenga sobre las dependencias de cada uno de los componentes que conforman la solución o conjunto de soluciones, será más difícil estimar dicho impacto.  El diseño dirigido por modelos arquitectónicamente bien construidos suele ser una aproximación interesante y poderosa al momento de asignar e identificar claramente dependencias entre componentes con distintas responsabilidades. 

Como usualmente ocurre, una solución por software a un problema general estará compuesta de un subconjunto de problemas particulares e independientes que de manera conjunta interactúan para dar una solución completa a un caso de negocio específico.  De esta manera algunos estructuran el software en capas, otros en anillos, otros por funcionalidad, sin embargo, parece que no importa de qué manera delimitemos las componentes de nuestro desarrollo, siempre debería ser posible cuantificar cuantos niveles se afectarían por los cambios realizados.   Si ya tenemos el conocimiento sobre el número de dependencias sobre los componentes de la solución, entonces debemos dar el siguiente paso, y este consiste en diagnosticar los segmentos de código que podrían presentar efectos indeseados.  Posteriormente se presentan algunas estrategias para combatir este tipo de problemas.

¿Tenemos problemas heredados del pasado? ¿Cómo los combatimos?

Los problemas heredados del pasado suelen ser una de las causas más relevantes de resistencia a cambios al momento de revaluar la arquitectura de un producto.  Si se plantea reestructurar una solución de software, pensamos inmediatamente en problemas de arquitectura que se presentan actualmente debido a correcciones del pasado que aún se soportan.  Como combatimos estas circunstancias?  Una forma es separar la implementación comercial de la implementación reestructurada.