Organizamos el caos o cómo implementar un enfoque basado en procesos en una organización

Una vez que cambié mi trabajo y pasé de una organización grande y bien estructurada a una startup en auge. Realmente me gustó todo de una vez: la energía con la que trabajaban las personas, la profesionalidad y el alma de las comunicaciones internas. Pero en el momento en que comenzaron a transmitirme los asuntos de PM, me esperaba una sorpresa:

- En el sentido de que no hay descripciones? Es decir, no ha escrito en ninguna parte, ¿con qué reglas trabajan sus equipos? Absolutamente, ¿en serio? ¿Incluso un SLA? ¿Y cómo me vas a dar? En términos de memoria, ¿qué pasa si algún tipo de arreglo se olvida y no se transmite? ¿Cómo entiendo esto en el camino? Oh mami ...

¿Alguna vez ha tenido la sensación de que su cabeza es redonda y el pensamiento que está tratando de pensar es cuadrado? Así es como me sentía acerca de mí mismo, tratando de entender cómo trabajaría. La startup ya no era pequeña: más de 200 personas, oficinas en varios países, clientes en todo el mundo. Y, por lo que entendí, los acuerdos sobre cómo trabajan los equipos de desarrollo, con qué frecuencia lanzan lanzamientos, de acuerdo con las reglas que fijan los tickets, cómo informan, dónde están los documentos y cómo se actualizan; todo se decidió de alguna manera. Y esto es maravilloso, cuando son pocos y están todos en un solo lugar. Pero cuando su nuevo equipo se sienta en una nueva ubicación, todos los demás en otras ciudades e incluso países, y nuevas personas cada día más y más ... No me sentía a gusto.

Como resultado, recordé un pensamiento simple, ya que tengo una educación técnica:

El sistema cambia desde cualquier parte del sistema.

Y decidió que probablemente sería ese punto que llevaría al sistema de un estado de caos a un estado de estructura clara.

Para los programadores y no solo para aquellos que creen que describir los procesos de gestión es una pérdida de tiempo: al igual que el código debe cubrirse con documentación técnica y de usuario, el trabajo de la empresa debe describirse mediante instrucciones y procesos. Por las mismas razones: cuantas más reglas y más confusas sean, más difícil es mencionarlas.

Especialmente deben describirse si el número de recién llegados crece constantemente y los procesos tienden a cambiar constantemente. Para qué sirve más tarde:

• Recuerde a las personas cómo funciona el proceso (por ejemplo, cuando no se ejecuta)
• Poner uno nuevo en el proceso
• Realice cambios en el proceso sin perderse nada
• Piense en lo que estamos haciendo mal y optimice el proceso.

Nunca pensé que lo escribiría, parece que es claro y verdadero. Pero no, resulta que las startups técnicas generalmente pierden la complejidad de los procesos de gestión y prefieren pensar que todo debería salir por sí solo.

Que escribir

En resumen y más simple, luego instrucciones y acuerdos con todas las partes sobre cómo se organiza el trabajo con incidentes, problemas, liberaciones, conocimiento, capacidades, seguridad, etc. en nuestra organización.

Si hay más, abra el Talmud de ITSM y lea :)
Este artículo no trata completamente sobre qué describir, sino más bien cómo describirlo e implementarlo para que los procesos vivan.

Como escribir

La tarea de describir para que la gente lo use no es muy trivial, especialmente en condiciones en que los cambios no provienen de arriba, del liderazgo. Se vuelve aún más complejo con pura resistencia.

Encontré una fuente de resistencia, largas instrucciones sobre 10-30 páginas, escritas hace aproximadamente 5 años, sobre las que todos olvidaron un año después. Es decir, los intentos de estructuración no funcionaron y hubo confianza en que no funcionaría.

Al leer estos documentos (bastante, por cierto, sensatos, pero largos, demasiado sofisticados), me hice mella.

Lección 1: Describe los arreglos cortos y animados.

Lo que no puede explicar en términos simples es un problema complejo, no el que lo lee. Quizás esté intentando unir varios procesos en uno.

Lección 2 Si no puede usar el cuadro, no lo use. Nunca use un diagrama complejo.

Desde el exterior, parece que lo contrario es que leer un muelle es más difícil que mirar un gráfico. Yo también lo pensé. Sin embargo, ahora tengo dos documentos que describen cómo publicaremos características, texto y diagrama. El gráfico no se actualiza (ya sea difícil o una vez), el texto es constante (no soy solo yo quien ha estado haciendo esto durante mucho tiempo).

Lección 3: Dos documentos cortos son mejores que uno largo.

Ya nadie lee textos largos, solo tienes que aguantar esto.

Lección 4: Si usted mismo no puede escribir, no escriba.

Es más fácil para las personas usar lo que se les ocurre y estructurarse a sí mismas. Convencer a alguien de la importancia de crear un acuerdo es más correcto que escribir usted mismo. Aunque, por supuesto, no es más fácil.

Lección 5: Si todavía te escribes, pide verificar

Muy a menudo, surge un documento después de la pregunta "¿Cómo se hace esto con nosotros?" Bueno, si envió un documento para verificación a alguien que recibió la información, con las palabras "por favor verifique, ¿es así?"

Lección 6: además de las entradas, salidas y artistas y los responsables, cada documento debe tener un público objetivo

Como en marketing: para que un artículo sea leído, debe ser de su interés personal. Si inserta información para todos en un solo documento, será largo, y recordamos que los textos largos asustan a la gente moderna. Por ejemplo, hay una regla general para todos sobre cómo trabajamos de acuerdo con el GDPR. En la práctica, estos son tres documentos:

• para todos los empleados: una descripción de la propia regla, qué se puede hacer y qué no se puede hacer con la información.
• Dónde y cómo contactar en una situación excepcional: para desarrolladores y servicios de soporte
• Cómo y dónde se ejecuta la descripción técnica: para desarrolladores

¿Qué hacer para que no solo se describa, sino que también funcione?

Declare que usted y su equipo se gestionan tal como están escritos.

Si algo sale mal, abro los documentos, les doy un dedo y digo que acordamos hacerlo. ¿Qué necesita ser arreglado? Si alguien del manual, por ejemplo, no está satisfecho con los plazos para trabajar en el ticket, abro el proceso donde dice

• ¿Cómo llevamos las entradas al trabajo?
• por qué etapas pueden pasar
• ¿Cuál es la razón para dejar de trabajar en el boleto y
• ¿Cuál es el tiempo promedio en cada una de las etapas?

y hacer una pregunta, ¿vamos a cambiar el proceso, las prioridades de los tickets u otra cosa?
Esto mitiga la insatisfacción, facilita la comunicación y, lo más importante, aumenta su previsibilidad y la transparencia de su trabajo. Y donde hay transparencia, hay confianza. Y en confianza, puedes construir mucho más.

Además, le brinda la capacidad de defender a su equipo si la falla no es pública, sino confusa en la administración (el 80% de los casos, de hecho).

Mostrar a la gente cómo funciona

Parte del proceso de administración de lanzamientos surgió de tres conversaciones con los administradores de lanzamientos ... En base a esto, le expliqué a la administración por qué el lanzamiento estaba tardando tanto, y el administrador de lanzamientos solicitó esta discusión. Ahora en este lugar hay varios documentos sobre cómo, por qué y qué debería publicarse aquí. Escrito, por supuesto, no por mí, sino por los gerentes de lanzamiento. Acostumbre a las personas al hecho de que es conveniente, lo que lo libera de explicaciones innecesarias y permite ser transparente de una vez y para todos. Por ejemplo

Conviértete en una fuente de conocimiento.

No olvido de vez en cuando dar una pequeña conferencia de que los acuerdos escritos sobre el formato del trabajo son mucho mejores que los no escritos. Estoy interesado en hablar sobre esto, así que todos tienen que escuchar muchas veces. No es la primera vez, gradualmente, la mayoría de los acuerdos que hemos arrastrado a la confluencia. El agua afila una piedra.

Porque lo necesitas

Como mínimo, el caos en la cabeza y en el lugar de trabajo será menor.

Como máximo, tiene suerte y se le notará en esta organización como un administrador inteligente que sabe cómo trabajar con los procesos. :)

Pensamientos sobre, bastante controvertido, solo especulan.

Tengo una creencia bastante seria de que alguien no puede escribir e implementar procesos desde el exterior. Él puede describir el estado actual, pero nadie apoyará el proceso. Y si necesita cambios rápidos, sucederán, y el proceso esperará hasta que su creador haga los cambios.

Los procesos de gestión son el negocio de aquellas personas que los usan.

Y, sin embargo, debe suceder que el enfoque basado en procesos no sea una regla impuesta externamente, sino mi acuerdo con el mundo exterior sobre las reglas para trabajar conmigo. Entonces, el enfoque del proceso no será un freno para el desarrollo de la organización (lo he visto antes), sino un catalizador de crecimiento.