Transparencia - La panacea de los Butcherts

Ya he tratado de tratar un scrum "mecánico" ( parte 1 , parte 2 , parte 3 ), y en este artículo intentaré escribir un medicamento universal para la "quema". Por sí mismo, "ardiendo", "hirviendo", etc. - Esto es bueno, significa que no te importa ( pero la indiferencia es un paso hacia el desánimo o, como es habitual en TI, para agotarse ). Se han escrito y filmado muchos materiales sobre el tema del daño por agotamiento, por ejemplo: aquí , aquí , aquí o aquí .

Una sabiduría común dice: "Buttherts son el motor del progreso". Pero a menudo sucede así: se quema => una solución superficial se adopta rápidamente, enmascarando el problema => la solución cobra vida => continúa ardiendo. En otras palabras, en lugar de resolver y hacer un diagnóstico, procedemos inmediatamente al tratamiento. Trataré de ilustrar esto con ejemplos.


Primero, definamos el término "transparencia". La guía Scrum lo define de esta manera:

Los aspectos significativos del proceso deben ser visibles para los responsables del resultado. La transparencia requiere que esos aspectos se definan mediante un estándar común para que los observadores compartan una comprensión común de lo que se está viendo.

Los aspectos importantes del proceso deben ser visibles para los responsables del resultado. Estos aspectos deben definirse mediante un estándar común para que los observadores entiendan igualmente el objeto de observación.

Estas definiciones se aplican solo al proceso, quiero considerar el concepto de manera más amplia. No me comprometeré a dar definiciones científicas exactas, pero intentaré describir la "transparencia" a través de las condiciones necesarias para su existencia. Entonces, para la transparencia, necesita:

• El objeto que alguien necesita ;
• Un objetivo común para todas las partes interesadas relacionadas con la instalación;
• El deseo de todas las partes interesadas de lograr el objetivo;
• La capacidad de todos para comunicarse en un idioma, es decir la capacidad de desarrollar un marco conceptual que sea significativo para todas las partes interesadas ( por ejemplo, términos como ROI y Redux , parece que se encuentran en planos diferentes y distantes, aunque muy capaces en entornos de información específicos ).

Si se cumplen estas condiciones necesarias, puede comenzar el proceso de creación de transparencia: definir la tarea, definir criterios de éxito para resolver el problema, desarrollar un método para evaluar los criterios. Como puede ser:

En primer lugar, respondemos las preguntas principales:

• Para que vas
• Cual es el proposito

Es posible la siguiente secuencia de acciones:

• Definimos la terminología ( por ejemplo, todos entienden la tarea finalizada de la misma manera, y no de modo que para el desarrollo sea cuando se escribe el código, y para los negocios es cuando el cliente comenzó a usar los resultados );
• Acordamos aspectos clave y cómo mediremos su condición, cómo percibiremos los resultados ( por ejemplo, nos reunimos una vez al día, miramos el plan, determinamos nuestra condición con respecto a este plan );
• Encarnamos nuestro plan.

Por separado, quiero enfatizar que la coherencia y la adopción general de acuerdos son importantes, sin lo cual es difícil lograr la participación. De hecho, en los sistemas de toma de decisiones ( por ejemplo, en el ejército ) la base conceptual es uniforme, las acciones y los criterios de evaluación son claros, pero la cantidad de aceptación ( hay empatía ) por parte de los participantes es una gran pregunta.

Espero haber logrado revelar mi idea de transparencia, luego intentaré dar algunos ejemplos de situaciones que pueden mejorarse si se agrega transparencia.

¿Soy una criatura temblorosa o tengo el derecho?

Recientemente, me parece que el tema del agotamiento profesional en el entorno de TI ha sido muy agudo ( se realizan reuniones temáticas completas sobre este tema, por ejemplo, PiterJS , donde hubo un informe de mi colega Zhenya Kot bunopus ).


Nuestro trabajo es intelectual, la mentalidad es analítica, bueno, usted mismo lo sabe. Me parece que hay una tendencia a inventar dificultades donde no existen. A veces esto sucede precisamente por la falta de transparencia ( aquí hay un par de resultados de la investigación: uno y dos ), y no por la gran cantidad de trabajo: no hay información necesaria: la elaboraré yo mismo ( recuerde la mentalidad analítica ), sacaré conclusiones de la suposición, elaboraré un plan e ir a la guerra con castillos en el aire. Estas son las preguntas que nos pueden preocupar ( especialistas de TI ):

• ¿Pero estoy haciendo tonterías? ¿Cómo mejora mi trabajo el mundo?
• ¿Qué tan bueno soy en mi negocio?
• Sí, ellos saben quién soy? Quienes son ¿Qué se permiten?
• Que sigue A donde voy ¿Voy con esos?

Las preguntas son correctas, es importante que una persona reflexione sobre el pasado, piense en el presente y planifique el futuro. Es importante pensar en las personas que están cerca. Y transfiriéndolo al trabajo, por supuesto, podemos esperar que los propios trabajadores busquen respuestas a estas preguntas, aclaren lo que les preocupa. Pero simplemente puede hacer que todo esto sea transparente, y luego las personas se centrarán en asuntos más importantes y resolverán problemas en el siguiente nivel, con el objetivo de optimizar, innovar, etc. Hay toneladas de herramientas para proporcionar este tipo de transparencia, aquí hay algunos ejemplos:

• Los objetivos, la misión y la estrategia de la empresa son abiertos y comprensibles para los empleados, y son bien conocidos. Todas las tareas tácticas se enseñan a través de la comunicación con la estrategia, siempre está claro para qué objetivo actual se requiere este o aquel trabajo. Está claro no solo lo que hay que hacer, sino también por qué hay que hacerlo.
• Los empleados reciben regularmente comentarios sobre los resultados de su trabajo: logros, puntos de crecimiento ( por ejemplo, encuestas de 360 o 1 a 1 ). Planificación conjunta del desarrollo e inspección de la dinámica para lograr este plan.
• La estructura organizativa descrita y las comunicaciones dentro de ella: qué y con quién puede hablar. Contratos sociales, tarjetas de visita del equipo, etc.
• Un sistema de motivación transparente, un árbol de carrera y, posiblemente, la gamificación de este proceso. Puede inspirarse con ejemplos de litros o 2GIS , y construir su propia cultura en la que los empleados entiendan cómo determinar e influir en su nivel de motivación material.

Ahora, sin embargo, como siempre, todos están ocupados buscando "el lugar de una persona en este mundo", y si se dan las herramientas para definirse al menos en el trabajo, entonces ese empleado será un poco más armonioso y feliz, y puede haber menos casos de agotamiento profesional.

Cruzadas

A los blancos nos encanta romper lanzas en guerras santas: React vs Angular , iOS vs Android, OOP vs funcionalism, etc. Pero desafortunadamente o afortunadamente, no hay una "bala de plata". Hay una tarea específica y soluciones. Cuando nos enfrentamos a la elección de tecnología, marco, arquitectura, etc., con un alto grado de probabilidad, estamos en un dominio "confuso", de acuerdo con el modelo de Kenevin , y, como resultado, no hay una respuesta correcta. En esta situación, es deseable darse cuenta y solucionar el problema que se está resolviendo, para comprender qué alternativas estamos considerando, qué criterios tenemos para tomar decisiones. Es necesario recopilar estos datos juntos, hacer una elección y también documentarlos. Con el tiempo, vale la pena volver a estos artefactos y conciliar con dónde nos estamos moviendo. Todo es cambiante: el mundo, la empresa, el equipo, personas específicas, condiciones, etc., por lo tanto, cuando tenemos información sobre qué áreas y por qué elegimos, es más fácil ajustar el camino en función de este conocimiento. Y para no caer en la clásica situación de rasgarse un chaleco en el pecho : “¿Pero quién inventó todo esto? Parece que las personas no eran adecuadas, una vez que esto se acumula. Aquí está la respuesta correcta, es obvio. Guardaré a todos y rehaceré todo ".

Creo que muchas personas están familiarizadas con la situación cuando, en un intento de construir un "nuevo mundo maravilloso", cambian sus líderes, el equipo, a aquellos que están listos para quemar Babilonia, pero el resultado no es un fénix, sino un duende.

Puede tratar de no quitárselo del hombro, pero analice retrospectivamente todos los errores e imprecisiones, haga un seguimiento de la lógica de las decisiones técnicas, tenga en cuenta los riesgos y presente una nueva hipótesis. Y la base para la toma de decisiones no será "todos son tontos ...", sino "las condiciones han cambiado y ya estamos resolviendo un nuevo problema".

Me parece que es difícil tomar las decisiones técnicas correctas todo el tiempo. Puede aprender a configurar experimentos, evaluar los resultados obtenidos y planificar los próximos pasos, teniendo en cuenta la nueva información recibida. Y puede ser más fácil si tiene artefactos disponibles para todas las partes interesadas que describen la lógica de las decisiones técnicas.

Implemente agile / scrum / kanban / lean en cp * ki comprimido

Hay un debate eterno en el entorno ágil: "¿Dónde comenzar la transformación: desde cultura / valores / mentalidad o mecánica / rituales / artefactos?". Un dilema tan clásico de pollo y huevo. Mi posición es que para un entrenador ágil "fuerte e independiente" puede suceder que un equipo a través de la mecánica llegue gradualmente a la atención plena. Pero más a menudo, si comienza con la mecánica e implementa algún tipo de enfoque como culto a la carga, lo más probable es que tengamos escepticismo y decepción en la metodología, y en el peor de los casos, también ganaremos enemigos. Cómo puede suceder esto está bien descrito en la Guía Scream ( aquí una traducción ardiente ).

Por lo tanto, estoy a favor de analizar la cantidad de valores ágiles en su caso, y solo luego proceder con la aplicación de un marco o técnica. No hay una prueba universal, pero hay documentos de tornasol ( por ejemplo: prueba ágil y guía ágil ): primero piense si el scrum condicional lo ayudará en su caso o no ( otro ejemplo de una tabla de prueba ).



Considere un ejemplo: una empresa se quema porque el desarrollo es lento, se toma una decisión: implementemos scrum / kanban / lean, porque acelera el desarrollo ( por lo que no significa ). Y con el tiempo, concluimos: "esto es charlatanería y trucos de marketing, no funciona". ¿Una historia familiar? Mi opinión es comenzar con transparencia. Vamos a entender qué es exactamente lo que molesta. Comencemos hablando en los mismos términos y comprendamos los términos de la misma manera. Formulemos las preguntas: “¿Cuál es el problema?”, “¿Cómo entendemos que es malo?”, “¿Cómo entender qué es mejor?”, “¿Cómo determinamos qué es bueno?”, “¿Todos se dieron cuenta del problema y lo percibieron? ella como un problema ( por ejemplo, no los caprichos de los estúpidos gerentes )? Y cuando todo se volvió transparente, en este momento puedes buscar soluciones. De hecho, "desarrollo lento" puede significar:

• No hay un proceso de implementación normal; implementar cambios en los productos es una molestia. Opciones de solución: implementar la cultura DevOps , ejecutar CI / CD ;
• Los negocios y el desarrollo no han aprendido a hablar. A las empresas les parece que el desarrollo no comprende nada, y el desarrollo, por el contrario, cree que la empresa no sabe lo que quiere. Posibles soluciones: intente crear un establecimiento de objetivos, crear mapas de impacto o utilizar OKR ;
• La estructura jerárquica está llena de microgestión, en la que hay una lenta adopción de decisiones tácticas debido a la necesidad de coordinación con las superiores. Opciones de solución: capacitar a las personas en facilitación, realizar experimentos con confianza ( ver un video motivador con TED );
• La lista continúa.

Puede haber muchas situaciones; para cada una de ellas, existen herramientas de mejora propias. Y a menudo la implementación de agile / scrum / kanban / lean / etc. parece martillar las uñas con un microscopio y, de hecho, crea la apariencia de actividad violenta, pero no busca una solución al problema. Por lo tanto, la regla "no te conviertas en un ídolo" funciona aquí: no debes buscar una bala de plata en los enfoques / metodologías / marcos publicitarios, primero debes darte cuenta del problema que estás resolviendo y elegir una herramienta de solución después de eso. Y resulta que, habiendo emprendido el camino de la mejora continua ( conciencia del problema, formalizando el trabajo con él, transparencia, encontrando soluciones a través de experimentos ), construirá su proceso como nunca, pero funciona perfectamente para usted.

¿Por qué soy todo esto?

Según el modelo de Kenevin, casi todo nuestro trabajo de TI está en un dominio confuso, lo que significa que la opinión de expertos no funciona aquí y no hay respuestas correctas. Y una de las posibles opciones para una existencia cómoda es un proceso empírico que comienza con la transparencia. Parece que estas son verdades comunes, pero parece que no siempre se recuerdan.

Si lees hasta este lugar y te bombardea un artículo de otro capitán populista, entonces puedes intentar hacerte preguntas:

• ¿Por qué se quema?
• ¿Por qué me enfureció?
• ¿Qué podría ser diferente para no causarme tales emociones?

Escribe todo esto en los comentarios: coloca todos los puntos sobre i y haz que esta pregunta sea transparente.
Resumiendo: la opacidad puede conducir a la desintegración de la sociedad en grupos, guerras santas, manifiestos , etc. Pero puede sentarse y tratar de hablar el mismo idioma y escucharse mutuamente. Toda la transparencia!

¡Gracias por la ilustración, Sai Kin !