DBXPRESS ¡Suscríbete!

Boletín DBAccess


¿Acepta HTML?

Síguenos también en:

Facebook FeedBurner Flickr Linked In Group Twitter YouTube SlideShare

Tecno Posts

DBAccess: Una organización distribuida

Atención, abrir en una nueva ventana. PDFImprimirE-mail

Leyendo el blog personal de Toni Schneider sobre “Las 5 razones por las que su empresa debería ser distribuida”, no pude dejar de reconocer a DBAccess en el texto. Y es que es una tendencia que más y más se ha estado adoptando en empresas alrededor del mundo. Sobre todo aquellas que están relacionadas a la tecnología, la innovación y las nuevas tendencias. Como es nuestro caso, enmarcándonos en la región latinoamericana.

Hace unos días comunicábamos en el correo corporativo DBA a todos los colaboradores; desde hace tiempo ubicados en diferentes lugares geográficos, lo que serían los lineamientos de Operación Distribuida de la Red DBAccess. Lineamientos que responden en parte a situaciones específicas del entorno, pero que tienen una estrecha relación con el tipo de organización que deseamos ser.

La Red DBAccess, distribuida.

Como colaboradores es de altísimo valor familiar. Sí, así los hemos visto en el estudio que anualmente nos hace Great Place To Work Intitute, nosotros lo llamamos “Homeshoring”, y es una de las prácticas más valoradas por la gente que trabaja junto con nosotros, sencillamente porque les permite estar más tiempo con sus familias. La flexibilidad de poder decidir tu propio horario, de poder agregar el mayor valor posible en base a compromisos, el no vivir “esclavo” de una hora fija o de una cola de tránsito, son entre otras muchas ventajas lo que en definitiva redunda en la calidad de vida de los colaboradores de DBAccess. Nuestra gente tiene la oportunidad de decidir en qué ciudad quiere vivir, evitando así tener que buscar trabajo en la misma ciudad o tener que mudarse y buscar otro trabajo. Tenemos personas que ya simplemente no se visualizan en un “8 a 5” sentados en el mismo cubículo de siempre.

La búsqueda de nuevos colaboradores es global. Al declararnos globales, el mercado para buscar a las mejores personas que deseen trabajar con nosotros es simplemente todo el planeta. Ni más ni menos. ¿Por qué buscar a las personas en la misma ciudad de siempre? Y esto es también un reto para los futuros colaboradores, porque la competencia es desde cualquier lugar. Ya no importa en que ciudad se encuentre la persona ni la cultura que lo rodea, lo importante es que se conecte con la Cultura DBAccess, con su misión y su visión, si puede producir desde Madrid ó desde Lima, es transparente para la organización.

Nos obliga a usar mejor las herramientas de comunicación. Ciertamente una conversación en el mundo físico puede ser más enriquecedora. Pero en nuestro caso hay personas que literalmente nunca se han visto y sin embargo, hacen equipos maravillosamente. Esto implica que, más allá de lo que ocurre localmente en nuestros espacios, al ser distribuidos obligatoriamente debemos deshacernos de reuniones largas e ineficientes, largas cadenas de correo y chismes de pasillo. La organización distribuida está obligada a ser eficiente, y de allí que las herramientas como Skype tengan que ser maximizadas en su uso efectivo u otras que nos permitan tener reuniones de equipos ubicados en diferentes países.

Lo social es importante. Y no importa que estemos en diferentes ciudades, al menos en nuestro caso hacemos el esfuerzo por reunir a las personas en las Jornadas, en las reuniones de cierre de trimestre, en los aniversarios y otro número de actividades. Además de estas actividades, siempre tenemos la posibilidad de reunirnos con nuestros equipos, digamos que esta es una decisión más del líder de unidad que una decisión en forma centralizada. Nuestros colaboradores tienen siempre la posibilidad de proponer reuniones o encuentros de todo el equipo distribuido, de tal forma de buscar esa conexión personal que siempre necesitamos para afianzar el espíritu de equipo y simplemente sentirnos bien con quienes trabajamos día a día.

No nos hace falta una “oficina”. Nosotros lo llamamos Espacios de Producción Distribuida o EPD. Y son eso y es claro que no son una oficina tradicional. Además pueden estar en cualquier ciudad del mundo en el que se encuentren equipos y personas conectados con DBAccess. Nuestra gente trabaja desde casa, en realidad desde cualquier lugar con buena conexión a internet, lo resaltante de nuestros EPD es que las personas no tienen que ir todos los días, nadie tiene un escritorio fijo, simplemente se requieren servicios básicos para trabajar y reunirse con el equipo o con clientes si fuera el caso, ah! Y por supuesto por lo general un portátil. ;)

Puede que algunos que lean este post, piensen que esa empresa no es posible, nosotros en DBAccess no sólo decimos que es posible, también decimos que puede ser con excelencia y calidad. Así que no hace falta más que empezar con las prácticas y trabajar.
 
Autor: Jesús Maceira 
 

El Proyecto y el Producto

Atención, abrir en una nueva ventana. PDFImprimirE-mail

Pedro García aborda distintos escenarios referentes al Proyecto y al 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.

Por: Pedro García
Blog: http://pedrogtit.blogspot.com/

   

Más noticias...