Flowcon, o botella: técnica de gestión, incluidas las tareas. Stream, proyecto, desarrollo, funciones de rutina, regular, etc.
Muchas personas, después de haber aprendido sobre la metodología y las soluciones basadas en ella, hacen preguntas: qué, cómo, cuál es la esencia, sobre la base de las "prácticas mundiales", qué métricas se utilizan, a quién conviene, de dónde vino. Respondí cada una individualmente, pero decidí: todo, detente, cansado de escribir lo mismo cien veces. Soy programador, o quien? La reutilización puede ser no solo para el código, sino también para información. Escribiré una vez, intentaré responder todas las preguntas del artículo, y pase lo que pase.
Lo mejor de todo, me parece, presentar en forma de historia, porque el nacimiento de una botella está estrechamente relacionado con mi carrera, por así decirlo. Lo haré Perseguido.
PMBOK
La primera técnica de gestión de proyectos y tareas que conocía se llamaba PMBOK. Era el año lejano 2006.
En aquellos días, PMBOK era casi un monopolio en la gestión de proyectos. En currículums y vacantes, solo se escuchó ese PMBOK. No había metodologías flexibles en el aire entonces, aunque ya existían en alguna parte.
PMBOK era entonces un método de gestión de proyectos puramente en cascada, es decir asumió una estructura rígida de etapas y tareas, plazos y dependencias de principio a comienzo. En consecuencia, se fragmentó rápida y bellamente en fragmentos en los proyectos de implementación de 1C de esa época, debido a la violación constante de la famosa (entonces) regla del triángulo Presupuesto - Tiempo - Contenido.
En aquellos días, ni los clientes ni los implementadores podían hacer especificaciones técnicas razonables, escribir requisitos funcionales, simular el trabajo de la empresa. Sí, y las configuraciones, como SCP, constantemente arrojaban sorpresas: se desarrollaron. Como resultado, la lista compilada de trabajos se volvió irrelevante en algún lugar un día después del inicio del proyecto.
Pero los cerebros de los programadores son curiosos, y se les ocurrió una cierta combinación de PMBOK y el entonces desconocido Agile. Lo llamamos el borde amarillo. Y yo también me vi obligado a convertirme en su apologista.
Borde amarillo
El borde amarillo se basó en las etapas creadas por PMBOK, solo reemplazando radicalmente el objetivo de cada uno de ellos. ¿Cuál es el propósito de PMBOK? Completa todas las tareas del escenario.
El borde amarillo se le ocurrió otro objetivo:
firmar el acto . Por ejemplo, hay una etapa: "Implementación de la contabilidad de almacén". En la etapa de diseño y redacción de conocimientos tradicionales, aparecen ciertos trabajos, como "Informe de material", "Capacitación del usuario", "Configuración de derechos de acceso", etc. - Dependiendo de la profundidad de estudio en la etapa de examen expreso.
Esta lista de trabajos sirvió como un kit de inicio para comenzar con algo. Un programador llega al jefe del almacén, o los dueños de las tiendas, o los contadores de materiales, comienzan a hablar con ellos, y resulta ... Bueno, hay tanto que aprender que los cuadernos terminaron con una fuerza terrible.
Al principio, los cerebros mimados por PMBOK dijeron: ¡no! ¡Es imposible! ¡Solo es necesario hacer lo que está escrito en el TK! Y los gerentes de proyecto entablaron largas negociaciones negativas con el cliente. Alguien logró convencer al cliente de un trabajo adicional, una tarea técnica adicional, etc. La mayoría no lo hace. El cliente dijo: maldición, muchachos, no sé qué es TK y qué mejoras hay que hacer en su programa para que todo funcione para mí, pero si no funciona,
no firmaré la ley .
La realidad, en general, ganó, y el proyecto vivió en dos dimensiones: plan y realidad. Parece que el plan se puede descartar, pero hay un inconveniente: se ha elaborado un presupuesto de acuerdo con él, que está protegido por el gerente del proyecto por parte del cliente, y no puede tocarlo. Pero el hecho permaneció: es necesario hacer un mínimo del máximo de lo que el cliente desea firmar, de lo contrario no habrá pago o, en consecuencia, salario.
Así que en mi cabeza había un modelo de Edge, aunque amarillo. La botella comenzó a formarse y contenía dos prácticas de gestión de tareas. Parece que se contradicen entre sí, pero se llevaban bien en la vida.
CORE PM
Por lo tanto, al montón lo mencionaré. Al ver los problemas con la gestión de proyectos entre mis colegas y yo, comencé a elegir la teoría fuera de PMBOK, y encontré un libro en la tienda con el título sencillo "Gestión de proyectos", escrito por las cuatro Tates. Llamaron a su método CORE PM.
La esencia es casi la misma que en PMBOK. La invarianza del plan se llama la principal. Se inventó un procedimiento directamente separado, grande, complejo y burocrático, cómo hacer cambios al plan.
Para entonces, habiendo reconocido el borde amarillo, no pude agregar nada de este libro a mi botella. Y esto es muy bueno, porque nuevamente me di cuenta de que no hay Smart Uncles en el mundo.
Tios inteligentes
Sobre el hecho de que no hay tíos inteligentes en el mundo, lo entendí hace mucho tiempo, en el instituto, cuando comencé a practicar. Luego me gustaban los métodos estadísticos de gestión de la calidad del producto, y fui a la fábrica, donde pasé un mes reuniendo datos para el diploma.
Al principio, el objetivo era precisamente la recopilación de datos que el profesor y yo queríamos convertir en software especializado (Statistica?). Parece que la idea era construir un modelo matemático de producción de transportadores para comprender la influencia de las diferentes etapas en la calidad del producto final.
El profesor, antes del viaje, me entregó algunos libros sobre mapas de Shekhart, control estadístico de procesos (SPC), gestión de calidad general (TQM). Aparentemente, él mismo no los leyó, de lo contrario no se ofrecería a construir una estera. modelo de producción Eran adecuados, por ejemplo, para sensores de presión, donde la construcción de modelos y el análisis de regresión de Draper eran la base de la calibración, pero no para la industria automotriz.
Y leo libros. Todo era tan simple allí que era impresionante. Y la fábrica también tenía Smart Uncles en el servicio de gestión de calidad. Conocían los conceptos básicos de estos libros, pero, para mi gran sorpresa, nunca utilizaron no solo métodos para mejorar la calidad, sino incluso las fórmulas más simples para evaluar el estado actual del proceso técnico.
Y las fórmulas eran mega simples. Toma cien detalles, mide, ingresa los números en Excel, calcula el promedio, la desviación estándar (el mismo sigma) y muestra un indicador simple y comprensible: el índice de idoneidad o el índice de reproducibilidad (si el proceso es estable). En realidad, este indicador dice claramente si todo es normal con el proceso o no.
Cuando calculé esta cifra, estaban en estado de shock. Y por el hecho de que finalmente vieron esta cifra, y por lo terrible que resultó ser. Pidieron contar algunas piezas y máquinas más, pero ¿qué hay de mí?
Luego hubo muchas cosas interesantes, incluido un simple esfuerzo, durante mi presencia, para mejorar radicalmente la calidad de la producción. Pero ese no es el punto.
Entonces se me ocurrió una idea clave: los
tíos inteligentes saben mucho, pero no hacen nada .
Los métodos están completos, tanto en la gestión de calidad como en la gestión de tareas / proyectos y en la gestión general. Pregúntele a cualquier gerente efectivo: él le dará una conferencia sobre cómo y qué hacer de acuerdo con tal y tal técnica. Y pregunte brevemente: ¿hace lo que está escrito en la metodología? Higos allí.
La botella se enriqueció con conocimientos muy útiles. Todo debe hacerse y verificarse uno mismo, no se puede confiar en nadie, especialmente aquellos que no pueden mostrar sus resultados en la práctica.
Modelo de gestión ruso
Al darme cuenta de que tenía que comprender todo por mí mismo, decidí leer algo más. No quería aprender una nueva técnica ya hecha, sino entender algo más fundamental. El libro "Modelo de gestión ruso" de Alexander Prokhorov me llamó la atención.
Decir que el libro es brillante es no decir nada. Debes leerlo si trabajas en Rusia. Afortunadamente, no hay recetas preparadas allí, pero todas las razones fundamentales por las que tenemos todo están pintadas con elegancia.
No pintaré durante mucho tiempo, solo mencionaré algunos pensamientos clave que son importantes en el contexto de este material.
La primera es que el trabajo del pueblo ruso debe medirse para que no se tuerza. Porque estamos tan acostumbrados a engañar a cualquier sistema que lo hacemos inconscientemente. No aceptamos reglas, restricciones y leyes. Más precisamente, asentimos con la cabeza, estamos de acuerdo, y nosotros mismos ya pensamos cómo engañar.
El segundo: los rusos trabajan mejor en el llamado células en racimo, es decir equipos pequeños no controlados muy estrechamente. El espacio abierto no es para nosotros. Como comprenderá, el mismo principio se establece en un scrum.
Tercero, los rusos no hacen nada como se les dice. Esta es una idea clave al implementar cualquier metodología. Da instrucciones sobre cómo actuar, liberar a las personas y esperar el resultado, pero no es así. Porque las personas tiran tus instrucciones y hacen lo que solían hacer.
La botella después de este libro está increíblemente enriquecida. Es cierto que los métodos para resolver estos problemas "rusos" tenían que buscarse por sí mismos. Encontré control.
Controlando
El control es un control basado en números. Una de mis tecnicas favoritas. Destaco lo principal: controlar no es controlar. Esto es gestión.
Si no hay números, el control se realiza a ciegas, en base a información indirecta. Cuando trabajas con tareas, esto es especialmente cierto, porque un sistema para medir tareas generalmente no tiene valor. Por lo general, estos son los costos de mano de obra en horas, la fecha límite (y entrar en ella) y, de hecho, partes de las tareas resueltas. Es imposible administrar de manera efectiva en función de estos datos.
La parte del control que formula los requisitos de información, es decir a números, métodos para obtenerlos, reproducibilidad, calidad, profundidad de estudio, etc.
La cifra debe ser de alta calidad, pero rara vez se ven tales. Ya he escrito varios artículos sobre esto, no me repetiré. Solo confíe en mi palabra: no encontrará cifras de muy alta calidad controlando los criterios muy a menudo. Probablemente porque nadie ha leído el artículo de Controlling en Wikipedia.
Entonces, el control apareció en la botella. Es universal, y en adelante controla la formación de cualquier número que requiera cualquier técnica.
Gestión de límites
La gestión de límites, o gestión de fronteras, es una ciencia poco conocida sobre la transformación de los sistemas empresariales. Aunque, tal vez, algo ya ha cambiado ahora: lo estudié hace varios años, según los artículos sobre los trabajos de Eric Trist y alguien más, no recuerdo el apellido. Ahora, Internet dice que hay algún tipo de libro en inglés sobre este tema: no puedo decir nada, no lo he leído.
La conclusión es increíblemente simple:
límites . Dentro de los sistemas de negocios, procesos, incluso en una sola persona, muchos límites. Física, emocional, energética, etc.
Las fronteras son malas y buenas, útiles y dañinas. Algunos interfieren con el curso normal del proceso, otros dividen el flujo mixto en dos partes, lo que ayuda a procesarlo más rápido. Algunos aíslan a una persona de la información necesaria, lo que dificulta la reacción a tiempo, mientras que otros la protegen de información innecesaria, lo que le permite no distraerse.
En resumen, las fronteras y su gestión son mega-cool. Para entender esto, debes intentarlo. Para personas inteligentes como usted, es suficiente comprender el principio clave para comenzar a aplicarlo. El resto necesita estudios de casos y prácticas específicas, y en realidad hay muchos de ellos. Solo que no están en Internet, pero tenemos que inventarlo nosotros mismos.
Se me ocurrieron algunos, de publicado -
Iceberg y el
método de nadar carriles .
La gestión de límites tuvo una influencia muy fuerte en la botella, y en casi todas sus partes: en la gestión del ciclo de vida de la tarea, en la organización de prioridades, en la gestión regular.
Hágalo usted mismo el infierno
Llamó a esta sección lo mismo que la
publicación del mismo nombre. Esta fue la primera experiencia en la construcción de un sistema para gestionar pedidos, notas, planes y proyectos basados en el conocimiento acumulado.
La experiencia es bastante exitosa, aunque el artículo suena más negativo. Al construir el sistema, se utilizaron principalmente los principios de control, gestión de límites e Iceberg (de la programación empresarial). Por supuesto, resultó ser demasiado tecnocrático, pero la experiencia, en su utilidad, fue enorme.
En primer lugar, era un sistema para toda la empresa, y no para un pequeño equipo de programadores. En segundo lugar, el sistema logró su objetivo: aumentó la disciplina ejecutiva a alturas sin precedentes.
Pero lo principal para mí es el uso práctico de partes de la botella a gran escala, y no en programadores, sino en personas comunes. Algo, según los resultados, tuvo que ser descartado de la metodología, pero algunos métodos demostraron ser efectivos. En su mayor parte, por supuesto, controlando.
Pensamiento sistémico
Esto no es para mí, sino sobre un campo de conocimiento llamado pensamiento sistémico. Está lleno de libros y casos, por lo que no volveré a contar. Observo solo un principio muy importante, que influyó mucho en la botella: las propiedades emergentes o emergentes. Estas son las propiedades del sistema que solo se pueden ver en el estado activado.
Mientras está sentado lejos del sistema y fantasea sobre cómo funciona, no ve las propiedades emergentes. Puede diseñar, dibujar, programar, probar, incluso en público, pero cuando inicia el sistema en un trabajo real, las propiedades emergentes comenzarán a funcionar.
Usted, por ejemplo, asumió que una persona plantea una tarea y la otra se compromete a llevarla a cabo. Bien bien La segunda persona simplemente no puede ver la tarea. Y si ve, no leerá. Y si lee, dirá que no leyó. O no lo entiendo. ¿O no es su trabajo? Etc.
O pensaste que en el equipo el coordinador es el jefe. Le proporcionaron un AWP, con una lista de tareas entrantes que distribuiría a los artistas. Inicie el sistema y verá que él no distribuye una maldita cosa, sino que solo corre alrededor de reuniones y fiestas corporativas. Y las tareas son distribuidas por un tipo tranquilo y de aspecto indescriptible sentado en la esquina: un líder oculto. Y él, ofendido por el hecho de que no se le notó, también comenzará a sabotear la implementación de su sistema.
Estas son propiedades emergentes. No son visibles durante el diseño especulativo; aparecen cuando el sistema comienza a funcionar.
Está claro que las "propiedades emergentes" son una abstracción tal que a alguien se le ocurrió nombrar un fenómeno que sea comprensible para todos: es necesario iniciar el sistema y surgirá algo más, desde errores de diseño de arquitectura hasta errores triviales.
Pero en el caso de la gestión de tareas, siempre tratamos con un sistema complejo que consiste en automatización, gestión, personas con sus relaciones y objetivos del equipo, clientes, gerentes, etc. El éxito de la gestión de tareas depende de todos los componentes, aunque en distintos grados, y ninguno de ellos puede ignorarse.
Y si, por ejemplo, usted es un programador que automatiza la gestión de tareas, no solo puede ignorar mucho. Es más fácil Por lo tanto, el sistema puede y no funcionará. No habrá errores, pero tampoco sentido.
Y quería que funcionara. Por lo tanto, agregué pensamiento sistémico a la botella, tanto como uno de los principios fundamentales, como acentos y prácticas específicos.
Códice Samurai y Libro de los Cinco Anillos
Suena extraño, pero fueron estos libros los que hicieron de la botella una botella. Explicaré brevemente ahora.
Un samurai decente en la vida hizo esto. Al principio fui a estudiar artes marciales con algún maestro. Estudió hasta que lo superó. Y aquí tenemos un samurai decente que posee la técnica de cierta escuela (por analogía - PMBOK).
Dejó la escuela y se fue al antiguo Japón, en busca de un nuevo desafío. Fui a diferentes escuelas, llamé al maestro local para un duelo y tomé decisiones basadas en los resultados. Si el maestro era más débil que el samurai, bueno, no el destino. Si el samurai pierde, entonces cae de rodillas y le pide que lo lleve como estudiante. Y estudió hasta que nuevamente sobresalió al maestro.
Esto sucedió varias veces. Y en cierto momento, el samurai tenía su propio estilo.
En general, no nació para todos, esto es normal. Algunos permanecieron "sin rostro", siendo solo maestros de varias escuelas conocidas (este tipo de MBA).
Y a algunos se les ocurrió su propio estilo incluso antes de ingresar a la primera escuela. Por ejemplo, uno de los héroes nacionales de Japón, Miyamoto Musashi, el inventor del estilo de dos espadas y el autor del Libro de los Cinco Anillos. O Masutatsu Oyama, un ciudadano coreano, el creador de la escuela de karate Kyokushinkai. Tanto el uno como el otro inventaron su método en algún lugar al comienzo de una carrera, y luego lo perfeccionaron. Tanto eso como otro en el camino se encontraron con maestros más poderosos y se quedaron para aprender de ellos.
Pero ni uno ni otro dejaron su equipo para reemplazarlo con un extraño que parecía más fuerte en un momento particular. Simplemente enriquecieron su técnica.
Y, bueno, al final, un samurai decente, que derrotó a todos en el mundo, abrió su propia escuela. Y otro samurai vino a él, alguien ganó y se fue, alguien perdió y se quedó. Y así sucesivamente hasta el infinito. Entonces, Masutatsu Oyama, al no encontrar oponentes entre las personas, comenzó, por alguna razón, a matar a los toros.
Entonces, después de leer este libro, entendí por primera vez lo que estaba haciendo. Yo, como un samurai decente, comencé con la escuela que estaba a poca distancia, con PMBOK. Luego comenzó a agregar otras escuelas. Es cierto que a menudo cometí un error indecente por un samurai decente: no combiné la práctica, sino que la reemplacé por otra en busca de una bala de plata. PMBOK no encaja - lo tiramos, tomamos CORE PM, no funciona - lo tiramos de nuevo, nos tiramos al scrum, y así sucesivamente. Por lo tanto, cambié mis tácticas: comencé a aplicar nuevas prácticas como experimento, ver qué pasa y dejar las soluciones más exitosas en la botella.
Programación de negocios
La programación empresarial es un conjunto de métodos y prácticas simples para mejorar un negocio. Al menos el todo, al menos una cierta parte.
Dio la casualidad de que la programación empresarial se desarrolló en paralelo con la botella, y el objeto de mejora fue todo, excepto el departamento de TI nativo.
Pero, en cierto momento, la comprensión llegó de repente. Bueno, no estoy del todo bien. Sé cómo mejorar cualquier proceso, y atormento mi proceso nativo con algunos métodos extraños.
En general, apliqué la programación empresarial, y por primera vez en mi vida recibí un aumento apreciable en la eficiencia de los programadores, e inmediatamente, dos veces. Los cambios se referían al proceso, la motivación, el objetivo, el sistema de gestión y la automatización. En general, los cinco componentes con los que trabaja la programación empresarial. Construimos nuestro trabajo nosotros mismos.
El resultado me impresionó a mí, a los programadores, a la gerencia y a los especialistas en sistemas de motivación.
Pero yo, no siendo un samurai decente, arrojé todos los resultados a la basura, porque en la venta compré un libro sobre scrum.Scrum
Hay dos scramas en este mundo: correcto e incorrecto. El correcto se describe en un libro de Jeff Sutherland. Incorrecto - en lo que se llama scrum guía, y los autores todavía enumeran el mismo Jeff Sutherland.El scrum correcto dice: es posible y necesario acelerar el trabajo 4 veces. El incorrecto no dice nada, solo te da algunas reglas.Un scrum correcto honestamente proporciona referencias a los métodos de gestión de calidad japoneses, llamándolos uno de los fundamentos de la filosofía scrum. En particular, recomienda usar las reglas de un samurai decente: tome el scrum como base y cree su propia técnica. El scram equivocado dice: haz lo que hemos escrito aquí. Y si lo haces de manera diferente, entonces esto no es un scrum.En general, tomé el libro e hice todo como está escrito. Tablero, pegatinas, mítines, retrospectivas, etc. El resultado cumplió con todas las expectativas: duplicamos la velocidad, es decir, comenzamos a producir el doble de resultados por unidad de tiempo.Sin embargo, el scrum en su forma pura tuvo que desecharse por una simple razón: el equipo de programadores se dispersó a diferentes oficinas y se perdió la oportunidad de usar un tablero. Sufrieron durante algún tiempo usando dos tableros, pero también hay manifestaciones, retrospectivas que requieren participación personal. Por lo tanto, el scrum fue abandonado.Pero lo mejor quedó en la botella. ¿Qué es lo mejor en scrum? Así es, el sistema de medición de tareas es la planificación del póker. No hay nada más decente para evaluar las tareas de los programadores en nuestro mundo.El sistema de reloj utilizado anteriormente es mucho peor, ya que constantemente surge la inflación o la deflación de las estimaciones. Los puntos son mucho más estables.De los elementos de scrum restantes en la botella, tal vez, solo quedaba un sprint, como una de las opciones de planificación. Quien haya trabajado con 1C sabe que el sprint es la planificación de calendario espacial más común, es decir. cierta cantidad de productos que necesitan ser vendidos / comprados / producidos por un período determinado.Entonces, gracias, scrum, por todo lo que nos enseñaste, pero cavaste tu propia tumba con tu guía scrum. Tomamos solo lo mejor.Stream scrum
Entonces tuve tanta experiencia como la implementación de la estrategia de una empresa. La experiencia es única para un programador: podemos decir que tuve mucha suerte. Era necesario cambiar el trabajo de la mayoría de los departamentos de la empresa y, como saben, una variedad de métodos.Una de las unidades problemáticas fue el suministro. Todavía no entiendo por qué es tan difícil: la función es simple. Entonces todavía estaba interesado en scrum, y decidí usarlo para compras.Pero inmediatamente se encontró con contradicciones metodológicas. Los programadores son una cosa: cada tarea es única allí, y es bastante digna de ser escrita en una pegatina y suspendida en una pizarra. ¿Y cuáles son las tareas para los proveedores? ¿Comprar cien bujes? Y mañana, ¿de nuevo para comprar cien bujes? ¿Y pasado mañana?En resumen, las pegatinas no son eso. Y el diagrama de combustión no es eso. Scrum está diseñado para la implementación de proyectos, ¿y qué es un proyecto? Este es algún tipo de actividad que algún día terminará. Debe terminar, en este sentido, este es el objetivo.Y aquí, las compras. ¿Pueden las compras terminar alguna vez? Bueno, solo con la empresa. Entonces, ¿cuáles son las compras? No es un proyecto, sino un proceso. Pero el proceso es una palabra regular, porque también da una cierta integridad, y hay un principio y un final. Y entre ellos: un descanso para fumar, Internet y comunicación en la cocina.El Sr. Presidente dio una respuesta cuando habló sobre su trabajo como primer ministro en 2008-2012. Él dijo: ser el primer ministro: cómo estar bajo una cascada de tareas, problemas y objetivos interminables. El trabajo nunca termina. Cuantos no lo intenten, siempre habrá algo que hacer.¿Qué es una cascada? Esta es una corriente. Entonces apareció la idea de los flujos. Gracias Vladimir Vladimirovich.Como era muy aficionado al scrum en ese momento, no quería dejar caer este nombre, y llamé a la metodología de la cadena de suministro primero "scrum alemán" (porque estaba muy involucrado en el control, que los alemanes aman más que cualquier otra cosa), luego - "Kazajo Scrum" (así, para la risa), y, finalmente, "streaming de Scrum".El punto es simple.
Las tareas para el proveedor siempre provienen del exterior, de las necesidades de ventas y producción. El sistema de prioridad para estas tareas es muy simple. Y la esencia del trabajo es aún más simple: desde la cerca hasta el almuerzo.Hay una necesidad de bujes - pedir bujes. Necesitamos tornillos, bueno, ya sabes qué hacer. Y así sucesivamente, hasta el infinito. Porque el flujo.Y el control, que se ha quedado largo y firmemente atrapado en la botella, proporcionó las métricas correctas y los indicadores individuales. Rápidamente se hizo evidente que los proveedores viejos y experimentados, por desgracia, trabajan mucho peor que las "chicas" que simplemente toman y hacen, y no hablan de "cómo solía ser".El resultado fue asombroso en calidad y velocidad de logro: en un mes llenaron el depósito de consignación a un nivel que antes era inalcanzable durante los años de gestión "ordinaria".Bueno, aquí, en algún momento, me di cuenta de que no hay proyectos de automatización interna, pero sí hay una corriente. El desglose de la automatización interna en proyectos es una convención que ha llegado como un legado del gran amor de 1Snikov por PMBOK. Se necesitan proyectos donde haya dinero, plazos, presupuestos, formalidades y burocracia. Si todo esto está en la automatización interna, entonces obviamente hay que hacer algo.En general, las corrientes y su gestión entraron firmemente en la botella. Mirando hacia el futuro, diré que el nombre Flowcon se deriva de la frase control de flujos.Teoría de las restricciones del sistema (TCC)
La teoría de Goldratt de las restricciones del sistema es un principio que dice que en cualquier sistema hay una restricción, el enlace más lento, cuya velocidad determina la velocidad general del sistema. Bueno, Goldratt y sus seguidores han desarrollado un montón de métodos basados en este principio. Por ejemplo, la técnica Velocity descrita en el libro "The New Goal" involucra TOC y Lean.Por supuesto, el principio principal pasó de la TCC a la botella: comprender la existencia de restricciones y los medios para trabajar con ella. No estoy escribiendo conscientemente "eliminando restricciones", porque La TCC implica no solo la eliminación, sino también la protección de las restricciones y, a veces, su creación artificial.Fue el TOC lo que me hizo ver no solo la fase de la tarea, sino también el "kit": lo que sucede antes y después del trabajo del ejecutor directo. No es ningún secreto que a menudo lleva 15 minutos completar una tarea, y lleva unos días aceptar, coordinar y aceptar el resultado. Y todos estos pocos días, el cliente, o el iniciador de la tarea, está esperando.Estas etapas burocráticas, dentro del ciclo de vida de la tarea, pueden analizarse desde diferentes ángulos. TOC dirá que estas son limitaciones porque aprovechan al máximo la velocidad de generación de las unidades del objetivo. La misma gestión de límites dirá que el problema es la presencia de límites adicionales, en este caso, entre las personas involucradas en la coordinación. Se pasa mucho tiempo superando estos límites.Los puntos de vista son diferentes, pero el resultado es uno: la tarea se resuelve prohibitivamente por mucho tiempo. Y la alineación es solo un ejemplo. ¿Y qué pasa con la elección de la tarea de un programador cuando el "boletín informativo" es prohibitivamente largo? ¿No es esto una limitación? ¿Y qué pasa con la elección incorrecta de un ejecutor, cuando las tareas del mismo tipo siempre llegan al mismo ejecutor, y se construye una línea súper larga frente a él?Los métodos específicos de TOC también se han introducido en la botella, por ejemplo, utilizando un búfer para determinar cuándo una tarea debe comenzar a funcionar si tiene una fecha límite. Pero lo principal en la TCC, por supuesto, es el principio, no los métodos. El propio Goldratt escribió sobre esto en el artículo "De pie sobre los hombros de gigantes".De pie sobre los hombros de gigantes
Este es un artículo tan famoso de Goldratt, en el que pone todo en su lugar, incluso, con sus palabras de Goldratt, dice quiénes son esos samurais decentes. No volveré a contar el artículo, está disponible públicamente en Internet.Solo daré una cita clave.“Hay una diferencia entre las soluciones aplicadas (aplicaciones) y los conceptos fundamentales en los que se basan estas soluciones. Los conceptos son generales, las soluciones aplicadas son la adaptación de conceptos a un entorno específico. Como ya hemos visto, tal adaptación no es simple y hace que sea necesario desarrollar ciertos elementos de la solución. Debemos recordar: la solución aplicada se basa en las premisas iniciales (a veces ocultas) sobre un entorno específico. No debe esperar que esta solución de aplicación funcione en un entorno para el cual las premisas originales no son ciertas. "Podemos ahorrar mucho esfuerzo y evitar decepciones si formulamos cuidadosamente estas premisas iniciales".Si en sus propias palabras, Goldratt dice lo mismo que el samurai y el pensamiento sistémico: no hay necesidad de fantasear, no hay que gritar "scrum para siempre" o "TOS - mierda" porque siempre estarás equivocado. Tómelo y pruébelo, y no olvide que ningún método puro le conviene. De todos modos, hay que observar, pensar y adaptarse.Observaciones
Al presentar la botella en diferentes equipos, vi mucho. Resultó que esto no solo es simple e interesante, sino también útil. Así que la botella se enriqueció con un montón de métodos, prácticas y trucos de la vida de mi propia invención. Honestamente entiendo que no he inventado nada nuevo, y de seguro algunos métodos describen tales métodos, pero no hay suficiente vida para leer todos los libros.Por ejemplo, se ha escrito mucho sobre la destructividad de elegir una tarea. Y si se selecciona la tarea, pero es necesario decidir cómo implementarla, entonces el programador, por ejemplo, puede pasar mucho tiempo hasta que sea el momento adecuado, y no tomará la primera opción disponible.Como Maxim Dorofeev, el autor de las técnicas Jedi, escribió en una imagen divertida, ¿cuál es el punto de esperar a que la fecha límite se haga a través de * opu, si puede hacerlo inmediatamente a través de * opu, pero habrá tiempo para arreglar todo?He visto repetidamente, tanto en mí como en los demás, que la elección de una solución a un problema puede llevar días. Además, las opciones pueden ser completamente idénticas en rendimiento, optimización y conveniencia para el usuario. Pero algo no toma ninguna decisión, y eso es todo. Trabaja durante 15 minutos y reflexiona como si estuvieras construyendo un cohete.Hay muchos ejemplos de este tipo, y todos ellos influyeron en la botella. Y siguen influyendo, porque Una vez que he entendido que mis propias observaciones no son peores que los libros, ya no puedo parar: no hay límite para la perfección.Automatización despiadada
Una vez, habiendo reunido todo mi conocimiento en un montón, hice una nueva versión del sistema de administración de tareas, comencé a aplicar todo el conocimiento de la botella y obtuve un resultado inesperado: la productividad del equipo de programadores aumentó 4 veces. Probablemente, solo los perezosos aún no han visto el video de mis informes sobre este tema, una y dos veces .En realidad, esta experiencia me llevó a distribuir la botella como una técnica. Comencé a sistematizar información y métodos, escribir artículos sobre la botella y sus métodos, y hablar sobre mi práctica.Arreglo para un nuevo sistema
Después de esa experiencia, me mudé a una compañía puramente de software y, por supuesto, continué la práctica de usar la botella. Pero me encontré con un desafío interesante: no tenía un sistema de gestión de tareas, en el que obtuve una aceleración 4 veces mayor.
Primero, me senté e hice un análogo simplificado, en 1-2 días. Cuando conoces la técnica, esto no es un problema, especialmente si no tienes que elegir tu comodidad, interfaz, etc.
Pero no tuve que trabajar con este sistema por mucho tiempo, porque nuestra empresa se comunicó con los clientes a través de GitHub. Si sabe, también hay algún tipo de gestión de tareas llamada Problemas.
El desafío se ha vuelto aún más interesante. Una cosa es crear el sistema usted mismo, desde cero, y otra muy distinta es adaptar el existente para que cumpla con los requisitos de la metodología. A pesar de que no puede cambiar nada, solo hay una interfaz estándar y API disponibles.
Entonces comencé con la API. No quiere decir que sea directamente chic, pero proporciona suficientes datos. El primer problema resultó ser la imposibilidad de indicar la evaluación del problema en forma de número. Tuve que salir a través de las etiquetas (etiquetas): son de tipo cadena, pero un script externo puede convertirlas en un número. Escribí este guión y lo usé durante varios meses; dibujó un gráfico de efectividad.
Pero hay problemas que no pude resolver en GitHub. Por ejemplo, priorización. Hay etiquetas, hay hitos, hay proyectos. Teóricamente, con su ayuda, es posible identificar qué tarea es más importante, pero usar esta información es extremadamente inconveniente: no puede ordenar por etiquetas. Tendría que hacer otro script que extraiga tareas a través de la API, clasifique y muestre la lista correcta.
En general, la rama resultó ser un callejón sin salida. Rebusqué en otros sistemas de gestión de tareas en línea: los problemas son similares. En todas partes existe la capacidad de ingresar y almacenar datos, pero muy pocas herramientas de configuración, es decir, la configuración convierte los datos en un sistema de control. En todas partes hay una API, y a través de ella puedes construir tu sistema, pero la pregunta es: ¿por qué su sistema? ¿Solo como fuente de datos?
Este dilema se quedó en mi cabeza durante varios meses. ¿Hacer o no? ¿Adaptar la técnica a GitHub haciendo tu propia mancha? O a otro sistema? En su forma pura, ninguno es adecuado, pero ninguno puede adaptarse, en un tiempo razonable. Sí, y use scripts externos que ya están hartos.
Pero, a pesar del dilema, la experiencia fue exitosa. La botella funcionó bastante bien por sí misma, aunque en un sistema bastante efímero, y aceleró el trabajo: al principio 4 veces, luego 6, llegó a 10. Está claro que el coeficiente depende del punto de referencia, pero dejé de preocuparme por esto durante mucho tiempo. La botella ya lo ha probado todo.
Transfiriendo a otro sistema nuevo
Entonces recordé que hay 1C en el mundo y un producto tan maravilloso como 1C: Workflow. Si alguien no lo sabe, este es un programa en el que puede configurar cualquier proceso. En consecuencia, no contiene ninguna metodología en sí misma, solo una técnica, y alguien debería decirle una técnica.
Aquí, simplemente, la gente iba a la próxima conferencia de 1Snu, y decidí participar allí. Tomé un estándar, vacío 1C: flujo de documentos, y comencé a configurar mi propia metodología en él: una botella. Honrar y alabar 1C: Administración de documentos: tomó varias horas configurarlo, y obtuvimos un sistema de administración de tareas bastante decente que corresponde en gran medida a la botella.
En la conferencia que habló, a la gente le gustó, a muchos les interesó la técnica. Es cierto que pocas personas usan 1C: gestión de documentos para la gestión de tareas; esto fue una sorpresa para mí. Toman algunos sistemas en línea en los que nada se puede configurar correctamente, y no hay una metodología inteligible en el interior, así como el concepto de eficiencia. Oh bien
El resultado sigue siendo positivo. Él, junto con el uso de tareas en GitHub, demostró que la botella puede integrarse completamente en otros sistemas. Entonces obtuvimos consultoría y varios proyectos para acelerar los equipos en sus propios sistemas.
Sistema propio
La consultoría es, por supuesto, divertida, pero larga y costosa. La mayoría de las personas no lamentan deshacerse de su antiguo sistema de gestión de tareas, que es de poca utilidad. Bueno, la gente quiere dos en uno, y la metodología, y el programa, en el que "todo está de acuerdo con la metodología".
Por lo tanto, nos sentamos a escribir nuestro programa de gestión de tareas, claramente afilado debajo de la botella. Hay pocas configuraciones, porque las configuraciones pueden expulsar la botella del programa, y este será el próximo sistema de administración de tareas, más como una computadora portátil.
Curiosamente, el desarrollo del programa inmediatamente comenzó a dar retroalimentación a la metodología. Algunas cosas tuvieron que ser arrojadas fuera de la botella, otras, agregadas, algo, cambiadas. Por supuesto, nosotros mismos nos mudamos rápidamente de GitHub a Flowcon.
Y fluye de nuevo
Nunca he dirigido una empresa antes. En realidad, todavía no puedo decir que estoy a cargo: hay dos de nosotros aquí y los derechos y responsabilidades se dividen aproximadamente a la mitad. Pero tenemos que ocuparnos de todos los problemas de la vida de la empresa, y no solo del desarrollo o implementación.
Tenemos el desarrollo de software y servicios, finalizando productos antiguos, presentando nuevos clientes, ventas netas sin servicios, apoyando a clientes antiguos, mercadotecnia, negociaciones, exhibiciones con seminarios, asuntos domésticos, como dinero, etc. En resumen, somos una empresa en miniatura.
Este estado de cosas nos hizo reconsiderar la botella e introducir dos nuevas entidades en ella: flujos y equilibrio.
Cada tipo de actividad que tengo que hacer es una secuencia. Por ejemplo, necesito programar nuevos productos, resolver problemas de clientes en implementaciones y escribir artículos. Soy una persona apasionada, como cualquier programador, por lo que no es tan difícil, pero soy muy reacio a cambiar entre estos hilos.
Me gustaría sentarme, por ejemplo, para desarrollar un nuevo producto y no salir durante una semana. Que va a pasar No habrá dinero, porque el diablo conoce el nuevo producto cuando comienza a venderse. Debemos cambiar a trabajar con clientes.
Si se deja llevar trabajando con clientes, también se producirá un colapso, porque crear un negocio con los mismos servicios es bastante arriesgado.
Bueno, participe en la redacción de artículos, generalmente solo escupe. Pero entonces no habrá productos, ni dinero. Por lo tanto, tienes que contenerte. Al principio lo hizo por presentimiento, a menudo se equivocaba, se dejaba llevar y recibía fracasos. Y luego me di cuenta de que estos son flujos, y todo cayó en su lugar.
Hay flujos que pueden medirse y planificarse. Por ejemplo, 100 horas al mes, por servicios, 300 puntos, por el desarrollo de nuevos productos, y entre 4 artículos. Cada flujo tiene su propia unidad y método de medición, y su propio objetivo. Y la botella debe equilibrar estos flujos, asegurando el desarrollo uniforme de la empresa.
Por supuesto, no hay tres flujos, sino más, tanto con nosotros como con usted. Y es necesario equilibrar todo para aquellos que desean un desarrollo sostenible, basado en una estrategia y no en el contexto actual y la lucha contra incendios.
Por lo tanto, la botella ha evolucionado de una técnica de gestión de tareas a una técnica de gestión de la empresa. Bueno, todavía no se ha dado la vuelta: este proceso todavía está en curso, pero los resultados son impresionantes.
Gestión del desarrollo
Anteriormente, no tenía que lidiar con el desarrollo de productos de software de uso masivo, en caja o servicios. Por lo tanto, la botella no contenía métodos específicos para este tipo de actividades.
Aparecieron brechas cuando tuvimos un problema: trabajamos mucho y rápidamente, y los productos no ingresan al mercado. Como dicen en bromas sobre scrum, queda por entender qué tipo de basura estamos haciendo a esa velocidad.
Tuve que ajustar la botella, introducir el concepto de lanzamientos y reconstruir el sistema de priorización basado en ellos. Después de todo, un lanzamiento no es un proyecto, ni una tarea, sino una especie de contenedor de otras tareas que deben realizarse para que el lanzamiento tenga lugar. Y el lanzamiento, especialmente el primero, es el acceso al mercado. Hasta que ocurra, nadie verá el producto y, en consecuencia, no habrá comentarios ni dinero.
¿Quién más se olvidó?
Siento que es hora de redondear. Si lees a este lugar, tienes mucho respeto. Todavía no he escrito mucho, pero lo principal, como, se reflejó en este material.
Todavía hay un montón de técnicas y prácticas que han afectado la botella, pero no las enumeraré. Tal vez algún día haré algo como un glosario o una lista de referencias, para aquellos que respetan firmemente todo tipo de enfoques científicos, índices de citas y "confiar en métodos de fama mundial".
Sí, queridos autores de los métodos de los cuales tomé algo útil para la botella, pero no lo mencioné en este artículo, me disculpo por ello.
Cual es el resultado?
Como resultado, tenemos una botella, una mezcla explosiva de mejores prácticas de gestión que mejora la eficiencia. Y existe exactamente para aumentar la eficiencia.
Lo que es importante para mí personalmente es una mezcla, un conjunto, no una secuencia. Puede aplicar todos los métodos, puede hacerlo, solo uno, o la mitad, de su elección. Cualquier método, en sí mismo, aumenta la eficiencia. Uno más, otro menos.
Como ya se mencionó en el artículo, a lo largo de los años de práctica he probado partes de la botella en diferentes empresas y, lo que es más importante, en diferentes tipos de actividad humana. Había programadores, ingenieros de diseño y servicios de calidad, y suministros, y ventas, y producción, y contadores, y economistas, y gerentes, y quién demonios sabe quién más.
Está claro que cada profesión necesita su propio conjunto de métodos para la botella y su propia automatización. Pero puedes elegir el kit adecuado para todos. Pero lo más importante: la botella se está desarrollando y a un ritmo acelerado. Porque fue más allá de los límites de mi práctica y comenzó a enriquecerse rápidamente con los comentarios de otras personas, empresas y profesiones.
Incluso hay personas que han tomado una o dos ideas de materiales publicados y las han puesto en práctica. Lo que es especialmente interesante es que no me escriben sobre esto, pero si accidentalmente se cruzan en algún lugar en un foro o conferencia, honestamente hablan de su experiencia y no son tímidos para decir que tomaron ideas de la botella.
Entonces, todo estará bien.