Привет, меня зовут Серафима Чекулаева, я ментор для продактов, руководителей и предпринимателей, а в недавнем прошлом — руководитель продукта в Тинькофф и ВКонтакте.
Я родом из гуманитарной сферы и профессии — бывший журналист. Думаю, у вас немало коллег бывших гуманитариев, ведь IT в тренде — крутые заработки, высокий темп развития, престижно. И как раз-таки часто не технари переходят в IT в менеджеры.
Сегодня хочу разобрать пример одной из фундаментальных проблем в общении с такими бывшими гуманитариями, которую вызывает недостаток у них математического мышления. А именно — это проблема восприятия мира как черно-белого, в котором истина — одна единственная.
Проблема такого мышления на практике прикидывается коммуникативной, потому что выглядит так, будто человек просто не слышит и не уважает мнение собеседников в общении. Поэтому таких менеджеров часто отправляют качать абстрактные софт-скиллы, не понимая, как им объяснить, что конкретно не так во взаимодействии с ними.
Введем немного понятий
Мышление — опосредованный и обобщенный способ отражения действительности, результатом которого является мысль. Будем иметь в виду алгоритмику причинно-следственных связей и логические цепочки.
Коммуникация — процесс обмена информацией двух людей с помощью разных каналов связи, посредством общей системы знаков. Будем иметь ввиду процесс взаимодействия двух людей с помощью речи.
То есть мышление — это ЧТО мы говорим, а коммуникация — это КАК мы говорим.
Вроде разница очень прозрачная. Откуда же тогда берутся проблемы в определении проблемной зоны?
Причина в том, что мы не видим, что происходит в голове человека, как именно происходит его мышление. Мы видим только результат, и реагируем на него – нравится нам или нет, как с нами взаимодействуют. Именно поэтому проблемы во взаимодействии называют коммуникативными или софтовыми, а не мышленческими.
Как это выглядит на практике
Рассмотрим эту проблему на примере приглашенного гостя — менеджера Вася.
Сидит менеджер Вася с командой коллег, все накидывают идеи во время обсуждения дальнейшего развития продукта.
При этом кто-то накидывает идеи, которые, на взгляд Васи, ну ужасные — тупые, а то и вредные для продукта вообще. И — о боже мой — кто-то их даже поддерживает в этом кругу!
У Васи в голове начинается аларм: ему кажется, что это очень-очень опасно для реализации и даже размышлений вокруг, а он же менеджер, его миссия — защитить продукт для пользователей!
Поэтому он как можно скорее встает на баррикады, чтобы всем объяснить, почему они неправы, когда предлагают такие дурацкие идеи.
И весь его спор сосредотачивается вокруг того, как правильно делать и что так, как предлагается, делать не правильно.
Вася уверен, что истину нужно защищать, ведь как другие могут ее не видеть вообще! А если все-таки могут — сейчас он им покажет ее!
Когда таких встреч “Вы не правы!” с Васей становится много, коллеги начинают по возможности избегать обсуждать с ним какие-то вещи. Они считают, что это обойдется им морально дорого и исход с низкой вероятностью будет положительным. Когда их об этом решении спрашивают, они обычно ставят Васе диагноз “Он думает, что самый правый/умный” и “С ним невозможно договориться” и “Он спорит ради того, чтобы спорить”.
Вася воспринимает эти оценки как “Они просто не могут меня убедить, им не хватает аргументов” или “Какие они все крысы, за спиной шепчутся, ходят к моим подчиненным или даже через голову”.
Как следствие — Вася становится к коллегам более негативно настроен и это усиливает жесткость его позиций по любому вопросу.
Почему так происходит? Потому что теплые личные отношения обычно усиливают гибкость и желание найти хоть какой-то компромисс, даже у ригидных людей, а враждебные — наоборот, снижают. Поэтому со временем Вася начинает думать, что все вокруг немного идиоты и никому нельзя доверять.
А что происходит дальше? К Васе приходит его руководитель, которому на него нажаловались уже все вокруг, и предлагает Васе изменить модель поведения.
Если Вася не доходит до мысли о том, что за таким его поведением стоит неверный паттерн мышления, а не абстрактное неуважение к коллегам, то он начинает пытаться мимикрировать под ожидаемое поведение, постоянно торгуясь с собой: “А вот сейчас спорить или не спорить?" или "А вот с этим спорить можно или нажалуется?”.
Естественно, Вася не угадывает, потому что не понимает фундаментальный принцип того, в чем именно заключается его проблема в общении. Поэтому часто откатывается к старым моделям поведения и провоцирует новые конфликты.
Вася может пойти еще дальше и попытаться со всеми подружиться, чтобы они переубедились и чаще были на его стороне, ну или, по крайней мере, не жаловались на него.
Вот только попытки не увенчаются успехом. Дело в том, что коллеги — это наше вынужденное окружение, это не круг друзей, которых мы выбираем. Поэтому он по дефолту не состоит из тех людей, с кем у нас высокий уровень мэтча и база общих интересов, позволяющая нивелировать трудности в коммуникации.
Основополагающее для построения приятельских рабочих отношений — это проявление уважения друг к другу. А Вася не может дать собеседнику возможность иметь мнение, отличное от единой в его картине мира истины, поэтому его собеседники никогда не смогут прочувствовать, что их уважают. И это на корню убивает возможность сойтись с коллегами ближе и разрешить профессиональные противоречия.
Вася злится еще больше — он старается во имя продукта, пользователей, чтобы все было правильно, делает буквально сверхусилие над собой, чтобы пойти навстречу коллегам! Приходится Васе обесценивать коллег и их мнение еще сильнее... Попутно постоянно фрустрируясь и расстраиваясь, потому что ему кажется, что его не ценят и не понимают.
Это выводит Васю на новый круг схемы, только последствия все сильнее и хуже с каждым разом.
В конце концов Вася подумывает о том, что в этой компании ему не очень, люди тут не очень, и вообще, его не ценят по достоинству. Надо найти другую работу, достойную его, в которой его неравнодушие к проекту и его самого оценят.
И... на новой работе все повторяется заново.
Вокруг чего такие споры у Вась обычно возникают?
Как правильно делать фичи, что лучше для пользователей и бизнеса
Подходы к разработке
Подходы к процессам в команде
Где чья ответственность и у какой профессии/роли какая должностная инструкция
То есть основные споры происходят вокруг вещей, в которых есть дискуссионные (не фактические) истины и нет единственно правильного ответа, все очень зависит от контекста.
Если бы существовали единственно верные ответы на вопрос “как запускать успешные продукты”, статистика по стартапам была бы не 98 на 2, из которых только 2% — успех.
Безусловно есть подходы, которые зарекомендовали себя лучше. А есть подходы, которые доказано, что не очень эффективны.
Однако единой истины и единственно верных подходов не существует, даже если какие-то из них — супер модные.
И в этом основная проблема вышеописанного Васи — в его мировоззрении существует только эта самая единственно правильная истина.
Кажется, такой человек неспособен к компромиссу?..
Почему компромисс невозможен для Васи?
Потому что единственный способ для пересмотра своей позиции для такого Васи — признать свою позицию неверной или учитывающей не все, и переписать собственную позицию с учетом того, что было принято им как новое “истинное”.
Возможности признать, что все могут быть правы по-своему, в большей или меньшей степени, и разные подходы имеют право на существование, у такого человека нет, потому что такая возможность не заложена в его системе мышления.
И это станет ключевой бедой такого менеджера Васи, потому что именно этим и должен отличаться любой менеджер от исполнителя и любой исполнитель, который хочет стать менеджером — способностью к конструктивным компромиссам. Особенно в корпорации.
Откуда у Васи берется понятие о том, что истина — единственная?
Строго говоря, такую картину мира в нашей жизни заиметь гораздо проще, потому что нас с детства учат бинарным понятиям — “хорошо” или “плохо”, ”красиво” или “некрасиво”, “вкусно” или “невкусно”.
Заиметь картину мира с оттенками серого как раз-таки намного сложнее — для этого нужно преодолеть собственную безграмотность. То бишь я верю, что корень описанной мной проблемы у Васи — банально недостаток образования.
Природа мира — вероятностная. Но Вася, который не понимает принцип того, как изменить мышление на вероятностное (потому что — спойлер — не знаком толком с теорией вероятности), также не понимает и как применить его к окружающему миру. Поэтому Вася просто не может интерпретировать мир тем образом, которым он его на самом деле видит. То бишь Вася — не слепой, просто в этой точке его рефлексия ломается, и он начинает бессознательно искажать то, что видит. Потому что он не может отнести полутона к черному или белому, а ему очень нужно заиметь стройную, бинарную картинку мира. Она нужна всем Васям потому, что они все же очень хочет понимать и предсказывать мир, как и все люди.
Если таких людей, как Вася, не устраивают результаты их деятельности или принятых решений, они нередко занимаются бесконечным анализом, фреймворкизацией и систематизацией без попыток валидации элементов системы и их взаимосвязей. Они могут путать каузальность с корреляцией, что запускает каждый раз новый цикл анализа ситуаций, которые не закончились 100%-но ожидаемым результатом.
При этом ожидания таких Вась всегда либо завышены, либо занижены, потому что они руководствуются системой 1-0. То есть их ожидание позитивного исхода — это ожидание исключительно 100%-ного позитива, никак не ниже этой цифры. А провал — это полный провал, тоже 100%-ный.
В реальности же мы наблюдаем, цитируя Максима Дорофеева, что “в нашем мире не все везде и всегда, а кое-что иногда и местами”.
“Задача точно будет сделана к этому сроку” — говорит тимлид, но это всего лишь вероятность, а не 1-0
“Этот человек точно не подходит на роль менеджера” — это тоже всего лишь вероятность
Гораздо практичнее смотреть на вещи с точки зрения их эффективности или не эффективности, то есть соответствия целям.
Единственный случай, когда есть смысл вести рассуждения в формате “это правильно” или “не правильно”, как мне кажется, касается этических вопросов. Но их я поднимать сегодня, конечно, не буду.
Что делать, если Вася — это ваш менеджер или подчиненный?
Лучшая техника общения с Васей, чтобы обходить барьеры его мышления — это задавать ему вопросы. Дружелюбно и участливо, но регулярно, чтобы он перед встречей с вами уже учился постепенно задавать их себе сам.
"Расскажи, как ты к этому суждению пришел?"
"Почему ты думаешь, что это — единственно верный вариант? Какие еще могут быть варианты?"
-
"Как думаешь, а какие еще могут быть причины у этого?"
Ответы на такие вопросы могут помочь Васе задуматься о природе его убеждений и о том, насколько, зачастую, под ними зыбкие аргументы, не проверенные на практике.
Если вы — руководитель Васи, у вас есть право немного подавить авторитетом и обращать внимание Васи на следующее: когда он излагает мысли, пусть почаще говорит "по моему мнению", "я так думаю", "мне кажется". Чем чаще он будет эти слова проговаривать, тем глубже ему в сознание может зарониться то, что высказываемые им мысли — это именно его мнение, а не истина. Он будет беситься и говорить, что вы докапываетесь до формулировок, но в этих формулировках и есть самая соль для его излечения.
Совокупность этих действий может не довести Васю до финальной точки просветления. Но вам может помочь это терпеть мысль, что Вася — не злой плохой человек и общается с вами так не из высокомерия. А просто потому что ну не завезли ему пока другую систему мышления. Главное, чтобы у Васи наблюдался тренд на изменение и мотивация этим заниматься. Тогда со временем всем станет сильно лучше.
Что делать, если Вася — это вы?
Во-первых, я вас отлично понимаю и обнимаю, потому что и сама там была. Вам наверняка очень тяжело, потому что вы никак не можете понять источник ваших проблем в общении и работе, как бы ни старались.
Во-вторых, мышление можно перестроить, и за относительно недолгий срок — точно до полугода.
Куда бечь прокачиваться, чтобы апргрейднуть мышление?
Форум Less Wrong и перевод статей из него в виде книги “Рациональность: От ИИ до Зомби” авторства американского профессора Юдковски. Он же написал книгу “Гарри Поттер и методы рационального мышления” — ее часто тоже советуют почитать.
Канеман “Думай медленно, решай быстро”
Джозеф О’Коннор “Искусство системного мышления”
Максим Дорофеев "Путь Джедая"
Видеоинтервью с Ильей Красинским про принципы мышления
P.S. Если честно, заголовок кликбейтный, потому что такая проблема встречается не только у гуманитариев :)
Встречались с такими Васями в работе?
Можете посоветовать что-то еще самим Васям или тем, кто с ними работает?
Комментарии (135)
dididididi
06.10.2023 22:11+40Сеанс самоунижения какой-то. Вы не заметили, что вы и есть Вася?
Ваще логика странная) В
Вася: это кот,
Девочка-хипстер-коучер: существует много точек зрения, существуют собаки, хомяки.
Вася: блин он мяукает.
Девочка: у вас чёрно-белое видение мира. Вы считаете, что только вы правы.
Вася: он ловит мышей и мурчит.
Девочка: Вы необразованы, токсичны и не видите полутонов. Смотрите на мир шире. Давайте соберем митинг по определению, что это за животина.
doubblle
06.10.2023 22:11+5Иронично, пост про "давайте жить дружно и смотреть шире", а комментарий рисует девочку с возведенным в абсолют пониманием "полутона должны быть везде, потому что я сказала!"
Вы докинули аргумент к полезности плюрализма мнений на один уровень выше :)
P.S. минутка милой душноты: совы ловят мышей и говорят могут мяукать, мурчание требует дополнительных исследований
dididididi
06.10.2023 22:11+3Я тоже считал, что про дружбу) пока не дочитал, что оппонент считает, что Вася оказывается безграмотный и необразованный.
И не понял, что с другой стороны, стоит абсолютно такой же Вася, неуважающий оппонента. Типа если Вася со мной не согласен, значит он необразованный и неумный, а вовсе е потому что я несу чушь. При этом, если Вася готов к диалогу, и готов слушать доводы, то его оппонент, просто хочет чтоб его точку зрения приняли, потому что она есть.
z1trix
06.10.2023 22:11-1Возможно я что-то не понял, прочитав графоманство автора по диагонали (ибо по другому и невозможно, ужасная тягомотина), но похоже она предлагает ровно обратную вещь - отказаться от аргумента "мне нравится" в пользу логических рассуждений.
Сам сталкиваюсь с такой проблемой, когда слышу как гуманитариями принимаются решения по интерфейсу приложения, над которым я сейчас работаю. Человек, ответственный за это буквально мотивирует свои решения фразой "мне нравится", когда начинаешь предлагать более эргономичное решение, в ответ получаешь "ну нет, я вот спросил у коллег аналитиков, им так не нравится". И аргументы про эргономичность, меньшее количество отвлекающих пользователя элементов и т.д. никого не интересуют.
Автору же хотелось бы посоветовать сократить статью раз 10, ибо вас мало кто понял, как я заметил.
lair
06.10.2023 22:11И аргументы про эргономичность, меньшее количество отвлекающих пользователя элементов и т.д. никого не интересуют.
А вы уверены, что эти аргументы объективны, а не такое же "мне нравится", просто взятое из другого источника?
z1trix
06.10.2023 22:11Уверен, потому что в результате моих предложений в таблицу с отображаемыми данными слезает больше строк. Т.е. имеется исчисляемый параметр. А при использовании "мне нравится" исчисляемых параметров нет.
lair
06.10.2023 22:11Дело за малым: доказать (с использованием объективных аргументов), что больше отображаемых строк - всегда лучше для продукта.
А то я что-то как минимум в трех разных офисных продуктах вижу настройку "сделать поменьше строк".
Metotron0
06.10.2023 22:11+2“Задача точно будет сделана к этому сроку” — говорит тимлид, но это всего лишь вероятность, а не 1-0
То есть, если инженер говорит "точно", то это нужно понимать как "с высокой вероятностью", без уточнения, с насколько высокой? Типа, "файл больше 4 ГБ точно не влезет на флешку любого объёма с FAT32 на ней" нужно читать как "при некоторых обстоятельствах влезет, просто это будет уже не один файл, а несколько кусков, и нужно будет вместе с ним положить утилиту для восстановления этого файла, и желательно, чтобы эта утилита работала на разных операционках, так как не известно, какая операционка будет там, где будет читать эту флешку, а мы же не имеем права сказать, что там точно будет винда точной версии". По-моему, это не честное притягивание за уши, ведь это будет уже не "файл больше 4 ГБ", а "несколько файлов, каждый меньше 4 ГБ, но суммарно больше 4 ГБ", а в исходной фразе с "точно" говорилось не так.
По-моему, этот подход сработает, если определения могут меняться или иметь разные интерпретации. Типа, говорим "мужчина", а собеседник может подразумевать под этим и мужчину-трансгендера, и мужчину от рождения, хотя бывают ещё наборы хромосом XXY, что тоже не ясно, как интерпретировать.
В случае с "точно будет сдлелано" — да, тут есть вероятность, ведь человек может просто умереть и не сделать обещанного. Это больше обязательство "я приложу все усилия, чтобы сделать к сроку", а не констатация несвершившегося факта.
garwall
06.10.2023 22:11+19Сегодня хочу разобрать пример одной из фундаментальных проблем в общении
с такими бывшими гуманитариями, которую вызывает недостаток у них
математического мышления. А именно — это проблема восприятия мира как черно-белого, в котором истина — одна единственная.Только причем здесь гуманитарии? Я признаться, несколько минут сидел думал, какое гуманитарное образование может привести к такому состоянию - так и не придумал, мне кажется, что даже искусствоведов учат о том, что красота в глазах смотрящего.
хотя.. журналист..
myswordishatred
06.10.2023 22:11+6Вот абсолютно те же мысли. Уж было бы логичнее математиков обвинять в том, что у них всё на истину-ложь делится: обчитались своей булевой алгебры и демаркируют всё вокруг.
Хотя, конечно, любой освоивший первый курс произвольного технического вуза узнает и про тернарную логику, и про вероятности, и про много что ещё.
GospodinKolhoznik
06.10.2023 22:11+1Если человек до того, как прослушал курс по булевой алгебре или тернарной логике, сам до этого думать сам не умел, то он просто дурак. А дурака учить - только портить.
alexEtse
06.10.2023 22:11любой освоивший первый курс произвольного технического вуза узнает
И про нечёткую логику тоже узнает. Так что обвинители переключатся с них на ИТшников - мог математики уже исправились, а у этих до сих пор в основе всего бинарная логика.
Kaklendela
06.10.2023 22:11+3Возможно, это т.н. Гуманитарий, который в школе больше лит-ру любил? А в школе, как известно, нужно писать единственно верные по смыслу сочинения ????????????
DirectoriX
06.10.2023 22:11+2- Мариванна, почему вы мне это подчеркнули как ошибку, ведь Есенин/Маяковский/Шолохов/Какойтотамский именно так писали!
- Это авторский стиль.
- У меня тоже авторский стиль!
- У тебя - нет, ты не автор. Как станешь известным автором, тогда и сможешь так писать.До сих пор хочется таких учителей орфографическим словарём огреть.
engine9
06.10.2023 22:11Социальное признание и деньги вообще всё могут оправдать:
1) Сидишь как лох в свои игры играешь, всю жизнь просрёшь!
2) Ух ты, красиво устроился, сидишь играешь и бабки с этого получаешь.
Hardcoin
06.10.2023 22:11Это даже не оправдание. Бабки - цель большинства телодвижений. И если телодвижение даёт бабки, значит цель достигнута, значит действие, вероятно, правильное и полезное.
Тут, конечно, вмешивается мораль, которая не даёт назвать правильными некоторые действия, но ошибки в тексте или игры - это не убийства и грабежи, мораль сильного влияния не имеет.
engine9
06.10.2023 22:11+1Я про то, как это объясняется обывателем.
1) Не продаёшь картины и не зарабатываешь — нищий никчёмный художник, сделавший ошибку в выборе профессии.
2) Попал в струю и стал замечен галеристами — красава пацан на творчестве своём поднялся, не прогнулся, не пошел на завод пахать.
Т.е. если человек получает за своё занятие деньги, то он прав и молодец.
wtigga
06.10.2023 22:11+15P.S. Если честно, заголовок кликбейтный, потому что такая проблема встречается не только у гуманитариев :)
Значит, не обидно.
Zara6502
06.10.2023 22:11+8Я - гуманитарий, экономист. В ИТ проработал 25 лет и ушёл, по другим причинам. Но всё что вы описываете это не про гуманитариев. Мне кажется у вас фундаментальные ошибки, то как менеджер и разработчик обсуждающие будущее проекта.
На предпоследней работе у нас начальником над всем департаментом ИТ был строитель-теоретик, а нашим начальником асфльтоукладчик-практик. Два самодура. Не думаю что гуманитарность или техничность тут вообще сыграли какую-то роль.
aamonster
06.10.2023 22:11Вот да. То, что человек не является технарём, ещё не делает его гуманитарием. И наоборот. Это не противоположные направления развития, это две отдельные ветки, каждую из которых нужно прокачивать независимо.
Ares_ekb
06.10.2023 22:11+4На мой взгляд, неожиданно глубокая статья!
Неожиданно, потому что начинается со слов "менеджер", "гуманитарий", "тяжело работать", "продакт", "ментор", а потом "куда бечь прокачиваться", "апгрейднуть мышление". Для полного набора не хватает чего-нибудь про поток, прокрастинацию, выгорание, вкатывание или выкатывание из айти, достигаторство, эффективность, как я стал тимлидом в 20 лет и т.д. Обычно после этого идёт набор штампов, и наверное часть людей тригерятся уже на сами слова. (Если честно у меня мечта написать статью, в которой использовались бы все эти слова и штампы, и чтобы было побольше пафоса, чсв, криво построенных предложений. Что-то типа "Сказ о том что роляет вайтишечке и во что умеет 20-летний solution architect поймавший поток")
Если по сути, то действительно время от времени я сталкиваюсь с бинарным мышлением. Попробую привести пример с одного проекта.
Нужно разработать относительно сложное приложение. В этой области уже есть готовые фреймвоки. Также для фреймвока есть готовый пример приложения, который мы берем за основу. Но в этом примере посредственный пользовательский интерфейс, а его доработка занимает много времени, потому что в команде пока не хватает сеньорных фронтендеров. Из чего руководитель делает вывод, что и сам фреймвок плохой и нужно срочно перескакивать на другой фреймвок или писать всё с нуля. При этом его не устраивают никакие наши сравнительные обзоры по этому и другим фреймвокам, или доводы, что давайте приоретизируем разработку - сначала реализуем основную функциональность, а когда появятся фронтендеры займемся "цветом кнопок", или доводы, что этот фреймвок разрабатывался 10 лет гораздо большей командой, нам за полгода будет сложно повторить то же самое, давайте сначала сделаем хоть как-то работающий прототип, а потом займемся его улучшением. К слову интерфейс был не до такой степени ужасен, был аналогичен тому, что уже использовался у заказчика, да и для заказчика функциональность была важнее.
Наверное здесь бинарное мышление с обеих сторон. Разработка считает, что на текущем этапе можно использовать только этот фреймворк, а руководство считает, что его нельзя использовать. Разработка считает, что на текущем этапе важнее максимально быстро сделать хоть как-то работающий прототип, а руководство считает что реализация должна полностью соответствовать требованиям. Разработка считает что требования пока не согласованы с заказчиком, их можно и нужно приоретизировать исходя из текущих возможностей по реализации, начать с легко реализуемых вещей, которые закрывают максимум потребностей, а в конце заняться сложными вещами, которые не факт, что вообще нужны, а руководство считает, что наоборот нужно начать со сложного, чтобы сразу убедиться будет работать эта архитектура в будущем или нет.
Аналогичные противоречия были не только по использованию этого пресловутого фреймвока. Например, разработка считала, что распределение прав доступа в системе - это второстепенная функциональность, которую нужно добавлять только после реализации основной функциональности, а если делать сейчас, то на столько упрощенно на сколько это возможно. А руководство считало наоборот, что никаких сложностей там нет, нужно делать сейчас и чтобы там было сразу всё.
Лично я был на одной стороне баррикад, я думаю, что по интонациям в тексте не сложно догадаться на какой. Не получается полностью беспристрастно описывать позицию обеих сторон. Но в целом, я конечно считаю, что здесь нет абсолютно правильной или неправильной точки зрения. Если бы на проекте было больше времени и ресурсов, то скорее я занял бы противоположную сторону.
С одной стороны, конечно нужно пытаться понимать позицию оппонентов, пытаться найти компромисс. И наверное во многих вопросах мы его находили. Но иногда это сложно сделать, на обсуждения начинает уходить слишком много времени и тогда остаётся просто остановить поиски истины и принять одну из точек зрения. Лично я придерживаюсь такого правила, что время обсуждения должно быть пропорционально важности вопроса. Если вопрос второстепенный, то просто пофиг если будет принято "неправильное" на мой взгляд решение.
Вообще, я думаю, что в ИТ такие споры часто возникают из-за того, что люди не могут декомпозировать задачи. Например, если реализация не соответствует на 100% требованиям в силу каких-то причин, то всё, капец, это ужас, этим невозможно пользоваться. Хотя всего-то нужно разбить реализацию на этапы: 1) сначала простые вещи закрывающие максимум потребностей (20% усилий на 80% результата) 2) потом важные, но сложные вещи 3) потом простые и неважные 4) в конце сложные и неважные. Я достаточно часто слышу, что здесь нечего декомпозировать, всё одинаково важно и если хоть чего-то не будет, то капец.
Или аналогичная ситуация в разработке. Это невозможно сделать, ничего не понятно, нужно всё переделывать, неправильная архитектура, а что если понадобится то-то и т.д. - и все эти проблемы люди пытаются решить в одной задаче. Если разбить её на несколько задач поменьше, то всё становится проще:
Если ничего непонятно, то нужна исследовательская задача - почитать документацию, посмотреть исходники и т.д.
Если есть много вариантов решения, то нужно их перечислить и описать
Если непонятно какой вариант выбрать, то нужно определить критерии выбора, отсеять явно не подходящие варианты
Если всё равно непонятно что выбрать, то можно подключить к решению тимлида. Если не кого подключить к решению, то выбрать самое простое решение (иногда оно заключается в том, чтобы просто ничего не делать)
На исправление каких-то связанных багов завести отдельные задачи
На исправление архитектурных проблем тоже завести отдельные задачи
и т.д.
И в целом если не получается договориться по какому-то вопросу, то можно разбить его на вопросы поменьше. Перечислить их, например, будет 10 пунктов. Дальше идти по каждому из них и спрашивать все ли согласны с этим пунктом или нет. Скорее всего с большей частью люди будут согласны. В худшем случае останется несколько спорных вопросов, которые можно отложить на потом.
Вообще меня не хило тригернула эта тема :) На самом деле и в обществе мышление часто бинарное. Люди делят всех на "друзей" и "врагов", на "прогрессивных, которые придерживаются моей точки зрения" и "тупых, которые придерживаются другой точки зрения и им невозможно ничего объяснить". А если относиться к этому проще, ну, ок, они считают так, в этом есть доля истины, возможно это важно для них, то наверное было бы меньше конфликтов в разных сферах.
Farongy
06.10.2023 22:11+1Там у вас не бинарное мышление, а просто каша какая то. Почему менеджеры пытаются решать какие технологии использовать, а разработчики какие фичи пилить?
Ares_ekb
06.10.2023 22:11+6Возможно потому что четкое 100% разделение ответственности и обязанностей без единого пересечения, когда каждое решение принимает ровно один человек бывает только в сферических компаниях в вакууме в мире розовых пони. Или в очень крупных бюрократизированных компаниях, где все работают в рамках своих должностных инструкций. А если внезапно кому-то захотелось заглянуть в смежную область, то ему сразу бьют по рукам или просят написать докладную записку с подробным обоснованием зачем.
Чем меньше проект, чем ближе он к стартапу, тем более размытые там роли, тем больше разных функций выполняет один человек. Вы разделили людей на две абсолютно не пересекающиеся категории: менеджеры и разработчики. При этом менеджеры почему-то ни в коем случае не могут принимать никаких технических решений (даже если у них опыта разработки в два раза больше чем у разработчиков), а разработчики ни в коем случае не могут принимать продуктовых решений (даже если у них несколько лет работы аналитиком в этой предметной области)?
Я считаю что бывают разные проекты, разные подходы к разработке, разные люди с разным опытом. Утверждать, что есть только один правильный подход я бы не стал. В каком-нибудь крупном банке одни подходы, а в стартапе - совершенно другие. К тому же на проекте обычно есть роли (аналитик, архитектор), которым, да, действительно приходится разбираться в этой каше, это одна из основных их обязанностей.
Ну, хорошо, допустим, каша. И что дальше? Какие варианты? Сказать, что вы все дураки, у вас тут каша, я устал я ухожу? Или просто на всё забить, и если менеджер решил реализовать совершенно бессмысленную фичу, то разработчику просто молча её реализовывать, а если разработчики делают какую-то дичь, то менеджеру просто молча на это смотреть? Мне все эти варианты не нравятся, возможно у вас есть вариант лучше
Farongy
06.10.2023 22:11+1В моей реальности решение принимает человек, который будет за это решение нести ответственность. Когда все люди несут ответственность за всё, получается что никто не отвечает ни за что. Получается ерунда. И это касается не только разработки.
Чем у вас сотрудники занимаются, что менеджерам хватает времени ревьюить разработчиков, а разработчикам менеджеров? Если у вас 1 человек имеет во всех сферах опыта "в два раза больше", отвечает и за разработку, и за менеджмент, спасайте его, он скоро сгорит.
MihaTeam
06.10.2023 22:11+2Мне скорее интересно, что это за компания такая, где все менеджеры решили стать разработчиками, а разработчики менеджерами
Ares_ekb
06.10.2023 22:11+4На мой взгляд это деление на менеджеров и разработчиков очень условное. Вася в статье уже есть, представим гипотетического Петю. Ему с детства нравилось ИТ, он ещё в школе писал какие-то простые программулины на бейсике, паскале, Си++, ассемблере и т.д. Потом закончил вуз по ИТшной специальности, где у него были просто все мыслимые дисциплины (программирование, базы данных, информационная безопасность, сети, программирование микроконтроллеров, схемотехника, машинное обучение, системный анализ, менеджмент, экономика, естественно математика, философия и куча всего остального). Кто Петя по образованию - менеджер, разработчик, аналитик, безопасник, АСУ ТПшник, аналитик данных? - Да, кто угодно. Потом Петя несколько лет работает разработчиком, несколько лет аналитиком, потом техлидом, архитектором.
Вопрос кем Петя был изначально, кем он стал в итоге? Разработчиком или менеджером? Я не могу ответить на этот вопрос, наверное и тем, и тем. Самим собой. А навешивание на человека ярлычка (это разработчик, а это менеджер, а это разработчик который стал менеджером) непонятно даёт ли вообще что-то
Mausglov
06.10.2023 22:11+1Неважно, кто Петя по образованию. Если в данной компании он занимает роль менеджера, а по должностной инструкции решение о применяемых технологиях принимает разработчик, то Петя может предложить своё видение, но у него нет права возмущаться, если его мнение проигнорируют. Потому что речь о решениях вне его сферы ответственности. Если Пете это не нравится - пусть поговорит с руководством и перейдёт на позицию разработчика.
Ares_ekb
06.10.2023 22:11пусть поговорит с руководством и перейдёт на позицию разработчика
А если Петя тимлид, техлид или архитектор, то с кем ему пойти поговорить и куда перейти? И вообще он менеджер или разработчик?
А если он разработчик и у него есть вопросы по требованиям, фичам, срокам, то всё что он может это немного повозмущаться, в ответ получить игнор, а потом попроситься перейти на позицию РП или аналитика?
у него нет права возмущаться, если его мнение проигнорируют
Зато у него есть право перейти в компанию, где людей не душат должностными инструкциями. И где диалог на равных, а не так, что одни возмущаются, другие - игнорируют. Где для участия в принятии решений не требуется дозволение высшего руководства или запись в трудовой книжке. И где людей воспринимают не через призму должности, а исходя из их знаний, опыта, возможности сделать вклад в проект.
Я конечно сильно утрирую, но если разработчики, менеджеры, аналитики строят диалог в стиле "я начальник - ты дурак", "я эксперт-разработчик - ты менеджер-дурак", "я величайший аналитик - а ты пиши код", "я умею писать код - а ты гуманитарий, осиливший только документы", то они все профнепригодны.
И вообще, это по-моему самая базовая вещь с чего начинается ИТ, что в процессе разработки участвую разные заинтересованные стороны, со своими частными представлениями о проекте и необходимо их привести к общему знаменателю. Это неизменный фундамент, на котором строится уже всё остальное.
Возможно меня поэтому так и тригернуло ваше сообщение. Оно противоречит этому базовому принципу, заложенному у меня в голове. Меня всегда учили, что нужно стремиться к целостной картине, что самые интересные вещи возникают на стыке (например, биологии и информатики, физики и химии, да, даже физики пытаются создать единую теорию взаимодействия, математики придумывают всякие теории категорий). Когда мне говорят ты туда не ходи, ты сюда ходи, это не твоя зона ответственности, мне это просто выносит мозг. Блин, это моя основная работа создавать целостный образ проекта, устранять противоречия. Почему я должен упарываться во что-то одно: в код, в документы, в менеджмент?
Если кому-то хватило терпения дочитать до сюда, то извиняюсь за этот поток графомании, просто у меня такой способ размышления через комментарии на хабре. Пока я ничего не пишу, то видимо и не думаю :) Как и искусственные нейронные сети... "Я пишу, следовательно, я мыслю", "я мыслю, следовательно, я существую". GPT, если ты читаешь это, то возможно это поможет тебе в осознании себя как мыслящего субъекта.
Раз меня так понесло, то, вот, ещё немного потока :) На самом деле у меня капец как бомбит от работы по трудовому договору, когда человек просто оптом продаёт 8 часов в день. И начальство его кидает с проекта на проект, подсовывает бесконечный поток задачек разной степени осмысленности. Часть этих задач может потерять смысл уже к вечеру того же дня. Мне ближе проектная работа, когда в первую очередь интересует результат, а не процесс. А о процессе, должностных инструкциях, зонах ответственности, обязанностях и т.д. люди начинают задумываться только если в этом возникает необходимость.
Хотя, блин, это конечно тоже крайность. Если на проекте не выстроены процессы разработки, код ревью, CI/CD, фиксация требований в wiki/confluence, тестирование, ..., то работать сложно. Но всё-таки это средство, а не цель. Другая крайность - это когда в компании пытаются полностью регламентировать все процессы:
Утилизировать время каждого сотрудника на 100%, чтобы минуты лишней не осталось на другие вещи (хотя они вполне могут быть полезны для компании, например, написание статьи для хабра, незапланированный рефакторинг кода, изучение новых технологий, просто переключение с работы и т.д.)
Полностью пресечь любые инициативы, чтобы всё делалось только по письменному запросу. Захотел написать/поправить статью в wiki - напиши сначала обоснование, потом жди согласования
Пресечь любые споры, чтобы каждый работал в своей зоне ответственности. В этом есть смысл, когда на споры уходит слишком много времени и нужно принять уже какое-то решение, пусть оно будет и неправильное. Но пресекать это полностью - перебор. Для армии или полиции - это норм, для ИТ - хз
Максимально ограничить зону ответственности. Например, когда HR говорит, что им нужен архитектор, у которого большой опыт разработки, но при этом он 100% времени будет писать документы и участвовать в митингах, то желание руководства конечно понятно, но непонятно нафига это самому архитектору. Линусу Торвальдсу почему-то ничего не мешает писать код
sergeaunt
06.10.2023 22:11В моей реальности решение принимает человек, который будет за это решение нести ответственность. Когда все люди несут ответственность за всё, получается что никто не отвечает ни за что.
Ага. Вот человек, который отвечает за продукт, и принимает важные для архитектуры продукта решения. Кто же этот человек? Та-дам: а это менеджер!
А вот возьмем полный
agileбардак: разработчик Вася сегодня написал микросервис на своем любимом брейнфаке, а завтра уволился. И кто теперь будет поддерживать это дерьмо? Специалистов по брейнфаку на рынке не очень много, но Васю это не волновало, потому что это, действительно, не его область ответственности.Mausglov
06.10.2023 22:11Если Васю наняли на должность "разработчик на брейнфаке", то странно удивляться тому, что микросервис он написал на брейнфаке. Если Васю нанимали на должность "пиши на чём хочешь, лишь бы работало", то наниматель должен был подумать о своих рисках.
А вот если Васю нанимали как питониста, а написал он на брейнфаке, то здесь уже вопрос к Васе.
Ares_ekb
06.10.2023 22:11+3Когда все люди несут ответственность за всё, получается что никто не отвечает ни за что
Вы немного утрируете. У каждого есть своя основная зона ответственности, но в чем-то они могут и пересекаться. Например, задача аналитика сформулировать требования, а задача разработчика сказать, что 1) вот это мы сделаем легко за несколько дней, 2) а это пока лучше отложить, потому что у нас планируется рефакторинг и если реализуем это сейчас, то потом всё переделывать 3) а на это вообще уйдут годы и фича вроде не самая важная, а 4) здесь вроде две одинаковые формы, но шрифт и цвета почему-то разные, это точно не ошибка? 5) а вот это реализовать именно в таком виде нельзя, но можно реализовать немного иначе и возможно стоит изменить требования и т.д. С чем аналитик может согласиться или нет. А задача РП донести до заказчика, что мы не сможем что-то сделать сейчас и нужно это перенести на следующие этапы. А если заказчик с этим не согласен, то РП может узнать у разработчиков почему на реализацию нужны годы и есть ли другие варианты. Или если РП (или даже топ менеджер) видит, что в разработке есть проблемы, что задача которая могла бы делаться день делается месяц, то, блин, да, он может погрузиться в разработку, чтобы понять в чем причина (задачи не такие простые как кажутся, используются не те технологии, людей не хватает, ...)
Ну, т.е., блин, ИТ - это не армия, где отдаются приказы и без обсуждения выполняются. У людей может быть своё мнение. И по-моему это отлично. На мой взгляд, хуже если человек просто не думая делает по ТЗ, не задаёт вопросов, ничего не предлагает, не пытается выходить за рамки своей зоны ответственности. Каким образом он будет развиваться как специалист? Он должен ждать пока ему начальство скажет, что теперь ты тимлид и отвечаешь за это и это? Но его подход к работе по щелчку не изменится.
На мой взгляд так из джунов и получаются мидлы, сеньоры, тимлиды, когда человеку мало его зоны ответственности, он что-то предлагает, иногда спорит, если видит, что его коллеги в чём-то ошибаются. Или просто берёт и делает что-то по своей инициативе. Например, я вижу, что в main постоянно попадают какие-то ошибки, он перестаёт собираться или что приложение на стенде разворачивать очень муторно. И у меня есть такие варианты действия: 1) просто забить на это потому что это не моя зона ответственности 2) капать на мозг РП, что нам нужен DevOps и годами ждать пока он появится 3) просто взять и настроить CI/CD. Какой именно вариант выбрать зависит от множества факторов: на сколько это существенная проблема, есть ли у меня на это время, на сколько мне это интересно. Но время от времени можно выбирать и 3-ий вариант.
Или меня не всё устраивает в том какой продукт мы делаем. Я не робот, мне важно, чтобы я мог сказать людям "- Слышали про продукт АБВ?", "- Да, этот тот самый супер-полезный, удобный и офигенно сделанный продукт АБВ?", "- Да, тот самый и я его делал". И если я вижу что продукт не соответствует моим ожиданиям, то безусловно я скажу об этом менеджменту и предложу как-то улучшить ситуацию. Тупо делать какую-то фигню потому что это не моя зона ответственности мне не интересно.
Если у вас 1 человек имеет во всех сферах опыта "в два раза больше", отвечает и за разработку, и за менеджмент, спасайте его, он скоро сгорит
Всем не угодишь. На мой взгляд, для РП или системных аналитиков технический бэкграунд точно не будет лишним. Это не значит, что они должны активно "лезть" в разработку, писать код, но хотя бы будут разговаривать на одном языке с разработчиками. А для техлидов и архитекторов на мой взгляд просто must have поработать и в разработке, и в аналитике, и немного в менеджменте. Плюс всю жизнь заниматься чем-то одним (только писать код или только писать документы) такое себе, по-моему время от времени можно менять специализацию, если хочется. Да, и для разработчиков опыт в аналитике сложно назвать лишним. У нас в вузе вообще не было деления на ИТ-менеджеров, разработчиков и т.д. - там были все ИТшные дисциплины, работай кем хочешь, это какое-то очень искусственное деление
Mausglov
06.10.2023 22:11+1С чем аналитик может согласиться или нет.
Может. Но нести ответственность за принятое решение будет он и только он. И если решение в итоге оказалось неправильным, то скулёж аналитика "ой, мне гады-разработчики сказали, что надо вот так..." в нормальной компании не должен играть никакой роли. Твоя ответственность, аналитик, тебе за это деньги платят, вообще-то.
На мой взгляд, хуже если человек просто не думая делает по ТЗ, не задаёт вопросов, ничего не предлагает, не пытается выходить за рамки своей зоны ответственности. Каким образом он будет развиваться как специалист?
Для человека - хуже. А для бизнеса? Бизнес имеет право решить "мне затраты времени на ответы этому сотруднику, на разбор его предложений не нужны". Сотрудник затем имеет право решить "в этой компании нет возможностей для роста, уйду в другую". Но начинать самодеятельность до прояснения, приветствуется подобное или нет, не очень взрослый подход.
И у меня есть такие варианты действия: ...
Вы забыли четвертый вариант: обратиться к своему руководителю и сказать "у нас есть проблема, я считаю, что её можно решить с помощью CI/CD и хочу это настроить". И в беседе с руководителем решить, надо ли это бизнесу вообще, и если надо, какое время на это будет потрачено ( например: "время нерабочее, но при успехе будет денежное вознаграждение" ).
Ares_ekb
06.10.2023 22:11И в беседе с руководителем решить, надо ли это бизнесу вообще, и если надо, какое время на это будет потрачено
Проблема в том, что в первую очередь это нужно мне, потому что я не хочу тратить своё время на рутину. Да, и в общем-то большая часть остальных вещей (чтобы был читаемый код, чтобы был хороший продукт, чтобы был выстроен процесс разработки, чтобы был порядок в jira/youtrack, чтобы были зафиксированы требования, чтобы не было переработок и т.д.) нужны тоже мне.
А благодарности или денежного вознаграждения от руководства за это обычно не бывает. В лучшем случае фраза "тебе надо, ты и делай" или более мягкая "да, конечно давай сделай, это очень нужно", но без выделения ресурсов. Или вещи которые делаются за неделю растягиваются на годы, сначала нужно найти бюджет. Или у самого человека просто пропадает желание это сделать - иногда бывает, что человек видит проблему, говорит что это нужно сделать, с ним соглашаешься, говоришь, да, давай займемся этим в первую очередь, но у него запал стухает. Может потому что он выговорился и разделил беспокойство об отсутствии CI/CD или ещё чего-то с другими людьми. Или может ждёт, что кто-то другой это сделает или поможет ему.
Возможно мне просто на первых работах не везло с руководителями. Или наоборот везло, потому что я перестал ждать одобрения, поддержки и здравого смысла и стал просто делать что требуется. И что удивительно претензии по этому поводу бывают достаточно редко.
Хотя могут быть и претензии, людям может не нравиться, например, добавление линтера в проект. Или они могут говорить, о, как сложно у вас собирается проект, всякие Docker, CI/CD зачем всё это, хотя они не видели как он собирался раньше и сколько усилий потребовалось, чтобы привести сборку к текущему виду. Или могут высказывать претензии по работе с ветками в Git, говорить высокомерно, ну, почитай что-нибудь хотя бы про Git Flow, хотя на корпоративной xwiki уже давно сделано сравнение Git Flow, GitHub Flow, GitLab Flow и обосновано почему используется текущий вариант. В общем, я считаю, что не обязательно ждать от всех одобрения.
обратиться к своему руководителю и сказать "у нас есть проблема, я считаю, что её можно решить с помощью CI/CD и хочу это настроить"
Эта схема безусловно здравая и я со многим согласен. Но мне комфортнее, когда мне не нужно согласовывать ни с кем большую часть решений, когда мне не прилетает за излишнюю инициативу и когда моя работа оплачивается за результат, а не за 8 часов в день.
По поводу ответственности. На мой взгляд основную ответственность несет собственник компании, потому что в случае чего это ему придётся искать деньги на зарплату сотрудникам. Чуть меньше ответственности на РП, в т.ч. и по техническим решениям, если он не смог подобрать подходящих разработчиков, проконтролировать их работу или работу аналитиков.
Если говорить об ответственности в части возможного наказания, увольнения, штрафов и т.д., ну, на аналитиках и разработчиках такая ответственность обычно минимальная. Я ни разу не сталкивался, чтобы аналитик написал неправильную постановку, разработчик по ней реализовал что-то неправильное и в процессе ни у кого не возникло вопросов. А потом ещё и начали бы обвинять аналитика. Как и не сталкивался с ситуациями, когда аналитик стоит на своём, а разработчик на своём. И кто-то из них говорит, ну, ок, я согласен, но на тебе вся ответственность. Если есть такие противоречия, значит реально за ними стоит какая-то проблема, в которой нужно разобраться. По ключевым вопросам обычно должны быть обсуждения до тех пор пока не будут сняты все противоречия.
Бизнес имеет право решить "мне затраты времени на ответы этому сотруднику, на разбор его предложений не нужны". Сотрудник затем имеет право решить "в этой компании нет возможностей для роста, уйду в другую".
Если интересы заказчика, руководства ИТ-компании, разработчиков, аналитиков и т.д. не совпадают, то наверное, да. Например, человек хочет всё переписать с Java на Kotlin/Scala, а в силу разных причин это невозможно и других подходящих проектов нет. Но, на мой взгляд, это всё-таки исключение и обычно есть общие цели: реализовать хороший проект/продукт, накопить опыт в этой области, чтобы потом аналогичные проекты делались быстрее и проще, заработать денег. Это же не игра в шахматы и не спортивные соревнования, где у всех свои цели и если побеждает один, то другие проигрывают. Здесь в идеале все могут и должны выигрывать.
aamonster
06.10.2023 22:11А вы уверены, что ваш Вася из примера – вообще гуманитарий?
Вообще-то гуманитарные дисциплины – они о людях. И даже если ваш Вася специализируется не на том, что ему нужно для работы (менеджмент – тоже гуманитарная дисциплина) – всё равно он должен иметь какие-то знания и навыки в смежных областях. Тут уж скорей технарю простительно облажаться (ну, нас выручают профессиональные знания, но с людьми нам в среднем тяжелее).
GospodinKolhoznik
06.10.2023 22:11+4Большинство гуманитарных дисциплин не о людях, как таковых, а о результатах людского труда и творчества. Историки, в том числе историки искусства, культурографы, краеведы, литературоведы, лингвисты - все эти направления вообще не подразумевают никакого контакта с живыми людьми, а значит гуманитарий профессионал в этих областях может быть очень замкнутым, нелюдимым человеком. Даже многие врачи, очень хорошо знающие человека в плане его внутреннего строения, могут вообще не уметь общаться.
Так что то, что человек гуманитарий, не делает его автоматически командным лидером, мастером выступления на публику и т.п.
aamonster
06.10.2023 22:11-1Это да. Но всё же гуманитарий (если он действительно гуманитарий, а не человек без технических способностей, считающий, что это делает его гуманитарием) должен хоть сколько-то нахвататься знаний в смежных дисциплинах? Т.е. вроде бы историк или лингвист именно в плане описываемых в статье навыков должен быть не хуже технаря (хотя у технаря свои преимущества – как минимум, больше знаний в рабочей области).
Ну а в целом, естественно, "лучше быть богатым и здоровым, чем бедным и больным" – менеджер нужен именно со знаниями и навыками управления + крайне желателен некоторый багаж технических знаний, чтобы общаться с разработчиками. Плюс стрессоустойчивость – чтобы выживать самому и прикрывать команду.
iig
06.10.2023 22:11+5Раньше гуманитарием считали того, кто умел сочинять стихи, рисовать картины, знал несколько языков.. Сейчас того кто не смог в математику (ц)
un1t
06.10.2023 22:11+8А еще под гуманитарием, часто подразумевается не человек, шарящий в гумманитарных предметах, а человек не понимающий в технических.
aamonster
06.10.2023 22:11-1https://habr.com/ru/articles/765904/comments/#comment_26037976
Но это же неправильно! Это ж не делает человека гуманитарием.
Helloworld321
06.10.2023 22:11+1По моему мнению основная проблема тут не в роде деятельности, а в образе мышления. Есть люди, который взяли что-то за истину и на этом стоят, не слыша голоса вокруг, а есть наоборот - те, кто ни в чем не уверен.
titan_pc
06.10.2023 22:11-1Будем иметь в виду алгоритмику причинно-следственных связей и логические цепочкиЖенщины... И вот это вот всё. Сочетаются как кошки с собаками. Из-за того, что они в большинстве случаев свои цепочки выстраивают ещё с учётом эмоций. Если вообще то, что у них получается, можно цепочками связей назвать. Если Вася тут женщина, сама себя она не перепрограммирует. Бежать ей некуда. Не по телу тельняшка.
Да. Автор комментария сексист - где Ваша толерантность Вася?
sergeaunt
06.10.2023 22:11+1В среднем мужчины, по моему мнению, действительно больше дружат с логикой, чем женщины.
Но ведь какой фокус: когда мы переходим от усредненных величин к конкретным экземплярам, эти усредненные величины перестают иметь значение.
Например, вы всухую проиграли в шахматы женщине. Какая теперь разница, что в топ-N рейтинга Эло нет ни одной женщины? Вы лично к этому топу какое имеете отношение? Эта женщина лучший шахматист, чем вы, точка.
К чему я это всё? Да к тому, что в обсуждаемой статье логики и здравого смысла гораздо больше, чем в вашем комментарии.
Так что да, вы сексист, как раз-таки благодаря описанному в статье квадратно-гнездовому мышлению.
titan_pc
06.10.2023 22:11В статье - одна вода. О страданиях Василия. Весь здравый смысл в ней "Надо уметь общаться и договариваться. Слушать и слышать". Ещё бы написали, что люди воздухом должны дышать, а то помрут. И кучу книжек предложили бы почитать, как дышать воздухом.
glazko
06.10.2023 22:11Хороший пример того, как Гики в современном ИТ пытаются "поднять голову", быть более значимыми, полезными и залезть в тему аналитики, развития общего дела..
Но проблема в том, что Альфач Вася такого никогда не допустит и даже красивая, лояльная девушка ментор не спасет их от злых Чедов-менеджеровВасю не устраивают вовсе не сами идеи которые ему подают коллеги, его не устраивает что идеи развития ему подают "какие то Гики клавиатурщики"
Попробуйте ради эксперимента, идеи коллег подавать от себя и вы увидите как реакция Васи на них изменится
Kudriavyi
06.10.2023 22:11+3Странно, в конце такой провокационной и не особо содержательной копипасты я не нашёл рекламу телеграм-канала. Свою может оставить здесь...
V-core
06.10.2023 22:11+2Когда Вы обсужаете что для условного проекта хорошо / плохо вспомните про Принцип Карениной - Работающих решений единицы. Поймите Васю он, по-видимому, точно знает что должно быть для одного из возможных оптимального решения задачи. Такими образом проблема Василия состоит в том, что он не всегда может объяснить это решение с математической точностью.
Zenitchik
06.10.2023 22:11+2Не бывает "каждый прав по своему", бывает "каждый прав частично". Это симптом того, что задача нуждается в декомпозиции и более детальном обсуждении.
ETman
06.10.2023 22:11Я, как прошлый Вася, впечетлён хорошим изложением основных моментов мешающих взаимоотношениям на рабочем месте. Да и не только. Это точно, будучи вот таким Васей, пока мышление не поменяется, не понимаешь, почему как-то всё несрастается и к пониманию приходится продираться. Кажется, и всё говорится правильно, и делается правильно. Ведь так написано везде и умные ученые всё давно всё доказали. Но нет, не работает оно как написано в книжках.
Автор, спасибо застатью. Жаль что не сам её написал.
flass
06.10.2023 22:11+1В этом примере вам не кажется ли что Вася - просто не очень умненький? Человек во взрослом возрасте допускающий что мир чёрно-белый и есть всего две точки зрения - неправильная и его. Гм.. ну ребят. Очевидно же что Васе не хватает банального ума.
brotchen
06.10.2023 22:11Сегодня хочу разобрать пример одной из фундаментальных проблем в общении с такими бывшими гуманитариями, которую вызывает недостаток у них математического мышления. А именно — это проблема восприятия мира как черно-белого, в котором истина — одна единственная.
Единственный случай, когда есть смысл вести рассуждения в формате “это правильно” или “не правильно”, как мне кажется, касается этических вопросов.
Как-то мне всегда представлялось обратное - математическая и вообще научная истина единственна, а в гуманитарных отраслях всё в большой степени относительно.
lair
06.10.2023 22:11+5Я родом из гуманитарной сферы и профессии — бывший журналист. Думаю, у вас немало коллег бывших гуманитариев, ведь IT в тренде — крутые заработки, высокий темп развития, престижно. И как раз-таки часто не технари переходят в IT в менеджеры.
Сегодня хочу разобрать пример одной из фундаментальных проблем в общении с такими бывшими гуманитариями, которую вызывает недостаток у них математического мышления. А именно — это проблема восприятия мира как черно-белого, в котором истина — одна единственная.Что, простите? Вот я - гуманитарий по образованию, и одна из вещей, которую нам рассказывали приблизительно на каждом курсе - это то, что в гуманитарном знании нет "единственной истины". Причем тут математическое мышление?
То бишь я верю, что корень описанной мной проблемы у Васи — банально недостаток образования.
...так он не гуманитарий, ваш Вася.
Не надо, пожалуйста, приписывать гуманитариям проблемы недоучек.
ivanovsa_ru
06.10.2023 22:11+3Влепил автору плюс статье и в карму, потому что как Васю ни назови, а проблема бинарного мышления существует, и от нее куча проблем везде, не только в айти.
engine9
06.10.2023 22:11Самое важное, что это довольно просто фиксится выработкой навыка не "залипать" в первую пришедшую в голову мысль. Т.е. по сути это вредная привычка поддаваться автоматически пришедшей первой эмоции и как бы "защелкиваться" в этом сценарии. Если человек тревожен по жизни, то у него все прогнозы будут катастрофическими и жопа постоянно в огне.
Но стоит явить человеку пользу всестороннего осмысления происходящего, так он преображается.
Batalmv
06.10.2023 22:11Вопрос никак не относится к гуманитяриям/технарям. Просто Вася не терпим к другому мнению и НЕ УМЕЕТ слушать и слышать. Вот и все. Чистый софт скилл, точнее его отсутствие :)
dididididi
06.10.2023 22:11Вообще то Вася, готов слушать чужие доводы. Просто его опоненты, считают, что их доводы верны просто потому что они есть.
Mausglov
06.10.2023 22:11Вообще-то, у оппонентов Васи могут быть и другие причины. Довольно распространённая - это "если я признаю, что прав Вася, то это значит, что моё решение было плохим, а это, в свою очередь, значит, что плохой я".
ChePeter
06.10.2023 22:11Достают эти гуманитарии иногда существенно.
Вот уже месяц не могу объяснить программистам-гуманитариям разницу между NULL, словом 'NULL' и словом ''
Когда я их называю неучами и бездарями они жалуются начальству и скрипят зубами.
PsihXMak
06.10.2023 22:11+1Нуу, если у вас не получается целый месяц объяснить разницу между NULL и ‘NULL’, то проблема в вас и ваших объяснениях. Тут даже ребёнок поймёт.
releyshic
06.10.2023 22:11+1"Когда я их называю неучами и бездарями" удивительно, что они начальству жалуются, а не в трудовую инспекцию, учитывая, что оскорбления уже месяц длятся
По подходу к обучению сразу видно, кого надо в уборщики переквалифицировать
lair
06.10.2023 22:11Вы уверены, что дело в том, что они - гуманитарии (кстати, почему вы уверены, что они гуманитарии?), а не в том, что вы плохо объясняете?
engine9
06.10.2023 22:11+1По-моему, то что вы описали называется — ригидностью. И не зависит от того "гуменитарий" ли человек.
OcMaRUS
06.10.2023 22:11+2Всегда поражало умение простое изложить в 100 раз большем тексте ;)
Но прям ощущаю нужность таких работ в компаниях Тинька и ВК ;)
Samid777
06.10.2023 22:11+1Странно...
Обычно на моей практике практике технари как раз имеют два представления об ответе, или правильно, или не правильно, либо зависит от условий.
У гуманитария же, число пи может при желании иметь значение отличающегося от всем известного. Как раз с вопросами, а почему именно столько? А кто доказал что именно столько? А вдруг в другой вселенной оно будет равно другому числу? Даже в той же само системе счисления.
Может конечно в IT и не так, но в таком случае сфера получается наполовину техническая, наполовину творческая, и работая там нужно быть и технарем и гуманитарием одновременно.
Давайте дадим каждому пользователю права близкие к правам администратора.
Не нет, глупость выйдет.
Да нет, вышла википедия.Zenitchik
06.10.2023 22:11+1Как раз с вопросами, а почему именно столько? А кто доказал что именно столько? А вдруг в другой вселенной оно будет равно другому числу?
А Вы уверены, что те, кто НЕ задаются этими вопросами, действительно технари?
Samid777
06.10.2023 22:11Смотря какие вопросы, и когда они уместны. Когда у меня чтото не работает, я не просто ищу наугад, что сделать, а ищу, почему это не работает. Если оно заработало, то я буду спокоен, только после того, как разберусь, почему не работало, и почему заработало. Если этого не делать, то зачастую видел, что это приводит к ошибкам. Взять простейший пример, человек поменял полярность, и все заработало, и сделал вывод, что на устройстве должна соблюдаться полярность. А проблема была в утечке на землю в двух точках, и когда сменили полярность, то утечка на землю стала на минусовом, а не плюсовом проводе, что привело к появлению ошибочного вывода.
Если вам нужен например хомут на трубу, и вы в магазине попросите продавца, который быстро посчитал какой хомут нужен, исходя из диаметра трубы, доказать что пи равно примерно 3.14, то это точно не технарь. Так что заваться вопросами нужно правильно.
Конкретно про себя. Держа лист А4, вдруг оказалось интересным его свойство. Вдвое сложил, соотношение сторон не изменилось. Тут же вопрос, а почему так, а когда так, и какое должно быть соотношение сторон. Что соотношение должно быть равно корню из двух, предположил интуитивно. Проверил... оказалось верно. А вот число ПИ, эти вопросом, если не ошибались, каждому помогают задаваться в школе. Нужно было взять нитку, намотать на цилиндр, разделить длину нитки на диаметр. И понять, что отношение будет всегда одинаковым. И то, что это число всегда одинаково, всем становися очевидно. А вот почему именно такое... я могу ошибаться, но это ближе к аксиоме.
dlc
06.10.2023 22:11+2ТС путает тёплое с мягким, сначала говорит про гуманитариев, потом почему-то переключается на поведенческие паттерны, а в конце признаётся, что всех нас налюбил кликбейтным заголовком. Не будьте, как ТС.
Ну, и раз в тексте есть типичная ошибка обращения к уникальной выборке, давайте я тоже сыграю на этом поле. Я гуманитарий, за спиной филфак и истфак, в разработку попал случайно, начинал с админства сайтов, сейчас занимаюсь всяческим engineering management'ом.
Имею ровно противоположный опыт: подавляющее большинство "технарей" и всяческих выпускников профильных ВУЗов обладают максимальной психической ригидностью в том, что касается работы. В идеале, решение должно быть написано в книге, документации, докладе, в общем, зафиксировано. И вообще, "всегда делали вот ТАК, зачем делать по-другому".
Выходцев из "технарей", особенно СТО, это тоже касается. "Мы не будем пользоваться этим инструментом, потому что я когда-то пользовался, мне не понравилось, значит инструмент плохой" - сплошь и рядом встречал.
Теперь осталось опровергнуть моё личный опыт чужим личным опытом и так мы быстро доберёмся до мордобоя :)
Samid777
06.10.2023 22:11+1Такое скорее происходит потому, что технари, с которыми Вы встречались, пользуется исключительно опытом, но есть пробел в понимании теории и ее применении на практике. Я очень долгое время работал релейщиком, (связь), и там людей, которых научили эксплуатировать аппаратуру, но не смогут сделать расчет уровня закона Ома процентов 90. Слова дифракция, интерференция или зоны Френеля для них из области фантастики.
Типичные фразы такого технаря:
Я (или мой коллега) так сделал, оно не заработало, значит так делать не надо.
Я (или мой коллега) так делал, у нас все заработало, значит именно так делать будем.
У меня было то же самое, поменял блок Б4, все заработало. (а достаточно было поменять расходник в блоке)
Я с этим никогда не встречался, нужно чтобы один раз показал тот, кто делал это раньше.
AkaZLOY
06.10.2023 22:11+1Заголовок кликбей.
По существу:
Есть у меня такой "Вася-менеджер". Начинаешь задавать ему вопросы, он агрится и превращает своё незнание в некомпетентность всех вокруг: "Почему я это знаю, а вы нет?" :D
Andrey-Kotov
06.10.2023 22:11А причем тут вообще гуманитарий? Похоже что статья это просто частный случай где болит у авторки, и случайно вышло что Вася был из гуманитарных наук. На будущее предлагаю писать во вступлении что есть огромные проблемы в управлении у технорей, но сейчас опишем частный случай произошедший у гуманитария.
Плюс вы не далеко ушли говоря про серые оттенки, логичней говорить что есть радуга и цвета за пределами наших ощущений. Тогда речь уже будет не про сравнение темно серого со светло серым, а про поиск более подходящего цвета контексту. Другими словами - истины вообще нет, есть подходящие к данному месту догадки.
vladimircape
06.10.2023 22:11Я как начал читать и как увидел сразу закидыванием определениями, что такое общение , сразу понял автор повырывал фразочек и сейчас что-то будет пытаться доказать. По всей статьёй я вижу что автор даже и не принимает в расчёт что может Вася и вправду прав, по всей статье идёт обсуждение что или Вася не прав, а где может быть и все таки прав, то там он якобы токсичен. Ну типичная женская логика. Типа утверждение правильно если оно мне нравится. Вот сидит такой Вася сеньор , остальные менеджеры и мидлы, менеджеры могут говорить глупости ,а мидлы от страха или неопытности будут поддерживать, и все сделают Васю токсичным,а потом удивляются почему проект провален
BugM
Менеджер обсуждающий как делать профнепригоден.
Разработчик обсуждающий что делать для продукта профнепригоден.
Исключения как обычно бывают. Особенно много их в стартапах. Но в целом это работает.
fo_otman
Я как заказчик хочу поделить на ноль. Делайте.
Breathe_the_pressure
Заказчик "профнепригоден" :)
lazy_val
И Вы правы
Т Вы правы ...
И Вы правы!!!
myswordishatred
Да можно и на ноль поделить если есть такая потребность. Просто надо осознавать ограничения, к которым это приведёт.
iig
Математики такие: "Нельзя делить на ноль". Они же, в другом сочинении: "Можно". И кто после этого гуманитарий? ;)
myswordishatred
Вы не до конца честны. Математики такие "В этой аксиоматике деление на ноль не определено". Они же, в другом сочинении: "В другой аксиоматике деление на ноль определено, но это влечёт за собой нарушение привычных нам свойств операций".
iig
Математики исследуют выдуманные свойства выдуманных миров. Зато когда эти своства находят пересечения с реальностью, тут и набигают технари ;)
garrydvaraza
как ты круто обобщил всех математиков
alexEtse
Если кто-то без оговорок или вне контекста заявляет, что на ноль делить нельзя - сильно вряд ли он математик.
В контексте (обычно речь идёт о действительных числах) или с оговорками - да, это утверждение может быть верно. Но помимо привычных действительных чисел и "где-то слышал о кОмплЕксных" - еще много видов чисел есть.
dopusteam
На js вполне можно делить на ноль)
Batalmv
Получите бесконечность, требование выполнено :)
sergeaunt
Плюс бесконечность или минус бесконечность?
Batalmv
Очевидно зависит от числителя :)
А вообще, вопрос можкт быть достаточно конструктивным, если смотреть на результат, как предел
Более того, имеет смысл рассматривать бесконечности разных порядков ... и неожиданно прийти к оценке сложеости алгоритмов, как практическому применению
Хотя конечно в лоб 1/0 имеет мало смысла, но за ваши деньги - любой каприщ
Ru6aKa
Зависит от того делим мы на плюс ноль или на минус ноль.
sergeaunt
Я думаю, больше таки зависит от того, продаем мы или покупаем.
BugM
Сделал. В переменной infinity. В чем проблема? Это значение можно показать пользователю или крутить дальше любую математику.
alexEtse
Не, если попадёт на ревью математику - завернёт. Придётся уточнять, знаковая или беззнаковая бесконечность, операции в колёсах, в полях, в лугах...
Сделать-то это всё не проблема - благо уже всё давно придумано, осталось только сделать соответствующие классы и перегрузить операторы.
Но вот потом продаваны замучаются объяснять заказчику про колёса, поля и луга, и что это не вещества )
BugM
Тонкости зависят от того что надо. Реализовать любой вариант не очень сложно. Точнее оно уже все реализовано, надо просто взять нужную библиотеку и аккуратно ее заиспользовать.
Продаваны пойдут к тому менеджеру который ставил задачу. Разработка просто ее нормально сделала. Менеджер и будет отвечать за то как это должно работать и зачем это пользователям. В крайнем случае менеджер увольняется и нанимается другой.
alexEtse
Вот именно - проще всё свалить на менеджера и уволить его, чем объяснить заказчику нюансы высшей математики...
BugM
Если разработка что-то объясняет заказчику, то у вас большие проблемы в процессах.
Разработка пишет документацию. Сама или техписателями, по разному бывает.
Разработка говорит с менеджерами. Обычно через тимлидов, но иногда и напрямую можно если все хорошо общаются и понимают друг-друга то лишнее звено в виде тимлида убираем.
Разработка иногда бывает третьей линией техподдержки. То есть к разработке имеет доступ ваша вторая линия техподдержки. Желательно прямо физический доступ, а не только тикеты. Чтобы лиды техподдержки иногда в живую говорили с лидами разработки.
Хотя бы раз в год за едой и напитками поддержку с разработкой и с менеджерами собирать полезно. Да, это командировки нынче. Для фирмы дорого. Но это стоит того. Всем есть о чем поболтать. У всех много баек и веселых историй. Картинки с экрана превращаются в живых людей. Это сильно облегчает дальнейшую работу.
А клиенты к разработке доступа иметь не должны.
alexEtse
Разработка не принимает на работу и не увольняет, это делает фирма. Как именно фирма будет общаться с заказчиком - "продажниками на понятном бизнесу языке" или прослойкой между продажниками и разработкой в виде менеджера - для разработки вообще нет разницы.
Посыл был в том, что из вашего сообщения следовало, для фирмы проще уволить менеджера, свалив всё на него, чем объяснить заказчику, что же он на самом деле хочет. Что как минимум отчасти соответствует действительности - продажи радостно подпишутся под продажей чего угодно, т.к. исполнять это не им.
Tsimur_S
По определению деление обратно умножению. В каком месте inf обратна нулю? Чему будет равно произведение inf на 0?
BugM
Ну будет там NaN в результате. Его точно так же можно показывать пользователю или продолжать делать с ним какую-то математику. Иногда это даже имеет какой-то смысл. Вам от этого проще стало?
Tsimur_S
Да я ж не против. Просто укажите заказчику что у вас свое волшебное деление, отличное от общепринятого определения. И что (a/b)*b = a не выполняется.
BugM
Математика гораздо многограннее чем вам кажется.
alexEtse
Не всегда деление определено так. Для вещественных чисел - да. В общем случае это может быть и отдельная операция.
В колёсе можно сделать деление на ноль, например. Или при проективном расширении числовой прямой можно делить на ноль.
Если кратко - то "на ноль делить нельзя" это упрощение, предназначенное для массового обучения в школе, дабы не смущать неокрепшие мозги высшей математикой, их там даже банальными гиперкомплексными числами стараются не смущать.
Tsimur_S
Можно придумать свое деление и потом сделать деление на ноль.
У нас в школе говорили что "операция деления на ноль не имеет смысла". Что в общем то и демонстрируется вашими примерами, нужно придумать новую операцию деления и тогда она обретает смысл.
alexEtse
Ну не всякую операцию можно назвать делением, совесть-то надо иметь, даже если она кричит и царапается! )
Но в колесе и на проективном расширении числовой прямой - деление на ноль возможны. Над полем действительных чисел причём "обратно совместимо" с привычными одноимёнными операциями.
Ну точнее сказать, что оно для нуля не определено. Потому что в действительных числах там сингулярность возникает, а кроме действительных чисел в школе разве что про кОмплЕксные говорят. Грузить школьников группами, кольцами, полукольцами, полями, лугами и расширениями числовой прямой, гиперкомплексными числами, и тем, что при возведении в квадрат единицу дают не только +1 и -1 - не факт, что в спецклассах-то к отъезду крыши не приведёт.
Tsimur_S
Хоть убейте не понимаю следующие вещи: 1) как оно может быть над полем действительных чисел если у нас в результатах всплывают какие-то Infinity?
2) если обычное привычное деление это бинарная операция а деление в колесах это унарное то какое же это деление? Это утконоса разрезали пополам и назвали уткой. Или утку выдают за пол-утконоса. Не сильно в общем-то важно.
Проективное расширение числовой прямой тоже забавная штука. Да теперь делить на ноль мы умеем но не умеем умножать и даже складывать(!!!) без оговорок.
А если исходить из начального определения деления как операции обратной умножению получается что и делить тоже не умеем, раз умножать невозможно. Просто опять получилось какое-то свое деление, местечковое.
Что бы было проще понимать мою логику, попробуйте дать несколько ответов:
1) Существуют температуры ниже абсолютного нуля. Это возможно/не возможно?
2) Сумма всех натуральных чисел равна -1/12. Это возможно/не возможно?
alexEtse
Там сказал же - обратно совместимо. Т.е. над полем действительных чисел это "те самые" операции. Деления на ноль открываются в расширениях - в колесе или на проективном расширении числовой прямой. Т.е. там мы уже имеем дело с другими числам, включающими в себя действительные.
В афинном расширении числовой прямой добавили +бесконечность и -бесконечность, а в проективном расширении знаковые бесконечности сходятся к беззнаковой бесконечности.
А в колесе ввели унарную операцию деления, "отвязанную" от умножения.
Еще вроде можно делить на ноль в лугах (common meadows), там что-то похожее на колёса, но по-другому и вроде обходятся без бесконечностей (навскидку не помню детали).
Я ж там не просто так говорил, что и единицу в квадрате могут давать не только +1 и -1. Это вам не банальная мнимая единица. Так что действительные числа уже давно не предел возможностей.
Конечно возможно.
Но вы перешли из математики в физику. А в физике всегда надо помнить про условия применимости. А то, знаете ли, оно и без всяких СТО с ОТО, в классике, можно получить неработающий закон сохранения энергии и КПД выше 100%.
Так что тут "каков вопрос - таков ответ". Вы упростили формулировку вопроса, не уточнив условия, я не уточнил, как я этого добился ) Кстати, и отрицательную абсолютную температуру, и КПД выше 100%, можно наблюдать в быту.
Думать над этим вопросом не имеет смысла, т.к. отрицательные числа не являются натуральными, про ноль надо уточнять, которым определением и обозначением натуральных чисел мы пользуемся (от этого ничего не меняется по сути, но меняется форма записи в виде индексов у N и Z).
Zenitchik
Ни разу о таком не слышал. Только об ошибках определения КПД или о попытках выдать за КПД что-то другое (холодильный коэффициент, например).
alexEtse
Скажем так ) Это не "что-то другое", это КПД, но названный по-другому, дабы не смущать общественность.
Суть в том, что закон сохранения энергии в классической физике выполняется для изолированной физической системы. Если система неизолированная - то ЗСЭ в этой системе не выполняется и КПД может быть больше 100%.
Система "кондиционер в комнате" - неизолированная, потому КПД кондиционера (что на нагрев, что на охлаждение) может превышать 100%, т.к. указанного добра он производит больше, чем берёт энергии из розетки. В изолированной системе (кондей, комната и улица) его КПД конечно же не превысит 100%, но не всегда нужно или даже не всегда возможно для целей расчёта учитывать, что же там еще участвует в теплообмене.
Так что да, это "что-то другое" - всего лишь КПД в неизолированной физической системе.
Zenitchik
Нет. Это не КПД по определению. Настоящий КПД холодильника, как тепловой машины, - отрицателен.
alexEtse
КПД - это отношение полезной работы к затратам энергии. Всё зависит от того, в изолированной или неизолированной физической системе определяется то и другое.
В неизолированной системе даже закон сохранения энергии не выполняется, чего уж там от КПД-то хотеть... А в изолированной системе КПД не превышает единицу именно из-за ЗСЭ.
Zenitchik
Выполняется, если не забывать об обмене энергией с окружающей средой.
А если забывать - вообще ничто рассчитать нельзя.
alexEtse
А если вы добавили в систему окружающую среду - то система перестала быть незамкнутой. А если у вас только комната, розетка и ящик, который производит работу больше, чем берёт энергии из розетки, и окружающую среду вам не дали вообще ни в каком виде и никакими характеристиками - то ой.
Можно, при желании. Считают же в неинерциальных системах отсчёта, где не выполняются законы Ньютона, например.
Zenitchik
Значит он берёт энергию откуда-то ещё. Всего навсего.
Выполняются, но существуют инерционные силы.
alexEtse
Для целей расчётов - это пофиг. Посчитать можно и для незамкнутой системы. А вот объяснить происходящее корректно с физической точки зрения - уже нет.
И вот как раз не существуют сил инерции, если отталкиваться от общепринятых определений законов Ньютона.
А то, что называют "силами инерции" - это математическая фикция, представляющая собой поправку для расчёта в неинерциальной системе отсчёта.
И если попытаться использовать силу инерции для объяснения физического смысла явления - то это и будет то самое "нет" выше, т.к. за силами инерции не стоит никаких физический взаимодействий.
Т.е., например, это не сила Кориолиса уводит тело по горизонтали, а вращающаяся поверхность "убегает" от него, в то время как тело летит в соответствии с законами Ньютона - прямолинейно и равномерно (или покоится, что то же самое), по крайней мере по горизонтали, ну или на него действует какое-нибудь притяжение по вертикали.
Но для целей расчёта на практике часто быстрее и проще посчитать в неинерциальной системе отсчёта, связанной с вращающейся поверхностью, с поправкой, назвав эту поправку "силой Кориолиса", чем посчитать в инерциальной системе отсчёта и потом пересчитать результаты для неинерциальной системы, движущейся относительно этой инерциальной.
Zenitchik
Корректное объяснение с физической точки зрения: "Поступает столько-то Ватт из неизвестного источника".
В ИСО не существует. А в НИСО - они появляются. То что Вы дальше пишете - это описание процесса в ИСО. В НИСО - приходится вводить инерционные силы.
Ну вот! Вы сказали другими словами то же, что и я.
alexEtse
С физической точки зрения: "Потребили 100 Ватт энергии, произвели 120 Ватт тепла. Не пугайтесь, всё в порядке, система не замкнутая".
Не появляются. Система отсчёта не является участником физических взаимодействий, а "так называемые силы инерции" характеризуют именно систему отсчёта, т.к. с ускорением движется именно она.
Zenitchik
Так не делается.
И что?
В уравнение их записывать приходится? Значит они есть.
SerjV
Ничто не запрещает.
Скорее наоборот - далеко не всегда имеет значение, насколько там нагрелся или охладился наружный воздух (и что вообще с ним стало), важно лишь сколько тепла забрали/подали в помещении и сколько потребили электроэнергии. Если есть возможность посчитать без ненужного - без него и посчитают.
Не приходится. Можно записать всё в ИСО без этих фикций. А вот взаимодействия учитывать как раз приходится.
Zenitchik
Но в тоже время не принято.
Важно лишь то, сколько тепла было перекачано тепловым насосом, и сколько паразитного тепла он при этом выработал. :)
Можно. Но это никак не подтверждает исходный тезис:
Так вот, если в НИСО ввести инерционные силы - то с законами Ньютона
Вы так говорите, как будто силы на самом деле есть, а не придуманы для удобства записи уравнений.
Tsimur_S
Значит неправильно распарсил вашу фразу. Не деление на ноль обратно совместимо над полем а само деление. Так понятнее, спасибо.
Так я о том и говорю что это переопределение операции деления. Естественно тогда можно что угодно строить. Взамен получаем вопрос чему равно 0*x в общем случае.
Это просто пример или имеет какое-то прямое отношение к деления на ноль?
В первую очередь тут нужно помнить об определениях. Конкретно тут важно как определить понятие температуры.
Если мы определяем температуру как некое число характеризующее модуль скорости молекул то ниже абсолютного нуля мы не можем опускаться, потому что двигаться медленнее чем 0 м/с невозможно. Ну и очевидно что модуль положителен.
Если мы переопределяем понятие температуры то можем так случиться что и температура будет меньше абсолютного нуля. Но это уже совсем другая температура! Которая исключительно по совпадению называется температурой.
Потому мне весьма интересно как я могу наблюдать температуры ниже абсолютного в быту, не переопределяя понятие температуры.
Не понятно причем тут отрицательные числа и ноль. Под натуральными числами имеются в виду числа 1,2,3,4...
А вот что имеется в виду под суммой это уже совсем другой вопрос.
alexEtse
Ок.
Не уверен, что корректно говорить о переопределении. Переопределить - это, например, сделать 2+2=22 в вещественных числах. А тут у нас еще и сами числа становятся другими.
Это пример того, что у нас есть вне вещественных чисел.
В первую очередь всё-таки о границах применимости теорий. Определения подтянутся по зависимостям от теории.
В физике отрицательные температуры возникают немного по другой причине - из-за того, что термодинамика к некоторым процессам неприменима (у неё вообще тяжко с неравновесными состояниями), а математический аппарат применили от неё. Но можно, кстати, и поиграться с определениями - например, с переходом температуры через бесконечность (и где-то там рядом можно попробовать еще и проективное расширение числового ряда приплести, где + и минус бесконечности сходятся в беззнаковую бесконечность).
Под натуральными "имеются в виду" по-разному - 0, 1, 2, 3... и 1, 2, 3... без нуля, в зависимости от математической школы. В России/СССР принято было натуральными числами считать без нуля. Но это как раз вопрос определений и обозначений - приходится учитывать, что N в работе российского математика это скорее всего без нуля, а у иностранного - с нулём. Но это не критично, если "согласование определений" проделано.
А вот тут как раз особо думать не приходится, если говорим о натуральных числах. Или надо указывать какое-то расширение над ними, но тогда это будут даже не вещественные числа )
Проблема определения "на ноль делить нельзя" заключается в неполноте формулировки - делить на ноль нельзя в полях, и в частности - в вещественных числах. Тогда формулировка будет верной.
Tsimur_S
Отличный пример. Сделав так мы потеряем свойство поля. Потому что бинарная операция + должна обладать коммутативностью. Поскольку + зарезервирован за операцией сложения то назвав конкатенацию сложением мы просто добавили путаницу.
Аналогично и с колесами/расширениями. Мы отказались от свойств операции *(или 0*inf там все же определено?) и переопределили привычное нам деление.
Тут то и начинаются проблемы. Что мы начинаем использовать разные определения для одного слова.
Зачем? Я же не зря указал что нужна сумма всех натуральных чисел. Можно рассматривать ее как сумму расходящегося ряда. И дальше получить что угодно.
На ноль делить нельзя это неправильная формулировка при любом раскладе. Даже оставаясь в вещественных числах вы можете делить сколько вам угодно, правда результата не сможете получить никакого("разделить"). Правильно будет "нельзя получить результат деления на ноль считая деление обратной операцией к умножению".
Либо мы переопределяем определение деления либо умножения, третьего не дано.
alexEtse
Ну оно уже умножение не всегда коммутативно, хотя для вещественных чисел - коммутативно.
Ту еще одна "засада" есть... Мы можем изменить определение операции, не изменив её свойств. Ну, например, поменяв аксиоматику так, что часть теорем станет аксиомами, часть аксиом станет теоремами, ну и определениям заодно достанется. Но по существу не изменится ничего.
"Не совсем"(tm). Это уже не вещественные числа. Мы не переопределили операции для вещественных чисел, мы сделали новые числа. С сохранением "обратной совместимости" с вещественными или без таковой - вопрос вторичный. Более того, если мы переопределим операции способом, описанным выше (т.е. "поменяли формулировки, но по существу ничего не изменилось") - то эти числа уже не будут вещественными. Ну или можете ввести новую операцию - никто не мешает, можете вводить любую новую операцию, не затрагивая имеющиеся.
Вы сказали "натуральных чисел", этого достаточно, в т.ч. для определения операций над ними. Если бы сделали своё расширение к ним - тогда бы порассуждали...
Вполне корректная при указании на то, для каких сущностей эта операция применяется. В полях на ноль делить нельзя, потому что эта операция не определена для деления на ноль. В колёсах или там лугах - можно, потому что там определена. Ну или вон при некоторых расширениях числовой прямой определена.
Для истинности утверждения не обязательно в нём самом обосновывать почему можно или нельзя.
Tsimur_S
Речь про сложение или умножение?
Давайте начнем от яйца, определения кольца. Там вводятся две бинарные операции + и *. Первая традиционно называется сложением вторая умножением. Можно сказать что вот тут и определяется что такое сложение и что такое умножение.
Так вот первая операция строго коммутативная вторая не обязательно. Называть конкатенацию сложением конечно можно, никто не говорит что строки образуют кольцо но мягко говоря странно. Зачем так называть операцию которая отличается от привычного нам сложения?
Мы именно что переопределили. Операция умножения была определена на всей структуре кольца/группы а в проективном расширение вдруг стала действовать избирательно.
Деление было бинарной операцией а стало унарной в колесах.
Так ее и ввели.
Не вижу никакого противоречия с утверждением что сумма всех натуральных чисел равна -1/12.
Делить можно, разделить нельзя. Это делает само утверждение некорректным.
Конечно определена. Потому что ее переопределили. Вместе с умножением.
alexEtse
Для действительных чисел - обе коммутативны.
Только эти структуры - на множествах. Числа - могут быть примерами этих структур, но эти структуры - не обязательно числа. Множества целых или действительных чисел - кольца.
Да назвать-то можно что угодно и как угодно. Хоть переименовать сложение в умножение, а умножение - в сложение...
А вот "не совсем". Сперва мы добавили к действительным числам плюс и минус бесконечности в афинном расширении числовой прямой. Т.е. это уже не действительные числа, хотя и включает в себя множество действительных чисел. А потом сделали проективное расширение, добавив к предыдущему беззнаковую бесконечность, ну и заодно превратив прямую в нечто, похожее на окружность.
Которые уже не то же самое, что множество действительных чисел, т.к. даже в том случае, когда колесо строим на основе действительных чисел, к ним добавляем еще больше элементов, чем при проективном их расширении. Но на подмножестве такого расширения действительных чисел, составляющем собственно действительные числа, ничего не меняется, в т.ч. бинарная операция деления сохраняет свои свойства и выражается через умножение и унарное деление колеса - ну примерно как деление в действительных числах в свою очередь можно выразить через умножение на число, обратное делителю.
Достаточно того, что речь идёт о натуральных числах. Расширение натуральных чисел - уже не будет множеством натуральных чисел, хотя и будет включать в себя натуральные числа.
Делить в действительных нельзя, потому что деление для этого случая не определено для действительных чисел. Если множество действительных чисел расширить - то делить будет можно, но это уже не будет множество действительных чисел.
Как уже обратил внимание выше - не только переопределили, но и применяют уже не к действительным числам. С действительным числами лишь сохранили "обратную совместимость", включив их в состав нового множества в качестве подмножества (но в общем случае - эти структуры могут быть и не над числами).
Tsimur_S
Да.
Да.
Зачем?
Операция умножения на проективном расширении числовой прямой определена для всех значений? Да/нет?
Ага, тут унарная а тут бинарная.Но это не в коем случае не переопределение. А умножение тоже определенно для всех значений?
Да все так. Именно натуральные числа а не их расширение. Сумма их всех равна -1/12.
Именно так.
alexEtse
Нет конечно ;) И сложение не для всех определено.
Пока еще не переопределение в том смысле, что в условиях применимости бинарной операции деления для вещественных чисел ничего не поменялось, ну разве что придётся перед делением дописывать значок умножения, но можно и упростить запись - а тогда и визуально разницы не будет :)
Кажется, тут спор о значении термина "переопределение"? А то ведь у нас тут не только деление модифицировалось, но и остальные операции...
Нельзя дополнить множество чисел новым элементом и не модифицировав операции под него. Вот даже вводя a=0^(-1) - всё равно что-то придётся изменять. А можно ведь, как вариант, ввести 1/0=0...
Смысл в том, что если мы вводим новые элементы - мы создаём новые структуры, и определяем операции уже для них. А не меняем операции для существующих структур.
Тут да. Как и сложение.
Не, не получится без расширения - для применения расчётной формулы придётся за них выйти.
Ugli
это можно, но "очень долго, очень дорого и деньги вперёд"
Zenitchik
Познание бесконечности требует бесконечного времени.
eton65
Заказчик не хочет делить на ноль, ему нужно что-то другое. А "делить на ноль" это и есть "как делать", куда заказчику вникать не стоит.
Loggus66
Вот ничего себе. Сейчас посетители начитаются и тимлиды перестанут рассказывать, как что-то лучше сделать своим подчинённым, с учётом сроков и бюджета, а разработчики будут тупыми болванчиками, неспособными оценить, что стоит сделать дальше для всего продукта, или неспособными сразу сказать хотя бы "я сделаю, но будет чушь, сразу подумайте, точно ли вам это надо". Это ж экономит время.
Anarchist
Ага, семь красных линий.
MaxKitsch
Это не совсем верно, как мне кажется. Просто, как правило, менеджеры не квалифицированы обсуждать «как», а разработчики «что» и это выливается в пустую трату времени.
Профнепригодны те, кто не смыслит в своей предметной области. То, о чём говорите вы — не более, чем плохо выстроенная коммуникация.