Gestión de arreglos

Hablemos sobre la gestión de los arreglos. ¿Por qué es todo esto de repente? Sí, porque en TeamLead Conf nos encanta discutir dolores y problemas, pero no nos olvidamos de las soluciones. Seguramente todos tienen problemas asociados con los arreglos laborales.

"Los arreglos no se están implementando", Captain Evidence

El dolor con ellos, en primer lugar, es que los acuerdos no se cumplen: todos lo saben, incluso nuestro amigo, el Capitán Evidence, que nos ayudará en este artículo.

Parecería, ¿cuál es el problema? Muchas cosas no van como nos gustaría. Por ejemplo, los días soleados no siempre son en San Petersburgo. Entonces, qué, la ciudad se para, la gente viene, me encanta. Lo que no sucede de la manera que queremos no siempre es un problema realmente serio.

Sin embargo, en este caso, Stas Mikhalsky afirma que el problema es más que grave. Debajo del recorte, entenderemos qué conduce al hecho de que el acuerdo no se está implementando y cómo, al final, hacerlos indestructibles.


Sobre el orador: Stas Mikhalsky se ha dedicado al desarrollo web desde 1998. Pasó de ser un programador junior de Perl a un director de desarrollo en Biglion. Participó en el desarrollo de varias docenas de proyectos con alta asistencia y brindó su apoyo.

¿Por qué es esto un problema?

Los negocios y el liderazgo de nuestros equipos y de nosotros, como líderes de equipo, estamos esperando el resultado. Completar una tarea a tiempo puede no conducir a un resultado, pero esta es una historia diferente.

El trabajo y el resultado son dos cosas diferentes, pero hablemos de esto en otro momento.

El resultado es el resultado del trabajo: la finalización de tareas, proyectos, subproyectos. Son posibles diferentes divisiones, pero de una forma u otra, el trabajo consiste en algunas acciones, cada una de las cuales es en realidad una consecuencia de un acuerdo.

Parece que todo está claro: cuando no realizamos acciones, rompemos acuerdos.

Consideremos ejemplos estándar. El cumplimiento del estándar de estilo de código es un acuerdo con un desarrollador específico. No todo el equipo responde con una sola voz: "Sí, sabio Kaa, respetaremos el estilo del código", pero todos dicen personalmente que promete cumplirlo. Lanzar el lanzamiento el viernes o lunes también es un acuerdo. Independientemente de lo que hagamos, alguien nos ha preguntado sobre esto, o nosotros mismos hemos decidido que esto es necesario para algo, si se espera un resultado de nosotros, entonces esta es una acción tomada como parte de un acuerdo.

- Si nosotros mismos decidimos que esperan esto de nosotros, ¿es un acuerdo?
- Sí, un acuerdo consigo mismo, pero este es un caso especial.

Ahora lo más interesante es en realidad lo contrario: un acuerdo fallido = acción fallida.

Es decir, no se interrumpe un acuerdo si la acción no se realiza, pero la acción que no se realiza es el resultado de un acuerdo fallido . No lo hicimos, porque no estábamos de acuerdo, o realmente no queríamos, o algo más. En el centro está el problema con el acuerdo. Por lo tanto, obtenemos una imagen en la que un acuerdo fallido conduce a una acción incumplida, que, por supuesto, afecta la calidad del trabajo y, en última instancia, a la falta de resultados.

Quiero transmitirle la idea de que los desarrolladores, back-end, front-end, probadores, líderes de equipo, gerentes de desarrollo son algunas de las funciones y roles dentro de los cuales hacemos algo. Pero si miras un poco más alto, entonces todo nuestro trabajo es la conclusión de acuerdos y su implementación. Es como UDP: todo lo demás está envuelto en un acuerdo. Si no sabemos cómo concluir los acuerdos correctamente, entonces podemos ser excelentes front-end o back-end, escribir un código excelente, pero no habrá resultado.

Por el contrario, si aprendemos cómo crear los arreglos correctos, entonces:

• ahorre mucho tiempo;
• reducir significativamente los gastos generales para todos los controles, desmontajes, etc.
• Realmente podemos hacer nuestro trabajo.

Que hacer

"Asegúrese de que se implementen los arreglos"

Capitán Evidencia

Esto está claro para todos, incluso el capitán de Evidencia, solo debe asegurarse de que los acuerdos se implementen, y no es necesario que lo haga para que no se implementen.

El modelo clásico de cómo se puede lograr esto:

1. Comprende las razones.
   
2. Identificar y tomar medidas para abordar estas causas y cambiar el resultado.
   

Hablemos un poco más en detalle. Hay tres actores:

1. Un acuerdo para tratar.
   
2. Interrupción que le sucede a un arreglo.
   
3. Las razones del fracaso.
   

Si miras todo esto desde todos los lados, entonces probablemente puedas entender cuál es el problema y cómo mejorar la situación. Espero que la situación requiera intervención, todos están de acuerdo.

¿Qué es un arreglo?

El acuerdo consta de dos partes: compromiso y promesa. La diferencia entre ellos es que se hace un compromiso, se hace una promesa .

Una promesa es un despojo, es un mensaje para alguien de que me comprometí. En principio, incluso no se puede dar, ya que esto es solo un mensaje de notificación. Pero asumo esta obligación. Por lo tanto, un compromiso sin promesa es mucho mejor que una promesa sin compromiso. Nos encontramos con esto último con bastante frecuencia.

Honestamente, me parece que todo el problema es que no todos (y nosotros también) y no siempre, cuando celebramos acuerdos, pensamos en las obligaciones. No siempre tomamos decisiones conscientemente y realmente comprendemos con qué nos amenaza esta promesa. Solo asentimos: "Sí, sí", nos vamos, pero no asumimos nuestra obligación con nosotros, y este es un gran problema.

De hecho, todavía es mucho más complicado, porque los arreglos son de tipo diferente:

• Como parte de sus responsabilidades inmediatas , por ejemplo, escribir comentarios en código, completar el lanzamiento al medio ambiente.
• Fuera del trabajo principal , por ejemplo, para monitorear la relevancia de la información en la wiki, leer un libro, ir a cursos.
• Cambie el comportamiento , por ejemplo, comience a trabajar a una hora determinada o haga un seguimiento del tiempo dedicado a la tarea.

Estos son acuerdos completamente diferentes, las personas los tratan de manera diferente y usted necesita trabajar con ellos de maneras completamente diferentes.

Como regla general, el alcance del trabajo principal va más allá de las preguntas, que en cierto sentido son más importantes, según me parece, que el nivel de codificación actual del desarrollador, porque puede transformarse a través de ellas. Si una persona sabe cómo aprender, esto es completamente diferente que si aprendiera a codificar rápidamente y sin errores en 10 años. A veces, aceptar un desarrollador para leer un libro puede ser mucho más difícil que exigirle que documente el código. Pero es aún más divertido cuando se trata de cambiar el comportamiento.

Un ejemplo clásico, cuando solía ser poco importante ir a 10 o 12, porque, en todo caso, puede demorarse y refinarse, y ahora necesita estar en el lugar de trabajo a más tardar a las 11, debido a los procesos, etc. Si una persona simplemente está de acuerdo: "Sí, bueno, vendré a las 11 mañana". Esto no es un cambio de comportamiento, sino una hazaña. Si resulta que para esto es necesario, tal vez, reconstruir la vida: acostarse un poco antes o no jugar Warcraft, entonces eso significa que la persona misma debe cambiar. Esto es difícil y, lo más importante, incontrolable, como cualquier proyecto.

Por lo tanto, es muy importante entender de qué tipo de acuerdo estamos hablando. El grado de elaboración depende de qué tipo de acuerdo estamos tratando de concluir.

Interrupciones

Los acuerdos no solo se rompen, sino que se rompen, en primer lugar, inesperadamente y en segundo lugar, en la línea de meta, porque es mucho más divertido. Aunque esto es inesperado, generalmente se encuentra en un punto predecible. Siempre sé cuándo se romperá el acuerdo.

Ahora estamos trabajando en equipos, la edad de los solteros y las computadoras de garaje ha pasado. Tenemos un equipo, procesos y todos los arreglos en una cadena. Si se derrumba, entonces todo se derrumba. Si una persona simplemente no leyó el libro, entonces, en principio, nada irá mal o se romperá, pero en un año su equipo de repente no será mejor que ahora. Para mí, este archivo es mucho más grande que dos horas de falla de todos los sistemas.

Las interrupciones también son diferentes.

El fracaso es mi tipo de fracaso favorito, el más honesto y el más inofensivo. Estuvimos de acuerdo, la persona prometió y no lo hizo, sucede. Este es un desglose simple, porque todo está claro con él.

Hay opciones más desagradables, como la ejecución formal.

La ejecución formal es cuando el viernes por la noche el desarrollador (para una cápsula de cerveza como inspiración) extiende 40 horas de tiempo de trabajo para las tareas que realizó en una semana. De hecho, la persona que hizo este acuerdo con usted no recibe nada en este momento. Si el registro de tiempo no es necesario para presionar a todos, pero para comprender estadísticamente cuánto tiempo toman los diferentes tipos de tareas, cuál es el error promedio, etc., tal ejecución arruina toda la iniciativa. No habrá estadísticas, porque los datos se toman de la cabeza. Como resultado, el acuerdo no se cumplió, aunque parece que se ha hecho algo, y todo está bien.

El problema es que no siempre registramos el cumplimiento formal como un acuerdo roto. Especialmente si usted no está muy interesado. Por ejemplo, soy un líder de equipo, el director me dijo desde arriba: "¡Escribe un reloj, de lo contrario castigaré a todos!" Vine al equipo y transmití que necesito grabar el reloj, de lo contrario, todos serán castigados. Como resultado, el reloj se grabó de alguna manera, estoy satisfecho, tengo algo que mostrarle al director. Yo mismo participo en este sabotaje, y para mí la ejecución formal es importante. Para el proveedor de tareas, no es aceptable.

La sustitución es ligeramente diferente de la implementación formal del formulario, pero de hecho es el mismo intento de violar el acuerdo. Justo en lugar de la visibilidad de la tarea completada, se crea una sustitución. Usando el ejemplo del registro de tiempo, suena algo como esto: “Para registrar el tiempo de cada tarea, necesito 5 minutos. En total, esto es dos horas a la semana. Oh bueno el. He realizado una tarea que no tenía intención de hacer en 4 horas. Pero hice más de lo que prometí, ni tampoco empeñé con el tiempo.

Este es un intento de darle algo para que esté atrasado con el cheque, pero en realidad también es un colapso. El problema es que, como regla, tenemos muchas otras cosas, el tiempo no seguro no es lo peor. Nos aprobamos a nosotros mismos.

Repito: un acuerdo pendiente es un trabajo negativo, un resultado negativo.

¿Cómo sobrevivir en un mundo de arreglos incumplidos?

Simplemente puede recordar : "¿Recuerdas que registramos el reloj?". Cuando se trata de cambiar el comportamiento, un recordatorio es un buen resumen. Los carteles colgantes más astutos que respaldan el modelo de comportamiento: "¡Tiempo prometido, salvó al castor!". De hecho, simplemente le recordamos que hubo un acuerdo, sin verificar su estado en este momento.

Puede ser un poco más persistente y preguntar cómo se implementa el acuerdo, si la persona ya ha hecho algo. Esto difiere de un recordatorio en que te obliga a dar algún tipo de respuesta articulada. Pero entonces pones a la persona antes de la elección: mentir o no mentir. La respuesta, por cierto, no es obvia para todos. En cierto sentido, estás empujando a una persona a lo malo. Preguntar es un tipo de control latente: parece preguntarse, pero no marcarse. El hombre mintió, pero lo dejamos en su conciencia.

Puedes consultar :

• por resultado;
• paso a paso
• en la dinámica

Verificación por el resultado que ya hemos discutido. La pregunta es qué hacer si el resultado no es satisfactorio, pero volveremos a esto más adelante.

Por pasos y por dinámica, es posible verificar el cumplimiento de un acuerdo dentro y fuera del trabajo. Por ejemplo, persuadimos a una persona para que completara una base de conocimiento, esbozamos un plan con él y seguimos ese plan; esto aún no se ha completado. Pero, ¿qué pasa con el cambio de comportamiento? Una persona registra el tiempo o no lo hace; o llega a tiempo o no. Es ridículo seguir esta transformación por pasos y dinámicas: hoy es media hora tarde, mañana 25 minutos, pasado mañana 20.

El mayor problema de validación es que esto no siempre es posible. Dado que los acuerdos se hacen todo el tiempo y con muchas personas, esto también requiere mucha mano de obra .

Existe un modelo de gestión en el que casi todo el tiempo que un gerente dedica al control de ejecución de tareas existe, pero no funciona bien en TI. Sí, y este es el siglo pasado. Espero que ese enfoque de gestión muera algún día, como el último dinosaurio.

En lugar de controlar, comprendamos mejor por qué ocurre realmente el colapso, por qué la persona que nos hizo la promesa no lo cumplió.

Razones para el desglose

Esta es probablemente una lista incompleta, pero aquí están los ejemplos más llamativos:

• Consentimiento irrazonable. Una persona está de acuerdo, porque es vergonzoso negarse: usted es su líder o simplemente una persona respetada, o sinceramente quiere ayudarlo, le gusta o no le gusta negarse en absoluto.
• Error en la evaluación. Una persona puede pensar, estar de acuerdo, pero cometer un error en la evaluación. Luego vendrá y dirá: "Sí, lo prometí, pero el trabajo fue el doble de lo que esperaba".
• Cambio de prioridades: "Casi termino, pero luego vino Vasya, tiene un problema aún más importante, así que lo siento".
• Falta de recursos , simplemente no hay suficiente tiempo.
• Circunstancias imprevistas : el piano cayó desde arriba.
• Sabotaje

A menudo, detrás de todas las excusas se encuentra el rey de los acuerdos frustrados: el sabotaje . Cuando no queremos hacer y no queremos admitir que no queremos hacer, tenemos un sabotaje. Beber 40 horas a la semana para tareas que utilizan el método de empuje es sabotaje. Llegar al trabajo a las 9 de la mañana y tomar café es un sabotaje. Se basa en una reticencia a hacerlo, que no se ha expresado explícitamente.

De hecho, hay más causas sistémicas del colapso . Lo que hemos dicho yace en la superficie, y si profundizas, solo hay tres razones:

1. Tipo de arreglo no tomado en cuenta.
   
2. El tipo de acuerdo no está acordado.
   
3. Una promesa sin compromiso.
   

Además, el primer y el segundo párrafo pueden estar presentes a la vez. Cuando concluimos un acuerdo, no pensamos en lo que acordamos. A menudo esto suena así:

- ¡Egeo, hazlo!
- Ok, lo haré! - y huyó

Esto se puede hacer cuando hablamos de trabajo en el trabajo, por ejemplo, sobre cómo escribir un módulo: "Haz rápidamente la tarea 28". Pero esto no se puede hacer cuando se trata de prepararse para una reunión en un mitin, por ejemplo. En el buen sentido, para preparar un discurso en una reunión, debe sentarse, ordenarlo, explicar lo importante que es, etc. Pero a menudo hacemos todo al mismo ritmo : "Haz esto" o "¡Mira, ya no llegues tarde!" - Y corrió .

Sucede que estamos de acuerdo, teniendo un entendimiento diferente sobre el tipo de acuerdo. Un ejemplo clásico es la documentación del código. En el pasado, tal vez todo ha cambiado, pero cuando me encontré con esto, mis colegas y yo tuvimos un debate constante sobre si el desarrollador debería documentar el código o no. Como líder, creo que debería. El desarrollador cree que el código funciona, y bueno, dada la carga de trabajo y las prioridades en constante cambio.

Un conflicto de comprensión del tipo de arreglo no siempre se revela. A menudo creemos que este acuerdo no necesita ser aclarado, reforzado, porque todo ya está claro: simplemente tómalo y hazlo. El subordinado cree que de él quieren desde arriba lo que él no quiere hacer. Y entonces comienza el sabotaje .

La situación más popular, como dije, es una promesa sin obligaciones. Un acuerdo que dio lugar a una promesa, pero no dio lugar a una obligación, no se cumplirá por una razón u otra: el piano se caerá, una persona se distraerá, algo más sucederá.

De hecho, en condiciones de complejidad de los sistemas, la intensidad de los cambios: cuando todos escribimos a toda prisa, lo desarrollamos rápidamente, lo rehacemos, en otras palabras, en condiciones de entropía, siempre puede suceder algo que impida el cumplimiento del acuerdo. Por supuesto, puede controlar cada paso, aprovechar cada caso de cada uno de sus subordinados, tratar de ayudarlo a llegar a la implementación de nuestro acuerdo. Pero entonces no habrá tiempo suficiente para nada más que tirar de todo por su cuenta.

La única posibilidad de que se cumpla el acuerdo es que una persona quiera cumplirlo.

Si deseo cumplir el acuerdo, me ocuparé de todos los problemas que surgen: los pianos que caen, el hecho de que cometí un error al evaluar, etc.

Esto es similar a la ideología de Scrum, al igual que la complejidad de la tarea no se conoce completamente. Hacemos algunas suposiciones con un error en la experiencia previa, evaluamos y luego hacemos todo lo posible para cerrar el sprint. Reconocemos que sí, será difícil, que podríamos cometer un error en alguna parte de la evaluación, que el sistema puede sorprendernos, pero lo haremos para resolver el problema.

Con el arreglo, debería ocurrir lo mismo que con los sprints en Scrum. Una persona que se ha comprometido a hacer algo solo tiene que hacerlo. ¡Todo es simple!

Resumiendo, lo que se dijo sobre las razones del fracaso del acuerdo:

• Una promesa no es una garantía.
• El control es difícil.
• El fracaso se revela sobre el hecho.

Está claro lo que hay que hacer: solo cree acuerdos duraderos que sean fáciles de administrar y finalmente vaya a las Bahamas.

Capitán Evidencia

En otras palabras:

• Tal como está: el sistema ahora se ve así: arreglos bastante frágiles que son difíciles de administrar.
• Para ser, debe ser: acuerdos indestructibles, cuya gestión es transparente y no laboriosa.

Para una situación de análisis GAP estándar, "Ser" es el objetivo final por el que nos estamos esforzando, pero no el hecho de que lo alcanzaremos. Pero debemos esforzarnos.

Queda por descubrir qué es un acuerdo sólido y cómo gestionarlo.

Acuerdo fuerte

Acuerdo fuerte: estas son obligaciones reales que se concluyen con una persona vinculante. Esto es muy importante Hablamos sobre obligaciones, como sobre algún paquete que necesita ser transferido, y ahora hablaremos un poco sobre el proveedor de este paquete.

Los arreglos realizados con una persona opcional conducen a inconsistencias. Si imagina el trabajo en forma de una serie de acuerdos que se envían en diferentes direcciones en lotes, cuando intente concluir un acuerdo con una persona opcional, prepárese para el hecho de que con un 50% de probabilidad perderá tiempo. Por lo tanto, lo primero para comenzar es aumentar el precio de una palabra.

Precio de la palabra

Idealmente, cada uno de sus colegas debe comprender que cumplir con las obligaciones es su trabajo principal. Esta es la esencia de su trabajo. Código escrito, liberación desinflada son derivados de obligaciones cumplidas. Por lo tanto, trato de hablar con las personas específicamente sobre las obligaciones y que el problema no es que el código no esté escrito o no haya resultado. Esto es una consecuencia y mucho dolor. Pero la esencia del problema es que, habiendo asumido la obligación, no encontramos una manera de cumplirla.

Si nunca ha hablado de esto con la gente, entonces, en general, no es tan obvio. Sospecho que para hablar de esto, puede ser necesario correr primero por la escalera desde el comienzo del informe "resultado - trabajo - acción - acuerdo" y viceversa. , , — , , , .

, , . - . , , 10 3. , — .

, .

, — . — , .

, , .

, — : « , ».

— , . , — . , .

— . , .

, , , .

, - — .

« » . , — . , , . , . , - . , , , , :

1. , .
   
2. , .
   

, , . — — , . - . , , , . , . .

, , «» :

• .
• .
• .

— , , , , , .

, . , .

, .

. , , : , , . , , , , . , — , - , . — .

, . — , «» . , — . - , . :

— , !
— .

-: «, , . 10:55. , ».

, , 5 — , , . , : , .

— — , .

?

, : ? 4 , , - :

1. ?
   
2. ?
   
3. , ?
   
4. , ?
   

. , . , .

: «, - , , , !» , , , .

, . . - , , , , .

« » . — . , , — .

« » , - , . , , — . , . , , .

, :

• .
• .
• , , — , .
• « » . , .

, Excel, : , , , . , .

?

, , , . , …

? ? — : — , — , — .

, «» , , . «» — - . « » , « ?» « ?»

…

Pero la opción de ir a TeamLead Conf o no, en mi opinión, es obvia. Además, el programa está casi listo. Pero puede elegir Moscú en febrero o Peter en septiembre, e inscribirse en el boletín para no perderse nuevos videos y artículos, la apertura de Call for Papers y las fechas clave.