Innovación conciente

¿Cómo lograr un balance “perfecto” entre lo que nos suena más atractivo tecnológicamente hablando, y lo que resulta mejor para nuestro cliente?

Somos una empresa de Tecnología, nuestro equipo está formado por profesionales entusiastas, no sólo por lograr cumplir con los objetivos que plantea cualquier desarrollo de software, sino también por ofrecer un producto tecnológicamente de avanzada y moderno.

Para lograr nuestros objetivos se nos suelen plantear, entre otros, dos dilemas que podrían titularse así:

1- Tratar de ver más allá, nuestros clientes sabrán agradecerlo ¿Cómo recomendar y/o implementar una tecnología, sin haberla visto en real funcionamiento?
No siempre todo lo que se vende por ahí como lo mejor, resulta serlo y es muy importante recomendar implementaciones tecnológicas que sean acordes a la necesidad que buscamos satisfacer.

2- La mejor tecnología no es una en particular, es la que mejor se aplica a cada caso ¿Cómo lograr que nuestro entusiasmo tecnológico no le gane a nuestra conciencia profesional?.

(imagen tomada de http//wasanga.com/flormpecasique/files/2013/07/Proceso-de-Toma-de-Decisiones2.jpg?id=flormpecasique)

Nuestra experiencia en tantos años, nos permite volcar algunos tips que pueden ser útiles para lograr el objetivo principal, un producto de excelencia que cumpla con las necesidades planteadas en tiempo y forma, que permita seguir un ciclo de vida acorde a los tiempos en los que le toca vivir. 

Tratar de ver más allá, nuestros clientes sabrán agradecerlo

Primer paso: 

Lo más conveniente es Leer, Leer y Leer, en todo equipo siempre hay personas más predispuestas a saber interpretar por dónde viene la mano, es importante escucharlas y darles el lugar para poder llevar a cabo esa tarea.

Los foros de discusión son de mucha ayuda, se suelen volcar allí inquietudes sobre problemas reales con los que nos encontramos o nos vamos a encontrar.

Es muy útil saber elegir quienes son los gurúes a los que podemos seguir, buscar gente que sea responsable en lo que recomienda, y no dejarse llevar por charlatanes de turno.

Segundo paso 

Aprender una nueva tecnología, es una inversión no solo personal sino también para el equipo y por consiguiente para la empresa, permitir esta inversión cada vez que sea posible nos va a dejar mejor parados para el futuro, se podría decir que es un poquito de hambre para hoy, pero es pan para mañana.

Prototipar las partes más complejas sin entrar en los detalles para luego tratar de someterlo a pruebas que lo pueden poner al límite.

Tener muy claro en todas estas pruebas que lo importante es ver si la tecnología nos sirve para lo que queremos hacer, tratar de mantenerse distantes.

Normalmente en los equipos están los perfiles más innovadores, y los más reaccionarios al cambio, buscar el equilibrio de ambos nos puede dar los mejores resultados, hay que saber escuchar todas las campanas.

La mejor tecnología no es una en particular, es la que mejor se aplica a cada caso 

Cuando se elige una tecnología hay muchos factores en juego, menciono algunas de las preguntas que nos deberíamos hacer:

¿Qué impacto tiene la tecnología en la usabilidad del producto, si es que lo tiene?

¿Qué durabilidad en el tiempo pretendemos que tenga?

El mercado donde el producto va a vivir ¿le permitirá un soporte adecuado? en términos de posibilidades y costos. Etc. Etc…

Creo que la clave de todo esto es, ponerse en lugar del cliente en todo momento, y buscar la alternativa que realmente más le convenga a él.

Esto no siempre nos va a llevar al lugar más cómodo para nosotros, pero si nos va a permitir ganar la confianza del cliente, algo muy importante para poder llevar adelante una tarea tan compleja como apasionante, que es el desarrollo de software.

Leer más...

Probando Pentaho III: Introducción a Pentaho CTools

Encontré un muy buen documento (Introducción...) que me ayudó a sintetizar todo lo leído y probado respecto la construcción de Dashboards con CTools. Comparto mi traducción y síntesis:

Pentaho CTools es un framework para crear y mantener dashboards en la versión Community de Pentaho business intelligence server (bi-server)
Una de sus características relevantes es la creación de dashboards interactivos, integrados con el bi-server. Todos los datos disponibles se pueden visualizar, aprovechando la configuración de seguridad del bi-server de Pentaho.

Está compuesto por:
1. Community Dashboards Framework (CDF)
2. Community Chart Components (CCC)
3. Community Data Access (CDA)
4. Community Dashboard Editor (CDE)

1. CDF: motor generador de dashboards. Estos dashboards están formados por COMPONENTES, conectados entre si.
Componente: es un objeto de javascript que encapsula otros objetos con propiedades y funcionalidades. Puede ser visual o no. Tienen interacción entre ellos, la más básica es que un componente puede re-dibujarse a partir del cambio de una variable.
Se puede customizar su comportamiento.

2. CCC: componentes gráficos que permiten la interacción del usuario,  basados en Protovis y Raphaeljs

3. CDA: componente diseñado para recopilar, compaginar y distribuir información desde diferentes origenes.
Aunque CDF puede acceder a consultas SQL y MDX directamente, recomiendan el uso de CDA por asegurar accesos seguros, permitir joins de datos desde diferentes fuentes, exportar los datos de las queries fácilmente. También habilita la definición de las data sources y queries de SQL del lado del server. De esta manera, CDA disminuye el riesgo de inserción de código malicioso por medio de SQL injection (cuando la query esta almacenada del lado del cliente)

4. CDE: Editor que permite crear dashboards siguiendo estos pasos

1. Crear el layout o presentación de la página.
2. Especificar los data sources con la información a mostrar.
3. Crear los componentes visuales específicos. Conectarlos a los datos y ubicarlos en el layout.
4. Introducir más flexibilidad parametrizando los componentes y logrando interacción entre los mismos.

A continuación una descripción de las secciones de Layout, Components y Data Sources ...

Layout workspace

Formado por un área de estructura y otra de propiedades, relacionadas entre sí.

Layout Structure :
El layout mas simple esta formado por tres filas: Header, Contents y Footer.
Para modificar este layout, se pueden agregar columnas, filas, espacios, bloques de html, imágenes. Bloques de javascript.
Hay que tener en cuenta que las filas y columnas generadas están mapeadas a una estructura de <div> anidados, dentro de un archivo html generado en forma dinámica por el pentaho-CDE-plugin.

Properties:
Hay una lista de propiedades, describo las principales.
Nombre del elemento: se usa después para ubicar dentro del mismo los componentes gráficas.
Tamaños: toma blueprint css’ stylesheets. 'Width' se basa en las columnas de blueprint. 
Se puede ajustar, pero es mejor que estos tamaños sean dados por el componente en si.
Si los tamaños sumados de todos las columnas exceden el ancho de la página, tomarán la fila siguiente. Por otro lado, con blueprint los 'Heigths' son definidos por las alturas de lo que contiene, por eso, si una columna está vacía, queda invisible porque su altura es de 0 px.
Seleccion de color: área de color y saturación, pueden ser configuradas por el selector de colores.

Data source workspace

Hay once tipos de datasources, de los cuales probamos SQL Queries y MDX queries. 
Se puede seleccionar el acceso via JDBC ó JDNI.
Se recomienda acceder por JDNI en los casos en que se quiera acceder a mas de una tabla. Otra ventaja es que para setear JDNI se necesita solo el nombre de la datasource.
Dentro de las propiedades, se puede seleccionar un origen de datos creado anteriormente por Pentaho.
Al ingresar la consulta, se recomienda controlar la sintaxis de las consultas SQL o MDX en otro entorno. Un error en la consulta no se detecta fácilmente desde CDE.
También es útil probar la datasource creada por medio del Preview de CDA
Hay que guardar las modificaciones al datasource en cada cambio, y limpiar el cache de la CDA, entre una prueba/ corrección y prueba
Tener en cuenta que el cache del repositorio no es el mismo que el cache de la CDA.

Component workspace

El concepto de componente intenta simplificar la construcción de dashboards. Es un objeto de JavaScript que encapsula todas las propiedades y métodos. 
Destacamos:

1. Genéricos: simple paramenter (javascript parameter), custom parameter(arrays, objetos, funciones), date parameter. Parametros con su inicialización, se usan para conectar los componentes entre si
2. Scripts: funciones de javascript
3. Otros. Usamos los botones, tablas.
4. Charts: los componentes para gráficos específicamente. Pie chart, line chart, bar chart
5. Selects: componentes usados para seleccionar valores. Permiten la interacción del usuario, desde text inputs hasta combos.
6. Custom: Raphael component: Raphaeljs es una librería para Scalable Vector Graphics (svg).

Propiedades  de los componentes:
Cada tipo de componente tiene propiedades específicas, pero hay algunas comunes a todos que se pueden usar para controlar el ciclo de vida y comportamiento. Este cuadro resume el ciclo de vida de un componente y permite entender el sentido de las distintas propiedades.

















- executeAtStart: una variable booleana o (función que devuelva booleano). Indica si el componente será ejecutado (renderizado) en el load del dashboard o no.
- Parameters: array de parámetros a pasar al componente, en general basados en el input del usuario. Permiten customizar (al data source que está detrás)
- Parameter: Parámetro de salida de la función 
- Listeners: array de parámetros que disparan la ejecución y renderización del componente.
- PreExecution: función ejecutada antes de la inicializar o actualizar el componente. Si la función devuelve False, el componente no se actualiza.
- PostExecution: función que se ejecuta después del update del componente y se puede usar para indicar que la actualización terminó.
- PreChange: function(v), siendo v el nuevo valor del componente. Tiene sentido para componentes de tipo selector, para validar los inputs. Si esta función devuelve F no se ejecuta el evento 'fireChange'
- PostChange: se ejecuta después del cambio.
- Click action: Si la  CCC charts es clickable ( Clickable = true), se ejecuta una función cuyo prototipo es:

function(s, c, v) { <body> }, cons = label of the seriesc = category label (value at the x-axis)v = value (value at the y-axis)

El uso más común de esta función es modificar el valor de un parámetro por medio de   Dashboards.fireChange(param, value). Pero se pueden crear interacciones más complejas con un popup, por ejemplo. Que permitan que el usuario tome distintas acciones.


-Height - Width: usar solamente si al ubicar el componente dentro del layout no se ajusta a lo 
que necesitamos.
-Datasource: la cda datasource definida antes.
-HtmlObject: es el id del html del layout, definido antes, que será reemplazado por el componente.
-Listeners: qué parámetros definidos previamente,  disparan el cambio del componente
- Priority: por default 5, si es menor el componente se ejecuta primero. Se usa en los casos en que se quiere dar un orden de ejecución.
-Cross tab mode y series in rows
están relacionados con la estructura del dataset y con la información a mostrar.
Cross tab mode: si la consulta generada esta compuesta por series y categorías, en general si la consulta es MDX o una SQL con la clausula group by.
Series in rows: determina si las filas corresponden a las series o no.
If series in rows = false los datos deben venir como Serie, Category, Data. If series in rows =
true deben ser Category, Serie, Data.

Si crosstab mode = False los column headers (nombres) no son parte del dataset, por ende no serán visibles en el dashboard.

-Extension points:

Permiten setear el font family, font-size, text-orientation de los distintos componentes de texto del chart. Se forman como 'ItemTipo_propiedad', por ejemplo titleLabel_font.
Cuadro con ItemTipo más usados,  propiedades y ejemplos de valores para las propiedades

Artículos relacionados:

Probando Pentaho I (Instalación de Pentaho Community)
Probando Pentaho II (Dashboard de ejemplo)


Twittear Seguir a @3p_ar

Leer más...

Incidencia de las TIC en la gestión del Capital Humano

En estos últimos años venimos acompañando a los departamentos de RRHH de algunos de nuestros clientes, que buscaban incorporar tecnología en varios de sus procesos comunes (evaluaciones, comunicación, búsquedas internas, promociones, capacitaciones, outplacement, etc..)

Esto no se debe a un movimiento aislado sino a la influencia que las TIC (Tecnologías de la Información y Comunicación) vienen teniendo desde hace años en todas las áreas de la compañía, y particularmente destacable, en la gestión del Capital Humano.

Las TIC engloban a un sector de actividad donde se aplican en conjunto dos tipos de tecnologías: las TI (tecnologías de la Información) y las telecomunicaciones, con el objetivo de administrar y transformar la información, protegerla y recuperarla para analizarla desde distintos enfoques.

Para poder entender los efectos positivos que la aplicación de las TIC puede acarrear es necesario tener en claro que "tecnología" no es sinónimo de "producto" (un software en particular) sino de un concepto mucho más amplio. La implementación de la tecnología lleva a nuevas formas de colaboración, desarrollo de nuevos conocimientos, organización del trabajo, y en el caso del área de RRHH, exige nuevas capacidades de parte de sus responsables.

Justamente parte de esas nuevas capacidades implican, entre otras cosas, una evaluación estratégica de la tecnología a usar, teniendo claro que para el desarrollo de dichas capacidades es fundamental el apoyo de la alta dirección de las empresas.

En qué aspectos ayudan las TIC al sector de RRHH?

• En la comunicación, por supuesto
• En el diseño de puestos y roles
• En la supervisión
• En la detección de la duplicidad de trabajo
• En la detección de tareas que se pueden tercerizar

Si bien, en muchos casos la tecnología, aún hoy, no se reconoce como un agente de éxito en el área de RRHH, es innegable el rol que cumple en la mejora de procesos de negocio, y como consecuencia, en la productividad.

Objetivos

El objetivo de las TIC como concepto global es el de agregar valor a la operación diaria. Cualquier estrategia de aplicación de tecnología de la información en la gestión del capital humano debe permitir a la organización, entre otras cosas:

1. Centralización y gestión de toda la información de la compañía y su análisis en tiempo real
2. Gestión y evaluación de desempeño
3. Mejora de la motivación de los empleados a través de una comunicación más abierta y fluida
4. Mejora de la información interna y del acceso a la misma, promoviendo la cultura corporativa
5. Que el área de RRHH pueda enfocar sus esfuerzos en decisiones estratégicas, al quedar liberados de otras cuestiones rutinarias que insumen tiempo y esfuerzo
6. Reducción de costos y tiempos con la automatización de procesos, eliminación del uso de papeles en muchas operaciones y la gestión del tiempo

Procesos como Audit Management o Knowledge Management, por ejemplo, son factibles de aplicación de tecnologías a través de diversas aplicaciones.

Encontramos también herramientas para e-recruitment (búsqueda de canidatos a través de la web corporativa, por ejemplo), e-learning, B2E (businees to employe), administración de Intranets (de código abierto, pagas o a medida).
Las redes sociales juegan un papel muy importante hoy en día en la comunicación interna de las empresas y distintos modelos de teletrabajo son también incorporados en búsqueda de reducción de costos, flexibilidad, retención de empleados, mejoras en productividad, entre otros beneficios.

El enorme valor que estas tecnologías ofrecen hace que estén presentes en casi todas - si no todas - las actividades sociales y económicas en cualquier tamaño de empresa. En el caso de la gestión de capital humano no hay que perder de vista que, más allá de aplicar y saber usar las herramientas necesarias de la mejor forma, las tecnologías deben incidir positivamente en la vida de las personas.

Artículo relacionado:
Las redes sociales dentro de la empresa

Twittear Seguir a @3p_ar

Leer más...

SCRUM, problemas en la reunión diaria: qué podemos hacer al respecto?

Internamente muchas veces nos preguntamos si las reuniones diarias están cumpliendo el objetivo que realmente tienen y al leer blogs y foros sobre metodologías ágiles descubrí que muchos equipos tienen los mismos problemas que detectamos puertas adentro.

Revisar objetivos

Para comenzar es bueno recordar cuál es el objetivo y qué debe hacer cada miembro del equipo en una típica reunión diaria.


La reunión diaria tiene como fin el facilitar la transferencia de información y la colaboración entre los miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se pueden ayudar unos a otros.


Cada miembro del equipo participa del trabajo que el resto está realizando (dependencias entre tareas, progreso y problemas) para luego de finalizar la reunión poder hacer las adaptaciones que permitan cumplir con las historias que el equipo comprometió para el sprint en curso.

Cada miembro del equipo debe responder las siguientes preguntas en un tiempo estipulado de como máximo 15 minutos:

• ¿Qué he hecho desde la última reunión diaria? ¿ Pude hacer todo lo que tenía planeado? ¿Cuál fue el problema?
• ¿Qué voy a hacer a partir de este momento?
• ¿Qué problemas tengo o voy a tener para cumplir con este sprint y en el proyecto?

Como apoyo a la reunión, el equipo cuenta con la lista de tareas del sprint (sprint backlog) donde se actualiza el estado y el esfuerzo pendiente para cada tarea. 

Con esto se ponen en evidencia los beneficios y restricciones que tiene cada equipo en realizar sus tareas. 

(Para quienes quieran profundizar recomendamos leer "Scrum y XP desde las trincheras")

¿Problemas? ¿Qué problemas?

Si bien la práctica descripta en el párrafo anterior puede ser muy clara y parecer muy simple, nos pasa que, con el correr del tiempo notamos que hay cosas que empiezan a fallar o a sacarnos del eje de lo que indican los libros. ¿Cuáles son esas cosas? Aquí listamos algunos ejemplos de situaciones que pueden presentarse en las reuniones diarias y que pueden ser tratadas durante la misma, así como también recomendaciones recopiladas entre experiencia propia y de otros:


1. Algún miembro del equipo se queda sin tareas dentro del sprint

• Que él mismo elija qué cosas puede hacer para ayudar al equipo (test, documentación, scripts, etc.)
• O decidir entre todos que ayude con otros tipos de tareas, por ejemplo que sea el cadete del grupo. 

2. Falta tiempo para corregir código o hacer una corrección que no produce historias válidas dentro del sprint.

• Bajar el rendimiento del equipo, para poder dedicarle el tiempo suficiente a las tareas de mejoras o correcciones, es decir, plantearse hacer menos historias para el sprint.

3. Ante un proyecto grande con muchos desarrolladores

• Cuando la cantidad de personas en un proyecto es grande, se dispersa mucho la información, lo ideal es armar varios grupos más pequeños de entre 3 y 10 desarrolladores.
• Si hay varios equipos en el mismo proyecto , lo más recomendado sería, un solo project owner (dueño del proyecto), sprint sincronizados para que las demos sean el mismo día, la planificación unificada para repartir las historias y luego cada equipo hace su propia planning poker. Hacer en diferentes horarios las reuniones diarias, para que el project owner esté en todas. La gran ventaja de esta experiencia es que cuando termina cada sprint los miembros del equipo pueden ser intercambiados, o reorganizados minimizando así las dudas y/o problemas. 

4. Llegadas tarde a la reunión diaria

• Elegir una hora buena para todos ( en la generalidad de los casos, se toma como horario de la reunión diaria, entre 15 y 30 minutos posteriores al horarios de inicio de la jornada).
• Si los retrasos son habituales se puede "llenar la alcancía", "traer algo para compartir para todos". Ante la reincidencia eligen hacer que duela un poco más el bolsillo y así tratar de evitar llegar retrasado.  
• Llegar tarde se puede deber al desinterés, con lo cual es válido plantear como alternativa que el propio implicado en los sucesivos retrasos puede exponer sus propias explicaciones ante el grupo y/o alternativas de participación para aumentar su interés. 
• Contar o no qué paso en la reunión o a los que no estuvieron presentes, depende de dos puntos de vista, el interés de escribir en una breve "minuta" sobre lo hablado por el project owner y el otro punto de vista el interés del integrante retrasado en interiorizarse en lo sucedido en la reunión diaria. 

5. Equipo distribuido geográficamente

• Skype, o cualquier vía de comunicación on line conectado permanentemente, reunión diaria del equipo completo, comunicación lo más fluida posible (skype, cámaras web, mail, de ser necesario palomas mensajeras!!!)

En forma anecdótica podemos decir, que en Tercer Planeta, hemos intentado varias de estas recomendaciones, algunas con funcionamiento óptimo y otras en vías de mejoras seguras. 

La más importante que hacemos es la de realizar una reunión diaria del grupo completo, ya sea que pertenezcan o no al mismo proyecto, contándonos en qué estamos cada uno y pidiendo todos los S.O.S. necesarios, esto permite que ninguno de los proyectos quede estancado, reconociendo que no todos sabemos todo. Además de poder contar con ayuda, podemos saber en qué estado está cada uno. A esta reunión diaria grupal general, muy cortita, le siguen las reuniones diarias específicas de cada proyecto en concreto (reuniones de avance). 

Personalmente, la primer reunión diaria es la más saludable y a veces hasta la más esperada por todos, nos permite entender el estado de cada uno, estar al tanto de temas generales del equipo y temas más sociales. Es una manera de mantener la comunicación "viva", más allá de los detalles particulares que presente cada proyecto. 

Twittear Seguir a @3p_ar

Leer más...