Я тебе уже четвертый раз объясняю, что у сложного процесса нельзя ткнуть в один-два показателя и объявить их KPI. Ты про обороты коленвала-то ответь - зачем их на приборную панель выводят, если они тоже не являются показателями эффективности ? Или вот еще - у нас коллеги занимались вибродиагностикой - датчик совали турбоагрегату в разные места и рисовали спектры как он гудит (или как оно меняется со временем). И что характерно, им за это платили нехилые такие деньги! А ведь тоже - от гудения турбины количество выработанного электричества никак не зависит... Наверное все-таки надо почитать учебник по теории автоматического управления, и уяснить себе что существуют три сущности: реальный процесс (очень сложный - такой что невозможно понять и измерить в реальном времени). Есть наше упрощение в виде модели (в нашей голове, и может быть на бумаге) - которое отражает наше целеполагание - как бы мы хотели чтобы этот процесс протекал. А из модели выводится множество переменных которые ее достаточно хорошо описывают. Вот это множество переменных в бизнесе называется KPI.
А касательно желания продать свои наработки... Живые подтверждения старой инженерной истины: "всякая сложная проблема имеет простое, легкое для понимания и реализации - неправильное решение" (C).
Следуя вашей логике - количество оборотов коленвала двигателя - не может быть показателем performance автомашины. Ну потому что при одних и тех же оборотах двигателя - машина может ехать туда, может не туда, а может вообще стоять на месте. Однако же - показатель считается таким важным, что выводится почти на любую приборную панель!
Знаете в чем ваша методологическая ошибка ? Вы пытаетесь найти индикаторы эффективности. Но в английском языке - "эффективность" - это "efficiency" а не "performance". Performance - это вообще деятельность: хоть канаву рой, хоть в хоре пой. И KPI - это индикаторы, которые позволяют наблюдателю (руководителю) судить о характере протекания этой деятельности.
Соответственно, показатель "количество строк кода на человека" в группе - для меня являлось важным диагностическим критерием: а нормально ли мы работаем. Отклонения от известной мне статистической нормы были для меня сигналом - куда надо посмотреть и с кем поговорить. Что я делал не так ?
Мысли сударя поражают меня своей безапелляционностью. Не будет ли сударь любезен объяснить более подробно - почему количество строк на человека в сутки - точно не может быть ключевым показателем процесса разработки ? И чтобы два раза не вставать - почему оно у меня работало ?
Ну как бы да - сам по себе алгоритм действительно прост. Если на него внимательно посмотреть - то это другими словами написанный PDCA (Plan–Do–Check–Act). А PDCA - вообще такая фундаментальная штука, которая в каждой отрасли есть! Причем некоторые ее изобретают независимо и называют другой аббревиатурой (привет USAAF со алгоритмом Бойда и OODA - Observe, Orient, Decide, Act).
Но я бы уточнил описание деятельности руководителя вот так:
1) На основе опыта и знаний строим в голове модель реального процесса, избавляясь от ненужных подробностей (например, нет смысла отслеживать движения пальцев программиста и как он головой крутит - в задаче создания кода это нерелевантно)
2) Придумываем KPI которые бы показывали насколько хорошо модель себя чувствует, и в нужном ли направлении она двигается
3) Теперь забываем про модель, и оставляем себе в голове только KPI на которые будем ориентироваться. Если KPI сигнализируют что где-то что-то пошло не так - идем туда, смотрим лично, говорим с людми, по необходимости - производим управляющие воздействия.
4) Если оказывается что по KPI у нас все хорошо, а из реальности приходят сигналы что мы факапим - разбираемся: то ли у нас модель в голове кривая, то ли мы какой-то из аспектов этой модели не отслеживали систематически через KPI. В зависимости от этого - или поправляем KPI, либо - пересобираем модель объекта, которым мы управляем.
Вот сейчас написал - и понимаю что ровно вот это было в учебнике по теории автоматического управления (ТАУ) - только для печей, ракет и клапанов: модель процесса -> переменные описывающие состояние -> сравнение с целевыми значениями -> выработка управляющих сигналов, и т.д. Только слава богу - в техническом вузе все понимали что бессмысленно предлагать деньги турбонасосу чтобы он пульсации давления в магистрали компенсировал - надо что-то руками делать!... А вот выпускникам экономфака приходится объяснять! :-)
А сложность - как всегда в исполнении. Потому что руководителем по-честному надо работать. А я видел массу товарищей которые почему-то считали что там существует волшебная пуля (собрать правильный коллектив, ввести KPI, заставить регулярно писать отчеты, поставить СКУД и контролировать время входа-выхода, etc) - и можно один последний раз напрячься - и уже потом больше ничего не делать, а только сидеть и получать зарплату. Ну и вот эти героически-бессмысленные попытки наконец-то сделать что-то чтобы потом ничего не делать - и убивают организации...
"Ты, Зин, на грубость нарываешься! Всё, Зин, обидеть норовишь! Тут за день так накувыркаешься - придешь домой: там ты сидишь!" (C) Высоцкий.
"Если в семье один из супругов внезапно без видимых причин умирает, оставшийся супруг автоматически становится главным подозреваемым, если только у него нет железного алиби. И... в общем-то это все, что вам нужно знать о браке" (C) Полиция Лос-Анжелеса
Я никому и никогда не рекомендую семью как защиту от выгорания. Это как дельфины, которые якобы толкают утопающих к берегу - на самом деле дельфинам просто приколько поиграть, но тех кого толкали от берега - об этом не расскажут. Тем кому повезло с семьей, и она защитила их от выгорания - сидят и пишут статейку на хабр. А кто вернулся с работы и так на грани срыва, и после скандала учиненного женой - вышел в окно, ничего к сожалению уже не пишет.
Если вы чувствуете что выгораете, и при этом у вас много денег - купите себе лодку, подите отучитесь на пилота и купите самолет или планер, и т.д. Когда дорогое хобби вам надоест - вы сможете а) отказаться и б) вернуть часть денег. От семьи с детьми вы хрен откажетесь, и потом еще будете пол-жизни платить алименты (даже не имея с этого никаких бенефитов).
И конечно же - пойти на курсы по софт-скиллз для вас выйдет в тысячи (а то и миллионы) раз дешевле чем для этой же цели создавать семью.
Это не означает что я агитирую НЕ создавать семью. Это означает, что семью надо создавать ровно потому что вы этого (семью) очень хотите, и готовы мириться с неудобствами которые она вам принесет. А заводить ее для любой другой цели - это очень, очень глупо!
Для чего нужны показатели ? В реалиях РФ - для того чтобы сношать мозг сотрудникам, и иметь возможность срезать премию. В бизнесе здорового человека - KPI - это циферки, которые сигнализируют руководителю - куда он должен направить свой ресурс (время, внимание, административные способности). Потому что руководитель не резиновый, а даже если вы такого найдете - то он будет ходить и бесконечно всех спрашивать как идут дела - а это контрпродуктивно.
Соответственно, система показателей должна быть а) удобна руководителю и б) быть релевантной. Сотрудник здесь вообще никаким боком - ему может казаться что скорость закрутки болта важна, а для руководителя - перпендикулярна (или наоборот)
Сотрудники - в идеале, вообще не должны знать что руководитель там контролирует. Если система показателей выстроена верно - то руководитель магическим образом появляется в нужном месте в нужное время как только что-то происходит (даже если это пока не очень заметно). И что делает руководитель ? Он не пытается вернуть на место показатель. Потому что показатель - это индикатор (как температура у человека). Если у человека внезапно температура +38 - вы не топаете ногами, и не даете ему немедленно парацетамол, а пытаетесь понять - то ли это грипп и надо просто полежать в постели, то ли сепсис и надо вызывать скорую...
Ключевая проблема с KPI (неважно, с хорошими или с плохими) - это когда руководитель принадлежит к племени лентяев и дураков. Лентяй и дурак немедленно приходит к "гениальной" мысли привязать KPI к зарплате или премии - и "дальше сотрудники в погоне за рублем сами приведут отдел/департамент/фирму к процветанию. Как только это сделано - фирму можно закрывать. Ибо если вы платите сотрудникам за показатели - работа прекращается, и начинается рисование показателей. Если люди к этому привыкли - проще их уволить и нанять новых чем отучить от имитации бурной деятельности.
Отдельно скажу - что если KPI не привязаны к оплате - то вред от неправильных KPI минимален. Он просто означает, что время и энергия руководителя распределены не оптимально. С третьей стороны - никто не гарантирует что руководитель найдет свою золотую систему показателей с первого раза. Но пока KPI не привязаны к оплате - их можно безболезненно менять и улучшать (что тоже составляет часть работы ответственного руководителя).
Также - то что до сотрудников не доводятся KPI - не означает что сотрудники предоставлены сами себе. Руководитель обязан разговаривать с людьми, доводить до них цели, обсуждать задачи и критерии их достижения. И сотрудники должны ориентироваться именно на это, а не на KPI руководителя (которые могут совпадать с критериями сотрудников, а могут и нет - на усмотрение руководителя).
P.S. Для любителей накинуть на вентилятор - многие годы я успешно использовал в качестве KPI количество строк кода на разработчика в день. И оно (при соблюдении условий выше) - прекрасно работало!.
Давайте честно скажем - проблемы с деньгами возникают тогда, когда деньгами пытаются "откупиться" от детей вместо их воспитания. Предоставленный сам себе - ребенок неизбежно дичает, а неограниченный доступ к деньгам - придает этой дикости особый кураж.
В семьях нормальных миллионеров и фабрикантов - на детей деньги, естественно, тратились - например на хорошее образование. Но одновременно прививалась и культура обращения с деньгами - и уважение к труду.
Иными словами - в подавляющем большинстве случаев, воспитанные в семье родителями дети будут обращаться с деньгами ровно так, как это было принято у родителей. И никаких вопросов о том кому и сколько денег оставлять - обычно не возникает.
Все в курсе - только нигде я не видел чтобы при болезни, отпуске, или вакантной должности в штатном расписании - остальным сотрудникам давали доп. соглашение об увеличении объема работы и доплату. Повторяю - НИГДЕ. Ни при развитом социализме, ни при развитом капитализме... Правовая норма есть, а культурной нормы нет. Чем собственники и менеджмент и пользуются.
Давайте честно скажем, что компания и не могла, и не хотела ничего делать с уходящим Антоном. Ну кроме как проактивно искать ему замену. :-)
Смотрите какая логика у компании: сейчас проект открыт, он приносит сколько-то денег, и сколько-то стоит каждый месяц (и основные затраты - это зарплата разрабов). Все это, и разница между доходами и расходами (оптимитично предполагаем что проект прибыльный) - учтены в бюджете компании и расписаны на год вперед.
И вот приходит сигнал что Антон может уйти. Поднять ему зарплату ? А как вы это объясните стейкхолдерам ? А что если коллеги Антона тоже придут с тем же самым ? Вы пойдете объяснять клиентам что они должны платить больше из-за Антона ? А они вам покажут договор, или вообще фигу с маслом - и перейдут на продукт конкурента (или open-source).
С другой стороны - все "затраты" которые предприятие якобы несет из-за того что Антон ушел - они теоретические. Потому что никто не остановит развитие продукта из-за того что ушел разработчик. В российской традиции - если в отделе было пять человек, а стало - четыре, то просто четверо будут работать интенсивнее за те же деньги. В конце-концов, когда коллега уходит в отпуск - никто не прибегает требовать доплату за временное увеличение объема работы. Может быть тимлид и PO как-то поменяют приоритеты в бэклоге чтобы сдвинуть работы с учетом ввода в строй нового разраба. Затраты на найм - опять же, не смешите мои тапочки - разрабов море на рынке, главное - умей выбрать. И некоторый процент времени на собесы уже сидит в зарплате менеджера и тимлида - хоть есть эти собесы, хоть нету их.
В итоге - по деньгам в кармане стейкхолдеров - в большинстве случаев выгоднее ничего не делать, а дать человеку уйти и заменить его на кого-то другого. Исключения бывают - но в реальной жизни их мало (потому что нормальный менеджер и тимлид обязаны профилактировать bus-factor).
Нет! "Если хорошие инженеры будут отказываться от руководящей работы - руководителями над ними станут плохие инженеры" (С). То есть нет - не хотите, не руководите. Но тогда не жалуйтесь что ваш руководитель - идиот! Вы же сами ему место оставили...
Идея интересная - но к сожалению "из двух зол - выбраны оба". Принципиальная фича шагового движения - это что вам не нужна непрерывная траектория на земле, а только островки чтобы поставить ногу при шаге. Из-за этой разрывной траектории - человек легко преодолевает разнообразные мелкие препятствия и перепады высот (ямы, бордюры, низкие заборы, и т.д.). Гусеница (равно как и колесный привод) - принципиально требуют непрерывной и неразрывной траектории движения по асфальту. Чтобы улучшить преодолеваемый вертиальный барьер и яму - гусеницу надо делать длинной и высокой. Гусеница размером с ботинок - никуда толком не проедет, и на первом же бордюре - сбросит с себя наездника. А если вы возьмете поверхность на которой такая гусеница будет нормально ехать - то это окажется ровный асфальт, и можно взять колесо и иметь гораздо лучший КПД и меньший износ при эксплуатации.
А при предложенном решении - мы и теряем преимущества шага (разрывную траекторию нечувствительную к локальным препятствиям), и не получаем никаких преимуществ гусеничного движителя (из-за малых размеров - а если сделать нужные размеры, то оно будет и больше и тяжелее самоката - и непонятно зачем если все-равно асфальт и город).
Предлагаю идею взять обратно для принципиальной доработки...
Ну шутки-шутками, а "с этим надо что-то делать" (С) - ибо маркетплейс вместо того, чтобы быть логистическим и торговым посредником между покупателем и продавцом (за разумную комиссию) - занимается очень странными вещами. В идеале - продавец должен сам устанавливать и менять цену, потому что это - базовое правило рыночной экономики! Разумеется, продавец может делать это не лично, а написав для этого алгоритм (а маркетплейс - предоставить API), или даже по договору поручения - передать такое право третьей стороне (но опять же - по свободному договору, и наверняка предусмотрев какие-то лимиты в которых это можно делать). Сейчас же маркетплейс фактически представляет продавца перед покупателем (то есть - является агентом), и при этом совершает действия которые агент ему не поручал, и которые (даже если это записано в типовом договоре) - не имеют экономического смысла для агента, и к которым он действуя разумно и добросовестно - не присоединился бы... И в принципе, за это (действия во вред принципалу) - маркетплейсы следовало бы судам натягивать и без специальных предложений АНО, ФАС, и кого-бы то ни было еще... Просто у нас суды немного робкие, когда бизнес - это кого надо бизнес...
Ну и чтобы было понятно - если маркетплейс хочет вмешаться в ценообразование на рынке (давая скидки тем или иным способом) - он обязан выкупить товар у селлера по предложенной селлером цене, и потом делать с ним уже что хочет - хоть даром раздавать. Ибо это будет прямо отражаться в его прибылях и убытках, и в какой-то момент денег не хватит на такие вот операции. А давать скидки на товары одних селлеров за счет комиссий, которые собираются со всех, и при это не нести за это никакой ответственности (ибо товар никогда не становится собственностью маркетплейса) - это очень, очень плохо! Выглядит как дикий moral hazard, или "интернализация прибылей, эктернализация убытков"...
Однако - если мы посмотрим на окружающий мир, то очень сложно найти действие без среды или актора, который его инициирует. Замечу, что безличные предложения типа: "на улице дует" или "надо взять мусор и вынести" - это артефакты человеческого языка, который позволяет такую компрессию - опускать подразумеваемые вещи. В реальности на улице дует ветер (сиречь направленный поток молекул воздуха), а для того чтобы взять мусор и его вынести - нужен объект с соответствующими type traits (например, домашние животные не способны к этому действию).
Поэтому, включение действий в состав объекта-актора я нахожу в большинстве случаев оправданной. Разумеется, могут существовать действия, акторов для которых вы по той или иной причине не включили в состав модели. В языках типа C/C++ или Kotlin никто вам не мешает определить глобальную функцию для этого. В чистой джаве, да - придется создать God-object с именем GlobalModel, или ModelRules или что-то такое. Что в общем-то тоже имеет смысл, поскольку ваши действия возникающие "по щучьему велению" - являются артефактом конкретной выбранной модели - и в другой модели вполне могут появляться естественным взаимодействием акторов. Также, собирание "произвольных" действий в God-object может быть весьма полезно, если у вас в программе есть несколько моделей явлений одновременно. Если определять глобальные функции - то рано или поздно случится name-clash, и придется их разводить через дополнительный объект namespace. А поскольку вы даже и в джаве можете импортировать статическую функцию из god-object (и вызывать ее без явного указания объекта) - такой объект IMHO ничем не отличается от namespace в C++...
Ну как бы если любое движение от ассемблера считать движением в сторону ФП - то дальше спор смысла не имеет. Просто живите там у себя в мире математических абстракций, и даст бог в реальной жизни я вас не встречу.
Я видел развитие языков программирования через руки - начиная от 8-бит ассемблера, и дальше через 80x86 к C, C++, Java и так далее. Никакого движения в сторону FP там не было. Есть объекты реального мира. У них объективно есть состояние, которое меняется со временем по присущим им законам - или под внешним воздействием. В программе мы строим модель этого объекта или явления, отображая законы реального мира в их подобия в модельном пространстве. То-есть заменяем реальный вес на последовательность битов, его кодирующую (с фиксированной или плавающей точкой), положение объекта в пространстве на значения эйлеровых углов (или чего-то посложнее), и так далее. На низком уровне (ассемблере) - не существует способов выразить в языке структуру модели - какая ячейка или регистр за что отвечает - приходится держать в голове. Все дальнейшие нормальные языки: от прости господи, бейсика - до джавы - вводили разные изобратительные средства чтобы отразить объективно существующую структуру реального мира в программе с минимальными искажениями. То есть - группировать признаки относящиеся к одному модельному объекту в структуры, и сделать сложнее некорректные действия - типа вызвать метод "покрутить хвостом" к кухонной двери вместо кошки. Никто, щука, никогда не пытался представить модель мира как комбинацию бесчисленного количества чистых функций.
При том, что интеллектуально я готов принять множественность описания объектов реального мира (например, описание сигналов в частотной области спектрами, или во временной - графиками) - идея описать всё сущее чистыми функциями - проходит в моей канцелярии как забавный курьез. Ну и что, что можно ?! Вон метафора конечных автоматов тоже полна по Тьюирнгу - и любой процесс или явление можно описать таким образом. И есть чудаки которые до сих пор носятся с концепцией автоматного программирования. И аргументы у них точно такие же как у вас: это простой формализм, компилятору легче оптимизировать, и т.д. Проблема в том, что существует все-таки естественное описание объекта, которое является предпочтительным. Есть природные явления которые прямо-таки созданы для описания КА (или ФП). И там их надо применять. А там где это не естественно - там начинаются натягивания совы на глобус: давайте создадим скрытые фиктивные состояния, давайте добавим фиктивные входные и выходные сигналы, и т.д.
В итоге - повторю свой изначальный тезис: то что у вас появился в руках молоток - не делает остальные предметы гвоздями! Пожалуйста не надо хреначить направо и налево - да еще и похваляться этим...
Вот вы удивитесь - но если я кому-то буду рассказывать как я хожу в магазин - то это будет именно пошаговое перечисление действий: одеваюсь и оказываюсь одет, выхожу и оказываюсь на улице, двигаюсь в разных направлениях по улицам и перекресткам - оказываюсь у дверей магазина, набираю продукты, расплачиваюсь на кассе, и т.д. А вот сайд-эффектами этой деятельности оказываются a) уменьшившееся количество денег на счете и b) увеличившееся количество продуктов в холодильнике. И да, можно дискутировать о том до какой степени детализовать этот процесс (в программировании мы обычно детализируем до stdlib call или syscall). Без шуток - покажите мне человека который будет описывать поход в магазин как функциональное преобразование цифр в продукты... "А папа-мама не сумасшедши ли ?" (C) Мультик
Дальше - аргументы о том, что проще рассуждать и доказывать. Охотно верю - но знаете, идите на матфак работать с такими аргументами, что-ли ? Там любят таких... А я тут у мамы инженер. Мне не надо чтобы красиво доказано - мне надо чтобы работало, и легко читалось. Понятно что когда у меня есть streams, то ими надо пользоваться - например не писать свой алгоритм сортировки, а передать лямбду в библиотечный sort(). А когда один черт в коде клеится весь алгоритм, но пересыпается .apply() .with() .orElse() и прочей матерщиной (привет Kotlin!) - очень хочется дать по башке, и отправить копию новгородской грамоты чтобы лучше доходило...
Аргумент про то, чтобы компилировать ФП в мутабельный код - это из серии "можно, но зачем?!". То есть сначала мы сношаем мозг чтобы императивный процесс реального мира описать эквивалентом в мире чистых функций, а потом ждем чтобы компилятор обратно превратил это в императивный код с мутабельными объектами... Я даже теряюсь что предложить в таком случае... Например, когда в следующий раз захотите в туалет - не идите сразу у себя дома, а не поленитесь и дойдите пешком до центра. Потом такси вас обратно привезет - и только потом на толчок... После эксперимента задайте себе вопрос - стоило ли оно того, чтобы оказаться в том же месте по такой кружной траектории ?
Ох ты ж блин - статья является отличной иллюстрацией тезиса: "Человек, впервые взявший в руки молоток - рассматривает все окружающие предметы как разновидности гвоздей" (С).
Да, мы все в курсе, что исчисление функций эквивалентно машине Тьюринга - а значит любая вычислимая задача может быть описана как функционально, так и императивно. То есть - даже мой поход в магазин в субботу можно описать как функциональное преобразование из цифр на банковском счете в набор продуктов в холодильнике...
Вопрос - нахрена, а главное - зачем ?! Если объективно процесс ествественным образом описывается как набор шагов, меняющих состояние системы - то почему бы не последовать совету берестяной грамоты N35, и не описать его на языке программирования тем же (т.е. императивным) способом ? В чем смысл натягивания совы на глобус и вытягивания цепочки лямбд - которые потом еще хрен отладишь нормально (потому что не видны промежуточные преобразования коллекций) ?
Я лично вижу два случая, когда ФП надо применять:
У вас есть большой и полезный фреймворк, который вы можете кастомизировать - и для этого вам надо в глубины этого фреймворка передать определенное поведение. Так вы вот это поведение запихиваете в функцию, и ее как first-class-object передаете в глубины чужого кода. В моем примере с магазином - это как если бы кто-то уже написал фреймворк, автоматизирующий все промежуточные этапы, и надо было только подать внутрь функцию выбора товаров с полок...
Либо у вас функциональное описание является естественным описанием процесса. То есть реально процесс зависит только от входов, не порождает side-effects (логгинг и инструментация весело машут ручкой в этот момент - ибо являются сайд-эффектами), и т.д.
Ну и до кучи скажу что архитектура современных ЭВМ нихрена не заточена под ФП - она заточена под императивное программирование с мутабельным состоянием в RAM. Соответственно, ФП всегда будет подвергаться performance penalty по сравнению с императивным кодом. Другое дело - что производительность софта за последние десятилетия опустили на такое дно, что добавление туда еще и ФП - уже существенно ничего не меняет...
Давайте я попробую развеять ваше непонимание по поводу:
Под каждой нашей статьёй про Честный ЗНАК мы видим одно и то же: нет комментариев с вопросами по интеграции, зато чистых эмоций — разочарования, злости, усталости — хоть отбавляй. И мы видим, что часть этой агрессии переносится на нас, как на авторов контента. Это печалит. Мы видим, что бизнес загнан в угол, но вместо принятия нашей посильной помощи, комьюнити почему-то навешивает на нас ярлык «соучастников».
Вот представьте себе - живете вы в небольшой деревне. И вдруг - откуда ни возьмись, приходят фашисты, и говорят - что теперь деревня должна каждый месяц сдавать им 3 (три) ремня для фашистских штанов. Крестьяне посудили, погоревали - и вроде как нашли и свинью которую меньше всего жалко, и как ремень шить - а фурнитуры-то для ремня нету. Стало быть, не видать вражине ремней - походит вокруг, курицу заберет со двора, да и уйдет восвояси...
И тут из-за угла вылезает мелкий засранец - и начинает кричать: "Нет есть! Есть! У меня есть!Я продам вам, бедные крестьяне, фурнитуру! Дорого конечно, но продам!" К какой категории народная молва относила такого мелкого засранца ? Правильно: "..каратели и их пособники".
Воспоминание разблокировано. Мы несколько раз ходили разговаривать с одним бизнесом (и одним собственником) относительно автоматизации склада. После третьего раза - я начал что-то подозревать. Ибо мы слушали речь собственника о стратегии компании и необходимости повышения эффективности всех подразделений (а особенно - склада). Потом мы презентовали решение. Потом отвечали на вопросы собственника и приглашенных специалистов. Потом они брали паузу на "подумать". А через несколько месяцев все повторялось с теми же людьми и той же обстановке - как будто двух аналогичных встреч до этого - просто не было. Потом оказалось что собственник натурально стоит на учете в ПНД, и повторяющийся день сурка об автоматизации склада - это одно из безобидных проявлений. Мы потом шутили, что надо в стандартный опросник диагностики склада - включить пункт о признаках психического расстройства у ключевых стейкхолдеров...
"Какая прелесть!" (С). Хорошо работать в налоговой и не знать о том, каким местом она повернута к налогоплательщику. Как все прочие государственные органы - у налоговой есть KPI по сбору налогов (и штрафов). И начальство уже лет 10 не интересуется тем, как районная налоговая этот план выполняет. Ну то есть нет - вообще-то лучше чтобы и план выполнили, и закон не нарушили, и с налогоплательщиком были вежливы. Но если план горит - то становится можно все:
Списать левым решением нарисованную недоимку, а потом волокитить процесс возврата. А в конце предложить зачесть деньги в счет будущих налоговых обязательств (ну или сейчас - просто положить на единый счет полежать)...
Заставить пользователя региональной налоговой льготы платить федеральную (не льготную ставку) налога УСН. Знаете как ? Каждый месяц трахать всех контрагентов этого льготника предоставлением документов связанных с платежами в адрес льготника по списку: договор, счета, подтверждения оплаты, путевые листы, акты ввода в эксплуатацию основных средств... (список стандартный и очень длинный - да вы наверное и сами знаете). В результате, клиенты приходят к льготнику и говорят что повесят его на заборе (или как минимум разорвут все договора), если он еще раз сдаст "льготную" декларацию по УСН со своим видом деятельности...
...и таких приколов любой предприниматель/собственник/директор вам назовет вагон и маленькую тележку.
А все почему ? А потому что отсутствие сменяемости власти, отсутствие разделения властей (судебная власть де-факто подчинена исполнительной), и принцип НОНД в судах (нет оснований не доверять должностному лицу при исполнении служебных обязанностей) - приводят к деградации чего угодно! :-(
Я тебе уже четвертый раз объясняю, что у сложного процесса нельзя ткнуть в один-два показателя и объявить их KPI. Ты про обороты коленвала-то ответь - зачем их на приборную панель выводят, если они тоже не являются показателями эффективности ? Или вот еще - у нас коллеги занимались вибродиагностикой - датчик совали турбоагрегату в разные места и рисовали спектры как он гудит (или как оно меняется со временем). И что характерно, им за это платили нехилые такие деньги! А ведь тоже - от гудения турбины количество выработанного электричества никак не зависит... Наверное все-таки надо почитать учебник по теории автоматического управления, и уяснить себе что существуют три сущности: реальный процесс (очень сложный - такой что невозможно понять и измерить в реальном времени). Есть наше упрощение в виде модели (в нашей голове, и может быть на бумаге) - которое отражает наше целеполагание - как бы мы хотели чтобы этот процесс протекал. А из модели выводится множество переменных которые ее достаточно хорошо описывают. Вот это множество переменных в бизнесе называется KPI.
А касательно желания продать свои наработки... Живые подтверждения старой инженерной истины: "всякая сложная проблема имеет простое, легкое для понимания и реализации - неправильное решение" (C).
Следуя вашей логике - количество оборотов коленвала двигателя - не может быть показателем performance автомашины. Ну потому что при одних и тех же оборотах двигателя - машина может ехать туда, может не туда, а может вообще стоять на месте. Однако же - показатель считается таким важным, что выводится почти на любую приборную панель!
Знаете в чем ваша методологическая ошибка ? Вы пытаетесь найти индикаторы эффективности. Но в английском языке - "эффективность" - это "efficiency" а не "performance". Performance - это вообще деятельность: хоть канаву рой, хоть в хоре пой. И KPI - это индикаторы, которые позволяют наблюдателю (руководителю) судить о характере протекания этой деятельности.
Соответственно, показатель "количество строк кода на человека" в группе - для меня являлось важным диагностическим критерием: а нормально ли мы работаем. Отклонения от известной мне статистической нормы были для меня сигналом - куда надо посмотреть и с кем поговорить. Что я делал не так ?
Мысли сударя поражают меня своей безапелляционностью. Не будет ли сударь любезен объяснить более подробно - почему количество строк на человека в сутки - точно не может быть ключевым показателем процесса разработки ? И чтобы два раза не вставать - почему оно у меня работало ?
Ну как бы да - сам по себе алгоритм действительно прост. Если на него внимательно посмотреть - то это другими словами написанный PDCA (Plan–Do–Check–Act). А PDCA - вообще такая фундаментальная штука, которая в каждой отрасли есть! Причем некоторые ее изобретают независимо и называют другой аббревиатурой (привет USAAF со алгоритмом Бойда и OODA - Observe, Orient, Decide, Act).
Но я бы уточнил описание деятельности руководителя вот так:
1) На основе опыта и знаний строим в голове модель реального процесса, избавляясь от ненужных подробностей (например, нет смысла отслеживать движения пальцев программиста и как он головой крутит - в задаче создания кода это нерелевантно)
2) Придумываем KPI которые бы показывали насколько хорошо модель себя чувствует, и в нужном ли направлении она двигается
3) Теперь забываем про модель, и оставляем себе в голове только KPI на которые будем ориентироваться. Если KPI сигнализируют что где-то что-то пошло не так - идем туда, смотрим лично, говорим с людми, по необходимости - производим управляющие воздействия.
4) Если оказывается что по KPI у нас все хорошо, а из реальности приходят сигналы что мы факапим - разбираемся: то ли у нас модель в голове кривая, то ли мы какой-то из аспектов этой модели не отслеживали систематически через KPI. В зависимости от этого - или поправляем KPI, либо - пересобираем модель объекта, которым мы управляем.
Вот сейчас написал - и понимаю что ровно вот это было в учебнике по теории автоматического управления (ТАУ) - только для печей, ракет и клапанов: модель процесса -> переменные описывающие состояние -> сравнение с целевыми значениями -> выработка управляющих сигналов, и т.д. Только слава богу - в техническом вузе все понимали что бессмысленно предлагать деньги турбонасосу чтобы он пульсации давления в магистрали компенсировал - надо что-то руками делать!... А вот выпускникам экономфака приходится объяснять! :-)
А сложность - как всегда в исполнении. Потому что руководителем по-честному надо работать. А я видел массу товарищей которые почему-то считали что там существует волшебная пуля (собрать правильный коллектив, ввести KPI, заставить регулярно писать отчеты, поставить СКУД и контролировать время входа-выхода, etc) - и можно один последний раз напрячься - и уже потом больше ничего не делать, а только сидеть и получать зарплату. Ну и вот эти героически-бессмысленные попытки наконец-то сделать что-то чтобы потом ничего не делать - и убивают организации...
"Ты, Зин, на грубость нарываешься! Всё, Зин, обидеть норовишь! Тут за день так накувыркаешься - придешь домой: там ты сидишь!" (C) Высоцкий.
"Если в семье один из супругов внезапно без видимых причин умирает, оставшийся супруг автоматически становится главным подозреваемым, если только у него нет железного алиби. И... в общем-то это все, что вам нужно знать о браке" (C) Полиция Лос-Анжелеса
Я никому и никогда не рекомендую семью как защиту от выгорания. Это как дельфины, которые якобы толкают утопающих к берегу - на самом деле дельфинам просто приколько поиграть, но тех кого толкали от берега - об этом не расскажут. Тем кому повезло с семьей, и она защитила их от выгорания - сидят и пишут статейку на хабр. А кто вернулся с работы и так на грани срыва, и после скандала учиненного женой - вышел в окно, ничего к сожалению уже не пишет.
Если вы чувствуете что выгораете, и при этом у вас много денег - купите себе лодку, подите отучитесь на пилота и купите самолет или планер, и т.д. Когда дорогое хобби вам надоест - вы сможете а) отказаться и б) вернуть часть денег. От семьи с детьми вы хрен откажетесь, и потом еще будете пол-жизни платить алименты (даже не имея с этого никаких бенефитов).
И конечно же - пойти на курсы по софт-скиллз для вас выйдет в тысячи (а то и миллионы) раз дешевле чем для этой же цели создавать семью.
Это не означает что я агитирую НЕ создавать семью. Это означает, что семью надо создавать ровно потому что вы этого (семью) очень хотите, и готовы мириться с неудобствами которые она вам принесет. А заводить ее для любой другой цели - это очень, очень глупо!
Едрит-мадрид! Ну нет конечно! Давайте по-пунктам:
Для чего нужны показатели ? В реалиях РФ - для того чтобы сношать мозг сотрудникам, и иметь возможность срезать премию. В бизнесе здорового человека - KPI - это циферки, которые сигнализируют руководителю - куда он должен направить свой ресурс (время, внимание, административные способности). Потому что руководитель не резиновый, а даже если вы такого найдете - то он будет ходить и бесконечно всех спрашивать как идут дела - а это контрпродуктивно.
Соответственно, система показателей должна быть а) удобна руководителю и б) быть релевантной. Сотрудник здесь вообще никаким боком - ему может казаться что скорость закрутки болта важна, а для руководителя - перпендикулярна (или наоборот)
Сотрудники - в идеале, вообще не должны знать что руководитель там контролирует. Если система показателей выстроена верно - то руководитель магическим образом появляется в нужном месте в нужное время как только что-то происходит (даже если это пока не очень заметно). И что делает руководитель ? Он не пытается вернуть на место показатель. Потому что показатель - это индикатор (как температура у человека). Если у человека внезапно температура +38 - вы не топаете ногами, и не даете ему немедленно парацетамол, а пытаетесь понять - то ли это грипп и надо просто полежать в постели, то ли сепсис и надо вызывать скорую...
Ключевая проблема с KPI (неважно, с хорошими или с плохими) - это когда руководитель принадлежит к племени лентяев и дураков. Лентяй и дурак немедленно приходит к "гениальной" мысли привязать KPI к зарплате или премии - и "дальше сотрудники в погоне за рублем сами приведут отдел/департамент/фирму к процветанию. Как только это сделано - фирму можно закрывать. Ибо если вы платите сотрудникам за показатели - работа прекращается, и начинается рисование показателей. Если люди к этому привыкли - проще их уволить и нанять новых чем отучить от имитации бурной деятельности.
Отдельно скажу - что если KPI не привязаны к оплате - то вред от неправильных KPI минимален. Он просто означает, что время и энергия руководителя распределены не оптимально. С третьей стороны - никто не гарантирует что руководитель найдет свою золотую систему показателей с первого раза. Но пока KPI не привязаны к оплате - их можно безболезненно менять и улучшать (что тоже составляет часть работы ответственного руководителя).
Также - то что до сотрудников не доводятся KPI - не означает что сотрудники предоставлены сами себе. Руководитель обязан разговаривать с людьми, доводить до них цели, обсуждать задачи и критерии их достижения. И сотрудники должны ориентироваться именно на это, а не на KPI руководителя (которые могут совпадать с критериями сотрудников, а могут и нет - на усмотрение руководителя).
P.S. Для любителей накинуть на вентилятор - многие годы я успешно использовал в качестве KPI количество строк кода на разработчика в день. И оно (при соблюдении условий выше) - прекрасно работало!.
Давайте честно скажем - проблемы с деньгами возникают тогда, когда деньгами пытаются "откупиться" от детей вместо их воспитания. Предоставленный сам себе - ребенок неизбежно дичает, а неограниченный доступ к деньгам - придает этой дикости особый кураж.
В семьях нормальных миллионеров и фабрикантов - на детей деньги, естественно, тратились - например на хорошее образование. Но одновременно прививалась и культура обращения с деньгами - и уважение к труду.
Иными словами - в подавляющем большинстве случаев, воспитанные в семье родителями дети будут обращаться с деньгами ровно так, как это было принято у родителей. И никаких вопросов о том кому и сколько денег оставлять - обычно не возникает.
Все в курсе - только нигде я не видел чтобы при болезни, отпуске, или вакантной должности в штатном расписании - остальным сотрудникам давали доп. соглашение об увеличении объема работы и доплату. Повторяю - НИГДЕ. Ни при развитом социализме, ни при развитом капитализме... Правовая норма есть, а культурной нормы нет. Чем собственники и менеджмент и пользуются.
Давайте честно скажем, что компания и не могла, и не хотела ничего делать с уходящим Антоном. Ну кроме как проактивно искать ему замену. :-)
Смотрите какая логика у компании: сейчас проект открыт, он приносит сколько-то денег, и сколько-то стоит каждый месяц (и основные затраты - это зарплата разрабов). Все это, и разница между доходами и расходами (оптимитично предполагаем что проект прибыльный) - учтены в бюджете компании и расписаны на год вперед.
И вот приходит сигнал что Антон может уйти. Поднять ему зарплату ? А как вы это объясните стейкхолдерам ? А что если коллеги Антона тоже придут с тем же самым ? Вы пойдете объяснять клиентам что они должны платить больше из-за Антона ? А они вам покажут договор, или вообще фигу с маслом - и перейдут на продукт конкурента (или open-source).
С другой стороны - все "затраты" которые предприятие якобы несет из-за того что Антон ушел - они теоретические. Потому что никто не остановит развитие продукта из-за того что ушел разработчик. В российской традиции - если в отделе было пять человек, а стало - четыре, то просто четверо будут работать интенсивнее за те же деньги. В конце-концов, когда коллега уходит в отпуск - никто не прибегает требовать доплату за временное увеличение объема работы. Может быть тимлид и PO как-то поменяют приоритеты в бэклоге чтобы сдвинуть работы с учетом ввода в строй нового разраба. Затраты на найм - опять же, не смешите мои тапочки - разрабов море на рынке, главное - умей выбрать. И некоторый процент времени на собесы уже сидит в зарплате менеджера и тимлида - хоть есть эти собесы, хоть нету их.
В итоге - по деньгам в кармане стейкхолдеров - в большинстве случаев выгоднее ничего не делать, а дать человеку уйти и заменить его на кого-то другого. Исключения бывают - но в реальной жизни их мало (потому что нормальный менеджер и тимлид обязаны профилактировать bus-factor).
Нет! "Если хорошие инженеры будут отказываться от руководящей работы - руководителями над ними станут плохие инженеры" (С). То есть нет - не хотите, не руководите. Но тогда не жалуйтесь что ваш руководитель - идиот! Вы же сами ему место оставили...
Идея интересная - но к сожалению "из двух зол - выбраны оба". Принципиальная фича шагового движения - это что вам не нужна непрерывная траектория на земле, а только островки чтобы поставить ногу при шаге. Из-за этой разрывной траектории - человек легко преодолевает разнообразные мелкие препятствия и перепады высот (ямы, бордюры, низкие заборы, и т.д.). Гусеница (равно как и колесный привод) - принципиально требуют непрерывной и неразрывной траектории движения по асфальту. Чтобы улучшить преодолеваемый вертиальный барьер и яму - гусеницу надо делать длинной и высокой. Гусеница размером с ботинок - никуда толком не проедет, и на первом же бордюре - сбросит с себя наездника. А если вы возьмете поверхность на которой такая гусеница будет нормально ехать - то это окажется ровный асфальт, и можно взять колесо и иметь гораздо лучший КПД и меньший износ при эксплуатации.
А при предложенном решении - мы и теряем преимущества шага (разрывную траекторию нечувствительную к локальным препятствиям), и не получаем никаких преимуществ гусеничного движителя (из-за малых размеров - а если сделать нужные размеры, то оно будет и больше и тяжелее самоката - и непонятно зачем если все-равно асфальт и город).
Предлагаю идею взять обратно для принципиальной доработки...
Ну шутки-шутками, а "с этим надо что-то делать" (С) - ибо маркетплейс вместо того, чтобы быть логистическим и торговым посредником между покупателем и продавцом (за разумную комиссию) - занимается очень странными вещами. В идеале - продавец должен сам устанавливать и менять цену, потому что это - базовое правило рыночной экономики! Разумеется, продавец может делать это не лично, а написав для этого алгоритм (а маркетплейс - предоставить API), или даже по договору поручения - передать такое право третьей стороне (но опять же - по свободному договору, и наверняка предусмотрев какие-то лимиты в которых это можно делать). Сейчас же маркетплейс фактически представляет продавца перед покупателем (то есть - является агентом), и при этом совершает действия которые агент ему не поручал, и которые (даже если это записано в типовом договоре) - не имеют экономического смысла для агента, и к которым он действуя разумно и добросовестно - не присоединился бы... И в принципе, за это (действия во вред принципалу) - маркетплейсы следовало бы судам натягивать и без специальных предложений АНО, ФАС, и кого-бы то ни было еще... Просто у нас суды немного робкие, когда бизнес - это кого надо бизнес...
Ну и чтобы было понятно - если маркетплейс хочет вмешаться в ценообразование на рынке (давая скидки тем или иным способом) - он обязан выкупить товар у селлера по предложенной селлером цене, и потом делать с ним уже что хочет - хоть даром раздавать. Ибо это будет прямо отражаться в его прибылях и убытках, и в какой-то момент денег не хватит на такие вот операции. А давать скидки на товары одних селлеров за счет комиссий, которые собираются со всех, и при это не нести за это никакой ответственности (ибо товар никогда не становится собственностью маркетплейса) - это очень, очень плохо! Выглядит как дикий moral hazard, или "интернализация прибылей, эктернализация убытков"...
Однако - если мы посмотрим на окружающий мир, то очень сложно найти действие без среды или актора, который его инициирует. Замечу, что безличные предложения типа: "на улице дует" или "надо взять мусор и вынести" - это артефакты человеческого языка, который позволяет такую компрессию - опускать подразумеваемые вещи. В реальности на улице дует ветер (сиречь направленный поток молекул воздуха), а для того чтобы взять мусор и его вынести - нужен объект с соответствующими type traits (например, домашние животные не способны к этому действию).
Поэтому, включение действий в состав объекта-актора я нахожу в большинстве случаев оправданной. Разумеется, могут существовать действия, акторов для которых вы по той или иной причине не включили в состав модели. В языках типа C/C++ или Kotlin никто вам не мешает определить глобальную функцию для этого. В чистой джаве, да - придется создать God-object с именем GlobalModel, или ModelRules или что-то такое. Что в общем-то тоже имеет смысл, поскольку ваши действия возникающие "по щучьему велению" - являются артефактом конкретной выбранной модели - и в другой модели вполне могут появляться естественным взаимодействием акторов. Также, собирание "произвольных" действий в God-object может быть весьма полезно, если у вас в программе есть несколько моделей явлений одновременно. Если определять глобальные функции - то рано или поздно случится name-clash, и придется их разводить через дополнительный объект namespace. А поскольку вы даже и в джаве можете импортировать статическую функцию из god-object (и вызывать ее без явного указания объекта) - такой объект IMHO ничем не отличается от namespace в C++...
Я предпочитаю: "Все модели неверны, но некоторые полезны" (C) Дж.Бокс.
Ну как бы если любое движение от ассемблера считать движением в сторону ФП - то дальше спор смысла не имеет. Просто живите там у себя в мире математических абстракций, и даст бог в реальной жизни я вас не встречу.
Я видел развитие языков программирования через руки - начиная от 8-бит ассемблера, и дальше через 80x86 к C, C++, Java и так далее. Никакого движения в сторону FP там не было. Есть объекты реального мира. У них объективно есть состояние, которое меняется со временем по присущим им законам - или под внешним воздействием. В программе мы строим модель этого объекта или явления, отображая законы реального мира в их подобия в модельном пространстве. То-есть заменяем реальный вес на последовательность битов, его кодирующую (с фиксированной или плавающей точкой), положение объекта в пространстве на значения эйлеровых углов (или чего-то посложнее), и так далее. На низком уровне (ассемблере) - не существует способов выразить в языке структуру модели - какая ячейка или регистр за что отвечает - приходится держать в голове. Все дальнейшие нормальные языки: от прости господи, бейсика - до джавы - вводили разные изобратительные средства чтобы отразить объективно существующую структуру реального мира в программе с минимальными искажениями. То есть - группировать признаки относящиеся к одному модельному объекту в структуры, и сделать сложнее некорректные действия - типа вызвать метод "покрутить хвостом" к кухонной двери вместо кошки. Никто, щука, никогда не пытался представить модель мира как комбинацию бесчисленного количества чистых функций.
При том, что интеллектуально я готов принять множественность описания объектов реального мира (например, описание сигналов в частотной области спектрами, или во временной - графиками) - идея описать всё сущее чистыми функциями - проходит в моей канцелярии как забавный курьез. Ну и что, что можно ?! Вон метафора конечных автоматов тоже полна по Тьюирнгу - и любой процесс или явление можно описать таким образом. И есть чудаки которые до сих пор носятся с концепцией автоматного программирования. И аргументы у них точно такие же как у вас: это простой формализм, компилятору легче оптимизировать, и т.д. Проблема в том, что существует все-таки естественное описание объекта, которое является предпочтительным. Есть природные явления которые прямо-таки созданы для описания КА (или ФП). И там их надо применять. А там где это не естественно - там начинаются натягивания совы на глобус: давайте создадим скрытые фиктивные состояния, давайте добавим фиктивные входные и выходные сигналы, и т.д.
В итоге - повторю свой изначальный тезис: то что у вас появился в руках молоток - не делает остальные предметы гвоздями! Пожалуйста не надо хреначить направо и налево - да еще и похваляться этим...
Вот вы удивитесь - но если я кому-то буду рассказывать как я хожу в магазин - то это будет именно пошаговое перечисление действий: одеваюсь и оказываюсь одет, выхожу и оказываюсь на улице, двигаюсь в разных направлениях по улицам и перекресткам - оказываюсь у дверей магазина, набираю продукты, расплачиваюсь на кассе, и т.д. А вот сайд-эффектами этой деятельности оказываются a) уменьшившееся количество денег на счете и b) увеличившееся количество продуктов в холодильнике. И да, можно дискутировать о том до какой степени детализовать этот процесс (в программировании мы обычно детализируем до stdlib call или syscall). Без шуток - покажите мне человека который будет описывать поход в магазин как функциональное преобразование цифр в продукты... "А папа-мама не сумасшедши ли ?" (C) Мультик
Дальше - аргументы о том, что проще рассуждать и доказывать. Охотно верю - но знаете, идите на матфак работать с такими аргументами, что-ли ? Там любят таких... А я тут у мамы инженер. Мне не надо чтобы красиво доказано - мне надо чтобы работало, и легко читалось. Понятно что когда у меня есть streams, то ими надо пользоваться - например не писать свой алгоритм сортировки, а передать лямбду в библиотечный sort(). А когда один черт в коде клеится весь алгоритм, но пересыпается .apply() .with() .orElse() и прочей матерщиной (привет Kotlin!) - очень хочется дать по башке, и отправить копию новгородской грамоты чтобы лучше доходило...
Аргумент про то, чтобы компилировать ФП в мутабельный код - это из серии "можно, но зачем?!". То есть сначала мы сношаем мозг чтобы императивный процесс реального мира описать эквивалентом в мире чистых функций, а потом ждем чтобы компилятор обратно превратил это в императивный код с мутабельными объектами... Я даже теряюсь что предложить в таком случае... Например, когда в следующий раз захотите в туалет - не идите сразу у себя дома, а не поленитесь и дойдите пешком до центра. Потом такси вас обратно привезет - и только потом на толчок... После эксперимента задайте себе вопрос - стоило ли оно того, чтобы оказаться в том же месте по такой кружной траектории ?
Ох ты ж блин - статья является отличной иллюстрацией тезиса: "Человек, впервые взявший в руки молоток - рассматривает все окружающие предметы как разновидности гвоздей" (С).
Да, мы все в курсе, что исчисление функций эквивалентно машине Тьюринга - а значит любая вычислимая задача может быть описана как функционально, так и императивно. То есть - даже мой поход в магазин в субботу можно описать как функциональное преобразование из цифр на банковском счете в набор продуктов в холодильнике...
Вопрос - нахрена, а главное - зачем ?! Если объективно процесс ествественным образом описывается как набор шагов, меняющих состояние системы - то почему бы не последовать совету берестяной грамоты N35, и не описать его на языке программирования тем же (т.е. императивным) способом ? В чем смысл натягивания совы на глобус и вытягивания цепочки лямбд - которые потом еще хрен отладишь нормально (потому что не видны промежуточные преобразования коллекций) ?
Я лично вижу два случая, когда ФП надо применять:
У вас есть большой и полезный фреймворк, который вы можете кастомизировать - и для этого вам надо в глубины этого фреймворка передать определенное поведение. Так вы вот это поведение запихиваете в функцию, и ее как first-class-object передаете в глубины чужого кода. В моем примере с магазином - это как если бы кто-то уже написал фреймворк, автоматизирующий все промежуточные этапы, и надо было только подать внутрь функцию выбора товаров с полок...
Либо у вас функциональное описание является естественным описанием процесса. То есть реально процесс зависит только от входов, не порождает side-effects (логгинг и инструментация весело машут ручкой в этот момент - ибо являются сайд-эффектами), и т.д.
Ну и до кучи скажу что архитектура современных ЭВМ нихрена не заточена под ФП - она заточена под императивное программирование с мутабельным состоянием в RAM. Соответственно, ФП всегда будет подвергаться performance penalty по сравнению с императивным кодом. Другое дело - что производительность софта за последние десятилетия опустили на такое дно, что добавление туда еще и ФП - уже существенно ничего не меняет...
Давайте я попробую развеять ваше непонимание по поводу:
Вот представьте себе - живете вы в небольшой деревне. И вдруг - откуда ни возьмись, приходят фашисты, и говорят - что теперь деревня должна каждый месяц сдавать им 3 (три) ремня для фашистских штанов. Крестьяне посудили, погоревали - и вроде как нашли и свинью которую меньше всего жалко, и как ремень шить - а фурнитуры-то для ремня нету. Стало быть, не видать вражине ремней - походит вокруг, курицу заберет со двора, да и уйдет восвояси...
И тут из-за угла вылезает мелкий засранец - и начинает кричать: "Нет есть! Есть! У меня есть!Я продам вам, бедные крестьяне, фурнитуру! Дорого конечно, но продам!" К какой категории народная молва относила такого мелкого засранца ? Правильно: "..каратели и их пособники".
Вот также и у вас... :-(
Воспоминание разблокировано. Мы несколько раз ходили разговаривать с одним бизнесом (и одним собственником) относительно автоматизации склада. После третьего раза - я начал что-то подозревать. Ибо мы слушали речь собственника о стратегии компании и необходимости повышения эффективности всех подразделений (а особенно - склада). Потом мы презентовали решение. Потом отвечали на вопросы собственника и приглашенных специалистов. Потом они брали паузу на "подумать". А через несколько месяцев все повторялось с теми же людьми и той же обстановке - как будто двух аналогичных встреч до этого - просто не было. Потом оказалось что собственник натурально стоит на учете в ПНД, и повторяющийся день сурка об автоматизации склада - это одно из безобидных проявлений. Мы потом шутили, что надо в стандартный опросник диагностики склада - включить пункт о признаках психического расстройства у ключевых стейкхолдеров...
"Какая прелесть!" (С). Хорошо работать в налоговой и не знать о том, каким местом она повернута к налогоплательщику. Как все прочие государственные органы - у налоговой есть KPI по сбору налогов (и штрафов). И начальство уже лет 10 не интересуется тем, как районная налоговая этот план выполняет. Ну то есть нет - вообще-то лучше чтобы и план выполнили, и закон не нарушили, и с налогоплательщиком были вежливы. Но если план горит - то становится можно все:
Списать левым решением нарисованную недоимку, а потом волокитить процесс возврата. А в конце предложить зачесть деньги в счет будущих налоговых обязательств (ну или сейчас - просто положить на единый счет полежать)...
Заставить пользователя региональной налоговой льготы платить федеральную (не льготную ставку) налога УСН. Знаете как ? Каждый месяц трахать всех контрагентов этого льготника предоставлением документов связанных с платежами в адрес льготника по списку: договор, счета, подтверждения оплаты, путевые листы, акты ввода в эксплуатацию основных средств... (список стандартный и очень длинный - да вы наверное и сами знаете). В результате, клиенты приходят к льготнику и говорят что повесят его на заборе (или как минимум разорвут все договора), если он еще раз сдаст "льготную" декларацию по УСН со своим видом деятельности...
...и таких приколов любой предприниматель/собственник/директор вам назовет вагон и маленькую тележку.
А все почему ? А потому что отсутствие сменяемости власти, отсутствие разделения властей (судебная власть де-факто подчинена исполнительной), и принцип НОНД в судах (нет оснований не доверять должностному лицу при исполнении служебных обязанностей) - приводят к деградации чего угодно! :-(