Diferencia entre revisiones de «Conformación de equipos»

De Dos Ideas.
Saltar a: navegación, buscar
(La intención de conformar un equipo)
(La intención de conformar un equipo)
Línea 6: Línea 6:
  
 
== La intención de conformar un equipo ==
 
== La intención de conformar un equipo ==
Generalmente, aprendemos a programar "de forma casera": nos enseña algo la facultad, vemos cómo programa un amigo o colega, y obviamente probamos mucho por nuestra cuenta. No tenemos ''intención'' de programar "bien", sino simples ganas. Pero más allá de estas ganas, es común que varias personas pasen su tiempo sin hacer algo concreto y probado para programar ''mejor''. Sin embargo, cuando realmente emepezamos a actuar con verdadera intención de mejorar, aprendemos que existen patrones de diseño, prácticas probadas, convenciones, etc. Más aún, entramos en contacto con prácticas como [[Extreme Programming]], que nos guian a través de prácticas para lograr programar de manera profesional. Logramos la intención de programar bien.  
+
Generalmente, aprendemos a programar "de forma casera": nos enseña algo la facultad, vemos cómo programa un amigo o colega, y obviamente probamos mucho por nuestra cuenta. No tenemos ''intención'' de programar "bien", sino simples ganas. Pero más allá de estas ganas, es común que varias personas pasen su tiempo sin hacer algo concreto y probado para programar ''mejor''. Sin embargo, cuando realmente empezamos a actuar con verdadera intención de mejorar, aprendemos que existen patrones de diseño, prácticas probadas, convenciones, etc. Más aún, entramos en contacto con prácticas como [[Extreme Programming]], que nos guian a través de prácticas para lograr programar de manera profesional. Logramos la intención de programar bien.  
  
 
Algo similar ocurre con la gestión de proyectos. Es común que los jefes gestionen los proyectos "con la receta de la abuela": técnicas y prácticas que surgen del día-a-día. Son estos jefes que terminan gestionado "como se hace acá", usando planillas de excel, mails, pedidos verbales, llamados por teléfono, micro-gestión, ausencia de gestión, y a veces todo esto junto. Gestionamos proyectos sin intención de gestionar bien. Recién cuando cobramos consciencia de nuestra necesidad de tener una ''intención'' por gestionar es que comenzamos a ver lo que ocurre en el mundo. Y allí nos encontramos con técnicas para la gestión de proyectos, como por ejemplo [[Scrum]]. Logramos la intención de gestionar bien.
 
Algo similar ocurre con la gestión de proyectos. Es común que los jefes gestionen los proyectos "con la receta de la abuela": técnicas y prácticas que surgen del día-a-día. Son estos jefes que terminan gestionado "como se hace acá", usando planillas de excel, mails, pedidos verbales, llamados por teléfono, micro-gestión, ausencia de gestión, y a veces todo esto junto. Gestionamos proyectos sin intención de gestionar bien. Recién cuando cobramos consciencia de nuestra necesidad de tener una ''intención'' por gestionar es que comenzamos a ver lo que ocurre en el mundo. Y allí nos encontramos con técnicas para la gestión de proyectos, como por ejemplo [[Scrum]]. Logramos la intención de gestionar bien.

Revisión del 19:53 9 oct 2009

El desarrollo de software consiste en la creación de Propiedad Intelectual: creamos abstracciones, cosas que no existen en el mundo real. Aplicamos nuestro intelecto para crear productos de software.

Este trabajo intelectual lo hacemos en equipos, esperando lograr armonia y sinergía entre sus integrantes para crear los mejores productos posibles. Lo cierto es, muy pocas veces tenemos intención de crear Grandes Equipos. Y, sin embargo, recién cuando seamos capaces de crear Grandes Equipos de personas podremos alcanzar un Gran Producto, ese software que exceda las expectativas de nuestro cliente.

La conformación de equipos trata sobre cómo crear Grandes Equipos, en donde los integrantes actuen de forma profesional, íntegra y alineada en pos de un objetivo en común.

La intención de conformar un equipo

Generalmente, aprendemos a programar "de forma casera": nos enseña algo la facultad, vemos cómo programa un amigo o colega, y obviamente probamos mucho por nuestra cuenta. No tenemos intención de programar "bien", sino simples ganas. Pero más allá de estas ganas, es común que varias personas pasen su tiempo sin hacer algo concreto y probado para programar mejor. Sin embargo, cuando realmente empezamos a actuar con verdadera intención de mejorar, aprendemos que existen patrones de diseño, prácticas probadas, convenciones, etc. Más aún, entramos en contacto con prácticas como Extreme Programming, que nos guian a través de prácticas para lograr programar de manera profesional. Logramos la intención de programar bien.

Algo similar ocurre con la gestión de proyectos. Es común que los jefes gestionen los proyectos "con la receta de la abuela": técnicas y prácticas que surgen del día-a-día. Son estos jefes que terminan gestionado "como se hace acá", usando planillas de excel, mails, pedidos verbales, llamados por teléfono, micro-gestión, ausencia de gestión, y a veces todo esto junto. Gestionamos proyectos sin intención de gestionar bien. Recién cuando cobramos consciencia de nuestra necesidad de tener una intención por gestionar es que comenzamos a ver lo que ocurre en el mundo. Y allí nos encontramos con técnicas para la gestión de proyectos, como por ejemplo Scrum. Logramos la intención de gestionar bien.

Y sin embargo, podemos lograr la intención de programar bien, podemos lograr una buena gestión de proyectos... y nos sigue quedando una parte fundamental por cubrir. La gestión de proyectos y la programación son actividades que giran alrededor de equipos de personas. ¿Y cómo conformamos estos equipos? ¿Tenemos intención de crear buenos equipos?

Es común que dejemos librado al azar la conformación del equipo: juntamos a un grupo de personas y les pedimos que resuelvan un proyecto, que generen un producto. Pero, ¿qué hacemos para que este equipo logre alcanzar su máximo potencial, para así lograr el mejor resultado?

Las técnicas de conformación de equipos se encargan de este paso fundamental para el desarrollo de software. Antes de construir software debemos construir personas.

En esta sección hablaremos sobre distintas técnicas de conformación de equipos, basadas en el libro Software for your head, de Jim y Michele McCarthy (ISBN 0-201-60456-6).

Las etapas para crear un Gran Equipo

La conformación de un equipo de propiedad intelectual gira alrededor de las personas, sus relaciones y emociones. ¿Cómo mejorar la relación entre las personas? ¿Cómo entender lo que nos pasa? ¿Hacia dónde vamos? ¿Qué queremos para nosotros? ¿Y para el equipo?

Nuestro objetivo será encontrar una Visión Compartida por el equipo: aquello que una y guíe al equipo más allá de la duración de un proyecto. Algo que sea de tanto valor para el equipo y para las personas que logre perdurar en el tiempo. Algo por lo que que valga la pena el esfuerzo.

Veremos varios protocolos y patrones para logra conformar el Mejor Equipo, que genere así el Mejor Producto posible. Las 4 etapas, en órden, serán:

  1. Check-In
  2. Decisión
  3. Alineamiento
  4. Visión compartida


Check-In

Decisión

Alineamiento

Visión compartida

Las personas son quienes crean al producto

(EQUIPO = PRODUCTO) es uno de los conceptos más importantes del desarrollo de software, y a menudo queda olvidado. El PRODUCTO es consecuencia del trabajo del EQUIPO: todas las características que tiene un PRODUCTO son porque el EQUIPO fue capaz de generarlas. Por otro lado, no puedo agregar algo a un PRODUCTO si en el EQUIPO no existe una característica que lo genere.

Existe una correlación directa (aunque a veces no obvia) entre una característica del PRODUCTO y una característica del EQUIPO. Ahora, como el PRODUCTO es consecuencia del trabajo del EQUIPO, para introducir o modificar características en el PRODUCTO deberemos actuar sobre el EQUIPO, que es la única parte de la ecuación a la que tenemos acceso.

De esta manera, (EQUIPO = PRODUCTO) nos permite analizar de forma pasiva una situación. También es una herramienta activa sumamente poderosa, ya que al modificar al EQUIPO vamos a modificar, inevitablemente, el PRODUCTO que se construye.

Los procesos y las personas

Son las personas quienes, a través de sus relaciones, crean y sostienen a los procesos. Son las personas quienes usan y aplican las herramientas. Y en definitiva, son las personas quienes trabajan en equipo y crean productos. Por eso buscamos crear los Mejores Equipos que nos permitan desarrollar los Mejores Productos para nuestros clientes.

Los valores que respaldamos y aplicamos en su totalidad nos permiten crear mejores relaciones humanas que, a su vez, generan los mejores equipos de propiedad intelectual posibles. Y allí reside el gran valor que tenemos para ofrecerle a nuestro cliente.

La conformación de equipos

Teniendo en cuenta que deberemos trabajar sobre el Equipo, estamos hablando de relaciones de personas.

Agil habla de un cambio en la forma de pensar y encarar el trabajo, basándonos fuertemente en principios y valores humanos. Aquí radica la dificultad de una implementación Ágil verdadera.

Ágil NO es implementar Scrum, XP u otra metodología. Ágil es un cambio cultural que, luego, se acompaña con cambios en las prácticas y métodos de la organización.

Implementar Scrum (o cuaqluier metodología) sin aceptar el desafío del cambio cultural es una invitación al desastre. Es en el cambio cultural donde radica el verdadero valor de negocio que se pretende generar y maximizar, y no en metodologías particulares. Ya lo sabemos: la bala de plata no existe. Sólo el trabajo serio y profesional.

Es por todo esto que la conformación de equipos es un aspecto fundamental en el desarrollo de cualquier creación de propiedad intelectual (como ser el desarrollo de software). Son las personas que, a través de sus conversaciones, generan relaciones y obtienen resultados (como ser, un producto de software).