Programador Exorcismo

Hay mucho material sobre cómo la introducción de sistemas de información ayudó a las empresas a deshacerse de las pérdidas, reducir los costos y reducir el robo. Es maravilloso cuando resulta deshacerse del mal en un volumen tan grande.

Mi artículo es sobre el mal menor. Sobre el sabotaje de implementaciones, sobre lo eterno "Estoy haciendo todo bien, es tu programa el culpable", sobre la hinchazón, sobre asuntos de pequeñas empresas y la resistencia al cambio.

Todo en el artículo es de experiencia personal, con ejemplos de uso. No pretendo ser único y revelar completamente el tema, no hay una verdad más elevada aquí, traté de evitar generalizaciones, no impongo nada.

Solo la experiencia de usar algunas herramientas y ejemplos de cómo me ayudaron.

Grabar acciones del usuario con parámetros de tiempo


Sinceramente, no recuerdo por qué hice esto, pero fue útil varias veces. El desarrollo es simple y torpe, no lleva más de una hora. No aplicable en todas partes, ya que puede consumir muchos recursos y los datos ocupan una cantidad significativa de espacio en disco, por lo que debe supervisarlo.

El principio es simple:

  • registra cuando el usuario abre el formulario (documento, directorio, informe, procesamiento);
  • toma notas cuando la cierra;
  • registra cuando lo grabó (si es un objeto almacenado, como un documento o directorio);
  • registra si era un objeto nuevo o uno antiguo;
  • registra todo lo que necesita saber sobre el objeto: enlace, nombre de tipo, nombre de usuario, nombre del formulario.

Como resultado, tenemos una tabla grande con datos y varios dígitos calculados. Por ejemplo, conocemos el "cheque promedio": cuánto tiempo lleva crear un recibo de una factura por parte de un contador. Sabemos cuántas veces un contador regresa a un documento creado previamente para cambiarlo, y cuánto tiempo pasa en él.

Daré ejemplos cuando el mecanismo sea útil.

El primero es la eliminación del pequeño sabotaje de implementación. Se introdujo un mecanismo para recoger un pedido en el almacén: el almacenista debe marcar los artículos recogidos en la caja. Se les dijo claramente a los comerciantes: sin fanatismo, trabajen con el sistema solo cuando haya tiempo libre.

Un día después, el gerente de envíos viene corriendo, dice que los comerciantes se niegan a cargar el automóvil, dicen que necesitan introducir datos en algún sistema y les lleva 2 horas al día hacerlo. Por supuesto, explico rápidamente que nadie les dio tales órdenes. Veo mi informe, ya veo: dedican 20 minutos al día a todos . Le dijo al gerente, le dijo a los dueños de las tiendas: eso es todo, no hubo más de tales declaraciones de ellos.

Segundo ejemplo Findir ordena algunas funcionalidades para administrar el dinero. Lo importante no es porque quiera, sino porque este ciclo de contabilidad no es suficiente para los superiores. Luego, en una reunión general, le preguntan: ¿por qué, cuándo aparecerán los datos? Él dice: hay errores, no funciona, escribiremos una tarea para que la finalicen los programadores. Abro el informe, demuestro que ni él ni sus hijas han ingresado ni el documento ni el informe. Eso es todo, la introducción ha seguido adelante.

El tercer ejemplo. La contabilidad dice: necesitamos expandir el personal, hemos aumentado el flujo de documentos. Se le pide a la gerencia, consciente de mi informe, dar estadísticas, qué ha crecido allí y dónde.

El primer recuento en la frente, el número de documentos y el número de líneas en ellos, mostró que el flujo de documentos no aumentó.

De acuerdo, creo, tal vez algo complicado allí en los documentos, en realidad puede ser más difícil redactarlos.

Miro el "cheque promedio" y su dinámica para dos contadores: no, parece que no crece, no cae.

Se dio cuenta de que un contador de mucho tiempo había ido recientemente a la licencia de maternidad, y dos nuevos estaban tomando su lugar. Tenía datos para los tres, comparo - bah, aquí está. Dos nuevos contadores ingresan documentos más lentamente que uno viejo.

Todo, la expansión del estado ha sido cancelada, solo hay que esperar hasta que llenen su mano. Al mismo tiempo, un poco de automatización.

Del tercer ejemplo sigue el cuarto , ya positivo. Al ver la dinámica de la "verificación promedio" por tipo de objeto, comenzamos a usarla para analizar la automatización de las operaciones y las consecuencias de los cambios. Si el "cheque promedio" creció, entonces analizamos las razones, observamos a las personas en vivo y mejoramos.

Registrar valores métricos


Técnicamente, esta es una solución muy simple. Su esencia es simple: se escribe una consulta que calcula algunos dígitos y los guarda en el sistema con la frecuencia deseada. Como resultado, tenemos la dinámica a tiempo para la figura.

No es necesario memorizar muchos números porque Son reproducibles. Por ejemplo, no es necesario recordar el volumen de ventas; siempre puede verlo retrospectivamente.

Pero algunos números solo se pueden reproducir elevando la base de datos de respaldo. Por ejemplo, esta es la única forma de averiguar cuántos saldos negativos de bienes tenía hace un mes. Quienes leen mis artículos anteriores entienden que se trata de Iceberg .

Primer caso de uso. Hay problemas con la compensación del anticipo: una cantidad bastante grande se cuelga simultáneamente en 60.01 y 60.02. La funcionalidad es típica, no hay dificultades metodológicas: solo indique la analítica correcta en los documentos y se contará el avance. En las reuniones, la contabilidad dice: no hay problema, lo haremos. En cada reunión posterior repite: estamos haciendo, hay mucho trabajo, mal automatizado. Me miran con recelo.

Vengo, enciendo el registro del indicador: la cantidad del anticipo no registrado. Creo que no, lo harán, dirán que el avance no reconocido está creciendo más rápido de lo que lo corrigen. Divido el indicador en tres partes: la cantidad a principios de año, la cantidad a principios de mes, la cantidad de hoy.

En la próxima reunión, muestro los números: cómo fue y cómo se convirtió. Un avance no reconocido a principios de año y principios de mes es una apuesta: no arreglaron nada. El avance no reconocido por hoy no ha cambiado mucho, lo que significa que ahora los documentos normalmente se redactan. Como resultado, los errores antiguos se corrigieron en 2 días.

Segundo caso de uso. Automatizó la cadena de suministro, la función es simple: el programa dice cuánto necesita pedir a los proveedores, tomarlo y pedirlo. Por separado, el mecanismo especificado escribe el nivel de déficit actual. Miramos: el déficit está disminuyendo en algunas posiciones y creciendo en otras. Diferentes personas son responsables de los puestos. En la reunión, todos dicen: sí, hacemos todo según lo ordenado, miramos, ordenamos. Por qué crecen los déficits: no lo sabemos, la automatización es probablemente mala, los números se calculan incorrectamente. Todos me miran con recelo.

Voy de frente: miro los pedidos realizados a los proveedores. Inmediatamente no puedo entender, porque los documentos se ingresan y cambian no con prontitud; esto es normal porque El proceso de aprobación puede llevar varios días y se ajustará todo este tiempo.

Puse un registro de dos indicadores individualmente para cada proveedor: cuántos artículos estaban disponibles para ordenar por la mañana, cuántos de ellos se ordenaron durante el día. Y listo, el gerente "bueno" (chica ordenada) ordenó del 85 al 100% de lo que el sistema requería, los "malos", el 15%. Todo, el trabajo con disciplina se ha ido. Lo que es interesante: a los proveedores, al ver este informe, se les pidió que se los entregaran (los proveedores mismos, y no su supervisor). La diferencia entre el mío y su informe fue simple. Su informe mostró los residuos actuales, y el mío todavía mostró la "vida útil" de estos residuos. Todo lo mismo Iceberg.

Ideas de fijación


Varias veces escuché de los programadores que se les robaron ideas, especialmente los jefes. Escuchan la idea, luego dicen que no se trata de nada, y después de un tiempo la hacen pasar como propia.

Por lo general, tengo muchas ideas, no juzgaré la calidad, pero de hecho hay muchas. Me di cuenta hace unos años que no los recuerdo. Sucede que se me ocurre una idea varias veces.

Luego vi en el sitio web del estudio Artemy Lebedev que estaban escribiendo ideas , y pensaron que era útil. Decidí hacer lo mismo: en el sistema de contabilidad de tareas me hice un dividendo, donde comencé a escribir estas ideas. Estaba disponible solo bajo todos los derechos, como Solo lo necesitaba.

Luego, la empresa decidió sistematizar el trabajo con propuestas de racionalización: archivo, evaluación, contabilidad de implementación, etc. Me preguntaron si es posible automatizar, dije: todo ya está automatizado, mostró su mecanismo. Lo modifiqué un poco para que hubiera un voto, comentarios, contabilidad de implementación, configuración de tareas, etc. Pero ese no es el punto.

La conclusión es que las ideas se han hecho públicas y fijas, y se ha vuelto difícil robarlas. El mío es casi imposible, porque Cuando el sistema se abrió para los usuarios, ya contenía varios cientos de mis registros.

El primer caso de uso ni siquiera requirió mi participación. Mucha gente lee ideas, y cuando alguien hizo una propuesta en algún lugar, los lectores le dijeron abiertamente: bueno, había una idea así, mira en el sistema, hay una discusión allí. Si no estuve presente en esta conversación, entonces el inventor me fue enviado, y usualmente comenzó la frase con "usted propuso esta idea, la leí, es interesante, impleméntela ...".

El segundo ejemplo está relacionado con la promoción de un sistema de propuestas de racionalización. Naturalmente, adjunté el seguimiento de lectura a la funcionalidad de arreglar ideas. Y resultó que los empleados de algunos departamentos, que realmente se esforzaban por cambiar su trabajo para mejor, comenzaron a hacer sus propuestas al sistema. Pero solo se implementaron propuestas relacionadas con la automatización, porque estaban dirigidos a mí, pero fue interesante para mí.

En las reuniones, a los gerentes se les hizo la pregunta: ¿cómo está usted con la implementación de las propuestas? ¿Alguna idea útil de su personal? Muchos respondieron amigablemente, no, nada interesante, todo sin sentido. Muestro el informe: no ingresaron en absoluto al sistema, no leyeron una sola idea, sin mencionar la implementación. Por si acaso, les preguntaron a los empleados: ¿pueden dar sus sugerencias verbalmente o por correo a sus gerentes? No, dicen, no hubo tal engendro, y en general tenemos miedo de levantar la cabeza.

Los datos proporcionados, el proceso se ha movido del suelo.

Captura de datos


El propósito de este mecanismo es expandir las capacidades de control de versiones. Por lo general, el control de versiones (tanto estándar como no estándar) captura los cambios en los datos primarios: directorios, documentos, etc. En la práctica real, esto no es suficiente.

Por ejemplo, el "voló" con diferentes variaciones de la "mosca". La forma tradicional es mirar los cambios en los documentos que podrían afectar o generar una copia de seguridad, cargar detalles en Excel y comparar revoluciones.

El problema también es que una persona debe rastrear el momento de la "escisión".

Como resultado, creó un mecanismo simple que almacena bellamente la estructura enrevesada de las revoluciones y reacciona a los cambios. Y el área de datos para arreglar, convolución y periodicidad, se configura a través de una consulta.

Sin entrar en detalles, el mecanismo señaló los cambios en el área de datos ("el tiempo de respuesta ha volado") durante una hora (esta es la frecuencia de la operación de la tarea). Indicó el área de datos, indicó el período e hizo posible encontrar los datos primarios.

Sí, y permitió "aceptar los cambios": si todo era honesto, los datos modificados se convirtieron en la referencia, y el seguimiento ya estaba en marcha sobre los cambios.

Primer caso de uso. La gente comenzó a quejarse de las sobretensiones en el almacén ("miro a las 10 de la mañana, miro a las 5 en el almuerzo, y ya le prometí al cliente, y no soy un tonto, veo que no ha habido movimientos durante una semana"). La contabilidad dice: no tenemos nada que ver con eso, todos los documentos se ejecutan en un día, sin correcciones retroactivas. Analizamos el mecanismo: voila, los saldos de hoy están cambiando, porque el impulso del mes anterior ha cambiado. Buscando: el contador presentó un nuevo documento hace un mes. Preguntamos: ¿qué estás haciendo? No tengo tiempo, dice ella.

Segundo caso de uso. Registré datos de ventas, simplemente porque probé el mecanismo en esta área de datos. Se creía que los datos de ventas cambian por un máximo de una semana, y luego en casos raros cuando se cometen errores. Y aquí miro: las ventas del mes pasado han cambiado. Usted comprende, durante el último mes, el gerente de ventas ya recibió un premio. Veo que el contador ha cambiado, ¿qué estás diciendo? Resultó que el gerente forzó, porque era demasiado inteligente, confundió al cliente. Después de este incidente, el contador dejó de hacer esto.

Preguntas para el control


Tareas de control funcional, proyectos, etc. hay, por ejemplo, en 1C: gestión de documentos, probablemente muchos lo han visto. Allí puede controlar cualquier (o casi cualquier) objeto, establecer una fecha y aparecerá un recordatorio.

No me gustó el típico, porque no le permite realizar el control en varias etapas, por ejemplo, hacer que el recordatorio aparezca 10 veces a intervalos de una semana. Por lo tanto, hice mi mecanismo simple, cuya principal diferencia es que le permite mantener un historial de control y estirarlo durante cualquier período de tiempo.

Por ejemplo, inicio un cambio en los procesos comerciales. Estoy escribiendo cartas, teniendo reuniones, etc. Escribo esta pregunta a mi sistema, pongo un punto de control: en una semana, escribo un comentario como "preguntar a Vasya nuevamente". Después de una semana veo un recordatorio, le pregunto a Vasya nuevamente, Vasya dice "aah, escucha, tenemos un bloqueo, hasta ahora no hay tiempo". Ok, digo, pongo el siguiente punto: en una semana. Veo un recordatorio, entro, veo una historia. Le pregunto a Vasya nuevamente, Vasya nuevamente tiene un bloqueo. Yo digo: Vasya, ya lo dijiste. Vasya jura que esta fue la última vez. Después de una semana, el movimiento aún comienza.

Parece una especie de basura, y parece que todo esto se puede resolver por correo, pero, como se indicó al comienzo del artículo, no pretendo decir la verdad. El uso de esta herramienta y este enfoque me ha ayudado varias veces cuando es obvio obtener algo de personas que no te obedecen. No puede establecer una tarea para ellos, y superar la situación en esta situación en particular no es algo infantil, la gente no hará nada en absoluto.

Contabilidad de costes de automatización


Técnicamente, es muy simple. Hay una contabilidad de tareas y proyectos en el sistema. En cada tarea hay una cierta evaluación de los costos laborales, ya sea horas o puntajes para la planificación del póker. Conocemos los salarios de los programadores. El cliente, su unidad y gerente son conocidos.

Tomamos el salario del programador y lo distribuimos a las tareas resueltas en un mes. Resulta el costo de resolver un problema específico. Se puede ensamblar por proyecto, por cliente, por unidad.

El primer ejemplo de uso es la protección contra colisiones como "no nos tratan, no resuelven nuestros problemas". Abrimos el informe, mira, sí, la compañía gastó 250 tr en la automatización de la contabilidad por el mes pasado O 1,5 millones de rublos al año, por ejemplo.

Aquí el truco es que está valorado en rublos, una unidad de medida que el director puede entender. Si dice "hemos resuelto 113 tareas del departamento de contabilidad", entonces él no penetrará; dirá que aún queda mucho por hacer. Y cuando dices "gastaste 1,5 millones en sus tareas", se avergonzaría de decir "¡gastar otros 2 millones de mi dinero en ellas!". La mayoría de las veces, suspiró y preguntó a la oficina de contabilidad qué tareas se debían gastar en 1,5 millones de rublos.

El segundo ejemplo es más interesante. A menudo, los programadores se quejan de que están haciendo algún tipo de funcionalidad siguiendo las instrucciones del usuario, y luego él no usa esta funcionalidad. Al mismo tiempo, continúa quejándose de que su trabajo está mal automatizado.

Decidimos resultar más interesantes. En las tareas resueltas, comenzaron a indicar no solo el cliente, sino también los nombres de los metadatos (documentos, directorios, etc.) que se crearon o finalizaron para resolver este problema.

Bueno, entonces es simple. Pidió al jefe del servicio de calidad que automatice la verificación de los instrumentos de medición. Solución técnicamente simple: hay instrumentos de medición, un cronograma de calibración y un documento que corrige el hecho de la verificación. Después de la automatización, como se esperaba, los usuarios ingresaron un instrumento de medición, un documento de verificación y un gráfico.

Y hemos calculado los costos. Digamos que esto es 30 tr. Conocemos los metadatos, la cantidad de objetos que conocemos, los dividimos uno en otro; resulta que en nuestro sistema se gastan 30 tr en contabilizar un instrumento de medición Aunque el propio instrumento de medición cuesta 1 tr.

Cuando el jefe del servicio de calidad la próxima vez en una reunión comience a decir que necesita automatizar algo, le preguntamos cortésmente: ¿cómo va el "calibrador de oro vernier", por la cuenta de una verificación de la cual la compañía gastó 30 tr?

Contabilidad de costos de soporte


A nosotros en el soporte técnico se sentó una persona: el oficial de servicio. A menudo escuché de él algo así como "cómo lo consiguió, la estúpida tonta, pregunta lo mismo todos los días". Al principio no le presté mucha atención: nunca se sabe, la persona no lo recordaba, o tenemos la culpa. Luego, de manera indirecta, descubrí que algunos usuarios lanzan deliberadamente ataques DDoS al soporte técnico, porque no les gusta el departamento de TI.

Organizó una solución de programación simple. Hicieron un documento para arreglar llamadas al soporte técnico. En general, cuando una persona necesita automatizar algo, escribió la tarea de todos modos, pero cuando tenía una pregunta, llamó o escribió por Skype.

La persona de turno simplemente introdujo el apellido y el tiempo aproximado de servicio en el documento. Fue posible leer los registros de Skype a través de la API, pero decidió no hacerlo; no contará la comunicación personal y la correspondencia de esta manera.

Bueno, entonces es simple. El costo total del soporte técnico lo conocemos en el párrafo anterior. Dividimos el dinero por el momento de las apelaciones, obtenemos la cifra: qué tipo de persona y departamento cuánto dinero gasta la compañía en sí misma.

El primer caso de uso es común. Cuando alguien dice que no responde a sus preguntas y lo está haciendo mal, mostramos la figura. Mira, amigo, la compañía gasta 20 tr en tus preguntas. por mes

El segundo ejemplo de uso es más interesante. Lo llamamos el "costo de la incompetencia". Desafortunadamente, nuestros recursos humanos no estaban muy versados ​​en las complejidades de la contabilidad, y no sabían cómo verificar los requisitos para vacantes en el conocimiento de los programas 1C, pero no querían enviarnos pruebas. Entonces obtuvimos contadores que no sabían cómo mantener registros en una computadora.

Y ahora hay un contador que recibe 30 tr. por mes, excluyendo impuestos. Y existe el costo del soporte técnico proporcionado a este contador. Por ejemplo, 20 tr por mes - los programadores son caros. Resulta que el contador le cuesta a la empresa 50 tr por mes Por ejemplo, el contador jefe adjunto cuesta la misma cantidad.

El director estaba un poco atónito por estas figuras. Una cosa es escuchar: “gastamos 50 tr. por mes para el soporte técnico de los usuarios "- está bien, es necesario. Un asunto completamente diferente: “la incompetencia de este contador nos cuesta 20 tr. por mes ". Hay menos llamadas de soporte técnico.

Inolvidable


Cuando llamamos al costo de la automatización, el cliente experimentó inconvenientes, pero solo temporales. Será regañado, tal vez escriban algo bueno y lo olviden. Recibe indulgencia y puede comenzar de nuevo.

Este enfoque no nos convenía, porque todo volvió a la situación de "los programadores son malos". Por lo tanto, actuamos simplemente: comenzamos a usar las estadísticas acumuladas de los costos de automatización.

Técnicamente, esto es simple: ya teníamos todos los datos, por clientes, departamentos y metadatos. Y comenzamos a abolir las indulgencias.

Cuando vuelve la conversación de que no estamos resolviendo ningún problema, o que alguien está mal automatizado, simplemente levantamos el informe y mostramos la cantidad acumulada. PorqueTeníamos estadísticas desglosadas por metadatos, la cantidad estaba bien dividida en dos partes: buena y mala.

Buena es la funcionalidad utilizada. Malo - sin usar. Alguien malo era el doble de bueno.

Análisis de versiones


Los sistemas de versiones en 1C y en el mismo CouchDB funcionan de la misma manera: simplemente almacenan versiones de objetos en el momento de la grabación. Algunos terminan estos sistemas; por ejemplo, no guarde versiones si nada en el objeto ha cambiado.

Nuestros usuarios, después de analizar que analizamos su trabajo, incluido el uso de versiones, comenzaron a reescribir documentos con más frecuencia. Bueno, por si acaso.

Estábamos molestos porque podría perder uno de los instrumentos de influencia y protección de sus intereses. Pero la mente del programador sugirió una solución: permítales reescribirnos todo lo que quieran, analizaremos y analizaremos las versiones en busca de cambios significativos.

Los contadores, por ejemplo, son personas astutas, pero tienen miedo de estropear la contabilidad: si reescriben un objeto, cambian algunos accesorios insignificantes, como un comentario. Formalmente, la versión es nueva, incluso si se filtra por la presencia de cambios.

Hemos agregado una entidad como ver significado. Simplemente enumeraron las propiedades de los objetos, cuyo cambio, muy probablemente, es un reflejo normal del trabajo de una persona, y no un BID. Hubo varias vistas sobre el mismo tipo de objeto. Por ejemplo, cambiar un artículo en el envío es un cambio importante. Cambiar la cuenta no es tan grave, pero sigue siendo un trabajo. Cambiar la hora de un documento dentro de una fecha, no, por desgracia, solo travesuras infantiles.

Entonces obtuvimos estadísticas de los cambios en términos de significado. Los usuarios, por supuesto, buscaron y comenzaron nuevamente DDoS'it: cambiar un atributo importante, en un minuto o un día, volver a cambiar. Ingenuo.

Después de todo, tenemos la oportunidad de comparar versiones no secuencialmente, sino, por ejemplo, la primera y la última, e ignorar los cambios intermedios. Cuando se cierra el trimestre, el documento, con una alta probabilidad, ya está en el estado objetivo, y puede compararlo con seguridad con la última versión en la fecha de creación.

Automatización de correlación y KPI


Muchos programadores, sus superiores y directores están preocupados por el impacto de la automatización en el negocio. Hay costos para programadores, proyectos completados y tareas resueltas. Y hay KPI de personas, departamentos, direcciones y sus líderes.

Se supone que la automatización debería ser beneficiosa o, como se dice en las bromas, "beneficio". Pero lo que realmente sucede generalmente no se sabe.

Basado en lo anterior, está claro que teníamos muchos números sobre automatización. Y hubo departamentos de KPI que ordenaron esta automatización. Algo se consideraba automático en el sistema, por ejemplo, las ventas. Algo se consideró manualmente, en Excel o en otro lugar. Pero había todos los KPI, que acababan de introducir algún tipo de sistema de motivación.

Nosotros, como programadores reales, en primer lugar automatizamos la contabilidad de todos los KPI. Los que no se pudieron calcular según el sistema, solo se descargaron de Excel. Tenemos todos los números que caracterizan el trabajo de los empleados y departamentos de la empresa.

De nosotros mismos agregamos un indicador más: el número de empleados en el departamento. Solo porque existe un estereotipo de este tipo: la automatización puede muy bien reducir la cantidad de personal requerido, especialmente el mantenimiento, como la contabilidad o los economistas.

Con el KPI y los costos de automatización, es muy fácil calcular la correlación, porque todos los datos se almacenan con referencia a las fechas. Por ejemplo, completamos un proyecto de automatización por valor de 200 tr. en enero - el KPI de la unidad respectiva debería cambiar. No de inmediato, sino, por ejemplo, en febrero o en marzo, o incluso en junio. Pero debe. De lo contrario, ¿cuál es el punto?

Por extraño que parezca, hubo una correlación. Por ejemplo, en el trabajo de adquisición, hemos realizado un proyecto de automatización de TOC, y sus KPI han crecido. Incluso las ventas han crecido desde eran el objetivo de la automatización de compras, al final.

Pero hubo ejemplos de la falta de correlación. Por ejemplo, la implementación de CRM no trajo nada en absoluto. Crear un sitio, en lugar del anterior, no tuvo ningún efecto.

Toda la automatización de la contabilidad solo trajo un efecto negativo, especialmente en el tamaño de su personal, a pesar de todos nuestros esfuerzos para contener este cáncer de la compañía.

Pero la automatización de los economistas contables tuvo un efecto positivo: perdimos dos empleados. No fueron despedidos, ellos mismos se fueron por sus propios motivos. Pero sugerimos: no tomemos nuevos todavía, veamos cómo funciona, automatizamos mucho allí. El director estuvo de acuerdo, y todo salió bien.

Después de la correlación calculada, la administración comenzó a mirar de manera diferente la automatización. Bueno, para programadores, por supuesto. Especialmente a la luz del hecho de que nadie nos ordenó calcular esta correlación, esta fue nuestra iniciativa.

Es cierto, entonces el director fue reemplazado, y todo tuvo que comenzar desde el principio. Pero, unos seis meses después, el nuevo director también apreció el cálculo de la correlación.

Source: https://habr.com/ru/post/es436570/


All Articles