Comunicación

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.

Anuncios
Leer entrada completa | Make a Comment ( 2 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 )

    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 )

    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 )

    LOGS de errores reflejan el funcionamiento del nucleo de nuestras aplicaciones

    Posted on 2 enero 2009. Filed under: Calidad del Software, Entorno de Pruebas, Herramientas Colaborativas, Herramientas, Métodos y Procesos, Resolución de Problemas y Gestión de Incidentes, Soporte de Aplicaciones, Testing | Etiquetas: , , , , , , |

    Algunas estrategias de detección de errores en nuestras aplicaciones pueden parecer demasiado sencillas o desactualizadas, sobre todo con el auge y advenimiento de herramientas potentes, con cientos de reportes, gráficas y métricas para analizar.

    Sin embargo prácticamente ninguna herramienta permite a desarrolladores, analistas funcionales y testers de aplicaciones, reconocer la causa raíz de los problemas que aquejan a nuestros desarrollos.

    Una técnica sencilla y pronta a aplicar, es la generación de logs de errores en formato TXT. A partir de allí mejorar el proceso de construcción en base a información obtenida del núcleo de funcionamiento de nuestras aplicaciones, es cuestión de solo dejar volar la imaginación.

    Aunque un conjunto de nuevas herramientas podrían ser la solución para el ahorro de tiempo y dinero en la resolución de defectos, estas herramientas principalmente deben tener la capacidad de generar reportes que permitan aislar los problemas raíces, haciendo mucho más sencillo el diagnóstico y resolución, sin tener que invertir en costosos ambientes de aislamiento ni tiempos de reproducción.

    Estas soluciones no están del todo presente en las actuales herramientas disponibles, ni diseñadas para el comportamiento dinámico de los defectos y solo se permite un análisis estático basado en la mayoría de los casos, en pruebas orientadas de “caja negra”.

    Pero tal vez la productividad se vería acelerada exponencialmente si no solo pudiéramos introducir herramientas con estas características dinámicas, sino que a su vez tuviéramos la capacidad de darle a nuestras aplicaciones la capacidad de resguardo y notificación de errores.

    Desde el análisis y diseño y bajo un planteo de pruebas que orienten la construcción de los componentes, es posible introducir ciertos niveles de detalles que serían plasmados en “logs de errores”, los cuales pudieran ser de gran utilidad para el diagnóstico de problemas raíces y resolución temprana, es decir en fases de pruebas tempranas.

    Al finalizar cada ciclo de prueba, testers y desarrolladores pueden interactuar con mejor foco en las causas raíces de los bugs, errores de construcción e inclusive errores de interpretación de requisitos o detección de requisitos mal formados.

    La verdadera potencia de tales “logs de errores” se manifestarán solo si esta solución es diseñada y aplicada en forma armonizadas para que no se entorpezca el trabajo y los resultados sean positivos y bien significativos.

    Un beneficio central es que los “tiempo ventana” demasiados cortos para la resolución de defectos, sean mejor aprovechados y el proceso se optimice significativamente.

    Hay quienes opinan que se deben modificar significativamente los requerimientos para incorporar estos elementos a los procesos de desarrollo, pero yo creo que el esfuerzo no es tan grande como para evitarlo y los beneficios son tremendos como para dejar de hacerlo.

    No piensen en tecnificar demasiado ni en agregar complejidad, orienten esta solución a la simplicidad y facilidad de lectura y comprensión y bastará con utilizar un notepad o archivo tabulado para comenzar a obtener resultados que mejoren la visibilidad del comportamiento erróneo de nuestras aplicaciones.

    Potenciar la solución  es cuestión de imaginación.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en LOGS de errores reflejan el funcionamiento del nucleo de nuestras aplicaciones )

    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 )

    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 )

    El impacto de las redes sociales en Argentina

    Posted on 29 noviembre 2008. Filed under: Comunicación, Herramientas Colaborativas, Mercado Tecnológico, Opinión, Redes Sociales, Soporte Colaborativo, WEB 2.0 | Etiquetas: , , , , , |

    Argentina se encuentra liderando el acceso y participación de las redes sociales, aún cuando España es el país que recientemente mas integrantes a sumado a este fenómeno Web 2.

    image

    El fenómeno de la creciente participación en las redes de enlace social, está relacionado principalmente por la necesidad de recupero de comunicación interpersonal, muy probablemente ligado a la gran dispersión de las personas al rededor de todo el mundo. Estos medios son la herramienta ideal para localizar y contactar a personas a las cuales se les ha perdido el rastro.

    Otro motivo no menos poderoso para el uso de herramientas sociales, tiene que ver con búsqueda de trabajo y relación profesional o comercial, donde nuevas oportunidades se abren en dos frentes, tanto para quienes buscan un nuevo puesto de trabajo como para quienes buscan nuevos prospectos. Del mismo modo para quienes tienen relaciones de negocios en algún grado.

    Es interesante notar que lo que aparentemente tiene un impacto de corto alcance, en realidad tiene un alcance inimaginable, tal es así que con solo tener unos cuantos contactos directos o de primer nivel, se genera una red de contactos que se disgrega por múltiples regiones del mundo, logrando así disponer de una red verdaderamente amplia, donde localizar a una persona, buscar trabajo, mano de obra califica o promocionar un producto, es mucho más simple y veloz, por no hablar de los costos que aún pagando, tienden a cero.

    Aún no hemos visto más que los inicios de las redes de la Web 2 y los servicios comienzan a escalar para brindarnos capacidades multimedias, aplicaciones de planificación de proyectos globales, coordinación de equipos distribuidos, ambientes colaborativos, soporte de archivos, voice mail, chat y poderosos monitores de estadísticas que nos ayudan a tener mayor visibilidad y definición de los rumbos a tomar.

    No me atrevo a especular sobre todo lo que aún nos deparan estos avances, pero sin duda estamos en un proceso de aprendizaje y adaptación, el cual cada vez es más rápido, tiene más adeptos y el feedback es instantáneo, hasta el punto tal que en cuestión de horas las aplicaciones OnLine perfeccionan sus funcionalidades y potencian sus servicios.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en El impacto de las redes sociales en Argentina )

    …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" )

    Cloud Computing. Mucho más que un BUZZWORD!

    Posted on 19 noviembre 2008. Filed under: Artículos sueltos, Cloud Computing, Herramientas Colaborativas, Mercado Tecnológico, Opinión, SaS, Soporte Colaborativo, Soporte de Aplicaciones, WEB 2.0 | Etiquetas: , , |

    Virtualización fue una de las primeras palabras que se escucharon varios años atrás y cuando nadie lo entendía, creímos que era algo para las mega corporaciones, inaplicable para un usuario común y corriente o para pequeñas organizaciones y muchos se resistieron a la idea.
    Hoy nadie se resiste, todos abogan por esa tecnología por que abarata terriblemente los costos y de la negación nadie se acuerda.
    “Cloud Computing” es el buzzword del momento y algunos nos metimos a usarlo aún a costa de que nuestra información personal pudiera perderse o caer en manos irresponsables.
    Particularmente yo necesité años atrás una solución para poder generar mis documentos y disponer de ellos en cualquier momento y lugar, así fue que me sumé a EYEOS como algo experimental. Hoy el sueño es más tangible o está  hecho realidad. Utilizo dos servicios alternativamente: google doc y Office Live Workspace, ambos con muy bueno resultados y criticables en ciertos aspectos.
    Las acciones de hoy ya dejaron de ser meras iniciativas y son bien serias. No son simples prototipos por que el usuario ya dijo “SI”.
    Aplaudo a las corporaciones por su competencia y garantizo que pequeñas organizaciones daremos soluciones alternativas basados en el mismo modelo.
    Levanto mi copa por que pronto las grandes y pequeñas compañías puedan decir que utilizan los servios OnLine de “…..” sin discriminación.
    Pagar? lógico y moderado.

    Leer entrada completa | Make a Comment ( Comentarios desactivados en Cloud Computing. Mucho más que un BUZZWORD! )

    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 )

    Fishbowl – parte 2 (Clue Computing)

    Posted on 17 noviembre 2008. Filed under: Comunicación, Fishbowl, Herramientas Colaborativas, IT, OpenSpace, Opinión |

    Habiendo realizado una apertura sobre la temática en mi primer artículo https://javosantillan.wordpress.com/2008/11/16/fish-bowl-parte-1-desarrollo-de-juegos/ me gustaría compartir la segunda parte del Fishbowl realizado en UTN de Córdoba, Argentina. La temática tratada en esta parte, está relacionada a la muy popular y populosa Clue Computing o Nube Informática.

    El debate se abrió con una visión un tanto “oscura y pecaminosa” de lo que son las tecnologías abiertas, donde se pretende llevar al usuario a una dependencia total de los entornos OnLine o Web Based. El expositor argumentó su óptica indicando que no se debería confiar información tan importante como la relacionada a los contactos de negocios, económicos o familiares a organizaciones que hoy ofrecen en forma gratuita sus servicios pero que no ofrecen garantías de que así se sostengan tales servicios. También indicó el expositor, que tales prestadores de servicios incluyen cláusulas en sus CLUF donde está claramente expresado que no son responsables por la pérdida de datos o información y que tampoco se expresa la garantía de sostener el servicio si comercialmente no se obtienen los réditos necesarios.

    Desde otras ópticas, algunos argumentaron que ven que los servicios WebBased son una creciente demanda en evolución, donde en muy corto tiempo lo que menos importará es si tales servicios sean pagos. Se mencionó a Oracle como la primer empresa en prestar servicios OnLine y WebBased para soportar el mantenimiento de grandes bases de datos, donde una gran corporación puede confiar sus datos a la infraestructura IT de Oracle. Esto redunda en que una empresa solo debe dedicarse a su negocios sin preocuparse de tener mano de obra especializada ni infraestructura IT costosa.

    Se habló de seguridad de datos, de disponibilidad e integridad de los mismos y por sobre todo, accesibilidad (curiosamente los pilares fundamentales de la seguridad informática) y en torno a esos puntos se encontraron posturas dispares pero todas orientadas a determinar cual es el beneficio o perjuicio para el usuario final.

    Un última exposición hizo hincapié en los recientes “temas calientes” donde se menciona la privatización de Internet y donde uno de los principales detractores de esta idea es el presidente electo de los EEUU, Obama, quien en uno de sus discursos pre electorales, remarca la necesidad de sostener una red abierta y accesible para todo el mundo y evitar que se genere un “tercer mundo informático” a raíz de servicios diferenciados tanto en los paquetes de software como con el ancho de banda, siendo que se planea que los carriers puedan segmentar por tipos de usuarios para establecer los márgenes de calidad para los servicios de Internet.

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

    Fishbowl – Parte 1 (Desarrollo de Juegos)

    Posted on 16 noviembre 2008. Filed under: Calidad del Software, Capacitación, Comunicación, Herramientas Colaborativas, Pruebas de Integración, Pruebas de Sistemas, Pruebas Unitarias, Testing |

    Recientemente participé del primer Fish Bowl de la provincia de Córdoba, organizado por la gente de Pregunta al Experto, en la Universidad Nacional de Córdoba.

    El evento aunque poco concurrido, fue de gran utilidad para mí, puesto que me permitió salir de mi esquema de trabajo unitario y de comunicación unidireccional y participar de un método de exposición y retorno inmediato.

    Se trataron varios temas en los que yo me anoté para participar siguiendo la modalidad propuesta y aunque en algunas temáticas no haya tenido ni la menor idea, puede realizar preguntas que fueron bien respondidas y me permitieron tomar alguna postura, pero no necesariamente una conclusión .

    La primer actividad fue al rededor de la temática “Desarrollo de Juegos”, donde quien hizo el planteo inicial nos introdujo en conceptos básicos de las plataformas existentes. Se mencionaron otras plataformas de desarrollo tales como Torque, Ogre, Genesis, Allegro, Fenix, Blitz y Jade, pero mencionó DXNA de Microsoft, como la de su preferencia para desarrollo en entorno Windows y consola XBOX.

    El expositor del momento indicó “el por que” de su preferencia, mostrando un entendimiento y alineación con las estrategias de expansión del gigante del software en el rubro y explicando que los pilares fundamentales son la facilidad de creación, prueba y distribución  de desarrollo de juegos, hasta el punto de permitir a desarrolladores individuales, lograr ser considerados casos de éxito mundial.

    Otros expositores indicaron que la plataforma JAVA para el desarrollo de juego de consolas, fue un verdadero fracaso quedando relegado a la expresión de juegos para celulares, lo cual pronto también evolucionarán como ya se puede percibir.

    Nos explicaron también que el lenguaje fuerte para la generación de juegos de consola es y seguirá siendo por mucho tiempo más, el legendario C++ y en respuesta a si existen juegos desarrollados para la plataforma Silverlight, se explicó que no se conocen tales desarrollos, pero que no consideran que sea una limitación del todo importante y que solo habría que esperar que Silverlight tome una orientación más definida a la que tiene en la actualidad o incluya a este rubro.

    Por mi parte, durante las exposiciones y el debate, había oído hablar de los términos, Xploit, bucles finitos, estructuras de datos y objetos, como también la frase “moderar el trabajo a bajo nivel y a alto nivel para manejar adecuadamente las funciones de control y evitar que este sea excesivo o poco en su defecto”. Entonces las preguntas obvias fueron:

    ¿como se establecen los niveles mínimos de calidad requeridos para los juegos y como se los alcanza?¿cómo se organiza el TEAM de desarrollo?¿cómo se testean los juegos?

    Las respuestas fueron poco satisfactorias para ser honesto. En primer lugar indicaron que no existe cosa tal como “Testing Unitario” dentro de sus procesos de construcción. Luego explicaron que el software es testeado de manera regresiva al 100% y que no son admitidos los errores en los juegos, por lo tanto es necesario que los testers recurran a probar todo el paquete cada vez que se introduce un cambio o una mejora. Las pruebas a su vez son todas del tipo funcional de caja negra, es decir que se prueba jugando.

    Sin lugar a dudas, no se conocen métricas de Testing, ni el costo de la calidad o si los programadores están abocados a las mejores prácticas efectivamente. Por lo tanto no es conocido el “costo de la no calidad”.

    Lo satisfactorio fue saber que existen empresas que trabajan en emprendimientos muchos más grandes (juegos categoría Triple A) y que deben contar con procesos formales donde aspectos como el Testing Unitario, de Integración, Pruebas Automatizadas y Métricas, son una necesidad más que nada por la envergadura de los proyectos.

    En muchos aspectos el Fish Bowl de esta temática fue interesante, pero lo que más rescato fue el juicio experto de quienes participaron exponiendo y respondieron las inquietudes en el entorno abierto.

    Un saludo para ellos.

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

    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 )

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