Hackear el contexto país: ¿Cuántas personas debe tener un equipo?


(Celeste Benavides) #1

Esto lo escribo bajo el thread de Hackers Culturales, porque quisiera que el enfoque del debate este más en descubrir por qué el número de personas en los equipos se debe convertir en un hack en los tiempos que corren, y no discutir sobre lo que proponen diferentes autores.

Les explico el contexto: me imagino que todos están familiarizados con lo complejo de la situación país, que en todos lados están despidiendo gente y “optimizando” los equipos. Lo pongo entre comillas porque en general es un eufemismo para decir que haremos lo mismo con menos gente (y como los clientes también cortan presupuestos, probablemente haremos lo mismo con menos gente y con menos plata). El punto es que no porque el contexto cambia los equipos se vuelven automáticamente más rápidos o con mayor capacidad.

Ahora, en el ejercicio hipotético que les propongo, les pido que piensen en que pertenezco a una organización que no quiere quedarse en el eufemismo de “si, somos súper eficientes, mira todo el trabajo que hago con dos personas”. Mis esfuerzos personales están enfocados en que verdaderamente podamos hacer más pega con menos gente (que no es lo mismo que con menos recursos, porque la gente “con motor grande” vale más, y lo tengo claro), y para eso tengo dos interrogantes que inspiran este tema:

  1. ¿Cuál es el número óptimo de personas en un equipo? Considerando que son perfiles muy preparados para los desafíos propuestos, me pregunto si hay un ‘número mágico’ que hace que trabajen autónomamente y tranquilos con su carga. Algo así como cuando pensamos el número de compañeros de un trabajo en el colegio, sabiendo que si es de a 4 personas hay dos que harán la pega y el resto va a poner su nombre en los créditos.

  2. ¿Cómo es el perfil de esas personas en el equipo? Y también cómo potenciarlo. En donde trabajo tenemos programas de capacitación constante, gratuitos para todos, pero no se si es la única o mejor forma de prepararlos.

Espero ansiosa sus opiniones y comentarios.


(David Lay) #2

Esto se puede responder desde varios ángulos distintos, pero lamentablemente no soy experto en ninguno. hago el llamado a @jessicapsicologa y a @Edmundo que nos ayuden un poco (y si @PatMolla nos ayuda con invitar a María José Munita al foro sería genial!).

Según tengo entendido, está el número óptimo de relaciones personales que alguien puede tener (entre 150 y 200 si no me equivoco).

Luego está el número de número de núcleo familiar, ya que se quiera o no, en un buen equipo se generan dinámicas de ‘manada’, es parte de nuestro mecanismo social.

pero como digo, estoy súper fuera de mi área de experiencia, así que ojalá alguien nos pueda apoyar, es súper interesante el tema.


(Pat) #3

Invitada la Munita! Y propongo especificar para qué es el equipo…en publicidad por ejemplo cada Célula tiene 6 y funciones específicas.
Según las habilidades y capacidades como su metodología de diálogo puenen ser mas o menos.
Innovación no menos de 12 y todos perfiles y profesioned diferentes…mejor…
No se si haya número màgico…


(Celeste Benavides) #4

Muchas gracias @davidlaym!
Independiente del área de expertise, creo que cualquier aporte ayuda :slight_smile:
Espero que los convocados nos apoyen con sus experiencias.


(Germán G.) #5

Me acabo de topar por casualidad con un post de Javier Garzás que habla de “¿Cuál es el número mínimo de personas óptimo para un equipo?”

Javier habla de mínimo 3 personas, en un contexto ágil.

Espero que sirva.


(Guillermo Schwarz) #6

En hitch hikers to the galaxy, la respuesta a todo era 42. Un número como respuesta a todo, dando a entender que no hay una teoría de todo.

Eso no es verdad, la teoría de sistemas de bartenfalanfy (no se cómo se escribe) es lo más lejos que ha llegado la civilización occidental a encontrar una teoría de todo. Tiene ideas como “todo sistema grande que funciona partió de un sistema chico que funciona”. Se parece bastante al agilismo, ¿no?

¿Qué quiero decir con esto?

¿Porqué nos importaría esto? El problema real es el número de relaciones interpersonales. Agrega una persona y el equipo se ve sobrepasado por el número de relaciones, o pierde el tiempo teniendo que responder preguntas.

Esto se resolvió en Microsoft designando responsables de distintos temas, partiendo de proyectos pequeños, y agregando personas que ayudan “team leaders”, que dirigen 2 o 3 personas, es decir, el grupo ideal es 4, pero puedes juntar 4 o 5 de esos equipos, y esos líderes se juntan y toman decisiones. Esos grupos representan en realidad hasta 25 personas, desarrollando un sólo producto.

La teoría general en China se llama Taoísmo. Es una filosofía y una religión. Pero lo interesante es que la teoría es lógica. Uno de los autores dice que en un ejército, organizas a las personas de a 10, y recursivamente el ejército puede ser tan grande como quieras.

Es la misma idea.

Las tribus germánicas que invadieron el imperio romano están organizadas de la misma manera.

El agilismo, por alguna razón, piensa que las organizaciones deben ser planas. Es cómodo al principio, pero para ser sincero en poco tiempo (6 meses a un año), te das cuenta que no funcionan.

El problema real en Chile es que los jefes no programan. Es decir, he postulado a varias jefaturas y una de las cosas que me dicen “ah, pero tú sabes programar” y quedo descartado. Creo que eso explica porqué en Chile no fabricamos nada, ya que descartan a la gente con conocimiento.

De hecho me ha pasado al revés. Ah, pero tú haz sido jefe de proyecto, necesitamos que programes. Luego se apestan de que no acepto que me pidan responsabilidad sin darme autoridad. Es decir, si algo falla es mi culpa. Si funciona, no hay decisiones que yo haya tomado. Obviamente mi experiencia dice lo contrario: si soy responsable, soy yo quien toma decisiones, no acepto responsabilidades si no puedo tomar decisiones, simplemente porque si no tengo el volante en mis manos no puedo ser responsable de que el auto choque.

¿Se entiende?

En realidad todo lo que digo está resuelto en la literatura de dirección de proyectos desde los años 60’s. Y aparece una y otra vez con diferentes nombres, no sólo en proyectos de software, en todo tipo de proyectos, incluso cuando tomas un MBA: tienes que empoderar a la gente, en el caso de Scrum el equipo se debe autogestionar, en lean el equipo debe conocer y resolver el problema por sí sólo, en kanban lo importante es que el equipo de proyecto aprenda algo cada semana, etc.

Todo está resuelto, todo está escrito hace décadas, pero esta información no se le entrega a los estudiantes de ingeniería… quizás para no se den cuenta que durante los primeros años los van a tratar como esclavos y con jefes ignorantes y poco inteligentes. No sé. Puede ser. Pero si piensas que tus compañeros de universidad son retrasados mentales, espera a conocer los pelotudos para los que vas a trabajar, durante algunos momentos te vas a preguntar si tienen alguna neurona dentro de esa cabeza, porque las cosas que dicen no son dignas de gente inteligente.

La verdad es que tengo mi propia teoría de cómo la gente piensa. Todos los ingenieros tienen ignorancia o consideran que ciertos temas son difíciles. Entonces ¿cóm ote das cuenta cuando algo es difícil para un ingeniero? Escribe mucho código para resolver ese tema. La mayor parte de las cosas se puede resolver con 2 líneas de código.

Ok, ahora piensas que estoy drogado y lo que digo es imposible. Pero si eres meticuloso y algo requiere cien líneas de código, puedes crear bibliotecas con ese código. Luego invocarlo son 2 líneas de código. ¿Cuántas bibliotecas crees que vas a crear en un proyecto? No más de 10.

¿Cómo haces entonces un equipo que funcione escribiendo poco código? Esto debe ser el objetivo de cualquier equipo de trabajo.

El problema de los equipos de trabajo es que quieren terminar rápido. Quieren ser evaluados bien. Ese motivador externo es lo que hace que los equipos de trabajo produzcan “crap”, como dice Uncle Bob.

Pensar es mucho más importante que escribir código. Si alguien no quiere pensar, no sé para qué estudió Ingeniería, significa que fue a perder el tiempo. Si quieren disminuir el tamaño del equipo te están haciendo un favor porque hay que revisar menos código.

Cuando la economía anda “lenta”, hay menos ventas, menos flujo de caja, menos presupuesto. Aunque tu JP te diga lo contrario, en realidad se espera que el equipo produzca menos. No sacas nada con mentir diciendo “sí, vamos a producir lo mismo”. Es imposible a menos que la personas que despidas tenga productividad negativa. Simplemente no es científicamente posible, tendrían que todos estar mintiendo y haciendo payasadas para que se peuda producir lo mismo con menos gente.

Se espera que produzcan menos y quien quiera que diga lo contrario está mintiendo. De hecho se espera que produzcan menos porque se va a vender menos, es así de simple. Si no fuera así, pedirían un crédito de unos 10 millones de dólares y harían crecer el equipo de desarrollo, pero no lo hacen. ¿Porqué? Porque la expectativa de retorno a la inversión es más pequeña que antes.

Cuando el proyecto está en etapa de diseño, haciendo los prototipos, basta con los team leaders. Luego se contrata 2 o 3 personas por team leader para que lo ayuden. Eso es todo. No hay grandes secretos acá.

¿Cómo se recompensa a las personas? Dinero + aprendizaje. Si ya no estás aprendiendo de tu team leader, es hora de pedir un aumento, pedir ser team leader o buscar pasto tierno.

En mi experiencia la gente no quiere enseñar lo que sabe. Aquellos que no explican lo que saben, es porque realmente no saben, no quieren exponerse al escarnio público de exponer sus ideas a medias. Entonces el problema no es el tamaño del equipo, sino la actitud de la gente dentro del equipo lo que importa.

Cuando la gente trata de ser política o de mantener la imagen, entonces fregaste, no hay equipo. me ha pasado varias veces que las pruebas que hacen están incorrectas, no están las opciones reales, la pregunta no está bien hecha, el enunciado hace suposiciones incorrectas, etc. Cuando intentas exponer que se equivocaron, en vez de escucharte, te dicen “ya, no importa, responde igual”. Está demás decir que en un ambiente así no se puede trabajar, sólo puedes hacer que trabajas, pero el nivel de estupidez es demasiado alto, o dicho de otra manera, el nivel de retraso mental es demasiado gigante.

Si les haces pruebas a todos y no dejas entrar retrasados mentales, al menos en mi experiencia, no hay nada que no se pueda hacer, el proyecto sale con mucho mejor calidad que lo que nunca han visto y te acusan de haber copiado un producto comercial… lo cuál obviamente te levanta el ego hasta la luna. JAJAJAJA

Lo único malo es que considero que las jefaturas son siempre retrasados mentales porque no pueden hacer lo que yo hago y por lo tanto que te alabe un cerdo porque puedes mirar al cielo y él no, como que pierde su gracia.

Los proyectos siempre deben ser desarrollados como si estuvieras dirigiendo una startup. Es decir, probar suposiciones y aprender. Esto lo dice Jeff Sutherland, el creador de Scrum. La jefatura arriba tuyo no pueden meter mano ni en tu proyecto ni en tu equipo, sino no te están tomando en serio y es hora de encontrar pasturas más verdes.


(Celeste Benavides) #7

Primero que nada, gracias por la respuesta.
Saco varios puntos interesantes. El primero tiene que ver con la rigidez que, a veces, sentimos que nos otorga el método. Muchas veces también la buscamos. ¿Por qué? Pues me parece que cuando queremos saltarnos la etapa de aprendizaje, nos hace sentir seguros el pensar que alguien más inteligente que uno ya lo resolvió antes. Creo que esto puede ser súper válido, siempre y cuando lo que se evalúa es una estructura estable, y no --como es el caso que planteo – una estructura que puede diferir según el contexto.

Me ayudó mucho tu comentario respecto a cuál es el efecto de añadir a una persona al contexto, que es la multiplicación de las interacciones. Muchas veces, cuando un equipo siente que tiene más trabajo del que puede abordar, la respuesta natural es “traigan más gente”, sin analizar el efecto negativo que viene con la incorporación de otra persona. No digo que esa nunca sea la respuesta a la carga de trabajo de los equipos, pero a veces no se miden las consecuencias, y se piensa que cuando el jefe se niega es solamente porque no quiere pagar otros recursos.

Sobre el punto de la expertise de quienes están en cargos altos, creo que es un gran tema que incluso excede el mundo de la agilidad. No puedo estar más de acuerdo en lo vital que es para un equipo que su jefe tenga claro el trabajo que están haciendo, quizás no en el detalle pero al menos nociones claras, tanto para defender el trabajo con otros jefes en más altos cargos, como con otros compañeros de equipos. Al menos donde estoy, tratamos siempre de evitar al jefe que es puramente manager del proyecto, privilegiando a los que hicieron carrera en la empresa o fuera de ella pero desde abajo. Creo que tiene demasiados pros como para preferir a un ingeniero o similar que tiene nada más que el cartón.


(Guillermo Schwarz) #8

Puede ser. De hecho lo que dices es lo mismo que dice the mythical man month: “adding people late to a project only makes the project late”.

La idea es que esa persona tiene que aprender muchas cosas del proyecto, y eso retrasa más el proyecto, porque se requiere entre 3 semanas y 6 meses para que esa persona entienda “así es como funcionan las cosas acá”, sin mencionar que además el código probablemente ha pasado por muchas iteraciones y las cosas que están escritas “ya no se hacen así”. Eso es bueno porque hubo aprendizaje, y es malo porque el 80% de código es basura y hay que reeescribirlo.

Adivina quien va a hacer eso… El nuevo que acaba de llegar porque está aprendiendo.

Por lo menos una persona va a pensar que el proyecto es una basura, y en este caso tiene razón. Y eso que he estado en proyectos que recién están en la etapa de diseño y los analistas pasan diciendo “este proyecto es una basura”. Oye, estás definiendo el proyecto y ya estás con el estribillo de que el proyecto es una basura??? ¿Ese es el nivel de ingenieros que está saliendo ahora de las universidades?

Pobres programadores si el analista piensa así.

Y no sólo eso, si estás es un equipo que apaga incendios, de esos donde hay bomberos, carrros de bomberos y los incendios se apagan con mangueras que transportan agua… ¿cuál es el tamaño perfecto del equipo?

Hasta donde sé el tamaño perfecto es lo más grande posible (dependiendo del incendio por supuesto), siempre y cuando todos los bomberos sepan lo que están haciendo, porque tener que ir a recoger al que se carbonizó no debe ser un bonito espectáculo, además que corres riesgo de que se te caiga el edificio en llamas para rescatarlo al que estaba perdido.

En el caso del software: hay que definir responsables. Lo crean o no eso funciona. Eso da un número mínimo: un responsable por área de responsabilidad. Es increíble la cantidad de empresas grandes que no siguen esta regla y obviamente sus proyectos son una basura.

Si le preguntamos a un comunista, te va a decir que todos hagan lo mismo. Si hay 100 CU y 5 desarrolladores, le va a pasar 20 CU a cada desarrollador y listo. Todas las pantallas diferentes, toda la persistencia diferente, etc. Eso crea bugs sutiles que son casi imposibles de encontrar después.

Imagina si los autos fueran fabricados así: todos los autos serían diferentes.

Por eso el comunismo colapsó. Y acá en Chile hacemos lo mismo porque aunque Chile habla contra el comunismo hasta por los codos, nadie entiende de qué se trata el capitalismo. Si leen a Adam Smith, habla de la división del trabajo. Y si leen con cuidado, la fábrica de agujas tiene 30 empleados para fabricar una sola aguja. Eso en Chile no se hace porque nadie entiende realmente de lo que se trata la división del trabajo. Creen que el capitalismo se trata de explotar a los trabajadores y esa es la visión comunista. De modo que en Chile somos todos comunistas y las empresas chilenas por eso son una basura. Pregunta en alguna parte del mundo si han consumido un producto chileno y se van a matar de la risa: en ninguna parte del mundo hay un sólo producto chileno. Y eso es por algo.

He conversado hasta con gerentes generales y no tienen idea de lo que se trata la división del trabajo. ¿Como alguien puede ser gerente general por 40 años en una empresa conocida y no saber eso?

Si el objetivo es mejorar la producción, mejorar la calidad, no puedes tener 20 maneras diferentes de hacer lo mismo Eso se vuelve inmantenible y el cliente queda desencantado de lo dificil que es usar tu sistema porque en cada pantalla hay una manera diferente de hacer lo mismo.

Todo sistema tiene 2 tipos de usuarios: los usuarios externos o usuarios finales, quienes son tus clientes, y los usuarios internos que son otros programadores.

¿Qué es más importante? ¿Que un sistema sea fácil de construir o que sea fácil de usar y de modificar?

Desde mi punto de vista lo importante son las características externas de lo que estás construyendo, que el cliente quede satisfecho, que el sistema sea fácil de usar para el usuario (tanto externo como interno). Que sea fácil de modificar en caso de que no sea fácil de usar, para que ahora sí sea fácil de usar.

Que la implementación sea dificil, bueno eso es parte del aprendizaje. Es importante, pero tiene una importancia menor. De todas maneras si subdivides el sistema y sigues aplicando las mismas indicaciones anteriores te vas a encontrar con que ya no es nada de dificil. ¿Es obvio, no?

Respecto de los cartones y certificaciones, probablemente no son importantes, especialmente si el tipo pasó copiando. Pero en las empresas además está el nepotismo, que es la continuación del tipo que partió copiando en el colegio, pueden hacer carrera usando la misma técnica y están tan acostumbrados a que los pillen que ni se arrugan.

Todo cae de cajón, ¿no?

En sistema donde hay pocas oportunidades, los ladrones son los únicos que se hacen millonarios. Es cosa de ver al hijo de Bachelet.

Ahora bien, ¿es así realmente? ¿No hay escape al inexorable destino? En realidad la gente que vive bajo sistemas comunistas vive atrapada dentro de su mente y ni siquiera lo intenta.

Por eso kanban es tan importante. Liberarse del modelo esclavista en que vivimos que atrapa a la gente dentro de su mente, obedeciendo a jefes idiotas en vez de hacer lo que realmente quieren hacer en la vida. Esa es la realidad.

El número de personajes dentro del equipo es completamente irrelevante si los sabes organizar.