No sé sobre ti, pero me gusta experimentar con personas. Por lo general, no le pido opiniones a las personas, pero esta vez el experimento se realizó a petición propia. La gente quería que les diera un nuevo sistema de motivación. Pues lo hice.
El artículo es algo largo, porque Traté de explicar no solo la entrada y la salida, sino también el proceso de desarrollo del sistema, las preguntas que surgieron en el camino y cómo los resolvimos. Quizás nuestra experiencia le sea útil, si no del todo, entonces algunas de sus partes.
Entonces, en la entrada, un pequeño equipo de programadores de 1C de tres personas trabajando en una solución. Además, yo, su líder, por competencia básica, también soy un programador de 1C.
El proceso de negocio es el más común:
1. Los programadores tienen tareas asignadas de cualquier departamento;
2. Las tareas están sujetas a aprobación, si es necesario. La lista de coordinadores es diferente para diferentes tareas;
3. Las tareas tienen una fecha límite, existe la posibilidad de su transferencia (no más de dos veces). Antes del comienzo, el plazo es acordado por ambas partes;
4. Hay proyectos de automatización llevados a cabo en cascada. Las tareas en el proyecto viven la misma vida que el resto: hay plazos, hay aprobaciones, etc.
5. Existe soporte técnico en forma de servicio: los programadores se turnan para sentarse durante 1 semana.
Sistema de motivación :
1. Los programadores tienen un salario, dependiendo de las calificaciones;
2. Hay una desmotivación para las tareas no completadas a tiempo;
3. Hay bonificaciones por la implementación de proyectos.
La automatización de todo esto es lo más común. Para establecer objetivos, se utiliza un sistema empresarial común, como 1C: Gestión de documentos. Tiene instrucciones y notas en las que viven las tareas. Hay una pequeña automatización de la gestión de proyectos en cascada. Existe un cálculo automático de desmotivación en caso de incumplimiento de los plazos.
Parece ser - vive y regocíjate, trabaja - no golpees al recostado. No es difícil cumplir los plazos si participa en su producción. Trabajo: sin mucha dificultad, nada sobrenatural. Yo, como líder, no destaco entre otros: en otros servicios, las tareas, los plazos y los proyectos se gestionan de acuerdo con los mismos principios.
Pero una pregunta nos persiguió:
¿cómo ganar más dinero?En el sistema actual había dos palancas: para lograr
un aumento en el salario o en las adjudicaciones de proyectos . A las empresas generalmente no les gusta aumentar el salario de un programador 1C, porque apenas entienden
por qué este tipo necesita pagar más dinero .
¿Para entrenamiento avanzado, o algún tipo de categorización, como calificaciones? No está muy claro por qué tiene que pagar más por esto si las calificaciones no afectan los resultados. Y si los resultados son diferentes para los programadores, ¿está esto relacionado con calificaciones formales? ¿Cuánto aumentar el salario, si aún así sigue? Los salarios actuales eran aproximadamente iguales al promedio del mercado.
Un par de veces para aumentar el salario de los programadores todavía tuvo éxito. Por ejemplo, uno fue expulsado a través de la certificación por las fuerzas de los franquistas involucrados. Aumentaron el otro, porque estaba bien en el mercado, valía más (evaluación subjetiva). Pero este camino no puede repetirse con frecuencia, para no escuchar, "¿Estás jodido allí al final, o qué?"
También es imposible trabajar duro para aumentar los premios del proyecto, porque El tema es bastante resbaladizo. Nos guste o no, la
adjudicación de un proyecto es un pago adicional por el trabajo por el cual ya se ha pagado . Por supuesto, puede reformularlo de alguna manera, por ejemplo, un cargo adicional por realizar antes de lo programado, por participar activamente en la implementación o por llevar rápidamente la automatización a los requisitos del cliente.
Pero tarde o temprano, el líder comienza a hacer la pregunta: si una persona siempre está haciendo proyectos antes de lo previsto, ¿por qué debería pagar más por esto? Tal vez la fecha límite se calcula incorrectamente?
Después de pensar, nosotros y los programadores decidimos por nuestra cuenta crear un sistema de motivación y cambiar nuestro trabajo para obviamente traer más beneficios a la empresa. Suponiendo que para un mayor beneficio, recibiremos más dinero.
Es correcto hablar con la compañía sobre los beneficios para la compañía, lo cual hice. Hablé con los líderes, director, dueño. Las opiniones eran diferentes, pero si las agrupaba y clasificaba, la idea central era esta:
queremos lo que ya está haciendo, solo que más rápido . O de otra manera: queremos obtener más al mismo tiempo.
Obviamente, estamos hablando de la
velocidad de programación e implementación . Cabe señalar que en ese momento no sabíamos nada sobre scrum, como un método que acelera el trabajo de los programadores.
Para mí, como líder, este momento fue muy importante:
quería que los programadores se ocuparan de sus resultados . No quería patearlos, pararme sobre mi alma, controlar el proceso y el momento. Necesitaba un sistema autónomo que pudiera funcionar sin mí y sin un líder en absoluto.
El sistema de pago más cercano adecuado para nuestros propósitos parecía ser el
pago a destajo por el trabajo realizado . Parecía prometedor y fácilmente demostrable: aquí está el hombre, aquí está el trabajo realizado, aquí están los ingresos. No hay necesidad de motivar: si una persona no quiere trabajar, no ganará dinero, y esto se hará evidente. Con tal persona, será posible irse sin remordimiento.
Surgió una pregunta clave:
¿cómo evaluar el trabajo y cuánto pagar por ellos ? En francos, este problema se resuelve de manera más simple: hay una estimación de la complejidad en horas por la que paga el cliente. El programador, de hecho, recibe un porcentaje de la tarifa por hora. No teníamos clientes ni relaciones monetarias, pero necesitamos evaluar de alguna manera el trabajo.
La idea surgió rápidamente, al igual que su implementación y la base de evidencia. Decidí evaluar las tareas
en las horas del mejor programador .
Si el mejor programador resuelve el problema en 1 hora, entonces cuesta 1 hora. Otro programador que resuelva este problema en 4 horas recibirá 1 hora paga por ello.
Para evaluar las tareas "por el mejor programador", debe comprender quién es. Decidimos de esta manera: el
mejor programador tiene todos los conocimientos necesarios sobre cómo resolver el problema . Conoce el campo metodológico, conoce los mecanismos necesarios de la plataforma, conoce los metadatos y "dónde está". En general, se sienta y lo hace, sin perder el tiempo en vano.
El objetivo clave de dicha evaluación es minimizar la pérdida de tiempo haciéndolos no rentables. Las pérdidas en el trabajo de un programador son enormes, y en términos de pérdidas de volumen a menudo exceden la mitad del tiempo de trabajo.
Hice la "mejor" evaluación personalmente, y este es quizás el cuello de botella de todo el sistema. De inmediato quedó claro que era necesario hacer que el sistema de evaluación, si no era transparente, se verificara retrospectivamente. Por lo tanto, decidí hacer un clasificador de evaluación de trabajo: un libro de referencia simple que contiene componentes estándar para resolver el problema y su evaluación. Se llenó gradualmente, llamamos a la evaluación del trabajo
"jurisprudencia" : los elementos probados en la práctica, con el tiempo de espera medido, cayeron en el clasificador.
El clasificador contenía, por ejemplo, los siguientes elementos:
- Desarrollo de un informe simple, como "Ventas", un registro, en el ACS en modo de usuario. Puntuación: 15 minutos;
- Creación de un registro de acumulación, con un simple registro de movimientos completamente determinado por el contexto del documento. Puntuación: 15 minutos;
- Desarrollo de roles, sin RLS, con una pequeña lista (hasta 10) de objetos permitidos. Calificación - 10 minutos.
El tiempo de entrega incluyó el desarrollo y las pruebas por parte del desarrollador. Si se produjo un error en la base de datos de trabajo sobre los cambios creados en esta tarea, el ejecutor corrigió los errores a su cargo.
Cada tarea que los programadores realizaron recibió dicha evaluación antes de la ejecución. Está claro que algunas tareas contenían varios puntos del clasificador, por ejemplo, registro, más varios detalles, más un informe, más tarea automática. El tiempo en este caso fue resumido.
Ahora era necesario determinar
cuánto pagar por una hora de trabajo del mejor programador . Decidimos esta pregunta en la frente. Un buen programador promedio recibió 60 mil rublos en el mercado. Decidimos que el mejor programador debería obtener 100 tr. Está claro que posteriormente esta cifra se puede cambiar en cualquier dirección.
Los cálculos simples y el redondeo nos dieron la tarifa por hora del mejor programador:
600 rublos por hora .
La cifra se verá bien, porque es la mitad de la tarifa por hora de las franquicias locales, y más baja que el costo de los trabajadores independientes, que luego pidieron entre 700 y 900 rublos por hora.
Pero lo principal:
solo el trabajo directo era parte de nuestra tarifa por hora. No hubo reflexión, modelado, análisis de decisiones, etc.
Sin embargo, al darnos cuenta de que todavía tendría lugar una conversación sobre esta apuesta con el liderazgo, decidimos asegurarnos de que teníamos razón. Para ello, conversamos con amigos y extraños franquicias y autónomos. Les dimos a estos muchachos algunas tareas para evaluar y les hicimos una pregunta simple: ¿cuánto tomarán dinero por ese trabajo? El resultado fue predecible: los muchachos pidieron trabajo 2-3 veces más que nosotros (teniendo en cuenta los impuestos sobre el salario). Esto se calmó, el culo está cubierto.
Ahora era necesario equilibrar el sistema por la cantidad de acumulación mensual para evitar errores en ambas direcciones. El primer lado son los programadores. Nunca se sabe, de repente resulta que el programador ganó 10 tr No tendrá nada con qué alimentar a su familia. La solución es simple, la vi cuando trabajaba en la franquicia: para
establecer el pago mensual mínimo , menos de lo que el programador no recibirá. Sin pensarlo dos veces, decidieron que este sería el salario actual.
El segundo lado es la empresa. Solo un pago mínimo no es rentable, porque Se puede utilizar para engañar al sistema. Por ejemplo, para hacer 20 tareas al mes antes de que el estado esté "casi listo", obtenga un salario, y el próximo mes haga un gran avance, cierre 20 tareas sin terminar y 30 más nuevas, y obtenga un acuerdo. Por cierto, en la franquicia fue así, y todos lo usaron.
La salida de la situación también es simple:
"recuerda menos" . Trabajó en 40 tr, recibió un salario de 60 tr - ok, recuerda el menos 20 tr El mes que viene tendrás que hacerlo. Trabaja el próximo mes en 80 tr - obtienes 60 tr, y no deberías.
Al mismo tiempo, por si acaso, establecemos el límite de pago: 100 tr. Acordamos que el trabajo realizado en exceso de esta cantidad se considerará un plus en el próximo mes.
Ahora tenía que averiguar qué hacer con los proyectos. Un proyecto, si se simplifica, es un conjunto de tareas relacionadas entre sí por algún significado u objetivo. Pero la compañía está interesada no solo en la implementación acelerada de cada una de estas tareas, sino también en la implementación más rápida posible de toda la lista de tareas del proyecto y la obtención del resultado.
La solución también es simple, y otra vez se asoma por otros:
acumular y dar parte del salario por pieza al final del proyecto . Decidimos que con nosotros será del 20%. Mientras el proyecto está en curso, el programador recibe 480 rublos por hora y los 120 rublos restantes de cada hora al final del proyecto.
Bueno, todo parecía estar calculado y pensado, es necesario comenzar la operación de prueba.
El primer paso fue
cambiar el proceso de
negocio de los programadores:
1. Las tareas ahora deben establecerse no personalmente para el artista, sino para mí, el líder;
2. Ahora tengo que evaluar cada tarea en horas;
3. Después de la aceptación y evaluación, la tarea queda disponible para su implementación.
Ok, el proceso de negocio ha cambiado, es necesario
automatizarlo . Para tener más libertad de creatividad, dejamos de usar tareas y memorandos (todos los usaron), y se nos ocurrieron e hicimos dos objetos nuevos para nosotros en 1-2 días:
1. Una aplicación para el departamento de TI, con todos los campos necesarios para nuestra evaluación;
2. Un sistema simplificado de contabilidad para proyectos y tareas en ellos, con el mismo sistema de evaluación.
E inmediatamente hicieron un informe que mostraba la producción en horas y el dinero ganado para que los programadores pudieran ver sus resultados todos los días.
Comenzó a trabajar e inmediatamente enfrentó dificultades: los
programadores comenzaron a quejarse de que las calificaciones de las tareas son demasiado bajas . "Necesito pensarlo", "pero nunca me he encontrado con el procesamiento, tengo que resolverlo", "Hice una tarea automática una vez, ¿hay alguna instrucción para leer?" etc.
Los escuché y comencé a reflexionar sobre la profundidad filosófica de la pregunta: ¿
debería la empresa pagar por la adquisición de conocimiento por parte de sus empleados?Parece que la respuesta es obvia, debería. ¿Pero es todo tan obvio? Lo que resulta
Aquí hay una tarea para un programador: completar la subcuenta de Warehouse en la contabilización en la cuenta 003 (por alguna razón, en un arrancador suave típico no se llena). Pero él no sabe cómo procesarlo, ni del lado del contratista, ni del lado del procesador.
Parece que siéntate y descubre qué tal y tal, siempre lo hizo. En el sistema salarial tradicional, el empleador le pagará el tiempo mientras usted hurga por allí.
Pero no es tan simple. De las cuatro personas (tres programadores + yo, el jefe), dos están bien versados en el procesamiento, y la tarea fue para alguien que no entiende. ¿Cuándo entendimos el reciclaje? El programador está en el último trabajo, yo estoy en el lugar actual, porque anteriormente no había práctica de peaje / reciclaje. Resulta que la
compañía actual ya ha pagado por esta competencia . Y parece que pagar por segunda vez, al menos en la misma cantidad, está mal. ¿Qué hay que hacer ahora? Así es, transfiera la competencia al que recibió la tarea.
Surgió otra pregunta, ¿y para qué la necesita el transportista competente? También tiene un sueldo a destajo, y en lugar de transferir conocimiento, hará más trabajo mejor.
Comencé a reflexionar sobre una pregunta aún más filosófica: ¿
debería una empresa pagar la transferencia de competencia entre los empleados? Tradicionalmente, la transferencia de conocimiento se da por sentado. Pero todos sabemos que la calidad de tal transferencia deja mucho que desear. La excepción son los programas de adaptación y tutoría, pero no son muy comunes.
Entonces, la solución se hizo obvia para nosotros:
1. Para la transferencia de conocimiento y ayuda mutua deben pagarse;
2. Para la adquisición de nuevas competencias se debe pagar.
El segundo punto es sobre el conocimiento que ninguno de los equipos posee. Por ejemplo, teníamos la tarea de extraer constantemente datos de un sistema externo a 1C mediante consultas directas a MS SQL. La tarea no es difícil, pero nadie ha hecho esto antes. Hice esto: hice una solicitud en mi nombre, cuya esencia es fumar el trabajo con fuentes de datos externas a un nivel suficiente para resolver un problema específico. Evaluación de la tarea: 1 hora (y puede sentarse al menos todo el día).
Como resultado de resolver el problema, obtenemos un especialista que puede resolver problemas con fuentes de datos externas,
y no pagaremos más por esta competencia . Solo por su transferencia a otros programadores.
Decidimos pagar por la transferencia de competencias y asistencia mutua, y para esto se nos ocurrió el término apropiado: los costos de análisis y diseño. Para no perder tiempo en una gran burocracia, dibujamos una tabla en la Palabra que contiene los datos:
1. El tema que fue discutido / diseñado / referido;
2. La hora de inicio y finalización de la discusión, precisa en minutos;
3. Los participantes.
Se agregó un documento separado al sistema de contabilidad, en el cual los resultados de tales discusiones se llevaron una vez por semana.
Por lo general, las discusiones se ajustan a 5 minutos , llegando ocasionalmente a 15 minutos.
Durante una semana resultó a las 3-5 horas .
Lo importante:
el tiempo de discusión se pagó a todos sus participantes , es decir Fue beneficioso adquirir y transmitir conocimiento. Fue beneficioso ayudar a los colegas, ya que las leyes humanas no han desaparecido: si ayudas, te ayudarán, y si te guardas el conocimiento, prepárate para una tarea desconocida con una estimación de 1 hora, siéntate con ella durante 2 días. Por supuesto, hubo excepciones cuando yo mismo eliminé de la lista de participantes al que estaba sentado y contando el cuervo.
Sí, todas esas reuniones deberían haberse celebrado en mi presencia, como Antes del mundo exterior, era responsable de la calidad del sistema. Todos los temas discutidos se reflejaron en el sistema y, si era necesario, era posible regresar y ver si el dinero se había gastado legalmente.
Había otra pregunta "podrida" más: soporte técnico . Asqueroso: debido a que no me gusta la disponibilidad de soporte técnico, embota la mente de los usuarios, les quita un valioso tiempo a los especialistas, sin brindar un beneficio especial a la empresa.
Formalmente, el soporte técnico en ese momento es un oficial de servicio dedicado que debería ayudar a las personas dentro de una semana. ¿Cuánto pagar a un programador que se sienta en soporte técnico?
Al principio, la idea no era pagar en absoluto, sino reducir la base para calcular el salario al calcular el pago. Por ejemplo, si un programador tiene un salario de 60 tr, pasó 2 semanas en un mes en soporte técnico, entonces, al calcular, considere la mitad como un salario: 30 tr, y por el resto del tiempo, considere un acuerdo.
Pero está claro de inmediato que se está obteniendo algún tipo de tontería: la empresa no es muy grande y, objetivamente, el soporte técnico no toma todo un día. En consecuencia, el programador logra resolver los problemas y puede utilizar el esquema con un "tirón".
Hay una salida mucho más fácil: calcular
cuánto tiempo por día pasa al soporte técnico del mejor empleado y pagarle al programador la misma cantidad en estos días. Porque Fui considerado el mejor de esta pandilla, luego lo medí en mí mismo. Simplemente me senté por unos días en apoyo con un cronómetro y el objetivo no era manchar los mocos, sino ayudar rápidamente a las personas. Redirige correctamente sus preguntas a las tareas. Proporcione enlaces a instrucciones si una persona no las ha leído y requiere capacitación en línea sobre lo que todos saben. Bueno, etc.
Según los resultados de las mediciones, resultó que
el soporte técnico toma un promedio de 2 horas al día . Bueno, esa es la cifra. Acordamos que en este monto se le pagaría al oficial de servicio: 2 horas al día o 10 horas a la semana.
Está claro que no es rentable dedicarse solo al soporte técnico, esto es alrededor de 25 mil rublos al mes.
Para que el oficial de servicio no se aburriera, le dimos un papel y le hicimos escribir a todos los que se dirigen a él, solo su apellido. En el sistema de contabilidad, se creó un documento en el que el asistente del día trajo a todos los "conversos". Por qué: mira el final del artículo, bajo el título "Un buen bono".En realidad, la imagen se formó sobre esto, y continuamos la operación de prueba del sistema .Entre los programadores había un entusiasmo sin precedentes . Aferrado a la tarea, el humo se erguía como un pilar en la ejecución.Silenciosamente, un programador comenzó a trabajar, a quien le encantaba discutir "qué tarea tan difícil, hay tantas trampas", que podría pasar horas chupando estas trampas, llenando su propio precio (sin embargo, no está claro por qué, el salario).El programador inmediatamente comenzó a tomar decisiones óptimas, a quienes les encantaba sentarse durante horas y "pensar en la solución óptima", porque ahora la solución óptima fue emitida por un equipo de lluvia de ideas en 5 minutos.Un programador introvertido comenzó a comunicarse con más frecuencia con los clientes, quienes podían sentarse en una tarea ya resuelta durante dos días porque le daba vergüenza hablar con el cliente.Comenzaron a aparecer tareas mucho más sensatas y de alta calidad de los usuarios, porque los programadores comenzaron a ayudar en su diseño.El programador novato, que tenía vergüenza de hacer una pregunta a sus colegas debido a que "es inconveniente distraerse, se molestará" (debo decir que estaban realmente molestos antes) durante horas sentado y tonto.Los programadores se han vuelto apasionados y codiciosos., en el buen sentido de la palabra. Yo, como líder, logré mi objetivo: el sistema comenzó a funcionar, aunque no sin mí, con mi mínima participación.Mi participación se ha vuelto transparente y comprensible, estos son solo puntos en el proceso de negocio:1. Aceptación y evaluación de tareas, hice esto una vez al día, durante aproximadamente 15 minutos;2. Participación en reuniones sobre análisis y diseño (esto es ~ 3 veces al día durante 5 minutos).Total, para administrar tres programadores: 30-60 minutos al día . Nadie necesita patear, seguir la ejecución y el tiempo, motivar, verificar la calidad: todo se hizo solo . Podía ver los resultados en cualquier momento a través del sistema. Esto no quiere decir que resultó ser un completo autogobierno, pero estábamos lo más cerca posible.Llevamos a cabo la operación de prueba durante 3 meses. Durante este tiempo, la producción en relojes se ha duplicado , y el salario calculado para la nueva motivación ha crecido un 30%. La diferencia es clara: ahora el salario tenía que calcularse . Según los propios programadores, nunca antes habían tenido que trabajar tan intensamente en ningún lado. Fue intenso, no largo o largo: siempre estuve en contra de más de 8 horas de trabajo.Pero lo que importa aquí no es lo que dijeron sobre la intensidad del trabajo, sino cómo lo dijeron. Hablaron orgullosamente por sí mismos.. No solo porque el nuevo sistema hizo su trabajo más eficiente, sino también porque ellos mismos fueron los autores de este sistema. Ellos mismos se hicieron más efectivos, ellos mismos hicieron su trabajo transparente y medible, ellos mismos comenzaron a mirar de manera diferente a la compañía, sus gerentes y empleados.Explico el éxito de la siguiente manera:1. Si observa el prisma de las tesis sobre el desarrollo de sistemas de motivación, queda claro que hemos definido bien el producto. Un producto es una tarea resuelta. Se paga dinero claro por este producto. Todo lo demás: a su cargo (reflexión, Internet, comunicación en mensajería instantánea, pausas para fumar, regaños, depresión, etc.).2. Si observa el proceso de desarrollo a través de la autogestión, puede ver que el sistema se creó con la participación directa de las personas que trabajan en él.3. Hicimos el sistema tan medible como pudimos, de acuerdo con los requisitos de control. La mera medición del trabajo realizado hizo que las personas se movieran más rápido y no se involucraran en tonterías.Después de la operación de prueba, pasé por varias iteraciones para proteger el nuevo sistema: director de personal, director financiero, director, propietario, consultor externo de recursos humanos (Moscú, parece muy famoso). A todos les gustó el sistema.Como responsable de su desarrollo, estaba particularmente interesado en la opinión del consultor de recursos humanos, ya que Él conoce bien la práctica mundial y ha completado cientos de proyectos para desarrollar sistemas de motivación. Su evaluación de mi sistema resultó ser muy alta, le gustó especialmente los contornos de la defensa ("recordar menos" y limitar el pago máximo).Posteriormente, los principios de este sistema se volvieron básicos para otros sistemas de motivación empresarial.Una buena ventajaEntonces, teníamos a mano una estimación en rublos para todos los trabajos, incluidos análisis, diseño y soporte técnico. Era un pecado no aprovechar esta oportunidad, y no hacer el cálculo del costo de la automatización en el contexto de clientes y proyectos . Después de todo, ahora sabíamos con certeza a quién gasta la empresa a través de la automatización, y si observa estos datos en términos de utilidad , obtenemos una imagen magnífica.Por ejemplo, aprendimos que el soporte técnico para el subdirector contable, que, según la descripción del trabajo, debe conocer mejor la AMR en contabilidad, deja más dinero del que recibe esta persona en forma de salario.También aprendimos que las personas que siempre se quejan "no están comprometidas con nosotros" consumen el 40% de todo el dinero para la automatización.Fue interesante observar el creciente presupuesto de mes a mes para proyectos que no tenían un host (esto es cuando el director, por ejemplo, dice: automatice este servicio, y la automatización no se ha ejecutado en ningún lado, pero tienen que escribir tareas ellos mismos, por lo que dan vueltas en círculos) .La apoteosis fue el informe en la sesión estratégica con un resultado decepcionante: más de la mitad del dinero que la compañía gasta en automatización sin sentido. La falta de sentido es una característica completamente significativa. Por ejemplo, la funcionalidad está desarrollada, no hay comentarios, pero no se utiliza ("sí, de alguna manera, todas las manos no alcanzan"). O la funcionalidad que está diseñada para ayudar a mejorar el proceso de administración al cambiar el valor del indicador, y el valor del indicador se detiene o empeora (y al comienzo del proyecto se dijo que esto no los ayudará a ustedes, tienen un problema diferente).Cual es el resultado?
Comenzaron a escucharnos con más frecuencia y atención, especialmente ANTES de que comenzara el trabajo. Porque ahora pudimos predecir los resultados de los proyectos, confiando no solo en el pensamiento sistémico, sino también en las estadísticas en números. El volumen de trabajo sin sentido en los primeros meses disminuyó al 30%, a pesar de que mejoró la estructura de "falta de sentido". Pero esa es otra historia.PS
Hay personas que han repetido mi experiencia, bueno, es decir, también construyeron un sistema de gestión y motivación basado en ciertas horas estándar. Dicen que les va bien. Aunque, quién lo admite ...No sé sobre ti, pero soy tonto. La experiencia descrita en el artículo ocurrió hace aproximadamente 4 años, si no recuerdo mal. Luego me enteré del scrum, más precisamente, compré un libro en una venta, y me dejé llevar, pero abandoné todo lo viejo. Porque es tonto.Siempre quieres no pensar, sino tomar lo terminado. Scrum, PMBOOK, CORE PM, Kanban, CBT u otra cosa, "implementar" o, más a la moda, "implementar". Y algunos imbéciles, como los desarrolladores de guías scrum, también están alimentando la situación diciendo algo como "si lo estás haciendo de la manera incorrecta, entonces no tienes que tener miedo". Aunque en el libro ellos mismos escribieron que debes pensar con la cabeza., , . , . , - . , , . , . , . .
? ? , , 1.