Массам предлагается образ "твёрдого, решительного человека", и массы взывают к "наведению порядка жёсткой рукой". В этой небольшой статье я попробую рассказать, почему "жёсткие руководители", как правило, совершенно не нужны вам в вашей коммерческой компании.
Печально, что вы не видите разницы между решительным (антоним - безвольный) и властным (антоним - не желающий демонстрировать свою власть) человеком.
Коммерческой компании как раз нужен твердый и решительный человек, умеющий задать четкие границы и четкие правила. По четким правилам комфортно работать. Четкие границы легко соблюдать.
Начну с главного. На мой взгляд, желание руководителя "навести порядок жёсткой рукой" почти всегда означает не владение представлением о предмете управления, его сложности, и нежелание разобраться в этом. Другими словами, такой руководитель как бы заявляет: "Я некомпетентен, и объект моего воздействия пусть сам опустится на мой уровень".
Это определение (с моей точки зрения), хорошо характеризует властного человека и недалекого человека. Но никак не решительного и твердного.
А если серьезно, то что в такой жизни плохого? Знакомому явно хватает на все его хотелки. Возможно, что он отлично умеет признавать свои ошибки (не отказывается от переезда в Австралию из-за ипотеки, не добивает коленку катанием только из-за наличия комплекта сноуборда хай-класса, не живет с нелюбимой женой ради ребенка).
Вот если бы он раза 3 подряд женился/стал отцом в браке/развелся - можно было бы задуматься о наличии системной ошибки.
Я знаю, что серийное производство и разработка - это разные процессы.
Для меня суть в том, что на серийном производстве заранее известен конечный результат и набор деталей, который нужен для производства. Кроме того, заранее зафиксирован процесс достижения результата: в каком порядке соединять детали, чтобы это занимало меньше времени.
А в разработке может оказаться, что через спринт вы узнали такие детали, из-за которых ваше представление о конечном результате (или о процессе достижения результата) коренным образом изменилось. И тут без гибкости никак.
Суть процесса другая, потому что по сути в разработке вы создаете прототип (или концепт) автомобиля. А потом копипаста сильно облегчает серийное производство.
Поэтому для серийного производства важен налаженый (работающий) конвейр, а для разработки - налаженый процесс Agile.
Только я не понял, что вы хотели сказать.
И за что мне слили карму, кстати, тоже не понял. Но слили явно после того, как я отметился в комментариях под этой статьей.
Т.е. заголовок звучит так: Если ты пришел к команде со своими требованиями к продукту, то Agile невозможен. Но это не так. Контрпример: Аналитик может формулировать прекрасные требования. И дальше команда может реализовывать эти требования по спринтам максимально быстро. И это будет Agile.
Ваш специфичный пример из статьи говорит только о том, что хорошая команда при хреновом аналитике может за счет принципов Agile оперативно выяснить всю хреновость требований. А если требования сформулированы хорошо - как это искоренит Agile?
Дальше вы пишете про согласование (не про формулировку!):
Если требования согласовываются до того, как команда разработки о них узнает, то это точно не Agile.
Это неверно, т.к. выше я уже привел контрпример с нормальным аналитиком и нормальными требованиями.
Дальше в комментарии вы пишете
Часто вижу следующую картину: в рамках водопадной модели все требования прорабатываются до мелочей
Это совсем другая ситуация. Когда на одном планировании распланировали сразу несколько спринтов. 2-6 или больше. И отказываются заниматься перепланированием после завершения первого спринта. Тут я с вами соглашусь, что это не Agile, а имитация. Так как нет гибкости в планировании. Но это совсем о другом. Не то, что вы писали в заголовке. К сформулированным (и согласованным!) требованиям отношения не имеет. И вот здесь я начинаю подзревать, что вы натягиваете сову на глобус.
А вот это совсем из другой оперы:
Ситуация бы изменилась, если бы команде дали возможность предлагать изменения в функционале
Даже если команде не дают предлагать изменения в функционале - это не искоренит Agile, т.к. не является необходимым условием Agile. Внесение изменений со стороны команды может быть приятным бонусом, когда команда достигла нужного уровня зрелости.
Детализация требований командой является необходимым, но не достаточным условием.
Детализировать можно после того, как требования согласованы. С моей точки зрения вы опять говорите не о том, что у вас сформулировано в заголовке и в статье. Детализировать и согласовывать - это совершенно разные процессы.
Поэтому у меня и возник вопрос: что это за магия?
Можете еще раз сформулировать с примером, что вы хотели сказать статьей?
Часто вижу следующую картину: в рамках водопадной модели все требования прорабатываются до мелочей, а затем их передают команде с предложением "давайте в Agile-формате найдем способ сделать это подешевле".
Побуду занудой: в таком процессе предлагаемое вами изменение не изменит сути процесса разработки. Как процесс не был Agile-ом, так он им и не станет.
Agile - это не про поиск самого дешевого решения. Он больше про гибкость (менять продукт в соответствии с новыми требованиями) и возможность добавлять функционал небольшими порциями.
Есть ощущение, что вы по одному случаю (который специфичен для вашей схемы работы, и вам встречается довольно часто), пытаетесь натянуть сову на глобус.
Если требования согласовываются до того, как команда разработки о них узнает, то это точно не Agile.
А можете объяснить почему?
Выглядит как карго-культ: "Чтобы был Agile, необходимо ознакомить команду разработки с требованиями до согласования требований. И тогда фичу получиться реализовать за один спринт, а не за 4 (или даже больше, если считать стабилизацию и тестирование)."
К тому же не советую Whoosh, «МТС Юрент» и «Яндекс» ссылаться на нарушения ПДД, санкции за которые и без того уже имеются в КоАП РФ. Тогда получится нарушения правового принципа Non bis in idem («не дважды за одно и то же»).
Предположу, что потребителя услуги "аренда самоката", наказывать будут не за нарушение ПДД. А за то, что во время аренды самоката он допустил административное правонарушение.
Поясню на примере, почему это разные вещи: Если турист совершает административку в чужой стране, то в следующий раз его легко могут развернуть при въезде в эту страну. Потому что не нужны закононепослушные туристы. Чтобы не мешали законопослушным туристам отдыхать.
Но тесты по НФ лучше включить в регресс, т.к. коммит с исправлением по нему или вообще часть НФ могут забыть добавить в релиз. Можно проверять НФ и в середине спринта, а потом его сломают при починке бага где-то еще.
Проверку НФ лучше включить не в регресс, а в предрелизное тестирование. А перед этим не забыть выполнить цикл проверки сразу после разработки.
Регресс - это проверка состояния старого функционала, который уже был в предыдущем релизе.
А чтобы коммит с исправлением НФ не забыли добавить в релиз, нужно не забыть, что жизненный цикл бага завершается не тогда, когда на рабочей станции у разработчика всё работает, а когда баг верифицировали на выпущенной версии продукта.
И что предрелизная стадия тестирования НФ включает в себя верификацию найденных багов.
Все подводные камни, описанные вами, легко обойти зная жизенный цикл разработки продукта. Ощущение, что вы сами старательно раскладываете грабли из-за плохого знания жизненного цикла, а потом героически терпите боль от собранных граблей.
Пример с забытым коммитом как бы намекает на бардак в тестировании и разработке.
Замечание справедливо, если не успевать тестировать НФ до регресса. Обычно оно у нас все-таки протестировано и описано в новых тестах до начала выпуска нового регресса.
Я не совсем понимаю. Вам нравится дублировать работу?
Если вы уже протестировали НФ до начала регресса, то зачем вам повторно заниматься тестированием НФ во время регресса?
Для того, чтобы часть тестов НФ стала регрессом, вы сначала должны выпустить текущий релиз и перейти к следующему циклу разработки НФ. Пока вы текущий релиз не выпустили, НФ текущего релиза отдельно, регресс отдельно. НФ тестируется в первую очередь, и лишь потом приступают к регрессу.
пока у вас нет этой четкой картинки предрелизного тестирования, есть вероятность того, что вы блокирующий баг в НФ найдете после регресса. Т.е. весь регресс проделаете зря.
Конечно, есть лайфхаки типа "баг затрагивает только вот этот кусочек функционала, поэтому переделывать регресс будем только для этого маленького кусочка продукта". Но даже с этим лайфхаком вы все равно будете переделывать то, что можно было не переделывать.
То, что вам редко дают время на второй цикл регресса - не означает, что нет смысла во втором цикле. И может быть имеет смысл выпускать релиз со списком известных багов вместо того, чтобы исправлять баги без надлежащей проверки продукта после исправлений.
Как по мне - тут вводит в заблуждение всё. И нумерация частей (которая может подразумевать порядок выполнения). И то, что вы "тестирование НФ" считаете подмножеством тестов регресса.
С моей точки зрения тестирование НФ можно считать частью предрелизного тестирования. И если говорить про предрелизное тестирование, то тогда можно будет формулировать так:
Тестирование релиза перед выпуском можно делить на две части
Тестирование НФ
Регресс
И выполнять последовательно именно в перечисленном порядке. Потому что как только вы при тестировании НФ нашли ошибку, требующую исправления, так сразу после исправления ошибки у вас новая версия продукта. И для новой версии продукта тоже надо будет выполнить регресс. Поэтому тестирование НФ (вместе с починкой найденных багов и верификацией) выполняют до регресса.
Кроме того, сам регресс может найти блокирующие выпуск релиза ошибки. И тогда придется повторять цикл регресса. По опыту редко удается обойтись одним циклом.
Про количество тестов в ядре регресса можно говорить долго. Обычно это считается по другим метрикам (где-то тут для сокращения количества тестов на регресс надо будет применять техники тест-дизайна). Хотя при расчете учитывается в том числе и доступные ресурсы.
На хабре вроде популярны статьи про борьбу с прокрастинацией.
И эти статьи прекрасно иллюстрируют, почему одни ждут (прокрастинируют), а другие достигают результатов.
Потому что ждущим, например, нужны гарантии успеха. И тут можно писать целый цикл статей как перестать ждать этих гарантий, брать на себя ответственность и начать действовать без таких гарантий.
Итого: для меня это хороший пример из жизни для того, чтобы увидеть разницу между ждущим и действующим. Так что для меня эта статья несет смысл и связана с темой ИТ.
P.S. Для меня интересно наблюдать отношение тру-айтишников к данным статьям. Типа заранее понятно, что там нет успеха. И я вспоминаю историю про создание синего светодиода https://youtu.be/gF1pHmqM1QU И мне кажется, что на примерах из этих статей тру-айтишникам есть чему поучиться.
Эта статья и комментарии под ней лично для меня демонстрируют вот что:
Пока одни ждут идеальных условий для того, чтобы начать действовать (т.е. ждут пока другие делом докажут, что когтеточки - это выгодно), другие просто действуют (т.е. начинают заниматься любым делом, в том числе когтеточками).
Да, у этих других нет гарантий окупаемости. Но пока первые ждут, вторые просто делают. И благодаря этим другим у нас есть то клубника, то пельмени, то телефоны есть куда отнести в ремонт.
И для меня это важно. Важно уметь приступать к действиям когда нет гарантий успеха. Когда ты не успел всё просчитать или нет всех знаний.
Пока одни занимаются теорией, другие достигают практического результата.
Имхо Маск придерживается такой же идеологии. Пока другие ждали, он создал теслу и спейс-икс.
Лысая голова хуже охлаждается, чем волосатая. На лысой голове испарение идет только с поверхности кожи головы, а на волосатой - ещё и с мокрых волос.
Именно поэтому на подмышках растут волосы. Которые ради эстетики и борьбы с запахом тщательно сбривают и усложняют организму задачу по нормальному охлаждению.
Так что бонус к рабочему состоянию у волосатых инженеров.
У человека была проблема с учетной записью, которую он решил через переписку с техподдержкой.
После этого в учетке появилось его имя (которое он без задней мысли использовал в переписке с техподдержкой). Т.е. его учетку "обогатили" без его согласия.
Я если честно так до конца и не понимаю механизм этого гелиевого исхода, он как-то самопроизвольно должен диффузировать из области пониженного давления в область повышенного?
Механизм примерно такой же, как шаров, наполненных гелием. Если взять два обычных резиновых шара и один надуть воздухом, а другой - гелием, то через некоторое время будет видно, что шар с гелием сдувается быстрее. Это происходит за счет того, молекула гелия намного меньше молекулы воздуха, и просачивается там, где воздух физически не проходит. Водород утекает примерно по тому же механизму.
Итого даже если давление самого гелия внутри диска не превышает атмосферное, гелий утекает за счет диффузии в местах уплотнений.
Почему утекает: снаружи диска давление гелия 0, а внутри диска больше нуля. Давление других газов не учитываю, т.к. размеры молекул других газов такие ,что им физически труднее пройти там, где может пройти молекула гелия. И получается, что с одной стороны уплотнения гелий давит, а с другой стороны уплотнения у него нет препятствий для выхода. И гелий просачивается.
Это примерно как одна и та же емкость может иметь достаточную герметичность, чтобы удерживать песок, но не удерживать воду.
Вы в лингвалео работаете? Поэтому вы полтора года ничего не писали, а теперь у вас бомбануло и вы решили посарказмировать?
У меня были свои причины для такого поведения. Хотел сначала статью запилить на тему джедайских техник, но всё никак не соберусь.
В лингвалео не работаю, а комментарий решил написать, т.к. тема упомянутой вами статьи перекликается с одним из вопросов, которые я хотел раскрыть в своей статье.
Сарказма не было. Извините за некорректную постановку вопроса про ваш план. Его можно было задать иначе. Или вообще не задавать.
Может быть, это одна из причин того, что статья до сих пор не написана. Боюсь быть непонятым и отмененным из-за непонимания.
С чего вы это взяли? С языком всё хорошо, я бросил приложение с раздражающей геймификацией, а не изучение языка.
В вашем комментарии выше нет никакой информации о том, что вы продолжили изучать язык с помощью других инструментов. И я решил уточнить. Потому что ваш поступок на первый взгляд не укладывался в рамки статьи о дисциплине. Логичным было бы продолжить изучение языка несмотря на геймификацию, ибо дисциплина превыше всего.
Я рад, что вы продолжили изучать язык. И у вас было достаточно гибкости, чтобы в каком-то смысле нарушить дисциплину и попрощаться с предоплатой за неподходящий для вас инструмент.
Печально, что вы не видите разницы между решительным (антоним - безвольный) и властным (антоним - не желающий демонстрировать свою власть) человеком.
Коммерческой компании как раз нужен твердый и решительный человек, умеющий задать четкие границы и четкие правила. По четким правилам комфортно работать. Четкие границы легко соблюдать.
Это определение (с моей точки зрения), хорошо характеризует властного человека и недалекого человека. Но никак не решительного и твердного.
А за премией в лимон баксов он обращался? :)
А если серьезно, то что в такой жизни плохого? Знакомому явно хватает на все его хотелки. Возможно, что он отлично умеет признавать свои ошибки (не отказывается от переезда в Австралию из-за ипотеки, не добивает коленку катанием только из-за наличия комплекта сноуборда хай-класса, не живет с нелюбимой женой ради ребенка).
Вот если бы он раза 3 подряд женился/стал отцом в браке/развелся - можно было бы задуматься о наличии системной ошибки.
Я знаю, что серийное производство и разработка - это разные процессы.
Для меня суть в том, что на серийном производстве заранее известен конечный результат и набор деталей, который нужен для производства. Кроме того, заранее зафиксирован процесс достижения результата: в каком порядке соединять детали, чтобы это занимало меньше времени.
А в разработке может оказаться, что через спринт вы узнали такие детали, из-за которых ваше представление о конечном результате (или о процессе достижения результата) коренным образом изменилось. И тут без гибкости никак.
Суть процесса другая, потому что по сути в разработке вы создаете прототип (или концепт) автомобиля. А потом копипаста сильно облегчает серийное производство.
Поэтому для серийного производства важен налаженый (работающий) конвейр, а для разработки - налаженый процесс Agile.
Только я не понял, что вы хотели сказать.
И за что мне слили карму, кстати, тоже не понял. Но слили явно после того, как я отметился в комментариях под этой статьей.
Простите, что? Я никак не могу вас понять, т.к. вы каждый раз говорите о разном.
Смотрим заголовок
Т.е. заголовок звучит так: Если ты пришел к команде со своими требованиями к продукту, то Agile невозможен.
Но это не так. Контрпример: Аналитик может формулировать прекрасные требования. И дальше команда может реализовывать эти требования по спринтам максимально быстро. И это будет Agile.
Ваш специфичный пример из статьи говорит только о том, что хорошая команда при хреновом аналитике может за счет принципов Agile оперативно выяснить всю хреновость требований. А если требования сформулированы хорошо - как это искоренит Agile?
Дальше вы пишете про согласование (не про формулировку!):
Это неверно, т.к. выше я уже привел контрпример с нормальным аналитиком и нормальными требованиями.
Дальше в комментарии вы пишете
Это совсем другая ситуация. Когда на одном планировании распланировали сразу несколько спринтов. 2-6 или больше. И отказываются заниматься перепланированием после завершения первого спринта. Тут я с вами соглашусь, что это не Agile, а имитация. Так как нет гибкости в планировании. Но это совсем о другом. Не то, что вы писали в заголовке. К сформулированным (и согласованным!) требованиям отношения не имеет. И вот здесь я начинаю подзревать, что вы натягиваете сову на глобус.
А вот это совсем из другой оперы:
Даже если команде не дают предлагать изменения в функционале - это не искоренит Agile, т.к. не является необходимым условием Agile. Внесение изменений со стороны команды может быть приятным бонусом, когда команда достигла нужного уровня зрелости.
Детализировать можно после того, как требования согласованы. С моей точки зрения вы опять говорите не о том, что у вас сформулировано в заголовке и в статье. Детализировать и согласовывать - это совершенно разные процессы.
Поэтому у меня и возник вопрос: что это за магия?
Можете еще раз сформулировать с примером, что вы хотели сказать статьей?
Побуду занудой: в таком процессе предлагаемое вами изменение не изменит сути процесса разработки. Как процесс не был Agile-ом, так он им и не станет.
Agile - это не про поиск самого дешевого решения. Он больше про гибкость (менять продукт в соответствии с новыми требованиями) и возможность добавлять функционал небольшими порциями.
Есть ощущение, что вы по одному случаю (который специфичен для вашей схемы работы, и вам встречается довольно часто), пытаетесь натянуть сову на глобус.
У меня другая точка зрения. Agile - это тот процесс, без которого эффективная разработка невозможна в принципе.
Как без налаженного конвейра сложно собирать автомобили, так без налаженного Agile сложно пилить задачки.
Я бы даже сказал, что вся наша жизнь - Agile. Только в сфере личных проектов, которая гораздо шире сферы разработки ПО.
А можете объяснить почему?
Выглядит как карго-культ: "Чтобы был Agile, необходимо ознакомить команду разработки с требованиями до согласования требований. И тогда фичу получиться реализовать за один спринт, а не за 4 (или даже больше, если считать стабилизацию и тестирование)."
Что это за магия такая?
Предположу, что потребителя услуги "аренда самоката", наказывать будут не за нарушение ПДД. А за то, что во время аренды самоката он допустил административное правонарушение.
Поясню на примере, почему это разные вещи: Если турист совершает административку в чужой стране, то в следующий раз его легко могут развернуть при въезде в эту страну. Потому что не нужны закононепослушные туристы. Чтобы не мешали законопослушным туристам отдыхать.
И это не повторное наказание за одно и то же.
Значит вы находитесь в категории недоверчивых попаданцев :) И этот комментарий не про вас
Проверку НФ лучше включить не в регресс, а в предрелизное тестирование. А перед этим не забыть выполнить цикл проверки сразу после разработки.
Регресс - это проверка состояния старого функционала, который уже был в предыдущем релизе.
А чтобы коммит с исправлением НФ не забыли добавить в релиз, нужно не забыть, что жизненный цикл бага завершается не тогда, когда на рабочей станции у разработчика всё работает, а когда баг верифицировали на выпущенной версии продукта.
И что предрелизная стадия тестирования НФ включает в себя верификацию найденных багов.
Все подводные камни, описанные вами, легко обойти зная жизенный цикл разработки продукта. Ощущение, что вы сами старательно раскладываете грабли из-за плохого знания жизненного цикла, а потом героически терпите боль от собранных граблей.
Пример с забытым коммитом как бы намекает на бардак в тестировании и разработке.
Я не совсем понимаю. Вам нравится дублировать работу?
Если вы уже протестировали НФ до начала регресса, то зачем вам повторно заниматься тестированием НФ во время регресса?
Для того, чтобы часть тестов НФ стала регрессом, вы сначала должны выпустить текущий релиз и перейти к следующему циклу разработки НФ. Пока вы текущий релиз не выпустили, НФ текущего релиза отдельно, регресс отдельно. НФ тестируется в первую очередь, и лишь потом приступают к регрессу.
пока у вас нет этой четкой картинки предрелизного тестирования, есть вероятность того, что вы блокирующий баг в НФ найдете после регресса. Т.е. весь регресс проделаете зря.
Конечно, есть лайфхаки типа "баг затрагивает только вот этот кусочек функционала, поэтому переделывать регресс будем только для этого маленького кусочка продукта". Но даже с этим лайфхаком вы все равно будете переделывать то, что можно было не переделывать.
То, что вам редко дают время на второй цикл регресса - не означает, что нет смысла во втором цикле. И может быть имеет смысл выпускать релиз со списком известных багов вместо того, чтобы исправлять баги без надлежащей проверки продукта после исправлений.
Как по мне - тут вводит в заблуждение всё. И нумерация частей (которая может подразумевать порядок выполнения). И то, что вы "тестирование НФ" считаете подмножеством тестов регресса.
С моей точки зрения тестирование НФ можно считать частью предрелизного тестирования. И если говорить про предрелизное тестирование, то тогда можно будет формулировать так:
Тестирование релиза перед выпуском можно делить на две части
Тестирование НФ
Регресс
И выполнять последовательно именно в перечисленном порядке. Потому что как только вы при тестировании НФ нашли ошибку, требующую исправления, так сразу после исправления ошибки у вас новая версия продукта. И для новой версии продукта тоже надо будет выполнить регресс. Поэтому тестирование НФ (вместе с починкой найденных багов и верификацией) выполняют до регресса.
Кроме того, сам регресс может найти блокирующие выпуск релиза ошибки. И тогда придется повторять цикл регресса. По опыту редко удается обойтись одним циклом.
Про количество тестов в ядре регресса можно говорить долго. Обычно это считается по другим метрикам (где-то тут для сокращения количества тестов на регресс надо будет применять техники тест-дизайна). Хотя при расчете учитывается в том числе и доступные ресурсы.
На хабре вроде популярны статьи про борьбу с прокрастинацией.
И эти статьи прекрасно иллюстрируют, почему одни ждут (прокрастинируют), а другие достигают результатов.
Потому что ждущим, например, нужны гарантии успеха. И тут можно писать целый цикл статей как перестать ждать этих гарантий, брать на себя ответственность и начать действовать без таких гарантий.
Итого: для меня это хороший пример из жизни для того, чтобы увидеть разницу между ждущим и действующим. Так что для меня эта статья несет смысл и связана с темой ИТ.
P.S. Для меня интересно наблюдать отношение тру-айтишников к данным статьям. Типа заранее понятно, что там нет успеха. И я вспоминаю историю про создание синего светодиода https://youtu.be/gF1pHmqM1QU И мне кажется, что на примерах из этих статей тру-айтишникам есть чему поучиться.
Эта статья и комментарии под ней лично для меня демонстрируют вот что:
Пока одни ждут идеальных условий для того, чтобы начать действовать (т.е. ждут пока другие делом докажут, что когтеточки - это выгодно), другие просто действуют (т.е. начинают заниматься любым делом, в том числе когтеточками).
Да, у этих других нет гарантий окупаемости. Но пока первые ждут, вторые просто делают. И благодаря этим другим у нас есть то клубника, то пельмени, то телефоны есть куда отнести в ремонт.
И для меня это важно. Важно уметь приступать к действиям когда нет гарантий успеха. Когда ты не успел всё просчитать или нет всех знаний.
Пока одни занимаются теорией, другие достигают практического результата.
Имхо Маск придерживается такой же идеологии. Пока другие ждали, он создал теслу и спейс-икс.
Лысая голова хуже охлаждается, чем волосатая. На лысой голове испарение идет только с поверхности кожи головы, а на волосатой - ещё и с мокрых волос.
Именно поэтому на подмышках растут волосы. Которые ради эстетики и борьбы с запахом тщательно сбривают и усложняют организму задачу по нормальному охлаждению.
Так что бонус к рабочему состоянию у волосатых инженеров.
Хорды? Мой внутренний математик негодует.
Вы же хотели сказать 4 сегмента?
P.S. Пойду форточку открою.
У человека была проблема с учетной записью, которую он решил через переписку с техподдержкой.
После этого в учетке появилось его имя (которое он без задней мысли использовал в переписке с техподдержкой). Т.е. его учетку "обогатили" без его согласия.
И с этим вопросом он вышел в публичное поле.
Механизм примерно такой же, как шаров, наполненных гелием. Если взять два обычных резиновых шара и один надуть воздухом, а другой - гелием, то через некоторое время будет видно, что шар с гелием сдувается быстрее. Это происходит за счет того, молекула гелия намного меньше молекулы воздуха, и просачивается там, где воздух физически не проходит. Водород утекает примерно по тому же механизму.
Итого даже если давление самого гелия внутри диска не превышает атмосферное, гелий утекает за счет диффузии в местах уплотнений.
Почему утекает: снаружи диска давление гелия 0, а внутри диска больше нуля. Давление других газов не учитываю, т.к. размеры молекул других газов такие ,что им физически труднее пройти там, где может пройти молекула гелия. И получается, что с одной стороны уплотнения гелий давит, а с другой стороны уплотнения у него нет препятствий для выхода. И гелий просачивается.
Это примерно как одна и та же емкость может иметь достаточную герметичность, чтобы удерживать песок, но не удерживать воду.
У меня были свои причины для такого поведения. Хотел сначала статью запилить на тему джедайских техник, но всё никак не соберусь.
В лингвалео не работаю, а комментарий решил написать, т.к. тема упомянутой вами статьи перекликается с одним из вопросов, которые я хотел раскрыть в своей статье.
Сарказма не было. Извините за некорректную постановку вопроса про ваш план. Его можно было задать иначе. Или вообще не задавать.
Может быть, это одна из причин того, что статья до сих пор не написана. Боюсь быть непонятым и отмененным из-за непонимания.
В вашем комментарии выше нет никакой информации о том, что вы продолжили изучать язык с помощью других инструментов. И я решил уточнить. Потому что ваш поступок на первый взгляд не укладывался в рамки статьи о дисциплине. Логичным было бы продолжить изучение языка несмотря на геймификацию, ибо дисциплина превыше всего.
Я рад, что вы продолжили изучать язык. И у вас было достаточно гибкости, чтобы в каком-то смысле нарушить дисциплину и попрощаться с предоплатой за неподходящий для вас инструмент.