Cuando es necesario hacer algo, ya sea una tarea nueva o ayuda con una existente, una reacción instintiva que he visto a menudo en la naturaleza es encontrar a una persona que lo haga .
Aquí hay algunos ejemplos aleatorios de esto:
" Necesito ver los registros, ¿con quién hablo? "
" Quiero que este parche se fusione, ¿quién puede ayudarme? "
" Quiero que ese botón se comporte de manera diferente, ¿quién está disponible para trabajar en esto? "
A veces, la gente supondría que un solo actor siempre está disponible y esperando para realizar una tarea en particular (" si quiero ver los registros, voy a Josh, él siempre me ayuda con eso ").
Otras veces, la gente supondría que siempre hay un solo enrutador disponible (" si quiero que se implemente algo, este gerente, Bob, siempre puede ayudarme a encontrar a la persona adecuada para el trabajo ").
A veces, las tareas se asignarán al azar (" Me asignan tareas al azar (más o menos) " - ¿ La mejor manera de dividir y asignar el trabajo de desarrollo en los proyectos? ).
Creo que esto se conoce coloquialmente como "empujar".
Por otro lado, algunas metodologías de desarrollo (Lean, Scrum, Kanban) parecen preferir el enfoque de "extracción", cuando en lugar de entregarlas a una persona en particular (y a veces a través de una persona de enrutamiento) las tareas se ponen en cola en algún lugar (en un Kanban). tablero, en una acumulación de Scrum, etc.) para ser recogido por los miembros del equipo.
Me pregunto, ¿cuáles son los beneficios del enfoque de "atracción"? Podría ser útil enumerarlos.
Asumiré que el enfoque de "empuje" no solo es directo, sino también inmediato .
(Como cuando alguien se te acerca y te dice " oye, Joe, ¿podemos rodar esto más tarde hoy? ").
El "tirón", por otro lado, no es sólo indirecto , proporcionando la cola como intermediario, sino también retrasado . Las tareas pueden acumularse en la cola, esperando ser seleccionadas durante el día o esperando una reunión de planificación.
Los humanos tenemos una memoria de trabajo limitada . Cada vez que alguien se nos acerca con una tarea, tenemos que cargar un montón de cosas en nuestra memoria de trabajo, cambiando al dominio del problema diferente. Esto requiere tiempo y capacidad intelectual (recuerdo haber leído un estudio sobre cómo, para algunos programadores, el cambio de tareas es un recurso limitado, solo pueden sufrir un puñado de esos cambios al día).
Necesitamos la memoria de trabajo para pensar, cuanto menos tengamos para la tarea en cuestión, peor será nuestro desempeño ( cf ), por lo que prestar parte de ella para discutir una tarea diferente es perjudicial para lo que sea que hayamos estado trabajando.
Además, si una persona logró sorprendernos con la pregunta, ¡entonces probablemente perderemos el estado actual por completo !
Y al tratar de retener dos cosas a la vez, la tarea en la que hemos estado trabajando y la tarea que se nos ha propuesto, es probable que también fallemos en la segunda. Podríamos prestarle una atención y una memoria de trabajo inadecuadas, al no poder estimar su complejidad adecuadamente, juzgar nuestra aptitud, captar el contexto y la imagen completa, etc.
Entonces, el enfoque de "jalar" nos permite programar mejor nuestro trabajo, aceptando nuevas tareas y preguntas relacionadas con tareas cuando nuestra memoria de trabajo está lista para contenerlas.
PD cf. http://blog.ninlabs.com/2013/01/programmer-interrupted/
Algunos de nosotros podemos entrar en un estado de hiperenfoque llamado Flujo.
Creo que Flow se trata de mantener un equilibrio adecuado entre nuestra parte cognitiva y emocional. Es un ciclo cerrado donde lo que hacemos también nos emocionará, alimentando nuestra creatividad, una sensación de descubrimiento, fluidez y cualquier otra cosa que nos motive .
Ese equilibrio es muy efectivo pero también precario.
La asignación de tareas puede ser estresante. Obliga a pasar del cerebro creativo al de planificación y gestión. Rompe el Flujo fácilmente.
Esta podría ser la razón por la que Schaffer enumera la "Libertad de distracciones" como uno de los requisitos .
Entonces, el beneficio del enfoque de "jalar" es que no tenemos que romper el Flujo de nadie con él.
La asignación de tareas a menudo genera incertidumbre. " ¿Puedo hacer esto? ¿Tengo tiempo? ¿Querré trabajar en esto mañana? ¿Hay consecuencias si apruebo? " Estas y muchas otras preguntas pueden surgir en la mente de alguien cuando se le pide que realice una tarea. .
La incertidumbre es estresante. Algunos estudios muestran que es peor que el dolor .
Curiosamente, una asignación sutil ( " ¿Considerarías trabajar en esto conmigo? " ) puede generar aún más incertidumbre en la imagen.
Un factor de estrés aún más fuerte es la falta de transparencia. Estamos conectados para estudiar el entorno social que nos rodea. Ya sea conscientemente o no, estamos evaluando dónde estamos, qué tan útiles somos para el equipo y si nuestras relaciones son seguras. Algunas personas por defecto están más ansiosas que otras ( cf ), pero la seguridad en las relaciones es una de nuestras necesidades fundamentales, junto con la alimentación y la procreación ( cf ).
El enfoque de "atracción" aporta transparencia al equipo. Sabemos qué está pasando, quién está trabajando en qué tareas, qué se está haciendo y qué se está retrasando.
La asignación directa de tareas, por otro lado, a menudo ocurre bajo la alfombra.
PD Más sobre ese aspecto de seguridad psicológica en Duhigg, lo que Google aprendió de su búsqueda para construir el equipo perfecto .
Como dijo Dijkstra , vale la pena " centrar la atención en algún aspecto ".
Escoger las tareas es definitivamente un aspecto aparte. O más bien un grupo de aspectos. Deberíamos aclarar y discutir los objetivos de la tarea, ver si la tarea es realmente necesaria, medir su prioridad, hacer algunas estimaciones de complejidad, analizar diferentes formas de lograr el objetivo (Cialdini cita un estudio que muestra a las empresas evaluando metódicamente las opciones y pensando en los riesgos de cada uno son en promedio más exitosos que las empresas cuyo proceso consiste en saltar a la palestra).
La distribución de tareas durante el desarrollo es importante, sin duda vale la pena el "pensamiento inteligente" del que habla Dijkstra.
El enfoque de "atracción" nos permite centrarnos en estas importantes preocupaciones.
Nuestros cerebros están sintonizados con el tiempo y el entorno, así como con otras señales. La mayoría de las veces desarrollaríamos patrones de comportamiento para ser activados por estas señales (cf. " investidura "). Puede pensar en ello como precarga .
Esto facilita nuestras actividades.
El Scrum clásico requiere que las reuniones diarias sucedan al mismo tiempo. Eso no solo ayuda a las personas a estar allí, sino que también juega con las señales de tiempo y lugar, lo que permite que nuestra mente se optimice para el tipo de actividades que implica la planificación y la distribución de tareas.
" Asignar tareas a personas es un reclamo implícito de que usted (el asignador) sabe más que ellos (los asignados). Incluso si esto es cierto, todavía es fácil que una persona se ofenda. Sin embargo, la mayoría de las veces no es así. cierto. Las personas se conocen mejor a sí mismas. Las personas son mejores asignándose tareas a sí mismas. Y, por lo tanto, tener una persona asignando tareas a otras personas casi siempre conduce a una distribución de trabajo subóptima entre los miembros de un equipo ". Trampa de Scrum: Asignación Tareas de Mishkin Berteig .
Todo es simple cuando tenemos un solo desarrollador. Pero en cuanto tengamos dos o más de ellos, empezaremos a cometer errores a la hora de asignar las tareas.
Supongamos que tenemos un desarrollador que siempre trabajó en el problema X y simplemente le asignamos las tareas relacionadas con X. ¿Qué podría salir mal?
Excepto que este desarrollador puede estar repentinamente ocupado, es posible que ya no esté interesada en el problema X y que se esté agotando, es posible que esté perdiendo la oportunidad de que otros desarrolladores aprendan mejor el sistema, otros desarrolladores pueden sentirse excluidos, puede haber menos incentivo para verificar las decisiones de diseño y la polinización cruzada, habrá menos interés en lo que está pasando con X y, por lo tanto, menos motivación proveniente de Fellowship, etc. Muchas trampas para una simple obviedad, ¿eh?
Los desarrolladores no son robots simplificados, realmente saben mejor cuando se trata de elegir sus tareas.
El enfoque de "empuje" por lo general asume y necesita una autoridad. Se estratifica el equipo en asignadores y asignatarios. Esta configuración a menudo pondrá en juego los patrones relacionados de la psicología humana.
Los asignadores pueden acercarse al estado del yo Padre del Análisis Transaccional, que es " ...esencialmente no perceptivo y no cognitivo. Es simplemente una base constante y, a veces, arbitraria para las decisiones... Opera válidamente cuando se dispone de información adecuada para una decisión de un Adulto". no está disponible, pero en ciertas personas, opera a pesar de una adecuada información de los Adultos ” (Claude Steiner).
En otras palabras, los cedentes pueden llegar a esperar que se les siga, independientemente de lo arbitrarias que sean sus decisiones.
Los cesionarios pueden asumir de manera similar la perspectiva sumisa u otras configuraciones que sean compatibles con el estado del ego Padre del cedente. (cf. Robert C. Ginnett - Tripulaciones como grupos: su formación y su liderazgo)
Los intentos de romper con este esquema pueden resultar en conflictos y confusión repentinos.
El enfoque de "atracción" es menos arriesgado en este sentido, tiende a atraer al equipo hacia el estado del ego adulto consciente en lugar de aprovechar la interacción de autoridad ligada a los estados del ego padre e hijo.
Para presentar las tareas en la cola, a menudo necesitamos prepararlas. Escriba una historia de usuario, cree una entrada de seguimiento, fije una pegatina en un tablero Kanban.
Esta pieza, aunque breve, podría servir como base para la documentación de tareas. Podemos hacer referencia al problema del rastreador desde el código o agregar detalles a la tarjeta de tareas en un tablero.
Cuando estaba investigando la gestión eficaz del tiempo, encontré en algunos de los autores la idea de que la parte más importante es tener una manera de sacar las cosas innecesarias.
Elimine las cosas que realmente no necesita de sus listas de tareas pendientes y de repente descubrirá que sí hay tiempo para las cosas que son importantes.
Una idea similar se puede encontrar cuando se trata de la gestión y priorización de proyectos. Puede ser crítico, para el diseño y desarrollo saludable del proyecto, tener la prioridad NO. Decir no a la fluencia característica. Separando la paja del trigo.
Ahora, esto es muy difícil de hacer con el enfoque de "empuje". Es difícil decir que no cuando se le asigna una tarea. Si se asigna, esperamos que sea importante (debido a la misma interacción social invertida en la asignación). Las tareas se acumulan en las colas de los desarrolladores. Los desarrolladores se vuelven perpetuamente ocupados y/u olvidadizos.
Con el enfoque de "extracción", la planificación iterativa en particular, el recorte se produce de forma natural. Las tareas en cola compiten entre sí por la iteración. Al oponerse unos a otros, desarrollan una prioridad natural. Solo se seleccionan un puñado de las tareas más importantes, de acuerdo con las restricciones de capacidad de iteración.
En la producción Lean existe un principio de "detención de la línea" ( cf ): si algo está mal con su canal de desarrollo, es mejor que lo averigüe y lo arregle en lugar de equivocarse y tratar de ignorar el problema.
Con el enfoque de "empuje", algunos problemas son difíciles de descubrir. La tarea puede carecer de información que le dé sentido, las personas pueden no tener idea alguna de por qué es importante, puede haber poco para continuar con respecto a la motivación, la tarea puede ser demasiado grande o demasiado compleja, etc., pero cuando se asigna la tarea , la mayoría los desarrolladores lo superarán a pesar de los obstáculos. Esto podría ser algo bueno. Pero cuando queremos mejorar la gestión, eliminar los obstáculos y " construir proyectos en torno a personas motivadas ", el trabajo estoico puede funcionar al revés.
Con el enfoque de "atracción", la retroalimentación esencial está integrada en el sistema. Cuando anuncias una tarea y nadie la toma, sabes que tienes un problema.
Tal vez el objetivo detrás de la tarea no esté claro, tal vez realmente no necesite implementarse, tal vez haya perdido el contacto con el equipo, etc., etc. Sea lo que sea, debe "detener la línea" y solucionarlo. .
La gente tiende a simplificar. Es un mecanismo de supervivencia esencial ( cf ). “ El Sistema 1 es propenso a sustituir una pregunta difícil por otra más sencilla ” ( Thinking, Fast and Slow ).
Una de esas simplificaciones es establecer si en un contexto dado necesitamos pensar por nosotros mismos o si simplemente podemos seguir las decisiones de otra persona. No podemos esperar que un desarrollador elija siempre entre los dos (porque hacer esa elección una y otra vez es lento y no efectivo). Es más probable que asuma el enfoque de autoorganización o el de seguidor.
“ La ventaja que un comandante cree que puede lograr a través de una intervención personal continua es en gran parte ilusoria. Al dedicarse a ella, asume una tarea que realmente pertenece a los demás, cuya eficacia destruye de ese modo. También multiplica sus propias tareas hasta el punto en que ya no puede cumplirlas por completo. ” -Helmut von Moltke .
“El factor decisivo, a pesar de la tecnología y el armamento, es el valor del soldado individual. … El campo de batalla requiere soldados que puedan pensar y actuar de manera independiente, que puedan hacer un uso calculado, decidido y audaz de cada situación y que entiendan que la victoria depende de cada individuo. ” -Truppenführung ( Wikipedia ).
El enfoque de "empuje" empuja a los desarrolladores a convertirse en seguidores. Si la gerencia toma decisiones importantes, maneja la comunicación importante y la división del tiempo, entonces la mayoría de los desarrolladores comenzarían a delegar estas funciones cognitivas a la gerencia.
Por lo tanto, vemos en la práctica que el enfoque de "empuje" a menudo conduce a que los gerentes se vean inundados con varios grados de microgestión.
El enfoque de "atracción", por otro lado, invita a los miembros del equipo a pensar por sí mismos. Suele mencionarse como un camino hacia los equipos autoorganizados.
Eso sí, un equipo autoorganizado aún necesita el liderazgo y la gestión, pero el tiempo de liderazgo se dedica a temas valiosos (motivación, sentido común, establecimiento de metas y plazos, despejar el camino de los obstáculos, etc.).
PD Debe tenerse en cuenta que "tirar" no es para todos. Solo funcionará si el equipo es compatible con él a nivel cultural, si hay mucha confianza y humildad entre sus miembros y si la gente está dispuesta a tomar la responsabilidad en sus manos. Como menciona el Manual de Valve para nuevos empleados , "tirar" puede necesitar coraje y conocimiento "para no enloquecer".
Los enfoques de extracción se optimizan para el flujo (la rapidez con la que las tareas pasan de "en progreso" a "terminadas"), mientras que los enfoques de inserción se optimizan para una utilización del 100 % (asegurarse de que todos estén haciendo algo en todo momento).
Veamos un ejemplo. Tenemos dos desarrolladores, A y B, y 8 tareas, 1-8, ordenadas por prioridad.
Asignamos 1, 3 y 5 a A, así como 2, 4 y 6 a B, dejando 7 y 8 en el backlog.
Empezamos con A trabajando en 1, B trabajando en 2.
Supongo que estás hablando de tareas pequeñas. En ese caso, una ventaja es que las personas que se encontraron buscando trabajo pueden aceptar una tarea de inmediato.
Parece que también está solicitando orientación sobre cómo manejar estas solicitudes:
Le sugiero que tenga un proceso bien definido sobre cómo hacer estas solicitudes y cuándo aceptarlas. La forma más fácil de ayudarlo a decidir es tener una "plantilla de solicitud" que el solicitante debe completar para que se acepte la solicitud. Algunos campos pueden ser: qué, por qué, descripción, fecha límite sugerida y cualquier cosa en particular relacionada con el problema de su dominio. ¡Esto les ayuda a pensar si su pedido tiene sentido!
El seguimiento y registro de estas tareas es importante para:
Todas las solicitudes no urgentes deben analizarse durante la planificación del próximo sprint. Luego, puede asignárselo a alguien según lo ocupado que vaya a estar y luego regresar con una fecha límite.
La respuesta corta es que pagamos un alto costo por interrumpir a las personas (cambio de contexto). Si desea que las personas trabajen de manera eficiente y se sientan bien con su entorno de trabajo, entonces depende del PM o del equivalente ágil (dependiendo de la metodología, Scrum Master, quien sea) proteger a los desarrolladores.
Esto no siempre es políticamente posible. Siempre se prefiere si se valora la productividad y el buen hacer. Y es que, a veces, se producen emergencias y esa interrupción es imprescindible. Pero, para repetir, el tirón está asociado con una productividad y satisfacción significativamente más altas.
Anexo: Es realmente malo para los desarrolladores estar a merced de cualquier parte interesada que tenga su información de contacto. Las interrupciones son perjudiciales (consulte la respuesta más larga anterior o considere el cambio de contexto), incluso cuando no se genera una nueva tarea. Independientemente de empujar o tirar, el PM (o quien sea) quiere estar en una posición para ser el único contacto con las partes interesadas fuera del equipo.
Según mi experiencia, las tareas de software suelen tener tanto dependencias ocultas como contextos ocultos. A menudo encuentra un desarrollador "especializado" en esta o aquella área del sistema porque está más familiarizado con ella y puede hacer el trabajo más rápido. Cualquier otro miembro del equipo debe estar lo suficientemente familiarizado con cualquier parte del sistema para "aumentar" cualquier área y hacer el trabajo correcto, pero la especialización improvisada suele ser más conveniente. Obviamente, debe alentar a "revolver la olla" para que las manos izquierdas sepan lo que están haciendo las manos derechas.
La "puesta en cola" a menudo funciona bien, siempre que conozca los patrones por los cuales esta cola podría ser atendida de manera más natural. Asegúrese de que todo el equipo siempre comprenda la urgencia de cada tarea y cómo avanzará el proyecto en su conjunto. Los propios miembros del equipo a menudo son un recurso excelente para ayudarlo a tomar estas decisiones en su nombre, porque están "en esto" todos los días y poseen conocimientos técnicos y experiencia específica del dominio que usted puede no tener, y realmente no se esperaría tener.
MCW