Acerca de un chico

La historia es real, lo vi todo con mis propios ojos.

Durante varios años, un chico, como muchos de ustedes, trabajó como programador. Por las dudas, lo escribiré de esta manera: "programador". Porque él era 1Snik, una productora en apuros.

Antes de eso, probó diferentes especialidades: 4 años en Francia como programador, director de proyectos, pudo completar 200 horas y al mismo tiempo recibir un porcentaje del proyecto, para la gestión y algunas ventas. Intenté desarrollar productos por mi cuenta, fui jefe del departamento de TI en una gran empresa con 6 mil personas, probé diferentes opciones para utilizar mi profesión cotizada: programador 1C.

Pero todas estas posiciones estaban en cierto modo sin salida, principalmente en términos de ingresos. En aquella época todos recibíamos aproximadamente el mismo dinero y trabajábamos en las mismas condiciones.

Este chico se preguntaba cómo podría ganar más dinero sin vender o crear su propio negocio.

Se consideraba un tipo inteligente y decidió buscar un hueco en la empresa donde trabajaba. Este nicho tenía que ser algo especial, no ocupado por nadie. Y quería que la propia empresa quisiera pagarle dinero a una persona en este nicho, para que no hubiera necesidad de engañar a nadie ni engañar a nada. Para lograr este objetivo: una persona en esta posición necesita que le paguen mucho dinero. Un excéntrico, en una palabra.

La búsqueda duró poco. En la empresa donde trabajaba este chico había un nicho completamente libre que podría llamarse “poner las cosas en orden en los procesos de negocio”. Toda empresa tiene muchos problemas. Siempre hay algo que no funciona y no hay ninguna persona que venga y arregle el proceso comercial. Entonces decidió probarse a sí mismo como un especialista que puede ayudar al propietario a resolver sus problemas en los procesos comerciales.

En ese momento llevaba seis meses trabajando en la empresa y percibía el salario medio del mercado. No tenía nada que perder, sobre todo porque en una semana podría encontrar fácilmente el mismo trabajo. En general, este tipo decidió que no pasaría nada malo si de repente nada salía bien y lo despedían.

Se armó de valor y se acercó al dueño. Le sugerí que mejorara el proceso más problemático del negocio. En aquella época se trataba de contabilidad de almacén. Ahora todos los que trabajan en esta empresa se avergüenzan incluso de recordar estos problemas, pero los inventarios, que se realizaban trimestralmente, mostraban discrepancias entre el sistema contable y los saldos reales de decenas de por ciento. Y en costo, en cantidad y en número de puestos. Fue un desastre. De hecho, la empresa tenía los saldos correctos en el sistema contable sólo cuatro veces al año, el día después del recuento de inventario. Nuestro chico comenzó a poner en orden este proceso.

El hombre acordó con el propietario que debería reducir a la mitad las desviaciones de los resultados del inventario. Además, el propietario no tenía nada especial que perder, porque antes de nuestro héroe, varios trabajadores ya habían intentado arreglar todo y, en general, la tarea se consideraba prácticamente irresoluble. Todo esto alimentó enormemente el interés, porque si todo salía bien, entonces el tipo automáticamente se convertiría en una persona que sabría poner las cosas en orden y resolver problemas sin solución.

Entonces se le planteó la tarea de reducir las desviaciones basadas en los resultados del inventario a la mitad en un año. Al inicio del proyecto, no tenía idea de cómo lograrlo, pero entendió que la contabilidad del almacén es algo simple, por lo que aún podría hacer algo útil. Además, reducir las desviaciones de decenas de por ciento a una décima de por ciento no parece tan difícil. Cualquiera que haya trabajado en consultoría o actividades similares comprende que la mayoría de los problemas de proceso se pueden resolver con pasos bastante simples.

De enero a mayo preparó, automatizó algo un poco, reescribió el proceso comercial de contabilidad del almacén, cambió los flujos de trabajo de los tenderos, contadores y, en general, rehizo todo el sistema, sin mostrar ni decirle nada a nadie. En mayo, distribuyó nuevas instrucciones a todos y, tras el primer inventario del año, comenzó una nueva vida: trabajar según sus reglas. Para observar los resultados, en el futuro la empresa comenzó a realizar inventarios con mayor frecuencia, una vez cada dos meses. Los primeros resultados ya fueron positivos y, a finales de año, las desviaciones con respecto a los resultados de la auditoría se redujeron a una fracción del uno por ciento.

El éxito fue colosal, pero no se podía creer en su sostenibilidad. El propio chico dudaba que el resultado se conservara si se hacía a un lado y dejaba de observar el proceso. Sin embargo, hubo un resultado y el chico recibió todo lo que había acordado con el propietario. Luego, después de varios años, se confirmó la estabilidad del resultado: durante varios años las desviaciones se mantuvieron dentro del 1%.

Luego decidió repetir el experimento y sugirió al propietario mejorar otro proceso problemático: el suministro. Hubo escasez que no nos permitió enviar los volúmenes que nuestros clientes querían. Acordamos que dentro de un año los déficits se reducirían a la mitad y que el tipo también completaría entre 10 y 15 proyectos relacionados con 1C, para automatizar varios procesos comerciales y otras herejías.

En el segundo año, todo se completó nuevamente con éxito, el déficit se redujo más de 2 veces y todos los proyectos de TI se completaron con éxito.

Como el salario ya satisfacía plenamente todas las necesidades de ese chico con dos años de antelación, decidió calmarse un poco, calmarse y sentarse en un lugar acogedor y cálido que él mismo había creado.

¿Cómo fue? Formalmente, era el director de TI. Pero es difícil entender quién era realmente. Después de todo, ¿qué hace un director de TI? Por regla general, administra la infraestructura de TI, dirige a los administradores de sistemas, implementa un sistema ERP y participa en las reuniones de la junta directiva.

Y este tipo tenía una de las responsabilidades clave de participar en los procesos de cambio, y principalmente: generación, inicio de estos procesos, búsqueda y propuesta de soluciones, aplicación de nuevas técnicas de gestión, examen de los cambios propuestos, análisis de la efectividad de otras funciones y divisiones y, finalmente, participación directa en el desarrollo estratégico de la empresa, hasta el desarrollo independiente de un plan estratégico para toda la empresa.

Le dieron carta blanca. Podía acudir a cualquier reunión a la que antes no había tenido acceso. Me senté allí con una libreta, escribiendo algo o simplemente escuchando. Rara vez hablaba. Luego empezó a jugar con el teléfono, afirmando que la memoria asociativa funciona mejor de esta manera.

En la reunión rara vez daba nada útil. Se fue, pensó, luego llegó una carta, ya sea con una crítica, con una opinión, con sugerencias o con una descripción de las soluciones que ya había aplicado.

Pero más a menudo él mismo convocaba las reuniones. Encontré un problema, se me ocurrieron soluciones, identifiqué partes interesadas e invité a todos a la reunión. Y luego... lo mejor que pudo. Convenció, motivó, demostró, argumentó, logró.

Extraoficialmente, se le consideraba la tercera persona de la empresa, después del propietario y director. Por supuesto, enfureció terriblemente a todas las “personas de la empresa”, empezando por el número 4. Especialmente con sus vaqueros rotos y sus camisetas de colores vivos, y también con su época como propietario.

El dueño le daba 1 hora al día. Cada día. Conversaron, discutieron problemas, soluciones, nuevos negocios, áreas de desarrollo, indicadores y eficiencia, desarrollo personal, libros y simplemente la vida.

Pero este tipo era extraño. Es como siéntate y sé feliz, la vida es buena. Pero no. Decidió reflexionar.

Se preguntó: ¿por qué a él le funcionó y a otros no? El propietario también lo presionó: dijo que quería que otros también pudieran restablecer el orden, porque hay muchos gerentes, ellos, por regla general, se dedican a la gestión operativa y la planificación estratégica, pero prácticamente nadie se dedica a cambios sistémicos. en sus procesos. Puede que en la descripción de su trabajo esté escrito que deberían acelerar su proceso y aumentar su eficiencia, pero en realidad nadie lo está haciendo. ¿Porqué es eso? El chico también se interesó en el porqué y fue a hablar con todos estos directivos.

Se acercó al subdirector de calidad y le sugirió introducir gráficos de control de Shewhart para que los productos fueran mejores que los japoneses. Pero resultó que el colega no sabía qué eran los diagramas de control de Shewhart, qué era el control estadístico de procesos y sólo había oído hablar del uso del ciclo de Deming en la gestión de calidad. DE ACUERDO…

Se dirigió a otro subdirector y le propuso introducir el control. Pero aquí tampoco encontré apoyo. Un poco más tarde, conoció sobre la gestión de límites (boundary management) y sugirió a todos los subdirectores implementar la parte sistémica de esta metodología para mejorar los procesos. Pero por mucho que nuestro chico hablara, nadie quería profundizar en de qué se trataba. Quizás no estaban interesados ​​o era demasiado difícil. Pero, en realidad, nadie se dio cuenta.

En general habló de todo lo que sabía y utilizaba en la empresa. Pero nadie lo entendió. Todavía no entienden por qué, por ejemplo, se corrigió todo en la contabilidad de almacenes y qué tiene que ver el control y la gestión de fronteras.

Por último, llegó a sus programadores: el personal estaba formado por 3 personas. Habló de gestión de límites, de control, de gestión de calidad, de ágil y scrum... Y, sorprendentemente, entendieron todo e incluso pudieron discutir de alguna manera con él, incluidas las sutilezas técnicas y metodológicas. Entendieron por qué los proyectos de almacén y suministro funcionaron. Y entonces el chico se dio cuenta: de hecho, los programadores salvarán el mundo.

Se dio cuenta de que los programadores son los únicos que pueden comprender los procesos de negocio normalmente, con el detalle necesario.

¿Por qué ellos? De hecho, nunca encontró una respuesta clara. Sólo formulé sugerencias de tesis.

En primer lugar, los programadores conocen las áreas temáticas del negocio y las conocen mejor que el resto de personas de la empresa.

Además, los programadores realmente entienden qué es un algoritmo de proceso. Esto es importante porque los procesos de negocio son algoritmos y es posible que los elementos que contienen simplemente no sean consistentes. Por ejemplo, en el proceso de adquisiciones en el que estaba trabajando el chico, el primer paso era crear un plan de compras anual y el segundo eran compras diarias. Estos pasos están conectados por una conexión directa, es decir, se supone que las personas deben trabajar de acuerdo con este algoritmo: elaborar un plan de adquisiciones anual y ejecutar inmediatamente la solicitud. El plan de adquisiciones anual se elabora una vez al año y las solicitudes se reciben 50 veces al día. Aquí es donde termina el algoritmo y hay que trabajar en ello. De hecho, razonó, para los programadores el conocimiento de los algoritmos es una ventaja competitiva, porque cualquiera que no esté familiarizado con ellos simplemente no entiende cómo debería funcionar un proceso de negocio y cómo se puede representar.

Otra ventaja de los programadores, según el chico, es que tienen suficiente tiempo libre. Todos entendemos cómo un programador puede dedicar a una tarea tres veces más tiempo del que realmente requiere, y pocos lo notarán. Esto, nuevamente, es una ventaja competitiva, porque para poner en orden algún proceso comercial, es necesario tener mucho tiempo libre: pensar, observar, estudiar e intentar.

La mayoría de los directivos, según el chico, no tienen ese tiempo libre y están orgullosos de ello. Aunque en realidad esto significa que una persona no puede volverse eficaz porque no tiene tiempo para mejorar la eficiencia: un círculo vicioso. En nuestra cultura está de moda estar ocupado, por eso todo sigue igual. Y para nosotros los programadores, esto es una ventaja. Podemos encontrar tiempo libre y pensar en todo.

Los programadores, afirmó, pueden cambiar rápidamente un sistema de información. Esto no es aplicable en todas las empresas, pero dondequiera que trabajara, podía hacer las modificaciones que quisiera. Especialmente si no se refieren al trabajo de nadie más. Por ejemplo, podría lanzar un sistema que mediría en secreto las acciones de los usuarios y luego usaría esta información para analizar la eficiencia del mismo departamento de contabilidad y realizar un seguimiento del costo de la contabilidad.

Y lo último que recuerdo de sus palabras es que los programadores tienen acceso a una gran cantidad de información, porque... tener acceso administrativo al sistema. Por lo tanto, pueden utilizar esta información en su análisis. Nadie más en una planta normal tiene ese recurso.

Y luego se fue. Durante las dos semanas de detención requeridas, lo obligamos a compartir su experiencia porque queríamos continuar el trabajo que estaba haciendo. Bueno, su puesto quedó vacante.

Durante varios días lo sentaron en una silla, encendieron la cámara y grabaron sus monólogos. Pidieron que nos informaran sobre todos los proyectos completados, métodos, enfoques, éxitos y fracasos, causas y efectos, retratos de gerentes, etc. No hubo restricciones especiales, porque No sabían lo que estaba pasando por su cabeza.

Los monólogos, por supuesto, eran en su mayoría tonterías y risas; él estaba de muy buen humor, porque Estaba saliendo del interior hacia San Petersburgo. ¿Dónde deberías ir a trabajar en San Petersburgo? A Gazprom, por supuesto.

Pero logramos extraer algo útil de sus monólogos. Te diré lo que recuerdo.

Entonces, las recomendaciones de ese tipo. Para aquellos que quieran intentar poner las cosas en orden en los procesos de negocio.

Para realizar este tipo de trabajo, en primer lugar, es necesario tener un cierto nivel de "congelación". No debe tener miedo de perder su trabajo, no tener miedo de correr riesgos, no tener miedo de los conflictos con los compañeros. Fue fácil para él, porque comenzó su andadura cuando llevaba sólo seis meses trabajando en la empresa, y no tenía tiempo de entrar en contacto con nadie, ni tenía intención de hacerlo. Entendió que la gente va y viene, pero para él son importantes sus propios resultados y la valoración que haga el empresario. En aquel entonces, le importaba poco si sus colegas lo trataban bien o mal.

El segundo punto es que, lamentablemente, para realizar este trabajo de forma eficaz, tendrás que estudiar. Pero no estudies en un MBA, ni en cursos, ni en institutos, sino por tu cuenta. Por ejemplo, en su primer proyecto, un proyecto de almacén, actuó de forma intuitiva, no sabía nada, sólo qué era la “gestión de calidad”.

Cuando comenzó a leer literatura sobre los métodos que existían para aumentar la eficiencia, descubrió las tecnologías que utilizaba. El chico los aplicó intuitivamente, pero resulta que este no fue su invento, todo ya estaba escrito hace mucho tiempo. Pero dedicó tiempo, y mucho más que si hubiera leído inmediatamente el libro adecuado. Aquí solo es importante comprender que cuando se estudia una técnica específica, ninguna de ellas, ni siquiera la más avanzada, resolverá por completo todos los problemas de un proceso empresarial.

El segundo truco es que cuantas más técnicas conozcas, mejor. Por ejemplo, en el antiguo Japón vivió Miyamoto Musashi, uno de los espadachines más famosos, autor del estilo de dos espadas. Estudió en alguna escuela con algún maestro, luego viajó por Japón, peleó con diferentes tipos. Si el chico era más fuerte, entonces el viaje se detenía por un tiempo y Musashi se convertía en estudiante. Como resultado, durante varios años adquirió las habilidades de diversas prácticas de diferentes maestros y formó su propia escuela, añadiendo algo propio. Como resultado, logró una habilidad única. Es lo mismo aqui.

Por supuesto, puede actuar como consultor empresarial. En general, son grandes chicos. Pero, por regla general, vienen a introducir algún tipo de metodología e implementan la metodología incorrecta que el negocio necesita. También hemos tenido situaciones muy tristes: nadie sabe cómo solucionar el problema y nadie quiere pensar en cómo solucionarlo. Empezamos a buscar en Internet o llamamos a un consultor y le preguntamos qué puede ayudarnos. El consultor piensa y dice que necesitamos introducir la teoría de las restricciones. Le pagamos por su recomendación, gastamos dinero en la implementación, pero los resultados son cero.

¿Por qué pasó esto? Porque el consultor dijo, estamos introduciendo tal o cual sistema, y ​​todos estuvieron de acuerdo con él. Genial, pero una metodología no cubre todos los problemas de ni siquiera un proceso de negocio, especialmente si los requisitos previos iniciales, los nuestros y los necesarios para implementar la metodología, no coinciden.

En la práctica que recomienda el chico, debes tomar lo mejor e implementar lo mejor. No tome los métodos en su totalidad, sino sus características, funciones y prácticas clave. Y lo más importante es entender la esencia.

Tomemos, dijo, por ejemplo, Scrum o Agile. En sus monólogos, el chico repitió muchas veces que no todos comprenden completamente la esencia de Scrum. También leyó el libro de Jeff Sutherland, que algunas personas consideran una "lectura ligera". Le pareció una lectura profunda, porque uno de los principios fundamentales de Scrum es la gestión de la calidad, esto está escrito directamente en el libro.

Habla de la producción de Toyota, de cómo Jeff Sutherland mostró Scrum en Japón, de cómo se arraigó allí y de lo cerca que estaba de su filosofía. Y Sutherland habló de la importancia del papel del Scrum Master, del ciclo de Deming. El papel del Scrum Master es acelerar constantemente el proceso. Todo lo demás que está en Scrum (entrega por fases, satisfacción del cliente, una lista clara de trabajo para el período de sprint) también es importante, pero todo esto debe avanzar cada vez más rápido. La velocidad del trabajo debe aumentar constantemente en las unidades en que se mide.

Quizás sea una cuestión de traducción, porque nuestro libro fue traducido como "Scrum - un método revolucionario de gestión de proyectos", y si el título en inglés se traduce literalmente, resultará: "Scrum - el doble en la mitad del tiempo". , es decir, incluso en El nombre hace referencia a la velocidad como una función clave de Scrum.

Cuando este chico implementó Scrum, la velocidad se duplicó en el primer mes sin cambios significativos. Encontró puntos de cambio y modificó el propio Scrum para que funcionara mucho más rápido. Lo único que escriben en Internet es que se enfrentaron a la pregunta: "Hemos duplicado la velocidad, solo queda entender qué estamos haciendo a esa velocidad". Sin embargo, esta es un área completamente diferente...

También recomendó personalmente varias técnicas. Los llamó fundamentales y fundamentales.

El primero es la gestión de límites.

Lo enseñan en Skolkovo; según el chico, no hay otros libros ni materiales. De alguna manera tuvo la suerte de asistir a una conferencia de un profesor de Harvard que predica la gestión de límites, y también leyó varios artículos en Harvard Business Review sobre el trabajo de Eric Trist.

La gestión de límites dice que es necesario poder ver los límites y trabajar con ellos. Hay muchos límites, están en todas partes: entre departamentos, entre diferentes tipos de trabajo, entre funciones, entre trabajo operativo y analítico. El conocimiento de la gestión de límites no revela verdades superiores, pero nos permite ver la realidad bajo una luz ligeramente diferente: a través del prisma de los límites. Y, en consecuencia, gestionarlos: levantarlos cuando sea necesario y eliminarlos cuando estorben.

Pero la mayoría de las veces el chico hablaba de controlar. Simplemente tenía algún tipo de peculiaridad sobre este tema.

Controlar, en definitiva, es gestionar con números. Aquí, dijo, cada parte de la definición es importante, tanto "gestión" como "basada en" y "números".

Nosotros, dijo, somos malos con los tres componentes del control. Sobre todo teniendo en cuenta que están estrechamente interconectados tanto entre sí como con otras partes del sistema empresarial.

Lo primero que es malo son los números. Hay pocos y son de baja calidad.

Luego tomamos una parte importante de los números del sistema de información 1C. Por lo tanto, la calidad de los números en 1C, como afirmó, no es buena. Como mínimo, debido a la capacidad de cambiar datos retroactivamente.

Está claro que esto no es culpa de los desarrolladores de 1C: solo tienen en cuenta los requisitos del mercado y la mentalidad de la contabilidad nacional. Pero para fines de control, es mejor cambiar los principios del trabajo de 1C con datos en una empresa específica.

Además, los números de 1C, según él, se procesan semimanualmente, utilizando Excel, por ejemplo. Este procesamiento tampoco añade calidad a los datos ni eficiencia.

Al final, alguien más vuelve a verificar el informe final para no enviar accidentalmente cifras con errores al gerente. Como resultado, los números llegan al destinatario hermosos, verificados, pero muy tarde. Generalmente, después del final del período (mes, semana, etc.).

Y aquí, dijo, todo es muy sencillo. Si los números de enero le llegaron en febrero, entonces ya no podrá gestionar las actividades de enero. Porque enero ya se acabó.

Y si las cifras se basan en contabilidad y la empresa es la más normal, con presentación trimestral del IVA, entonces su director recibe cifras relativamente adecuadas una vez por trimestre.

El resto está claro. Recibe números una vez al mes; tiene la oportunidad de administrar por números (es decir, controlar) 12 veces al año. Si practica informes trimestrales, los gestionará 4 veces al año. Más una bonificación: informes anuales. Conduce una vez más.

El resto del tiempo el control suele realizarse a ciegas.

Cuando (y si) aparecen los números, entonces entra en juego el segundo problema: ¿cómo gestionar en función de los números? No puedo estar de acuerdo con este punto de su razonamiento.

El hombre argumentó que si el gerente no tenía los números antes, entonces su apariencia causaría un efecto sorpresa. Mirará y distorsionará los números de un lado a otro, llamará a la gente en la alfombra, exigirá explicaciones e investigaciones. Después de jugar con números, realizar análisis y prometer amenazadoramente a todos los empleados que "ahora no me desharé de ustedes", el gerente se calmará muy rápidamente y se dará por vencido en este asunto. Deja de usar la herramienta. Pero los problemas seguirán ahí.

Esto se debe, dijo, a una falta de competencias de gestión. En el control, ante todo. El gerente simplemente no sabe qué hacer con estos números. Qué сhacer - sabe qué hacer - no. Hacer es lo que está escrito arriba (pelear, jugar). Hacer es un proceso empresarial diario.

Sostuvo que todo es muy sencillo: lo digital debe pasar a formar parte del proceso empresarial. En el proceso de negocio debe quedar claramente claro: quién debe hacer qué y cuándo, si las cifras se desvían de la norma (cualquier opción: por encima de la frontera, por debajo de la frontera, yendo más allá del corredor, la presencia de una tendencia, el incumplimiento de los cuantil, etc.)

Y así planteó el dilema clave: el número existe, debería formar parte del sistema empresarial para aumentar la eficiencia de la gestión, pero... esto no está sucediendo. ¿Por qué?

Porque el líder ruso no cederá ni una parte de su poder a un competidor.

Los competidores del gerente ruso (un proceso de negocios funcional y de alta calidad, una motivación bien pensada y mutuamente beneficiosa y una automatización adecuada) lamentablemente dejarán al gerente sin trabajo.

Una especie de tontería, ¿no estás de acuerdo? Especialmente sobre los líderes. Está bien, te lo dije, tú decides por ti mismo.

Un poco menos, pero demasiado, en mi opinión, habló de Scrum.

Asegúrate, dije, lee y prueba Scrum en la práctica. Si, dice, lo has leído pero no lo has probado, considérate un ignorante. Es mejor leer un libro, por ejemplo de Sutherland, que artículos y todo tipo de guías (¿qué diablos?) en Internet.

Scrum, dijo, sólo se puede aprender a través de la práctica y con mediciones obligatorias de la cantidad de trabajo realizado. Pruebe personalmente los dos roles más importantes: Product Owner y Scrum Master.

Es especialmente importante, según el chico, experimentar en la práctica el papel de Scrum Master, cuando se puede aumentar el volumen de tareas realizadas por sprint sin aumentar los recursos y el coste del sprint.

Bueno, en su cima estaba TOS (teoría de las limitaciones del sistema).

Estos, según el hombre, son los principios básicos y fundamentales para aumentar la eficiencia, que se pueden aplicar en casi cualquier área, en cualquier proceso de negocio y sistema de negocio en su conjunto.

Cuando descubrió que no estábamos familiarizados con TOS, dejó de decírnoslo. Sólo añadió que no nos privaría del placer de leer los libros de Eliyahu Goldratt. Le dio una recomendación similar a Scrum: léelo y pruébalo. Por ejemplo, no importa en qué posición se encuentre, no importa qué trabajo haga, hay un lugar para aumentar la eficiencia utilizando métodos TOC.

Entonces su bolsa de técnicas aparentemente se agotó y dijo: mezcle los principios para crear soluciones aplicadas en una situación específica.

Ésta, afirma, es la principal recomendación, la clave del éxito. Comprender los principios, la esencia y crear soluciones de aplicaciones únicas: procesos y sistemas comerciales.

Luego intentó recordar alguna cita y al final tuvo que conectarse. Resultó ser una cita del artículo “De pie sobre hombros de gigantes” de Eliyahu Goldratt:

“Existe una diferencia entre las soluciones aplicadas (aplicaciones) y los conceptos fundamentales en los que se basan esas soluciones. Los conceptos son generales; las soluciones aplicadas son la adaptación de conceptos a un entorno específico. Como ya hemos visto, dicha adaptación no es sencilla y requiere el desarrollo de ciertos elementos de la solución. Debemos recordar que la solución de una aplicación se basa en suposiciones iniciales (a veces ocultas) sobre un entorno específico. No se debe esperar que esta solución de aplicación funcione en un entorno en el que las suposiciones no son correctas”.

Dijo que el trabajo de un programador y el de un “mejorador de procesos de negocio” son muy similares. E izquierda.

Fuente: habr.com