Mejores formas de contratar talento (Era: Se busca arquitecto Java EE con interés por metodologías ágiles)

35 views
Skip to first unread message

José Manuel Beas

unread,
Jun 30, 2010, 1:34:04 PM6/30/10
to agile-spain
¿He dicho talento? Dios, no quería reeditar viejas discusiones... ;-)

Bueno, al tema, he cambiado el asunto del hilo para no confundir.

Claro que tengo ideas sobre cómo contratar a gente con talento. Todos las tenemos. ¿Verdad? Algunas son mejores que otras, por la relación coste/beneficio fundamentalmente. Por supuesto que siempre que hablamos de costes es relativamente fácil, pero cuando hablamos de beneficios la cosa se complica. Beneficios, ¿para quién? ¿para cuándo?

Ideas. La mayoría robadas, la mayoría sin elaborar lo suficiente.

* Pedir al candidato/s que empleen un sábado para venir a programar a mi empresa. Les enseñaré cómo es mi cocina y les pediré que hagan una serie de ejercicios (codekatas) que, lógicamente, el que se las traiga preparadas tendrá más fácil de resolver. Pero a lo largo del día les iré pidiendo que trabajen en pareja, en solitario, con un ejercicio conocido, con un ejercicio desconocido, a contrareloj, sin requisitos, cambiando de IDE, cambiando de lenguaje... en fin, les pondré a prueba. Y al final, nos habremos echado unas risas, habremos aprendido unos de otros, y alguno(s) se quedaran en mi empresa porque, además del sueldo, les gustará mi manera de hacer las cosas, los compañeros (a los que conocerá más o menos después de un día entero de trabajo)... ¿A quién contrataré? Al que más le guste a mi, a mi equipo y nosotros le gustemos a él.
COSTE: Un sábado de trabajo de todo el equipo (Los candidatos vienen gratis)
BENEFICIO: Nos conocemos todos mucho mejor que a través de un CV, dos entrevistas de RRHH y tres técnicas. ¿No os parece?


* Una competición: les daré unos requisitos (una codekata cualquiera puede ser) y les pediré que resuelvan el problema, programando por supuesto, durante una semana, en su casa. Al final, con el que tenga interés en enseñarlo y explicarnos qué ha hecho, cómo lo ha hecho y qué decisiones tomó, concertamos una cita y durante 3 horas hablamos de todo eso. Pista: si el candidato no trata de deslumbrarnos, no lo contratamos. :-)
COSTE: Sobre todo para el candidato. (¿Le merecerá la pena tanto esfuerzo?)
BENEFICIO: Lo conocemos muy bien técnicamente, aunque no tenemos ni idea de cómo funciona en equipo. Habría que complementar esto con otra cosa.

¿Alguien se atreve a proponer algo más?

Un saludo,
Jose Manuel Beas

http://agilismo.es
http://jmbeas.iExpertos.com
http://twitter.com/jmbeas



On 30 June 2010 17:44:21 UTC+2, Christian López Espínola <penya...@gmail.com> wrote:
Hola,

2010/6/30 José Manuel Beas <jose....@gmail.com>

P.S.
Tengo otras ideas para contratar a gente de valía, pero no aplican a grandes compañías y además quedarían más que offtopic en este hilo.


¿Me las cuentas? Tú ya eliges si en la lista o en privado, si crees que es offtopic.
 


Carlos Díez-Gil Romero

unread,
Jun 30, 2010, 1:48:12 PM6/30/10
to agile...@googlegroups.com
José Manuel, me gustan tus ideas de las pruebas... Si a un candidato no le interesa hacer ese proceso, seguramente no te merezca la pena.

Hace un tiempo en uno de los libros de 39signals (creo recordar que rework ) leí que ellos contratan gente activa en la comunidad opensource. Saben cómo funcionan y les gusta su código antes de verle el careto. Además hacían pruebas técnicas. Y decían algo así como: ¿Cuando compras ropa te la pruebas? Qué no tendrás que hacer con un recurso mucho mas caro ;) El libro en si es muy recomendable, pero el capítulo de contratación (o falta de contratación) mas.

Quizá sea demasiado bestia (en España no hay demasiada gente "viva" en comunidades opensource) pero es una idea...

Saludos,
Carlos Díez-Gil
 

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

José Manuel Beas

unread,
Jun 30, 2010, 2:01:08 PM6/30/10
to agile-spain
On 30 June 2010 19:48:12 UTC+2, Carlos Díez-Gil Romero <cdie...@gmail.com> wrote:
José Manuel, me gustan tus ideas de las pruebas... Si a un candidato no le interesa hacer ese proceso, seguramente no te merezca la pena.


Me alegro no estar (demasiado) solo. Ésa es la idea. Filtrar por la actitud antes de empezar siquiera el proceso. (Ahorro de costes "lean")
 
Hace un tiempo en uno de los libros de 39signals (creo recordar que rework ) leí que ellos contratan gente activa en la comunidad opensource. Saben cómo funcionan y les gusta su código antes de verle el careto. Además hacían pruebas técnicas. Y decían algo así como: ¿Cuando compras ropa te la pruebas? Qué no tendrás que hacer con un recurso mucho mas caro ;) El libro en si es muy recomendable, pero el capítulo de contratación (o falta de contratación) mas.


Más ahorro de costes "lean". ¿Por qué gastar en un departamento que gestione los despidos y todas esas insatisfacciones si podemos evitar llegar a ello? ;-)

Quizá sea demasiado bestia (en España no hay demasiada gente "viva" en comunidades opensource) pero es una idea...


Deberíamos encontrar una manera de encontrarlos. Se me ocurre que hay portales #madeinspain como "masterbranch" que pueden servir para eso. (No, no me llevo comisión, ya me gustaría!)
 
Saludos,
Carlos Díez-Gil
 

Martin Perez

unread,
Jun 30, 2010, 3:29:41 PM6/30/10
to agile...@googlegroups.com
José Manuel, me gustan tus métodos. El primero lo veo un poco utópico, desde el sentido de que no sería tan fácil.

Lo primero es que pones a todos los candidatos en un brete. Ir a un sitio a competir con otra gente. No suena demasiado bien, especialmente si es un sábado. Imagínate la tensión, "cabrón me quieres quitar el puesto". Entrarías en juego psicológico de aupa. Sería interesante incluso analizar la legalidad del tema. En fin que la realidad creo yo es que ese proceso les gustaría justamente a los cracks y que les vaya lo geek, que entonces seguro que irán contentos. Pero en ese caso ¿para qué hacer la selección si ya sabes que son unos cracks? De hecho sería algo injusto, porque serán todos tan buenos que te dará pena dejar a algunos. ¡Acabarás contratando a varios y la empresa se irá a la ruina!

El segundo está bien pero una semana se me antoja demasiado tiempo. No creo que nadie te quisiese trabajar una semana, especialmente si tienen trabajo y están quemados, algo muy probable. Y si no, al que no tenga trabajo le da ventaja. Y el tema legal, que no te denuncie nadie diciendo que le haces currar una semana y no le pagas :D Para mi un día sería suficiente. Un programa suficientemente simple. Suficiente para saber si copia y pega, si es de los que lo hacen a pelo, si es de los que usan frameworks, de los que comenta poco, de los que comenta de más, etc. etc.

Ya que hablamos del sector IT, a mi una de las mejores formas de contratar talento me parece el usar herramientas como MasterBranch que es una buena idea. En general los proyectos Open Source son un gran lugar para encontrar talento, ya que vas a encontrar gente que tiene pasión por programar, a menudo cracks, ya tenemos uno de los puntos cumplidos. Después sería cosa de hacer una entrevista más tradicional para ver si está majareta o no, si es sociable o no, etc. etc. 

Ladrillo va.

Saludos,
Martín

2010/6/30 José Manuel Beas <jose....@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.



--
Martín Pérez

Founder,
http://www.jobsket.com

José Manuel Beas

unread,
Jun 30, 2010, 3:50:23 PM6/30/10
to agile-spain
On 30 June 2010 21:29:41 UTC+2, Martin Perez <mpe...@gmail.com> wrote:
José Manuel, me gustan tus métodos. El primero lo veo un poco utópico, desde el sentido de que no sería tan fácil.


No he dicho que fuera fácil. (De hecho, no he dicho que sea siquiera rentable, habría que demostrarlo)
 
Lo primero es que pones a todos los candidatos en un brete. Ir a un sitio a competir con otra gente. No suena demasiado bien, especialmente si es un sábado. Imagínate la tensión, "cabrón me quieres quitar el puesto". Entrarías en juego psicológico de aupa.

Bueno, el que se lo tome como una competición donde el objetivo es hacer perder a los competidores, peor para él. (Es muy fácil de ver a esos y de decirles en la primera media hora que su puesto no está en nuestra compañía)
 
Sería interesante incluso analizar la legalidad del tema.

¿Legalidad? No entiendo. ¿Qué problema legal hay? [Y no me vengas con las horas extra, por favor, que las pago, las pago] :-D
 
En fin que la realidad creo yo es que ese proceso les gustaría justamente a los cracks y que les vaya lo geek, que entonces seguro que irán contentos. Pero en ese caso ¿para qué hacer la selección si ya sabes que son unos cracks?

¿Tienes una manera mejor de distinguir y ATRAER a esos cracks de entre toda la pila de CVs que puedes tener encima de tu mesa ahora mismo? Si es así, soy todo oidos. :-)
 
De hecho sería algo injusto, porque serán todos tan buenos que te dará pena dejar a algunos. ¡Acabarás contratando a varios y la empresa se irá a la ruina!


Estaría encantado de tener a gente que sea muy buena técnicamente y con la que además mi equipo se lleve bien (recuerda que es otra de las cosas que tratamos de averiguar con esta prueba). Creo que hay gente en esta lista que tiene experiencias positivas de equipos de alto rendimiento formados por gente con grandes aptitudes técnicas. Ojo, los incompetentes, los competidores y los divos, a la calle. No encajan, aunque en su casa sean de lo mejor. :-)

El segundo está bien pero una semana se me antoja demasiado tiempo. No creo que nadie te quisiese trabajar una semana, especialmente si tienen trabajo y están quemados, algo muy probable.

Bueno, si no te motiva cambiar de trabajo a una empresa donde se valora el trabajo bien hecho. No hay problema. Selección hecha: descartado. ;-)
 
Y si no, al que no tenga trabajo le da ventaja.

Justamente, si les damos poco tiempo, el que tenga otras obligaciones está en desventaja.
 
Y el tema legal, que no te denuncie nadie diciendo que le haces currar una semana y no le pagas :D

¿Realmente crees que se puede considerar trabajo el resolver el Juego de la Vida de Conway, la KataPotter o cualquiera otro de los miles de ejercicios similares que se pueden plantear y que cada candidato, con su imaginación, puede complicar hasta el infinito con el objetivo de deslumbrarnos? Bueno, si resulta que inventan un algoritmo alucinante para resolver la KataPotter, publicaremos un libro y donaremos los beneficios a la asociación de informáticos workaholics. ;-)


Para mi un día sería suficiente. Un programa suficientemente simple. Suficiente para saber si copia y pega, si es de los que lo hacen a pelo, si es de los que usan frameworks, de los que comenta poco, de los que comenta de más, etc. etc.


Vamos, de los que no te dicen más allá que si no es un tarado. Yo lo que pretendo es descubrir a los que tienen TA-LEN-TO. Me interesa saber hasta dónde son capaces de complicar un problema sencillo sin perder la magia. ;-)
 
Ya que hablamos del sector IT, a mi una de las mejores formas de contratar talento me parece el usar herramientas como MasterBranch que es una buena idea. En general los proyectos Open Source son un gran lugar para encontrar talento, ya que vas a encontrar gente que tiene pasión por programar, a menudo cracks, ya tenemos uno de los puntos cumplidos. Después sería cosa de hacer una entrevista más tradicional para ver si está majareta o no, si es sociable o no, etc. etc. 


+1
De hecho, en términos de rentabilidad para la empresa, probablemente sea una de las soluciones más rentables para separar el polvo de la paja. Eso sí, cuidado porque hay gente que programa muy bien y que no hace una linea de código libre. Mmmm, ¿cómo encontrar a estos señores? ¿Merece la pena encontrarlos? Quiero decir, ¿hay tantos como para que perdamos el tiempo en intentar encontrarlos? Pensar es gratis, pero seleccionar personal no. ;-)
 
Un abrazo,
JMB

German DZ

unread,
Jun 30, 2010, 4:31:01 PM6/30/10
to agile...@googlegroups.com
Me gusta la forma... nosotros al contratar, prueba en máquina de unas
2hs aprox, pero si querían quedarse 4hs bien, si nos decían que mejor
lo hacían en la casa bien.. solo nos interesaba verlo interactuar y
obviamente su destreza.

Además, entrevista con uno de sus posibles líderes, con alguno de los
socios de la empresa y con el especialista si aplicaba el caso. Más un
exámen de 10 preguntas sobre arquitecturas y conceptos de OOAD, y otro
general. Al menos todo eso.

De esa forma nos equivocabamos bastante poco, y el "candidato" también
podía conocernos un poco (y saber que eso era un manicomio!!! jejej).

2010/6/30 José Manuel Beas <jose....@gmail.com>:

Martin Perez

unread,
Jun 30, 2010, 4:41:55 PM6/30/10
to agile...@googlegroups.com
2010/6/30 José Manuel Beas <jose....@gmail.com>
On 30 June 2010 21:29:41 UTC+2, Martin Perez <mpe...@gmail.com> wrote:
José Manuel, me gustan tus métodos. El primero lo veo un poco utópico, desde el sentido de que no sería tan fácil.


No he dicho que fuera fácil. (De hecho, no he dicho que sea siquiera rentable, habría que demostrarlo)
 
Lo primero es que pones a todos los candidatos en un brete. Ir a un sitio a competir con otra gente. No suena demasiado bien, especialmente si es un sábado. Imagínate la tensión, "cabrón me quieres quitar el puesto". Entrarías en juego psicológico de aupa.

Bueno, el que se lo tome como una competición donde el objetivo es hacer perder a los competidores, peor para él. (Es muy fácil de ver a esos y de decirles en la primera media hora que su puesto no está en nuestra compañía)
 
Sería interesante incluso analizar la legalidad del tema.

¿Legalidad? No entiendo. ¿Qué problema legal hay? [Y no me vengas con las horas extra, por favor, que las pago, las pago] :-D
 
En fin que la realidad creo yo es que ese proceso les gustaría justamente a los cracks y que les vaya lo geek, que entonces seguro que irán contentos. Pero en ese caso ¿para qué hacer la selección si ya sabes que son unos cracks?

¿Tienes una manera mejor de distinguir y ATRAER a esos cracks de entre toda la pila de CVs que puedes tener encima de tu mesa ahora mismo? Si es así, soy todo oidos. :-)
 
De hecho sería algo injusto, porque serán todos tan buenos que te dará pena dejar a algunos. ¡Acabarás contratando a varios y la empresa se irá a la ruina!


Estaría encantado de tener a gente que sea muy buena técnicamente y con la que además mi equipo se lleve bien (recuerda que es otra de las cosas que tratamos de averiguar con esta prueba). Creo que hay gente en esta lista que tiene experiencias positivas de equipos de alto rendimiento formados por gente con grandes aptitudes técnicas. Ojo, los incompetentes, los competidores y los divos, a la calle. No encajan, aunque en su casa sean de lo mejor. :-)


José Manuel, el problema es que tú te lo planteas como una diversión, y créeme que estoy seguro de que para mi lo sería, pero para mucha gente se trata de un puesto de trabajo, donde competirán con otras personas para conseguirlo, y sólamente el mejor, sean los criterios que sean los utilizados para el adjetivo "mejor", será el que lo consiga. En cuanto a legalidad, aquí en España en realidad tampoco creo que tuvieses mucho problema porque aquí vale todo, por eso digo lo de que habría que mirarlo, porque bueno aquí se están poniendo algo bravos también con la ley últimamente. 

En otros países lo tendrías chungo. En Irlanda o UK por ejemplo serías carne de demanda muy fácilmente debido a la subjetividad de las pruebas. Cualquier candidato podría decir que una prueba no era igualitaria, o discutir que otros candidatos les han hecho la vida imposible y no has hecho nada, etc. No te olvides que en los países civilizados el candidato tiene las de ganar si te demanda, eres tú el que tendrás que demostrar que el proceso fue justo. Por ejemplo, podrías diréctamente olvidarte de excluir a cualquiera que no considerase divertido tu forma de contratar personal o lo viese como una competición, te podría caer un buen paquete por discriminación, no olvides que estás ofreciendo un puesto de trabajo públicamente. 


 
El segundo está bien pero una semana se me antoja demasiado tiempo. No creo que nadie te quisiese trabajar una semana, especialmente si tienen trabajo y están quemados, algo muy probable.

Bueno, si no te motiva cambiar de trabajo a una empresa donde se valora el trabajo bien hecho. No hay problema. Selección hecha: descartado. ;-)
 
Y si no, al que no tenga trabajo le da ventaja.

Justamente, si les damos poco tiempo, el que tenga otras obligaciones está en desventaja.
 
Y el tema legal, que no te denuncie nadie diciendo que le haces currar una semana y no le pagas :D

¿Realmente crees que se puede considerar trabajo el resolver el Juego de la Vida de Conway, la KataPotter o cualquiera otro de los miles de ejercicios similares que se pueden plantear y que cada candidato, con su imaginación, puede complicar hasta el infinito con el objetivo de deslumbrarnos? Bueno, si resulta que inventan un algoritmo alucinante para resolver la KataPotter, publicaremos un libro y donaremos los beneficios a la asociación de informáticos workaholics. ;-)


Para mi un día sería suficiente. Un programa suficientemente simple. Suficiente para saber si copia y pega, si es de los que lo hacen a pelo, si es de los que usan frameworks, de los que comenta poco, de los que comenta de más, etc. etc.


Vamos, de los que no te dicen más allá que si no es un tarado. Yo lo que pretendo es descubrir a los que tienen TA-LEN-TO. Me interesa saber hasta dónde son capaces de complicar un problema sencillo sin perder la magia. ;-)
 

Yo soy de los que cree que el talento se ve en la persona. Se puede descubrir talento en quince minutos en un bar con alguien que le entusiasme lo que hace. Respecto al tema legal, lo tendría que decidir un juez, y tendrías que convencerlo a él no a mi :) Pero bueno teniendo en cuenta que el que tiene un trabajo parte con desventaja yo creo que tendrías el caso perdido desde el principio ya sólo por discriminación. No quiero que pienses que te discuto por discutir, te lo digo en serio, en temas de selección hay que tener muchísimo cuidado, hay verdaderos profesionales de las demandas que se ganan su pasta denunciando a empresas que olvidan poner o/a en las ofertas.   

Estoy más con el sistema que hace German. A mi me molaría más el tuyo, pero ya te digo, lo veo un poco utópico.

Saludos,
Martín

harr...@gmail.com

unread,
Jun 30, 2010, 4:55:20 PM6/30/10
to Liste Agile Spain
Podrias precisar por favor el tema de la legalidad. No me queda de todo claro donde ves indicios de ilegalidad. En cualquier proceso de seleccion estas compitiendo con alguien, te estan comparando y toman una decision para el candidato totalmente subjetiva.

Otra cosa es lo de abogados "buscar pies al gato", pero creo que eso no sea un problema de legalidad, sino de abuso de la legalidad y existe en todos los paises.

Slds,
Harald

Enviado desde mi BlackBerry® de Vodafone


From: Martin Perez <mpe...@gmail.com>
Date: Wed, 30 Jun 2010 22:41:55 +0200
Subject: Re: [agile-spain] Mejores formas de contratar talent o (Era: Se busca arquitecto Java EE con interés por metodol ogías ágiles)
--

José Manuel Beas

unread,
Jun 30, 2010, 4:55:52 PM6/30/10
to agile-spain
Entiendo lo que dices, Martín, respecto a la legalidad. Es cierto, yo he estado en procesos de selección donde me preguntaban de qué raza era. Y no para discriminarme sino para proteger a la empresa en caso de disputa sobre racismo en el proceso de selección.

Bien, pero como soy español... resulta que no anuncio que voy a contratar a nadie. Simplemente voy a convocar a todos los que quieran venir a pasar un sábado divertido mostrando sus habilidades. Quizás de allí termine contratando a alguien... quién sabe... ;-)

Un saludo,
Jose Manuel Beas
"Buscando trampas para las leyes desde 1969" ;-)

Rafa de Castro

unread,
Jun 30, 2010, 4:57:39 PM6/30/10
to agile...@googlegroups.com
Nosotros hacemos un examencillo (una pregunta chupada y otra rozando lo imposible, la idea es ver como aproximas la solución y como piensan) y luego una entrevista pero reconozco que los criterios son muy subjetivos. Al final pensándolo bien si volvemos a contratar habrá que hacer lo del portátil. 

Creo que lo del día entero es demasiado hardcore. Solo con la pruebecita con el laptop creo que es más que de sobra y no le metes más presión al entrevistado de la necesaria. ;)

Y otra cosa. Yo no discriminaría para nada a la gente que ya está trabajando. No es complicado ni nada encontrar un profesional que merezca la pena como para sesgar más. El sector es amplio, pero el sector de gente capacitada no lo es tanto...

2010/6/30 Martin Perez <mpe...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.



--
Rafa de Castro
raf...@refugioseguro.com

José Manuel Beas

unread,
Jun 30, 2010, 5:03:51 PM6/30/10
to agile-spain
Define: "que merezca la pena". ¿Cuánto estás dispuesto a gastarte en que esas personas que "merecen la pena" trabajen en tu empresa? ¿Cuánto están dispuestas a hacer ellas por trabajar en la tuya? ¿Es tu empresa lo suficientemente atractiva como para que a ellos les "merezca la pena" hacer un esfuerzo mayor o menor para entrar en tu empresa?

Mi opinión es que la manera más barata de conseguir que a los que "merecen la pena" les "merezca la pena" acercarse a mi empresa es haciendo que gente que "merece la pena" esté en mi empresa. (Dios los cría y yo les ayudo a juntarse) ;-)

Vicenç Garcia

unread,
Jun 30, 2010, 5:06:42 PM6/30/10
to agile...@googlegroups.com
Yo he estado haciendo un proceso de selección ultimamente. Yo era el entrevistador. Que conste que parto sin ninguna experiencia haciendo entrevistas.

Primero era una simple entrevista revisando el curriculum y explicándole de que va la empresa ( que es lo que me hicieron a mi ). Esto no funciona, te la pueden colar por donde sea.

Después fue esto, más un test con preguntas de C# ( buscábamos un programador sénior ). El test tenia 10 preguntas y no puedes abarcar todo. A parte, era demasiado concreto. No funcionó.

Cambié el test por un exámen más completo, con preguntas técnicas, pero no solo de C#, sinó también de POO, patrones de diseño, etc. Este ya me gustó más, pero no acababa de encontrar las preguntas ( o eso, o el nivel de la gente que vino era muy bajo ).

Finalmente he cambiado el examen por tres ejercicios más las preguntas básicas de el examen. Esto me funciona bien. Les dejo media hora solos haciendo los ejercicios y el examen y después lo comentamos entre los dos, mirando las cosas que se ha equivocado y haciéndole preguntas para ver si sabe ir un poco  más allá. Con esto voy más seguro. Quien hace bien los ejercicios y el examen es que es el tio que necesito. Alguien que a la primera no te hace bien los ejercicios, pero que si le vas orientando un poco se sale con la suya, pués también está bien, pq quiere decir que programando por parejas me funcionará bien. Por ahora lo voy a dejar así ( ya se ha acabado el proceso ) pero estoy bastante contento. Igualmente lo mejor seria hacer los ejercicios con portátil ( ahora lo hacen a papel ) pq ves más cosillas.

Esta es mi corta experiencia.

Saludos,

2010/6/30 Rafa de Castro <raf...@refugioseguro.com>

Harald Messemer

unread,
Jun 30, 2010, 5:08:33 PM6/30/10
to agile...@googlegroups.com
A mi me parece excelente de dar la oportunidad a uno de demostrar lo que es capaz de hacer y como se relaciona con su futuro equipo de trabajo. Lo que veo algo teorico es discutir sobre cuantas horas alguien debe dedicar en realizar esta prueba. Vamos, estamos discutiendo sobre objetivos, sobre los inconvenientes de estimar en horas, de pagar por horas y ahora debatimos sobre cuantas horas se necesitan para saber si alguien encaja en un puesto de trabajo. Seamos libres y creativos :-)

Slds,
Harald

2010/6/30 José Manuel Beas <jose....@gmail.com>
Define: "que merezca la pena". ¿Cuánto estás dispuesto a gastarte en que esas personas que "merecen la pena" trabajen en tu empresa? ¿Cuánto están dispuestas a hacer ellas por trabajar en la tuya? ¿Es tu empresa lo suficientemente atractiva como para que a ellos les "merezca la pena" hacer un esfuerzo mayor o menor para entrar en tu empresa?

Harald Messemer

unread,
Jun 30, 2010, 5:10:28 PM6/30/10
to agile...@googlegroups.com
Bien hecho, pero repetiste la última versión con los candidatos que entrevistaste mal. Lo digo por si anda un abogado "listillo" aquí :-)

2010/6/30 Vicenç Garcia <vincen...@gmail.com>

Vicenç Garcia

unread,
Jun 30, 2010, 5:12:08 PM6/30/10
to agile...@googlegroups.com
jejeje, no desgraciadamente no lo hice. Los abogados me van a matar!!!

2010/6/30 Harald Messemer <harr...@gmail.com>

Martin Perez

unread,
Jul 1, 2010, 3:14:15 AM7/1/10
to agile...@googlegroups.com
Harald, 

Quizás no me expliqué del todo bien. El comentario se refería a lo que decía José Manuel de que si a alguien no le gustaban esos métodos o los veían como una competición entonces los excluía y problema arreglado. Y yo intentaba comentar que legalmente no puedes excluir a nadie de un proceso de selección así por así bajo ese tipo de criterios tan subjetivos y que los tendrías que dejar participar igualmente en el proceso y ver si lo hacen bien o mal (lo que en realidad podría echar al traste toda la prueba) antes de tomar una decisión. 

Si se hace como decía José Manuel en su email posterior, como una reunión informal sin convocatoria pública, entonces puedes hacer lo que te de la gana, claro.

Martín

2010/6/30 <harr...@gmail.com>

harr...@gmail.com

unread,
Jul 1, 2010, 3:32:30 AM7/1/10
to Liste Agile Spain
Hola Martin,

A parte que sera dificil de demostrar que alguien ha sido excluido de un proceso de seleccion por discriminacion (raza, sexo, etc - supongo que te refieres a esto), creo que no aplica en nuestro caso.

El mismo proceso de seleccion consiste en excluir candidatos hasta fichar uno de todos los que se han presentado. Lo que JMB no es otra cosa. Recibe 10 CV e invita 2 a sus casa. De los 2 se queda con 1. No lo veo problematico.

Un saludo,

Harald

Enviado desde mi BlackBerry® de Vodafone


From: Martin Perez <mpe...@gmail.com>
Date: Thu, 1 Jul 2010 09:14:15 +0200
Subject: Re: Re: [agile-spain] Mejores formas de contratar ta lento (Era: Se busca arquitecto Java EE con interés por met odologías ágiles)

Martin Perez

unread,
Jul 1, 2010, 3:48:45 AM7/1/10
to agile...@googlegroups.com
Harald, 

No te creas. A lo que tiende la ley es a que son las empresas las que tienen que demostrar que no han discriminado, y no lo contrario. Por eso a José Manuel le han preguntado en una entrevista por su raza, porque aunque parezca absurdo, si no lo hacen no podrán demostrar que no te han discriminado por tu raza. Por eso se pone "camarero/a" en las ofertas de trabajo (todas las agencias son muy cuidadosas con esto), porque si no ponen ese "/a" automáticamente son carne de demanda, ya que nuevamente aunque parezca absurdo no podrás demostrar que no has discriminado al sexo femenino. O por eso mismo la edad está desapareciendo de las ofertas ya que en muchos países como pongas lo típico de 20-30 años estarás discriminando por edad. 

Lo mismo aplica a ser alto/bajo, joven/viejo, simpático/antipático, guapo/feo, gordo/delgado o competitivo/no_competitivo. Así es Europa, me gustaría ponerte referencias pero creo que el tema ya se está alargando más de lo que pretendía ser un mero comentario y que ha derivado en temas legales. Si te/os interesa el tema, en el CIPD (www.cipd.co.uk) tienen mucha información sobre esto. Ahí se pueden encontrar mucha información sobre sentencias y casos de discriminación. Pero bueno, tampoco creo que sea tema para esta lista. 

Saludos!
Martín

Juan Carlos Quijano Abad

unread,
Jul 1, 2010, 4:42:10 AM7/1/10
to agile...@googlegroups.com
Buenas,

Más de 10 años haciendo entrevistas técnicas de RRHH me han llevado a la conclusión de que lo importante es la actitud ante el equipo y al trabajo en grupo y a las relaciones sociales. La destreza técnica se va obteniendo con el tiempo, o ya la tienen.

Y mucho más cuando nuestra profesión lo que sabes ahora en tres o cinco años se ha quedado obsoleto.

Me encanta los métodos de JMB, pero creo que les falta la visión de RRHH y de dirección.

RR.HH: No hay un estudio profesional sobre las actitudes y aptidudes del candidato en la sociedad laboral. Lo dejás al primer contácto entre el candidato y un equipo mosqueado que lo hagan trabajar un sábado ( si, la gente le gusta estár con su mujer, hijos o pareja los sábados). En donde en unas pocas horas se tienen que caer bien o mal. Y que se complica por el ratio de "perros verdes" que tiene nuestra profesión.

No es que quiera mucho a los sicólogos, pero es cierto que estudian una larga carrera para, junto a la experiencia y una bateria de test, poder localizar al perro verde asocial que te va a reventar al equipo o al cliente, o al menos intentar localizarlo.

También olvidas que los procesos de selección son parte del coste del departamento de RRHH y que debe de ser menor que los beneficios reportados por los contratados con exito (que también podriamos hablar del nivel de contratos fallidos). Con el método que propones el coste sería desorbitado si haces una selección de, por ejemplo, 30 candidatos. Y larguísimo en el tiempo.

Dirección: Todo puesto de trabajo en una empresa es motivado por una necesidad que tiene, por definición de lo que debe ser una empresa, un coste máximo.  Es decir, cuando buscas candidatos lo primero es que te encaje en el presupuesto que tienes. Te dá igual encontrar a Bill Gates si el presupuesto para el puesto es de un programador senior. Lo que necesitas es el mejor profesional al menor coste que puedas dentro del máximo que puedes ofrecer. (costes directos o indirectos Inmediatos o futuros.).

Con tus métodos estás buscando gente de una calidad impresionante que todos quisieramos en nuestra empresa, pero que nuestros clientes casi nunca están dispuestos a pagar o nuestros beneficios no lo permiten.

Pero como este debate ha de ser constructivo aquí vá mi propuesta:

Primero hacer un anuncio como el comentado en el otro hilo en donde pongas el listado de las cosas que REALMENTE son en las que se va a trabajar y otro de las que molaría que se tuviera experiencia. Y una descripción de las necesidades sociales, es decir el mínimo que buscamos para que se integre en el equipo y en la filosofía de la emrpesa.

1. Recepción de CV y estudio del mismo.
2. Entrevista personal con RRHH para presentar al empresa y descartar asociales o que no encajen con el espíritu de la empresa.
3. Entrevista técnica en profundidad con pequeño test relacionado con el puesto de trabajo.
4. Ejercicio técnico para llevarselo a casa y que lo devuelva resuelto. No en busca de la calidad técnica, si no que muestra su interés y capacidad de ser parte del equipo. Valorado por dirección técnica.
5. Entrevista final con RRHH y el jefe de proyecto o gestor o cliente.


Ahora mismo lo hago así (menos el anuncio que sigue siendo "el listado de superman"), y me ha funcionado de bastante bien.
--
Un saludo
Juan Quijano
2010/7/1 Martin Perez <mpe...@gmail.com>

Rafa de Castro

unread,
Jul 1, 2010, 5:54:06 AM7/1/10
to agile...@googlegroups.com
A mi siempre me han sentado bastante mal los "listados de supermán". ¿Para que? De hecho en mi empresa contratamos una empresa de RRHH y nos encontramos con que uno de sus anuncios para el puesto que necesitábamos tenían unas siglas que no significaban nada. Yo entiendo que la gente no tiene que saber de todo antes de venir. Entonces, ¿para que lo pido? Sencillamente me estoy cargando a la gente honrada que como no cumple no intenta entrar y acepto a jetas que dicen que hacen de todo que luego tendré que filtrar con el consiguiente ratio de error...



2010/7/1 Juan Carlos Quijano Abad <juancarl...@gmail.com>



--
Rafa de Castro
raf...@refugioseguro.com

Jorge Uriarte Aretxaga

unread,
Jul 1, 2010, 6:22:19 AM7/1/10
to agile...@googlegroups.com
2010/7/1 Rafa de Castro <raf...@refugioseguro.com>

A mi siempre me han sentado bastante mal los "listados de supermán". ¿Para que? De hecho en mi empresa contratamos una empresa de RRHH y nos encontramos con que uno de sus anuncios para el puesto que necesitábamos tenían unas siglas que no significaban nada. Yo entiendo que la gente no tiene que saber de todo antes de venir. Entonces, ¿para que lo pido?

Aunque estoy de acuerdo con que pedir un montón de siglas en un anuncio no ayuda, yo confieso que alguna vez he usado una lista (de varios folios!) durante las entrevistas... es una especie de juego. 

La cosa funciona así.
Primero, explicamos que vamos a ir recorriendo esas siglas, y que me gustaría que me digan si saben o no lo que son. Que no es un test sino un guión que vamos a usar, y que el objetivo es que pregunten todas las dudas que se les ocurran sobre el tema, que no se espera que "se las sepan", sino que las usaremos para poder hablar de tecnología un rato, y conocernos.

Si lo conocen o "les suena", etc.., suelo pedir que expliquen rápidamente qué es... para qué se usa... qué problemas resuelve... si no los saben a priori, se les explica en pocas palabras, y se les pregunta lo mismo "para qué crees que se usa", "qué problema resolvería esto", se les plantean casos problemáticos en los que podrían aplicar, etc...

El test deriva hacia una conversación si todo va bien... y así vamos conociéndonos mejor.
El resultado no es cuantitativo sino cualitativo y, aunque sujeto a error, me sirve para esbozar:
- Entusiasmo o carencia del mismo.
- Comprensión de los problemas a resolver mediante las tecnologías (algo más importante de lo que parece!)
- Nivel conversacional de la persona (nada despreciable!)
- Capacidad para entender las explicaciones sobre lo que no entienden y aplicarlas a su experiencia.

Ahora bien, esto no sirve como criba inicial, porque requiere tiempo (si todo va decentemente, un mínimo de hora y media de charla). Pero me ayuda a hacerme una idea acerca de la persona, y a él tambien (porque si es posible, las explicaciones se aplican al proyecto/entorno al que se piensa en incorporar a la persona, y sirve para darle más información)

La temática puede incluir de todo... frameworks, sistemas operativos, metodologías, relaciones de equipo, etc... cualquier cosa puede servir, y esa lista la podemos trabajar a priori más o menos.

Me gusta complementarlo con pedirles que expliquen un proyecto en el que hayan trabajado, algo que les guste cómo se hizo, algo que no les guste... y ahí se nos va otra hora y pico, seguro, porque la idea es esa, conocernos un poco...

Eso sí; la clave es no considerar esto un test que va a devolver una nota numérica, sino una excusa para hacer una evaluación general de aspectos muy diferentes y sacar una impresión (que como todas, es subjetiva... pero es *mi* subjetiva ;) )
Pensé en formalizarlo... pero creo que sería mucho peor. La clave es que la conversación fluya, y que tanto el entrevistador como el entrevistado se examinen en un marco lo más parecido posible a una conversación de trabajo normal.

En fin... de todos modos este método sigue sin tocar el primer paso, la selección previa... y ahí se *pierden* muchas grandes posibilidades.

_
Jorge

José Manuel Beas

unread,
Jul 1, 2010, 6:31:58 AM7/1/10
to agile-spain
On 1 July 2010 10:42:10 UTC+2, Juan Carlos Quijano Abad <juancarl...@gmail.com> wrote:
Buenas,

Más de 10 años haciendo entrevistas técnicas de RRHH me han llevado a la conclusión de que lo importante es la actitud ante el equipo y al trabajo en grupo y a las relaciones sociales. La destreza técnica se va obteniendo con el tiempo, o ya la tienen.
 
Y mucho más cuando nuestra profesión lo que sabes ahora en tres o cinco años se ha quedado obsoleto.


Discrepo. El libro del GoF ¿de cuándo es? ¿Ha cambiado mucho? ¿Y hacer TDD? ¿Cuánta gente ha quedado obsoleta por hacer TDD? :-(
 
Me encanta los métodos de JMB, pero creo que les falta la visión de RRHH y de dirección.


¡Uy lo que me ha dicho! :-O
 
RR.HH: No hay un estudio profesional sobre las actitudes y aptidudes del candidato en la sociedad laboral. Lo dejás al primer contácto entre el candidato y un equipo mosqueado que lo hagan trabajar un sábado ( si, la gente le gusta estár con su mujer, hijos o pareja los sábados). En donde en unas pocas horas se tienen que caer bien o mal. Y que se complica por el ratio de "perros verdes" que tiene nuestra profesión.


¿Un equipo mosqueado? ¿Que los hago TRABAJAR un sábado? Mmmm, creo que no has entendido nada de mi planteamiento. No estoy contratando gente así. Quiero que a mi grupo excelente se QUIERAN unir gente excelente. ¿Cuál es la perspectiva de RRHH (¿recursos humanos?) que le falta a mi propuesta?
 
No es que quiera mucho a los sicólogos, pero es cierto que estudian una larga carrera para, junto a la experiencia y una bateria de test, poder localizar al perro verde asocial que te va a reventar al equipo o al cliente, o al menos intentar localizarlo.


Yo tampoco es que quiera mucho a los ingenieros en informática (quizás pq soy licenciado en informática), pero es cierto que estudian una larga carrera para, junto a la experiencia y una cantidad ingente de código fuente y configuraciones... entregarle al cliente una m.... Vamos, ¡venga ya!  ¿Es ese tu mejor argumento? ;-)

También olvidas que los procesos de selección son parte del coste del departamento de RRHH y que debe de ser menor que los beneficios reportados por los contratados con exito (que también podriamos hablar del nivel de contratos fallidos). Con el método que propones el coste sería desorbitado si haces una selección de, por ejemplo, 30 candidatos. Y larguísimo en el tiempo.


Creo que esto ya lo comenté al principio del hilo. Los costes es fácil. ¿Y los beneficios? Mi enfoque "lean" busca reducir los costes futuros porque el candidato (futuro empleado) no encaje finalmente en la organización. En cualquier caso, tampoco he dicho que mi propuesta escale a empresas más grandes. 
 
Dirección: Todo puesto de trabajo en una empresa es motivado por una necesidad que tiene, por definición de lo que debe ser una empresa, un coste máximo.  Es decir, cuando buscas candidatos lo primero es que te encaje en el presupuesto que tienes. Te dá igual encontrar a Bill Gates si el presupuesto para el puesto es de un programador senior. Lo que necesitas es el mejor profesional al menor coste que puedas dentro del máximo que puedes ofrecer. (costes directos o indirectos Inmediatos o futuros.).


Yo no he hablado de la negociación por la pasta. Lo que trato en mis propuestas es de darle menos importancia a esto porque creo que ya quedó claro que no es un elemento especialmente relevante para la motivación de un trabajador del conocimiento. No quiero decir que no sea algo importante, pero no puede ser lo más relevante en el proceso de selección.

Lo que sí tengo claro es que nunca contrataría para cubrir una necesidad a corto plazo (porque me ha salido o está a punto de salir un contrato importante y necesitamos un especialista en la herramienta tal o la tecnología pascual). Justamente trato de que huyamos de ese modelo. Supongo que a todos nos gustaría que nos contrataran porque "encajamos", o como decía alguien antes, porque "nos merece la pena" unir nuestras vidas laborales (la del empleado y la de la empresa). Si pensamos en relaciones a largo plazo, todo lo que dices no tiene ningún sentido.
 
Con tus métodos estás buscando gente de una calidad impresionante que todos quisieramos en nuestra empresa, pero que nuestros clientes casi nunca están dispuestos a pagar o nuestros beneficios no lo permiten.


¿Quién ha dicho que ser de una calidad impresionante signifique extremadamente caro? Es más. ¿Quién ha dicho que contratar a alguien que proporciona una calidad impresionante en sus trabajos vaya en contra de nuestros beneficios? Una vez más, míralo desde una perspectiva "lean" y verás que tengo razón.
 
Pero como este debate ha de ser constructivo aquí vá mi propuesta:

Primero hacer un anuncio como el comentado en el otro hilo en donde pongas el listado de las cosas que REALMENTE son en las que se va a trabajar y otro de las que molaría que se tuviera experiencia. Y una descripción de las necesidades sociales, es decir el mínimo que buscamos para que se integre en el equipo y en la filosofía de la emrpesa.

1. Recepción de CV y estudio del mismo.
2. Entrevista personal con RRHH para presentar al empresa y descartar asociales o que no encajen con el espíritu de la empresa.
3. Entrevista técnica en profundidad con pequeño test relacionado con el puesto de trabajo.
4. Ejercicio técnico para llevarselo a casa y que lo devuelva resuelto. No en busca de la calidad técnica, si no que muestra su interés y capacidad de ser parte del equipo. Valorado por dirección técnica.
5. Entrevista final con RRHH y el jefe de proyecto o gestor o cliente.


¿Has sumado las horas de diferentes personas involucradas en este proceso? ¿Y cuál es el resultado? Que al final terminas contratando a alguien al que no has visto trabajar nunca. Sólo sabes que tiene la labia suficiente como para venderse bien durante todo el proceso y que pide el suficiente poco dinero como para que resulte "viable la adquisición del nuevo recurso". :-(
 

Ahora mismo lo hago así (menos el anuncio que sigue siendo "el listado de superman"), y me ha funcionado de bastante bien.

¿Te ha funcionado bastante bien? No es eso lo que destila de tus planteamientos cuando hablas de que la gente está quemada o que no está dispuesta a emplear un sábado para comprobar si un posible nuevo compañero encajará en la empresa. ;-)

--
Un saludo
Juan Quijano


Jorge Uriarte Aretxaga

unread,
Jul 1, 2010, 6:43:50 AM7/1/10
to agile...@googlegroups.com
2010/7/1 José Manuel Beas <jose....@gmail.com>

On 1 July 2010 12:22:19 UTC+2, Jorge Uriarte Aretxaga <jorge....@gailen.es> wrote:
En fin... de todos modos este método sigue sin tocar el primer paso, la selección previa... y ahí se *pierden* muchas grandes posibilidades.


Jorge, ¿qué quieres decir con lo de "la selección previa"?


Que no puedo aplicar este sistema a 200 personas, porque me lleva 800 horas "mías"... :'(
Por eso necesito que a grandes rasgos haya una criba o selección previa... y ahí puedo cometer muchos errores...
Es decir, el sistema funciona (emho) para evaluar a las personas, pero no para extraer un grupo de 10 candidatos a entrar a un equipo de entre 1000 CVs apilados en la web de turno, todos ellos "mentira" (unos por exageración, otros por prudencia o porque es imposible plasmar con fiabilidad en un papel determinadas características personales...)

Sistemas previos; el CV, vampiempresas de rrhh... no me molan... las recomendaciones pueden funcionar decentemente... búsqueda en comunidades afines puede ser buena idea... 

José Manuel Beas

unread,
Jul 1, 2010, 6:57:13 AM7/1/10
to agile-spain
On 1 July 2010 12:43:50 UTC+2, Jorge Uriarte Aretxaga <jorge....@gailen.es> wrote:
2010/7/1 José Manuel Beas <jose....@gmail.com>


On 1 July 2010 12:22:19 UTC+2, Jorge Uriarte Aretxaga <jorge....@gailen.es> wrote:
En fin... de todos modos este método sigue sin tocar el primer paso, la selección previa... y ahí se *pierden* muchas grandes posibilidades.


Jorge, ¿qué quieres decir con lo de "la selección previa"?


Que no puedo aplicar este sistema a 200 personas, porque me lleva 800 horas "mías"... :'(

¿Quieres decir que te podrían aparecer 200 candidatos? Bueno, eso sería un problema en tu caso. Incluso en la propuesta que yo hago podría llegar a serlo (si hubiera que darles un PC y un bocata a cada uno saldría por una pasta) ;-)

En serio, creo que la clave está en hacer que NO se presenten 200. Que el que se presente tenga claro que va a tener que hacer también una inversión en averiguar si quiere entrar en mi empresa.
 

Sistemas previos; el CV, vampiempresas de rrhh... no me molan... las recomendaciones pueden funcionar decentemente... búsqueda en comunidades afines puede ser buena idea... 


Lo de las recomendaciones... antes me lo tomaba en serio, pero después de ver alguna recomendación en LinkedIn... he perdido la fé en las recomendaciones. :-(

Al final, vamos a una especie de modelo "enséñame tu book de fotos" (es decir, enséñame cómo es el código que haces).

Por si sirve de idea. Yo he utilizado (debo decir que con unos resultados excelentes) una prueba de selección basada en el TestFirstChallenge.

Dejaba claro que el que valía, valía, y el que no tenía ni idea, no tenía ni idea.
Los de enmedio, la mayoría, los evaluábamos nosotros, echando un vistazo al código. Teníamos una infame hoja de cálculo para simular que era algo objetivo pero... :-P

Hicimos la prueba antes de "ponerlo en producción" con todo el departamento de desarrollo y fue estupendo comprobar como, durante una hora, el que sabía, sabía, y el que no tenía ni idea, no tenía ni idea. :-)

Coste/beneficio yo diría que aceptable. Pero había que complementarlo con entrevistas personales, claro. (Afortunadamente inevitables) ;-)

--

Jonathan Vila Lopez

unread,
Jul 5, 2010, 4:24:29 AM7/5/10
to agile...@googlegroups.com
Beas, estas pruebas prueban la parte de "la inteligencia emocional o social" de los candidatos ? es decir, sabe un monton pero no es un hombre de equipo, o tiene demasiado ego, o no comunica bien, o se lleva mal con los compañeros, etc, etc..........que basicamente es lo que genera la mayoria de despidos o problemas en el equipo y no su nivel tecnico, que ademas es muy facil de obtener si crees en el candidato....

Por cierto el metodo que apuntais de personas que hacen una prueba de varios dias, supongo que solo tiene en cuenta a los que estan en el paro, no ? porque a los que curran ( yo me cuentro entre ellos ) como les pidas que dediquen 5 dias a una compañia de la que aun no saben si les gustara, y por lo que si tienen 3 ofertas iguales se funden las vacaciones , el candidato te dira que esta muy bien pero que ya le llamara si acaso...... vamos, es lo que yo haria.


-----------------------------------------------
Slitzweitz !!!!!!

juanc

unread,
Jul 5, 2010, 9:03:11 AM7/5/10
to agile...@googlegroups.com
Buen dia necesitaria para una investigacion que estoy llevando a cabo sobre scrum, nombre de empresas o equipos de personas que trabajen con scrum,tanto en españa como en otro pais ,gracias por su colaboracion saludos !!

 

German DZ

unread,
Jul 5, 2010, 9:19:19 AM7/5/10
to agile...@googlegroups.com
Buenas Juan C,

Sería importante que te presentaras, que cuentes para que es esa información, que tratamiento se le dará, quien se beneficiará, etc. Así tal vez animes a que alguien conteste, esto de internet va de recibir pero también de ofrecer, sino el balance se pierde.

Seguramente obtendrás mejores respuestas si guías el pedido y lo haces respetuosamente y con un marco de validez.


Saludos


2010/7/5 juanc <juanc2...@yahoo.com.ar>
Buen dia necesitaria para una investigacion que estoy llevando a cabo sobre scrum, nombre de empresas o equipos de personas que trabajen con scrum,tanto en españa como en otro pais ,gracias por su colaboracion saludos !!

 

--

Juan Carlos Quijano Abad

unread,
Jul 5, 2010, 9:28:53 AM7/5/10
to agile...@googlegroups.com
http://www.quadramqs.com/ 
Perfil de Linkedin

Mi empresa actual.

--
Un saludo
Juan Quijano
El 5 de julio de 2010 15:03, juanc <juanc2...@yahoo.com.ar> escribió:
Buen dia necesitaria para una investigacion que estoy llevando a cabo sobre scrum, nombre de empresas o equipos de personas que trabajen con scrum,tanto en españa como en otro pais ,gracias por su colaboracion saludos !!

 

--

juanc

unread,
Jul 6, 2010, 7:03:02 AM7/6/10
to agile...@googlegroups.com
Muchas gracias por tu amabilidad Juan Carlos,al igual que a Ricardo y Alejandra por su colaboracion.
                                                                                         saludos !!
 
                               

--- El lun 5-jul-10, Juan Carlos Quijano Abad <juancarl...@gmail.com> escribió:
Reply all
Reply to author
Forward
0 new messages