[agile-spain] Premio vs castigo

[Francisco Manuel Maldonado]

Hola a todos:

Me permito presentarme: Mi nombre es Maldonado y soy responsable de programación de una empresa de desarrollo web que está actualmente inmersa en proceso de adaptación de metodologías ágiles y, en general, de mejorar los procesos de gestión de proyectos desde la programación.

Puesto que estamos ahora mismo en condiciones de aprender más que de aportar, me tomo el atrevimiento de plantear al grupo algunas cuestiones que nos inquietan:

- Se ha hablado frecuentemente de la resistencia del equipo de desarrollo al cambio. En general, observo que el programador no está  abierto a que le hagan observaciones/exigencias en la forma de hacer su trabajo y hay que plantear estas cosas con mucho tacto. Al respecto, dudamos en  emplear como revulsivo el premio o el castigo. Es decir, bonificar de alguna forma (incentivos económicos, reconocimiento púbico, etc) el trabajo bien hecho (el concepto de trabajo bien hecho que manejamos ahora mismo es el de incidencias reportadas por el cliente aunque como he comentado estamos incorporando otos criterios: calidad de código, seguimiento del estandar de codificación propuesto, capacidad de reutilización, etc) o por el contrario castigar el no cumplimiento de esos criterios.

- Alguién del grupo tiene experiencia en la gestión de equipos de desarrollo desolcalizados? Hay varios programadores trabajando sobre un mismo proyecto pero cada uno está al cargo de tareas independientes. Aunque hay comunicación no es habitual que un programador utilice o evalúe el código generado por otro. Además no están físicamente juntos.

- ¿Que auditoría se puede realizar sobre el trabajo realizado (código) por otros programadores? ¿Que herramientas utilizáis y que criterios son valorables?

Un abrazo

[jcesarperez]

Hola Maldonado y bienvenido al grupo.

Depende mucho de las personalidades de tu gente. Necesitas mucho tacto
y empatía. Pero por lo general yo no recomendaría una estrategia
basada en premios y castigos, mucho menos en algo tan subjetivo como
la calidad del código. El tema de bugs sí me parece más objetivo y
propenso a experimentar en forma de premios, pero no de castigos.

Aunque no creo que se puedan sacar normas en este tema, yo sí que me
atrevería a señalar que cualquier medida debe tener la aprobación de
todo el equipo. Se hace una reunión, se presenta la idea o medida,
ventajas y desventajas, se debate y finalmente se vota.

Yo lo que te recomendaría, desde mi experiencia, es una estrategia muy
gradual basada en fijar unas métricas mínimas que tiene que tener el
código. Empezaría con algo sencillo en cuanto a herramientas, como
cobertura de tests (30-40% si hasta ahora no haceis tests) y número de
violaciones de FindBugs (¿usais Java?). Todo esto en un entorno de
integración continua, con el tiempo puedes ir añadiendo otras
herramientas (checkstyle, pmd, etc.) y subiendo las métricas.

Las herramientas están bien para hacer revisiones de las partes más
rutinarias, pero no hacen una revisión completa ya que no se meten en
temas de diseño, más allá de alguna metrica en cuanto a tamaños y
número de dependencias. Necesitas establecer también una política de
revisiones manual, haciendo pair-programming entre programadores (por
tus comentarios parece que ahora cada programador desarrolla su código
de forma aislada) o con una figura de lider técnico del proyecto.

Lo que hay que tener claro es que no se puede aumentar la calidad del
código si no se dedican más recursos (tiempo, personas, etc).

Nosotros hace unas semanas hemos empezado una iniciativa que hemos
llamado Nuestros Coding Horrors. Consiste en publicar en la lista de
correo un trozo de código especialmente horroroso que te hayas
encontrado. El objetivo no es señalar al autor (está prohibido), es
discutir posibles soluciones y *aprender* entre todos. Es sólo un
experimento, en el momento que vea mal rollo lo cortaré. Pero de
momento todos estamos de acuerdo en probarlo.

Espero haberte ayudado, aunque de equipos deslocalizados no tengo
experiencia. Cualquier cosa me preguntas.

Saludos,
Julio.

On 26 mar, 08:09, Francisco Manuel Maldonado

[Alfredo Casado]

En mi opinión el tema del palo y la zanahoria no funciona, puede dar un pequeño empuje inicialmente pero no creo que sea sostenible e incluso puede ser perjudicial en el medio plazo, siempre que oigo el tema de los incentivos recomiendo este libro: Drive. Es de obligada antes de plantear medidas de este tipo, quizas os haga cambiar de opinión al respecto.

La cosa es que si quereis mejorar la calidad del desarrollo (tanto externa reflejada en el número de incidencias como interna con otros criterios de calidad), en mi opinión y por lo que cuentas tenéis otros frentes que atacar más prioritarios:

- Necesitáis que el equipo (cada uno) tenga como minimo alguien que lidere el cambio en el ambito técnico, tener claro que el cambio no se va a producir si no hay alguien que tira del carro y convence al resto de hacerlo, tiene que ser alguien que tenga experiencia aplicando técnicas de ingeniería ágil (TDD, IC) y que tenga capacidad para ayudar al resto del equipo ha hacerlo. En su defecto, si no contáis con un experto, por lo menos necesitáis alguien con ganas de aprender y cambiar que tire de los demás en el ambito técnico. Personalmente veo muy difícil que un equipo cambie sus hábitos técnicos sin alguien que les ayude, aunque no conozco el nivel de experiencia de los equipos. 

- En temas más concretos, antes incluso de TDD necesitáis olvidaros de eso de "cada uno se dedica a una parte de la aplicación", la propiedad colectiva es en mi opinión una practica fundamental, sin propiedad colectiva no hay equipo, y sin equipos no hay agile ni nada que se le parezca, hay un conjunto de gente cada uno haciendo la guerra por su cuenta. Este cambio parece más difícil de lo que luego en realidad es, podéis empezar simplemente cambiando las tareas a la gente y que cada uno coja algo que no tenga nada que ver con "su parte". Esto duele un poco al principio, pero no hay mejora sin un poco de dolor :P

- Si no tenéis integración continua montarla ya, suele le ser la practica más facil de poner en marcha y aporta muchos beneficios.

- Sobre métricas y tal, esto es muy dependiente de la tecnología y de donde estéis ahora. De todos modos,yo antes de las métricas de cobertura empezaría por cosas más básicas, por ejemplo la duplicación de código, tamaños de clase/función etc,etc. Aunque aqui necesitas de nuevo al lider técnico que sepa interpretar estas métricas y transmitir al equipo la importancia de mejorarlas, las métricas pueden servir como argumento a ese lider, pero no sirve de mucho sacar un montón de métricas y poner criterios arbitrarios, al final la gente encuentra formas de esquivar las métricas que en lugar de ser una "ayuda" son vistas como el "enemigo".

--
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.

[Jose R.]

Hola,

 Yo trataría no usar premios y castigos. Desde mi percepción, ambos acaban desmotivando. El premio por que a alguien le das más que a otro, o por que les parece pequeño. Y el castigo, por que no siempre se es justo.
 La táctica que he encontrado más adecuada pra este tipo de cambios es conseguir que salgan del propio equipo. Lidera un pequeño grupo de personas, de dentro de los equipos, con el fin de que sean ellos los que vayan implantando las técnicas o tácticas en cada equipo. Dales poder de decisión, y de difusión. Si no controlan mucho todavía, dales tiempo de autoformación, y pon a alguien más experto que les ayude.
 Que sienten que tiren del carro, que su trabajo lo valoran el resto de la gente de los equipos.
 No planteeis las cosas que quereis que hagan. Haced que ellos se planteen las cosas que quieren mejorar, aprender y practicar. Es un proceso mucho más gratificante para ellos, no lo como algo impuesto, y es más motivador.

 En definitiva, confía/respeta a la gente, y dales la oportunidad de responsabilizarse de su propia mejora continua.

 Un saludo!
 
   Jose Ramón
   http://najaraba.blogspot.com

2011/3/26 Francisco Manuel Maldonado <fmanuel....@gmail.com>

--

[José Manuel Beas]

2011/3/26 Jose R. <jrr...@gmail.com>

 En definitiva, confía/respeta a la gente, y dales la oportunidad de responsabilizarse de su propia mejora continua.

Lo cuál implica que todos (TODOS) deben estar dispuestos a equivocarse. ;-)

Un saludo,
Jose Manuel Beas

http://agilismo.es

http://jmbeas.iexpertos.com

http://twitter.com/jmbeas

 

[Ángel Medinilla]

 

2011/3/26 Alfredo Casado <casado....@gmail.com>

En mi opinión el tema del palo y la zanahoria no funciona, puede dar un pequeño empuje inicialmente pero no creo que sea sostenible e incluso puede ser perjudicial en el medio plazo, siempre que oigo el tema de los incentivos recomiendo este libro: Drive. Es de obligada antes de plantear medidas de este tipo, quizas os haga cambiar de opinión al respecto.

Video resumen de las tésis del libro (que comparto al 110%):

 http://www.youtube.com/watch?v=u6XAPnuFjJc

 

[José Manuel Beas]

También puedes releer los hilos de este foro:

https://groups.google.com/group/agile-spain/browse_thread/thread/7e594b8303825763?hl=es

https://groups.google.com/group/agile-spain/browse_thread/thread/0bd950cc3c6bd76c/3f8d8b215077507f?hl=es%03f8d8b215077507f

(Donde muchas de las cosas que se han dicho en éste ya se habían dicho entonces)

Un saludo,
Jose Manuel Beas

http://agilismo.es

http://jmbeas.iexpertos.com

http://twitter.com/jmbeas

2011/3/26 Ángel Medinilla <angel.m...@gmail.com>

http://www.youtube.com/watch?v=u6XAPnuFjJc

[Carlos Ble]

Da gusto leer hilos como este, que pasada. Asi uno aprende y vale la
pena el foro. Felicidades a todos, es para quitarse el sombrero :-)

On 26 mar, 18:25, José Manuel Beas <jose.m.b...@gmail.com> wrote:
> También puedes releer los hilos de este foro:https://groups.google.com/group/agile-spain/browse_thread/thread/7e59...
> <https://groups.google.com/group/agile-spain/browse_thread/thread/7e59...>https://groups.google.com/group/agile-spain/browse_thread/thread/0bd9...
>
> <https://groups.google.com/group/agile-spain/browse_thread/thread/0bd9...>(Donde

> muchas de las cosas que se han dicho en éste ya se habían dicho entonces)
>
> Un saludo,
> Jose Manuel Beas
>
> http://agilismo.eshttp://jmbeas.iexpertos.comhttp://twitter.com/jmbeas
>

> 2011/3/26 Ángel Medinilla <angel.medini...@gmail.com>
>
> >http://www.*youtube*.com/watch?v=u6XAPnuFjJc

[Carlos Ble]

Me quedé tan flipado que no comenté nada mas en mi mensaje anterior.

Queria añadir que la figura del lider tecnico no la comparto demasiado
si se trata de un puesto fijo. Si es para poco tiempo (maximo 6
meses), como agente del cambio y sobre todo si es externo, tiene
sentido. Un coach XP parece que encaja bien ahi. Si le haces fijo,
puede ser contraproducente a la hora de hacer un verdadero equipo
autogestionado. Al mismo tiempo se corre el riesgo de que se acomode y
adopte malos hábitos en lugar de contagiar los buenos.

Con respecto a lo de mostrar horrores de código, ¿que tal si cada uno
sólo comentase su propio código? Así se fomenta la autocrítica, la
humildad y el espiritu de mejora. Ten en cuenta que si la empresa o el
codigo no es muy muy grande, es probable que cuando se comente el de
alguien, ese alguien lo reconozca y no se sienta muy bien con las
criticas, sobre todo porque pueden estar fuera de contexto.
Conviene que en los equipos se hable con total transparencia de las
personas, con sus nombres. Nada a las espaldas. Y siempre desde el
respeto. Mostrar codigo "anonimo" podria parecer algo desleal. Me da
un poco de mal rollo.
Como lo ideal es que se programe en pareja lo maximo posible... tal
vez si una pareja hace comentarios sobre el código de otra y se dice
claramente quiénes son la pareja que ha hecho el código que está
siendo evaluado, hay mas transparencia y menos lugar para las criticas
destructivas. Además las 4 personas pueden dialogar, argumentar y
mantener un nivel de tension saludable.

Saludos :-)




On 26 mar, 10:56, jcesarperez <julio.cesar.perez.arq...@gmail.com>
wrote:

[Martin Perez]

Me han gustado tus comentarios Carlos, te comento entre líneas. 

2011/3/26 Carlos Ble <ble.j...@gmail.com>

Me quedé tan flipado que no comenté nada mas en mi mensaje anterior.

Queria añadir que la figura del lider tecnico no la comparto demasiado
si se trata de un puesto fijo. Si es para poco tiempo (maximo 6
meses), como agente del cambio y sobre todo si es externo, tiene
sentido. Un coach XP parece que encaja bien ahi. Si le haces fijo,
puede ser contraproducente a la hora de hacer un verdadero equipo
autogestionado. Al mismo tiempo se corre el riesgo de que se acomode y
adopte malos hábitos en lugar de contagiar los buenos.

El problema es que aunque no tengamos figura de líder técnico, la cruda realidad es que siempre lo hay, si no es explícito, será implícito. 

La figura de líder técnico y como implementarla daría para hablar horas y horas. En mi opinión, y por eso comento, la figura de líder técnico es muy importante. Es cierto que si se asienta corres el riesgo de que tanto él como el equipo se acomoden y de que se adquiera demasiada dependencia de esa persona. Pero es que entonces... estamos ante un mal líder técnico. 

Un buen líder técnico no debe de ser autoritario y debe dejar al resto del equipo tomar sus decisiones y tomar responsabilidades (siempre que no estén metiendo terriblemente la pata). Un buen líder técnico debe saber darle responsabilidad al equipo y dejar que se autogestione, aunque tome decisiones que van contra sus preferencias personales (Equipo: queremos hacer esto en Ruby, Líder Malo: Ni de coña, Java es lo mejor y no podemos usar otra cosa, Líder bueno: Vale, creo que puede funcionar, probaremos una semana, pero Pepe tu te encargas de esto, y Juan tu de esto, y tener en cuenta que como es nuestro primer proyecto tendréis que currar mucho más para coger velocidad). En definitiva, un buen líder técnico, en mi opinión, debe ser uno más del equipo pero al mismo tiempo dirigirlo.

Con respecto a lo de mostrar horrores de código, ¿que tal si cada uno
sólo comentase su propio código? Así se fomenta la autocrítica, la
humildad y el espiritu de mejora. Ten en cuenta que si la empresa o el
codigo no es muy muy grande, es probable que cuando se comente el de
alguien, ese alguien lo reconozca y no se sienta muy bien con las
criticas, sobre todo porque pueden estar fuera de contexto.
Conviene que en los equipos se hable con total transparencia de las
personas, con sus nombres. Nada a las espaldas. Y siempre desde el
respeto. Mostrar codigo "anonimo" podria parecer algo desleal. Me da
un poco de mal rollo.
Como lo ideal es que se programe en pareja lo maximo posible... tal
vez si una pareja hace comentarios sobre el código de otra y se dice
claramente quiénes son la pareja que ha hecho el código que está
siendo evaluado, hay mas transparencia y menos lugar para las criticas
destructivas. Además las 4 personas pueden dialogar, argumentar y
mantener un nivel de tension saludable.

Muy de acuerdo en esto. El tema de las revisiones de código es muy peliagudo. Hace tres años más o menos ( diantres, como pasa el tiempo )  escribía sobre el tema. Perdón por la cuña (http://brigomp.blogspot.com/2008/02/code-reviews-buena-o-mala-idea.html). Básicamente lo que yo recomendaría es introducir herramientas de análisis estático. 

Muchos de los errores más importantes los pueden detectar estas herramientas automáticamente, y nadie se va a sentir especialmente herido por ello. No es lo mismo que venga el listillo de Martín y Carlos y le diga al pobre Pepito que su código apesta, que que venga Findbugs y te muestre tus vergüenzas. En el primer caso Pepito se puede sentir herido y atacado. En el segundo caso todo lo que puede hacer Pepito será cagarse en el cabroncete de Findbugs. 

 

Un saludo,

Martín

--
Martín Pérez

Founder,
http://www.jobsket.com

[Carlos Ble]

Gracias por compartir el link Martin :-) cuñas interesantes como esas,
las agradezco.

Se ve que lo de lider da para mucha discusión. Al leerte me da
sensacion de que en verdad quieres decir "facilitador", o "scrum
master", algo asi ;-)
Aunque en los equipos siempre haya gente que destaca mas, mi forma de
entender XP es que yo enseño y aprendo de los demas y tratamos de
igualarnos y superarnos juntos. El resultado en nuestro proyecto esta
siendo genial porque cuando uno no puede estar al pie del cañon,
descansa tranquilo. Todos aprendemos de todos. La cuestion es que en
pocos sitios se practica de verdad XP. No se programa en pareja, no
hay verdadera propiedad colectiva de código...

Yo apuntaria a lo que dice Joserra ;-)

Saludos cordiales

On 26 mar, 20:47, Martin Perez <mper...@gmail.com> wrote:
> Me han gustado tus comentarios Carlos, te comento entre líneas.
>

> 2011/3/26 Carlos Ble <ble.jur...@gmail.com>

[Jorge Uriarte Aretxaga]

> Con respecto a lo de mostrar horrores de código, ¿que tal si cada uno
> sólo comentase su propio código? Así se fomenta la autocrítica, la
> humildad y el espiritu de mejora. Ten en cuenta que si la empresa o el
> codigo no es muy muy grande, es probable que cuando se comente el de
> alguien, ese alguien lo reconozca y no se sienta muy bien con las

> criticas [...]

> Conviene que en los equipos se hable con total transparencia de las
> personas, con sus nombres. Nada a las espaldas. Y siempre desde el
> respeto. Mostrar codigo "anonimo" podria parecer algo desleal. Me da
> un poco de mal rollo.

Carlos; ¿no son ambos enfoques ("cada uno lo suyo para autocrítica y
no molestar" y "total transparencia") en cierto modo opuestos?
Es decir, no hacer algo que podría molestar no es reducir la
transparcencia, evitar una faceta comunicativa por potencialmente
problemática?

A mi me gusta que en las revisiones de código se hable, se opine
libremente. En ese sentido, si cada uno presenta su código y los demás
opinan, se crea un debate saludable y sobre todo se encuentran puntos
de encuentro, nuevas practicas que el equipo puede adoptar.
Se sube el nivel común, el equipo aprende, el proceso evoluciona.

Esta claro que si hay un perfil especialmente sensible o especialmente
agresivo, se pueden producir problemas. Pero ya cruzaremos ese puente,
¿por qué ponernos la venda antes que la herida?

A priori, transparencia, y libertad de critica dentro de un contexto
sano. Si hay disfuncionaldades en el equipo, el problema no es
particular de las revisiones sino general de las relaciones del
equipo, y como tal debemos abordarlo.

Abrazo!!!

--

_
Jorge Uriarte Aretxaga
http://www.gailen.es
http://www.linkedin.com/in/jorgeuriarte

[Carlos Ble]

Quise decir que cada uno muestra en publico su propio código. Todos lo
comentan en grupo. Si el ambiente es bueno y el grupo es pequeño,
pueden comentar el codigo de otros, pero cada grupo es diferente y en
principio prefiero recomendar precaucion :-)

Un abrazo

On 26 mar, 21:52, Jorge Uriarte Aretxaga <jorge.uria...@gailen.es>
wrote:

[Abel Muiño Vizcaino]

Hola Maldonado y ¡bienvenido!

Te contesto entre lineas a cada punto…

El 26/03/2011, a las 08:09, Francisco Manuel Maldonado escribió:

- Se ha hablado frecuentemente de la resistencia del equipo de desarrollo al cambio. En general, observo que el programador no está  abierto a que le hagan observaciones/exigencias en la forma de hacer su trabajo y hay que plantear estas cosas con mucho tacto. Al respecto, dudamos en  emplear como revulsivo el premio o el castigo. Es decir, bonificar de alguna forma (incentivos económicos, reconocimiento púbico, etc) el trabajo bien hecho (el concepto de trabajo bien hecho que manejamos ahora mismo es el de incidencias reportadas por el cliente aunque como he comentado estamos incorporando otos criterios: calidad de código, seguimiento del estandar de codificación propuesto, capacidad de reutilización, etc) o por el contrario castigar el no cumplimiento de esos criterios.

Me surge una duda "de fondo". ¿Estáis formando al equipo de alguna forma?

Es que me resulta curioso que penséis en castigar/premiar como si el equipo hiciese las cosas mal "a propósito" (algo que no he visto en mi vida) y el premio/castigo les pudiese motivar a trabajar mejor.

No conozco los detalles, pero mi experiencia es que la resistencia al cambio viene de la imposición de "calidad de código", "estándar de codificación", etc... impuestas desde fuera. Necesitas que esas cosas partan del técnico (con formación, con un colaborador que "despierte" al equipo, etc…). En caso contrario la resistencia es lógica... "alguien que no sabe lo que hago me dice cómo lo tengo que hacer". Todos los técnicos tenemos una historia y una experiencia... por eso hacemos las cosas como las hacemos.

Martín hablaba de la figura del lider técnico y que siempre existe de forma implícita. Yo incluso diría que es más relevante el "implícito" que el "explícito" (elegido por la empresa) ¿Lo has identificado en tu equipo? ¿Tienes alguna persona que "trae ideas nuevas"? ¿Que lee blogs técnicos? ¿A quién pregunta el equipo cuando tiene un problema?

Si no eres capaz de encontrar a una figura así en tu equipo, yo te recomendaría contratar a alguien que pasase un tiempo con tu equipo para "espabilarlos" (autopromo: esa es una de las cosas a las que nos dedicamos en 1uptalent, pero hay mucha otra gente en la lista capaz de hacerlo)

- Alguién del grupo tiene experiencia en la gestión de equipos de desarrollo desolcalizados? Hay varios programadores trabajando sobre un mismo proyecto pero cada uno está al cargo de tareas independientes. Aunque hay comunicación no es habitual que un programador utilice o evalúe el código generado por otro. Además no están físicamente juntos.

He participado en varios equipos de ese tipo, pero no me queda clara tu consulta.

- ¿Que auditoría se puede realizar sobre el trabajo realizado (código) por otros programadores? ¿Que herramientas utilizáis y que criterios son valorables?

Durante tiempo utilicé herramientas de análisis de código (findbugs, checkstyle...). Si usas integración continúa (y si no, otra cosa que tienes que hacer YA antes de pedir nada a los técnicos) es fácil sacar gráficas y tendencias.

El mayor problema es el tiempo empleado en configurar las herramientas. Normalmente en dos vertientes:

- Integración con los proyectos. Si usas un sistema "más o menos estandar" es fácil. Si no, quizá lo primero sea automatizar las builds (y aportar algo al equipo en el proceso).

- Configuración de las herramientas. La configuración estándar de las herramientas suele ser muy ruidosa... antes de implantarla de forma "visible" habrá que asegurarse de que el criterio de la herramienta, del equipo y de la empresa están alineadas.

En resumen… no es poco el trabajo que tienes por delante :-). Pero es muy emocionante. ¡Suerte!

--

Abel Muiño - 1st Generation FOOTY with JPop Superpowers

http://abelmuino.es

[Ángel Medinilla]

Esta claro que si hay un perfil especialmente sensible o especialmente
agresivo, se pueden producir problemas.

En cuyo caso hay que solucionar ese problema, no evitarlo o circunvalarlo. Al fin y al cabo, de eso va todo este rollo... ;)

 

  Si hay disfuncionaldades en el equipo, el problema no es
particular de las revisiones sino general de las relaciones del
equipo, y como tal debemos abordarlo.

+1 ;)

[adiazmaroto]

Antes de nada quisiera disculparme con la comunidad por mi baja
actividad, y agradecer a Alfredo Casado por la referencia al libro
"The Surprising Truth About What Motivates Us".

"Just to add my 2 cents" Opino que, independientemente del
procedimiento gestion del cambio que
se decida usar, es indispensable que las personas que forman parte del
cambio perciban este como una decision personal que les guie hacia un
objetivo comun.
Dos elementos son claves para esto:
1. Advertir la necesidad del cambio
2. Formar parte de la decision de cambio

Siendo mas concreto, propongo comenzar el proceso del cambio con un
encuentro del equipo donde se evidencia la necesidad de mejorar ( los
diagramas
causa-efecto pueden resultar utiles en este tipo de encuentros). Creo
que ser consciente de la necesidad de mejorar es condicion
imprescindible (aunque no suficiente) para crear la motivacion
necesaria para realizar el esfuerzo adicional que supone cualquier
cambio.

Una vez que todos los componentes del grupo son participes de la
necesidad de mejorar, las sugerencias de mejora y criticas apareceran
por si solas. Es ahi cuando
el gestor del cambio puede comenzar a trabajar en la guia del grupo a
traves del camino de la mejora continua, usando su experiencia
adicional, habilidades interpersonales y de gestion para promover,
apoyar, sostener y mantener las iniciativas de mejora, dejando las
cuestiones tecnicas para los tecnicos.

[Francisco Manuel Maldonado]

Muchas gracias a todos por el recibimiento y vuestras aportaciones. Los recursos que habéis compartido también parecen muy interesantes pero evidentemente requiren de un tiempo para procesarlos. Esta semana nos vamos a reunir en la empresa para plantear algunas de las custiones que sugerís. Os mantendré al tanto de las conclusiones.

En general tratar con personas es siempre peliagudo, sobre todo cuando estás convencido de su valía pero necesitas que vayan un paso más allá. Es ese efecto motivador el que hecho en falta ahora mismo.

Un abrazo

[manuel casuso]

Trabajo en la misma empresa que Manuel Maldonado. Quería sumarme a sus
palabras y agradeceros a todos vuestras intervenciones y consejos.
Llevo dos meses leyendo los foros de este grupo. Me han impresionado
muchos hilos por la altura de sus debates. Pero sobre todo, ver que
existe gente con tanta ilusión por su profesión y con ganas de cambiar
las cosas. Off topic total: Aquí hace falta una sección de ofertas de
trabajo....las empresas necesitamos gente así.





On 26 mar, 09:09, Francisco Manuel Maldonado

[David Palomar]

Hola, primero darte la enhorabuena por que hace falta valentía para
exponer un tema como este en un foro público. Muchos líderes,
gerentes, jefes o como quieras llamarlo se escudan tras una barrera de
responsabilidades y no son capaces de consultar un asunto tan
importante como el de la gestión de personas. Asimismo, te
recomendaría cierta cautela sobre las estrategias a considerar, por el
mismo motivo, este es un foro público.

Un posible consejo por mi parte va en la línea que han comentado
anteriormente en este mismo hilo y es que plantees esta situación al
propio equipo. Primero declara los objetivos que quieres conseguir del
equipo y los puntos fuertes que tiene el mismo y las áreas de mejora
que todavía no tienen y a continuación expón junto con el equipo qué
es lo que necesitas de ellos y de qué manera podrían resolverlo y qué
necesitan ellos de ti, o de la empresa para lograrlo. Te sorprenderás
lo sencillo que son algunas soluciones tomadas por el propio equipo.

Otro consejo es sobre el tema de los castigos y recompensas, cuidado
no siempre funcionan como esperamos. Todo aquello que recompensas
tiende a repetirse mientras exista la recompensa, pero en el caso que
tú comentas, es algo que debería ser parte del trabajo diario de los
desarrolladores y no debería ser recompensado. Lo que hay que hacer es
fomentar la responsabilidad del equipo, para ello lo mejor es realizar
una "foto" de la situación del equipo, cómo ven ellos a la empresa
donde trabajan, cómo ven el trabajo que hacen, el proyecto donde
están, etc.

Todo esto, a mi parecer (of course), es más importante que el usar
simplemente unas herramientas que me dicen lo bien o mal que estoy
haciendo las cosas sin tener en cuenta el contexto en el que ocurren,
ni el porqué estoy usando esas herramientas, que además pueden servir
de excusa para tomar malas decisiones, o usar el paradigma del palo y
la zanahoria. Cuando se acabe la zanahoria el equipo se detendrá,
incluso pueden acabar haciendo las cosas peor porque no hay
recompensa, entonces es el momento de sacar el palo, lo que
seguramente no traerá nada bueno.

No dudes en buscar consejo profesional puntual, te ahorrará todo ese
tiempo de procesamiento de material del que hablas.

Un saludo y espero haber arrojado algo de luz.

On 26 mar, 09:09, Francisco Manuel Maldonado
<fmanuel.maldon...@gmail.com> wrote:

[Juan Carlos Quijano Abad]

Buenas,

En mi contexto particular, nunca utilizo el castigo. Al abrir las puertas al equipo a decidir sobre su trabajo, implicitamente se obtiene una fuerte motivación y responsabilidad sobre sus tareas.

Así, partiendo de la base que no hay juez más duro que uno mismo, no es necesario caer en "ordeno y mando" y repartir estopa.

Esto se rompe cuando alguien del equipo se bloquea a trabajar de forma Agile, y entonces hay que tomar decisiones para proteger al equipo de este importante impedimento. Por suerte, para mí, solo me ha pasado una vez.

--

Un saludo

Juan Quijano

 

Blog de .Net y Gestión de proyectos

Blog de opinión social

Blog de World of Warcraft

Blog de Tiro con Arco