Equipos 4×4

Recientemente en la empresa ha surgido el debate de si en un equipo (Scrum) todos los componentes deben saber hacer todas las tareas que surjan. Nuestros equipo está formado por 6 personas pero por distintos productos o partes de productos. Hay frontend, varios backends, dentro de los backends hay muchas matices, tenemos un plataforma que su punto fuerte es que es distribuida, otros que son meramente endpoints que integran servicios, etc. hay mucho de devops, etc. En tecnologías tenemos ruby, python, java, Spring Integration, Django, RabbitMQ, redis, couchdb, mysql y seguro que me dejo alguna.

De primeras para mi esto no es un equipo 100% scrum, sino que debería haber equipos separados por producto, proyecto, pero siendo tan pocos acabaríamos teniendo reuniones con nosotros mismos😀. 

Veo muy complicado que un equipo pueda ser productivo en todo, llevo más de 11 años trabajando en esto y todas las veces que lo he intentado ha fallado. Para mi, el problema es que una persona puede adquirir conceptos e ideas de otros proyectos y tecnologías pero si son demasiadas cosas, básicamente lo que se consigue es tener a una persona que no es productiva y que esta frustrada, más si pensamos que a una persona no le guste o no se encuentre cómoda en una tecnología o producto. 

Los que defienden este enfoque suelen decir que con el tiempo la gente ganará soltura y podrá ayudar y que haciendo pairing eso se consigue. Pero yo veo muy complejo que alguien llegue a ser tan productivo en algo como otro que lleva tiempo en eso y que le gusta, además de las aptitudes de cada uno. Me parece mucho presuponer pensar que alguien pueda ser igual de productivo que otro sin más. En mi opinión se corre el riesgo de acabar siendo aprendiz de todo y maestro de nada. 

Para mi es raro, por ejemplo imagina que tienes a Guido (http://www.python.org/~guido/) y le tienes haciendo frontend, si le gusta y quiere ir hacia ese camino perfecto, pero sino… estás desaprovechando demasiado lo que tienes en el equipo.

Además el tema del pairing, para mi ya se parece a las curas milagro,  es otra cosa que hecho en todas las empresas, y creo que funciona pero no es nada mágico ni nada para hacer a todas horas. Muchas de las veces que estoy haciendo pairing sé que los dos que estamos haciendo pairing podríamos avanzar más y mejor por separado y luego hacer pairing al final, para mergear o implementar las partes que se tocan.

La idea del post es básicamente conocer otras experiencias para intentar cambiar un poco mi forma de verlo, cambiar mi experiencia negativa para construir algo más productivo, así que ¿Cual es vuestra experiencia?

6 comentarios sobre “Equipos 4×4

  1. Leyendolo y releyendolo te doy mi opinión.

    Estoy de acuerdo en que sois demasiado pocos para separar en equipos por proyecto y/o producto.

    Te doy la razón en que una persona primariamente debería dedicarse a lo que le motive, sino o bien se va a ir de la empresa o bien se frustra y pierdes su rendimiento, pero eso no evita que haya que hacer o aprender cosas que no gusten.

    Otro problema de dividir por equipos para proyecto o producto es que no todos conocen el modelo de dominio de todos los productos.

    Para mi lo más importante es que todos sepan bien que productos hay y su modelo de domino dentro de su campo de expertise.

    Por ultimo no soy para nada partidario de que todo el mundo sepa hacer de todo fuera de su camp. Se puede saber apagar un fuego pero creo que es una locura intentar saber hacer de todo y más en vuestro entorno que es bastante exigente.

    Para mi la solución menos mala pasaría por organizar la gente en backend, frontend y devops y desde ahí siguiendo en vez de Scrum una metodología Kanban o si queréis mantener algo de Scrum pues Scrumban.

    El punto de esto es:

    a) Todo el mundo sabe de todos los proyectos pero en su campo de expertise
    b) Kanban te simplifica el proceso de las tareas y también puedes limitar el WIP

    Con el inicio de un proyecto se hace una reunión de arranque con la gente que se va a necesitar, se expone todo lo que hay que saber y cada uno aporta su grano sobre el proyecto en su campo.

    A mi siempre me ha gustado este enfoque para trabajar en equipos🙂

    Un saludo.

    1. Yo lo veo muy parecido, equipos backend, frontend, etc como dices. Lo de cambiar roles está bien de vez en cuando y siempre que la persona quiera, pero hacerlo como norma no me gusta

  2. Muy buenas!

    En el debate veo dos puntos, primero, si dividir o no en equipos separados y segundo, si todo el mundo dentro del equipo debe saber hacer de todo. Voy respondiendo por orden:

    Lo primero y ante todo, me baso en que “Un equipo es mucho mas que la suma de sus integrantes”. Es decir, si es posible no separes en equipos a no ser que el número sea demasiado grande para su propia autogestión. Desde mi experiencia a partir de 8 personas la cosa empieza a ser bastante inestable.
    Tanto si hay especialistas como generalistas, todo el mundo debe sentirse dentro del mismo equipo, todo el mundo debe saber que está haciendo cada miembro del equipo y todo el mundo debe sentir el avance de todos los proyectos del equipo como suyo.

    Me diréis que puede haber proyectos dentro del equipo en los que haya otros miembros que no metan mano. Pero aunque estos otros no toquen código o no configuren máquinas o entornos de ese proyecto, tienen experiencia y conocimientos que pueden ayudar a aconsejar desde diferentes puntos de vista, aplicar técnicas diferentes, librerías, herramientas, etc que ellos conozcan y el resto no.
    Imaginaos la típica conversación de cafetería con un colega de profesión pidiendo consejo sobre algún tema técnico, y el cual te dice, pues de NoSQL no tengo ni idea, pero yo pruebo eso con esta herramienta, o yo tuve un problema parecido en Java y lo resolvimos de esta forma. Pues eso aplícalo todos los días a todos tus compañeros de equipo, para mi esto es un plus incalculable.

    Por otro lado ¿todo el mundo debe saber de todo? Pues así de primeras me parece imposible. Ahora, tener unos conocimientos mínimos de todas las tecnologías que utilizan las 6 personas de tu equipo me parece bastante factible, incluso si me fuerzas exigible.
    No digo que todo el mundo sepa instalar y configurar un mysql en maestro-maestro al dedillo en una hora, pero si, que no me tarde una semana en hacerlo si se necesita.

    Aclarando un poco, mi opinión en este tema es que todas las personas del equipo, deben saber resolver los problemas del día a día de cualquier tarea del equipo. Unos tardarán más y otros menos, unos lo harán mejor que otros, pero quiero asegurarme de que si tengo un pico de trabajo en una banda y tengo saturado al especialista de android, que otra persona o personas, puedan empezar a trabajar en ello y sacarme el trabajo adelante, aunque sea en el doble de tiempo y con apoyo del especialista. Todo esto lo tendremos que tener en cuanta al aceptar y gestionar el proyecto, por supuesto e incluso si nos vemos desbordados decir que no.

    Ya he dejado ver que opino que sí debe haber especialistas, aunque estos especialistas no deben estar estancados en una tecnología ni hacer siempre lo mismo. Si soy el que hago los informes en BIRT, pues ale todos para mi y no hago otra cosa, !MAL! Los miembros del equipo deben irse intercambiando roles. Roles que les gusten a ser posible, y de vez en cuando que no les gusten. Todos deben ir mejorando en todas las areas que tiene el equipo, aunque sigas teniendo especialistas. Este sprint hago yo el informe y tardo una semana, mientras que el especialista lo hace en dos días. Pues bien, para la próxima que se necesite fijo que en vez de una semana tarda 3 o 4 días.

    También es verdad que esta situación debe darse lo mínimo posible para ser lo más productivos posibles, solo en picos. No podemos tener a una persona que no le gusta el backend haciéndolo siempre por que el experto está super saturado. Como dice Mario, la gente se quema haciendo estas cosas y es un riesgo grande.

    En vuestro caso, creo que el modelo de dominio no es un problema, ya que creo que es parecido siempre, pero en otros casos podría serlo también.

    Y bueno, ya paro que como ves me extiendo mucho😛 creo que podría estar hablando del tema un buen rato y si quieres con una caña mejor😉

    Salu2!

  3. A mi también me parece que estaría bien que todos tuvieran unos pocos conocimientos de todo, pero yo no acabo de ver que sea beneficioso. Me explico.
    Imagina que hay una 2 personas proyecto y una sola en otro proyecto. Para que todos tengamos conocimientos de todo, rotamos, cada sprint o cada 2 sprints pasamos a otro proyecto. El sprint en el que solo hay una persona, de repente pasa a quedarse sin la persona que tiene todos los conocimientos (no solo técnicos), aunque probablemente lo más normal es que la persona de ese proyecto no rote y solo roten los de los otros proyectos. Ok, aquí viene mi gran miedo. Crees que una persona que pasa de vez en cuando por un proyecto (me refiero a proyectos/productos complicados, de largo recorrido y amplía arquitectura) tiene los suficientes conocimientos como para apagar un fuego? Te arriesgarías a que metería mano durante un momento de tensión como un fuego?

    Yo pienso en mi, yo he pasado por muchos proyectos de frontend de esa manera, echas una mano aquí, otra allí, etc pero no creo que de verdad pueda ponerme en un sprint a un nivel para meter mano a ciertas cosas.

    Mi punto es que no sería mejor tener a mínimo dos personas fijas en un proyecto durante un período más o menos largo y que así aprendan y tengan en su cabeza solo eso? después se puede rotar de vez en cuando si alguien quiere cambiar, se pueden hacer charlas para explicar la arquitectura, las decisiones tomadas y se puede documentar (no Biblias :D).

    No sé quizá es una preferencia personal o mejor dicho solo una experiencia, en las empresas que he cambiado de proyecto sin parar he rendido poquísimo, me he sentido desaprovechado y frustado.

    1. Cuando hablo de rotar en los sprint no es rotar al 100% ahora tu te dedicas todo el sprint a hacer este proyecto, ahora yo a hacer este otro sin tener ni idea de ello. Eso sería una locura y a saber que saldría de ahí claro😄. De lo que yo hablo y lo que he podido probar en un equipo, es hacer poco a poco pequeñas tareas y al principio supervisadas por el especialista, para ir metiendo mano al proyecto. Esto requiere un coste en tiempo ahora, para ahorrarlo en el futuro, inversión. Y por otro lado un sobresfuerzo en esas personas, asumido por que se supone que quieres mejorar y aprender a hacerlo.

      Con el tema de apagar fuegos como me dices, al principio no me arriesgaría en dejar meter mano a nadie que no sea ese especialista a no ser que sea cuestión de vida o muerte. Pero con el tiempo y con este aprendizaje continuo, llegaría el día que si y cada día que pase, le dejaría con más confianza.
      Este mismo caso me pasó a mi. Estaba en un proyecto donde teníamos que tener guardias 24 horas y solo podíamos hacerlas 2 personas por el desconocimiento del sistema completo del resto del equipo y después de realizar estas rotaciones de tareas, las guardias podíamos hacerlas todos.

      También es verdad que estoy pensando en proyectos/productos grandes, es decir, un largo plazo de desarrollo. Con lo que tienes la posibilidad de ir haciendo esto poco a poco y ver que el equipo completo va creciendo en conocimiento y va siendo cada vez mas multidisciplinar.
      En el otro caso, tendrías un equipo de especialistas que solo saben de su campo (cada vez más eso si). ¿Que pasa si se te va alguien? te haría un boquete bien bonito en el proyecto/producto ya que ese conocimiento no se ha extendido al resto del equipo, por mucha documentación que haya😛 Y por otro lado, no conozco a nadie inquieto y con afán de aprender, que quiera estar toda la vida estancado haciendo lo mismo.

      Ahora viéndolo desde el punto de vista de proyectos pequeños, no lo veo nada claro el rotar entre proyectos. Si un proyecto te dura dos meses o tres, el retraso que supone esta rotación se notaría mucho en los proyectos, y luego además el conocimiento adquirido del proyecto no serviría de mucho a una persona que solo hiciera una parte concreta. En este caso es mucho mejor el conocimiento adquirido estando todo el proyecto inmerso en él.

      Lo que veo claro es que estar rotando de tareas y andar como pollo sin cabeza no es nada bueno y hace perder productividad, pero el hacerse un bunker de conocimiento creo que cava tu propia tumba también.

      Influye mucho en esta discusión que haya estado mi vida laboral en proyectos bastante largos y grandes😛

  4. Con poca gente y hay proyectos y productos a los cuales dedicarse simultáneamente no dividiría fuertemente los trabajos ni asignaciones.

    Probablemente la gestión de proyecto sea entre trivial e inútil. Pero creo que es de suma importancia la gestión “ágil” del portfolio de proyectos. En estos contextos, matar una iteración de un proyecto con 1 o 2 personas trabajando e incumplir con el objetivo es válido (valor entregado cero y un cierto coste hundido). A nivel de proyecto puede parecer un fracaso absoluto, pero hay que tener en cuenta el portfolio y ver que valor a nivel empresa se obtiene haciendo que la gente que estaba en ese proyecto “arruinado” aporte a otro proyecto que ayuda a cumplir con un objetivo superior (el CEO probablemente te lo sepa decir muy bien!).

    Para que esto funcione es indispensable que la información de la empresa sea transparente y fluída, sino es posible que se tiendan a establecer objetivos individuales y fictisios. En organizaciones pequeñas no es posible que se logre éxito individual en un contexto adverso general (en las corporaciones es super fácil).

    Para mi la clave es un equipo desorganizado (algunos lo llaman auto-organizado), es decir donde no hay reglas escritas, asignaciones obligatorias y todo está sujeto a cambio en pos de lograr el objetivo final de la empresa.

    Algunos axiomas, hipótesis y creencias que considero indispensable para que funcione son:

    – todos pueden equivocarse
    – siempre debes hacerle saber a alguien cuando está equivocado
    – todos están obligados a decir que no cuando lo crean necesario
    – los líderes surgirán naturalmente
    – las órdenes se obedecen (el que da órdenes también tiene derecho a equivocarse)
    – siempre son bienvenidas las sugerencias de mejora
    – cada uno sabra comprender cuando algo es una órden y no usa sugerencia
    – las quejas solo pueden venir acompañadas de una propuesta de mejora
    – hay que preguntar hasta el infinito hasta comprender lo que se está haciendo
    – no hay que “ponerse creativo” para solucionar cosas “de base”, mejor hacerlas como dicen los libros
    – si ya está escrito en un libro, no tendrás ventaja alguna en hacerlo igual (alguien ya obtuvo el rédito antes), así que solo poniéndote creativo marcarás una diferencia

    Resumiendo en el contexto que mencionas, no creo que ninguna metodología sea la solución. Hay que basarse en un equipo donde todos se sientan cómodos, sean talentosos (no me valen los “suficientemente competentes con ganas de aprender”) y que tengan todos pasión por el objetivo.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s