Quiero hablar sobre mi experiencia de acelerar la automatización en un equipo de programadores, y sobre qué técnicas ponemos en práctica y qué surgió de ello.
Condiciones iniciales
Llevamos a cabo nuestro experimento para acelerar el trabajo de los programadores en las siguientes condiciones:
- era una empresa manufacturera distribuida geográficamente;
- 4 programadores 1C y yo, su líder participamos en el experimento;
- somos programadores de tiempo completo que admiten configuraciones complejas;
- nos aburrimos y decidimos desarrollarnos.
En primer lugar, el deseo de desarrollar surgió después de que llamamos la atención de un libro de Jeff Sutherland sobre Scrum. Probablemente ya sepa mucho sobre esta técnica, por lo que no me detendré en ella. La parte principal del artículo no será sobre Scrum.
Entonces, cuando leemos este libro, descubrimos que hay un dilema, que es la traducción incorrecta del nombre del libro. El nombre en inglés sugiere que Scrum se acelera cuatro veces: "El arte de hacer el doble de trabajo en la mitad del tiempo".
Y en la traducción al ruso se afirma que Scrum es un método revolucionario de gestión de proyectos. Cuando los gerentes de TI están preparados para las entrevistas, a menudo se les dice, preste atención a lo que la persona se está concentrando, los procesos o los resultados. La traducción al ruso se centra en el proceso .
¿Por qué estoy hablando de esto con tanta confianza? Vi a decenas de personas que usaban Scrum en vivo. La mayoría de ellos acaba de comenzar el proceso de Scrum , y cuando les preguntas: "¿Qué has cambiado?" - dicen: "Nos hemos vuelto transparentes, interesantes, divertidos". Pero cuando está interesado en cómo han cambiado los resultados, si la velocidad de desarrollo ha aumentado, si comenzó a entregar proyectos más rápido, resulta que no lo saben, porque no midieron la efectividad .
Entonces, leímos este libro y lanzamos el clásico Scrum con todas sus etapas principales del proceso comercial (se muestran en la imagen).
Mencionaré el método de medición (aparecerá en todo el informe). La forma tradicional de medir en Scrum es la planificación del póker . Consiste en lo siguiente: para cada tarea, el equipo (o aquellos participantes que entienden algo en esta tarea) reciben una puntuación de 1, 2, 3, 5, 8 y hasta 34 (números de la serie de Fibonacci). Según la totalidad de las estimaciones, se toma el promedio. La tarea se considera completada cuando fue aceptada por el cliente.
Primeros resultados
¿Qué nos dio la introducción del clásico Scrum? Antes de él, la producción diaria promedio por persona era de 4.2 puntos, y con su introducción, el indicador aumentó a 7.73 puntos . Resultó que nuestra productividad se duplicó.
A todos les gustó, les contamos a colegas de otros departamentos, toda la compañía se interesó, todos comenzaron a implementar Scrum en casa.
Pero no pasó nada, porque todos se dejaron llevar por un fetiche: compraron tableros de corcho, pegaron pegatinas y se limitaron a esto. Incluso el propietario, que también estaba interesado en Scrum, engañaba a los empleados: fue al panel de corcho, le tomó una foto, luego regresó una semana más tarde y le tomó una foto nuevamente; el tablero no cambió.
Yo queria mas
Dos veces la mejora del rendimiento nos pareció aburrida. Entonces comencé a leer el libro nuevamente. En la página 54-55, algunos shuhari se dieron cuenta. Estaba escrito en el libro que este es un principio del Aikido que decía: primero haz todo de acuerdo con las reglas (syu), luego comienza a improvisar (ha), y solo luego separa y haz tu propia técnica (ri) .
Curiosamente, en la conocida Guía Scrum, este principio fue rechazado, y solo "syu" quedó del "shuhari".
Y decidimos ir hasta el final.
El algoritmo de aceleración básico recomendado en el libro de Jeff Sutherland es el ciclo de Deming . En palabras simples, puede formularse de la siguiente manera: observas cómo trabaja tu gente, notas dónde son estúpidos, dónde hay un retraso, encuentras algún tipo de cambio, lo implementas y ves lo que sucedió. Si mejora, más rápido, deja el cambio. Si empeora, elimine el cambio. Lo principal es hacerlo rápidamente.
Por cierto, la Teoría de restricciones de Goldratt Systems dice lo mismo, solo se concentra en el otro. Ella dice: encuentre el enlace más estrecho en su sistema, amplíelo o elimínelo. Luego repite de nuevo.
El objetivo de uno y otro es hacer posible obtener el resultado lo más rápido posible en todo el ciclo de producción. Por cierto, el desarrollador del sistema de producción de Toyota expresó la misma idea: el objetivo del sistema de producción es hacer que el dinero del cliente llegue lo más rápido posible.
El rol del observador para el flujo de trabajo lo realiza el Scrum-master. Podemos decir que este es un entrenador. Cuando lees la experiencia de tus colegas de Scrum, perciben a los maestros de Scrum como defensores y dicen que el maestro de Scrum debe eliminar los obstáculos , alejar a algunas personas y ayudar en algo.
Sin embargo, estoy seguro de que el Scrum-master es un observador y entrenador que le enseña a su gente a trabajar más rápido, observa dónde están tontos, ayuda, solicita, busca algo nuevo, prueba diferentes combinaciones. Como un entrenador de fútbol.
Equipo de experimentación
Para comprender el contexto en el que tuvo lugar nuestro experimento, necesitamos presentar un equipo. Si te digo que había dos Stas, Oleg e Igor, esto no te dirá nada, porque nadie conoce a estas personas. Tú, más o menos, solo me conoces.
Por lo tanto, en lugar de dos Stasov, Oleg e Igor, el equipo presentará personajes que todos conocen y que son lo más similares posible a personas reales:
- El conejo es inteligente, silencioso, silencioso.
- Piglet es el más joven, el más rápido, el más curioso.
- El burro es el más deprimido, y es así en la vida.
- Y el búho ... En realidad, el libro original no era un búho, sino un búho real, masculino. Entonces el equipo tenía un búho real.
El siguiente paso es la improvisación.
El primer día, cuando decidimos cambiarlo todo, nosotros:
- Tiró el tablero de Scrum y las pegatinas. Scrum-board fue reemplazado por un sistema de información basado en 1C: gestión de documentos;
- Las etiquetas adhesivas han sido reemplazadas por tareas en este sistema de información;
- Póker izquierdo y medición de velocidad;
- Se eliminaron las reuniones diarias, las retrospectivas, los proyectos (en general, como una entidad), dejando solo una cierta clasificación de tareas por tema;
- Se agregó monitoreo constante del tiempo de inactividad, pérdidas;
- Y agregaron un cambio de proceso constante.
En total , durante este experimento, que duró aproximadamente un año con nosotros, encontramos unos 40 aceleradores . Intenté agrupar estos 40 aceleradores y ahora les diré rápidamente cómo cada uno de ellos influyó en el flujo de trabajo.
Por si acaso, mencionaré de dónde provienen estos aceleradores. No hay nada nuevo aquí. A mí mismo se me ocurrieron algunos principios, a algunos de mis muchachos se les ocurrió algo, leímos algo de los libros. Por ejemplo, cuando en un libro se recomienda actuar de esta manera para resolver tal problema, debe tomar e intentarlo. Si resulta, entonces déjalo. Si no tiene sentido, lo tiramos.
Cambio cero
Entonces, lo primero que comenzó a repensar el proceso es el libro "Código del Samurai" . Recomiendo que todos lo lean, compren y lo guarden en casa. Debido a que fue escrito hace 500 años, y ya hace 500 años, las personas sabían cómo manejar, cómo obedecer, cómo desarrollarse y cómo mejorar.
La atención del personaje, a quien llamo Piglet, en el "Código Samurai" fue atraído por estas dos frases. Él vio eso:
- La decisión debe tomarse muy rápidamente, en siete respiraciones;
- Y si no toma una decisión rápidamente, el resultado será desastroso.
Piglet se dejó llevar por esta idea que si no podía tomar una decisión en siete respiraciones, se negaría. Una vez incluso me perdí una bebida divertida.
Me resultó interesante, volví a leer este libro nuevamente y me di cuenta de que aproximadamente cada décima página dice: para tomar decisiones rápidamente, debe pensar de antemano cómo actuará en una situación dada.
¿Cómo se ve?
Es como una estrategia cuando tienes reglas para tomar decisiones .
¿Cuál es la estrategia más común en nuestro país? Cuando le preguntas a alguien: "¿Cuál es la estrategia de tu empresa?", Te muestran un largo "pie" que dice lo que harán este año: cuáles son los planes, presupuestos, tareas de la empresa, cómo crecerán en ventas, etc. .d.
Esta definición no está cerca de mí, no es adecuada para mis propósitos.
Por lo tanto, dejamos para nosotros solo la segunda definición y comenzamos a percibir la estrategia solo como un conjunto de reglas para tomar decisiones .
En consecuencia, el cambio cero que introdujimos en nuestro proceso Scrum fue que, en nuestro equipo , probando nuevas técnicas de aceleración, formulamos principios para ellos , les damos nombres (para que sea más fácil recordarlos y discutirlos), y usarlos más en nuestro trabajo . Estos principios son los portadores de todo lo demás.
El secreto principal de las mejoras.
El siguiente principio fundamental al que hemos llegado es "el secreto principal de la mejora" .
Lo quieres, lo crees, lo quieres, no, pero hemos encontrado el "secreto principal de las mejoras", cuya eficacia hemos visto muchas veces.
Se puede formular de la siguiente manera: el 75% de los problemas en los cambios surgen debido al hecho de que las personas no trabajan como se les dijo.
¿Por qué está pasando esto? El hecho es que las personas que intentan implementar cambios (por ejemplo, Scrum) vienen y le dicen a sus subordinados: "Ahora está trabajando de una manera nueva". Y luego simplemente se van. Y cuando regresan en una o dos semanas, ven que no hay resultados. Y al final, estos "tramposos" deciden que Scrum no funciona y lo eliminan permanentemente de su memoria y de su conjunto de herramientas. Lo mismo sucede con todos los demás métodos. Vi esto una cantidad increíble de veces en mi empresa, y constantemente intentaban convencerme de que algo (algún tipo de cambio) no funcionaba.
Por lo tanto, hemos formado los principios básicos del cambio: para que se produzcan cambios, deben aplicarse . Si decidimos que no tenemos soporte técnico hoy, solo queremos ver qué sucederá sin soporte técnico, entonces no hay soporte técnico, y nada más.
Esta es probablemente la cosa más importante en la que se basó nuestro éxito, en el hecho de que los muchachos que trabajaron conmigo aceptaron estas reglas. No me pidieron órdenes, instrucciones, cambios en el personal o permutaciones. Simplemente acordamos y lo hicimos juntos. Como resultado, en un día podríamos verificar el funcionamiento de algunos métodos, prácticas, etc.
Siempre había muchos gerentes geniales. Yo mismo una vez quise ser uno.
¿Quién es un gerente genial? Este es el que cree que es necesario establecer una tarea, nombrar la fecha límite, y cuando la fecha límite pasa y la tarea no se completa, el ejecutivo tiene la culpa. Esto no es mío, sino su expresión. Dicen que: Scrum es una mierda, tienes que establecer tareas y seco cuando no cumplen con los plazos.
Pero decidimos por nosotros mismos que los plazos son malos . Por qué
- En primer lugar, cuando tiene un grupo de tareas, por ejemplo, 150, y establece una fecha límite para cada uno de ellos, debe volver a calcular estas fechas todos los días, porque "flotan" todo el tiempo. Como resultado, se dedica una gran cantidad de tiempo a la administración;
- En segundo lugar, debido al hecho de que las fechas "flotan" todo el tiempo, siempre son incorrectas ;
- Además, el grado en que una persona cae en el tiempo no significa nada en absoluto . Es solo que una persona, por un período, podría tener una tarea;
- ¿Y para qué se necesitan entonces? Si te preocupas mucho, pero de hecho, el momento siempre es incorrecto? El tiempo es solo un fetiche;
- Decidimos por nosotros mismos que la gestión del tiempo es un "enfoque femenino" en la gestión .
El último punto debe aclararse por separado. Inmediatamente les pido a las mujeres que no se ofendan, especialmente porque este enfoque ahora es aún más común en los hombres. Esta metáfora fue inventada para explicar de alguna manera las acciones de algunos gerentes.
Una analogía de la vida: imagina que una mujer le pide a un hombre que arregle un grifo y le da 5 días para hacerlo. ¿Qué pasará todos estos cinco días? ¿Un hombre hará algunos de sus propios asuntos y una mujer se lo recordará? No, no lo hará. Ella vendrá todos los días y observará tranquilamente, reparada o no reparada. Y aquí llega el quinto día, aparece la mujer, mira, no lo arregló. Esperando en la mañana y en la mañana ...
Y lo más importante, para una mujer, este es un resultado positivo . Por qué Porque después de eso puedes hacer así:
Ahora dibuje una analogía con los gerentes duros que establecen la tarea para que la persona no la complete a tiempo, y luego podría explotar . Me parece que esto es una especie de sadismo. Se divierten mucho y creen que esto es trabajo , y para eso tienes que pagar 300-500 mil rublos al mes.
No somos así, por lo tanto, hemos formulado para nosotros mismos el principio de que se necesita un término solo cuando no se necesita hacer nada después de él . Por ejemplo, la fecha límite para la presentación de informes. Después de eso, ya no puede hacer la tarea, porque parece que la penalidad por informar tarde es aproximadamente el 20 por ciento de los ingresos.
Objetivos
Seguramente todos vieron a sus subordinados en este estado.
Vienes a trabajar y tu empleado se sienta así.
O asi.
¿Qué hacer con eso? Solía hacer esto:
Como resultado, fue enviado con franqueza varias veces, una vez llevó a una persona a un desmayo, y esto sin contar las lágrimas, tanto hombres como mujeres. Asqueroso, todavía avergonzado.
Una persona que constantemente le grita se convierte en una mierda. Aunque es más correcto decir que el imbécil fue quien lo hizo de esa manera.
¿Por qué esta condición es mala? Si constantemente le gritas a una persona, ya no verás sus lágrimas, lo que significa que no sabrás que está sentado y no hace nada . Porque una persona en depresión no hace nada . Por eficiencia, esta es una gran pérdida. Si una persona se deprime por la mañana, pasará todo el día navegando por Internet, abrirá el configurador y cambiará rápidamente de un lado a otro. Aún así, los programadores están sentados junto al monitor desde la puerta, ¿verdad?
Por lo tanto, es mejor no gritarle a la gente. Es necesario analizar la situación, y puede resultar que la persona no tenga una motivación común . Pero una persona no tiene motivación porque no tiene una meta . Vino a trabajar y no sabe por qué. Y si también recibió algún tipo de negatividad en el hogar, por ejemplo, porque no logró ningún objetivo en el hogar (su esposa quiere irse de vacaciones a las Maldivas, pero no puede proporcionar esto), viene a trabajar solo para sentarse . Porque cómo lograr el objetivo, él no lo sabe . O tal vez no tiene ningún propósito.
Por lo tanto, hemos formulado para nosotros mismos el principio de que necesitamos hablar sobre objetivos . Primero, nos sentamos uno a la vez, hablamos, luego nos juntamos, discutimos.
Como resultado, logramos derivar una cierta meta "promedio", una para todos .
Este "objetivo promedio" era así: trabajar para el futuro empleador . Esta redacción tiene muchos significados (bueno, me parece). Mencionaré solo dos:
- En primer lugar, el objetivo del programador no está relacionado con el trabajo actual de la organización actual. Porque las personas que se apegan a la organización actual cuando la abandonan reciben un gran golpe a su importancia. Después de todo, lo que era importante aquí, nadie lo necesita allí .
- En segundo lugar, ¿qué significa "trabajar para el futuro empleador"? Esto significa obtener la experiencia más abstracta que será útil para la mayoría de los futuros empleadores.
Este es el objetivo que formulamos para los niños, y esto tuvo un efecto muy positivo en ellos.
Algunas palabras sobre "personalización sobre la marcha" es una forma puramente técnica para acelerar el trabajo.
La imagen muestra una lista incompleta de dichos aceleradores. Estas son soluciones abstractas que resuelven ciertas clases de problemas muy rápidamente . El ejemplo más común es la validación de datos. En lugar de cada vez que el usuario quiere prohibir algo mientras sostiene un documento, escribir código durante 30 minutos, realizamos una verificación en tres minutos sin iniciar el configurador. Eso es todo.
Después de agregar el "Objetivo promedio" y la "Personalización sobre la marcha", obtenemos el "Kit de despido". Que es esto Este es solo el conjunto de conocimientos, experiencias e ideas que una persona, dejando la empresa, lleva consigo .
Para cada miembro del equipo, hicimos una lista bastante grande de lo que necesitamos estudiar, lo que debemos probar, lo que debemos entender, para que cuando salgamos de la empresa, esto se pueda aplicar a un nuevo trabajo.
Las prioridades son una cosa increíblemente importante.
En mi vida, he probado muchas opciones diferentes para asignar prioridades a las tareas, en la medida en que utilicé el modelo de desarrollo innovador de vectores de una empresa a partir de una disertación doctoral en economía.
Pero la práctica ha demostrado que la eficiencia está en la simplicidad. Por lo tanto, al final, para establecer prioridades, elegí la matriz Eisenhower habitual . Todos conocen esta herramienta, cuando todas las tareas se dividen en cuatro cuadrados.
En los principios del equipo, esto se reflejó de la siguiente manera:
- La urgencia / importancia es puesta por el gerente (s);
- El empleado no tiene opción de orden de ejecución;
- Por Nefig.
¿Por qué el empleado no tiene una opción de orden de ejecución? Porque la capacidad de elegir una tarea para el programador es un mal terrible para la eficiencia . Puede elegir una tarea todo el día. Que es un dia Esto es el 20% de la semana. Eso es todo, el día ha pasado. No solo elige una tarea, puede ir al configurador, ver cómo se resuelve, cuáles son las trampas, y luego se asustará y cambiará de opinión sobre hacerlo. Y así pasa todo el día, y tal vez más.
Y los dos males más grandes para la eficiencia son cuando una persona tiene miedo y cuando no comprende .
Miedo: esto es cuando una persona se sienta y él:
- Da miedo preguntar;
- Es terrible equivocarse;
- Es aterrador distraer a los colegas para preguntar algo;
- , .
, . , – , – ?
, , . , . . ?
, .
, metadata.js.
, , 20 . , , – , – . .
, . , .
, . . , . , , .
, ? , , , .
- , , , . ? : « , ». , . - – . , : «, , ». , , , , . , , .
, ? – , . :
- .
- « ». , – . , , – . – , , .
- - – - . , - , – . , : «, , , , , ». , – 30 .
- – . : , , , . , . : , . : «, , » – . - - .
, , . – – , , .. , .
– , ? . , , , , .
. 30 % . :
, … , , . , , , . , . .
– .
, , . . , — , . , , – , . – . , . , . – . , , , .
, , .
… , « ». .
, ? . :
, , , . , - , .
, , .. , – . – , , , . « », .
, . . , – , - . , , , , – , , , , – -, .
, , , , . , – , , , -, , , . , . , .
. , , , . , . , . , , . .
Se les cayó, en el departamento de compras, Piglet. Digo: ¿cuánto tiempo llevas quejándote de que te falta automatización? Aquí está Piglet a su completa disposición. El aterrizaje fue con intención maliciosa, porque Piglet es un chico alegre y encantador, y a las chicas realmente les gusta (la mayoría de las cuales están en el departamento de compras).
Durante una semana simplemente se sentó con ellos: esa era la tarea del centro, sentarse y mirar. Vi, vine y dije: trabajan el 3% del tiempo. Funcionan, en el sentido de comprar, buscar proveedores, hacer pedidos, es decir desempeñan su función principal. El resto del tiempo se dedican a algún tipo de proceso, burocrático y sin sentido.
Naturalmente, no les dijimos esto a los compradores, para no ofendernos. Piglet recibió una nueva tarea y volvió a la adquisición. Comenzó a hacerle preguntas incómodas al jefe, o simplemente a troll. Suficiente por unos días, la jefa misma vino a nosotros al departamento de TI y dijo: ahhh, ¿qué hay de este zoológico?
Bueno, todavía tengo un plan de la época de Vasya. Aquí, digo, hagámoslo. Y eso es todo.
Ahora un poco sobre el conejo. Trabajó solo durante mucho tiempo en fábricas.
¿Qué le sucede a una persona cuando ha estado trabajando solo en la fábrica durante 1C como programador? Comienza a resistir las tareas. Lo hace de muy alta calidad: les recuerdo que Rabbit es muy inteligente, estudió bien en la escuela y la universidad. Le traen una tarea, dicen: hagámoslo, y Rabbit responde: no, no es necesario que hagas esto, y da muchas razones aparentemente objetivas por las que el problema realmente no necesita ser resuelto.
Todo estaría bien, pero él comenzó a hacer lo mismo conmigo. Por ejemplo, le puse la tarea. No dice nada, se sienta a la computadora.
Me dedico a mis asuntos y creo sinceramente que él se sienta y resuelve el problema. Y él, el perro, se sienta y piensa por qué no se debe hacer . ¡El resultado de su trabajo en un día, o incluso en dos, es una lista de razones de alta calidad por las cuales la tarea no debe hacerse!
Y si todavía lograba superar esta etapa, se reclinó en su silla, miró hacia el techo y comenzó a decir qué dificultades encontraría para resolver este problema. Yo digo, ¡para! ¿Sabes cómo hacer todo esto? Pues sí. Entonces, ¿por qué me cuentas sobre tus dificultades aquí? Bueno, entonces yo ... - dice Conejo.
Como resultado, formulamos el principio más simple: el problema debe resolverse . No importa lo que piense al respecto, si yo, como líder, tomé esta tarea para trabajar, entonces tendrá que resolverla, sin opciones. No busque ninguna forma de evadir esta tarea. Y eso es todo, no surgieron más de estas situaciones.
Este es un principio muy simple. Las tareas son grandes y pequeñas. Scrum dice: debe dividir las tareas en pedazos para que cada una no tome más de un día.
Pero a veces resulta así. Un hombre se sienta, hace una tarea y termina, por ejemplo, a las 15-00, dos horas antes del final de la jornada laboral. Renuencia a comenzar una nueva tarea. Del mismo modo en la mañana, mientras que el café, el correo, las redes sociales, eso, y solo entonces las tareas.
Para utilizar eficazmente estos límites de tiempo, hemos identificado un grupo especial de tareas, que llamamos "shorties". No obedecieron a la matriz de Eisenhower, se colocaron en una lista separada y estaban destinados específicamente a "tapar agujeros". Queda una hora antes del final de la jornada laboral: haga un par de shorties. Simple, sin sumergirse en el contexto, pero tareas beneficiosas. Si no los ignora, puede obtener un aumento en la eficiencia del treinta por ciento.
La mosca importunate soy yo.
Scrum clásico dice que tienes que hacer reuniones diarias por la mañana. Y recuerdo mi control favorito y miro a través de su prisma. ¿Qué son las reuniones matutinas diarias? Este es un acto de gestión una vez durante el día. Es decir En el Scrum clásico, puedes acercarte al timón una vez al día.
Esto no es suficiente para mí, porque si en la reunión una persona dijo que estaba haciendo todo, y después de cinco minutos no estaba funcionando, entonces lo sabré solo al día siguiente, habiendo perdido el 20% de eficiencia.
Así que reemplacé las reuniones diarias con control.
- Usted pregunta una vez al día; se las arregla una vez al día;
- Usted pregunta una vez a la semana; se las arregla una vez por semana;
- Usted pregunta una vez al mes; se las arregla una vez al mes;
- Pides 5 veces al día; gestionas 5 veces al día;
- La administración es un cambio en la dirección correcta .
Naturalmente, un tablero de scrum no era adecuado para tal control. Ella responde la pregunta "qué se ha hecho durante el sprint", pero no sabe nada de lo que se hizo en la mañana o ayer. Intentaron adaptarse, por ejemplo, para escribir la fecha y hora de ejecución en una pegatina, pero leer esta información es inconveniente.
Por lo tanto, el tablero de scrum, como líder, me enfureció terriblemente, no proporcionó información para la administración. Bueno, lo tiré, reemplazando la automatización simple en el sistema de información. La tarea cerrada cayó inmediatamente en el informe, que dividí en dos secciones: desde el comienzo de la semana hasta la mañana. Controlando estos dos indicadores, en cualquier momento vi que había desaparecido algún tipo de falla.
Los principios son simples:
- Mire el volumen de tareas varias veces al día ;
- Preguntar consciente y urgentemente sobre dificultades y obstáculos;
- Inmediatamente entiendo;
- Gracias 1C: ANTES, adiós scrum-board.
Resultados finales
Como resultado, obtuvimos cierta técnica con principios y puntos de control. Como ya se nos ocurrieron los principios, tuvimos que inventar un nombre, porque de lo contrario no es conveniente discutirlo. ¡La búsqueda del nombre tomó exactamente un minuto!
Primero así.
Y luego así.
El experimento que realizamos según la metodología "kazaja" duró aproximadamente un año.
- Permítanme recordarles, antes de la introducción del clásico Scrum, nuestra eficiencia estaba en el nivel de 4.2 puntos.
- Book Scrum elevó el puntaje a 7.73 puntos.
- Y en el Scrum "kazajo", comenzamos a dar 17 puntos.
Y después de todo esto, dejé esta compañía, y un "gerente duro" entró en mi lugar. Un gerente realmente genial, a quien Scrum llama "scrum" y dice que esta es una técnica novedosa. Como mis muchachos permanecieron en la empresa, continuaron midiendo su efectividad y me dieron sus indicadores de cómo están trabajando ahora. Ahora su efectividad ha caído a 2.5 puntos.
Si calculamos el cociente de las primeras y finales mediciones, resulta que todos los métodos y principios aplicados nos dieron un aumento de 4 veces en la eficiencia .
PD: También hay una versión en video: una y dos .