Тогда не очень понятно как ваши вычисления могут занимать минуты, если исходить из того что в слое 200 на 200 точек то он будет обрабатываться за доли секунды.
Вы поставили перед собой цель смоделировать дифракцию через численное нахождение интеграла Френеля методом Монте-Карло.
И визуально сравнили полученный результат с наблюдаемым в результате эксперимента.
Полученный результат интегрирования ожидаемо дал значения заложенные в теоретическую модель.
В статье смущает вот что: длительность вычисления зависит от количества точек для которых проводится расчет. Очевидно -- взяв меньше точек вы сможете оптимизировать трудозатраты при сохранении визуализации. (Как вы выбирали дискретность вашего расчета?)
Очень похоже что в наличии ошибка наименования осей на графике, там где должна быть интенсивность поля указана координата Y.
В отношении пятна Пуассона, вы получаете интенсивность исходного поля, которая похоже задается как 1, просто исходя из того что exp(0) == 1;
Прочитал статью и как интересно она отражает реальность. Доктора обсуждают болезни, танцоры движения, писатели сюжеты для книг. А тут программисты обсуждают неразрешимые проблемы программирования. Которые на поверку оказываются социальными.
У программирования как раздела математики нет проблем, просто потому что проблемы математики носят не прикладной, а теоретический характер и являются не столько проблемами, сколько законами и ограничениями мироустройства, зато у программирования есть проблемы социальные.
Как подобрать коллектив, как наладить работу, как настроить постороннего человека выполнять задачи поставленные перед коллективом, как наладить образование. Это из того что раскрыто в статье, а за кадром наверное осталось, как удержать спрос, как монетизировать фичи, как не вляпаться в налоговые и административные ограничения, как не накосячить в других аспектах.
Программирование из раздела сакральных знаний выходит в массы и как результат критерии отбора становятся более ремесленными. Раньше в этой области трудились победители математических олимпиад и на собеседовании их пытались выявлять, задавая олимпиадные задачки, а теперь нужно найти человека который будет тянуть рутину.
Раньше куски кода рождались с целью превозмочь ограничения реальности на каждом шагу, а нынче нужно просто прикручивать фичу к уже существующему коду, в котором нужно хоть немного разобраться и впаять костыль, так чтобы и дальше можно было поддерживать работающую кодовую базу.
Очень похоже, что в программировании мы столкнулись с кризисом идей, не появляется новых программ. Картинки меняются а суть остается прежней. Во главу угла поставлена монетизация.
Новые идеи не требуют всего того что описано в статье. Если для реализации идеи нужно больше чем 1 человек, то это скорее всего не самая лучшая идея. Для реализации алгоритма обратного распространения ошибки не нужна команда из 100 человек... И ТДД с УМЛ тоже будут только удлинять путь от идеи к монетизации.
Как итог в коде рожденном на базе идеи нет документации, нет комментариев. Все это приходит на этапе, когда более менее удачную идею начинают насыщать маркетинговыми фичами и нанимают "команду".
Мы наблюдаем то, что новое, пока еще не устоявшееся ремесло начинает обрастать терминологией, критериями успеха, процессами. Мы просто наблюдаем как программирование растет и переживает кризисы взросления. Мы счастливые люди, на нашем веку программирование из ассемблерных кодов развилось в социальное явление.
А проблемы программирования это наверное все же нечто совсем другое и гораздо более математически точное.
Именно такие знания и отличают профессионала от любителя. В моей любительской практике я крайне редко сталкиваюсь с макросами и не обратил внимания на факт наличия или отсутствия ';'
Действительно подумал, а почему бы просто не использовать фигурные скобки, вместо обработки условия, но решил, что с макросом так не сработает.
Так что спасибо, за то что обратили мое внимание на существенный факт написания заготовки для функции в в обертке do{}while(0)
Эволюция интерфейсов прошла путь от редактора перфокарт до 3д моделирования 4д объектов голосовыми командами с использованием ИИ.
За это время накопилось огромное количество людей, которые привыкли к тем или иным элементам управления, которые они использовали многие годы каждый день. И теперь любое движение и изменение будет находить своих отпетых сторонников и ярых противников.
Все то обилие и пестрота интерфейсов доступных в сети говорит о том, что не существует единого стандарта на основе которого каждый будет взаимодействовать с пользователем.
А вот в Windows до определенного момента все интерфейсы были более менее стандартизованы и да поддавались модификации ( Но кто бы этим занимался если есть хороший стандартный набор элементов более менее хорошо настроенных по умолчанию ( Включая полосы прокрутки и прочие удобства (MFC)) отсутствие которых смущает автора.
При этом в сети стандартный интерфейс не прижился. Наличие стандартных кнопок на пестрых раскрашенных страницах сети выглядит плохо, а прибыльность и удобство явно не коллинеарные понятия. Красочный рекламный баннер-кнопка монетизируется лучше чем невзрачная серая кнопка интерфейса управления.
А так как добавление каждого инструмента управления требует затрат не только на программиста но и на дизайнера и на художника и на тестировщика и еще использование какой-нибудь загадочной библиотеки которая завтра перестанет работать. В общем чем меньше тем лучше. Вот и идем мы от серьезно проработанного интерфейса читалки для fido к непонятным одностраничным приложениям в телефон задача которых заставить тебя ввести телефон и почту и получать коммерческие предложения.
Как по мне, статьи в которых автор подробно рассказывает о разработке ПО от самых базовых математических основ и до работающего кода являются наиболее ценными.
В данной статье не только описана модель и ее реализация, но и очень чистый и красивый код. Приятно почитать. Кроме того, чтобы увидеть результат автор не поленился и подготовил визуализацию.
на мой вкус, это подход из серии "когда убьют, тогда и приходите".
Уж как есть.
Реагировать на жалобы из интернета логично
Вам поступает жалоба на клиента который платит вам денежку от непонятно кого из интернета. У вас два варианта:
Проигнорировать и получить оплату за следующий месяц. (253 IPv4 адреса это порядка 25 тыс руб ) И потенциальный и низкий риск когда-нибудь быть вовлеченным как свидетель правонарушения о котором ничего не знали, которое происходило на территории чужого государства. Не связанного с большим ущербом. Произошедшего отчасти по вине технического специалиста жертвы.
Отреагировать и 1. потерять клиента. 2. Потратить время технического специалиста 3. потратить время юридического специалиста. 4. Потенциально получить отзыв о том что неправомерно отключили на основе беспочвенной жалобы из интернета. И еще много разных других плюшек.
Мне было-бы очень интересно услышать ваши аргументы по вопросу того почему провайдер должен предпочесть вариант 2.
С одной стороны логично, зачем реагировать на жалобы людей из интернета?
В полицию идти тоже особо не с чем. Ну шлет кто то в интернете кому-то сообщения, где тут криминал. Максимум хулиганство, да и то не особо внятное.
Даже если заявление примут, то доказать факт нарушения сложно и дорого. Может и самому за поклеп наказание прилететь.
В моем случае помог ответ http сервера:
HTTP/1.1 301 Moved Permanently
Location: Ссылка на оооочень большой файл оставленный каким то провайдером в интернете чтобы проверять какая у них хорошая скорость скачивания.
Идея интересная.
Завести зоопарк ботов размером с интернет.
У меня был случай, когда злоумышленники нашли уязвимость в апи сервера и долбили по ней без остановки на обед и выходные с разных адресов не взирая на результативонсть. Даже после полной блокировки всех участвующих в атаке IP атака продолжалась несколько месяцев. Никакие жалобы и обращения к провайдеру атакующих не имели никакого успеха.
Исходя из логики описанных вами процессов — а именно отсутствие реакции многих ботов на удачное инфицирование. Говорит о том что хост жертвы может заноситься в базу данных, а это в дальнейшем может привести к тому что IP машины использованный в эксперименте будет испачкан и может подвергнуться более детальному долговременному воздействию.
Согласен с вами const в данном случае уместен и скорее всего поможет оптимизатору принять правильное решение. Может быть даже constexpr.
Что касается сравнения с nullptr это обсуждали выше в комментариях.
Бесспорно, раздвоение сущностей — путь к ошибкам. Однако, разделение условий на понятные составляющие может исключить ошибки и поспособствовать при проверке.
Т.е. в имени переменной заключается текстом что конкретно проверяется в условном выражении. В случае из статьи это не так принципиально, но когда условий несколько и они сложно сочетаются очень удобно прямо текстом написать что каждое из условий проверяет.
И конечно здорово, что среда разработки уже умеет находить подобные проблемы.
Если вы владелец своей конторы, то вы понимаете, что с вами работают не за количество переложенных джейсонов, хотя жестко косячить конечно не нужно. Я не продаю скиллы, они сами собой торгуют. К эффективности апеллируют если кто-то накосячил со сроками, а виноваты в этом многие, а не кто-то один.
Я во многом с Вами согласен и даже не хочу спорить. Просто диапазон возможных превращений бизнеса достаточно широк от "Рабовладения" до "Богадельни" есть масса точек достижения комфортного равновесия.
Оптимальный набор команды это широко известная и достаточно изученная тема. Теория, да и практика гласит что в любой команде есть набор ролей которые распределятся между людьми. При этом есть набор темпераментов которым свойственны некоторые алгоритмы поведения. Несоответствие темперамента и роли приведет к ухудшению общих результатов команды. Если вы наберете команду лидеров то они будут плохо уживаться друг с другом, если вы наберете команду исполнителей то не будет инициативы, если вы наберете команду из перфекционистов они завязнут в деталях, а если в команде будут одни шейперы, то любой проект погибнет из за размера технического долга и недоделок. Есть профессионально бесполезные роли, однако их вклад в общее дело при этом может быть значительным. (Похоже этот случай описан в статье)
Если оценивать всех исключительно по скорости и количеству исполнения тикетов то приходим к безынициативной и бесперспективной команде от которой нечего ждать.
Оптимальная команда это набор людей разных темпераментов работающих сообща для достижения общей цели.
Немалую роль в достижениях команды несет лидер, он должен защитить вот этот странный коллектив из себя, исполнителей, перфекционистов и раздолбаев от нападок извне и распределить задачи свойственные темпераменту каждого. Если он не справляется, то сотрудники теряют мотивацию и команда рушится и работает плохо.
Если он при любом удобном случае переформатирует команду то роли тоже начинают меняться и команда работает хуже чем вариант с устоявшимися ролями.
Когда лидер по своей сути лидером не является является ему технически выгодно сваливать провалы проекта на исполнителей вместо того чтобы биться с равными за своих "котят" и искоренять причину проблемы. Судя по всему в статье как раз зачатки подобного и имеют место быть. Лидер видит что есть человек который повышает качество работы команды, хотя сам тикеты не очень решает…
Иногда временные рамки существования команды не позволят решить проблем и тогда нужно искать административные рычаги. Но доля подобных проблем должна быть исчезающе мала, что будет свидетельствовать о здоровье коллектива.
А зарплата на карточку, и рабочее место с кофе и печеньками это же базовые потребности, не будет их люди сами убегут… Вы себе не представляете какое счастье работать в коллективе целеустремленных единомышленников. Как в рекламе щуплый такой тренер выходит и говорит двум качкам — "Ребята, может поработаем", качки ему отвечают "ТРЕНЕР СКАЗАД НАДО, ЗНАЧИТ НАДО".
Отчасти невозможно с Вами не согласиться. Однако, у каждой медальки есть две стороны.
О котенке я говорю не в профессиональном смысле, но в смысле ответственности руководителя за каждого подопечного, даже за суперпрофи. Если вы микроскопом забьете гвоздь то в профессиональном смысле точнейший инструмент испортится И его нужно будет заменить, но нужно будет заменить и следующий микроскоп и т.д. И такое поведение руководства встречается сплошь и рядом...
Если вдруг человек никогда не был профессионально годен, то почему он прошел испытательный срок? А если все было нормально, то что изменилось? Может быть тут проблема вовсе не в этом человеке?
Успех управления-- это выравнивание векторов усилий каждого сотрудника компании в одном направлении. Успех бизнеса это правильно поставленная задача призванная сделать жизнь лучше и успех управления.
Далеко не факт что задачи поставленные "Бизнесом" вообще кому-то нужны. Как показывает статистика прогорания стартапов, вообще не факт что нужны, а многие задачи спущенные вниз даже вредны. И очень может быть что правильный анализ этого вопроса позволил бы более эффективно выбирать направление деятельности а не гробить микроскопы и мучить котят.
Ну и увещевания человеку — работай лучше. Я пробовал так со своими детьми. Дети учитесь лучше! Не работает. Чтобы человек лучше работал нужны условия при которых этот человек будет работать лучше и для каждого такие условия свои. Но в основном нужно показать человеку что в вашем понимании хорошая работа.
Вы меня поняли не совсем верно. Нельзя это неправильное слово, можно.
Но будет ли это наилучшим решением?
Почему ваш гипотетический человек не стремится работать лучше? Может ему что-то мешает? А может работа которую в этой команде делают не нужна ему/никому?
Пожалуй, в этом не должен разбираться работодатель и лидер маленького коллектива, но тогда кто?
Вы подобрали на улице котенка, он вам понравился, он бегал и сломал лапку, теперь этот котенок инвалид. Нужно ли его кормить, кто должен его кормить? Так же и сотрудник устраивал вас когда-то, а сегодня он вас раздражает. Почему?
Да потому что он не вписывается в какие-то рамки которые ничего не имеют общего с успехом. Что такое успех? Какие цели у успешных компаний? Заработать много денег? Нет, у действительно успешных компаний цель сделать жизнь в мире лучше и удобнее (Хотя может это такой ПР шаг).
Как пример социальной ответственности мне кажется лучше всего подходят тюрьмы в Норвегии. Социальный институт призванный исправить неправильное поведение индивида. Не наказать человека, но перевоспитать. Не знаю насколько у них там все получается, но звучит правильно. Если человек заболел его нужно полечить, а не добить.
Люди размышляют о том как оценить работу и эффективность. Как и в сообществе зверей слабых заклевывают, сильные получают лучший кусок.
Но, если посмотреть на картину глобально, то окажется что одним из основных стимулов заставивших человека добраться до вершины пищевой цепочки является слабость новорожденного, который, в отличии от новорожденных других видов вообще не способен к самостоятельному существованию. Даже голова не держится и нужно ее осторожно придерживать. Кто там еще на вершине? Вирусы? Грибы? Что нас от них отличает?
Избавляясь от слабых мы в какой то мере стратегически убиваем перспективу. Кто сказал, что вот этот неэффективный сегодня специалист не станет ключевой причиной развития?
А зачем вообще поддерживать старых, больных, немощных? Нужно всех измерить, сравнить с критерием и наступит счастье…
Приведенные рассуждения сильно утрированы, чтобы показать насколько опасен выбранный путь. Измерили, уволили всех плохих и стало лучше. Нет, хорошо будет только тогда, когда получится создать гармонично развивающуюся группу. Когда люди не конкурируют за, но поддерживают друг друга, и это несколько другой уровень развития.
Только в человеческом обществе поддерживают старых и больных и это характеризует отличный духовный уровень развития. Вот ежели бы вопрос ставился не о том как измерить неэффективных сотрудников, а как помочь неэффективному стать лучше…
Вот тут где-то зарыта собака. Но мы думаем о КПИ...
Тогда не очень понятно как ваши вычисления могут занимать минуты, если исходить из того что в слое 200 на 200 точек то он будет обрабатываться за доли секунды.
Интересная задачка
Вы поставили перед собой цель смоделировать дифракцию через численное нахождение интеграла Френеля методом Монте-Карло.
И визуально сравнили полученный результат с наблюдаемым в результате эксперимента.
Полученный результат интегрирования ожидаемо дал значения заложенные в теоретическую модель.
В статье смущает вот что: длительность вычисления зависит от количества точек для которых проводится расчет. Очевидно -- взяв меньше точек вы сможете оптимизировать трудозатраты при сохранении визуализации. (Как вы выбирали дискретность вашего расчета?)
Очень похоже что в наличии ошибка наименования осей на графике, там где должна быть интенсивность поля указана координата Y.
В отношении пятна Пуассона, вы получаете интенсивность исходного поля, которая похоже задается как 1, просто исходя из того что exp(0) == 1;
Прочитал статью и как интересно она отражает реальность. Доктора обсуждают болезни, танцоры движения, писатели сюжеты для книг. А тут программисты обсуждают неразрешимые проблемы программирования. Которые на поверку оказываются социальными.
У программирования как раздела математики нет проблем, просто потому что проблемы математики носят не прикладной, а теоретический характер и являются не столько проблемами, сколько законами и ограничениями мироустройства, зато у программирования есть проблемы социальные.
Как подобрать коллектив, как наладить работу, как настроить постороннего человека выполнять задачи поставленные перед коллективом, как наладить образование. Это из того что раскрыто в статье, а за кадром наверное осталось, как удержать спрос, как монетизировать фичи, как не вляпаться в налоговые и административные ограничения, как не накосячить в других аспектах.
Программирование из раздела сакральных знаний выходит в массы и как результат критерии отбора становятся более ремесленными. Раньше в этой области трудились победители математических олимпиад и на собеседовании их пытались выявлять, задавая олимпиадные задачки, а теперь нужно найти человека который будет тянуть рутину.
Раньше куски кода рождались с целью превозмочь ограничения реальности на каждом шагу, а нынче нужно просто прикручивать фичу к уже существующему коду, в котором нужно хоть немного разобраться и впаять костыль, так чтобы и дальше можно было поддерживать работающую кодовую базу.
Очень похоже, что в программировании мы столкнулись с кризисом идей, не появляется новых программ. Картинки меняются а суть остается прежней. Во главу угла поставлена монетизация.
Новые идеи не требуют всего того что описано в статье. Если для реализации идеи нужно больше чем 1 человек, то это скорее всего не самая лучшая идея. Для реализации алгоритма обратного распространения ошибки не нужна команда из 100 человек... И ТДД с УМЛ тоже будут только удлинять путь от идеи к монетизации.
Как итог в коде рожденном на базе идеи нет документации, нет комментариев. Все это приходит на этапе, когда более менее удачную идею начинают насыщать маркетинговыми фичами и нанимают "команду".
Мы наблюдаем то, что новое, пока еще не устоявшееся ремесло начинает обрастать терминологией, критериями успеха, процессами. Мы просто наблюдаем как программирование растет и переживает кризисы взросления. Мы счастливые люди, на нашем веку программирование из ассемблерных кодов развилось в социальное явление.
А проблемы программирования это наверное все же нечто совсем другое и гораздо более математически точное.
Именно такие знания и отличают профессионала от любителя. В моей любительской практике я крайне редко сталкиваюсь с макросами и не обратил внимания на факт наличия или отсутствия ';'
Действительно подумал, а почему бы просто не использовать фигурные скобки, вместо обработки условия, но решил, что с макросом так не сработает.
Так что спасибо, за то что обратили мое внимание на существенный факт написания заготовки для функции в в обертке do{}while(0)
Очень интересная и познавательная статья.
Помню, как в свое время меня удивило отсутствие возможности получить имя элемента енум и возможность конвертировать его в строковое значение.
А нынче, прочитав набор ваших пожеланий, увидел массу интересных и хорошо проработанных алгоритмов по которым многому можно было бы научиться.
Понравилась конструкция do {} while(0); в макросе.
Хотелось бы чаще встречать подобные статьи.
PS. И картинка в заголовке вообще супер.
Эволюция интерфейсов прошла путь от редактора перфокарт до 3д моделирования 4д объектов голосовыми командами с использованием ИИ.
За это время накопилось огромное количество людей, которые привыкли к тем или иным элементам управления, которые они использовали многие годы каждый день. И теперь любое движение и изменение будет находить своих отпетых сторонников и ярых противников.
Все то обилие и пестрота интерфейсов доступных в сети говорит о том, что не существует единого стандарта на основе которого каждый будет взаимодействовать с пользователем.
А вот в Windows до определенного момента все интерфейсы были более менее стандартизованы и да поддавались модификации ( Но кто бы этим занимался если есть хороший стандартный набор элементов более менее хорошо настроенных по умолчанию ( Включая полосы прокрутки и прочие удобства (MFC)) отсутствие которых смущает автора.
При этом в сети стандартный интерфейс не прижился. Наличие стандартных кнопок на пестрых раскрашенных страницах сети выглядит плохо, а прибыльность и удобство явно не коллинеарные понятия. Красочный рекламный баннер-кнопка монетизируется лучше чем невзрачная серая кнопка интерфейса управления.
А так как добавление каждого инструмента управления требует затрат не только на программиста но и на дизайнера и на художника и на тестировщика и еще использование какой-нибудь загадочной библиотеки которая завтра перестанет работать. В общем чем меньше тем лучше. Вот и идем мы от серьезно проработанного интерфейса читалки для fido к непонятным одностраничным приложениям в телефон задача которых заставить тебя ввести телефон и почту и получать коммерческие предложения.
Как по мне, статьи в которых автор подробно рассказывает о разработке ПО от самых базовых математических основ и до работающего кода являются наиболее ценными.
В данной статье не только описана модель и ее реализация, но и очень чистый и красивый код. Приятно почитать. Кроме того, чтобы увидеть результат автор не поленился и подготовил визуализацию.
И Вам еще сильно повезло, в большинстве случаев даже умножение это уже большой прогресс.
На базараки есть такие карты. :)
Уж как есть.
Вам поступает жалоба на клиента который платит вам денежку от непонятно кого из интернета. У вас два варианта:
Мне было-бы очень интересно услышать ваши аргументы по вопросу того почему провайдер должен предпочесть вариант 2.
С одной стороны логично, зачем реагировать на жалобы людей из интернета?
В полицию идти тоже особо не с чем. Ну шлет кто то в интернете кому-то сообщения, где тут криминал. Максимум хулиганство, да и то не особо внятное.
Даже если заявление примут, то доказать факт нарушения сложно и дорого. Может и самому за поклеп наказание прилететь.
В моем случае помог ответ http сервера:
HTTP/1.1 301 Moved Permanently
Location: Ссылка на оооочень большой файл оставленный каким то провайдером в интернете чтобы проверять какая у них хорошая скорость скачивания.
Идея интересная.
Завести зоопарк ботов размером с интернет.
У меня был случай, когда злоумышленники нашли уязвимость в апи сервера и долбили по ней без остановки на обед и выходные с разных адресов не взирая на результативонсть. Даже после полной блокировки всех участвующих в атаке IP атака продолжалась несколько месяцев. Никакие жалобы и обращения к провайдеру атакующих не имели никакого успеха.
Исходя из логики описанных вами процессов — а именно отсутствие реакции многих ботов на удачное инфицирование. Говорит о том что хост жертвы может заноситься в базу данных, а это в дальнейшем может привести к тому что IP машины использованный в эксперименте будет испачкан и может подвергнуться более детальному долговременному воздействию.
Ну, с такой же вероятностью у вас будет мусор в SomeGlobalPointer ...
Согласен с вами const в данном случае уместен и скорее всего поможет оптимизатору принять правильное решение. Может быть даже constexpr.
Что касается сравнения с nullptr это обсуждали выше в комментариях.
Бесспорно, раздвоение сущностей — путь к ошибкам. Однако, разделение условий на понятные составляющие может исключить ошибки и поспособствовать при проверке.
Да интересная ошибка, с одной стороны все очень просто, а с другой стороны вот из таких простых ошибок все проблемы и складываются.
Тут люди делились грамотными методами написания кода, которые позволяют таких ошибок избежать, мне всегда был близок следующий подход:
Т.е. в имени переменной заключается текстом что конкретно проверяется в условном выражении. В случае из статьи это не так принципиально, но когда условий несколько и они сложно сочетаются очень удобно прямо текстом написать что каждое из условий проверяет.
И конечно здорово, что среда разработки уже умеет находить подобные проблемы.
Если вы владелец своей конторы, то вы понимаете, что с вами работают не за количество переложенных джейсонов, хотя жестко косячить конечно не нужно. Я не продаю скиллы, они сами собой торгуют. К эффективности апеллируют если кто-то накосячил со сроками, а виноваты в этом многие, а не кто-то один.
Я во многом с Вами согласен и даже не хочу спорить. Просто диапазон возможных превращений бизнеса достаточно широк от "Рабовладения" до "Богадельни" есть масса точек достижения комфортного равновесия.
Оптимальный набор команды это широко известная и достаточно изученная тема. Теория, да и практика гласит что в любой команде есть набор ролей которые распределятся между людьми. При этом есть набор темпераментов которым свойственны некоторые алгоритмы поведения. Несоответствие темперамента и роли приведет к ухудшению общих результатов команды. Если вы наберете команду лидеров то они будут плохо уживаться друг с другом, если вы наберете команду исполнителей то не будет инициативы, если вы наберете команду из перфекционистов они завязнут в деталях, а если в команде будут одни шейперы, то любой проект погибнет из за размера технического долга и недоделок. Есть профессионально бесполезные роли, однако их вклад в общее дело при этом может быть значительным. (Похоже этот случай описан в статье)
Если оценивать всех исключительно по скорости и количеству исполнения тикетов то приходим к безынициативной и бесперспективной команде от которой нечего ждать.
Оптимальная команда это набор людей разных темпераментов работающих сообща для достижения общей цели.
Немалую роль в достижениях команды несет лидер, он должен защитить вот этот странный коллектив из себя, исполнителей, перфекционистов и раздолбаев от нападок извне и распределить задачи свойственные темпераменту каждого. Если он не справляется, то сотрудники теряют мотивацию и команда рушится и работает плохо.
Если он при любом удобном случае переформатирует команду то роли тоже начинают меняться и команда работает хуже чем вариант с устоявшимися ролями.
Когда лидер по своей сути лидером не является является ему технически выгодно сваливать провалы проекта на исполнителей вместо того чтобы биться с равными за своих "котят" и искоренять причину проблемы. Судя по всему в статье как раз зачатки подобного и имеют место быть. Лидер видит что есть человек который повышает качество работы команды, хотя сам тикеты не очень решает…
Иногда временные рамки существования команды не позволят решить проблем и тогда нужно искать административные рычаги. Но доля подобных проблем должна быть исчезающе мала, что будет свидетельствовать о здоровье коллектива.
А зарплата на карточку, и рабочее место с кофе и печеньками это же базовые потребности, не будет их люди сами убегут… Вы себе не представляете какое счастье работать в коллективе целеустремленных единомышленников. Как в рекламе щуплый такой тренер выходит и говорит двум качкам — "Ребята, может поработаем", качки ему отвечают "ТРЕНЕР СКАЗАД НАДО, ЗНАЧИТ НАДО".
Отчасти невозможно с Вами не согласиться. Однако, у каждой медальки есть две стороны.
О котенке я говорю не в профессиональном смысле, но в смысле ответственности руководителя за каждого подопечного, даже за суперпрофи. Если вы микроскопом забьете гвоздь то в профессиональном смысле точнейший инструмент испортится И его нужно будет заменить, но нужно будет заменить и следующий микроскоп и т.д. И такое поведение руководства встречается сплошь и рядом...
Если вдруг человек никогда не был профессионально годен, то почему он прошел испытательный срок? А если все было нормально, то что изменилось? Может быть тут проблема вовсе не в этом человеке?
Успех управления-- это выравнивание векторов усилий каждого сотрудника компании в одном направлении. Успех бизнеса это правильно поставленная задача призванная сделать жизнь лучше и успех управления.
Далеко не факт что задачи поставленные "Бизнесом" вообще кому-то нужны. Как показывает статистика прогорания стартапов, вообще не факт что нужны, а многие задачи спущенные вниз даже вредны. И очень может быть что правильный анализ этого вопроса позволил бы более эффективно выбирать направление деятельности а не гробить микроскопы и мучить котят.
Ну и увещевания человеку — работай лучше. Я пробовал так со своими детьми. Дети учитесь лучше! Не работает. Чтобы человек лучше работал нужны условия при которых этот человек будет работать лучше и для каждого такие условия свои. Но в основном нужно показать человеку что в вашем понимании хорошая работа.
Вы меня поняли не совсем верно. Нельзя это неправильное слово, можно.
Но будет ли это наилучшим решением?
Почему ваш гипотетический человек не стремится работать лучше? Может ему что-то мешает? А может работа которую в этой команде делают не нужна ему/никому?
Пожалуй, в этом не должен разбираться работодатель и лидер маленького коллектива, но тогда кто?
Вы подобрали на улице котенка, он вам понравился, он бегал и сломал лапку, теперь этот котенок инвалид. Нужно ли его кормить, кто должен его кормить? Так же и сотрудник устраивал вас когда-то, а сегодня он вас раздражает. Почему?
Да потому что он не вписывается в какие-то рамки которые ничего не имеют общего с успехом. Что такое успех? Какие цели у успешных компаний? Заработать много денег? Нет, у действительно успешных компаний цель сделать жизнь в мире лучше и удобнее (Хотя может это такой ПР шаг).
Как пример социальной ответственности мне кажется лучше всего подходят тюрьмы в Норвегии. Социальный институт призванный исправить неправильное поведение индивида. Не наказать человека, но перевоспитать. Не знаю насколько у них там все получается, но звучит правильно. Если человек заболел его нужно полечить, а не добить.
Люди размышляют о том как оценить работу и эффективность. Как и в сообществе зверей слабых заклевывают, сильные получают лучший кусок.
Но, если посмотреть на картину глобально, то окажется что одним из основных стимулов заставивших человека добраться до вершины пищевой цепочки является слабость новорожденного, который, в отличии от новорожденных других видов вообще не способен к самостоятельному существованию. Даже голова не держится и нужно ее осторожно придерживать. Кто там еще на вершине? Вирусы? Грибы? Что нас от них отличает?
Избавляясь от слабых мы в какой то мере стратегически убиваем перспективу. Кто сказал, что вот этот неэффективный сегодня специалист не станет ключевой причиной развития?
А зачем вообще поддерживать старых, больных, немощных? Нужно всех измерить, сравнить с критерием и наступит счастье…
Приведенные рассуждения сильно утрированы, чтобы показать насколько опасен выбранный путь. Измерили, уволили всех плохих и стало лучше. Нет, хорошо будет только тогда, когда получится создать гармонично развивающуюся группу. Когда люди не конкурируют за, но поддерживают друг друга, и это несколько другой уровень развития.
Только в человеческом обществе поддерживают старых и больных и это характеризует отличный духовный уровень развития. Вот ежели бы вопрос ставился не о том как измерить неэффективных сотрудников, а как помочь неэффективному стать лучше…
Вот тут где-то зарыта собака. Но мы думаем о КПИ...