viernes, 29 de noviembre de 2013

La inteligencia de las personas no garantiza los resultados

Mejor equipos geniales que personas geniales.
Los mejores resultados no los producen las personas inteligentes,
sino los equipos de alto desempeño.
La semana pasada estuvimos hablando de las buenas prácticas de trabajo durante el desarrollo de soluciones de gestión de información producidas con tecnologías de la información y conceptos de Arquitectura de información. La conclusión incluyó el énfasis necesario que hay que hacer en los métodos, en los procedimientos definidos y gestionados, en la mejora continua de procesos, realimentado la organización que desarrolla con el análisis permanente de los resultados, buenos o mejorables, de cada tarea. Quedó la pregunta planteada de si, como muchas veces se cree, lo que se necesita es contar con las personas particularmente inteligentes, al punto de hacer ésto el centro casi exclusivo de la atención, dado que hay una cierta consciencia de que los resultados que se obtienen desde una persona u otra son muy variables. La respuesta que dábamos es que no es así y que la garantía final de buenos resultados estaba en métodos y procesos. Es el punto donde continuamos hoy.

Aclaremos de entrada que no queremos decir que cuando hay métodos y procedimientos los resultados sean siempre buenos o que las personas no se equivocarán. Los errores y los problemas son siempre inevitables. Lo que afirmamos es que cuando se hace el trabajo bien, dentro de procedimientos maduros, métodos definidos y mejora continua de procedimientos a partir del análisis permanente de lo que puede ser mejorado, los resultados satisfactorios tienden a ser la norma y, si los métodos y procedimientos se mejoran constantemente, los buenos resultados será cada vez más repetibles, gestionados y el desarrollo será así optimizado.

A veces se cree que las personas brillantes es lo que hay que buscar en los equipos. Esta creencia es un error que tiene sus fundamentos. Es cierto que una persona genial puede hacer veinte veces más que una promedio (No hay error ni exageración en la afirmación. Una persona bien competente puede hacer el doble o el triple de una promedio. Pero una muy competente puede producir diez o veinte veces más). Pero hay dos elementos que hay que tomar en cuenta. Uno que las virtudes de un equipo son siempre mayores a las de las personas, por lo que es mejor contar con gente que sabe trabajar con otros en equipos de alto desempeño, que descansar sobre resultados impredecibles productos de las mentes geniales.

Por otro lado, la manera de prevenir los problemas ligados a los errores humanos no es trabajando con personas que no se equivocan, sino con procedimientos a pruebas de errores que hacen evidentes las fallas y disparan las actividades que generan correctivos.

Los métodos y los procedimientos realizados por equipos integrados y bien coordinados son los que conducen las buenas experiencias. A su vez, las experiencias (buenas y malas) deben usarse para refinar los métodos. Es decir, si hay algo que falló, los constructores deben preguntarse cómo pueden evitar esa falla en el futuro. De qué manera pueden mejorarse los métodos de trabajo y los procedimientos para que los problemas analizados no se presenten o, al menos, los resultados indeseados se detecten con poco esfuerzo en forma temprana.

Cuando nos damos el tiempo para hacer este tipo de reflexión, y analizamos, concluimos y producimos mejoras a los métodos y procesos como una práctica recurrente, los buenos resultados se repiten sistemáticamente.

viernes, 22 de noviembre de 2013

Los métodos para construir

La construccíón de muros de piedra y de soluciones de tecnologías
de la información se realiza mejor y produce buenos resultados
si se trabaja con métodos y se siguen procedimientos
que son analizados y revisados
(Fotografía tomada de http://www.themarthablog.com)
Para construir buenas soluciones de gestión de información es importante, crucial en nuestra opinión, tener un método. Probablemente un conjunto de métodos enmarcados dentro de una metodología consistente. Esto es tan importante que decirlo debería resultar una trivialidad. Sin embargo, en la práctica, son muchos los casos en que el uso de metodologías no es lo que priva. La presión que ejerce la necesidad urgente de resultados, descontextualizada de qué es lo que asegura los buenos logros y evita el retrabajo, el deslumbramiento que producen ciertas herramientas, el desconocimiento de las prácticas elementales de gestión de la calidad de algunos desarrolladores y organizaciones, la ausencia de cultura de procesos, son algunos de los elementos que inciden en que se no sean pocos los casos en que se trabaje sin métodos ni metodologías.

La verdad es que los hechos están allí y las buenas prácticas internacionales muestran que si se desea garantizar buenos resultados, productos del trabajo satisfactorios y conforme a especificaciones y un cumplimiento razonable de los calendarios, es importante trabajar con métodos y diseñar, mejorar y seguir procesos.

Toda buena solución desarrollada con herramientas de tecnologías de la información es siempre el producto de una serie de interacciones e iteraciones. Interacciones entre todas las personas involucradas que hacen sus aportes respectivos en cada una de las fases de proyecto e iteraciones dentro del equipo de desarrollo refinando por aproximaciones sucesivas un resultado que por definición nunca está acabado, dado que siempre es perfectible y se tiene conciencia de que puede mejorarse, en su presentación, en su facilidad de uso, en su funcionalidad, en su flexibilidad, en su adaptación al usuario, etc. Todo esto dando por descontando el cumplimiento de los requisitos que fueron planteados en las fases tempranas del proyecto.

Si las cosas son así, tiene que haber un criterio para decidir cuando la construcción está lista para ser entregada y que debe pasarse a la etapa de transición con el objeto de que, finalizada ésta, la solución construida pueda entrar en producción. Este criterio es la validación final, donde los constructores, sus contrapartes y los usuarios certifican que la solución construida está lista para transferirse al ambiente de preproducción.

Pero ocurre en el camino, que mientras se construye, e incluso durante la transición, las iteraciones continúan. Es por ello que el uso de métodos y procesos es fundamental. Métodos y procesos es la única garantía de mejoras continuas en el refinamiento sucesivo que mencionamos. Si no hay métodos, en cualquier momento, en cualquier iteración, alguno de los desarrolladores hará algo mal con consecuencias negativas ya que puede que los malos resultados no sean detectados hasta muy tarde en el tiempo y en los cronogramas.

Es por ello que los métodos y los procesos hacen diferencias, especialmente cuando la organización que los usa los revisa y mejora constantemente. Muchos constructores, inadecuadamente, se confían y se dejan llevar por la apreciación de que se tiene en un instante un buen resultado. Lamentablemente estos buenos resultados son seguidos estadísticamente, en las próximas iteraciones, por los malos, ya que la concentración en los productos y no en los métodos y procesos hace que los problemas, inconsistencias y errores, inevitables en el tiempo, no sean detectados y corregidos.

Tener personas competentes ayuda a la producción de buenos resultados, pero no sustituye la necesidad de colocar el acento en los métodos y la mejora continua basada en procedimientos y procesos como lo expondremos con más detalles en una próxima oportunidad.

viernes, 15 de noviembre de 2013

Pruebas de comunidades y seguridad

La importancia de probar la seguridad salta a la vista,
pero hay algunos detalles que conocen los
 Arquitectos de información de experiencia que vale la pena revisar
Coherentes con el discurso general que hemos mantenido de que una aplicación con una buena Arquitectura de Información tiene cinco dimensiones: Estructura, Funcionalidad, Navegación, Seguridad y Estética y que todo lo que se construye en la fase de desarrollo debe probarse, y habiendo hablado ya de las pruebas de las tres primeras y de la última, dedicaremos el día de hoy a hablar del importante e insoslayable tema de las pruebas de seguridad. La importancia salta a la vista, pero hay algunos detalles que conocen los Arquitectos de información de experiencia que vale la pena examinar.

Las pruebas de seguridad deben permitirnos corroborar que la solución que se construyó cumple a cabalidad las especificaciones que la fase de diseño legó a la fase de desarrollo en cuanto a los perfiles de las comunidades de usuarios que usará la solución automatizada en la que trabajamos. Cuando esto es así es posible confiar en los resultados y operar con la aplicación construida en forma segura y consistente.

Cuando el proceso de desarrollo es guiado con una Arquitectura de Información definida y bien establecida, (ver Las cinco dimensiones de la Arquitectura...) y se usan herramientas apropiadas, la funcionalidad debe poder desarrollarse con independencia de las comunidades de usuarios y la seguridad. El énfasis cuando se trabaja con la funcionalidad es que todos los casos de uso definidos se comporten según lo especificado en el diseño, por eso, salvo las pruebas que involucran la funcionalidad que está dirigida al público anónimo no identificado, es válido, en las primeras etapas de la fase de construcción, hacer las pruebas funcionales sin reparar en los permisos. Esto equivale a hacer verificaciones de resultados operando el sistema con la figura de un administrador o súper usuario al que le es permitido hacer todo tipo de cambios.

Lo que se establece durante el proceso de construcción de la seguridad es precisamente qué es lo que cada comunidad de usuarios puede hacer con cada objeto de información y esto debe poder definirse y redefinirse para cada comunidad sin afectar adicionalmente las otras dimensiones del desarrollo y las otras comunidades. Simplemente se recorre cada perfil de usuario y se establece qué puede hacer y qué no puede hacer y, de nuevo, si las herramientas de desarrollo usan criterios de Arquitectura de Información, los resultados deben cumplir las especificaciones diseñadas.

Las pruebas de seguridad deben alinearse también con los casos de uso (ver Conceptualización de la solución y casos de uso). Para cada comunidad hay que probar que puede hacer lo que está definido que puede hacer en cada caso de uso que es válido para ella. También hay que probar que no puede hacer lo que está definido que no puede hacer. Son dos tipos de pruebas que son complementarias porque se no sustituyen entre sí.

Es muy importante cuando se vayan a hacer las pruebas de comunidades y seguridad llevar un registro de cada prueba y cada resultado y dejarlo grabado como línea base debido a que es imprescindible en un desarrollo confiable que estas pruebas con cada comunidad se automaticen ya que, en ningún momento, debería haber dudas acerca de la confiabilidad con que se trabaja al usar una aplicación. Resulta imprescindible por tanto poder ejecutar  las pruebas de seguridad cada vez que se cambie cualquier variable involucrada en el sistema, así se trate de un elemento aparentemente intrascendente. Esto debe convertirse en un hábito.

Un error de algunos desarrolladores nóveles es suponer que como se probó para dos comunidades y todo trabajó bien se puede extrapolar el buen esultado y suponer que todo seguirá trabajando bien con las restantes que son del mismo tipo. Esto no es necesariamente cierto y lo razonable es probar con cada comunidad de usuarios y automatizar las pruebas para que el hacerlas con todas no sea limitado por el tiempo y el trabajo que tales pruebas involucran.

viernes, 8 de noviembre de 2013

Probar la estética

La funcionalidad y la estética se interrelacionan, pero deben poder
desarrollarse y probarse en forma paralela.
(la imagen que muestra aspectos de estética y funcionalidad en un
vehículo eléctrico esta tomada de checkeredflag.com)
La semana pasada comentábamos que la frase de que todo lo que se construye cuando se realiza una solución de gestión de información debe probarse incluye no sólo lo meramente funcional y los aspectos más informáticos como la estructura de información y la seguridad, sino también características que tradicionalmente no se consideraban objetos de pruebas sistemáticas como la navegación y la estética. Dedicamos en esa oportunidad nuestro post a las pruebas de la navegación, por lo que hoy nos centraremos en la conversación sobre las pruebas de la estética.

Sobre el papel de la imagen y la estética ya hemos hablado en otras oportunidades (Ver por ejemplo: ¿Por qué considerar la estética?, Imagen y estética: la quinta dimensión en Arquitectura de Información, El diseño de la imagen y la estética y La imagen y la Estética deben ser paralelas).

Es para todos claro que la estética trasmite y representa la imagen institucional, pero su rol va más allá de la institucionalidad ya que según como se implemente puede hacer más usable o menos usable una aplicación. Por ejemplo, un encabezado institucional grande en la pantalla puede hacer la salida muy elegante y bonita, pero quizás quita demasiado espacio útil y obliga al usuario a desplazarse abajo y arriba para ver contenidos, enlaces o botones, dificultando con ello el uso. Todo esto aunque la funcionalidad esté correcta.

Al igual que ocurre con aspectos como la navegación, es importante que las personas que construyen la estética puedan moverse y hacer cambios con independencia de quienes implementan la funcionalidad. Esto hace el desarrollo de una solución de gestión de información más eficiente y versátil. También tiene impacto en el mantenimiento y las modificaciones que se pueden hacer más adelante para acoplar, por ejemplo, una aplicación a un cambio de imagen institucional o a una campaña circunstancial. Es muy diferente en esos casos el poder tener o no la confianza de que la tarea puede realizarse y probarse sin el concurso de los constructores de la funcionalidad, pero estando seguros de que lo que se hizo no trae implicaciones indeseadas.

Hay, por supuesto, una prueba final que debe hacerse presentado la estética a quienes deben aprobar la imagen institucional. Pero mientras se construye la aplicación hay elementos ligados a la estética que deben tomarse en cuenta: la separación de contenidos y estilos, por ejemplo.

La fase de construcción exige el respeto a la disciplina en los nombres que se dan a cada cosa. Los Arquitectos de información saben que durante la fase de diseño deben definir los campos, los objetos de información, sus códigos y sus nombres. También el uso de bases de datos requiere de una normalización de los nombres de tablas y campos. Así, los encargados profesionalmente de la estética deben saber que estilos de presentación de la información (en la práctica presente especificados en lenguaje CSS) deben ser normalizados para facilitar el trabajo de desarrollo de hoy, así como el de los cambios que vendrán mañana.

Poder atender sugerencias de cambios sin tener que temer a implicaciones que impactan la funcionalidad es una capacidad de las aplicaciones con una buena Arquitectura de información que, entre otras cosas, requiere que se tenga siempre a la mano la posibilidad de validar el funcionamiento correcto de todos los servicios después de un cambio de imagen y estética y no trabajar sólo con la presunción de inocencia de estos cambios.

viernes, 1 de noviembre de 2013

Probar la navegación

La prueba final de la navegación debe hacerse con usuarios reales,
emulando procesos reales y usando datos reales
 (imagen tomada de http://es.kioskea.net)
En las explicaciones de la fase de desarrollo dentro del ciclo de vida de una solución de gestión de información, llegamos a la actividad de pruebas diciendo que todo lo que se construye debe probarse. Dimos algunas pautas sobre cómo probar la estructura de información y la funcionalidad. Hoy queremos comenzar a referirnos a dimensiones diferentes, que no suelen ser muy consideradas por muchos constructores al hablar de pruebas, pero que siendo consistentes con nuestro discurso de que todo debe probarse, hay que tomarlas en cuenta también. Es el caso de la navegación y a la estética. Dedicaremos el post de hoy a las pruebas de la navegación y dejaremos para uno siguiente las pruebas de la estética.

En un sistema bien desarrollado desde el punto de vista de Arquitectura de Información la navegación y la estética agrupan características que deben poder ser desarrolladas como dimensiones, es decir, en forma independiente de la funcionalidad. ¿Qué significa esto y por qué es importante?

Significa que con toda la estructura de información desarrollada y con toda la funcionalidad implementada debe ser posible realizar cambios en la navegación o la estética de un sistema sin afectar el funcionamiento correcto de la aplicación. Los cambios en la navegación y estética deben poder ser realizados por personas diferentes a las que definen la estructura de información y la funcionalidad y el funcionamiento correcto debe poder validarse realizando pruebas automáticas, como lo mencionamos en días pasados (Ver Pruebas durante la construcción de una solución). Esto es importante para asegurar la calidad y el mantenimiento futuro de la solución.

La navegación es una capacidad que nos facilita (¡o nos dificulta!) usar un sistema. Nos permite que pasemos de una actividad a la siguiente, de una pantalla de resultados a la otra que sigue como parte del proceso. La navegación se expresa a través de distintos tipos de menús y opciones que son colocados en los diferentes lugares de la pantalla. Hemos hablado de ella en otras oportunidades (ver por ejemplo: Mucho que aprender sobre navegaciónLas Áreas básicas de la salida, Los cinco menús modernos, En la Derecha, el menú de opciones complementarias).

Durante el proceso de construcción podemos darnos cuenta que algunos caminos de navegación resultan más sencillos si colocamos (o, a veces, si quitamos) opciones y enlaces. El trabajo de apreciar lo que facilita o entorpece la navegación normalmente lo hace mejor un Arquitecto de Información que un programador o un constructor sin experiencia en los problemas de navegación. De allí que el manejar la navegación con independencia de la funcionalidad facilita el trabajo tanto de unos como de otros. Permite el avance paralelo de la solución y facilita la realización de los cambios que se hacen durante la fase construcción para atender las sugerencias de los distintos involucrados en el proyecto.

Al final del camino la prueba crítica que debe pasar la navegación construida debe ser el presentarle el sistema a usuarios reales y solicitarles que usen la aplicación para hacer actividades que emulen los procesos reales usando datos reales (Ver Los datos para probar). Al hacer esto se debe observar cómo trabajan, escuchar sus observaciones y atender sus preguntas. Eso permitirá entender los esquemas naturales de navegación para esos usuarios. Una vez mas, la actividad de pruebas así realizada con los usuarios debe grabarse para incorporarla a las pruebas automatizadas.