Project Management

Equipo QA – El recurso oculto

Posted on 4 marzo 2009. Filed under: Calidad del Software, Ingeniería del Software, Metodologías de Desarrollo, Opinión, Procesos Ágile, Recursos Humanos, Roles, Trabajo en Equipo, Waterfall |

¿Que es lo primero que viene a mente cuando mencionamos Ingeniero QA o Tester?

Hay quienes piensan y asumen que las actividades típicas del Tester, las puede llevar a cabo cualquiera, ya sea utilizando procesos de desarrollos tradicionales o Agiles.

La razón puede estar fundada en el concepto erróneo de que cualquier persona puede determinar si una aplicación funciona o no. Sin embargo con este pensamiento se deja de lado la naturaleza destructiva de las actividades de Testing y el no centrarse en el funcionamiento correcto, sino en los aspectos fallidos del software.

También se está asumiendo que el aseguramiento de calidad es solo cumplir con actividades de Testing. Nada más lejos de la realidad.

En las metodologías tradicionales de desarrollo de software, se tiene especial cuidado con la planificación de las pruebas, de modo tal que esta sea acorde a la definición temprana de los requerimientos (obviando las verificaciones y validaciones QA) y en base a un aprendizaje oportuno de como debería funcionar el sistema, de modo tal que según lo planificado, en ciclos de pruebas de sistemas se valide la completitud y correctitud del sistema en base a tales requisitos.

Como contrapartida, se supone un Plan de Pruebas rígido, con muy baja adaptabilidad al cambios de requerimientos y a aparición de nuevos requisitos.

En la vereda del frente estarían las metodologías Agiles, donde la planificación del Testing debe ser adaptativa, acorde a la velocidad de cambios en los requerimientos del sistema, lo cual puede presumir una mayor participación de los miembros QA en etapas tempranas del proceso de desarrollo, inclusive en la misma formación de los requisitos, su analisis y estimaciones, lo cual comprensiblemente podría ser deseable.

Esto es en resumen como se comporta el Testing en metodologías no Agiles.

De este modo, conceptualmente la participación del QA cambia de un rol de “full-control” a “full-partner” del resto de los miembros del equipo.

Esta concepción permite revalorizar los roles QA debido al uso petenciado de los mismos, aportando un valor más estratégico para las necesidades de los negocios que atienden los sistemas que se construyen.

Los Testers, podrían ser utilizados a su máxima potencia, con actividades operativas que ayudan a los desarrolladores a promover la generación de soluciones más eficientes y en instancias tempranas.

A su vez los miembros del equipo QA podrían ser fuentes de información constante referido al comportamiento del sistema en construcción, permitiendo adelantarnos a cambios en los requerimientos, requerimientos mal concebidos o desarrollados en modo no deseado, promover mejoras y una lista larga de etcs. que en definitiva orientan a traves de todo el ciclo de vida del proyecto.

Pero no confundamos esta revalorización del personal QA tratando de abarrotarla detrás de las metodologías Agiles, ya que el concepto puede ser aplicado a cualquier proceso de desarrollo. De hecho, las metodologías Agiles no han planteado este paradigma ni es algo que les pertenece, aún cuando se utilice la terminología “Testing Agile”. Inclusive muchos “pseudoagilístas” consideran a un Tester como a cualquier otro recurso QA, un recurso de menos rango y hasta despreciable para la organización.

QA se da cuenta de la evolución por la misma adaptación que debió sufrir acorde a la velocidad de respuesta que requieren los procesos de desarrollos actuales.

Asumamos que un cambio de paradigma QA es posible aún dentro de procesos tradicionales. Aún así, el cambio no puede gestarse por si solo, debe surgir de un cambio en el paradígma organizacional.

Fuentes de inspiración:
Testers: The hidden resource

Anuncios
Leer entrada completa | Make a Comment ( Comentarios desactivados en Equipo QA – El recurso oculto )

Tres factores que influyen positivamente en los proyectos exitosos

Posted on 23 febrero 2009. Filed under: Calidad del Software, Gestión de Proyectos de Software, Métricas, Project Management | Etiquetas: , , , , |

Según una revisión realizada por SDTime a cerca del Chaos-Report,  , los proyectos iniciados en el año 2006 han culminado exitosamente en un 35%, comparado con el 16% reportado en el año 1994.

Considerando como exitoso a aquellos proyectos que culminaron a término, dentro del presupuesto y satisfaciendo las necesidades de los usuarios, se conoció que se redujo de casi 53% al 46% la tasa de proyectos que no cumplían con alguno de estos tres atributos de éxito.

Según la revisión existen tres factores que fundamentan esta mejoría:

  1. El estilo de gerenciamiento, los conocimientos en técnicas y métodos como la evolución de las estrategias y la aplicación de todo el conjunto en contextos dinámicos, permite que los proyectos inicien de un modo mucho más favorable, lo cual directamente impacta en su desarrollo y culminación.
  2. La nueva infraestructura Web juega un papel significativo para la producción de mejores proyectos, por cuanto permite que una idea pueda ser mostrada, aprender de ella y obtenerse un importante volumen de retroalimentación que genera experiencias dinámicas únicas.
  3. Pero podría decirse que el principal factor que favorece a que los proyectos sean exitosos, es la creciente inclusión del aseguramiento de la calidad, lo cual ha permitido que las organizaciones desde un principio se planteen aspectos de sus productos y servicios que antes no consideraban, incluyendo la relación con sus clientes y usuarios finales de quienes requieren cada vez más devolución para el perfeccionamiento de todo el proceso.

Un elemento central del aporte QA son las métricas organizacionales y quienes a medir su rendimiento, lograron tomar partido de sus fracasos y éxitos, revirtiendo los aspectos negativos de los proyectos para conseguir un fuerte sesgo a la culminación exitosa de sus proyectos.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Tres factores que influyen positivamente en los proyectos exitosos )

Actitudes y Aptitudes – 2

Posted on 20 febrero 2009. Filed under: Actitudes, Aptitudes, Capacitación, Habilidades Personales, IT Management, Opinión, Pruebas de Campo, Recursos Humanos | Etiquetas: , , , , |

Agustín, ¿que esperabas obtener de las respuestas de los entrevistados?

sería importante que nos contaras eso para saber si no pecaste de lo que la mayoría de los entrevistadores pecan, que quieren innovar en las entrevistas siguiendo un proceso que en definitiva es clasisista. 

Es muy interesante ver cuando los entrevistadores hablan mal de los entrevistados adusiendo que no pueden resolver tal o cual “asunto simple” que uno mismo está acostumbrado a resolver a diario, o no responden de acuerdo a las espectativas.

Sin embargo, la mayoría de las veces no se explica el contexto de la entrevista, por ejemplo indicando que no se esperan respuestas tradicionales y que se busca que los interesados en el trabajo puedan responder innovativamente, hasta con un toque de “infantilismo” si se quiere aceptar el término.
Así mismo no se plantean las dinámicas que le permita al entrevistado adaptarse rápidamente al proceso de selección y logre participar de juegos, actividades de grupo y cosas por el estilo que ayuden al mismo entrevistador ir detectando líderes, planificadores, operarios, según la participación y su modo de resolver los aspectos de las dinámicas.

Luego hay que tener en cuenta que muchos recruiters intentan innovar en la forma de encontrar nueva gente, pero en cuanto ven un talento, inmediatamente le buscan el “pero”, y lo tildan de excéntrico o viciado, dado a que gente de esta naturaleza es un poco excentrica y hasta demasiado exigente. Allí mismo comienza el proceso de truncar el caracter innovador del prospecto.

También se debe tener autocrítica
Analizar si se está dispuesto a que la gente sea proactiva, auto resolutiva, extrovertida y motivada como motivadora, por que aunque son atributos deseables en las personas, son aplacables en la mayoría de los entornos de trabajo.

¿Se está dispuesto a detectar los talentos con potencial pero sin las habilidades técnicas maduras?
creo fuertemente que esta es la principal razón que evita que las personas talentozas estén ahora mismo trabajando y no pasa lo mismo con quienes mañana mismo puede iniciar una actividad técnica que aporte valor técnico y operativo inmediato, pero que a la larga su curva de aprendizaje en el resto de los ámbitos, es plana.

Buscar talentos es un proceso de maduración organizacional
fortalecido por un aprendizaje por parte de los RRHH, en estrategias, métodos y técnicas específicas y hasta comprendiendo aspectos psicológicos y neurofisiológicos de los que ni si quieran oyeron hablar y mucho menos entienden de buenas a primeras.
Lleva mucho tiempo comprender esto y mucho más aplicarlo y mucho más aún ver los resultados reales.

“Extreme Interviewing”
es un metodo reciente de entrevistas basadas en dinámicas de grupo y trabajo específicos que ayudan a detectar talentos, basados no netamente en habilidades técnicas, sino más bien en actitudes correctas que permitan la absorsión de nuevas habilidades según el curso de los negocios actuales.
Se pretende detectar a las personas que podrán sostener una curva de aprendizaje constante dentro de la organización.
Intenta validarse en contraposición con las “Entrevistas Tradicionales”, pero lo malo es que ya se le dió una orientación que la liga con las metodologías Ágile.

¿Malo por que?
Por que ya antes, con mucho sentido común, muchos se dieron cuenta que la búsqueda y reclutamiento tradicional de personal IT (o de cualquier otro tipo), son obsoletas o comenzaban a serlo y mientras estas buscaban “robots tecnificados”, las personas comenzaron a estar más lejos de estas habilidades requeridas, por la velocidad del cambio tecnológico, por los desmanes psicológicos que propinan seguir estos rítmos de aprendizaje contínuos, por la mala calidad de vida que genera en si mismo tratar de estar al corriente, sobre todo los que sientes estar siempre al borde del avismo para permanecer en sus puestos de trabajos o conseguir uno mejor.

En artículos de opinión personal, yo mismo ya había hablado de este tema y muchos foros había preguntado cual es la preferencia en una organización “¿un elevado perfil técnico o una mejor actitud?”. Un ejemplo puede leerse aqui: “Actitudes y Aptitudes – 1”

Sin embargo este tipo de “entrevistas extremas” tiene una connotación importante, pues todos los posibles candidatos son convocados a trabajar juntos en sesiones de trabajo por pares, donde se les asigna una tarea a realizar, con la premisa de resolver un problema, sin embargo, los recruiters no observan solo las capacidades de resolución, sino el desembolvimiento del prospecto como un ser humano que interactuará en una sociedad de trabajo colaborativo y con objetivos comunes, tal es así que la resolución del problema pasa a ser un elemento secundario y se valor mucho la capacidad de “hacer sentir bien a tu socio colaborador”.

La respuesta siempre apunta al equilibrio
pero los reclutadores parecen no entenderlo, ni las organizaciones cuando inician el proceso de búsqueda para cubrir vacantes. Es en ese punto cuando quieren al “genio de la bola de cristal”. Ah!!! también debe ser proactivo, autogestionado, colaborador y resolutivo con un alto sentido de la urgencia, con un caracter apacible pero fuertemente decidido, con amplia orientación al cliente y a los servicios.

Hacer sentir bien a tu socio colaborador
Lo que se debe intentar buscar, es evidencia de las personas con verdaderas capacidades de ayudar a sus pares, colaborar con ellos sin importar el inconveniente, ni las diferencias de habilidades técnicas. Quizás la idea es siempre “nivelar hacia arriba”.
Lo que se destaca, es que las personas que finalmente serán seleccionadas, en realidad comenzaron con su entrenamiento en el preciso momento en que iniciaron el proceso de evaluación y selección.

El diseño de un ambiente propicio para el aprendizaje
es el aspecto fundamental para este cambio de paradigma, ya que no es posible promover el reclutamiento de talentos sobre el reclutamiento de habilidades si organizacionalmente solo nos interezan los aspectos de resolución técnica inmediata y no contamos con la estructura de capacitación y transferencia de conocimientos técnicos.
Nuevamente la capacitación es un ítem de importancia, pero fijémonos que aquí no comentamos los mismos errores.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Actitudes y Aptitudes – 2 )

Cambiar o morir

Posted on 19 febrero 2009. Filed under: Actitudes, Trabajo en Equipo | Etiquetas: , , , |

La encargada de limpieza en las oficinas de una Software Factory puso carteles en el baño y en la cocina, llamando a la colaboración para mantener el orden y la limpieza. El resultado directo fue el enojo y reacción de las personas, los comentarios por lo bajo y los email masivos mostrando el descontento de quienes se vieron afectados por las notas.
Del mismo modo sucede cuando se envía una circular indicando la necesidad de mejoras en los comentarios de códigos, cuando se levantan “no conformidades” en revisiones de especificaciones del software, o documentación de arquitectura y diseño, cuando se pide aumento de detalle o modificaciones drásticas o simples en las definiciones de los Casos de Usos o User Story, cuando se pide ampliación de pruebas unitarias para garantizar la construcción, cuando se pide limpieza en la utilización de juegos de datos en pruebas de integración para garantizar la reutilización del ambiente, cuando se pide modificar o aumentar caminos de pruebas para mejorar la cobertura de las pruebas de sistemas, cuando se solicita la involucración temprana de los líderes de proyecto para hacer seguimiento de los proyectos, cuando se piden planes de despliegue que incluyan pruebas de campo, o inclusive cuando se pide considerar incluir estimación de riesgos, análisis post mortem, lecciones aprendidas, repositorio de clases, comentarios en actualizaciones del repositorio o se introduce y notifica cualquier modificación en el proceso, aún luego de haberse convenido tales cambios.

¿Será que nuestra naturaleza no nos permite ser reflexivos y por el contrario somo fuertemente reactivos a cualquier situación que indique que debemos cambiar y modificar nuestras actitudes más íntimas?

¿ Será que no nos damos cuenta que hasta para las cosas más simple es mejor cambiar para vivir y convivir?

Quizás debamos ser drásticos e interpretar que debemos “Cambiar o Morir”.

Leer entrada completa | Make a Comment ( Comentarios desactivados en Cambiar o morir )

Actitudes y Aptitudes – 1

Posted on 19 febrero 2009. Filed under: Actitudes, Aptitudes, Capacitación, Comunicación, Habilidades Personales, Liderazgo, PNL y Coaching, Opinión, Organización del Trabajo Personal, Recursos Humanos, Resolución de problemas, Trabajo en Equipo | Etiquetas: , , , |

El balance Actitud/Aptitud. Una respuesta desde Recursos Humanos

El trabajo de un individuo no solo puede evaluarse por sus resultados externos, sino también por el aprendizaje del sujeto en el proceso de trabajo

El proceso de aprendizaje podrías ser tal vez, el agente disparador de las actitudes y aptitudes que definen a un sujeto frente al trabajo y a las acciones que realice para ejecutarlo, de modo tal que tanto actitud como aptitud se encuentran fuertemente ligadas.

Aunque las aptitudes (relativo a los conocimientos agnósticos y técnicos) puedan ser mejores en algunos individuos, probablemente lo que mejor define a un trabajador es su actitud, ya que le favorece notablemente en su curva de aprendizaje continuo, en el enfrentamiento con nuevos desafíos, en la posibilidad de innovación, en la propuesta de cambios y mejoras,  en la colaboración y en la toma de decisiones, elementos necesarios en los paradigmas de los negocios actuales.

En respuesta a estos criterios, es que las organizaciones en sus áreas de Recursos Humanos, debe evaluar correctamente y con amplio criterio a las personas que pertenecerán a los equipos de calidad y testing, de modo tal que no sea excluyente el conocimiento técnico aplicado a una herramienta particular.

Recursos Humanos debe integrar sus conocimientos de selección de personal con los requisitos del área QA y Testing, de modo tal que su búsqueda no se encause en aspectos débiles, inclusive buscando fortalezas técnicas.

Me inclino ampliamente a la contratación de personal que tiene una elevada actitud positiva, proactiva, comunicativa y coloborativa, al menos para actividades de calidad, salvo que el requisito implique a personal con capacidades acabadas en el manejo de una o más herramientas operativas donde no existen posibilidades de una curva de aprendizaje por parte del prospecto.

Personas con grandes habilidades técnicas suelen llevar al fracaso proyectos por derruir la moral del equipo, desmotivándolo, volviéndolos contrarios y haciendo que los mismos se olviden aunque sea en forma temporal, de la misión de su participación en los proyectos.
En muchas ocasiones puede inclusive hasta perderse la confianza en su desempeño técnico, gracias a la observación de actitudes contrarias a las necesidades de los proyectos y de los equipos de trabajo.

Los líderes de equipos muchas veces no saben como lidiar con esta gente, pues los necesitan por su valor técnico y los desprecian por su actitud.
Esta dualidad no es buena y quizás eliminarla desde un principio, detectando cual es el balance Actitud/Aptitud, sea lo conveniente para asegurar éxito en los proyectos.

Es importante que Recursos Humanos evite  dejar toda la carga de control de la situación en manos de los líderes, que sin duda deberán restar esfuerzo y concentración a sus otras actividades para encausar su equipo de colaboradores.

Después de todo como en cualquier proceso, lo importante es no introducirse BUGS a uno mismo.

Leer entrada completa | Make a Comment ( 2 so far )

Asumir responsabilidades – Resolución de problemas (Técnicas)

Posted on 16 febrero 2009. Filed under: Plan de Acción, Resolución de problemas, Resolución de Problemas y Gestión de Incidentes, Trabajo en Equipo | Etiquetas: , , , |

La evolución del concepto de calidad aplicado a la industria, y ahora a los servicios, muestra claramente que se ha pasado de una etapa, en donde la calidad era aplicada totalmente al control realizado al final de las líneas de producción, a otra donde aplicamos calidad total a todo dentro de la organización. Por ende, ya se habla de calidad de vida en el trabajo, calidad de vida en los servicios y calidad ambiental.
Recordemos que el concepto de calidad hoy en día, es aplicado en el ámbito industrial, como el logro de hacer las cosas bien la primera vez. Y se aplica control de calidad sobre las operaciones desde el diseño. Hasta que se obtiene el producto final e inclusive se habla de la calidad en la atención al cliente.
El camino que nos lleva hacia la Calidad Total crea una nueva cultura, establece y mantiene un liderazgo, desarrolla al personal y lo hace trabajar en equipo, además de enfocar los esfuerzos de calidad total hacia el cliente y a planificar cada uno de los pasos para lograr la excelencia en sus operaciones.
El hacer esto exige vencer obstáculos que se irán presentando a lo largo del camino. Estos obstáculos traducidos en problemas se deben resolver conforme se presentan evitando con esto las variaciones del proceso. Para esto es necesario basarse en hechos y no dejarse guiar solamente por el sentido común, la experiencia o la audacia. Basarse en estos tres elementos puede ocasionar que al momento de obtener un resultado contrario al esperado nadie quiera asumir responsabilidades.
De allí la importancia de basarse en hechos reales y objetivos, además de que surge la necesidad de aplicar herramientas de solución de problemas adecuadas y de fácil comprensión.
Las herramientas y técnicas cualitativas y no cuantitativas son las siguientes:
1. Recolección de datos.
2. Lluvia/Tormenta de ideas (Brainstorming).
3. Diagrama de Paretto.
4. Diagrama de Ishikawa.
5. Diagrama de flujo.
6. Matriz de relación.
7. Diagrama de comportamiento
8. Diagrama de Gantt.
9. Entrevistas.
10. Listas checables.
11. Presentación de resultados.
La experiencia de los especialistas en la aplicación de estas herramientas señala que bien utilizadas y aplicadas, con la firme idea de estandarizar la solución de problemas, los equipos pueden ser capaces de resolver hasta el 95% de los problemas.

RECOLECCIÓN DE DATOS
CONCEPTO
Es una recolección de datos para reunir y clasificar las informaciones según determinadas categorías de un evento o problema que se desee estudiar. Es importante recalcar que este instrumento se utiliza tanto para la identificación y análisis de problemas como de causas.

USO
Hace fácil la recopilación de datos y su realización de forma que puedan ser usadas fácilmente y ser analizadas automáticamente. Una vez establecido el fenómeno que se requiere estudiar e identificadas las categorías que lo caracterizan, se registran los datos en una hoja indicando sus principales características observables.

Una vez que se ha fijado las razones para recopilar los datos, es importante que se analice las siguientes cuestiones:
· La información es cuantitativa o cualitativa.
· Cómo se recogerán los datos y en que tipo de documentos se hará.
· Cómo se utilizará la información recopilada.
· Cómo se analizará.
· Quién se encargará de recoger los datos.
· Con qué frecuencia se va a analizar.
· Dónde se va a efectuar.

OTROS NOMBRES
· Hoja de recogida de datos
· Hoja de registro
· Verificación
· Chequeo o Cotejo

PROCEDIMIENTO
1. Identificar el elemento de seguimiento
2. Definir el alcance de los datos a recoger.
3. Fijar la periodicidad de los datos a recolectar.
4. Diseñar el formato de la hoja de recogida de datos, de acuerdo a la cantidad de información a escoger, dejando espacio para totalizar los datos, que permita conocer: las fechas de inicio y termino, las probables interrupciones, las personas que recoge la información, la fuente etc.

LLUVIA DE IDEAS
CONCEPTO
Técnica que consiste en dar oportunidad, a todos los miembros de un grupo reunido, de opinar o sugerir sobre un determinado asunto que se estudia, ya sea un problema, un plan de mejoramiento u otra cosa, y así se aprovecha la capacidad creativa de los participantes.
USO
Se pueden tener dos situaciones ante la solución de un problema:
1. Que la solución sea tan evidente que sólo tengamos que dar los pasos necesarios para implementarla, y
2.  Que no tengamos idea de cuáles pueden ser las causas, ni las soluciones.
Es aquí donde la sesión de tormenta de ideas es de gran utilidad. Cuando se requiere preseleccionar las mejores ideas.

OTROS NOMBRES
· Brain Storming
· Tormenta de ideas

PROCEDIMIENTO
1. Nombrar a un moderador del ejercicio.
2. Cada miembro del equipo tiene derecho a emitir una sola idea por cada turno de emisión de ideas.
3. No se deben repetir las ideas.
4. No se critican las ideas.
5. El ejercicio termina cuando ya no existan nuevas ideas.
6. Terminada la recepción de las ideas, se les agrupa y preselecciona conforma a los criterios que predefina el equipo.

DIAGRAMA DE PARETTO
CONCEPTO
Gráfico cuyas barras verticales están ordenadas de mayor a menor importancia, estas barras representan datos específicos correspondientes a un problema determinado, la barra más alta esta del lado izquierdo y la más pequeña, según va disminuyendo de tamaño, se encuentra hacia la derecha.

USO
Ayuda a dirigir mayor atención y esfuerzo a problemas realmente importantes, o bien determina las principales causas que contribuyen a un problema determinado y así convertir las cosas difíciles en sencillas. Este principio es aplicable en cualquier campo, en la investigación y eliminación de causas de un problema, organización de tiempo, de tareas, visualización del antes y después de resuelto un problema, o en todos los casos en que el efecto final sea el resultado de la contribución de varias causas o factores.

PROCEDIMIENTO
1. Decidir qué problemas se van a investigar y cómo recoger los datos.
2. Diseñar una tabla de conteo de datos (totales).
3. Elaborar una tabla de datos.
· Lista de ítems
· Totales individuales
· Totales acumulados
· Composición porcentual
· Porcentajes acumulados
4. Organizar los ítems de mayor a menor.
5. Dibujar dos ejes verticales y uno horizontal
6. Construir un diagrama de barras.
7. Dibujar la curva acumulada (curva de Pareto).
8. Escribir cualquier información necesaria.

DIAGRAMA DE ISHIKAWA
CONCEPTO
Técnica de análisis de causa y efectos para la solución de problemas, relaciona un efecto con las posibles causas que lo provocan.

USO
Se utiliza para cuando se necesite encontrar las causas raíces de un problema. Simplifica enormemente el análisis y mejora la solución de cada problema, ayuda a visualizarlos mejor y a hacerlos más entendibles, toda vez que agrupa el problema, o situación a analizar y las causas y subcausas que contribuyen a este problema o situación.

OTROS NOMBRES
· Diagrama de espina de pescado
· Diagrama Causa Efecto

PROCEDIMIENTO
1. Ponerse de acuerdo en la definición del efecto o problema
2. Trazar una flecha y escribir el “efecto” del lado derecho
3. Identificar las causas principales a través de flechas secundarias que terminan en la flecha principal
4. Identificar las causas secundarias a través de flechas que terminan en las flechas secundarias, así como las causas terciarias que afectan a las secundarias
CAUSA MAYOR
CAUSA MAYOR
DEFECTO
CAUSA MAYOR
CAUSA MAYOR
5. Asignar la importancia de cada factor
6. Definir los principales conjuntos de probables causas: materiales, equipos, métodos de trabajo, mano de obra, medio ambiente (4 M`s)
7. Marcar los factores importantes que tienen incidencia significativa sobre el problema
8. Registrar cualquier información que pueda ser de utilidad

MATRIZ DE RELACIÓN
CONCEPTO
Gráfico de filas y columnas que permite priorizar alternativas de solución, en función de la ponderación de criterios que afectan a dichas alternativas.

USO
· Cuando se requiere tomar decisiones más objetivas.
· Cuando se requiere tomar decisiones con base a criterios múltiples.

OTROS NOMBRES
· Matriz de priorización
· Matriz de selección

PROCEDIMIENTO
1. Definir las alternativas que van a ser jerarquizadas
2. Definir los criterios de evaluación
3. Definir el peso de cada uno de los criterios
4. Construir la matriz
5. Definir la escala de cada criterio
6. Valorar cada alternativa con cada criterio (usando la escala definida anteriormente)
7. Multiplicar el valor obtenido en el lado izquierdo de las casillas, por el peso de cada criterio y anotarlo a la derecha de cada casilla
8. Sumar todas las casillas del lado derecho y anotar el resultado en la casilla Total
9. Ordenar las alternativas de mayor a menor

DIAGRAMA DE COMPORTAMIENTO
CONCEPTO
Herramienta que permite graficar los puntos del comportamiento de una variable, de acuerdo a como se van obteniendo.

USO
· Para representar visualmente el comportamiento de una variable
· Evaluar el cambio de una proceso en un período

OTROS NOMBRES
· Diagrama de Tendencias

PROCEDIMIENTO
1. Decidir qué problema se va a monitorear y cómo se van a recoger los datos
2. Mantener el orden de los datos, tal como fueron recolectados
3. Dibujar un eje vertical y uno horizontal (Eje X Tiempo – Eje Y Medida)
4. Marcar los puntos. Un punto marcado indica ya sea la medición o cantidad observada en un tiempo determinado
5. Unir las líneas de puntos
6. Escribir en el diagrama cualquier información necesaria

DIAGRAMA DE GANTT
CONCEPTO
Gráfico que establece el orden y el lapso en que deben ejecutarse las acciones que constituyen un proyecto.

USO
· Permite vigilar el cumplimiento de un proyecto en el tiempo.
· Permite determinar el avance en un momento dado.

OTROS NOMBRES
· Cronograma de actividades

PROCEDIMIENTO
1. Identificar y listar todas las acciones que se deben realizar para cumplir con un proyecto
2. Determinar la secuencia de ejecución de las acciones
3. Definir los responsables de ejecutar cada acción
4. Escoger la unidad de tiempo adecuada para trazar el diagrama
5. Estimar el tiempo que se requiere para ejecutar cada acción
6. Trasladar la información anterior a las ubicaciones correspondientes en el diagrama

ENTREVISTAS
CONCEPTO
Técnica que permite reunir información directamente con el involucrado en el proceso.

USO
Obtener información de clientes o proveedores de un proceso.

PROCEDIMIENTO
1. Planear la entrevista. Determinar que información se necesita recopilar.
2. Elaborar una guía para la entrevista (introducción, preguntas relacionadas con el tema). Elaborar una prueba piloto.
3. Seleccionar las personas que más conozcan sobre el tema.
4. Programar la entrevista. Planear el tiempo necesario para realizar la entrevista.
5. Ubicar un lugar apropiado para realizar la entrevista sin interrupciones.
6. Invitar al entrevistado, informarle del objetivo, fecha y lugar donde se realizará la entrevista.
7. Realizar la entrevista (sea puntual, cordial y desarrolle la guía para la entrevista, luego resuma y permítale al entrevistado hacer comentarios. Dele las gracias.)

LISTAS CHECABLES
CONCEPTO
Método, lista u hoja de información para lograr que nada se nos olvide ni se omita, en la cual la información consignada es de fácil análisis y verificación. Las podemos encontrar con diferencias sencillas y de tres tipos:
· Guías para la realización secuencial de operaciones, observaciones o verificaciones.
· Tablas o formatos para facilitar la recolección de los datos.
· Dibujos o esquemas para señalar la localización de puntos de interés.

USO
· Muestra una secuencia sistemática de hacer las cosas.
· Facilita la recolección de datos.
· Relaciona pasos o elementos que constituyen el todo de un proyecto o de una preparación.
· Proporciona un medio de seguimiento y control del avance de un proyecto.


Leer entrada completa | Make a Comment ( 3 so far )

Agile. La evolución de las metodologías tradicionales?

Posted on 9 febrero 2009. Filed under: Empresa, Gestión de Equipos, Gestión de Proyectos de Software, Herramientas Colaborativas, Herramientas, Métodos y Procesos, Metodologías de Desarrollo, Procesos Ágile, Project Management, Trabajo en Equipo, Uncategorized, Waterfall | Etiquetas: , , , , , , , , , , |

“Agile se ha vuelto tan popular entre los profesionales del software, que muchos se abstienen de criticarlo por miedo a ser etiquetados como “retrazados”, “de la vieja escuela”, o incluso “estúpido”.
Afortunadamente los profesionales IT con experiencia saben mejor y reconocen las limitaciones de Agile”

Así rezan las las declaraciones en un blog de Project Management, bastante conocido TheProjectManagmenteHut

Agile fue creado en gran parte en reacción al modelo predominante, WATERFALL, y en menor medida al resto de las tradicionales metodologías y aunque está en boca de todos y en manos de muchos, Agile hasta el día de hoy no ha demostrado ser superior a estas metodologías que le dieron razón y motivo para su existencia.
De hecho existe amplia y variada información que puede avalar tanto el éxito como el fracaso de las metodologías tradicionales, más su acoplamiento con los modelos y estándares de calidad reconocidos mundialmente y las culturas organizacionales más importantes del mundo, inclusive hablando de la industria del software.

Aunque no prentendo ser defensor de lo indefendible, ni “abogado del diablo” de Agile, es conveniente hacernos las siguientes preguntas:

  • cuando Agile es comparable con metodologías tradicionales?
  • cómo podemos combinar Agile con procesos tradicionales para abordar mejor una situación concreta?

Para responder a estas preguntas, es mejor reconocer las limitaciones de Agile

Un equipo de estrellas

Agile ha sido diseñado por experimentados y para experimentados.
Este es un aspecto a considerarse si se ha de intentar una incursión en las metodologías Agile, no como regla general, sino como un ítem de peso, sobre todo si se debe sostener el concepto de “equipo autogestionado”.

En lo personal y por la experiencia de participación en equipos Waterfall y en equipos en búsqueda de la agilidad, puedo decir que es mucho más dificil adaptarse a procesos Agile que a los procesos Waterfall, inclusive si se sigue un modelo de calidad como CMMI.

En los procesos Waterfall, el atributo de “equipos autogestionado” no es remarcable y aunque puede existir mucho trabajo individual, se hace bajo las premisas estrictas de la planificación, siguiendo los métodos y técnicas sugeridas y aceptadas por la organización. No se hace de otro modo o no lo estarías haciendo correctamente.

En estos procesos tradicionales, es cierto que existe también una gran carga administrativa pero en realidad no todos están afectados por ella y solo lleva una porción pequeña de tiempo y a muy baja complejidad realizarlas, principalmente para quienes no lideran los proyectos y solo rinden su progreso del día.

En los equipos Ágile, es un tanto más complicado la adaptación de las personas, siempre hablando de aquellas que no tienen la experiencia suficiente y el tren de trabajo disciplinado sin controles estrictos.
Aquí las entradas de algunos son fuertemente dependiente de las salidas de otros, no existe un trabajo individual o “individualista”, o no debería existir.

Las técnicas de gestión de tareas tradicionales pueden perder por completo su sentido y también debe existir una readaptación del mecanismo de estimación, de equilibrio de carga y del seguimiento. Los controles aunque parecieran ser menores, en realidad se incrementan por que el ciclo de vida en si mismo es mucho más corto y los cambios se presentan con mayor velocidad, pero parecieran ser de otra naturaleza y los resultados deben ser inmediatos, como también deben ser inmediatas las correcciones y a gran velocidad para que en la misma jornada laboral se tenga una aproximación del resultado, cuando no el resultado en si mismo.

El cáos está siempre al acecho…pero en que proyecto no lo está? La diferencia es la velocidad de detección de los inconvenientes, el análisis del problema y las soluciones, más su implementación, verificación y/o validación.
Entonces, preguntas simples pueden ser:

  • Tiene tu equipo el potencial para Agile?
  • Tienes el potencial para Agile?
  • Tienes la materia prima en las personas, para formar un equipo Agile?

Si la respuesta es “no” a algunas de estas preguntas, no significa que no puede transformase en Agile, solo quiere decir que puede haber algunos pasos intermedios a tomar antes de llegar allí.

Estos pasos suelen incluir la adaptación de la cultura del trabajo por equipos y la progresiva potenciación de los individuos, la formación y la contratación de las personas adecuadas.

Encaje con la cultura organizacional (los procesos son secundarios a la gente)

Habilitar el comportamiento Agile requiere de una gran dosis de libertad individual (no individualismo) y de equipo, que se traduce en una cruz funcional en constante adaptación del trabajo y funciones de conmutación, según sea necesario.

Se trata también de ajustar continuamente los procesos a fin de reflejar la situación actual. Más que nada, significa que los procesos son secundarios a la gente.

Otras organizaciones hacen incapié con estrechéz en los roles y responsabilidades, políticas y procesos, y han sido la clave de la supervivencia las mismas.

Aunque estas empresas estén bastante alejada de las dogmas de la agilidad, no es imposible que algunas unidades puedan realizar un trabajo diferenciado para experimentar, conocer y adaptar el nuevo paradigma.

Dado que la innovación es parte de la cultura de cualquier organización exitosa, entonces las personas que la integran tienen buenas habilidades y potencial para realizar “adaptaciones situacionales” y saltar de un modelo a otro.

Agile está restringido a equipos pequeños

  • Los equipos deben ser autogestionados, lo cual implica un orden eficiente emergente de un caos temporal. Este tipo de adopción del orden será mucho más prolongado en equipos grandes y perdería efectividad.
  • Los miembros del equipo de trabajo deben estar habilitados para comunicarse entre ellos espontáneamente, e inclusive con clientes y otros interesados en los proyectos.
  • La gestión diaria del equipo depende por completo de todo el equipo y no está centralizada en una sola persona. Es necesario el reconocimiento y visualización por parte de todo los miembros del equipo, de los cronogramas, tareas, cambios, impedimentos, etc.
  • Los miembros del equipo deben conocer exactamente que es lo que otros miembros están realizando, ayudar a otros que el proceso de su trabajo sea fácil, en forma colaborativa y sin un control centralizado.
  • Los miembros del equipo deben trabajar en la misma locación, facilitando el trabajo cara-a-cara y fortaleciendo los canales de comunicación inmediatos, sin tener las limitaciones típicas de las distancias, diferentes horarios e inclusive herramientas de gestión.

    Lo que se quiere expresar con estos puntos, es que equipos que superan un cierto límite en el número de integrantes (típicamente ocho) pierden eficiencia en las habilidades comunicacionales requeridas para equipos Agile. Así mismo la tarea de un Scrum Marster, se vería dificultada si tuviera que gestionar tareas, avances e inconvenientes de más cantidad de miembros y otros atributos como conocer las tareas y actividades entre todos los miembros se verían cada vez más en merma.

    Una forma de adaptación de equipos mucho más grandes, sería la división del mismo en equipos cross-funcionales más chicos y dinámicos.

    En este sentido necesariamente se deberá contar con un “nivel de gestión superior” que permita centralizar la información de todo el proyecto. Sin duda esto está lejos de ser puramente Agile, sino más bien una combinación de metodologías tradiciones y agilísmo.

    Hay que tener en cuenta también que si se divide un proyecto grande, se minimiza la dependencia arquitectónica del proyecto, para pasar de una medición del avance típicamente medido por su avances arquitectónicos, a una medición basada en la entrega de características funcionales. Esto da como resultado que la definición de “progreso” de Agile, deba ser adaptada a un nuevo contexto con un nivel de gestión superior.
    De nuevo la adaptación situacional “es un buen jugador”.

    Una gran limitación tiene que ver justamente con el especto comunicacional, dado que Agile promueve la comunicación cara-a-cara, con resoluciones dinámicas y proactivas, sin documentación más que la que oriente al desarrollo.

    El trámite comunicacional con otrás áreas es un trastorno que Agile debe aprender a dominar, puesto a que los modelos agilístas actuales exigen que otros interesados del proyecto deban siempre estar en la misma locación de trabajo, inclusive evitandose el traslado desde una oficina a otra para realizar simples consultas.

    La tecnología colaborativa y de multimedios, permiten actualmente realizar trabajos perfectamente coordinados y con esquemas de reuniones cara-a-cara, aunque virtualizadas, muy eficientes. Sin embargo esto no está bien aceptado en el mundo actual del agilísmo.

    Donde está mi metodología?

    Metodologías de desarrollo de software, tradicionalmente incluyen procesos como, Análisis, Arquitectura, Implementación, Gestión de Proyecto, Gestión de la Configuración, Gestión de Riesgos, Gestión de Cambios y una larga lista de procesos dependientes de Áreas de Procesos y Grupos de Procesos. Sin embargo, las metodologías

    Agile no promueven estos grupos de procesos y de hecho no los definen para sus marcos de trabajo, como tampoco definen un marco de gestión de proyectos.

    Esto puede verse justificado por el hecho de que las metodologías Agile tienen como insignia, que lo que demuestra y garantiza el proceso es el producto entregado y no la documentación que puedas presentarle a tu cliente.

    Las metodologías Agile delinean un marco conceptual, pero no explicitan de ninguna manera la exclusión de alguna de las prácticas tradicionales, aunque se asume que solo sobrevivirá lo estrictamente necesario para la obtención de los incrementos (entregables de software)

    Metodologías Agile completas parecen estar emergiendo y el soporte a la organización podrías ser total con adaptaciones sencillas de ambos metodologías, donde la substracción de las buenas prácticas de ambas, de como resultado el éxito y calidad total de la organización.

    Dado el contexto planteado es que me hago las siguientes preguntas para reflexionar:

    • ¿Existe la evolución de las metodologías Agiles?
    • ¿Surgieron por si solas o son adquiridas y formadas en reacción a la complejidad propuesta por las metodologías tradicionales?
    • ¿Las metodologías Agiles de alguna nueva generación no serán en si mismas las adaptaciones y evoluciones de metodologías tradicionales?
    Leer entrada completa | Make a Comment ( 3 so far )

    Agile Open Córdoba – El EVENTO que se viene en Argentina

    Posted on 6 febrero 2009. Filed under: Gestión de Equipos, Gestión de Proyectos de Software, Ingeniería del Software, Procesos Ágile, Trabajo en Equipo |

    Agile Open Córdoba 2009

    ¡Ya podés inscribirte en Agile Open Córdoba 2009!

    “¿Y por qué querrías hacerlo?”, te preguntarás.

    • Porque nos juntaremos 100 personas con muchas ganas de implementar metodologías ágiles en nuestros trabajos
    • Porque tu participación será activa, con el formato Open Space
    • Porque lo organizamos de manera tal que te permita asistir sin depender de otros (gratuito, fuera del horario laboral, en un lugar de fácil acceso)

    Fecha: 17 y 18 de abril, 2009

    Horarios (a confirmar)
    Viernes  17 de 18:30 a 21:00 Hs.
    Sábado 18 de 10:00 a 18:00 Hs.

    Tema: Implementando Metodologías Ágiles

    Sede:
    Colegio Universitario IES Siglo 21
    Buenos Aires 563
    SUM – Salón de Usos Múltiples (a confirmar)

    Contacto: por consultas o sponsoreo, comunicarse con eventos en agiles.org

    Además, y dentro del marco de este evento, se dictará por primera vez en Córdoba el curso de Certificación Scrum Master (CSM), con reconocimiento oficial de la Scrum Alliance.
    Ud. puede registrarse para realizar este curso aquí.

    Leer entrada completa | Make a Comment ( 2 so far )

    QA & Testing en SCRUM

    Posted on 24 enero 2009. Filed under: Actitudes, Aptitudes, Calidad del Software, Comunicación, Entorno de Pruebas, Gestión de Equipos, Gestión de Proyectos de Software, Herramientas Colaborativas, Herramientas, Métodos y Procesos, Ingeniería del Software, Metodologías de Desarrollo, Opinión, Organización del Trabajo Personal, Procesos Ágile, Project Management, Soporte Colaborativo, Testing, Trabajo en Equipo | Etiquetas: , , , , , , |

    Estimado tester del mundo,

    Dando vueltas por “la red” veo repetidamente tus preguntas que reniegan de las metodologías Ágile, principalmente de  SCRUM:

    “¿Cómo es posible que me digas que las iteraciones deben ser tan cortas? ¿si una iteración dura cuatro(4) semanas, tres (3) serán de desarrollo y una (1) de testing? ¿como se gestionan los defectos? ¿como es la comunicación en la gestión de defectos en proyectos Ágile? ¿si los desarrolladores deben continuan codificando los próximos incrementos, cuando corrigen los defectos? ¿cuando se los verifica?

    NO ME QUEDAN CLARO LOS CICLOS!!!”

    Como te habrás dado cuenta no obtuviste respuestas concretas ni en los mejores foros estos últimos dos años. Eso es así por que QA no tiene una definición concreta y formal en los entornos Ágile y me arriesgo a decirte que en SCRUM no está bien estipulado como es el proceso de testing y calidad.
    Leí varios libro sobre agilísmo y en todos ellos dicen “la calidad no se negocia”, pero en ninguno de ellos explican como evitan la merma de calidad con iteraciones tan cortas, o dicho de otra manera, como la obtienen y garantizan.

    Alguna respuesta lógica podría ser:

    1. la intervención temprana del equipo de testing en el ámbito del proyecto.
      Esto quiere decir que hay que apartarse de la idea de esperar a que los requisitos estén maduros para tomar el documento de requerimientos y realizar el diseño de casos de pruebas. En este tipo de metodologías, debemos tener en cuenta la mutación de requerimientos, como también la eliminación de algunos de ellos y la aparición de nuevos en tiempos muy cortos.
      Aquí debemos ingresar en el preciso momento en el que nace un requerimiento, es decir cuando el requerimiento es expuesto al equipo. Nuestra fase de análisis comienza al mismo tiempo que para el equipo de desarrollo.
      Prontamente estaremos en la fase de diseño de las pruebas, donde también es extremadamente dificultoso ser veloces y preciso con iteraciones tan cortas. Es debido a ello que verás muy pocas propuestas serias para trabajar, aunque hoy en día se están abriendo paso…
    2. …herramientas colaborativas donde los encargados de indicar criterios de calidad, criterios de aceptación, modos de fallos, modos de prueba y demás, son todos los miembros del equipo e interesados.
      Esto es así dado a que la industria se dió cuenta que las mejores pruebas las hacen nuestros clientes y en todo el ciclo de vida de un requisito, los distintos tipos de analistas (negocios, requerimientos, sistemas, soporte, pruebas) representan algún aspecto de los clientes, aunque no todos.
      Estas herramientas ayudan a…
    3. … automatizar el proceso de desarrollo, donde la generación del requisito es el inicio natural, pero está acompañada su evolución por aspectos de la gestión de proyectos, tales como criticidad y priorización, estimaciones, asignaciones, control de cambios, control de estados, gestión de recursos, desvíos, replanificación y métricas. Todos elementos para sostener un curso razonable de la calidad del proceso y del proyecto.

    En relación a tus preguntas te diría que:

    • Tres semana de desarrollo y uno de testing es posible. Debes contar con los recursos necesarios y adecuados. El problema aquí nuevamente es la planificación del testing y la calidad.
      ¿tendrás tiempo de planificar algo que garantice cobertura sobre los requerimientos? dificilmente del modo tradicional.
    • Mientras se hace testing los desarrolladores codifican. Para eso están, salvo que también sean testers, ya que aunque está mal visto en los paradígmas tradicionales, puedo asegurar que visto con un pensamiento lateral es positivo, imprime rítmo, genera velocidad y ayuda al crecimiento técnico del equipo QA.
      También adoptan perspectivas diferentes que le ayudan en sus próximos enfoques para el desarrollo de las soluciones.
      Tiene sus aspectos negativos que se pueden ir puliendo. Por ejemplo un desarrollador que eventualmente pasa a testing, al detectar un defecto lo analizará desde el aspecto que más conoce. Querrá acceder a la base de datos y debaguear el código, y si fuera posible corregir y recompilar inmediatamente.
      Bueno, eso también lo hemos hecho, pero en otras situaciones, por ejemplo cuando se hace la verificación de las correcciones de defectos.
    • Particularmente yo me salto “el aparato comunicacional” y  digo al desarrollador: “master, tengo un defecto persistente. Que te parece mirarlo juntos y resolverlo de buenas a primera?”
      La herramienta de gestión de defectos es como cualquier otra o como una planilla Excel si lo quisieras llevar a extremos precarios (habrá quienes me discutan lo de precario por Excel) y en ocaciones suele ser una importante barrera comunicacional burocrática, puesto a que nuestros defectos deben “atravezar el espacio-tiempo” mientras esperan ser atendidos. Yo prefiero la interacción y la proactividad, inicialmente hablar con quien lidera el proyecto mostrando los defectos detectados, dándole información precisa y concisa, ayudándole a priorizar su resolución y a medir los impactos.
      También interactuo con los desarrolladores planteándoles un modo de uso, uno modo de fallo, un modo de prueba y ayudando a desarrollar una mejor solución.
    • Al respecto de cuando se solucionan los defectos, opino que no es buena cosa pasar a un próximo ciclo de desarrollo si no se cerró el anterior. De manera tal que decir que tenemos un incremento va ligado de la frase “está hecho!!!”.
      Sin embargo en la vida real, notarás que es común iniciar la próxima iteración antes de corregir todos los defectos. Esto será válido si el incremento desarrollado fue aceptado por el cliente (Product Owner) aún a sabiendas de los defectos de la entrega.

    Como elemento QA debes ser lo suficientemente analítico para iniciar el ciclo de vida de los proyectos, estudiando los requerimientos, detectando sus falencias, investigando modos de pruebas y modos de fallos. Mientras tanto deberás ir generando los criterios de aceptación funcional, generando un modelo de pruebas y si tuvieras el tiempo, los casos de pruebas.

    También será menester gestionar los ambientes de pruebas netamente funcionales, aislados de accesos a bases de datos e IDEs de desarrollo, ya que lo que se pretende al menos en las pruebas de funcionalidad, es utilizar el sistema como lo haría nuestro cliente final, pero con mucho más rigor.

    Entonces, como verás hay muchísima tela para cortar al respecto. Solo hemos “tocado por encima” algunos aspectos QA & Testing. Imagina si tenemos que hablar de pruebas unitarias, de componentes, de integración, métodos y técnicas…. en fin.

    Lo cierto es que SCRUM es solo una metodología de gestión de proyectos, bien sinérgica, orientada a equipos maduros, autogestionados, con altísimos conocimientos técnicos, con gran dominio del negocio que genera los requerimientos y no pretende indicar como se hará el arte de desarrollar, ni de probar, mucho menos se hará de conceptos para el mundo QA & Testing.

    Saludos,
    Javo.

    Leer entrada completa | Make a Comment ( 2 so far )

    El entrenamiento

    Posted on 21 enero 2009. Filed under: Actitudes, Aptitudes, Artículos sueltos, Capacitación, Empresa, Gestión de Equipos, Habilidades Personales, Liderazgo, PNL y Coaching, Plan de Acción | Etiquetas: , , , , , |

    Alberto Herreros, el por entonces capitán del Real Madrid de Baloncesto, estaba en la línea de tiros de tres puntos esperando el balón. Era la final de la liga. El quinto partido del playoff para el título de la liga ACB. El Real Madrid jugaba en el campo del TAU, en Vitoria, y durante todo el partido había estado por debajo en el marcador. Faltaban sólo seis segundos para que se acabara el partido. Alberto no había jugado mucho tiempo en la serie final. De hecho en ese partido había salido solo unos minutos antes. Muy probablemente sería su último partido en el equipo. A falta de cincuenta segundos el Real Madrid perdía por ocho puntos, pero una remontada de infarto había situado al equipo con una marcador de 69-67. Un triple daría la victoria y la liga a su equipo. Y Hamilton se acerca a él en la banda derecha y le deja la patata caliente. El último balón: “tíralo tú si te atreves”, debió pensar. Y Alberto no se lo pensó. Tal y como recibió el balón, se levantó y tiró. Y encestó. Y el Real Madrid fue campeón de liga.

    ¿Qué hace que un jugador no falle en esas circunstancias? Se podría decir que hay un factor de azar, un factor de suerte. Un buen amigo dice que la suerte no es más que la planificación de todos los detalles. Y yo apelo a la planificación. Al cuidado de los detalles. Es evidente que nadie en su sano juicio deja las cosas importantes al
    azar, al destino, salvo que no le importe. En general, a los directivos les importan sus empresas, y a sus dueños también.

    La diferencia está en el entrenamiento. Alberto Herreros habrá tirado más de 5.000 tiros de tres puntos en todos los partidos que ha jugado, pero habrá tirado muy probablemente más de 50.000 en los entrenamientos. Por eso, en el preciso momento que lo necesitó, salió la mecánica de tiro perfecta, aquella que ha ensayado horas y horas en los entrenamientos.

    ¿Qué pasa en la empresa? ¿Entrenamos? El equivalente al entrenamiento en la empresa es la formación. Formación en habilidades, en nuevos conocimientos, en nuevas herramientas…

    Formalmente podemos entender por formación en la empresa un conjunto de actividades planificadas, cuya finalidad es adquirir, mantener, modificar, y desarrollar las competencias profesionales de los recursos humanos de la empresa. Desde esta amplia perspectiva, la formación en la empresa cumple un doble cometido. De una parte trata de proporcionar al personal las competencias profesionales necesarias para la adecuada realización de su trabajo y por otra parte, trata de mejorarlas y adecuarlas a los requerimientos derivados de los cambios que, a ritmo acelerado, suelen producirse en el entorno empresarial.
    Este es el mismo cometido que tienen los entrenamientos en los equipos. Sólo así se puede llegar a una situación complicada y que a uno no le tiemble el pulso. A lo largo de los años que llevo formando equipos comerciales lo he podido ver con claridad.

    La gente aprende entrenando. Se quita el miedo a hablar en público entrenando, se quita los temores de la negociación con el entrenamiento, es consciente de sus errores en la gestión de equipos cuando entrena. Y si es tan importante el
    entrenamiento en la empresa, en los equipos, ¿por qué es el primer presupuesto que se recorta cuando vienen malos momentos? ¿Alguien se imagina a un equipo de fútbol, de baloncesto de primer orden eliminando las horas de entrenamiento cuando las cosas no van bien, cuando no se obtienen buenos resultados? En ese caso, lejos de reducirse, se duplican.

    Deberíamos aprender esta lección. Si le importa el destino de su empresa, si quiere que su equipo sea mejor, que obtenga mejores resultados, no recorte en formación, no recorte en entrenamientos. La formación no es un gasto. Es la mejor inversión que puede hacer por su empresa, por sus accionistas, sus empleados y por usted mismo.

    Sólo así cuando un jugador de su equipo esté ante una situación crítica de cuyo éxito dependa el contrato clave para su empresa, tendrá garantías de que no le temblará la mano. Tirará su triple y lo meterá.
    Y los demás nos alegraremos por usted. Habrá hecho bien su trabajo.

    De © Raúl Castro extraído de XING del Newslater de grupo “Argentina País Emergente

    Leer entrada completa | Make a Comment ( Comentarios desactivados en El entrenamiento )

    Predictivo contra adaptativo?

    Posted on 20 enero 2009. Filed under: CMMI, Gestión de Proyectos de Software, Ingeniería del Software, Metodologías de Desarrollo, Procesos Ágile, Project Management, Waterfall |

    CMMI indica que una organización evaluada en nivel 3, es una organización con proceso DEFINIDO, es decir que la organización cuenta con una base de conocimientos que le permite gestionar proyectos cuyas decisiones sobre alternativas de solución técnica, tiene una tendencia histórica organizacional.

    Una organización cuyo proceso está definido, indica a su vez que ese proceso esta sustentado por documentación reutilizable, prácticas repetibles y métricas objetivas para la consecución de resultados concretos.

    Poder predecir es algo que todo administrador de proyectos desea y debe hacer. Entonces, ¿por que negarnos a los elementos que facilitan y favorecen tal característica primordial de maduréz en la organización?

    PREDECIR es el primer nombre del administrador de proyectos.

    Predecir no es perder la capacidad adaptativa, no significa evitar la introducción de cambios en los requisitos, ni evitar que nuevos requisitos surgan, tampoco es ser rígido con una replanificación.

    Claro no es tan simple ser predictivo, pero mucho menos lo es ser adaptativos. De hecho, pienso que no se puede ser adaptativo sin ser predictivo o más bien serás intuitivo, pero mejor atenerse a los resultados fortuitos.

    Sin duda el esfuerzo del cambio es superior, pues la organización deberá adquirir conocimientos sobre las prácticas para los procesos que hay que implantar:

    * Desarrollo de requisitos * Solución Técnica * Integración del producto * Verificación * Validación * Desarrollo y mejora de los procesos de la organización * Definición de los procesos de la organización * Planificación de la formación * Gestión de riesgos * Análisis y resolución de toma de decisiones.

    Ahora, ¿alguno de ustedes ve un proceso de los que menciona CMMI para el nivel 3, diferente a los procesos que se utilizaría en Ágile?

    Leer entrada completa | Make a Comment ( 1 so far )

    Gestión de Incidentes & Help Desk – cadena de atención de incidentes

    Posted on 19 enero 2009. Filed under: Consultoría IT, Gestión de Soporte y Mesa de Ayuda, Herramientas Colaborativas, IT, IT Management, Plan de Acción, Resolución de Problemas y Gestión de Incidentes, Technical Leader, Trabajo en Equipo | Etiquetas: , , , , , |

    Los actuales modelos colaborativos, permiten que la organización entera tenga visibilidad de los incidentes, problemas y fallos de los productos y servicios que ofrecen. Estos modelos hoy incluyen a los usuarios/clientes como
    parte fundamental del motor de soluciones.

    En el ámbito del soporte y mesa de ayuda de nuestras organizaciones, existen herramientas que han sido diseñadas con obejtivos precisos y claros. Tales herramientas pueden estar modularmente divididas y así, en módulos externos permitir a un grupo de usuarios realizar pedidos en base a categorías que la organización puede atender.

    En la mayoría de las situaciones estos pedidos de los usuarios no se hace de manera directa, es decir utilizando puntos de accesos directos a quienes desarrollan los productos y las soluciones.
    Esto naturalmente es así, puesto a que sus pedidos suelen ser ponderados incialmente por analístas de negocios y comerciales, quienes no solo tienen facultades especiales para dar peso a los distintos requisitos, sino que entienden las necesidades organizacionales y cuidan intereses que ciertas áreas desconocen.

    De manera tal que generar puntos de accesos directos a los desarrolladores es posible pero con ciertas precauciones fundamentales.

    Por ejemplo, implementar formularios de registración de incidente del usuarios, donde el mismo cliente/usuario puede dejar su inquietud, es parte de una estrategia de obtención de información, la cual será convenientemente registrada, evaluada y tratada.  Otros sistemas tal vez requieren de la activa participación de terceros, como operadores humanos o automáticos que transfieren los pedidos a otras áreas donde se desmenuza el requerimiento, se lo analiza, se detecta y reconoce el problema, se estima la solución, se pondera el tiempo y se desarrolla dicha solución.

    Mientras tanto es posible que el usuario no tengo una resolución inmediata y deba esperar o insistir con su inconveniente.

    Aún en pequeñas organizaciones, es crítico definir una cadena de atención de incidentes que considere un cierto orden en la registración de los incidentes, una categorización que indique su tipo, una categoría que indique su importancia e inmediatéz, un reconocimiento incial del problema,  alternativas de solución técnicas, una estimación del tiempo de resolución, su correspondiente verificación de calidad, la implantación de las soluciones y su validación.

    No debemos olvidar que estos son elementos únicos de nuestra base de conocimientos.

    Es por lo tanto en extremo relevante la utilización de un lenguaje común, estándar y unificado, para sostener un hilo conductor comunicacional de principio a fin.

    Esta visibilidad justamente lo que exige es, que las acciones sean perfectamente encadenadas desde un principio
    hasta un fin óptimo tanto para el usuario/cliente, como para la organización.

    Esta es una de las causas por la cual no es bueno que las áreas de desarrollo y operaciones tengan capacidad de acción directa sobre los incidentes y se justifique el que otras personas deban intervenir previamente.

    Es así como las herramientas potencian la visibilidad del contexto global para cada uno de los ítems registrados y puden evitar que inicidentes se transformen en problemas y que problemas lleguen a nuestros clientes y que aquellos que ya existen, puedan ser solucionados eficientemente.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Gestión de Incidentes & Help Desk – cadena de atención de incidentes )

    Palabras importantes o como crear confianza hacia el líder

    Posted on 2 enero 2009. Filed under: Actitudes, Habilidades Personales, Liderazgo, PNL y Coaching, Roles, Trabajo en Equipo |

    Reconocer los errores propios

    Reconocer que uno no sabe de todo, que no es infalible, que no siempre lleva la razón, que necesita a los otros, es una magnífica oportunidad de acercarse a los suyos.

    Felicitar en público aquellas cosas que se han hecho bien

    Dejar los reproches para el ámbito privado, reconocer la valía de las personas y pedir opinión ayuda a resolver muchos sencillos problemas cada día.

    Pida opinión y habrá ganado a un fiel colaborador
    La persona que trabaja en algo generalmente es la más cualificada para solucionar un problema en su ámbito.

    No tema parecer desinformado o sin conocimientos

    No debe conocer ni dominar todos los ámbitos.  Consulte, muestre que necesita información y busca conocimientos. Si lo hace reforzará su imagen de ser falible, y dará su minuto de gloria a una persona de la organización. Si además, una vez tomada la decisión, le pide su opinión sincera y luego le da las gracias, el resultado será formidable. Ellos a su vez lo harán con las personas que tengan a su cargo, por lo que de su ejemplo, habrá obtenido una reacción en cadena que muy probablemente llegue hasta el último escalón de su organización.
    Eso va creando cultura y confianza en la empresa y en su líder.

    Use siempre estas “palabras importantes”

    La seis palabras más importantes: Reconozco que he cometido un error.
    Las cinco palabras más importantes: Estoy muy orgulloso de ti.
    Las cuatro palabras más importantes: ¿Cuál es tu opinión?
    Las tres palabras más importantes: Si te parece.
    Las dos palabras más importantes: Muchas gracias.
    La palabra más importante: Nosotros.
    La última palabra y la menos importante: Yo.

    Extraído del Newsletter del Grupo Newsletter del Grupo Argentina País Emergente. Tiempo para Decidir. 9º entrega “Liderar con el ejemplo”

    Feliz año, feliz vida!

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Palabras importantes o como crear confianza hacia el líder )

    CMMI/Agile. Un híbrido que se viene – I

    Posted on 23 diciembre 2008. Filed under: Calidad del Software, CMMI, Gestión de Proyectos de Software, Herramientas, Métodos y Procesos, Metodologías de Desarrollo, Testing, Trabajo en Equipo | Etiquetas: , , , |

    He sido participe de certificaciones CMMI 4 en una empresa del Cluster Informático de Córdoba en Argentina y actualmente estoy como Responsable de Calidad y Mejora de Procesos en una empresa donde intentamos implantar metodologías ágiles.

    Conceptualmente son dos modelos distintos en cientos de aspectos, siendo imposible considerarse ágil al modelo CMMI.

    Quiero ser tajante en la diferenciación de esto, pues ahora se habla mucho de CMMI Agile y tal concepto no es más que un híbrido y no está formalizado. Esto es así, por que habría que decidir que parte de CMMI utilizamos y que proceso de los existentes tomaremos para recoger lo mejor de los ágiles.

    Notemos que los frameworks que la gran mayoría de las empresas ofrecen, se enfocan en uno u otro modelo.

    Pero vamos a ejemplos vivos. Bajo CMMI, siendo líder de testing, no tenía más participación que la ejecución de las pruebas, previo planning encapsulado y siguiendo una estricta ERS, no era partícipe a nivel horizontal del planning inicial y los criterios de calidad no se establecían por el líder de testing sino hasta que la documentación tuviera ya un alto grado de definición (documento maduro) e inclusive la participación de mi rol seguía siendo escueta y debía tomar los criterios establecidos por el arquitecto.

    Posteriormente, en CMMI, los cambios de requisitos no son aceptados con la amplia libertad con la que son aceptados en un proceso ágil y por lo general deben ser de bajo impacto para que ingresen en el catálogo de requisitos y siempre bajo un estricto circuito de análisis y revisiones de un comité de cambios, el cual está formado por una cantidad de personas y roles que en empresas que pueden seguir un proceso ágil, no hay.

    Las reuniones (ICE) en CMMI tienden a ser verticales y la participación de los roles transversales no es tan significativa como lo es en un proceso ágil, es decir que las decisiones normalmente pasan por una situación elitista donde desarrolladores y testers no tienen una grandilocuencia aceptada. Esto se contrapone con el precepto que indica que para ser ágil se debe tener un fuerte énfasis en las pruebas sobre la aplicación que se desarrolla y una continua integración de sus componentes.

    Con esto no pretendo decir que en CMMI no se tenga énfasis en las pruebas, pero se llega a ser tan robótico que la creatividad se destruye y proyecto tras proyecto tienes la misma documentación, los mismos estilos de pruebas, los mismos resultados y esto ya da para la desconfianza.

    En procesos ágiles debes anticiparte por eso participa todo el equipo de pruebas en las primeras reuniones donde se definen criterios de calidad, métodos de pruebas posibles, modos de fallos y otros elementos que puedan definir mejor la calidad de los productos. Recuerdo que trabajando bajo el proceso CMMI todo esto me venía llovido, y se suponía que el líder del testing era yo, un elemento SQA.

    Otro precepto que aleja CMMI de ágile (keep it simple).

    Uno más, documentar solo lo estrictamente necesario y centrarse en lo más crítico del producto, que es el código fuente.

    Por otro lado y para ir cerrando al menos este post, si un híbrido CMMI-Agile debe existir, ya sabemos que partes podemos tomar de CMMI según su nivel, pero… ¿que parte de Àgile tomamos? ¿Programación Extrema, Scrum, DSDM, Crystal Clear, …?

    Hablando de Framworks, hay algunos que ofrecen la posibilidad de trabajar con una metodología Ágile con documentación formal y que mediante un esfuerzo (considerable) se podría alcanzar un nivel CMMI-3 en el mejor de los casos, utilizando otra parte del mismo Framework. Es más complejo que eso.

    Pero aqui me acoplo a lo que algunos dicen por la red. Lo más importante que toda organización o persona debe tener en cuenta, es que no existe una metodología ideal para cualquier escenario en la que se aplique. La metodología de desarrollo que se seleccione, bien sea ágil o no, siempre dependerá directamente del equipo de trabajo, la cultura organizacional, lo cambiante del medio ambiente y la aceptación del usuario final.

    Leer entrada completa | Make a Comment ( 4 so far )

    Quien es quien – II

    Posted on 23 diciembre 2008. Filed under: Actitudes, Aptitudes, Artículos sueltos, Recursos Humanos, Roles, Trabajo en Equipo |

    Que opinan de esto?

    Es algo que encontré WEBEANDO y me pareció muy gráfico.

    Algo que nunca aprendo es que debo guardar las URL de referencia. Lo siento pero esta vez no lo hice y google no me ayudó mucho tampoco y solo puedo dirigirlos a un buén grupo de discución donde mostré este mismo “artículo suelto”

    1. Gestor de proyectos es aquel que piensa que nueve mujeres pueden traer un bebé al mundo en un mes.

    2. Desarrollador es aquel que piensa que toma 18 meses traer un bebé al mundo.

    3. El empresario es aquel que pretende que una sola mujer puede traer nueve bebés al mundo en un mes.

    4. Cliente es aquel que no sabe por qué quiere traer un bebé al mundo.

    5. Manager de marketing es aquel que piensa que puede traer un bebé al mundo incluso si no hay hombres ni mujeres disponibles.

    6. El equipo de optimización de recursos piensan que no necesitan un hombre ni una mujer, ellos traerán un bebé al mundo con cero recursos.

    7. El equipo de documentación piensa que a ellos no les importa si se trae un bebé al mundo, ellos sólo documentarán nueve meses.

    8. El encargado de SQA es aquel que nunca está contento con el proceso de traer un bebé al mundo.

    9. El tester es aquel que siempre le dice a su mujer que ese no es el niño definitivo.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Quien es quien – II )

    Quien es quien – I

    Posted on 22 diciembre 2008. Filed under: Actitudes, Aptitudes, Habilidades Personales, Metodologías de Desarrollo, Opinión, Recursos Humanos, Roles | Etiquetas: , , , , , |

    Pensando los Roles y Competencias para definir nuestro proceso de trabajo

    Las metodologías de desarrollo de software suelen establecer roles y delimitar sus competencias,  remarcar sus responsabilidad, indicar interdependencias, definir elementos de entrada-salida y proponer la repetición constante de estos ítems, con variantes que le dan alguna particularidad a los distintos procesos.

    El objetivo es inicialmente presentarse de manera clara al publico usuario, como un mecanismo  estable, controlable, medible y repetible, que garantice en mayor o menor medida, el éxito de los proyectos permitiéndole llegar a su fin, con el uso de la secuencialidad propuesta.

    Suele suceder que los modelos parecieran no tener en cuenta al área QA y Testing como un área independiente dentro los proyectos de productos/servicios, que genera su propio proyecto donde conviven productos/servicios que dan soporte al proyecto matríz.

    Tal es así que las competencias QA y Testing no son tan bien definidas  y explicadas como las compentecias de otros roles, en la mayoría de los procesos. Y aunque algunos presentan detalles excesivos, quizás no encuadran correctamente a los roles QA.

    Independientemente del proceso que se intente aplicar y su definición de roles y competencias, sugiero que las organizaciones consideren la aplicación de roles, pero justificado principalmente por el enfoque y especialización que exista o se desee.

    Por ejemplo, la existencia de Líderes de Proyectos que a su vez sean verdaderos especialístas en los negocios que generan los productos que lideran.

    Los Arquitectos de Sistema los mejores diseñadores y programadores, sobre todo líder especialista en “los aspectos íntimos de los sistemas”.

    El Líder QA de perfil analítico transversal y el principal
    “entrenado” en el uso de los productos en prácticamente todos los
    niveles de los sistemas. También uno de los probadores más
    importantes de la organización, guía de pruebas en todas las fases de revisión.

    El equipo de testing  con competencias técnicas variadas y acabadas, conocedores de técnicas y métodos de pruebas, pero con grandes atributos actitudinales.

    Las principales potencias de un equipo QA bien conformado quizás son:
    capacidad analítica en el sentido transversal a lo que se supone como
    la mejora solución técnica, la obsesión por demostrar que el sistema
    tiene defectos, orientación bien marcada a las pruebas exploratorias,
    proactividad y comunicación eficiente, entrenamiento anticipado en el
    uso del sistema, énfasis en detectar debilidades en los requerimientos, énfasis en reconocer y entender por que y para que existe cada requerimiento, capacidad de proponer nuevas alternativas de uso, control del tiempo y el sentido de fin de fases.

    Creo que habilidades de esta naturaleza no solo en los roles QA, sino en otros que reciben productos de fases anteriores y las destilan a fases posteriores en los procesos de desarrollo, ayudan a definir un proceso bien limpio y delimitado para elaborar, planificar, seguir y finalizar los proyectos.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Quien es quien – I )

    CMMI/Agile. Un híbrido que se viene – II

    Posted on 22 diciembre 2008. Filed under: CMMI, Gestión de Proyectos de Software, Herramientas, Métodos y Procesos, Ingeniería del Software, Metodologías de Desarrollo, Opinión, Procesos Ágile, Project Management | Etiquetas: , , , , |

    Tratando de continuar con la saga CMMI/Ágile,  diré que creo que si tenemos en claro que CMMI es el modelo del proceso de desarrollo a seguir y Scrum es el modelo de gestión, entonces en teoría no habría discrepancias ni razones de frustración a la hora de intentar gestionar con Scrum mientras se siguen las prácticas sugeridas por CMMI.

    Sin embargo Scrum se plantea con un conjunto de prácticas bien definidas, que bien podrían no ser compatibles con las prácticas CMMI, las cuales desde un principio parecieron ser mejor adaptadas a RUP y las “gestiones pesadas” con prácticas al estilo PMBOOK.

    Habría que plantearse si eso de ligar a CMMI con RUP, PMI o procesos Waterfall, no es un fallo conceptual, puesto a que en realidad CMMI no plantea restricciones al respecto del modelo de gestión de los proyectos.

    En cierto aspecto, lo interesante es tratar de respetar toda la metodología de gestión Scrum y sus roles, mientras se respetan las exigencias de los roles CMMI.
    Creo que aquí es donde nos damos cuenta de la necesidad de nuevos significados para las cosas y reestructuración de los modelos, si es que los mismos debieran sostener su vigencia.

    Por ejemplo yo partiría los roles en dos capas:

    • una capa de nivel “No Operativa” o administrativa donde por ejemplo, el Product Owner sería todo el Stakeholder de capa superior de los roles exigidos por CMMI (Gerencia, Gerencia Senior, Sponsor, Representante del Cliente, y Gerente QA)
    • una capa “Operativa” donde encontraríamos por ejemplo, al Team (Líder de Proyecto, Arquitecto de Sistemas, Líder de Testing, Testers, Desarrolladores) todos gestionados con Scrum, donde Scrum Master sería necesariamente el Líder de Proyectos.

    Ahora bien, solo estamos hablando de gestionar roles, pero habría que profundizar en las similitudes y diferencias de las prácticas sugeridas o impuestas para cada rol y PA por cada modelo.

    A mi entender por más que se gestione con Scrum, el proceso ya no sería puramente Ágile ni puramente RUP sino uno de los “hibridos que se vienen”.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en CMMI/Agile. Un híbrido que se viene – II )

    Quien es quien – III

    Posted on 5 diciembre 2008. Filed under: Comunicación, Habilidades Personales, Opinión, Recursos Humanos, Roles, Trabajo en Equipo |

    Aunque causan gracia, es cierto que un mismo equipo de proyecto se puede ver con claridad a personajes que cumplen a rajatablas con procesos, etapas y pseudo etapas. Otros no tanto y algunos ni…

    A modo de ejemplo y para reírme de mi equipo les cuento:

    Líder de Proyecto

    Más bien parece un Gerente de QA imponiendo a latigazos de lengua y soberbia, el rigor del proceso. Obviamente con efectos contrarios. Bien prendida a una montaña de templates, checklist y cuadernos de anotación más las herramientas informáticas de gestión de las que ya dispone.
    Castiga y no premia, negocia su futuro con 14 horas en la oficina y 4 horas más de trabajo en su departamento.
    Se enteró ayer que tiene un hijo de 2 años y un marido, cuando al llegar ambos reían y jugaban con la empleada doméstica.

    Arquitecto de Sistema

    La mayor parte de los días es Peter Pan negándose rotundamente a cargar sus avances de actividades, demorando eternidades aquellas actividades asignadas con apenas horas de duración estimada, renegando permanentemente de la matriz de rastreabilidad, proponiendo cada media hora la eliminación de algún documento formal, y peleando con el área de QA como si de un deporte se tratara.
    Para el colmo delega tareas de revisión por pares dando instrucciones precisas de como debe ser el resultado de su revisión (llevada a cabo por otro) y por supuesto Testing no existe, salvo el unitario. Se conoce todos los procedimientos y procesos existentes, opina siempre en sentido contrario aunque la otra persona haya dicho lo mismo con otros términos.
    Los workshop de 30 minutos con el duran 1.30 horas, solo está de acuerdo con lo que tiene que ver con sus criterios de medición y por lo general solo se refiere al código que el generó o del que se hizo cargo. El resto es mala palabra o esta mal, o el que lo hizo “es un muerto“. El resto del tiempo es chating.

    Desarrollador Líder – Desarrollador Estrella

    Me resulta definir su estado, pues el muchacho esta siempre bien dispuesto, revisa con exagerada motivación cada uno de los componentes de su actividad y de las que le fue delegada por su Arquitecto de Software, critica en forma constructiva el código que genera, el código que modifica, la arquitectura del sistema y de hecho tiene un umbral de conocimientos muy alto que cuesta definir que cosa no sabe.
    Sin embargo no esta conforme con lo que hace, quiere cambiar a otra empresa y ya van cinco en dos años, no le apetece la cultura actual y creo que sueña con ser la estrella de una empresa estrella. Debe de tener aires de superioridad, pero es buen compañero y conversador aunque siempre que se comenta algo, ya le pasó lo mismo a él, a un intimo amigo, a la madre o padre, íntimo amigo de madre o padre o con más ocurrencia a su hermano mayor.

    Analista de Pruebas

    Naturalmente, por definición de proceso CMMI-5, debería pertenecer al departamento de QA, es decir, ser externo al equipo de proyecto. No debe verse influenciado por el Líder de Testing, ni por el Arquitecto del Sistema, ni por el Sponsor, ni por los Desarrolladores. Debe ser una suerte de verdugo del sistema, aunque el mayor colaborador.
    Pero la suerte de esta persona es diferente al imponerse una política organizacional en la cual la empresa exige contar con su propio equipo de Testing. Entonces es influenciado por la Líder de Proyectos a realizar la carga de avances mentirosas, de actividades mal planificadas con estimaciones lastimosas por que no tuvo en cuenta las horas de I+D,  las de generación de los ambientes de prueba y juegos de datos, o por que no estimó que la tecnología a aplicarse es nueva y solo conocida por el área de desarrollo.
    Si desvía los tiempos, seguramente quedará sin trabajo.
    El arquitecto odia a los testers, no hay para que decir más.
    Los desarrolladores odian a los testers.
    El área de QA es de otra empresa. El Analista de pruebas (tester) no es de QA 😦

    Necesariamente para sobrevivir en un entorno así, hay que tener una gran adaptación según la situación lo requiera, pero particularmente yo, vivo rezando a Dios.

    Saludos, Javo.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Quien es quien – III )

    ¿Que es lo que significa un entorno de pruebas inconsistente?

    Posted on 5 diciembre 2008. Filed under: Calidad del Software, Entorno de Pruebas, Gestión de Proyectos de Software, Ingeniería del Software, Juegos de Datos, Pruebas de Campo, Pruebas de Sistemas, Testing | Etiquetas: , , , , , , |

    Se conoce como “entorno de pruebas inconsistente”, al entorno de ejecución de pruebas que no cumple con los requerimientos del Plan QA y/o del Plan de Testing. Estos documentos formales de los procesos de desarrollo, definen cuales son las necesidades de Recursos IT, Recursos Humanos, Juegos de Datos, entre otros ítems a cumplir, previo a la ejecución de un ciclo de Testing. Estos elementos serán requeridos, presentados y revisados para los diferentes ciclos planificados a lo largo de todo el ciclo de vida del proyecto.

    Hay quienes pueden pensar que un entorno incompatible, está relacionado a la diferencia de entornos entre el ambiente de laboratorio y el ambiente de producción (donde se desenvuelve el usuario final), sin embargo esto no es real puesto a que en la mayoría de los casos, los entornos de producción son absolutamente irreproducibles, principalmente por su costo.

    Por ende un ambiente de pruebas no debe ser necesariamente un espejo de los ambientes de producción y mucho menos utilizar el juego de datos que en producción se utilizan, sino que solo es factible simular en una variedad de grados de aproximación, y definir las características del sistema bajo prueba para tratar de inferir el comportamiento del mismo en un ambiente real.

    Esta es la misma razón por la cual existen y se planifican las “Pruebas de Campo” de los productos desplegados. El nuevo sistema corre posiblemente en paralelo al sistema actual, con el objeto de determinar y reconocer la estabilidad y robustez del mismo, como también los niveles de cumplimiento respecto a los requerimientos.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en ¿Que es lo que significa un entorno de pruebas inconsistente? )

    Como lidiar con un usuario que quiere liderar el proyecto?

    Posted on 4 diciembre 2008. Filed under: Comunicación, Habilidades Personales, Liderazgo, PNL y Coaching, Project Management, Recursos Humanos, Roles, Trabajo en Equipo |

    Creo que la pregunta está planteada en un contexto demasiado amplio y por lo menos surgen algunas preguntas:

    ¿Es posible liderar si no eres miembro del equipo del proyecto?
    Los Stakeholder son todos los que sufren o gozan los resultados o productos del proyecto, pero solo algunos Stakeholder son miembros del equipo del proyecto.

    ¿Estará realmente interesado en liderar un equipo que no conoce?
    Liderar no se consigue con solo presentarse y decir “hola soy el cliente y tengo una titulación en liderazgo, ahora están bajo mi tutela”. Liderar involucra roce con tu equipo y conocimiento de sus verdaderas fortalezas y debilidades, creo que de allí surge la capacidad de compromiso.

    ¿Querrá estar informado al detalle?
    Eso es posible y hoy en día los clientes están mucho más involucrados con los proyectos que generan.

    ¿Quizas quiera determinar que se hará, como se hará, cuando se hará, introducir cambios?
    Bueno, eso depende de las características del proyecto y de la flexibilidad del mismo para adoptar cambios, pero los controles pueden y deben ser planteados como hitos del proyecto y ese nivel de detalle es necesario que nuestro cliente involucrado tome decisiones y nos haga pedidos concretos.

    En conclusión, podemos hacer que nuestro cliente sea un verdadero lider de nuestro proyecto, creando un canal de comunicación multinivel donde pueda no solo conversar con el LP del proyecto, sino con otros invlucrados y miembros del equipo del proyecto, por ejemplo con el Líder de Calidad para definir los esperables de calidad, conocer las estratégias de pruebas y métodos que se usaran para asegurar calidad. También se puede requerir su participación en algunas reuniones en las que su participación sería clave, siempre cuidando que su acceso no sea “irruptivo” y cuidando los alcances.

    Creo que nuestro cliente es nuestro mejor líder si lo sabemos escuchar, guiar y enseñarle a cumplir su rol tan importante.

    Saludos, Javier.-

    Leer entrada completa | Make a Comment ( 2 so far )

    …alguien usó "la solución de la galera"

    Posted on 29 noviembre 2008. Filed under: Capacitación, Gestión de Proyectos de Software, Habilidades Personales, Herramientas Colaborativas, Liderazgo, PNL y Coaching, Opinión, Project Management, Recursos Humanos, Trabajo en Equipo |

    ¿Que evidencia hay de que los conocimientos que exiges hoy de un RRHH siempre fueron vitales y exigibles?

    Como líder, ¿te has puesto a pensar en la presión obcecada que ejerces sobre tus colaboradores, muchas veces tratándolos de ineptos por no tener sus prácticas al día en relación a alguna herramienta o técnica en particular?

    ¿Te has puesto a pensar en lo injusto de pedir soluciones inmediatas cuando no capacitas a tu gente en el uso de esas herramientas? quizás nunca antes habías hecho un pedido que involucre conocimientos técnicos para llevar adelante operaciones que hoy te son útiles.

    ¿Pensaste que quizás tu falta de previsibilidad para los proyectos? ¿Que quizás no tienes en consideración sus riesgos?  ¿Nunca asumiste la culpa por que tu equipo de trabajo no está correctamente preparado para enfrentar los problemas?

    Somos informáticos y nos dedicamos a muchas cosas distintas, pero no somos el “botón rojo que lanza el misil”.

    Nuestro personal siempre debe estar capacitado con mucha anticipación para poder ser resolutivos en los proyectos venideros.

    Ya sea que nuestro colaboradores obtuvieron la experiencia de otros proyectos o por que los capacitamos, los líderes nos hacemos cargo verdaderamente del éxito de los proyectos que guiamos. Si no es así, entonces nos arriesgamos a un fracaso rotundo o a un éxito poco meritorio, donde alguien usó “la solución de la galera”.-

    Leer entrada completa | Make a Comment ( Comentarios desactivados en …alguien usó "la solución de la galera" )

    Demanda laboral IT en Argentina – Acumulado Anual

    Posted on 29 noviembre 2008. Filed under: Artículos sueltos, Calidad del Software, Gestión de Proyectos de Software, Opinión, Recursos Humanos |

    Recientemente en el sitio Universo Bit se publicó la lista de demanda laboral IT, actualizada hasta el 22 del mes de noviembre del año 2008.

    La imagen muestra cuales son las herramientas IT más requeridas en el mercado en todo el año y cuales son los perfiles de mayor demanda.

    Demanda Laboral IT - Noviembre 08

    Queda muy a las claras que la inversión en calidad aún no es demandante, o quienes cubren puestos QA tienen mayor estabilidad y perduran en sus posiciones, o un bajo porcentaje de profesionales involucrados en QA es suficiente para el control, seguimiento y aseguramiento de la calidad de todos los procesos, prácticas, productos, servicios y derivados de todas las áreas.

    De cualquier manera algo no me huele bien respecto a la demanda de profesionales QA.-

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Demanda laboral IT en Argentina – Acumulado Anual )

    ¿Que hace un SQA?

    Posted on 22 noviembre 2008. Filed under: Calidad del Software, Gestión de Proyectos de Software, Habilidades Personales, Ingeniería del Software, Project Management | Etiquetas: , , , , |

    Es responsable de asegurar la calidad de los productos generados en el proyecto y del proceso utilizado. Para asegurar la calidad debe revisar la calidad de los entregables de planificación del proyecto y los entregables de valoración del proyecto. Además revisa el nivel de apego al modelo de proceso de desarrollo de software y a los planes de Verificación, Gestión de Proyecto y Gestión de Calidad, documentando las desviaciones encontradas.

    Debe conocer los conceptos y técnicas de Gestión de Calidad del Software. Debe identificar las propiedades de calidad que deben cumplir los productos del proyecto.

    Centralizar y revisar las entregas que se realizan durante el ciclo de vida del proyecto.

    Realiza las Revisiones Técnicas Formales con los responsables de los productos a revisar.

    El Responsable de SQA debe:

    • Asegurarse de que se desarrollen prototipos para probar y eliminar riesgos técnicos que hagan fracasar el proyecto así como también disminuir la calidad del mismo

    • Asegurarse de que se realicen estudios de factibilidad

    • Realizar mediciones para comprobar la calidad del proyecto

    • Asegurarse de que se realice la actividad de implementación y se haga según los estándares de calidad propuestos

    • Evitar el desperdicio de esfuerzo en conjunto con el Administrador y el Arquitecto

    • Registrar las métricas de aceptación tomando en cuenta el Documento de Validación con el Cliente.

    Perfil del rol

    • Debe conocer los requerimientos del sistema.

    • Debe conocer los estándares o lineamientos del proyecto para asegurar la calidad.

    Actividades que son responsabilidad del rol

    • Planificar la Calidad

    • Revisión Técnica Formal (RTF)

    • Revisar las Entregas

    • Revisar el Ajuste al Proceso

    • Evaluar la Calidad de los Productos

    • Realizar el Informe Final de Calidad

    Entregables que son responsabilidad del rol

    • Plan de Calidad

    • Informe de RTF

    • Entrega Semanal de SQA

    • Informe de Revisión de SQA

    • Informe Final de Calidad

    Actividades en las que está involucrado el rol

    • Relevar los Requerimientos

    • Especificar los Requerimientos

    • Priorizar los Requerimientos

    • Validar los Requerimientos

    • Validar con Prototipo

    • Definir el Alcance del Sistema

    • Definir la Línea Base del Proyecto

    • Planificar el Proyecto

    • Describir la Versión

    • Planificar la Transición

    • Seguimiento de Satisfacción del Cliente

    • Gestión de Riesgos

    • Registrar Esfuerzo

    • Auto estudio

    • Reunión de Equipo

    • Preparar Cierre del Proyecto

    • Reunión Conmemorativa


    Obtenido de MUM

    Leer entrada completa | Make a Comment ( 1 so far )

    Está hecho y lo voy a comprobar

    Posted on 18 noviembre 2008. Filed under: Comunicación, Metodologías de Desarrollo, Testing, Trabajo en Equipo |

    No confundir los hitos de pruebas

    La revisión par de componentes intenta validar la completitud y correctitud de los componentes generados, es decir marcar el hito de finalización de la construcción por componentes. De ninguna manera representa una integración de los mismos con otras unidades, esto lo sabemos por la experiencia del momento, por que cada uno supo el alcance y los límites de su caso de uso y aunque hubo cierta integración necesaria con otros componentes, los fallos imputados solo atañen al componente en revisión.

    Todos defienden sus implementaciones.

    Es por eso importante finalizar y avisar al par revisor tanto como al líder de desarrollo. Este aviso implica principalmente a los conceptos de, “está hecho” (el famoso “done”) y “lo voy a comprobar”. Pasado este hito, ya estamos asegurados para muchas cosas más como, cambios de funcionalidad, mejoras de funcionalidad, acoplamientos exitosos, seguir con otras cosas diferentes, etc. pero todo estará dentro de un “marco de generación de valor agregado”.

    Continuar sin haber validado el componente implica un riesgo importante para la integración y normalmente debemos volver atrás con un cúmulo importante de retrabajo. También implica que la prueba deja de ser de componente y presentaría un sesgo hacia pruebas de sistemas, el decir con una versión del aplicativo el cual ya sin dudas tendría N cantidad de fallos indeseados.

    Es bueno saber para que sirve cada cosa y no confundir los hitos, sabiendo que un momento se desea asegurar los componentes, en otro momento la integración modular y en otro el sistema.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Está hecho y lo voy a comprobar )

    Informática OpenSpace

    Posted on 7 noviembre 2008. Filed under: Herramientas Colaborativas, Resolución de problemas, Soporte Colaborativo, Trabajo en Equipo | Etiquetas: , , , , , , |

    Algo interesante está ocurriendo en el mundo y es lo que se conoce como “Espacios Abiertos”, donde los profesionales, idóneos o interesados en una temática en particular pueden PARTICIPAR (con todas las letras en mayúscula) en la discución, información, recomendación y conclusión de aspectos y conceptos estratégicos para definir el rumbo de ese asunto.
    En Córdoba, Argentina se llevará a cabo en la Universidad Tecnológica Nacional, en el Salón de Actos el miércoles 12 de Noviembre a partir de las 18:30hs, el primer evento con características OpenSpace, dondeen el inicio del evento se plantean las bases del mismo, para que las personas que no conocen o no saben de la modalidad puedan ponerse al tanto.

    Luego de 15 minutos introductorios, los asistentes deben dirigirse a un pizarrón, o tablón, que contiene una grilla de vacantes y horarios. O sea, algo similar a esto:

    Pizarron

    En esa grilla, cada persona asistente puede proponer un tema. Cada tema propuesto compite con otros en el caso de que existan más temas que los horarios y vacantes posibles. Los demás asistentes votan, si así lo desean, por alguno de los temas ya propuestos o simplemente proponen aquellos temas que les interesan.

    Al finalizar esa etapa las charlas con mayores votaciones son las que se llevan a cabo.

    La idea general es que, en cada charla se colocan 4 sillas. Cada persona que quiere opinar sobre el tema en cuestión debe sentarse en una de las sillas y solo recién emitir su opinión. Siempre debe quedar una silla disponible (para que se siente quien quiere opinar). Si las 4 estuvieran ocupadas, la persona que ya no tiene más que decir, o que ha estado más tiempo, o aquella que simplemente tiene la voluntad de pararse y volver a la “zona” de escuchas lo hace.

    Los asistentes pueden ir pasando por diferentes grupos, y no necesariamente deben quedarse en una charla, o en la charla inicialmente elegida. La persona que propuso el tema de la charla es la que inicia la misma, y al mismo tiempo puede o debería, preferentemente, actuar como moderador.

    Hay que destacar que no es necesario conocer un tema para proponerlo. Puede, por ejemplo, proponerse un tema del cual una persona quisiera obtener conocimientos ya que es posible que dentro de los asistentes se encuentren personas que sepan del mismo.

    En esta oportunidad, cada charla debería tomar alrededor de 45 minutos. Si el mismo se agota antes de tiempo, este se disuelve y las personas pueden ir a observar o participar de otras charlas. Es posible llevar computadoras, y mostrar código y/o presentaciones, bajo la idea de que los asistentes deberán asomarse a la pantalla y tratar de ver algo.

    Si se cuenta con algún medio de proyección, también es posible usarlo, aunque esto dependerá directamente de las instalaciones. Que temas tratar: Los temas son de informática, y no necesariamente de código. Tampoco están relacionados a una empresa, industria, propietario o modalidades de distribución. Simplemente es informática. Se podría hablar de generación automática de código, software factories, test unitarios, análisis estático de código, cloud computing, pair programming vs. revisión de código, test automation, herramientas de productividad, estimaciones, secure programming, XSS y SQL injection, domain specific languages, CMMi vs Agile, store procedures vs SQL inline, web client vs smart clients, lenguajes funcionales, hasta XNA o el mercado del desarrollo de juegos, o lo que sea.

    Extraído de Preguntale al Experto

    Leer entrada completa | Make a Comment ( 2 so far )

    OpenSpace

    Posted on 7 noviembre 2008. Filed under: Comunicación, Herramientas Colaborativas, Herramientas, Métodos y Procesos, OpenSpace, Trabajo en Equipo | Etiquetas: , , , , , , |

    Durante los últimos 15 años, claramente se ha ido percibiendo como el Espacio Abierto puede crear organizaciones inspiradas, donde personas normales trabajan juntas para crear resultados extraordinarios con regularidad.

    face to face meeting

    ¿Qué es?

    La Tecnología de Espacio Abierto es una forma de permitir a toda clase de personas, en cualquier tipo de organización, crear reuniones y eventos que inspiran.

    En reuniones, eventos y organizaciones, de Espacio Abierto, los participantes crean y manejan su propia agenda, de trabajos y sesiones simultáneas, en torno a un tema principal de relevancia estratégica, tal como: ¿Cuál es la estrategia, el grupo, la organización o la comunidad que los “stakeholders” pueden apoyar y trabajar en conjunto, para crear?
    El resultado es poderoso y efectivo a la hora de implementarlo y ayuda a apoyar lo que ya está sucediendo en la organización, no sólo planeando sino actuando, aprendiendo y enseñando, con pasión y responsabilidad, siendo no sólo participantes sino ejecutores.

    ¿Cuándo y Por Qué?

    El Espacio Abierto funciona mejor cuando el trabajo que se debe realizar es complicado, las personas y las ideas que están involucradas son diversas, la pasión por resolverlo (y potencial para conflictos) es enorme, y el tiempo para realizarlo “era ayer”.

    Es llamado “pasión limitada por la responsabilidad”, “la energía de un buen coffee break”, “auto-organización intencional”, “espíritu en el trabajo”, “caos y creatividad”, “evolución en la organización”, y una forma poderosa y sencilla de hacer a las personas y a las organizaciones moverse cuando y donde es más necesario.

    Y mientras que el Espacio Abierto es conocido por su falta de estructuración y abierto a sorpresas, resulta ser que los eventos u organizaciones de Espacio Abierto son, de hecho, muy estructuradas, pero esa estructura es tan perfectamente diseñada para las personas y para el trabajo diario, que pasa desapercibida en sus roles de dar apoyo (no obstaculizar) a un trabajo mejor realizado.

    Aún más, las historias y trabajos que se realizaron en Espacio Abierto son generalmente más complejos, más fuertes, más duraderos, y se pueden mover de manera más rápida y ágil que trabajos realizados por expertos o bajo los diseños administrativos convencionales.

    .

    ¿Cómo se estructura?

    Cuando se abre un Espacio Abierto para un grupo de personas, para que realicen su trabajo más importante, se debe garantizar estos resultados:

    1. Todos los puntos considerados como los MÁS importantes para los participantes, serán tratados;

    2. Todos los puntos que surjan serán sugeridos por los participantes más calificados y capaces de lograr algo en cada uno de esos puntos;

    3. En un período tan corto como uno o dos días, todas las ideas, discusiones, informaciones, recomendaciones, conclusiones, preguntas para discutir y planeamientos más importantes, serán documentados en un reporte muy fácil de entender, impreso y entregado en las manos de los participantes en el preciso momento que ellos se marchan;

    4. Cuando el momento sea apropiado para esto, el contenido de este reporte puede priorizarse en pocas horas, aunque se esté trabajando con grupos grandes (100);

    5. Después de un evento, todos estos resultados pueden ponerse a disposición de toda la organización o toda la comunidad, sin necesidad de realizar el evento, ya que conversando se puede invitar a los “stakeholders” en la implementación, justo en el mismo momento;

    6. Y resultados como estos pueden ser planeados e implementados más rápido que cualquier otro tipo de “intervención para grupos grandes”. Es literalmente posible obtener en días y semanas lo que cualquier otro tipo de técnica dura meses y años.

    Las buenas y malas noticias es lo que funciona. Buenas noticias porque hace que las personas y el trabajo se muevan, malas noticias porque puede significar que muchas cosas pueden llegar a cambiar. Cosas que uno desea, aparecerán y cosas que uno no desea, desaparecerán, y en algunas ocasiones vice-versa-pero así es como la vida funciona. En resumen, el Espacio Abierto trae vida a la organización y trae a las organizaciones de vuelta a la vida.

    Estráido de OpenSpaceWork

    Leer entrada completa | Make a Comment ( Comentarios desactivados en OpenSpace )

    Qué es el PMBOK® y cómo usarlo

    Posted on 31 octubre 2008. Filed under: Gestión de Proyectos de Software, PMBOOK, Project Management |

    La Guía de los fundamentos de la dirección de proyectos (más conocida como PMBOK) es el estándar más ampliamente reconocido para manejar y administrar proyectos.  Se trata de una obra realizada por personas con un agudo sentido práctico, y que tiene incorporada la concepción de que un proyecto exitoso va a ser resultado de la colaboración (y los conflictos) .

    Para citar uno de los párrafos introductorios del PMBOK: «“Buenas prácticas” no quiere decir que los conocimientos descritos deban aplicarse siempre de manera uniforme en todos los proyectos: el equipo de dirección del proyecto es el responsable de determinar lo que es apropiado para cada proyecto determinado.»

    Desde su misma Introducción, el PMBOK deja muy claro su carácter y finalidad: el conjunto de conocimientos (the body of knowledge) para dirigir un proyecto “residen en los practicantes y académicos que los aplican y los desarrollan”; en otras palabras, estos conocimientos representan un conjunto vivo, extraordinariamente amplio, producto tanto de la experiencia como del estudio y del desarrollo sistemáticos. Este conjunto de conocimientos se encuentra distribuido en miles de personas, organizaciones y textos; por ende, el lector no debe esperar tal cosa como un manual que le vaya a explicar los “nueve pasos fáciles para hacer de su proyecto un éxito”.

    La finalidad del PMBOK, entonces, no es la de exponer las disciplinas, técnicas y experiencias aplicables a la dirección de proyectos, sino simplemente la de identificar el subconjunto de éstas que es generalmente reconocido como buenas prácticas.
    Para que estas buenas prácticas sean asequibles, el PMBOK divide el conjunto de conocimientos para la dirección de proyectos en cuatro grupos de procesos: todo proyecto (así como sus distintas fases e iteraciones) tiene que transitar por una serie de actividades de INICIO, PLANEACIÓN, EJECUCIÓN Y CIERRE, bajo el gobierno de un grupo de procesos más general de supervisión y cierre.

    diag01

    Estos grupos de procesos no representan fases rígidas ni recetas, sino que, grosso modo, equivalen al modelo “planear, hacer, revisar y actuar”:

    diag02

    El meollo del PMBOK, sin embargo, lo representan las nueve áreas de conocimiento, y que son propiamente las que contienen las técnicas para poder realizar los proyectos. Las nueve áreas de conocimiento son:

    diag03

    Para cada una de estas áreas de conocimiento, el PMBOK recomienda la realización de una serie de procesos. Por ejemplo, la Gestión del alcance comprende los procesos Planificar alcance, Definición del alcance, Crear estructura de desglose de tareas, Verificación de alcance y Control de alcance. Podemos apreciar los primeros tres de éstos en el siguiente diagrama:

    diag04

    Para cada uno de estos procesos de las áreas de conocimiento, el PMBOK plantea o sugiere una serie de entradas, técnicas y salidas. Como ya se ha explicado, el PMBOK identifica las mejores prácticas que son generalmente aceptadas para la realización de cada uno de estos procesos.
    Aunque muchas de las descripciones de estos procesos contienen valiosas observaciones, el lector no deberá considerarlas como un manual de técnicas, sino más bien como la descripción del estándar para manejo de proyectos. Las técnicas mismas están contenidas en textos de diversos autores, en cursos y en la práctica misma de las organizaciones dedicadas a manejo de proyectos.

    Extraído de www.liderdeproyecto.com

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Qué es el PMBOK® y cómo usarlo )

    Humildad – Evitar el exceso de confianza

    Posted on 27 octubre 2008. Filed under: Liderazgo, PNL y Coaching | Etiquetas: , |

    Evitar la confianza exacerbada en uno como individuo y profesional, en las personas como equipo y colaboradores, en los equipos como miembros de las organizaciones, en las organizaciones y sus visiones, es también parte de la humildad que conforma a los líderes.

    Sostener el equilibrio justo entre la excitación y la calma, el coraje y la humildad, nos permite abordar cualquier inconveniente con agilidad y con flexibilidad para el cambio y capacidad de reacción, con compromiso verídico evitando creer que nuestra percepción  es la única que nos llevará al éxito.

    La humildad es un atributo muy difícil de incorporar cuando no se la tiene naturalmente, pero los hechos de la vida nos dan los elementos necesarios para poder arraigarla a nuestra personalidad y a nuestra conciencia, formando parte de nuestro accionar diario y que sin ella no podríamos concebir éxito alguno.

    Entonces el individuo exitoso es aquel que de alguna manera logra un equilibrio entre el coraje para enfrentar situaciones difíciles sabiendo que siempre se presentan y la humildad para reconocer los cambios que debe realizar para reestructurar sus paradigmas.

    Periodistas de Harvard Business Review le preguntaron a Olli-Pekka Kallasvuo, presidente ejecutivo de Nokia desde junio de 2006, qué cualidad era la más importante en el ejercicio de su liderazgo y de qué manera la ponía a prueba.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Humildad – Evitar el exceso de confianza )

    Al rescate del 60%

    Posted on 10 octubre 2008. Filed under: Artículos sueltos, Liderazgo, PNL y Coaching, Plan de Acción, Resolución de problemas, Trabajo en Equipo |

    Recientemente leí un artículo interesante en la versión digital de La Nación, el cual en su marco principal trata sobre “qué hacer y cómo tratar a las nuevas generaciones de empleados que nacieron entre 1981 y 2000, y que traen en su ADN una nueva manera de insertarse en el mundo del trabajo”. En este artículo me interesó un concepto particular y es que según estudios recientes, se determinó que el 60% de la fuerza laboral estaría representado por empleados desmotivados cuyo aporte es el mínimo indispensable para la organización y que en lugar de hacer un aporte efectivo estarían generando pérdidas.

    Esto me llevó a reflexionar sobre mi participación en distintas empresas de Argentinas y de las cuales finalmente me desvinculé, principalmente por cuestiones de motivación y una falta de misión y compromiso de tales empresas con su empleados, o por el parcialismo que representó su accionar.

    Más de una vez me pregunté que ocurre con aquellas personas que por sus características personales y capacidades profesionales o adecuaciones realizadas de su aprendizaje, fueron seleccionadas para pertenecer a un equipo de trabajo para el cual se le brinda inicialmente una apertura y participación amplia, pero con el correr del tiempo, proyecto a proyecto la resultante es un un aporte operativo básico, carente de participación en opinión analítica, crítica constructiva y pensamiento diferenciado.

    Creo que las insistentes “conversaciones en pasillos” entre empleados, sobre las malas políticas de RRHH, sueldos bajos, falta de capacitación o el exceso de las mismas, más la poca o nada de relación esfuerzo/compensación, en realidad tienen mucho más que ver con la falta de participación y opinión que se le ofrece a los empleados, que con los ítems negativos. 

    Es allí donde veo la falta de preparación de las diferentes líneas gerenciales y jefaturas, quienes manifiestan a las claras su falta de liderazgo al no saber declarar una misión, transmitir la visión, conseguir el compromiso y motivar para el cumplimiento de los objetivos.

    Creo que gran parte de ese 60% de empleados desmotivados fueron finalmente empujados a esa actitud nociva y destructiva. Es posible que de alguna manera su accionar sea un acto de ajusticiamiento y revancha.

    No se debe “tirar a la hoguera” a un soldado que aún vivo huye, sino rescatarlo, curarlo, re reclutarlo y aliarlo bajo un nuevo compromiso. Es importante considerar que, si como líderes y organización no estamos listo para “el rescate”, nuestra vida laboral también será complicada y en camino hacia un valle de desánimo, con un tendal de gente que “no trabaja motivada” y otros que poco a poco planifican su huida.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Al rescate del 60% )

    Madurez para reconocer riesgos y trabajar con ellos

    Posted on 7 octubre 2008. Filed under: Gestión de Proyectos de Software, Ingeniería del Software, Metodologías de Desarrollo, Procesos Ágile, Project Management, Trabajo en Equipo, Waterfall | Etiquetas: , , , , |

    Según mis experiencias en el entorno de los proyectos de software, no he vivido un solo proyecto que no haya sufrido modificaciones en el alcance del mismo. Estoy seguro que en la mayoría de las situaciones ese alcance se ve alterado por cambios en los requerimientos en si mismo, ya sea por que detectaron nuevos, se modificaron parámetros restrictivos o nuevos impactos son visibles en fases posteriores del proyecto, entre otros aspectos.
    Esto nos lleva a darnos cuenta que es posible que las estrategias de gestión deban cambiar en el transcurso del proyecto, lo que quizás no implique cambiar el estilo de gestión.
    Sin embargo para minimizar los cambios en la gestión, es que se realizan análisis de riesgos, priorizando los mismos y estimando cual es la chance de convertirse en realidad y cuales serían las estrategias que se aplicarían para aceptarlos, mitigarlos o minimizarlos.
    Es decir que cómo se enfrenta el equipo del proyecto a los cambios, tiene mucho que ver con la madurez para reconocer riesgos y trabajar con ellos.
    Actualmente se plantea mucho el uso de metodologías Ágiles, donde lo que se pretende es manejar un poco mejor la variación del alcance, definiendo entregables de menor tamaño, en tiempos relativamente chicos y donde cualquier modificación del alcance se gestiona como un “incremento” del requerimiento y eso exige la repriorización del
    entregable completo, donde es posible que se deba negociar la introducción a la iteración actual, de “algo de lo nuevo” quitando normalmente “algo de lo viejo” para pasarlo a una nueva iteración o pasándolo al final de la cola.
    Yo pude ver que este tipo de manejo se puede hacer sin que la organización necesariamente esté involucrada en modelos de gestión agilístas, pero si se debe estár insertos en un estilo flexible de gestión y negociación permanente, donde invariablemente el alcance varía y el tiempo también, posiblemente no los costos.
    Pude ver que este tipo de gestión permite generar mayor valor agregado en cada iteración (es notable con solo invocar el interés del cliente) y es posible adaptarse rápido a los cambios. Pero quiero que quede claro que sin gestión de cambio, las adaptaciones apropiadas no son posibles o representan en si mismo un riesgo mayor que los riesgos detectados.
    Quiero que tengan en cuenta algo para pensar. En las metodologías Waterfall (tradicionales) la triple restricción se presenta normalmente de la siguiente manera: 1-Requisitos (fijo), 2-Tiempo (estimado), 3-Recursos (estimado). Siguiendo ésta línea es posible que nuestras restricciones sean muy fuertes en el sentido de que los requisitos son plenamente mandatorios e inclusive el tiempo y es por eso que los PM deben a partir de allí planificar los recursos y “jugar” con las restricciones que este último punto les impone, en relación al carácter mandatorio de los otro dos.
    En las metodologías Ágile, la triple restricción se presenta de la siguiente manera: 1-Recursos (fijo), 2-Tiempo (fijo), 3-Características (estimado). Siendo imperativo conocer de antemano cuales son sus recursos, en segunda instancia cual es el tiempo de respuesta esperado y así decidir que características priorizar para cada iteración, adquiriendo compromisos solo en función de poder cumplir según las restricciones de los puntos 1 y 2. Ahora “el juego” se traslada al punto 3 nuevamente, pero el punto 3 ahora es otro.

    Saludos,
    Javo.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Madurez para reconocer riesgos y trabajar con ellos )

    « Entradas anteriores

    Liked it here?
    Why not try sites on the blogroll...