Actitudes

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.

Anuncios
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 )

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 )

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 )

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 )

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