Много вы знаете приложений/диалогов в Win или Lin которые по кнопке/команде "Закрыть" не закрываются
Да полно. Заходите на любой сомнительный сайт, и вас ими завалит.
"Но это же сайты! А я вам про систему!", – можете восликнуть Вы. Но в этом случае Вы просто не понимаете, как работает реклама, и откуда берутся все эти назойливые рекламные попапы в приложениях. А берутся они (за исключением собственных промо-попапов приложения) из какого-нибудь рекламного SDK. Никто не пишет показ interstitial (полнорекламной) рекламы. И даже баннеры никто сам не пишет. Все берут какой-нибудь рекламный SDK (или несколько), интегрируют его в приложение, подрубают callback-и, где нужно, чтобы, например, рекламный SDK знал, от имени какого окна показать полноэкранное окно. Но само окно, за исключением использования так называемой нативной рекламы, "приходит" из SDK. А поэтому, как я сказал выше, Ваша стройная схема не будет работать. Потому что ушлые люди, которые хотят показать Вам гору плохой рекламы, просто подключат SDK, который позволяет это сделать. А уже в SDK это будет один раз реализовано так, чтобы кнопка не работала. Только и всего.
Попробуйте в AppStor "протащить" собственное приложение не использующее "только дозволенные OS объекты/элементы с определенным дизайном"
Видите ли, я – iOS-разработчик с бэкграундом в разработке рекламных SDK :) Так что я прекрасно представляю, как бы я "это" сделал, как со стороны приложения, так и со стороны рекламного SDK, если бы я задался такой целью. Вот возьмём, например, iOS. Что должна делать Ваша волшебная кнопка? Возьмём, допустим, UIKit. Есть два стандартных способа установить иерархию между "экранами" (ViewController-ами, хотя, в общем случае, один ViewController != один экран): push-переход и модальный переход. Табы я не рассматриваю сейчас. В случае push-перехода у нас есть стек экранов. В случае модального перехода показываемый экран показывается поверх родительского. Соответственно, например, полноэкранная реклама показывается обычно как модальное окно. Допустим, мы делаем так, чтобы наша супер-кнопка закрывала текущее презентуемое окно. Сходу (что-нибудь из этого может не сработать, если углубиться, но суть понятна):
Как создатель рекламного SDK, я могу показывать прозрачное окно с единственным viewController-ом поверх моей полноэкранной рекламы, так что кнопка будет закрывать это окно. А я тут же буду переоткрывать его без анимации.
Я переделаю интеграцию таким образом, что полноэкранная реклама будет встраиваться непосредственно в иерархию view существующего экрана. Опять же, сходу вижу несколько способов это сделать. Они потребуют кооперации от автора приложения, но, будучи таким же недобросовестным автором, как и я, он в этом заинтересован. Так кнопка будет работать, но будет закрывать и тот контент, с которым Вы работали. Вам придётся посмотреть рекламу, чтобы вернуться к тому, что Вы делали.
Я могу сделать push-переход вместо модального. Вы можете сказать, что пусть кнопка и push-переходы отменяет! Но это, во-первых, поломает логику некоторых приложений, если мы не даём приложению возможность отключить обработку супер-кнопки для определённых экранов. А если даём – то можно прописать рекламу в исключения, да и всё.
А теперь финт ушами – я реализую свой собственный ContainerViewController. Не push, не модальный показ. Что система с ним должна делать? Система не знает, он кастомный. И это не какая-то "чёрная магия", это всё официальный API, которым люди пользуются по вполне легитимным причинам.
Да я могу банально отслеживать сворачивание рекламы по "мега-кнопке", и тут же открывать снова. Нажимайте :)
И это мы ещё не говорим про баннерную рекламу. Она бывает довольно большой. Но баннерная реклама интегрирована в иерархию view приложения. Система просто не знает, какому view послать запрос на закрытие. Но, допустим, Apple / Google, как часть API для этой кнопки, заставляют маркировать рекламные вьюшки. Я просто промаркирую пустую вьюшку, показываемую поверх рекламы, вот и всё. Ну и, также, как и выше, есть миллион способов сделать это как-нибудь ещё.
Вы можете сказать: "Но у Apple есть ревью! Вы не пройдёте ревью!". На что я отвечу: пройдём :) Как, думаете, куча шлака пробивается через ревью? Просто на время ревью рекламный SDK будет вести себя "прилично". В конечном итоге мы огребём от Apple проблем, наверное, но это не точно :) А от Google вот даже не знаю, огребём ли. Может и вообще прокатит.
А, а ещё помните, как я говорил, что авторы рекламных SDK (как минимум, некоторых) активно борются против "плохой" рекламы? Так вот. Представьте себе "хорошего" разработчика приложений. Этот разработчик берёт "хороший" SDK, поддерживающий кнопку и т.д. Так вот. Как думаете, с кем борются авторы SDK? С авторами непосредственно рекламы, конечно! Баннерная реклама в приложениях показывается просто браузером. Video interstitial-ы – каким-нибудь видео-плеером с доп. обвязкой для обработки рекламных событий и действий. Интерактивная полноэкранная реклама, если мне память не изменияет – тоже просто браузер с веб-страницей. А там JavaScript. И этот JavaScript может творить всякое. Так что даже в "хороших", "порядочных" приложениях "плохая" реклама всё равно иногда да пробивается.
Так что идея-то хорошая. Но реализации не предвидится. Это даже если забыть, откуда Google получает огромный кусок своих доходов.
Оригинальные Герои, несмотря на эклектику стилей и мифологий, смотрелись довольно цельно. ХотА для меня лично такой цельной не выглядит.
Наверное, я слишком хорошо знаю историю, поэтому меня появление уже пиратов уровня века этак, 17го, когда в Замке войска примерно на уровне 14 века, смотрелось крайне дико. Теперь, с появлением стрелков в виде ганфайтеров 19 века, этот разрыв ещё сильнее увеличился.
Если у вас уже такая мощь огнестрельного оружия, которая делает бессмысленными доспехи, тогда почему войска в людском Замке до сих пор в доспехах, а их кузница производит какие-то убогие баллисты?
Второй аспект: я пробовал играть в 1.5.4 на случайных картах. Понял, что не зря Хоту злые языки называют "Герои цехов и зефирок". Привычных объектов на карте стало гораздо меньше, они вытеснены новыми. Ожидал ли я такого от дополнения к игре, как позиционируют Хоту сами разработчики? Нет. По-моему, ещё Сид Мейер вывел эмпирическое правило: в новой части 1/3 элементов геймплея оставить старыми, 1/3 поменять, 1/3 добавить новых. Тут это правило нарушается.
Третий аспект: геймплей.
Все недостатки оригинального геймплея были в ХотА бережно сохранены:
Дисбаланс героев, где толковых где-то около 15% в лучшем случае.
Дисбаланс навыков
Дисбаланс системы магии
В 95% сражениях стрелки + масс. замедление = победа. Активное использование автоматических битв только доказывает, что все эти сражения не нужны, никакого напряжения межушной мышцы игрока не требуется.
Способы исправления дисбаланса навыков (порезка некромантии и дипломатии, замена сопротивлени) в ХотА мне не нравятся. Всё равно считаю, что мои варианты гораздо лучше.
При этом в разных других модах почти все перечисленные недостатки были исправлены, поэтому возвращаться к старому геймплею особого желания нет.
Я работал в ВК с 2011 по 2016. Всё начало ощутимо лететь на дно примерно через год после ухода Дурова. Было очень серьёзное изменение внутренней культуры. Появился аж целый HR-отдел. Начали набирать пачками сотрудников, которые не особенно отличались компетенцией. Начали вводить иерархии. Появились эти менеджеры никчёмные, которые активно мешали мне работать. Продуктовые решения начали приниматься без участия разработчиков — задачи просто сваливались с неба и обсуждению не подлежали. Появился весь этот бизнес и собственные цели компании, которые шли вразрез с потребностями пользователей. Все эти Сергеевы и Добродеевы, да, которые интересовались только деньгами, на продукт им было насрать, в зингере их никто никогда не видел, и уж тем более с разработчиками они не общались. Для меня это всё было дикостью уже тогда. Потому и уволился. Это было сложным решением, но под конец работа в ВК для меня походила на какие-то абьюзивные отношения.
То, что происходит сейчас — всего лишь дальнейшее развитие этих проблем, имхо. Почти все мои бывшие коллеги из-за всего этого тоже уволились рано или поздно. У нас есть аж целый чат бывших сотрудников.
Хе-хе, ставишь цели - выполняешь это хороший подход. Прозрачный. Есть у нас в одной e-commerce бигтех компании более весёлый вариант ревью - без четких целей и критериев оценки, еще и в формате олимпиады: всех сравнивают со всеми (разработчиков с qa и системными аналитиками) кто больше для компании принес ценности, еще и в разных грейдах. И оценивают консилиумом руководителей по N задачам котрые сами сотрудники вписывают как самые значимые за пол года. Получается плоский список отсортированных по полезности людей, на который накладывается распределение оценок - хороших столько то % , плохих %
В итоге если задачи сотрудника на взгляд руководителей менее полезные чем у других но работал он хорошо - у него высокий риск попасть в распределение так себе оценки, не получить премию, или повышение. А при совсем плохой - вообще быть уволенным.
Ну это же база - ставят ОКР/perf review на работе - значит, будут на это смотреть при повышении зп/должности. А значит, нужно выдумывать такие цели, которые ты 100% выполнишь, если даже половину года проспишь. В идеале - выполненные уже сейчас.
А работать ли на цели бизнеса или на личные - очевидно на те, за которые дадут больше денег.
Не знаю, имел ли автор в виду ВК или VK (ex. mail.ru), но в ВК система ревью существовала как минимум с 2015 года, и после ~2020 года она была сравнительно доведена до ума.
Процесс согласования целей (обычно - оконченных проектов) проводился адекватно и согласовывался с руководителем. Можно было оспорить, подтюнить договорённости, согласовать иной DOD. На амбиции не дрочили, так как должна быть и оценка "соответствует ожиданиям", и "выше ожиданий" - как раз для амбициозных чуваков.
Также в системе был учёт влетающих adhoc-проектов, которыми можно было вытеснить любой из ранее согласованных эпиков. Понятно же, что ты пользу бизнесу приносил по запросу самого бизнеса, и странно тебя за это штрафовать при невыполненном другом эпике.
Периоды оценивания короткие, поэтому ты не терял фокус, не забывал о договорённостях, было всё честно и сравнительно справедливо.
То, что описывает автор, для меня похоже скорее на лень со стороны руководителя автора, который скипнул этап формирования ожиданий в эпиках, переложил ответственность на сотрудника, ведением сотрудника не занимался, а сотрудник не придал этому важности. Теперь автор вместе с руководителем будет разгребать сложившуюся ситуацию.
А ещё ситуация не то что бы из ряда вон выходящая, и считаю, что автор на обозрение вынес сор из избы. Не знаю, как к этому относиться, но внутренние правила компании предписывали такое сначала с hr-bp разобрать.
В нашей конторе похожий подход, хотя мы эксплуатация, не разработка. Начальство: "вот вам новые показатели, эти цифры обязательны". Сотрудники: "это нереальные цифры, выбранная метода оценки построена неправильно". Начальство: "мы знаем, вот вам инструкция как на%бать систему, если не получается, вот секретная инструкция, как это сделать точно". Спецы-мотиваторы, блин. Я уже открытым текстом говорю, засуньте эти цифры в опу, уволят так уволят.
Абсолютно абстрактная и непроверяемая цель - как я и хотел, а вы нет)
менторство одному/ двум джунам
Тоже мало проверяемая цель, чисто на уровне - ну ты помогал? - помогал еще как!
Главная проблема тут в этом:
Тогда можно будет говорить об амбициозности взятых обязательств и при этом хоть как-то легитимно двигаться к ним
Вот, в этом вся и проблема! В программировании все очень шатко, зыбко и неопределённо как в сложной творчески-исследовательски-технической деятельности. Поэтому сама идея брать на себя какие-то обязательства на год вперед - это полнейший, шизофренический бред. Написать больше строчек кода или больше классов/методов на 20%? Закрыть больше жир на 15%? Ускорить работу моего модуля в 3 раза? Выучить питон в 1.5 раза глубже? Всё это примеры бреда бредового. В таких сложных, часто меняющихся и не очень предсказуемых сферах деятельности работают только экспертные оценки.
ох... 10 лет назад занимался подобным (и даже вещами на пару порядков продвинутее, но все равно очень рад, что это в прошлом)
во-первых, что мой личный вывод, что серьезных алготрейдеров с командами разрабов, что стратегии на основе анализа одного числового ряда, мягко говоря, хрень полная. Могут еще как-то работать либо вещи, основанные на микроструктуре рынка (стакан, HFT, код на FPGA), на предоставлении ликвидности, на технологическом превосходстве, на анализе дополнительной информации (новости читать нейросетью), но вот эта магия на свечах сделала богатыми только продавцов лопат. К слову, продавцы лопат неплохо постарались, - сейчас куча библиотек (в том числе, бесплатных), которые любой индикатор вроде MACD или линий Боллинжера рассчитают из коробки без необходимости программировать их с 0 через pandas и numpy
во-вторых, если уж так хочется в этом участвовать, то инструменты давно придуманы и запрограммированы. 10 лет назад была удивительная прожка Amibroker, имеющая свой векторный язык, интерпретирующийся написанным на С++ движком, что давало поистине реактивную скорость. И там были из коробки реализованы очень неплохие алгоритмы оптимизации, позволяющие реально сократить время оптимизации на порядки без потери точности, например, CMA-ES. Конкретно он настолько хорошо работал, что я потом кажется, запрограммировал его сам на C#, чтобы в свой самопичный бектестер залить.
ну и, последнее, - оптимизировать по профиту, не имея защиты от дурака в виде статистических тестов стат значимости гипотез - очень плохая идея. Втупую оптимизировать по профиту можно, разве что, HFT с 10000+ сделок за один прогон бектеста. Во всех остальных случаях это будет просто подгонка под историю. Недаром люди придумали всякие штуки вроде Sharpe ratio. Скачайте тот же Amibroker ради любопытства, посмотрите, какие там, помимо профита, цели оптимизации из коробки дает выбрать, почитайте их формулы на википедии, задайтесь вопросом, а зачем это придумано?
Так у нас это уже сделано. Просто писать такое было бы голимой рекламой. Но раз уж ты спросил, то встречай Axiom Native Image Kit. Это downstream distribution для GraalVM Community Edition с поддержкой команды Axiom JDK.
Видимо через пару лет и до использования контейнеров дело дойдёт. К сожалению, не очень понятно, для чего была проведена миграция, и были ли достигнуты её цели.
Проблема в том, что можно делать коммиты под чужим именем. Вы делаете коммит от кого-то знакомого мейнтейнеру проекта, надеясь что он не будет внимательно все проверять и смержит. Можно использовать подпись, но все ли так делают?
Потому что НЕ ЧИТАЮТ. Даже в условиях, когда это напрямую влияет на размер получаемой зарплаты.
И не будут. Никогда. Как человек, в свое время обучивший более 500 сотрудников работе за компьютером и конкретно в 1С:Розница, и день за днем повторявший им по телефону одни и те же инструкции, зачитываемые по бумажке, которую сам и писал аж в четырех вариантах, могу объяснить, почему. Все эти ваши "симпрактические" и "теоретические" мышления, как и прочие сравнительные конструкты, ни при чем.
Дано: крупная сеть по продаже преимущественно печатной продукции в киосках в одном крупном городе и близлежащей области. Количество точек: около 300 (на момент моего ухода оттуда отсалось почти вдвое меньше - данная часть торговли умирает под гнетом разных факторов). Контингент обучаемых: женщины возраста от 30 до бесконечности, большинство пенсионеры. Уровень знаний: есть бывшие бухгалтеры, есть те, кто компьютер видит впервые в жизни за свои 40 с лишним лет - нет, это не шутка, я сам с трудом в это поверил, и тем сильнее был мой шок от осознания той задницы, в которой я оказался в тот момент, ибо мне предстояло за несколько часов обучить человека уровня "ноль на уровне комплексного числа" до умения хотя бы тыкать в кнопки в 1С в нужной последовательности.
Требуется: обучить сотрудников работе в 1С:Розница на свежекупленных ноутах. Обучить на минимальном уровне "зайти в программу под собой, пробивать товары сканером штрихкода, фиксировать продажу, смотреть остаток товара в программе". Для продвинутых - проводить инвентаризацию по категориям, делать пересорты и так далее, как в любой торговой точке. Мной была написана инструкция. Детальная. Подробная. Талмуд на 16 страниц убористого текста А4. Я на тот момент еще был молод и зелен, да. Потом была написана еще одна - та же инструкция, но урезанная до уровня "1. Нажать кнопку А. 2. Ввести сумму в поле Б, нажимая кнопки с цифрами на ноутбуке, 3. Нажать кнопку В.". Менеджеры меня умоляли сделать инструкцию "с картинками", потому что "без картинок они не понимают", но я уже на тот момент на практике понял, что картинки/не картинки - значения не имеет абсолютно, так как проблемы лежат абсолютно в другой плоскости. Люди работают не деградировавшие ментально, чтобы им нужны были картинки, как маленьким детям. Была написана третья инструкция. Четвертая. Сложился определенный стиль общения, новая терминология, я уже по номеру торговой точки на экране телефона знал, что там за люди работают, и с чем они обратятся. Да, инструкции все еще не читали, даже спустя месяцы и годы. Только если придешь, встанешь рядом и скажешь "берите, читайте вслух инструкцию и повторяйте за мной все действия". И вот почему.
Человек должен быть мотивирован исполнять инструкцию. Нет, не так. Нет, зарплата тут ни при чем. Опосредованно - да, она влияет, чтобы человек любил свою работу, он должен быть в том числе финансово мотивирован. Но часто, очень часто бывает так, что человек ненавидит свою работу и ходит на нее от безысходности. И можно повышать ему зарплату, можно пугать его штрафами, материальной ответственностью, применять кнут и пряник - ему плевать. Ему одинаково хреново во всех случаях на неблагодарной, изматывающей работе. И когда приходят с очередной инструкцией, которую надо делать, он просто не хочет это делать, потому что человеку все равно. И вы с этим не сделаете ничего. Поэтому лучше перефразирую - человек изначально должен любить свою работу, чтобы хотеть ее выполнять качественно. Есть еще один случай, который должен быть в списке под номером ноль - люди ленивы, хотят делать меньше, но получать за это больше, но он настолько очевиден, что я его пропущу. Хотя любовь к халяве часто настолько прет из всех щелей и о ней в открытую заявляют в лицо, что это перекрывает все остальное.
Человек любит свою работу. Человек хочет научиться, чтобы эту работу не потерять. Проблема номер два, самая главная, и самая большая - человек боится исполнять инструкцию. Да, именно так. Инструкция может быть сколь угодно примитивной и тупой, "интуитивно понятной", она бесполезна, если человек боится совершить ошибку. Я приходил, вставал рядом с продавцом, говорил "открывайте при мне инструкцию, делаем по порядку, как написано". Удивительным образом, делали. Правильно. Аккуратно. Медленно, да, но делали. Я спрашивал, все ли понятно, есть ли что-то сложное. Ничего нет. Я уходил. Все повторялось. С надзором сверху, с контролем (я на телефоне, перед глазами экран ноута по VNC) все делается. Самостоятельно - нет. Страх вызывает ступор и даже самая простая инструкция перестает восприниматься. Страх вызывает все, вплоть до открытой агрессии - когда я развозил по тем же точкам онлайн-ККМ под 54-ФЗ, на меня орали отборным матом, запирали в киоске и угрожали, отказываясь даже слушать, что все, что им понадобится дополнительно делать - отрывать чек и менять рулон с лентой, больше в их работе не изменится ни единого момента.
Проблема номер три. Инструкция непонятна. Нет, рассуждения об "абстракциях" ни при чем. Абстрактное мышление у людей прекрасно работает, если его пнуть нужным образом (ага, "ёж птица гордая, пока не пнешь - не полетит"). Чтобы это сделать, нужно говорить на языке исполнителя. Забудьте слова "окно", "курсор", "поле ввода", "кнопка мыши", "отрицательный остаток". Люди не поймут, что такое "окно", даже если видят его на экране перед собой. Вы оперируете этими понятиями, потому что обучались им с нуля. Исполнитель ими не оперирует. Он их не знает. Если у вас дохренища времени, можете обучить исполнителя вашему языку и объяснить ему все это, но это долгий и тупиковый путь, который не ведет к выполнению текущей задачи. Переводите абстракции на язык, понятный исполнителю, которым он описывает свою обычную работу. "Таблица", "стрелочка", "мигающая черточка", "полоска сверху", "желтый кружок слева". Чукча из анекдота ваш лучший друг - "что вижу, о том пою". Это не деградация мышления, это описание тех же абстракций другим языком. Человек поймет, что скрывается за теми или другими визуальными элементами, если ему объяснить на том языке, на котором он вас понимает. Даже базовые бухгалтерские понятия - дебит, кредит, "минус на остатке", приход, расход - объяснить человеку очень легко. Когда я увольнялся, самой частой фразой от продавцов было "вы единственный, кто нас понимает, когда мы объясняем". Учите язык исполнителя. Его язык описывает среду, в которой он работает. Он не обязан учить ваш и постоянно заниматься переводом с "языка инструкции" на свой. Этот язык иностранный, даже если вам кажется, что это тот же русский язык.
Проблема номер четыре. Инструкция не должна быть алгоритмом. Точнее, должна, ибо описывает действия... но и не должна. Человек не машина, не автомат на заводе, выполняющий однообразные операции (хотя упомянутых сотрудников Амазона вынуждают превращаться в них). Человек выполняет много разных дел. Человеку важен контекст. Говорите с человеком. Инструкция должна описывать, что человек должен сделать, и что за этим стоит. Вы можете научить человека упомянутому выше "кнопка А, сумма Б, кнопка В". Шаг влево, шаг вправо - ступор. Это кстати и проблема, которой страдают все "курсы программирования" - они учат стандартным ситуациям, стандартным примерам... но они не учат программировать. На выходе с курсов мы моем получить человека, который вызубрил синтаксис SQL, но не имеет понятия о внутренней кухне реляционных БД. Я видел столько кода от подобных "программистов", где неиндексируемые выборки миллион на миллион записей уходят в прямое произведение в запросе... оптимизация? что это? индексы? какие индексы? какие предвыборки? какая сложность алгоритма? какой еще поиск в куче? Такой человек не знает, он умеет только выполнять операции. Объясняйте суть операций, объясняйте на человеческом языке, не на языке автомата. Я научился писать инструкции и информационные записки для продавцов очень просто. Я просто разговаривал с продавцом и записывал свои слова как есть. Поток сознания, который потом приводился в литературный вид. Как мне потом некоторые говорили "достаем из почты листок и сразу понимаем, что от вас, потому что написано точно как вы говорите". И людям было понятно. Главное - не растекаться мыслью по древу, читающий потеряет смысл предложения на второй его строчке. Кратко, но по сути.
Проблема номер пять. Инструкция должна быть нужна. Человек не будет тратить время на то, чем он не пользуется. Человек должен понимать, что он должен делать. Этот вопрос в большей степени организационный... но вот скажите, например, нужны ли стенды на стенах с описанием эвакуационных выходов на случай пожара? Конечно, нужны, скажете вы. А вот конкретно вы всегда ли идете в каждом здании к этому стенду и читаете его? Понятен ли он вам? Всегда ли прикидываете, где вы находитесь в здании и как отсюда выйти в случае чего? Если вдруг случится пожар, насколько этот стенд будет информативен для людей, бегущих в состоянии паники, в дыму, в нулевой видимости? Нельзя повесить стенд на стену и ждать, что он поможет спасти людей от пожара. Нельзя просто спустить инструкцию исполнителям и ожидать, что они будут ей пользоваться. Нужно показывать, для чего инструкция предназначена. Убедиться, что человек ознакомился с инструкцией и сможет ее применить. Убедиться, что человек обучен совершать действия, необходимые от него по инструкции.
Я выше упоминал, что мне приходилось обучать людей, которые видели компьютер впервые в жизни? Это было уже незадолго до моего увольнения, когда руководство распорядилось завершить автоматизацию для самых отдаленных точек, и мне пришлось ездить по селам за 120 километров от областного центра, и на тот момент все описанные выше шаги были пройдены. Так вот. От этих людей я не слышал впоследствии НИ ОДНОГО вопроса. Они обучились всему. Для них сошлись абсолютно все факторы, описанные выше. Они были мотивированы - им нечего терять и они работают в маленьком селе, где все друг друга знают, и работают друг для друга. Они не боялись сделать ошибку - я оставил им копию тестовой базы для самостоятельного обучения и сказал "творите с ней что хотите, вы здесь не испортите ничего" - было устранено самое большое препятствие. Инструкции для них были уже написаны на языке, понятном им. Даже "галопом по европам" я объяснял им не как надо тыкать кнопки, а как надо работать. Им было предельно очевидно, что я не приеду больше за 120 километров стоять рядом с ними, и что им надо учиться сейчас, как и мне было предельно очевидно, что мне надо донести до них все максимально понятным образом и предусмотреть для них все - что они смогут сходить к соседям посмотреть (взаимное обучение тоже очень важный момент), что они могут обратиться по телефону в крайнем случае, но я не буду висеть с ними на телефоне часами (проблема восприятия "вы наш персональный специалист, сделайте нам все красиво" - тоже большая проблема). Была одна бабушка из этой группы обучаемых, которая боялась всего как огня и едва ли не плакала, пытаясь научиться кликать мышкой - для нее мы придумывали все возможные упрощения действий, пытаясь избавить человека от этого страха, и это получилось.
Инструкции работают. Если ими уметь пользоваться. Это тоже искусство, и оно не зависит от всяких "типов мыслительной деятельности".
P.S. Что-то я почти на самостоятельный пост намалевал тут...
надо держать его как можно дальше от себя. хотя бы метров 30
Да полно. Заходите на любой сомнительный сайт, и вас ими завалит.
"Но это же сайты! А я вам про систему!", – можете восликнуть Вы. Но в этом случае Вы просто не понимаете, как работает реклама, и откуда берутся все эти назойливые рекламные попапы в приложениях. А берутся они (за исключением собственных промо-попапов приложения) из какого-нибудь рекламного SDK. Никто не пишет показ interstitial (полнорекламной) рекламы. И даже баннеры никто сам не пишет. Все берут какой-нибудь рекламный SDK (или несколько), интегрируют его в приложение, подрубают callback-и, где нужно, чтобы, например, рекламный SDK знал, от имени какого окна показать полноэкранное окно. Но само окно, за исключением использования так называемой нативной рекламы, "приходит" из SDK. А поэтому, как я сказал выше, Ваша стройная схема не будет работать. Потому что ушлые люди, которые хотят показать Вам гору плохой рекламы, просто подключат SDK, который позволяет это сделать. А уже в SDK это будет один раз реализовано так, чтобы кнопка не работала. Только и всего.
Видите ли, я – iOS-разработчик с бэкграундом в разработке рекламных SDK :) Так что я прекрасно представляю, как бы я "это" сделал, как со стороны приложения, так и со стороны рекламного SDK, если бы я задался такой целью. Вот возьмём, например, iOS. Что должна делать Ваша волшебная кнопка? Возьмём, допустим, UIKit. Есть два стандартных способа установить иерархию между "экранами" (ViewController-ами, хотя, в общем случае, один ViewController != один экран): push-переход и модальный переход. Табы я не рассматриваю сейчас. В случае push-перехода у нас есть стек экранов. В случае модального перехода показываемый экран показывается поверх родительского. Соответственно, например, полноэкранная реклама показывается обычно как модальное окно. Допустим, мы делаем так, чтобы наша супер-кнопка закрывала текущее презентуемое окно. Сходу (что-нибудь из этого может не сработать, если углубиться, но суть понятна):
Как создатель рекламного SDK, я могу показывать прозрачное окно с единственным viewController-ом поверх моей полноэкранной рекламы, так что кнопка будет закрывать это окно. А я тут же буду переоткрывать его без анимации.
Я переделаю интеграцию таким образом, что полноэкранная реклама будет встраиваться непосредственно в иерархию view существующего экрана. Опять же, сходу вижу несколько способов это сделать. Они потребуют кооперации от автора приложения, но, будучи таким же недобросовестным автором, как и я, он в этом заинтересован. Так кнопка будет работать, но будет закрывать и тот контент, с которым Вы работали. Вам придётся посмотреть рекламу, чтобы вернуться к тому, что Вы делали.
Я могу сделать push-переход вместо модального. Вы можете сказать, что пусть кнопка и push-переходы отменяет! Но это, во-первых, поломает логику некоторых приложений, если мы не даём приложению возможность отключить обработку супер-кнопки для определённых экранов. А если даём – то можно прописать рекламу в исключения, да и всё.
А теперь финт ушами – я реализую свой собственный ContainerViewController. Не push, не модальный показ. Что система с ним должна делать? Система не знает, он кастомный. И это не какая-то "чёрная магия", это всё официальный API, которым люди пользуются по вполне легитимным причинам.
Да я могу банально отслеживать сворачивание рекламы по "мега-кнопке", и тут же открывать снова. Нажимайте :)
И это мы ещё не говорим про баннерную рекламу. Она бывает довольно большой. Но баннерная реклама интегрирована в иерархию view приложения. Система просто не знает, какому view послать запрос на закрытие. Но, допустим, Apple / Google, как часть API для этой кнопки, заставляют маркировать рекламные вьюшки. Я просто промаркирую пустую вьюшку, показываемую поверх рекламы, вот и всё. Ну и, также, как и выше, есть миллион способов сделать это как-нибудь ещё.
Вы можете сказать: "Но у Apple есть ревью! Вы не пройдёте ревью!". На что я отвечу: пройдём :) Как, думаете, куча шлака пробивается через ревью? Просто на время ревью рекламный SDK будет вести себя "прилично". В конечном итоге мы огребём от Apple проблем, наверное, но это не точно :) А от Google вот даже не знаю, огребём ли. Может и вообще прокатит.
А, а ещё помните, как я говорил, что авторы рекламных SDK (как минимум, некоторых) активно борются против "плохой" рекламы? Так вот. Представьте себе "хорошего" разработчика приложений. Этот разработчик берёт "хороший" SDK, поддерживающий кнопку и т.д. Так вот. Как думаете, с кем борются авторы SDK? С авторами непосредственно рекламы, конечно! Баннерная реклама в приложениях показывается просто браузером. Video interstitial-ы – каким-нибудь видео-плеером с доп. обвязкой для обработки рекламных событий и действий. Интерактивная полноэкранная реклама, если мне память не изменияет – тоже просто браузер с веб-страницей. А там JavaScript. И этот JavaScript может творить всякое. Так что даже в "хороших", "порядочных" приложениях "плохая" реклама всё равно иногда да пробивается.
Так что идея-то хорошая. Но реализации не предвидится. Это даже если забыть, откуда Google получает огромный кусок своих доходов.
Оригинальные Герои, несмотря на эклектику стилей и мифологий, смотрелись довольно цельно. ХотА для меня лично такой цельной не выглядит.
Наверное, я слишком хорошо знаю историю, поэтому меня появление уже пиратов уровня века этак, 17го, когда в Замке войска примерно на уровне 14 века, смотрелось крайне дико. Теперь, с появлением стрелков в виде ганфайтеров 19 века, этот разрыв ещё сильнее увеличился.
Если у вас уже такая мощь огнестрельного оружия, которая делает бессмысленными доспехи, тогда почему войска в людском Замке до сих пор в доспехах, а их кузница производит какие-то убогие баллисты?
Второй аспект: я пробовал играть в 1.5.4 на случайных картах. Понял, что не зря Хоту злые языки называют "Герои цехов и зефирок". Привычных объектов на карте стало гораздо меньше, они вытеснены новыми. Ожидал ли я такого от дополнения к игре, как позиционируют Хоту сами разработчики? Нет. По-моему, ещё Сид Мейер вывел эмпирическое правило: в новой части 1/3 элементов геймплея оставить старыми, 1/3 поменять, 1/3 добавить новых. Тут это правило нарушается.
Третий аспект: геймплей.
Все недостатки оригинального геймплея были в ХотА бережно сохранены:
Дисбаланс героев, где толковых где-то около 15% в лучшем случае.
Дисбаланс навыков
Дисбаланс системы магии
В 95% сражениях стрелки + масс. замедление = победа. Активное использование автоматических битв только доказывает, что все эти сражения не нужны, никакого напряжения межушной мышцы игрока не требуется.
Способы исправления дисбаланса навыков (порезка некромантии и дипломатии, замена сопротивлени) в ХотА мне не нравятся. Всё равно считаю, что мои варианты гораздо лучше.
При этом в разных других модах почти все перечисленные недостатки были исправлены, поэтому возвращаться к старому геймплею особого желания нет.
Я постараюсь. Вообще такой план и был но потом мне стало лень 😂
Я работал в ВК с 2011 по 2016. Всё начало ощутимо лететь на дно примерно через год после ухода Дурова. Было очень серьёзное изменение внутренней культуры. Появился аж целый HR-отдел. Начали набирать пачками сотрудников, которые не особенно отличались компетенцией. Начали вводить иерархии. Появились эти менеджеры никчёмные, которые активно мешали мне работать. Продуктовые решения начали приниматься без участия разработчиков — задачи просто сваливались с неба и обсуждению не подлежали. Появился весь этот бизнес и собственные цели компании, которые шли вразрез с потребностями пользователей. Все эти Сергеевы и Добродеевы, да, которые интересовались только деньгами, на продукт им было насрать, в зингере их никто никогда не видел, и уж тем более с разработчиками они не общались. Для меня это всё было дикостью уже тогда. Потому и уволился. Это было сложным решением, но под конец работа в ВК для меня походила на какие-то абьюзивные отношения.
То, что происходит сейчас — всего лишь дальнейшее развитие этих проблем, имхо. Почти все мои бывшие коллеги из-за всего этого тоже уволились рано или поздно. У нас есть аж целый чат бывших сотрудников.
Хе-хе, ставишь цели - выполняешь это хороший подход. Прозрачный. Есть у нас в одной e-commerce бигтех компании более весёлый вариант ревью - без четких целей и критериев оценки, еще и в формате олимпиады: всех сравнивают со всеми (разработчиков с qa и системными аналитиками) кто больше для компании принес ценности, еще и в разных грейдах. И оценивают консилиумом руководителей по N задачам котрые сами сотрудники вписывают как самые значимые за пол года. Получается плоский список отсортированных по полезности людей, на который накладывается распределение оценок - хороших столько то % , плохих %
В итоге если задачи сотрудника на взгляд руководителей менее полезные чем у других но работал он хорошо - у него высокий риск попасть в распределение так себе оценки, не получить премию, или повышение. А при совсем плохой - вообще быть уволенным.
Ну это же база - ставят ОКР/perf review на работе - значит, будут на это смотреть при повышении зп/должности. А значит, нужно выдумывать такие цели, которые ты 100% выполнишь, если даже половину года проспишь. В идеале - выполненные уже сейчас.
А работать ли на цели бизнеса или на личные - очевидно на те, за которые дадут больше денег.
Такова работа в корпорации :)
Не знаю, имел ли автор в виду ВК или VK (ex. mail.ru), но в ВК система ревью существовала как минимум с 2015 года, и после ~2020 года она была сравнительно доведена до ума.
Процесс согласования целей (обычно - оконченных проектов) проводился адекватно и согласовывался с руководителем. Можно было оспорить, подтюнить договорённости, согласовать иной DOD. На амбиции не дрочили, так как должна быть и оценка "соответствует ожиданиям", и "выше ожиданий" - как раз для амбициозных чуваков.
Также в системе был учёт влетающих adhoc-проектов, которыми можно было вытеснить любой из ранее согласованных эпиков. Понятно же, что ты пользу бизнесу приносил по запросу самого бизнеса, и странно тебя за это штрафовать при невыполненном другом эпике.
Периоды оценивания короткие, поэтому ты не терял фокус, не забывал о договорённостях, было всё честно и сравнительно справедливо.
То, что описывает автор, для меня похоже скорее на лень со стороны руководителя автора, который скипнул этап формирования ожиданий в эпиках, переложил ответственность на сотрудника, ведением сотрудника не занимался, а сотрудник не придал этому важности. Теперь автор вместе с руководителем будет разгребать сложившуюся ситуацию.
А ещё ситуация не то что бы из ряда вон выходящая, и считаю, что автор на обозрение вынес сор из избы. Не знаю, как к этому относиться, но внутренние правила компании предписывали такое сначала с hr-bp разобрать.
Не смотря на то, что я очень плохо отношусь к различным «ревью», именно эта ситуация выглядит комично и справедливо:
Людям говорят определить цели и планы, они считают это необязательным, игнорируют. Выполнять тоже не спешат:
«Желания выполнять цели, которые практически были высосаны тобой из пальца, дабы соответствовать количеству в n* штук - особо не было.»
Руководство решает не выплачивать необязательную премию тем, кто решил не выполнять поставленные задачи:
Мы демотивированы, это нечестно
В нашей конторе похожий подход, хотя мы эксплуатация, не разработка. Начальство: "вот вам новые показатели, эти цифры обязательны". Сотрудники: "это нереальные цифры, выбранная метода оценки построена неправильно". Начальство: "мы знаем, вот вам инструкция как на%бать систему, если не получается, вот секретная инструкция, как это сделать точно". Спецы-мотиваторы, блин. Я уже открытым текстом говорю, засуньте эти цифры в опу, уволят так уволят.
Абсолютно абстрактная и непроверяемая цель - как я и хотел, а вы нет)
Тоже мало проверяемая цель, чисто на уровне - ну ты помогал? - помогал еще как!
Главная проблема тут в этом:
Вот, в этом вся и проблема! В программировании все очень шатко, зыбко и неопределённо как в сложной творчески-исследовательски-технической деятельности. Поэтому сама идея брать на себя какие-то обязательства на год вперед - это полнейший, шизофренический бред. Написать больше строчек кода или больше классов/методов на 20%? Закрыть больше жир на 15%? Ускорить работу моего модуля в 3 раза? Выучить питон в 1.5 раза глубже? Всё это примеры бреда бредового. В таких сложных, часто меняющихся и не очень предсказуемых сферах деятельности работают только экспертные оценки.
ох... 10 лет назад занимался подобным (и даже вещами на пару порядков продвинутее, но все равно очень рад, что это в прошлом)
во-первых, что мой личный вывод, что серьезных алготрейдеров с командами разрабов, что стратегии на основе анализа одного числового ряда, мягко говоря, хрень полная. Могут еще как-то работать либо вещи, основанные на микроструктуре рынка (стакан, HFT, код на FPGA), на предоставлении ликвидности, на технологическом превосходстве, на анализе дополнительной информации (новости читать нейросетью), но вот эта магия на свечах сделала богатыми только продавцов лопат. К слову, продавцы лопат неплохо постарались, - сейчас куча библиотек (в том числе, бесплатных), которые любой индикатор вроде MACD или линий Боллинжера рассчитают из коробки без необходимости программировать их с 0 через pandas и numpy
во-вторых, если уж так хочется в этом участвовать, то инструменты давно придуманы и запрограммированы. 10 лет назад была удивительная прожка Amibroker, имеющая свой векторный язык, интерпретирующийся написанным на С++ движком, что давало поистине реактивную скорость. И там были из коробки реализованы очень неплохие алгоритмы оптимизации, позволяющие реально сократить время оптимизации на порядки без потери точности, например, CMA-ES. Конкретно он настолько хорошо работал, что я потом кажется, запрограммировал его сам на C#, чтобы в свой самопичный бектестер залить.
ну и, последнее, - оптимизировать по профиту, не имея защиты от дурака в виде статистических тестов стат значимости гипотез - очень плохая идея. Втупую оптимизировать по профиту можно, разве что, HFT с 10000+ сделок за один прогон бектеста. Во всех остальных случаях это будет просто подгонка под историю. Недаром люди придумали всякие штуки вроде Sharpe ratio. Скачайте тот же Amibroker ради любопытства, посмотрите, какие там, помимо профита, цели оптимизации из коробки дает выбрать, почитайте их формулы на википедии, задайтесь вопросом, а зачем это придумано?
Так у нас это уже сделано. Просто писать такое было бы голимой рекламой. Но раз уж ты спросил, то встречай Axiom Native Image Kit. Это downstream distribution для GraalVM Community Edition с поддержкой команды Axiom JDK.
Видимо через пару лет и до использования контейнеров дело дойдёт.
К сожалению, не очень понятно, для чего была проведена миграция, и были ли достигнуты её цели.
Проблема в том, что можно делать коммиты под чужим именем. Вы делаете коммит от кого-то знакомого мейнтейнеру проекта, надеясь что он не будет внимательно все проверять и смержит. Можно использовать подпись, но все ли так делают?
И не будут. Никогда. Как человек, в свое время обучивший более 500 сотрудников работе за компьютером и конкретно в 1С:Розница, и день за днем повторявший им по телефону одни и те же инструкции, зачитываемые по бумажке, которую сам и писал аж в четырех вариантах, могу объяснить, почему. Все эти ваши "симпрактические" и "теоретические" мышления, как и прочие сравнительные конструкты, ни при чем.
Дано: крупная сеть по продаже преимущественно печатной продукции в киосках в одном крупном городе и близлежащей области. Количество точек: около 300 (на момент моего ухода оттуда отсалось почти вдвое меньше - данная часть торговли умирает под гнетом разных факторов). Контингент обучаемых: женщины возраста от 30 до бесконечности, большинство пенсионеры. Уровень знаний: есть бывшие бухгалтеры, есть те, кто компьютер видит впервые в жизни за свои 40 с лишним лет - нет, это не шутка, я сам с трудом в это поверил, и тем сильнее был мой шок от осознания той задницы, в которой я оказался в тот момент, ибо мне предстояло за несколько часов обучить человека уровня "ноль на уровне комплексного числа" до умения хотя бы тыкать в кнопки в 1С в нужной последовательности.
Требуется: обучить сотрудников работе в 1С:Розница на свежекупленных ноутах. Обучить на минимальном уровне "зайти в программу под собой, пробивать товары сканером штрихкода, фиксировать продажу, смотреть остаток товара в программе". Для продвинутых - проводить инвентаризацию по категориям, делать пересорты и так далее, как в любой торговой точке. Мной была написана инструкция. Детальная. Подробная. Талмуд на 16 страниц убористого текста А4. Я на тот момент еще был молод и зелен, да. Потом была написана еще одна - та же инструкция, но урезанная до уровня "1. Нажать кнопку А. 2. Ввести сумму в поле Б, нажимая кнопки с цифрами на ноутбуке, 3. Нажать кнопку В.". Менеджеры меня умоляли сделать инструкцию "с картинками", потому что "без картинок они не понимают", но я уже на тот момент на практике понял, что картинки/не картинки - значения не имеет абсолютно, так как проблемы лежат абсолютно в другой плоскости. Люди работают не деградировавшие ментально, чтобы им нужны были картинки, как маленьким детям. Была написана третья инструкция. Четвертая. Сложился определенный стиль общения, новая терминология, я уже по номеру торговой точки на экране телефона знал, что там за люди работают, и с чем они обратятся. Да, инструкции все еще не читали, даже спустя месяцы и годы. Только если придешь, встанешь рядом и скажешь "берите, читайте вслух инструкцию и повторяйте за мной все действия". И вот почему.
Человек должен быть мотивирован исполнять инструкцию. Нет, не так. Нет, зарплата тут ни при чем. Опосредованно - да, она влияет, чтобы человек любил свою работу, он должен быть в том числе финансово мотивирован. Но часто, очень часто бывает так, что человек ненавидит свою работу и ходит на нее от безысходности. И можно повышать ему зарплату, можно пугать его штрафами, материальной ответственностью, применять кнут и пряник - ему плевать. Ему одинаково хреново во всех случаях на неблагодарной, изматывающей работе. И когда приходят с очередной инструкцией, которую надо делать, он просто не хочет это делать, потому что человеку все равно. И вы с этим не сделаете ничего. Поэтому лучше перефразирую - человек изначально должен любить свою работу, чтобы хотеть ее выполнять качественно. Есть еще один случай, который должен быть в списке под номером ноль - люди ленивы, хотят делать меньше, но получать за это больше, но он настолько очевиден, что я его пропущу. Хотя любовь к халяве часто настолько прет из всех щелей и о ней в открытую заявляют в лицо, что это перекрывает все остальное.
Человек любит свою работу. Человек хочет научиться, чтобы эту работу не потерять. Проблема номер два, самая главная, и самая большая - человек боится исполнять инструкцию. Да, именно так. Инструкция может быть сколь угодно примитивной и тупой, "интуитивно понятной", она бесполезна, если человек боится совершить ошибку. Я приходил, вставал рядом с продавцом, говорил "открывайте при мне инструкцию, делаем по порядку, как написано". Удивительным образом, делали. Правильно. Аккуратно. Медленно, да, но делали. Я спрашивал, все ли понятно, есть ли что-то сложное. Ничего нет. Я уходил. Все повторялось. С надзором сверху, с контролем (я на телефоне, перед глазами экран ноута по VNC) все делается. Самостоятельно - нет. Страх вызывает ступор и даже самая простая инструкция перестает восприниматься. Страх вызывает все, вплоть до открытой агрессии - когда я развозил по тем же точкам онлайн-ККМ под 54-ФЗ, на меня орали отборным матом, запирали в киоске и угрожали, отказываясь даже слушать, что все, что им понадобится дополнительно делать - отрывать чек и менять рулон с лентой, больше в их работе не изменится ни единого момента.
Проблема номер три. Инструкция непонятна. Нет, рассуждения об "абстракциях" ни при чем. Абстрактное мышление у людей прекрасно работает, если его пнуть нужным образом (ага, "ёж птица гордая, пока не пнешь - не полетит"). Чтобы это сделать, нужно говорить на языке исполнителя. Забудьте слова "окно", "курсор", "поле ввода", "кнопка мыши", "отрицательный остаток". Люди не поймут, что такое "окно", даже если видят его на экране перед собой. Вы оперируете этими понятиями, потому что обучались им с нуля. Исполнитель ими не оперирует. Он их не знает. Если у вас дохренища времени, можете обучить исполнителя вашему языку и объяснить ему все это, но это долгий и тупиковый путь, который не ведет к выполнению текущей задачи. Переводите абстракции на язык, понятный исполнителю, которым он описывает свою обычную работу. "Таблица", "стрелочка", "мигающая черточка", "полоска сверху", "желтый кружок слева". Чукча из анекдота ваш лучший друг - "что вижу, о том пою". Это не деградация мышления, это описание тех же абстракций другим языком. Человек поймет, что скрывается за теми или другими визуальными элементами, если ему объяснить на том языке, на котором он вас понимает. Даже базовые бухгалтерские понятия - дебит, кредит, "минус на остатке", приход, расход - объяснить человеку очень легко. Когда я увольнялся, самой частой фразой от продавцов было "вы единственный, кто нас понимает, когда мы объясняем". Учите язык исполнителя. Его язык описывает среду, в которой он работает. Он не обязан учить ваш и постоянно заниматься переводом с "языка инструкции" на свой. Этот язык иностранный, даже если вам кажется, что это тот же русский язык.
Проблема номер четыре. Инструкция не должна быть алгоритмом. Точнее, должна, ибо описывает действия... но и не должна. Человек не машина, не автомат на заводе, выполняющий однообразные операции (хотя упомянутых сотрудников Амазона вынуждают превращаться в них). Человек выполняет много разных дел. Человеку важен контекст. Говорите с человеком. Инструкция должна описывать, что человек должен сделать, и что за этим стоит. Вы можете научить человека упомянутому выше "кнопка А, сумма Б, кнопка В". Шаг влево, шаг вправо - ступор. Это кстати и проблема, которой страдают все "курсы программирования" - они учат стандартным ситуациям, стандартным примерам... но они не учат программировать. На выходе с курсов мы моем получить человека, который вызубрил синтаксис SQL, но не имеет понятия о внутренней кухне реляционных БД. Я видел столько кода от подобных "программистов", где неиндексируемые выборки миллион на миллион записей уходят в прямое произведение в запросе... оптимизация? что это? индексы? какие индексы? какие предвыборки? какая сложность алгоритма? какой еще поиск в куче? Такой человек не знает, он умеет только выполнять операции. Объясняйте суть операций, объясняйте на человеческом языке, не на языке автомата. Я научился писать инструкции и информационные записки для продавцов очень просто. Я просто разговаривал с продавцом и записывал свои слова как есть. Поток сознания, который потом приводился в литературный вид. Как мне потом некоторые говорили "достаем из почты листок и сразу понимаем, что от вас, потому что написано точно как вы говорите". И людям было понятно. Главное - не растекаться мыслью по древу, читающий потеряет смысл предложения на второй его строчке. Кратко, но по сути.
Проблема номер пять. Инструкция должна быть нужна. Человек не будет тратить время на то, чем он не пользуется. Человек должен понимать, что он должен делать. Этот вопрос в большей степени организационный... но вот скажите, например, нужны ли стенды на стенах с описанием эвакуационных выходов на случай пожара? Конечно, нужны, скажете вы. А вот конкретно вы всегда ли идете в каждом здании к этому стенду и читаете его? Понятен ли он вам? Всегда ли прикидываете, где вы находитесь в здании и как отсюда выйти в случае чего? Если вдруг случится пожар, насколько этот стенд будет информативен для людей, бегущих в состоянии паники, в дыму, в нулевой видимости? Нельзя повесить стенд на стену и ждать, что он поможет спасти людей от пожара. Нельзя просто спустить инструкцию исполнителям и ожидать, что они будут ей пользоваться. Нужно показывать, для чего инструкция предназначена. Убедиться, что человек ознакомился с инструкцией и сможет ее применить. Убедиться, что человек обучен совершать действия, необходимые от него по инструкции.
Я выше упоминал, что мне приходилось обучать людей, которые видели компьютер впервые в жизни? Это было уже незадолго до моего увольнения, когда руководство распорядилось завершить автоматизацию для самых отдаленных точек, и мне пришлось ездить по селам за 120 километров от областного центра, и на тот момент все описанные выше шаги были пройдены. Так вот. От этих людей я не слышал впоследствии НИ ОДНОГО вопроса. Они обучились всему. Для них сошлись абсолютно все факторы, описанные выше. Они были мотивированы - им нечего терять и они работают в маленьком селе, где все друг друга знают, и работают друг для друга. Они не боялись сделать ошибку - я оставил им копию тестовой базы для самостоятельного обучения и сказал "творите с ней что хотите, вы здесь не испортите ничего" - было устранено самое большое препятствие. Инструкции для них были уже написаны на языке, понятном им. Даже "галопом по европам" я объяснял им не как надо тыкать кнопки, а как надо работать. Им было предельно очевидно, что я не приеду больше за 120 километров стоять рядом с ними, и что им надо учиться сейчас, как и мне было предельно очевидно, что мне надо донести до них все максимально понятным образом и предусмотреть для них все - что они смогут сходить к соседям посмотреть (взаимное обучение тоже очень важный момент), что они могут обратиться по телефону в крайнем случае, но я не буду висеть с ними на телефоне часами (проблема восприятия "вы наш персональный специалист, сделайте нам все красиво" - тоже большая проблема). Была одна бабушка из этой группы обучаемых, которая боялась всего как огня и едва ли не плакала, пытаясь научиться кликать мышкой - для нее мы придумывали все возможные упрощения действий, пытаясь избавить человека от этого страха, и это получилось.
Инструкции работают. Если ими уметь пользоваться. Это тоже искусство, и оно не зависит от всяких "типов мыслительной деятельности".
P.S. Что-то я почти на самостоятельный пост намалевал тут...