Comenzaré con lo principal: si sus programadores eligen su propia tarea, entonces tienen grandes problemas.
Estamos acostumbrados a ver una elección como operador condicional en un lenguaje de programación o esquema de algoritmo. Bueno, recuerde, tal rombo está dibujado, contiene una condición de selección y dos ramas: sí y no. Cuando se ejecuta el algoritmo, la condición se verifica instantáneamente, por lo que su rendimiento generalmente no se tiene en cuenta.
¿Y cuál es la elección hecha por el hombre? Este no es un algoritmo instantáneo, sino un proceso. Este proceso tiene un comienzo, un fin (Dios no lo quiera) y, lo más importante, la duración. ¿Cuánto tiempo cree que puede llevar la selección de tareas?
Puedes adivinar, pero es mejor medir. Vi este proceso muchas veces, y la conclusión es decepcionante: el programador puede elegir una tarea durante varios días.
El proceso de selección es malo porque está oculto a nuestros ojos. Si una persona estuviera deambulando por la oficina, corriendo de lado a lado, levantando la cabeza en un largo aullido, entenderíamos que tenía un problema. Pero sucede de manera diferente.
Los programadores han ideado durante mucho tiempo un algoritmo como el reconocimiento en la batalla. En relación con las tareas, significa: no solo leer la condición, sino entrar y ver. Eche un vistazo al código, formularios, enlaces, metadatos, ejemplos de reproducción e informes analíticos.
Debe mirar para evaluar la tarea "como debería", no a simple vista. Si encuentra a un programador en esta ocupación, él le dirá: Soy un profesional y no puedo asumir la tarea sin conocer todas las sutilezas. Parecería, ¿por qué es así? ¿Es correcto que lo haga un hombre?
Por supuesto que es correcto. Pero solo si, de acuerdo con los resultados de su investigación, toma la decisión final: asumir la tarea o no. Como opción, tome la tarea con reservas, como la necesidad de estudiar mecanismos adicionales.
Si el programador decidió tomar la tarea y se sentó a hacerlo, entonces todo está bien. Si abandonó la tarea, entonces todo está mal. Se perderá el tiempo dedicado a la investigación.
Hay dos opciones Primero, el programador se negará rotundamente y alguien más verá la tarea. En principio, es posible que el primer programador simplemente vuelva a contar los segundos resultados de su investigación, descubriera dificultades y dificultades asociadas. Pero en la práctica, los programadores prefieren independencia unos de otros, incluso de las opiniones de colegas. Algunos incluso experimentan cierta emoción, entendiendo una tarea que un colega no emprendió.
La segunda opción: el programador no se negó, pero pospuso la tarea hasta más tarde. Cuando llega este "momento posterior", se desconoce, pero lo más probable, después de un tiempo bastante largo. ¿Qué pasará durante la segunda iteración de reconocimiento en la batalla? Comience donde lo dejó en su investigación? Por supuesto que no, él seguirá el mismo camino, de principio a fin. Y, con una alta probabilidad, se detendrá en el mismo lugar que por primera vez.
Y así resulta. Hay tiempo que los programadores dedican a resolver problemas. Normal, correcto, buen momento. Como regla general, se dedica tiempo a resolver un problema una vez.
Y hay tiempo que los programadores pasan en reconocimiento múltiple. No hay ningún beneficio particular en este momento, ni para el programador, ni para el cliente, ni para su empresa. El tiempo para el reconocimiento en la batalla es casi una pérdida pura.
Pero el problema no es solo la inteligencia. Sucede peor.
Por ejemplo, un programador comprende todas las tareas en su lista, pero simplemente no puede elegir qué hacer. El problema se agrava por el hecho de que la elección tiene lugar cuando Dios se pone el alma, sin un algoritmo, criterios y prioridades específicos. Y luego hay mucha gente.
Uno elige lo que es más interesante. Otro elige lo que es más fácil. El tercero elige tareas por mecanismos que le son familiares. El cuarto elige las tareas de su querido cliente, porque el resultado es más fácil de pasar. El quinto elige la tarea más ambiciosa para mostrarse.
Al mismo tiempo, lo cual es importante, casi cada uno de ellos experimenta un tormento mental grave debido a la incertidumbre de los criterios. Más o menos comprende qué tareas quiere resolver, pero consciente o inconscientemente siente que está haciendo algo mal. Le parece que debemos elegir una tarea completamente diferente, basada en la estrategia de la empresa, el estado del proyecto, el plan para el desarrollo de nuestras propias competencias, etc. Pero quiero elegir no lo que se necesita, sino lo que me gusta.
Tal tormento mental agrava aún más el proceso de selección. Una persona se sumerge en pensamientos sombríos, sopesando su elección en la balanza de la conciencia. Y así pueden pasar horas y días.
Desde el punto de vista del gerente parado al margen, todo este proceso se asemeja a una marmota de una famosa película que sale de un agujero y "elige el clima para las próximas seis semanas". ¿Qué sigue allí, si ve su sombra o no, y por qué la marmota lo hace? Es cierto que si el gerente a menudo mira este proceso desde afuera, entonces la pregunta es más probable para él que para los programadores.
Además, en el contexto de elección, las vacaciones son de gran importancia. Un programador es una persona, antes que nada, y no un robot. ¿Qué quiere una persona después de completar un trabajo difícil? Vacaciones por supuesto!
La tarea completada debe tenerse en cuenta. Ir a fumar, tomar té o café, chatear con amigos, alardear de un problema resuelto, sentarse en las redes sociales, leer las noticias, en general, hay muchas opciones. Lamentablemente, estas vacaciones a veces se retrasan.
Es especialmente malo si la tarea se completó en una hora, o incluso dos antes del final de la jornada laboral. Bueno, ¿quién, en su sano juicio, elegirá una nueva tarea para ellos, si es que está pronto: en casa?
Todo ruso sabe lo difícil que es salir del estado de las vacaciones, todos descansamos en las vacaciones de Año Nuevo. En nuestro caso, es aún más difícil, porque el programador no debe volver a resolver el problema, sino a elegir el siguiente. Cuán dolorosa es la elección, ya lo hemos discutido.
Si para resumir las pérdidas de la elección, siempre están ahí. La única pregunta es su cantidad. Para inspirarte, te llamaré esta cifra: toma hasta el 50% del tiempo elegir una tarea. Solo piensa en esta figura.
Pero, en el contexto de nuestro material, esta figura es simplemente hermosa. Al eliminar la pérdida de elección, puede duplicar la eficiencia.
¿Cómo deshacerse de la elección? No hay nada mas facil. En realidad, tú mismo sabes cómo hacerlo. Presentaré mis sugerencias, y las combinará con sus propios métodos, y se obtendrá un aumento decente en la eficiencia.
Lo primero y más importante para comenzar es controlar. Cualquiera que sea el sistema de prioridades y distribución de tareas que se le ocurra, no funcionará hasta que los programadores "lo escuchen".
El control, en pocas palabras, es el control numérico. En este caso, la cifra no será el beneficio o la cantidad de ventas, sino el número de secuencia de la tarea en la cola. Debe administrar la selección de tareas en función de este número y asegurarse de que las tareas se resuelven en el orden indicado.
El control es necesario si gestionas un equipo, e incluso cuando te controlas a ti mismo. Después de todo, ¿estar de acuerdo contigo mismo es más fácil que con un jefe? "Sí, ahora, por última vez, ¡y seguro!"
En general, hablaremos más sobre el control con más detalle, aquí corrí por delante, pero vale la pena. Si se le ocurrieron las reglas para elegir una tarea, pero nadie las ejecuta, entonces nada funcionará.
Por lo tanto, todo lo que debe hacerse es alinear las tareas en la cola y asegurarse de que se siga esta cola. En algunas fuentes, se recomienda ocultar la cola a los programadores, dejando solo dos tareas a la vista: la actual y la siguiente. Si le muestra al programador todas las tareas a la vez, no importa cuánto lo intente, él todavía "mirará", estudiará lo que le espera.
El primer método es la distribución de tareas por parte del jefe, sin utilizar la automatización. Simplemente diga quién hace qué y en qué orden. Puede hacer planes simples, por ejemplo, en forma de pequeños trozos de papel, como órdenes de trabajo o tareas de producción. Simplemente puede dictar los números de tarea para escribir en un cuaderno.
Puedes hacer un tablero, como scrum, y colgar calcomanías allí durante el día. El método de scrum implica colgar muchas tareas, por ejemplo, durante una semana o un mes, pero esto no nos conviene, porque la elección aparece nuevamente.
La asignación manual de tareas es muy fácil de comenzar e igual de fácil de detener, porque se aburre rápidamente. Necesita tener una fuerza de voluntad significativa, o buenas habilidades de gestión regular, para obligarse a distribuir las tareas diariamente. Si lo anterior se trata de usted, puede comenzar hoy.
Para la automatización perezosa es adecuado. En su sistema de información, donde se almacenan las tareas, debe establecer un mecanismo para clasificarlas. Como estas mas cerca Ordenar por fecha de producción? ¿Por plazo? Cualquier forma es buena. Lo principal es que sea determinado e igualmente entendido por los programadores. Personalmente, recomiendo no limitarse a la clasificación, sino a almacenar números en una cola como un campo separado. Los sistemas modernos son demasiado convenientes para el usuario y le permiten configurar la clasificación de forma independiente. Entonces decidió que debía realizar tareas en el orden de recepción (FIFO), y el programador, accidental o intencionalmente, cambió la clasificación a la opuesta y recibió LIFO.
Si se guarda el número en la cola, entonces ordenar, no ordenar, es difícil cometer un error.
No puede apegarse a la clasificación, pero establezca los números manualmente. También funciona si tienes suficiente fuerza de voluntad para organizar estos números.
El principio, creo, es claro. Cualquier sistema de colas entendido por programadores y monitoreando su cumplimiento. Este será el primer paso para privar a una elección que requiere eficiencia.
El segundo paso lo consideraremos más a fondo. Nos permitirá obtener muchos más beneficios de las colas, no solo para simplificar la elección, sino también para hacerlo bien.
Resumen- Elegir una tarea no es un instante, sino un proceso largo;
- El programador elige una tarea basada en sus propias ideas;
- Se dedica una gran cantidad de tiempo a la elección;
- El proceso de selección no es bueno ni de placer;
- La elección debe ser privada;
- Puede distribuir tareas manualmente, como un capataz;
- La automatización puede ayudar a hacer cola.