Gerencia - La verdad en la cara

La verdad en la cara

Son muchos los comentarios que realizan las personas en los pasillos, pero pocos los que llegan al oído de los sacrificados. Que sea esta una oportunidad para decirles la verdad en la cara.

Me dí a la tarea de conversar con un grupo de amigos y conocer su percepción acerca de sus lideres, directores, jefes o como quieran llamarlo. He aquí el resumen (Obviamente censurado).

• ... Parece una prostituta, le dice que sí a todo lo que le solicitan y obviamente llega al final del día y me clava.
• Me reclama por llegar 15 minutos tarde, pero eso si, no vacila en solicitar que me quede tiempo adicional para solucionar algún problema.
• Cualquier estimación que realizo le parece una exageración, pero como no le ha tocado sufrir como a mi, no tiene ni idea del trabajo que se requiere.
• Les tengo una noticia buena y una mala. Dice el hijo de tuta. La buena es que esta noche comen arroz chino, la mala es que se lo comen aquí en la oficina. ¡Este es mucho...!
• El desgraciado me pide que trabaje de mas para cumplir con el compromiso y mientras tanto realiza seguimiento a mi trabajo desde el gimnasio.
• No tiene imaginación, lo único que se le ocurre para solucionar los problemas del proyecto es: Trabaje hasta tarde y si se puede los fines de semana.
• Nooo!!!!!!, yo que le voy a contar este problema tan verraco, lo único que logro con eso es estresarlo y que me la monte. Solo me demoraría mas solucionando el problema con ese intenso acosando.
• Cuando no alcanzamos a entregar a tiempo lo único que se le ocurre es decir: ¿Como vamos? por el chat. ¡Que estrés!
• Todo el día se la pasa gerenciando un cronograma, y el cree que eso le va a garantizar éxito en la entrega. ¡Pobre iluso!
• Cuando hay problemas me la monta todo el día, pero cuando hago algo bien se queda callado el infeliz.
• Tienes esta cantidad de errores, siempre te pasa lo mismo ¿Que es lo que pasa?. Pues pasa que me encanta trasnochar solucionando problemas para que usted quede como un príncipe presentando el producto ante el usuario final.
• Muchachos ¿podríamos corregir los errores que tenemos reportados en tiempo extra?. ¿Pero como así? esa funcionalidad la desarollamos en tiempo extra. ¿Trabajamos entonces tiempo extra al extra?. ¿Este cree que no descansamos, por que no, nos inyecta la comida en las venas y seguimos derecho?.
• Entregó el proyecto a tiempo, pero no se dio cuenta el charco de sangre que dejó en el intento. ¡Así son esos negreros!
• ¿Pero como así?, ¿usted es que nunca entiende lo que le digo?. Pues yo si le entiendo, lo que pasa es que usted es un incompetente que no se hace entender.
• Plata, plata, plata, tiempo, tiempo, tiempo. Y las personas ¡que se vayan pal carajo!. Al fin y al cabo hay mucho desempleado dispuesto a reemplazarlos.
• El proyecto va al 80%, ¡que bien!. Las personas tienen un nivel de estrés de 90%. ¡Que bien el proyecto va como debe ir!. !Si, como no!.
• Es tan descarado que le pido un permiso y me pregunta ¿Cuando me vas a pagar el tiempo?, como si no se lo hubiera pagado ya con todas las noches que he trabajado por cuenta de los problemas que el no fue capaz de gestionar adecuadamente.
• ¡Que pereza trabajar con ese sujeto!. Cree que para ser el lider debe ser quien mas sabe en el equipo, y cuestiona todo, así no tenga idea de lo que habla.
• Parece un viejo chocho, si las cosas no se hacen como él diga, no sirven. Mejor me limito a trabajar 8.5 Horas/Nalga porque igual no podré generar valor agregado.
• Este cree que ordenando va a lograr que el equipo luche por conseguir las metas. ¡Máximo logrará que terminemos las tareas asignadas!.
  

Y estas son solo unas cuantas de las cosas que hablamos nosotros a sus espaldas señores lideres, pero todo esto es...

...Porque los queremos mucho...

...Queremos mucho que les toque hacer nuestro trabajo a ver si les gusta comer de ese delicioso manjar que nos obligan a saborear a diario.

Espero que lo tomen de la mejor manera y quienes se sientan identificados busquen mejorar cada día un poco mas para llegar finalmente al punto en el que deberían estar. Lideres serviles. Al servicio de sus colaboradores. Buscando una meta de equipo y trabajando por ello.

Blog relacionado. El camino hacia el líder servil

Arquitectura - La vista de integración

La vista de integración

A partir de los datos recolectados en la vista de información (Ver Vista de información), se debe iniciar un trabajo fuerte  definiendo las estrategias de integración para todas las fuentes que hayamos identificado. 

Para interfaces pequeñas de baja complejidad la definición de los contratos y estrategias de integración son bastante simples, pero conforme aumenta el alcance, aumenta también la información que se requiere y por ende se hace más complejo unificar los componentes y de esta manera aumentan los riesgos de que las cosas salgan mal. 

¿Qué puede salir mal?

• Aquellas cosas que afectan la estabilidad del proyecto: En esta categoría podríamos encontrar problemas relacionados con integraciones mal realizadas que extienden los tiempos de desarrollo y por ende afectan las fechas pactadas de los entregables.

• Aquellas cosas que afectan la estabilidad del producto: Aquí podríamos encontrar deficiencias que impacten directamente la percepción del usuario final (Problemas de desempeño, Problemas de disponibilidad, entre otros.)

¿Cómo disminuir entonces la probabilidad de que estos problemas se presenten?

Para mitigar los riesgos relacionados con la estabilidad del proyecto lo mas importante es mantener la comunicación constante con los responsables de aquellos componentes con los que debamos integrarnos (Esto tiene valor principalmente durante la etapa de desarollo). No basta con definir unas interfaces al inicio del proyecto, estas pueden cambiar y lo mas seguro es que lo hagan, por lo tanto la retroalimentación constante mientras se realizan las integraciones es vital.

Es aconsejable también que los acuerdos a los que se llegue con los responsables no se queden en llamadas telefónicas o documentación dispersa (Correos electrónicos) que sea difícil de analizar posteriormente. Si algo puede fallar, falla y si no se tiene clara esta información lo mas probable es que cuando la ejecución del software no sea satisfactoria por causa de una mala integración, quieran hacer responsable a quien se integró aún cuando no sea así, y sin la documentación de los acuerdos es imposible demostrar lo contrario.

    Para mitigar los riesgos relacionados con la estabilidad del producto podriamos hacer lo siguiente: 

• Tenga clara su meta de diseño (Ver Goal driven design). Solo asi podrá aumentar las posibilidades de generar valor a los usuarios finales.  

• Seleccione y evalué las alternativas de integración de cara a su impacto sobre la meta de diseño.  Por ejemplo. Si una opción del sistema es critica a nivel de desempeño, preguntase que necesidades de integración tiene, e identifique una estrategia que satisfaga este atributo de calidad, en este caso podría pensar en comunicación asíncrona.

• Tenga en cuenta los Trade-offs (Aquellos puntos de la meta de diseño que se deben satisfacer pero al impactar uno positivamente se afecta el otro de manera negativa). Por ejemplo. Al utilizar mecanismos de comunicación asíncrona podría aumentar el desempeño pero disminuir la usabilidad al retardar la respuesta del procesamiento al usuario final.

• Evalúe el catalogo de patrones de integración (Les recomiendo el libro Enterprise integration patterns de Martin Fowler). Nunca va a estar de mas revisar como éstos podrian apoyarnos en la tarea de lograr nuestra meta de diseño.

• Tenga en cuenta la cantidad de datos que deberá intercambiar. Esto determinará que tan adecuada sea una estrategia de integración.

• Finalmente documente y comunique las decisiones tomadas en este punto a todo el equipo de trabajo.

Arquitectura - La vista de información

La vista de información

Un componente de software se puede ver como una caja negra a la cual se ingresa información, éste internamente realiza un procesamiento y finalmente genera otra información procesada a partir de la información que le ingresó inicialmente.

El concepto es bastante simple pero a partir de la percepción podríamos afirmar que la complejidad del software aumenta exponencialmente cada vez que aumenta su alcance porque la cantidad de información que se debe contemplar, manejar y procesar es mucho mayor.

A lo anterior se le debe añadir que en la actualidad pocas veces hacemos “Stovepipe systems”, es decir sistemas que son islas y que están en capacidad de generar toda la información que necesitan para realizar su procesamiento. Evidentemente hoy debemos interactuar con toda una organización y esto se convierte en un reto no solo a nivel de gestión sino también a nivel de diseño e implementación del software.

Piensen en el siguiente escenario:

El cliente solicita la implementación de un componente de software, los analistas realizan la revisión de la funcionalidad e incluso tienen en cuenta los atributos de calidad, se hace un diseño conceptual de la necesidad, se estima y tiempo después se aprueba el inicio del proyecto. 

Lo primero que hace el equipo es hacer un plan y definir la arquitectura del sistema con el fin de garantizar que se contemplen las funcionalidades más representativas y los atributos de calidad. Finalmente se pasa a desarrollo.

El desarrollador empieza a implementar el sistema, diseña su base de datos implementa las funcionalidades y entrega al cliente. Cuando se hace la entrega el cliente dice: Nosotros ya teníamos un sistema x, y, z que ofrecía la información a, b, c que ustedes están almacenando en la base de datos, no podemos replicar información. ¡Plop!

Supongamos que en el mejor de los casos se tenga en cuenta la plataforma tecnológica del cliente y el desarrollador antes de hacer cada implementación solicita al cliente los contratos y la ubicación de cada uno de los servicios que requiere para hacer la implementación. Siendo optimistas el cliente gestiona al interior de la organización y entrega las definiciones al desarrollador o solicita la implementación de aquellas que no estén codificadas. Pero ¿qué pasa si esto no es así? ¡Impacto para el proyecto, un desarrollador sin nada que hacer porque depende de definiciones que no han llegado!.

La vista de información busca mitigar los siguientes riesgos:

• Que no tengamos en cuenta la plataforma tecnológica del cliente en la arquitectura y por ende en la implementación.

• Que no tengamos en cuenta la dependencia con otras áreas de negocio y/o otras personas y que por ende se impacte el proyecto por falta de disponibilidad o capacidad de estos.

¿Qué hacemos entonces para que esto no nos pase?

Lo primero que debemos hacer es identificar las necesidades de información al inicio del proyecto:

1. Leer la definición funcional del sistema (Requisitos, Casos de uso, Historias de usuarios, etc.) e identificar aquellos casos en los cuales se requiera cierta información o se deba entregar cierta información. No se pregunte en este punto si la información la debemos almacenar en un repositorio local a la aplicación o si será un sistema externo, lo importante es tener clara cuál es la información que requiere el sistema para poder realizar su procesamiento.
2. Revisar los prototipos de las interfaces graficas de usuario. Allí podrá identificar necesidades de información principalmente en las listas desplegables o en los campos de texto de autocompletar.

Una vez identificadas estas necesidades de información dedíquese a buscar al interior de la organización quien está en capacidad de ofrecerla, busque alternativas, acuda a otros proyectos e identifique si están haciendo algo similar que usted pueda usar y en tal caso realice acuerdos y diseñe un plan que contemple todo esto.  

Si nadie está en capacidad de ofrecerle la información que requiere entonces puede realizar el almacenamiento en un repositorio propio pero en éste punto usted estará tranquilo de que tuvo en cuenta las restricciones técnicas de sistemas legados de la organización y minimizará la probabilidad de impacto por este motivo.

El escenario con una vista de información clara es el siguiente:

El cliente solicita la implementación de un componente de software, los analistas realizan la revisión de la funcionalidad y a partir de ésta se identifican las necesidades de información, se hace un diseño conceptual de la necesidad, se estima, en la estimación se realizan asunciones sobre el origen de la información y se envía la estimación al cliente. Tiempo después el cliente retroalimenta aceptando o negando las asunciones y se aprueba el inicio del proyecto.

Lo primero que hace el equipo es revisar nuevamente las necesidades de información y en éste punto ir a las áreas de negocio involucradas de modo que puedan identificar puntos de integración a partir de los cuales se pueda obtener la información requerida, a partir de esto realizan el diseño de arquitectura del sistema esta vez contemplando las restricciones técnicas. Finalmente se hace un plan y se pasa a desarrollo. En el plan se incluyen dependencias con otros proyectos y/o áreas de negocio pero se tiene en cuenta su capacidad y disponibilidad por lo que la fecha final de entrega se mueve teniendo en cuenta los momentos en los que estos actores pueden entregar la información necesaria. 

El desarrollador empieza a implementar el sistema, diseña su base de datos solo para almacenar aquella información que no ofrezca otro sistema, implementa las funcionalidades y entrega al cliente. ¡Tuvimos problemas pero no tantos como al inicio y entregamos lo que esperaba el cliente!

Ventajas de construir la vista de información.

• La principal ventaja es que apoya la identificación de la plataforma tecnológica que posee el cliente porque en el proceso de identificación del origen de la información se debe buscar el apoyo de los involucrados en TI.

• Se tienen en cuenta las dependencias con otras áreas de negocio y/o proyectos en la elaboración del plan.

Arquitectura - Primer acercamiento a los atributos de calidad del software

Primer acercamiento a los atributos de calidad del software

Aunque son llamados de muchas formas (Calidades sistémicas, requisitos de nivel de servicio, requisitos no funcionales, atributos de calidad, entre otros) no son más que aquellas características que hacen único a un producto de software. Dos productos pueden ser funcionalmente idénticos pero sus atributos de calidad son los que realmente marcan la diferencia porque dependen del entorno, de la organización y de las personas que finalmente se beneficiaran del uso del sistema. En otras palabras los atributos de calidad permiten determinar las condiciones de operación y evolución del software de cara a sus usuarios finales y/o no finales.

Respecto al nombre no vale la pena debatir, personalmente pienso que el nombre más adecuado es el de Atributos de calidad porque no demarca la delgada línea entre lo funcional y lo no funcional que en la mayoría de los casos es difícil de trazar. ¿La seguridad es un requisito no funcional? Probablemente la gran mayoría piensen que si, pero cuando pensamos en todo lo que involucra (Ingresar credenciales de acceso, autenticación, autorización) ¿No es todo esto algo funcional? Los atributos de calidad son difíciles de definir pero fáciles de percibir.

¿Por qué son importantes los atributos de calidad?

 PORQUE NOS AYUDAN A GENERAR VALOR EN LA SOLUCIÓN FINAL QUE OFRECEMOS A LOS USUARIOS.

Los atributos de calidad se podrían dividir en dos grupos:

1. Aquellos percibidos de forma directa por el usuario final y que finalmente impactan al negocio. Tales como: Disponibilidad, Facilidad de uso, Desempeño o Confiabilidad.

•  Si el sistema no está disponible durante un periodo determinado de tiempo los usuarios finales no podrán ejecutar sus tareas, por ende el negocio sufrirá una baja de productividad y probablemente las personas tendrán que trabajar de mas afectando su calidad de vida.

• Si el sistema tarda mucho tiempo en responder ante las diferentes solicitudes de los usuarios probablemente ocurra lo mismo que en el punto anterior.

 2. Aquellos que son percibidos en el tiempo por el negocio. Tales como: Facilidad de modificación, Facilidad de extensión, Portabilidad o Escalabilidad.

• Si el sistema es difícil de modificar o de extender, se requerirá un esfuerzo mayor para realizar cambios sobre éste y por ende mayor será el costo de hacerlo, lo que finalmente afectará al negocio.

• Si el sistema no es portable será difícil de reutilizar y probablemente ocurrirá lo mismo que en el punto anterior.

En ambos casos el impacto se da tiempo después cuando sea necesario hacer cambios o reutilizar funcionalidades y es justo en ese momento cuando el negocio se ve afectado, no antes.

Cualquier atributo de calidad que no pueda agruparse en una de estas dos categorías no tiene sentido porque no estaríamos generando impacto sobre la calidad de vida de las personas ni sobre el negocio y finalmente éste debe ser nuestro objetivo.

Es claro entonces que nuestra responsabilidad es identificar estos atributos de calidad de cara a su impacto directo sobre las personas o el negocio. Para lograrlo existen muchas técnicas, una de las que más me gusta se llama QAW (Quality attribute workshop) de SEI, la cual discutiremos en otro post.