A historia é real, vin todo cos meus propios ollos.
Durante varios anos, un rapaz, como moitos de vós, traballou como programador. Por se acaso, escribirei deste xeito: "programador". Porque era 1Snik, nunha empresa de produción.
Antes diso, probou diferentes especialidades: 4 anos en Francia como programador, xefe de proxectos, puido completar 200 horas, ao mesmo tempo que recibía unha porcentaxe do proxecto, para a xestión e facer un pouco de vendas. Tente desenvolver produtos pola miña conta, era o xefe do departamento de TI nunha gran empresa con 6 mil persoas, probei diferentes opcións para usar a miña profesión cotizada: programador 1C.
Pero todas estas posicións estaban un pouco sen saída, principalmente en termos de ingresos. Daquela, todos recibíamos aproximadamente o mesmo diñeiro e traballabamos nas mesmas condicións.
Este rapaz preguntábase como podería gañar máis cartos sen vender nin crear o seu propio negocio.
Considerouse un tipo intelixente e decidiu buscar un oco na empresa na que traballaba. Este nicho tiña que ser algo especial, non ocupado por ninguén. E quería que a propia empresa quixese pagar diñeiro a unha persoa neste nicho, para que non houbese necesidade de enganar a ninguén nin enganar nada. Para conseguir este obxectivo: unha persoa neste posto ten que pagar moito diñeiro. Un excéntrico, nunha palabra.
A procura foi de curta duración. Na empresa onde traballaba este tipo, había un nicho completamente gratuíto que se podería chamar "ordenar as cousas nos procesos comerciais". Toda empresa ten moitos problemas. Algo sempre non funciona, e non hai ningunha persoa que veña arranxar o proceso empresarial. Entón, decidiu probarse como un especialista que pode axudar ao propietario a resolver os seus problemas nos procesos comerciais.
Daquela levaba seis meses traballando na empresa e cobraba o salario medio do mercado. Non había nada que perder, sobre todo porque podía atopar facilmente o mesmo traballo nunha semana. En xeral, este mozo decidiu que non pasaría nada malo se de súpeto nada funcionaba e era despedido.
Colleu coraxe e chegou ao propietario. Suxerín que mellorase o proceso máis problemático do negocio. Daquela era a contabilidade de almacén. Agora todos os que traballan nesta empresa teñen ata vergoña de lembrar eses problemas, pero os inventarios, que se realizaban trimestralmente, mostraban discrepancias entre o sistema contable e os saldos reais de decenas de por cento. E en custo, e en cantidade, e no número de postos. Foi un desastre. En realidade, a empresa tiña os saldos correctos no sistema contable só catro veces ao ano, o día seguinte ao reconto de inventario. O noso mozo comezou a poñer en orde este proceso.
O mozo acordou co propietario que debería reducir á metade as desviacións dos resultados do inventario. Ademais, o propietario non tiña nada especial que perder, porque antes do noso heroe, varios traballadores xa intentaran arranxar todo e, en xeral, a tarefa considerábase practicamente irresoluble. Todo isto alimentou moito o interese, porque se todo funcionase, entón o tipo converteríase automaticamente nunha persoa que sabe ordenar as cousas e resolver problemas irresolubles.
Entón, enfróntase á tarefa: reducir as desviacións en función dos resultados do inventario 2 veces nun ano. Ao comezo do proxecto, non tiña idea de como logralo, pero entendía que a contabilidade do almacén é unha cousa sinxela, polo que aínda podería facer algo útil. Ademais, reducir as desviacións de decenas de por cento a unha decenas de por cento non parece ser tan difícil. Calquera persoa que teña traballado en actividades de consultoría ou similares entende que a maioría dos problemas de proceso pódense resolver con pasos bastante sinxelos.
De xaneiro a maio, preparou, automatizou un pouco algo, reescribiu o proceso comercial da contabilidade do almacén, cambiou os fluxos de traballo dos almacenistas, dos contadores e, en xeral, refixo todo o sistema, sen amosar nin dicir nada a ninguén. En maio, distribuíu novas instrucións para todos e, despois do primeiro inventario do ano, comezou unha nova vida: traballando segundo as súas regras. Para observar os resultados, no futuro a empresa comezou a realizar inventarios con máis frecuencia, unha vez cada dous meses. Os primeiros resultados xa eran positivos e, a finais de ano, as desviacións dos resultados da auditoría caeron a unha fracción do un por cento.
O éxito foi colosal, pero non se podía crer na súa sustentabilidade. O propio mozo dubidaba de que o resultado se conservase se facía un lado e deixaba de observar o proceso. Non obstante, houbo un resultado e o mozo recibiu todo o que acordaba co propietario. Despois, despois de varios anos, confirmouse a estabilidade do resultado: durante varios anos as desviacións mantivéronse dentro do 1%.
Entón decidiu repetir o experimento e suxeriu que o propietario mellorase outro proceso problemático: a subministración. Houbo carencias que non nos permitían enviar os volumes que querían os nosos clientes. Acordamos que dentro dun ano os déficits reduciríanse á metade e o tipo tamén completaría 10-15 proxectos relacionados con 1C, para automatizar varios procesos comerciais e outras herexías.
No segundo ano, todo volveu completarse con éxito, os déficits diminuíron máis de 2 veces, todos os proxectos de TI completáronse con éxito.
Dado que o salario xa satisfacía por completo todas as necesidades daquel tipo con dous anos de antelación, decidiu acomodarse un pouco, acougarse e sentarse nun lugar acolledor e cálido que el mesmo creara.
Como foi? Formalmente, era o director de TI. Pero quen era realmente é difícil de entender. Despois de todo, que fai un director de TI? Por norma xeral, administra a infraestrutura informática, xestiona os administradores do sistema, implementa un sistema ERP e participa nas reunións do consello de administración.
E este tipo tiña unha das principais responsabilidades para participar nos procesos de cambio, e principalmente - xeración, inicio destes procesos, busca e proposta de solucións, aplicación de novas técnicas de xestión, exame dos cambios propostos, análise da eficacia doutras funcións e divisións e, finalmente, a participación directa no desenvolvemento estratéxico da empresa, ata o desenvolvemento independente dun plan estratéxico para toda a empresa.
Déuselle carta branca. Podería acudir a calquera reunión á que antes non tivese acceso. Sentei alí cun bloc de notas, anotando algo ou simplemente escoitando. Raramente falaba. Entón comezou a xogar no teléfono, alegando que a memoria asociativa funciona mellor deste xeito.
Na reunión raramente deu nada útil. Marchou, pensou, logo chegou unha carta, ben con críticas, ou con opinión, ou con suxestións, ou cunha descrición das solucións que xa aplicara.
Pero máis veces convocaba reunións el mesmo. Atopei un problema, atopei solucións, identificei as partes interesadas e acheguei a todos á reunión. E entón - como puido. Convenceu, motivou, demostrou, argumentou, conseguiu.
Extraoficialmente, era considerado a terceira persoa da empresa, despois do propietario e director. Por suposto, enfureceu terriblemente a todas as "persoas da empresa", comezando polo número 4. Sobre todo cos seus vaqueiros rotos e camisetas brillantes, e tamén co seu tempo como propietario.
O propietario dáballe 1 hora ao día. Tódolos días. Falaron, discutiron problemas, solucións, novos negocios, áreas de desenvolvemento, indicadores e eficiencia, desenvolvemento persoal, libros e simplemente a vida.
Pero este tipo era raro. É como, senta e sé feliz, a vida é boa. Pero non. Decidiu reflexionar.
Preguntouse: por que lle resultou, pero outros non? O propietario tamén o impulsou: dixo que quería que outros tamén puidesen restaurar a orde, porque hai moitos xestores, eles, por regra xeral, dedícanse á xestión operativa e á planificación estratéxica, pero practicamente ninguén se dedica a cambios sistémicos. nos seus procesos. Pode estar escrito na súa descrición do traballo que deberían acelerar o seu proceso e aumentar a súa eficiencia, pero de feito ninguén o fai. Por que é iso? O tipo tamén se interesou polo porqué e foi falar con todos estes xestores.
Chegou ao subdirector para a calidade e suxeriu a introdución de gráficos de control de Shewhart para que os produtos fosen mellores que os xaponeses. Pero resultou que o colega descoñecía o que eran os gráficos de control de Shewhart, o que era o control estatístico dos procesos e só escoitou falar do uso do ciclo Deming na xestión da calidade. OK…
Foi a outro subdirector e suxeriu introducir o control. Pero aquí tampouco atopei apoio. Un pouco máis tarde, coñeceu a xestión de límites (xestion de límites) e suxeriu que todos os subdirectores implementen a parte sistémica desta metodoloxía para mellorar os procesos. Pero por moito que falase o noso rapaz, ninguén quería profundar de que se trataba. Quizais non lles interesaba ou era moi difícil. Pero, de feito, ninguén o descubriu.
En xeral, falou de todo o que coñecía e utilizaba na empresa. Pero ninguén o entendía. Aínda non entenden por que, por exemplo, se corrixiu todo na contabilidade de almacén, e que ten que ver o control e a xestión de fronteiras.
Por último, chegou aos seus programadores: o persoal incluía 3 persoas. Falou de xestión de límites, de control, de xestión de calidade, de áxil e scrum... E, sorprendentemente, entendérono todo, e mesmo puideron discutir dalgún xeito con el, incluíndo sutilezas técnicas e metodolóxicas. Entenderon por que funcionaron os proxectos de almacén e abastecemento. E entón entendeu o tipo: de feito, os programadores salvarán o mundo.
Os programadores, deuse conta, son os únicos que poden entender os procesos empresariais con normalidade, co detalle necesario.
Por que eles? De feito, nunca atopou unha resposta clara. Formulei só suxestións de tese.
En primeiro lugar, os programadores coñecen as áreas temáticas do negocio e coñécenas mellor que todas as demais persoas da empresa.
Ademais, os programadores realmente entenden o que é un algoritmo de proceso. Isto é importante porque os procesos de negocio son algoritmos e os elementos neles poden simplemente non ser consistentes. Por exemplo, no proceso de adquisición no que estaba a traballar o mozo, o primeiro paso foi crear un plan de compras anual e o segundo a compra diaria. Estes pasos están conectados por unha conexión directa, é dicir, asúmese que as persoas deben traballar segundo este algoritmo: elabore un plan de compras anual e execute inmediatamente a solicitude. O plan de contratación anual elabórase unha vez ao ano e as solicitudes recíbense 50 veces ao día. Aquí é onde remata o algoritmo e cómpre traballar nel. De feito, razoou, para os programadores, o coñecemento dos algoritmos é unha vantaxe competitiva, porque calquera outra persoa que non estea familiarizada con eles simplemente non entende como debe funcionar un proceso empresarial e como se pode representar.
Outra vantaxe dos programadores, segundo o mozo, é que teñen tempo libre suficiente. Todos entendemos como un programador pode gastar tres veces máis nunha tarefa do que realmente require, e poucos o notarán. Esta, de novo, é unha vantaxe competitiva, porque para ordenar algún proceso empresarial, cómpre ter moito tempo libre: pensar, observar, estudar e probar.
A maioría dos directivos, segundo o mozo, non teñen este tempo libre e están orgullosos del. Aínda que de feito isto significa que unha persoa non pode facerse efectiva porque non ten tempo para mellorar a eficiencia - un círculo vicioso. Na nosa cultura, está de moda estar ocupado, polo que todo segue igual. E para nós, os programadores, esta é unha vantaxe. Podemos atopar tempo libre e pensar en todo.
Os programadores, dixo, poden cambiar rapidamente un sistema de información. Isto non é aplicable en todas as empresas, pero onde traballaba, podía facer as modificacións que quixese. Sobre todo se non se refiren ao traballo de ninguén. Por exemplo, podería lanzar un sistema que mide en segredo as accións dos usuarios e, a continuación, utiliza esta información para analizar a eficiencia do mesmo departamento de contabilidade e facer un seguimento do custo da contabilidade.
E o último que recordo das súas palabras é que os programadores teñen acceso a unha gran cantidade de información, porque... ter acceso administrativo ao sistema. Polo tanto, poden utilizar esta información na súa análise. Ninguén máis nunha planta normal ten tal recurso.
E entón marchou. Durante a obrigada detención de dúas semanas, obrigámolo a compartir a súa experiencia porque queriamos continuar co traballo que estaba a facer. Ben, o seu posto quedou vacante.
Ao longo de varios días, sentárono nunha cadeira, prenderon a cámara e gravaron os seus monólogos. Pedíronnos falar de todos os proxectos rematados, métodos, enfoques, éxitos e fracasos, causas e efectos, retratos de xestores, etc. Non había restricións especiais, porque Non sabían o que estaba a pasar na súa cabeza.
Os monólogos, por suposto, eran na súa maioría tonterías e risas: estaba de moi bo humor, porque saía do interior para San Petersburgo. Onde deberías ir traballar en San Petersburgo? A Gazprom, claro.
Pero conseguimos extraer algo útil dos seus monólogos. Vouche contar o que recordo.
Entón, recomendacións dese tipo. Para os que queren tentar poñer orde nos procesos empresariais.
Para facer este tipo de traballo, en primeiro lugar, cómpre ter un certo nivel de "conxelación". Non debes ter medo a perder o teu traballo, non ter medo a arriscar, non ter medo aos conflitos cos compañeiros. Foi doado para el, porque comezou a súa andaina cando levaba só seis meses traballando na empresa, e non tiña tempo de entrar en contacto con ninguén, e non tiña intención de facelo. El entendía que a xente vai e vén, pero os seus propios resultados e a súa valoración por parte do empresario son importantes para el. Que os seus compañeiros o trataran ben ou mal non lle preocupaba entón.
O segundo punto é que para realizar este traballo de forma eficaz, por desgraza, terás que estudar. Pero estuda non para un MBA, nin en cursos, nin en institutos, senón pola túa conta. Por exemplo, no seu primeiro proxecto, para un almacén, actuou de forma intuitiva, non sabía nada, só o que era a “xestión da calidade”.
Cando comezou a ler a literatura sobre os métodos que existían para aumentar a eficiencia, descubriu as tecnoloxías que utilizaba. O mozo aplicounos intuitivamente, pero resulta que este non era o seu invento, xa estaba todo escrito hai moito tempo. Pero pasou tempo, e moito máis que se tivese lido inmediatamente o libro correcto. Aquí só é importante entender que cando estudas unha técnica específica, ningunha delas, nin sequera a máis avanzada, resolverá por completo todos os problemas dun proceso empresarial.
O segundo truco é que cantas máis técnicas coñezas, mellor. Por exemplo, no antigo Xapón vivía Miyamoto Musashi, un dos espadachíns máis famosos, o autor do estilo de dúas espadas. Estudou nalgunha escola con algún mestre, despois viaxou por Xapón, loitou con distintos tipos. Se o mozo era máis forte, entón a viaxe detívose durante algún tempo e Musashi converteuse nun estudante. Como resultado, ao longo de varios anos adquiriu as habilidades de varias prácticas de diferentes mestres e formou a súa propia escola, engadindo algo propio. Como resultado, acadou unha habilidade única. Aquí pasa o mesmo.
Por suposto, pode actuar como consultor de empresas. En xeral, son grandes rapaces. Pero, por regra xeral, veñen a introducir algún tipo de metodoloxía e implementan a metodoloxía incorrecta que o negocio necesita. Tamén tivemos situacións tan tristes: ninguén sabe como resolver o problema e ninguén quere pensar como solucionalo. Comezamos a buscar ben en Internet ou chamamos a un consultor e pregúntalle que nos pode axudar. O consultor pensa e di que hai que introducir a teoría das restricións. Pagámoslle a súa recomendación, gastamos cartos na implementación, pero os resultados son cero.
Por que ocorre isto? Porque dixo o consultor, estamos introducindo tal ou cal sistema, e todos estaban de acordo con el. Xenial, pero unha metodoloxía non abarca todos os problemas dun mesmo proceso empresarial, especialmente se os requisitos previos iniciais -os nosos e os necesarios para implementar a metodoloxía- non coinciden.
Na práctica que o rapaz recomenda, cómpre tomar o mellor e implementar o mellor. Non tome os métodos por completo, senón que tome as súas principais características, características e prácticas. E o máis importante é entender a esencia.
Tomemos, dixo, por exemplo, Scrum ou Agile. Nos seus monólogos, o mozo repetiu moitas veces que non todos entenden completamente a esencia de Scrum. Tamén leu o libro de Jeff Sutherland, que algunhas persoas consideran "lectura lixeira". Pareceume unha lectura profunda, porque un dos principios fundamentais de Scrum é a xestión da calidade, isto está escrito directamente no libro.
Conta sobre Toyota Production, sobre como Jeff Sutherland mostrou Scrum en Xapón, como se arraigou alí e o preto que estaba da súa filosofía. E Sutherland falou da importancia do papel do Scrum Master, sobre o ciclo Deming. O papel do Scrum Master é acelerar constantemente o proceso. Todo o demais que está en Scrum -entrega por fases, satisfacción do cliente, unha lista clara de traballo para o período de sprint- tamén é importante, pero todo isto debe avanzar cada vez máis rápido. A velocidade de traballo debe aumentar constantemente nas unidades nas que se mide.
Quizais sexa unha cuestión de tradución, porque o noso libro foi traducido como "Scrum - un método revolucionario de xestión de proxectos", e se o título en inglés se traduce literalmente, resultará: "Scrum - o dobre na metade do tempo" , é dicir, mesmo en O nome fai referencia á velocidade como función clave de Scrum.
Cando este tipo implementou Scrum, a velocidade duplicouse no primeiro mes sen cambios significativos. Atopou puntos para cambiar e modificou o propio Scrum para facelo funcionar moito máis rápido. O único que escriben en Internet é que se enfrontaron á pregunta: "Dplicamos a velocidade, só queda entender que estamos facendo a tal velocidade?" Non obstante, esta é unha área completamente diferente...
Tamén recomendou persoalmente varias técnicas. Chamounas fundamentais e fundamentais.
O primeiro é a xestión dos límites.
Ensinano en Skolkovo; segundo o tipo, non hai outros libros e materiais. Dalgunha maneira tivo a sorte de asistir a unha conferencia dun profesor de Harvard que predica a xestión de límites, e tamén leu varios artigos na Harvard Business Review sobre o traballo de Eric Trist.
A xestión de límites di que debes poder ver os límites e traballar con límites. Hai límites abondo, están en todas partes: entre departamentos, entre diferentes tipos de traballo, entre funcións, entre o traballo operativo e o analítico. O coñecemento da xestión de límites non revela verdades superiores, pero permítenos ver a realidade nunha luz lixeiramente diferente, a través do prisma dos límites. E, en consecuencia, xestione-los: érgueos onde sexa necesario e retíreos onde estean no camiño.
Pero a maioría das veces o mozo falaba de controlar. Só tiña algún tipo de peculiaridade sobre este tema.
Controlar, en definitiva, é unha xestión baseada en números. Aquí, dixo, cada parte da definición é importante: tanto a "xestión" como a "baseada en" e os "números".
Nós, dixo, somos malos cos tres compoñentes do control. Sobre todo tendo en conta que están estreitamente interconectados entre si e con outras partes do sistema empresarial.
O primeiro que está mal son os números. Hai poucos e son de baixa calidade.
Despois collemos unha parte importante dos números do sistema de información 1C. Entón, a calidade dos números en 1C, como afirmou, non é boa. Como mínimo, debido á posibilidade de cambiar os datos de forma retroactiva.
Está claro que esta non é culpa dos desenvolvedores de 1C: só teñen en conta os requisitos do mercado e a mentalidade da contabilidade doméstica. Pero para fins de control, é mellor cambiar os principios do traballo 1C con datos nunha empresa específica.
Ademais, os números de 1C, segundo el, sofren un procesamento semimanual, usando Excel, por exemplo. Tal procesamento tampouco engade calidade aos datos, así como eficiencia.
Ao final, outra persoa revisa o informe final para non enviar accidentalmente cifras con erros ao xestor. Como resultado, os números chegan ao destinatario fermosos, verificados, pero moi tarde. Normalmente - despois do final do período (mes, semana, etc.).
E aquí, dixo, todo é moi sinxelo. Se os números sobre xaneiro chegáronche en febreiro, xa non podes xestionar as actividades de xaneiro. Porque xaneiro xa rematou.
E se as cifras están baseadas na contabilidade, e a empresa é a máis común, con presentación trimestral do IVE, entón o seu xestor recibe unhas cifras relativamente adecuadas unha vez ao trimestre.
O resto está claro. Recibes números unha vez ao mes; tes a oportunidade de xestionalos por números (é dicir, controlar) 12 veces ao ano. Se practicas a elaboración de informes trimestrais, xestionalo 4 veces ao ano. Ademais dunha bonificación: informes anuais. Dirixe unha vez máis.
O resto do tempo, o control adoita realizarse a cegas.
Cando (e se) aparecen os números, entra en xogo o segundo problema: como xestionalos en función dos números? Non podería estar de acordo con este punto do seu razoamento.
O tipo argumentou que se o director non tivese os números antes, entón a súa aparición provocaría un efecto sorpresa. Mirará e retorcerá os números dun lado a outro, chamará á xente na alfombra, esixirá explicacións e investigacións. Despois de xogar cos números, realizar análises e prometer ameazadamente a todos os empregados que "agora non me vou librar de ti", o xerente calmarase moi rapidamente e renunciará a este asunto. Deixa de usar a ferramenta. Pero os problemas seguirán no seu lugar.
Isto ocorre, dixo, por falta de competencias directivas. En controlar, en primeiro lugar. O director simplemente non sabe que facer con estes números. Que сfacer - sabe que facer - non. Facer é o que se escribe arriba (rifar, xogar). Facer é un proceso empresarial diario.
Defendeu que todo é moi sinxelo: o dixital debe pasar a formar parte do proceso empresarial. No proceso de negocio debe quedar claramente claro: quen debe facer que e cando se os números se desvían da norma (calquera opción - por riba da fronteira, por debaixo da fronteira, máis alá do corredor, a presenza dunha tendencia, o incumprimento da norma). cuantil, etc.)
E por iso expuxo o dilema fundamental: o número existe, debería pasar a formar parte do sistema empresarial para aumentar a eficiencia da xestión, pero... isto non está a suceder. Por que?
Porque o líder ruso non cederá un anaco do seu poder a un competidor.
Os competidores do xestor ruso: un proceso empresarial de alta calidade e traballo, unha motivación ben pensada e mutuamente beneficiosa e unha automatización adecuada, por desgraza, deixarán ao xestor sen traballo.
Unha tontería, non estás de acordo? Sobre todo sobre os líderes. Vale, xa cho dixen, ti decides por ti mesmo.
Un pouco menos, pero aínda demasiado, na miña opinión, falou de Scrum.
Asegúrese, dixen, de ler e probar Scrum na práctica. Se, di, o liches pero non o probaches, considérate ignorante. É mellor ler un libro, por exemplo de Sutherland, que artigos e todo tipo de guías (que carallo?) en Internet.
Scrum, dixo, só se pode aprender coa práctica, e con medicións obrigatorias da cantidade de traballo realizado. Proba persoalmente os dous papeis máis importantes: Product Owner e Scrum Master.
É especialmente importante, segundo o mozo, experimentar na práctica o papel dun Scrum Master, cando podes aumentar o volume de tarefas completadas por sprint sen aumentar os recursos e o custo do sprint.
Pois ben, na súa parte superior estaba TOS (teoría das limitacións do sistema).
Estes, segundo o mozo, son os principios básicos e fundamentais para aumentar a eficiencia que se poden aplicar en case calquera área, en calquera proceso e sistema empresarial no seu conxunto.
Cando descubriu que non estabamos familiarizados co TOS, deixou de contalo. Só engadiu que non nos privaría do pracer de ler os libros de Eliyahu Goldratt. Deulle unha recomendación similar a Scrum: lea e proba. Como, independentemente da posición na que esteas, sen importar o traballo que fagas, hai un lugar para aumentar a eficiencia usando métodos TOC.
Entón, a súa bolsa de técnicas secouse ao parecer e dixo: mesturar os principios para crear solucións aplicadas nunha situación específica.
Esta, di, é a principal recomendación, a clave do éxito. Comprender os principios, a esencia e crear solucións de aplicación únicas: procesos e sistemas de negocio.
Despois intentou lembrar algunha cita e, ao final, tivo que conectarse. Resultou ser unha cita do artigo "Standing on the Shoulders of Giants" de Eliyahu Goldratt:
“Hai unha diferenza entre as solucións aplicadas (aplicacións) e os conceptos fundamentais nos que se basean esas solucións. Os conceptos son xerais; as solucións aplicadas son a adaptación de conceptos a un ambiente específico. Como xa vimos, tal adaptación non é sinxela e require o desenvolvemento de determinados elementos da solución. Debemos lembrar que unha solución de aplicación baséase en suposicións iniciais (ás veces ocultas) sobre un entorno específico. Non se debe esperar que esta solución de aplicación funcione nun ambiente para o que as suposicións non son correctas".
Dixo que o traballo dun programador e un "mellorador de procesos de negocio" son moi similares. E marchou.
Fonte: www.habr.com