02 November 2009

Niveles de actuación; el ser y el hacer, la persona y el proceso...

Comento dos frases que para mí son trascendentes y que tienen mucho impacto en mi forma de abordar muchas situaciones en el día a día.

La primera la escuché de un instructor del SEI en un curso de CMMi: "no fallan las personas, fallan los procesos".
La segunda de un amigo de quien tuve la oportunidad de acercarme, sólo un poco, al couching ontológico; la distinción entre el ser y el hacer.

Estas dos sencillas experiencias son en realidad herramientas poderosas de cara a lograr resultados personales, profesionales y organizacionales. Si bien desde el punto de vista personal el tema es particularmente profundo, me limito aquí al ámbito profesional y organizacional.

CMMi plantea un modelo de madurez organizacional y como todo modelo de madurez basado en procesos persigue la consecución de los resultados de forma independiente a las personas, a través de la definición de prácticas bien documentadas, formación y controles de calidad. En un escenario como éste; no fallan las personas, fallan los procesos!.

La segunda es una distinción básica entre dos cosas muy diferentes y que normalmente encontramos colapsadas en cada frase impune, en cada juicio emitido, cada vez que el orgullo no nos deja mejorar. El ser nos representa como individuos, lo que somos, nuestra historia, nuestro potencial, nuestros valores. El hacer habla de acciones específicas, que ocurren en un momento del tiempo.

Para ilustrar la idea que quiero transmitir, peco tal vez de mezclar un poco peras y manzanas y defino tres niveles de actuación; ser, hacer y diseñar.

Generar un resultado satisfactorio depende de haber ejecutado correctamente la acción correcta. Siendo así y dado que estamos hablando en un nivel organizacional, no sólo debemos saber ejecutar correctamente la acción prevista sino que esa acción previamente diseñada y definida también debe ser correcta. Muchos ejemplos existen de resultados no exitosos cuando se ejecutó la acción prevista, pero que no necesariamente era la indicada en esa situación. Esta realidad abre un espacio para la crítica de las prácticas y los procesos, sin que sea mezclada con la actuación de una persona que ejecutó una acción prevista y que no dio el resultado esperado. Cuestionar una práctica es posible sin que quienes la ejecutan se sientan atacados, ni quienes la cuestionan los ataquen. Esta posibilidad es la diferencia entre hacer y diseñar, dos estados de actuación posibles y necesarios que se complementan.

Todo lo anterior para el lector puede ser tan obvio como revelador, dependiendo de su experiencia. Para mí es necesario transmitir el mensaje al ver frecuentemente que profesionales se sienten atacados cuando las prácticas que ejecutan por diseño son sometidas a revisión. Son procesos que deberían promover ellos mismos y participar abiertamente para mejorar sus resultados. Una cosa es la persona, otra cosa es el proceso, es responsabilidad de cada persona comprometerse con la mejora continua de los procesos que ejecuta.

La segunda distinción se mueve más en un ámbito personal, pero que manejada correctamente facilita y mejora de forma inmediata las comunicaciones y relaciones en un plano profesional y organizacional. Cada persona debe ser valorada en su ser, como individuo, y esto no debe mezclarse con sus actuaciones en un ámbito profesional. La mayoría de las desventuras de un tradicional empleado son producto de cuestionamientos a su ser por parte de un tradicional jefe cuando los resultados en un ambiente laboral no son los esperados. Un profesional puede ser tachado de incompetente, de flojo o de irresponsable por no lograr un resultado esperado, todos estos juicios que afectan a la persona en su ser, son equivocados al no estar dirigidos a las acciones específicas que no fueron acertadas, generando un efecto contraproducente en el rendimiento y deteriorando a puntos irrecuperables las relaciones humanas. Los juicios al ser de una persona, en realidad hablan de la incompetencia de quien los emite para manejar niveles básicos de respeto y comunicación.

En un ambiente emocionalmente sano y maduro las personas comunican sus opiniones o emiten juicios en función de acciones específicas, sin afectar el ser de nadie. Abriendo el espacio para la aceptación de la crítica y el compromiso a la mejora, haciéndose cargo desde el mismo mensaje en que la persona que lo recibe es valiosa en su ser y que eso no está siendo cuesitonado.

En DBAccess estas distinciones o prácticas están planteadas en el ambiente, y su aplicación nos deja la experiencia de la alta complejidad que tiene su transmisión e implantación en un contexto de constante crecimiento. Esto es posible sólo a través de un liderazgo integral consistente en toda la organización.

El mensaje es en realidad una invitación a incorporar estas distinciones en el día a día, a través de evitar hablar impunemente colapsando los diferentes niveles de actuación.

23 May 2009

El Proyecto y el Producto

Veo una constante confusión en los equipos de desarrollos de software y en general en las disciplinas de TI entre el proyecto y el producto. No tener estas distinciones claras y no saber separar estos dos contextos tiene un impacto directo en la mantenibilidad, en costos, al verse reflejada en la documentación de los sistemas y de las organizaciones.

Una analogía que me ha ayudado a explicar este fenómeno, como casi siempre tomada de la ingeniería civil. Imaginen que van a una ciudad y para ubicarse piden el mapa de vías. La expectativa esta clara para todos, puede ir de un plan en papel a un GPS, con mayor o menor información asociada es en el fondo lo mismo, una imagen de todas las calles, vías y avenidas en una determinada región. Imaginen por un momento que en vez de recibir esto les dan la documentación de todos los proyectos de ingeniería civil realizados sobre la vialidad de la ciudad durante los últimos 40 años; el proyecto de construcción de un puente, el de asfaltado de una calle, el de ensanchado de una autopista, etc., con la expectativa que ustedes sean capaces de deducir de ahí el mapa vial de la ciudad. Ante estas realidades es que hay que recordar que no debemos desesperar, la ingeniería civil nos tiene 2.000 años de ventaja.

Tengo la certeza que la mayoría de las organizaciones no son capaces de dar su mapa de vías en el contexto tecnológico. También que nuestras disciplinas (desarrollo de software, arquitectura empresarial, etc.) seguirán su progreso acelerado en los próximos años y alcanzarán y superarán estos niveles obvios.

Siguiendo con el proyecto y el producto, lo abordo en tres escenarios diferentes y tres ejemplos.

El Proyecto y el Sistema

Un sistema de información inicia su ciclo de vida una vez que entra en producción y termina una vez que es descontinuado (o desenchufado) unos años después. Durante este periodo típicamente pasa por múltiples proyectos que lo completan, adaptan, evolucionan y sobre todo reparan. Al arrancar cualquiera de los proyectos sobre el sistema, el caso típico es que el equipo mantenedor se encuentra con la situación de la analogía inicial, para entender su funcionalidad y su arquitectura el equipo debe reconstruir la historia de los proyectos anteriores cuando en realidad esto no agrega ningún valor para ejecutar la tarea del momento. Si agrega valor es precisamente porque la documentación funcional y de arquitectura del sistema no es suficientemente completa.

Una aplicación o componente de software en general debe contar tanto de documentación funcional como de arquitectura que permita comprender qué hace,
para qué lo hace, cómo lo hace y por qué se decidió que lo hiciera de esa forma. Contando con esta información el equipo se enfrenta a un problema con baja incertidumbre y puede tomar acciones;

  • Disminuyendo drásticamente el riesgo de afectar el funcionamiento.
  • Disminuyendo drásticamente el tiempo de análisis requerido para iniciar el mantenimiento y por ende el costo del proyecto.
  • Disminuyendo el riesgo de incluir elementos que no cumplen los lineamientos de diseño del sistema.
Adicionalmente se aumenta la posibilidad de reutilizar diseños y componentes, en este sistema y otros, al permitir entender rápidamente los elementos que conforman el sistema.

En resumen el mensaje que quiero transmitir es que lo importante no es el proyecto, es el producto resultante. Poco valor tendrá el proyecto que terminó en menor tiempo pero que dejó la realidad que disparará los costos del próximo proyecto sobre el mismo producto. El valor de la información del proyecto es temporal o circunstancial, mientras
que el producto es un activo de la organización y su valor dependerá entre otras cosas de la calidad de la información que le acompañe.

Estos son algunos casos específicos donde he visto mezclados el proyecto y el producto.
  • Como parte de un proyecto se hace un documento de visión (utilizando como metodología PU) que define nuevas características a incorporar a una plataforma existente, pero no se actualiza el documento funcional original (como el de casos de uso). Lo mismo podría ocurrir en metodologías ágiles si haces por ejemplo nuevos user stories y no los agregas al repositorio de los existentes.
  • Cualquier cambio de índole tecnológico que no actualiza el documento de arquitectura, luego por ejemplo tomarían días en averiguar qué frameworks se utilizan, en qué versiones y con qué fines.
A partir de estos momentos comienza la historia de tener que reconstruir proyectos para entender el sistema.

El Proyecto y los Sistemas

Lo mismo que ocurre con con un proyecto que afecta un sistema, ocurre con un proyecto que afecta o produce varios sistemas. Se generan documentos en el contexto del proyecto que hablan de múltiples sistemas, haciendo la información aún más densa y compleja de entender.

Se debe asegurar en estos proyectos dejar la información actualizada de cada sistema.

El Proyecto y la Organización

Una situación similar a la que describo en el contexto de sistemas, se me presentó recientemente con procesos de negocio de una organización.

En proyectos orientados a atender necesidades de negocio, es muy posible que se vean afectados los procesos de la organización. Toda organización debe tener sus procesos documentados y difundidos. Cualquier cambio sobre estos implica acciones de difusión, entrenamiento, cambios en sistemas, etc. Pueden y existen grupos de consultores que no ven los procesos más allá del proyecto y donde los cambios a estos quedan sólo en los documentos del proyecto, creando un riesgo importante de operación en la organización. Esto puede ocurrir
en organizaciones pequeñas o inmaduras donde el uso de procesos no está institucionalizado.


Estas situaciones suelen ocurrir por ingenuidad sobre la realidad de la vida de un sistema al pensar sólo en el proyecto actual y no en los futuros, por falta de experiencia y/o por comodidad. En cualquier caso se disminuye el valor del activo y se dispara el costo de futuros mantenimientos.

30 July 2007

DBAccess en Ciberespacio Radio


Entrevista con Edgar Rincón. En su estilo incisivo hizo una entrevista bien amena y fresca.

24 July 2007

Tips para construcción de diagramas de clases útiles y legibles

Escribo en este post uno de los temas más recurrentes y de más utilidad en clases, revisiones de pares, recomendaciones de diseño, revisiones de documentos de arquitectura y en general en cualquier momento donde aparezca un diagrama de clases.

Hago una recopilación de los tips y observaciones que surgen continuamente y que teniéndolos en cuenta se mejora significativamente la calidad y utilidad de los diagramas.

El error más común: Relaciones conceptuales

En muchos casos un modelo conceptual, que representa el espacio del problema, se utiliza como base para la identificación de clases. Las relaciones que se presentan en un modelo conceptual suelen ser acciones o interacciones de elementos en el mundo real. Por ejemplo en el modelo conceptual de un sistema de inscripciones de un ente educativo, seguramente consiguiremos una relación inscribe entre los conceptos de Estudiante y Materia.

Figura 1: Modelo Conceptual
En el modelamiento de un diagrama conceptual ésto es perfectamente válido. Ahora cuando se habla de relaciones entre clases, una relación inscribe entre las clases Estudiante y Materia tiene un significado bien específico y está relacionado directamente con la implementación.

Figura 2: Diagrama de Clases
La relación de la figura 2 establece que en la clase Materia existe un método llamado inscribe y que este método es invocado en algún momento por la clase Estudiante. Hay que estar claros con lo que se está expresando y hacerlo concientemente.

Si por ejemplo asumimos que un componente, capa de software o servicio es responsable de un contrato de registro de la inscripción de una materia y ofrece una operación o método con firma:
void inscribirMateria(Estudiante estudiante, Materia nuevaMateria)
throws InscripciónDuplicadaException

Este servicio en su implementación podría hacer una serie de validaciones y luego acceder a un repositorio y almacenar la formalización de la inscripción de la materia.
En este caso la clase Estudiante nunca invocaría un método inscribir de la clase Materia e inclusoeste método podría no existir, aunque sea cierta la relación conceptual entre ambas clases. En un diagrama de clases, de acuerdo a la implementación planteada, sería un error colocarla en un diagrama de clases.

Tipos de relaciones:
estáticas vs. dinámicas

Las relaciones entre dos clases pueden ser clasificadas en dos tipos, estáticas y dinámicas.

Las relaciones estáticas son aquellas que definen estructuralmente a la clase, básicamente en los lenguaes OO utilizados actualmente se definen tres tipos; extensión o herencia, agregación y composición. No es el objeto de este artículo explicar estas relaciones, hay múltiples fuentes disponibles.

Las relaciones dinámicas son las que definen la interacción de la clase con otras, invocaciones que desde la clase se hace a métodos de otra clase. Un ejemplo de relación dinámica se define en la Figura 2.

El tip que se presenta a continuación se basa en esta definición teórica para hacer una recomendación concreta en la construcción de diagramas.

No llene el diagrama de clases con relaciones dinámicas descontextualizadas

Las relaciones dinámicas se dan en el contexto de la ejecución de una operación, servicio o contrato específico. Una clase que participa en la realización de múltiples operaciones, probablemente contará con múltiples invocaciones a otras clases, subconjuntos de todas estas relaciones (invocaciones) participan en la relización de una cada operación específica.

Si en un diagrama de clases, adicionalmente a las relaciones estáticas, colocamos todas las relaciones dinámicas que se dan entre las clases del diagrama (es decir, todas las relaciones por cada vez que una clase llama a un método de otra clase) entonces terminaremos con un diagrama sobrecargado, de aquellos que solemos llamar spaghetti diagram.
Figura 4: Espagueti inentendible... encontré un buen ejemplo buscando imágenes en la red.

Cuando se presenta un diagrama de clases, lo más recomendable es presentar la estructura utilizando sólo las relaciones estáticas. Las relaciones dinámicas recomiendo presentarlas en su debido contexto, por ejemplo utilizando un diagrama de secuencias o colaboración para cada operación o servicio. De esta forma se apreciará claramente la interacción entre las diferentes clases e incluso objetos, para lograr la realización de una operación.

Seguir esta recomendación mejora significativamente la utilidad de la documentación para el equipo que hará mantenimiento del sistema en construcción, disminuyendo así los costos de soporte y mantenimiento a futuro.

22 July 2007

Re Re Re Re Re Reconversión Monetaria

La metodología para afrontar el impacto de la reconversión monetaria en las plataformas tecnológicas que definimos en la Unidad de Arquitectura e Innovación de DBAccess, ha sido mercadeada efectiva y masivamente por el equipo de la Unidad de Mercadeo. Numerosas notas de prensa, presentaciones y entrevistas has sido muestra de la acogida que ha recibido en el mercado. Yo por mi lado, de vocero del tema, repito una y otra vez como el conejito de las pilas...

Recopilación de enlaces y entrevistas.

Entrevista televisada para Alta Densidad - Globovisión.
La entrevista fue en un formato de preguntas y respuestas que después serán editadas. El fondo verde al mejor estilo de Matrix fue una nota divertida. Espero a que salga el programa en TV para ver qué fondo le colocan.
http://red-dbaccess.blogspot.com/2007/07/dbaccess-en-alta-densidad.html

DBAccess habla sobre los efectos de la reconversión monetaria sobre las plataformas TI en foro de CAVEDATOS 7/11/2007:


Nuestra estrategia para la reconversión monetaria en ComputerWorld (Junio 2007): http://red-dbaccess.blogspot.com/2007/07/nuestra-estrategia-para-la-reconversin.html
Leer nota completa en ComputerWorld Venezuela (.pdf)

La conversión al bolívar fuerte tiene fuerte impacto en los sistemas informáticos:
http://enbytes.com/noticias/reconversionI.htm

Igual al anterior pero publicado por Conapri:
http://www.conapri.org/ArticleDetailIV.asp?CategoryId=14563&ArticleId=282506

CANTV.Net: DBAccess habla sobre los efectos de la reconversión monetaria:
http://www.cantv.net/ciencia/resena.asp?id=141181&cat=2&Fresena=TRUE

DBAccess en Alta Densidad - Radio. Entrevista por Carlos Monzón a ser transmitida en el Circuito X.






http://red-dbaccess.blogspot.com/2007/05/dbaccess-en-alta-densidad.html
Escuche la entrevista: