Разочарование, стресс, профессиональное выгорание — частая причина конфликтов с практически детской основой: «почему меня не любят», «меня никто не понимает», «мне тяжело», «я не хочу»…
Когда ожидания сталкиваются с реальностью, внутри нас начинает бунтовать тот самый «внутренний ребёнок», которому не дали конфетку. Но поскольку лечь на пол и закатить истерику в офисе не получается, мы приходим к стрессу и выгоранию
Интересные у вас, конечно, коннотации к проблеме стресса на рабочем месте.
Деградация от рационального к инфантильному мышлению происходит именно, потому что, рационально проблему решить не получается. Происходит это исключительно по вине руководителя, который не способен создавать адекватные условия труда.
Но почему-то в вашем списке главных причин конфликтов нет ни слова про компетенции менеджеров. Опять эти капризные исполнители во всём виноваты.
Некоторые топовые сотрудники уже получают более 500 тысяч рублей в месяц и требования к уровню зарплаты лишь растут.
Реальные зарплаты растут не сильно. Цифры стали больше потому что компании стали чаще оформлять по ИП. В пересчете на ТК, это всё те же 350к рублей на позицию ведущего IT специалиста. А в пересчете на инфляцию и реальное обеспечение, это примерно 200к как и 5 лет назад.
Никто вам не заплатит в российской компании 500к на руки по ТК, то есть 750к с налогами (для компании) на рядовой позиции разработчика, пусть и топовой квалификации.
Ага, согласен. Вопрос выбора правильных терминов и понятий — задача не из лёгких. А когда используешь что-то большое вроде "действительности" так вообще. Попробую почитать Калугина. Я в принципе всегда рад узнать новые точки зрения на интересующие темы.
В своё время меня поразила мысль что фантастики может и не существует вовсе. Действительность — она одна у человека, занимает всё его воображение. Особенно это хорошо видно в научной фантастике, где за межгалактическими пространствами и космолётами часто скрываются обычные морские приключения и средневековые междоусобные войны.
Так я и не описывал игровой процесс DF, с чего вы взяли? С того что и там и там есть влажность земли?
Это потому что хороший игровой процесс всегда отражает действительность. Если начать погружаться в то, что такое фермерство в реальности, вы неизбежно столкнётесь с первоочередными аспектами: почва, влага, свет, эрозия, и т.д.
Точно определить жанр можно только на поздних стадиях разработки игры. Получится в итоге условный Stardew Valley, или зубодробительный симулятор про почвообразование на терраформированих планетах — зависит от того как игровой дизайнер сведёт игровой баланс и другие аспекты игры: эстетику, динамичность, размер бюджета на разработку, в конце концов.
Это важные моменты, когда мы говорим про фермерство на других планетах Солнечной системы (по идее эти планеты отличаются разными условиями окружающей среды, в том числе разной освещенностью, температурой, длительностью времён года). Смотрите на графике список всех механик. Сезонность и освещение в механиках «ход времени» и «свет» соотвественно.
Но для статьи не нашлось столько смыслового материала, чтобы включить описание всех механик в качестве иллюстраций.
Если вы намекаете, что я просто пересказал вики DF, это конечно не так. Я бы сказал, это подтверждение идей изложенных в статье. Если игровой процесс действительно отражает тему окружающей действительности, не удивительно что в другой игре будут похожие аспекты из этой же темы.
Насчёт всего остального. Быть оригинальным автором — не значит использовать устаревшие и неэффективные средства.
Графики и формализмы в статье это не признак промышленного производства, а свежий взгляд на то, как игровой дизайнер может работать в наше время, используя компьютер по полной.
Да, может я немного преувеличиваю когда говорю что использовать Unity3D так же просто, как вырезать из бумаги фигурки. Но это точно даёт больше возможностей. Тратить на изучение новых инструментов своё время или нет — это уже выбор каждого.
Спасибо, не могу согласиться с вашими комментариями. Скорей всего, потому что у нас очень разные взгляды на игру, а точно передать мысли в предложениях не получается.
Я старовер. Я всё ещё топлю за то, что авторский вижен - первичен. За то, что границы есть и паттерны есть - но их НАДО регулярно ломать, чтобы не уйти в самоповторение и деградацию. Что надо гнуть код под пользователя, а не наоборот, - не меняя при этом вижена.
Для меня первичен замысел игрока. Я считаю, что игровой процесс создаёт сам игрок. Вижен игрового дизайнера и набор игровых правил — это исходный материл, который интерпретирует и использует играющий как ему удобно.
На хороший геймплей можно натянуть любую тему и получить хороший результат. Но не наоборот.
Опять же, мозгами я понимаю, что Вы имеете в виду "промышленное" производство игры, когда первые два компонента из трёх кем-нибудь да заданы. Но молодёжь может сделать из этого неверные выводу.
Нет. Статья как раз о том что хороший игровой процесс, вопреки современным представлениям отрасли, это не шаблон, на который натягивается произвольная тема и рескин.
Игровой процесс, который приводит к новому опыту, удовольствию и удовлетворению не может быть шаблонным. Хорошая игра — это отражение конкретной темы через действия игроков, которые всегда подчиняются определенной роли.
Понятие роли при этом не имеет никакого отношения к жанровой классификации. Роль — это и есть замысел игрока, реакция и модель поведения в заданных сюжетных рамках. В Age of Empires вы можете быть агрессивным варваром, который устраивает набеги на крестьян противника, доблестным полководцем, который выстраивает отряды для сражения в чистом поле, или расчетливым стратегом, который изматывает противников от защиты собственного замка — всё это роли, которые по разному раскрывают тему средневековых сражений.
Игрок конечно может менять свою роль, если текущая его не устраивает, или он просто хочет чего то нового. Расщепление личности при этом не происходит, это нормальный процесс.
Аналогия прямая. Таксист вам оказывает услугу, транспортирует ваше тело в другое место, в котором у вас очевидно есть какие-то дела. Разработчик точно так же оказывает услугу по развитию компании, только через программное обеспечение, а не автомобиль.
Предлагаю на собеседовании обсуждать реальные задачи компании, которые предстоит решать.
Обсуждение ведь и есть настоящая работа, первый этап любой задачи. Не надо моделировать ситуации и что-то там проверять искусственно. Если интервьюер не способен в процессе такого обсуждения отличить сладкие беседы от дельных предложений — это вопрос его компетенций.
Другое дело конечно, если надо "работать", то есть сидеть в штате ровно как можно дольше. Тогда, да, надо проверить что человек хороший и надёжный! Без шуток, надо проверить по всем параметрам: образование, военный билет, медкомиссию, наличие профессиональных сертификатов, алгоритмы...
Вы когда хотите воспользоваться услугой стоматолога, сантехника или таксиста. Как выбираете специалиста? Отправляете им тестовое задание или спрашиваете теорию по специальности? С разработчиками так же.
Лучше обсуждать в формате диалога предстоящие задачи бизнеса в контексте опыта кандидата. Если хотите, идеальное собеседование — это консультация у разработчика по вопросам решения ваших задач.
В процессе такого диалога можно узнать наличие навыков по вашим технологиям и насколько продуктивным может быть сотрудничество. Разве это не главное?
А разве такие рабочие ситуации бывают? Приходит продукт менеджер и говорит: "отсортируй пузырьком клиентов по дате подписки". У вас такое бывало?
По-моему, разработчику гораздо чаще приходится направлять свои благодетели на анализ предметной области и совместное с бизнесом планирование сроков.
Как правило задачи от бизнеса выглядят так:
Птица летит на юг, лодка идёт на встречу с заданной скоростью. Сделай такой сервис, чтобы мы могли продолжить платить нашим курьерам прежнюю зарплату за большее количество заказов. Два дня на бэкенд? А чего так долго?
Вам разве не хочется узнать насколько комфортно с кандидатом будет решать подобные задачи? Насколько у него развит кругозор, предприимчивость, способность делать технические решения подходящие реальным задачам бизнеса.
Всего этого не узнать, если потратить внимание и заинтересованность кандидата на придумывание алгоритмов в стрессовой ситуации.
Приходит повар в ресторан на собеседование, а ему говорят, приготовь нам соус бешамель по-азиатски. Ну а что, вполне понятное желание посмотреть на кулинарные способности.
Если серьёзно, наличие алгоритмической секции может означать одно из двух. Либо в компании техническая бюрократия, либо интервьюер не умеет проводить собеседования. В любом случае, в таком месте лучше не работать.
Справедливости ради, некоторые обидчивые люди воспринимают ответ с отказом как приглашение к диалогу, начинают выяснять подробности, бывает даже оскорблять. Если компания решила не иметь с вами дел, HR "безопаснее" ничего не отвечать.
Я бы развернул мысль. За мотивацией стоит постоянное профильное развитие и разработка IT проектов даже в свободное от работы время. Компании по факту платят за этот опыт и навыки, а не какую-то особую мотивацию.
А большинство вайтишников приходят и буквально ждут должностную инструкцию, выполнив которую они хотят получать те же самые деньги. Естественно, никто за это платить не будет.
Получается он как получал начальником склада свои 100р так и получает на позиции айтишника, только еще дополнительно нужно вникать в сложные инженерные практики. Как тут не разочароваться.
А мне так же забавно наблюдать как разработчики сначала берут Java/.Net, тратят буквально недели на обсуждения очередного интерфейса или абстрактного класса, чтобы достичь необходимой гибкости архитектуры. И в конечном итоге всё равно из-за нехватки производительности изучают твики виртуальной машины, изобретают всякие костыли для ручного управления памятью и прочее.
Пренебрежительное отношение к скриптовым языкам может быть разве что от незнания бытовой мудрости — какой бы язык не выбрал, всё равно найдутся функциональные блоки, которые будет выгоднее переписать на другом языке.
Очередной виток развития технологий сейчас выводит в тренды "low-code" решения для разработки ПО, в основе которых, как правило, BPMN. Много их. Кроме упомянутого в статье, вот например Camunda.
Программисты пишут отдельные функциональные блоки типа "отправить вопрос", "обработать ответ" специфичные для чат-платформы, а все диалоговое дерево бота строится уже аналитиками средствами BPMN редактора.
В идеале это конечно мечта любого топ-менеджера по разработке ПО. Умные разработчики не нужны, системные аналитики не нужны, проектировать не надо, тестировать не надо. Взял одного бизнес-аналитика, составил с ним BPMN диаграмму на понятном бизнесу языке, и вот вам программное обеспечение для любого бизнес процесса. Красота.
На практике это работает только в определенных сферах бизнеса, с высокой степенью регламентированности процессов.
Практически любая нотация выглядит понятно и привлекательно на простых процессах. Ваш пример регистрации пассажира — по сути диаграмма последовательности (которая бы ещё выиграла в читаемости без лишней строгости BPMN).
Можете показать сложный пример использования BPMN, где участвует 4 или больше сторон непоследовательно?
Часто настройка цветов диаграммы и расположения элементов это не просто эстетический момент, но и прямое требование к оформлению документации или презентации компании, согласно её дизайн коду.
Не говоря уже о косяках которые проявятся если сильно менять содержимое диаграмм.
Получить такой прикол обычное дело даже на простых диаграммах
Весь выигрыш скорости от ручного редактирования придется потратить на решение проблем визуального представления.
Поддерживаю и добавлю еще что решает экспертность в предметной области и личная мотивация ревьюера вносить качественные изменения в рассматриваемый код. Должность тут никак не влияет.
Представьте, например, что ведущий разработчик, который занимается разработкой нового веб движка, вынужден смотреть все коммиты джунов, которые верстают лендинг. В лучшем случае это будет бесполезная трата времени, без каких либо результатов.
Просто речь не про тех мидлов и джунов, которые работают. А про тех, что числятся в расчете бюджета перед инвестором (материнской компанией).
Интересные у вас, конечно, коннотации к проблеме стресса на рабочем месте.
Деградация от рационального к инфантильному мышлению происходит именно, потому что, рационально проблему решить не получается. Происходит это исключительно по вине руководителя, который не способен создавать адекватные условия труда.
Но почему-то в вашем списке главных причин конфликтов нет ни слова про компетенции менеджеров. Опять эти капризные исполнители во всём виноваты.
Реальные зарплаты растут не сильно. Цифры стали больше потому что компании стали чаще оформлять по ИП. В пересчете на ТК, это всё те же 350к рублей на позицию ведущего IT специалиста. А в пересчете на инфляцию и реальное обеспечение, это примерно 200к как и 5 лет назад.
Никто вам не заплатит в российской компании 500к на руки по ТК, то есть 750к с налогами (для компании) на рядовой позиции разработчика, пусть и топовой квалификации.
Ага, согласен. Вопрос выбора правильных терминов и понятий — задача не из лёгких. А когда используешь что-то большое вроде "действительности" так вообще. Попробую почитать Калугина. Я в принципе всегда рад узнать новые точки зрения на интересующие темы.
В своё время меня поразила мысль что фантастики может и не существует вовсе. Действительность — она одна у человека, занимает всё его воображение. Особенно это хорошо видно в научной фантастике, где за межгалактическими пространствами и космолётами часто скрываются обычные морские приключения и средневековые междоусобные войны.
Так я и не описывал игровой процесс DF, с чего вы взяли? С того что и там и там есть влажность земли?
Это потому что хороший игровой процесс всегда отражает действительность. Если начать погружаться в то, что такое фермерство в реальности, вы неизбежно столкнётесь с первоочередными аспектами: почва, влага, свет, эрозия, и т.д.
Точно определить жанр можно только на поздних стадиях разработки игры. Получится в итоге условный Stardew Valley, или зубодробительный симулятор про почвообразование на терраформированих планетах — зависит от того как игровой дизайнер сведёт игровой баланс и другие аспекты игры: эстетику, динамичность, размер бюджета на разработку, в конце концов.
Это важные моменты, когда мы говорим про фермерство на других планетах Солнечной системы (по идее эти планеты отличаются разными условиями окружающей среды, в том числе разной освещенностью, температурой, длительностью времён года). Смотрите на графике список всех механик. Сезонность и освещение в механиках «ход времени» и «свет» соотвественно.
Но для статьи не нашлось столько смыслового материала, чтобы включить описание всех механик в качестве иллюстраций.
Если вы намекаете, что я просто пересказал вики DF, это конечно не так. Я бы сказал, это подтверждение идей изложенных в статье. Если игровой процесс действительно отражает тему окружающей действительности, не удивительно что в другой игре будут похожие аспекты из этой же темы.
Насчёт всего остального. Быть оригинальным автором — не значит использовать устаревшие и неэффективные средства.
Графики и формализмы в статье это не признак промышленного производства, а свежий взгляд на то, как игровой дизайнер может работать в наше время, используя компьютер по полной.
Да, может я немного преувеличиваю когда говорю что использовать Unity3D так же просто, как вырезать из бумаги фигурки. Но это точно даёт больше возможностей. Тратить на изучение новых инструментов своё время или нет — это уже выбор каждого.
Спасибо, не могу согласиться с вашими комментариями. Скорей всего, потому что у нас очень разные взгляды на игру, а точно передать мысли в предложениях не получается.
Для меня первичен замысел игрока. Я считаю, что игровой процесс создаёт сам игрок. Вижен игрового дизайнера и набор игровых правил — это исходный материл, который интерпретирует и использует играющий как ему удобно.
Нет. Статья как раз о том что хороший игровой процесс, вопреки современным представлениям отрасли, это не шаблон, на который натягивается произвольная тема и рескин.
Игровой процесс, который приводит к новому опыту, удовольствию и удовлетворению не может быть шаблонным. Хорошая игра — это отражение конкретной темы через действия игроков, которые всегда подчиняются определенной роли.
Понятие роли при этом не имеет никакого отношения к жанровой классификации. Роль — это и есть замысел игрока, реакция и модель поведения в заданных сюжетных рамках. В Age of Empires вы можете быть агрессивным варваром, который устраивает набеги на крестьян противника, доблестным полководцем, который выстраивает отряды для сражения в чистом поле, или расчетливым стратегом, который изматывает противников от защиты собственного замка — всё это роли, которые по разному раскрывают тему средневековых сражений.
Игрок конечно может менять свою роль, если текущая его не устраивает, или он просто хочет чего то нового. Расщепление личности при этом не происходит, это нормальный процесс.
Например, в Blender. Я тогда начал писать плагин для экспорта моделей и случайно переквалифицировался с Java на Python.
В начале развития Unity3D была поддержка самостоятельной версии языка Boo.
Ну и образцовый пример — это конечно EVE Online.
Аналогия прямая. Таксист вам оказывает услугу, транспортирует ваше тело в другое место, в котором у вас очевидно есть какие-то дела. Разработчик точно так же оказывает услугу по развитию компании, только через программное обеспечение, а не автомобиль.
Предлагаю на собеседовании обсуждать реальные задачи компании, которые предстоит решать.
Обсуждение ведь и есть настоящая работа, первый этап любой задачи. Не надо моделировать ситуации и что-то там проверять искусственно. Если интервьюер не способен в процессе такого обсуждения отличить сладкие беседы от дельных предложений — это вопрос его компетенций.
Другое дело конечно, если надо "работать", то есть сидеть в штате ровно как можно дольше. Тогда, да, надо проверить что человек хороший и надёжный! Без шуток, надо проверить по всем параметрам: образование, военный билет, медкомиссию, наличие профессиональных сертификатов, алгоритмы...
Вы когда хотите воспользоваться услугой стоматолога, сантехника или таксиста. Как выбираете специалиста? Отправляете им тестовое задание или спрашиваете теорию по специальности? С разработчиками так же.
Лучше обсуждать в формате диалога предстоящие задачи бизнеса в контексте опыта кандидата. Если хотите, идеальное собеседование — это консультация у разработчика по вопросам решения ваших задач.
В процессе такого диалога можно узнать наличие навыков по вашим технологиям и насколько продуктивным может быть сотрудничество. Разве это не главное?
А разве такие рабочие ситуации бывают? Приходит продукт менеджер и говорит: "отсортируй пузырьком клиентов по дате подписки". У вас такое бывало?
По-моему, разработчику гораздо чаще приходится направлять свои благодетели на анализ предметной области и совместное с бизнесом планирование сроков.
Как правило задачи от бизнеса выглядят так:
Вам разве не хочется узнать насколько комфортно с кандидатом будет решать подобные задачи? Насколько у него развит кругозор, предприимчивость, способность делать технические решения подходящие реальным задачам бизнеса.
Всего этого не узнать, если потратить внимание и заинтересованность кандидата на придумывание алгоритмов в стрессовой ситуации.
Приходит повар в ресторан на собеседование, а ему говорят, приготовь нам соус бешамель по-азиатски. Ну а что, вполне понятное желание посмотреть на кулинарные способности.
Если серьёзно, наличие алгоритмической секции может означать одно из двух. Либо в компании техническая бюрократия, либо интервьюер не умеет проводить собеседования. В любом случае, в таком месте лучше не работать.
Справедливости ради, некоторые обидчивые люди воспринимают ответ с отказом как приглашение к диалогу, начинают выяснять подробности, бывает даже оскорблять. Если компания решила не иметь с вами дел, HR "безопаснее" ничего не отвечать.
Я бы развернул мысль. За мотивацией стоит постоянное профильное развитие и разработка IT проектов даже в свободное от работы время. Компании по факту платят за этот опыт и навыки, а не какую-то особую мотивацию.
А большинство вайтишников приходят и буквально ждут должностную инструкцию, выполнив которую они хотят получать те же самые деньги. Естественно, никто за это платить не будет.
Получается он как получал начальником склада свои 100р так и получает на позиции айтишника, только еще дополнительно нужно вникать в сложные инженерные практики. Как тут не разочароваться.
А мне так же забавно наблюдать как разработчики сначала берут Java/.Net, тратят буквально недели на обсуждения очередного интерфейса или абстрактного класса, чтобы достичь необходимой гибкости архитектуры. И в конечном итоге всё равно из-за нехватки производительности изучают твики виртуальной машины, изобретают всякие костыли для ручного управления памятью и прочее.
Пренебрежительное отношение к скриптовым языкам может быть разве что от незнания бытовой мудрости — какой бы язык не выбрал, всё равно найдутся функциональные блоки, которые будет выгоднее переписать на другом языке.
Очередной виток развития технологий сейчас выводит в тренды "low-code" решения для разработки ПО, в основе которых, как правило, BPMN. Много их. Кроме упомянутого в статье, вот например Camunda.
Программисты пишут отдельные функциональные блоки типа "отправить вопрос", "обработать ответ" специфичные для чат-платформы, а все диалоговое дерево бота строится уже аналитиками средствами BPMN редактора.
В идеале это конечно мечта любого топ-менеджера по разработке ПО. Умные разработчики не нужны, системные аналитики не нужны, проектировать не надо, тестировать не надо. Взял одного бизнес-аналитика, составил с ним BPMN диаграмму на понятном бизнесу языке, и вот вам программное обеспечение для любого бизнес процесса. Красота.
На практике это работает только в определенных сферах бизнеса, с высокой степенью регламентированности процессов.
Практически любая нотация выглядит понятно и привлекательно на простых процессах. Ваш пример регистрации пассажира — по сути диаграмма последовательности (которая бы ещё выиграла в читаемости без лишней строгости BPMN).
Можете показать сложный пример использования BPMN, где участвует 4 или больше сторон непоследовательно?
Часто настройка цветов диаграммы и расположения элементов это не просто эстетический момент, но и прямое требование к оформлению документации или презентации компании, согласно её дизайн коду.
Не говоря уже о косяках которые проявятся если сильно менять содержимое диаграмм.
Весь выигрыш скорости от ручного редактирования придется потратить на решение проблем визуального представления.
Поддерживаю и добавлю еще что решает экспертность в предметной области и личная мотивация ревьюера вносить качественные изменения в рассматриваемый код. Должность тут никак не влияет.
Представьте, например, что ведущий разработчик, который занимается разработкой нового веб движка, вынужден смотреть все коммиты джунов, которые верстают лендинг. В лучшем случае это будет бесполезная трата времени, без каких либо результатов.