Я не могу согласиться, что всё плохо, что долго разбираться и что архитектору для 10 элементов обязательно использовать функции препроцессора (видимо, про них речь). Каждой задаче свой инструмент.
Мне реально часто проще использовать именно PlantUML. Понадобится вставить новый элемент на схему, я это сделаю вставкой одной новой строки и модификацией пары-тройки существующих. Все блоки подвинутся, мышкой перетаскивать не нужно будет. Понадобится поменять раскраску группы блоков (например, классов), я это сделаю буквально за пару секунд. И я не ограничиваюсь сиквенсами.
Плюс многие диаграммы не содержат гигантского числа элементов, в таких случаях даже прибегать к продвинутым возможностям не приходится. Я не говорю, что ничего кроме PlantUML не использую, я делюсь опытом и надеюсь, что это будет полезно тем, кто категорично не отрицает этот инструмент и готов им пользоваться.
Соглашусь, эти 2 момента в явном виде не были проговорены и могло получиться не очень прозрачно. Прокомментирую.
Емнип, стрелки можно писать не только слева направо, но и в обратном направлении, то есть B <–– A должно быть эквивалентно A ––> B. Правда, не помню, можно ли это использовать в целях позиционирования, но по крайней мере, в статье этот вопрос не покрыт.
Стрелки можно ставить справа налево, слева направо, делать их двусторонними или вообще без стрелок. Смысл в том, что наконечник — это дополнительный графический символ. Важно само ребро, то есть это дефисы или точки, используемые при задании связи. Что изображено на конце (или обоих концах) ребра — не принципиально. Для позиционирования важно то, что ранг передаётся от левого узла правому (пардон за не очень строгую формулировку). Поэтому запись B<--A сформирует то же отношение между узлами, что и A-->B, но ранг будет выше в первом случае для A, во втором — для B. Ниже привожу модификацию ранее рассмотренного примера.
Также, по прочтении осталось непонятно, можно ли в одной стрелке совместить опции [hidden] и [norank] (полагаю, что можно).
Если подходить к вопросу с точки зрения синтаксиса, то можно увидеть, что PlantUML принимает связи вида A - [norank,hidden] - B, но я бы не делал по двум соображениям: такая инструкция выглядит как потенциально рискованная для рендеринга плюс встаёт вопрос семантики. Остановлюсь на втором соображении более подробно.
[hidden] и [norank] совмещать не стоит потому, что эти опции направлены на решение разных задач. Первая опция прячет связь, введённую специально для добавления ранга, т.е. в данном случае ранг связи важен и ради него связь и добавлялась (чтобы искусственно пододвинуть узел на нужное нам место). Вторая опция указывает на то, что ранг от этой связи считать не надо, но семантика этой связи важна и её отображение должно сохраняться.
Если же мы смешиваем эти обе инструкции, то стоит задуматься: а точно ли мне эта связь нужна, зачем я её вообще вводил, ведь мне не нужен ни вес связи, ни её визуальное отображение? Ответ, скорее всего, будет отрицательным.
Не вижу противоречий. Я тоже его использую за быстроту и то, что не надо много времени уделять тому, как эстетично расставить блоки на экране. Но ведь иногда схема становится большой и/или возникает желание переставить элементы так, чтобы лучше донести какую-то мысль, и вот тут надо переходить на следующий уровень.
Могу ответить иначе: можно заставить PlantUML расставить элементы как надо, а вот заставить draw.io или что-то иное расставить автоматически -- не особо:)
90 или нет, сказать трудно, но точно много. И если до этого навёл красоту, то с добавлением новых деталей по мере развития диаграммы всё может "поплыть". Поэтому сперва предпочитаю максимально проработать детали, а уже потом, если результат автоматики не впечатляет, начинаю влиять на расстановку элементов.
Я ожидал в группировке объектов скрытые связи. Но в статье они помещенны в другое место.
Одно другому не противоречит. Все способы можно комбинировать. А то, что конкретно в раздел с группировкой я не поместил скрытые связи, объясняется тем, что я хотел представить материалы по мере усложнения: сначала то, что лежит на поверхности, что можно пробовать, не вникая во "внутрянку", а потом постепенно усложняя детали.
Если интересен пример, где сочетаются скрытые связи, norank и ractangle, могу предложить обратиться к примеру №2 из упомянутой в конце работы (прямая ссылка, самый последний раздел). Когда готовил данную публикацию, решил не включать этот пример, чтобы статья совсем не разрасталась.
Из статьи выделил следующие утверждения. И хотелось бы поделиться мыслями на их счёт.
Парадокс Тога (также известный как парадокс сложности или парадокс сложности Тога) — это наблюдение, согласно которому продукты, призванные упростить задачу для пользователей, как правило, порождают новые, более сложные задачи.
и
Парадокс Тога хорошо заметен при разработке корпоративного программного обеспечения, где попытки оптимизировать рабочие процессы часто приводят к более сложным требованиям с течением времени.
и
Например, CRM-система, предназначенная для автоматизации взаимодействия с клиентами, может изначально фокусироваться на базовых функциях, таких как управление контактами и отслеживание истории общения. Как только пользователи начинают ощущать повышение эффективности благодаря этим основным функциям, они начинают запрашивать более сложные инструменты, такие как интеграция с другим программным обеспечением, расширенные отчёты или аналитика для дальнейшей оптимизации их работы.
Рассматривая одни и те же факты, разные люди могут находить им разные интерпретации. Именно это я и предлагаю сделать. Посмотрим на данные цитаты сквозь призму отечественной школы проектирования АСУ. Это не современно, но всё же.
В 60-х гг были сформулированы принципы построения АСОиУ, среди которых был и так называемый принцип новых задач. Суть его состоит в том, что ошибочно пытаться с помощью автоматизации решать существующие проблемы и тупо заменять сложившийся ручной (рутинный) труд машинным; появление вычислительных ресурсов (тогда это называли "ЭВМ") должно стимулировать к появлению качественно новых задач, которые ранее либо не решались, либо вообще были немыслимы на предыдущих этапах развития. Иными словами появление новых возможностей должно приводить к новым задачам.
В такой парадигме предъявление новых требований и нежелание остановиться на автоматизации ещё вчерашней рутины выглядит вполне естественным и обоснованным. А значит и приведённые выше цитаты уже не несут в себе парадокса.
Парадокс, как мне кажется, был бы при условии, что люди, обретя новые возможности, всегда удовлетворялись бы оптимизацией существующего положения вещей, не делая шаг вперёд и не пытаясь "выжать" что-то ещё. Хорошей иллюстрацией подобного подхода, как мне кажется, может послужить цитата, приписываемая Генри Форду: "Если бы я спросил людей, чего они хотят, они бы сказали, что хотят более быстрых лошадей."
UPDATE 2024-03-25: Я видел RFE, где сказано, что IEEE Senior Membership не подходит для критерия ассоциаций.
Спасибо за подробную статью.
Скажите, а в итоге Вам лично зачли участие в этой ассоциации? Интересно просто, "не подходит" это стандартная практика относительно членства в IEEE или кому как повезёт.
Спасибо за статью. При прочтении у меня возник вопрос, правда не совсем по прочитанному:)
У нас 977 000 километров дорог, 64 000 регулируемых перекрёстков и 480 000 знаков, из которых нужно создать дорожные полотна и разметку.
Случается так, что в районе перекрёстка знаки могут стоять не со всех сторон (дорожные службы так проверяют телепатические способности автовладельцев или ещё по какой причине, мне неведомо). Пример: на Х-образном перекрёстке знак главной дороги стоит с 2х сторон, а с двух других знаков нет. Другой пример: нет "кирпича" и знака одностороннего движения по пути "кольцо" и надо догадаться о необходимости в нужный момент свернуть на безымянный съезд, чтобы корректно заехать на "кольцо", а не оказаться на встречке съезда с него.
Иными словами, целиком на знаки полагаться не всегда можно. И в этой связи у меня вопрос: в 2ГИС при построении маршрутов учитываются такие реалии?
Я почему спрашиваю, сам раз был в ситуации, когда такси, двигаясь по навигатору, бодро заскочило на встречку, не подозревая о таких фантомных предписаниях для автомобилистов.
... особенно в случаях, когда провайдер не поддерживает валюту платежа...
Банк-отправитель обычно предоставляет услугу внутренней конвертации, когда платёж сперва конвертируется в валюту платежа, а потом "выгоняется". Конечно, если валюта платежа экзотическая или сопряжена со сложностями текущего времени, то, наверное, могут быть нюансы и не всякую валюту можно получить.
Я верно понял, что разрабатывается платёжный шлюз, независимый от конкретного банка и платёжной системы?
У вас карта в евро. Вы совершаете покупку в Польше в польских злотых. В этом случае схема пересчёта следующая: польские злотые (PLN) → пересчитываются в USD по курсу Mastercard, далее USD → пересчитываются в CNY по курсу Mastercard, затем CNY → пересчитываются в евро по курсу банка.
Справедливости ради стоит сказать, что базовая валюта карты может разниться от страны/юрисдикции и даже банка, выпустившего ту или иную карточку. В примере, насколько я понимаю, речь про некие нововведения в Беларуси.
"rounding": 2,
Если я верно понял, то предоставляется возможность клиенту запросить результат с округлением до некоторого знака. Если так, то надо быть готовым к тому, что для некоторых случаев может вернуться ноль.
И ещё. Примера ответа в статье не заметил, поэтому, на всякий случай, отмечу, что некоторые источники курсов оперируют такими параметрами, как:
количество единиц валюты в курсе (пример: курс для JPY может быть указан за 100 иен, а не за одноу, см. пример: https://cbr.ru/currency_base/daily/)
признак обратного курса (обратной котировки).
Учёт этих особенностей, как в своё время показала практика, было самым сложным в расчёте конвертации.
Эта проблема возникает, когда аналитики и маркетологи начинают слишком рано анализировать данные теста, не дожидаясь его завершения. Такое поведение может привести к неверным выводам и решениям, которые, в свою очередь, могут нанести ущерб бизнесу.
У меня возник вопрос: а зачем посреди эксперимента вообще пытаться делать выводы? Это мне напоминает идею 100 раз бросить монету, но уже после 3-х бросков, увидев, что все 3 раза были "орлы", начать верить в то, что и оставшиеся 97 бросков приведут к "орлам".
Есть эксперимент, есть его условия, критерии завершения (время, число испытаний и/или ещё что), есть гипотезы, а значит можно просто дождаться завершения и потом смотреть на отслеживаемые метрики.
Возможно, конечно, я из статьи не уловил мысль, но правда любопытно понять, зачем "подглядывают".
Визуализация процессов в большинстве случаев доносит информацию более эффективно, чем текст или аудио. В отличие от этих подходов, где возможны разночтения, визуальную презентацию все понимают примерно одинаково, и это очень удобно.
Тоже придерживаюсь такого подхода.
А если у вас есть свои зарекомендовавшие себя в работе способы визуализации, кидайте их в комментарии — обсудим.
Средств визуализации и полезных техник много. Могу предложить посмотреть статьи в моём профиле (ссылка). На текущий момент только последняя из них не касается вопросов визуализации. Надеюсь, будет что взять на вооружение.
Из скрина с резюме удивил пункт о понимании своей зоны ответственности. Как это может быть требованием? В каждой компании или даже команде ответственность разная, по-разному нарезан функционал между ролями и по-разному выстроен процесс. Соответственно, я бы это рассматривал как условия на конкретном месте работы, а не как входное требование.
Пишешь ли ты запросы к БД напрямую или используешь ORM? И все в этом духе.
Если смотреть по тексту, то больше всего насторожили слова про чтение кода недокументированной системы и пассаж про написание запросов к БД, особенно через ORM. Да, способность по коду понять общую логику полезна, но тут надо трезво смотреть на вещи: не каждый аналитик способен (да и вообще не обязан) разбираться в хитросплетениях каких-нибудь лямбда-функций или сишных алгоритмов.
Такие вещи наталкивают на мысль, что работодатель ищет человека, на которого можно будет сгружать всё, что не понравилось делать остальным. При этом оплата, конечно же, будет ниже, чем у тех, кто "делегировал" эту работу аналитику. Я уже сталкивался с такого рода вакансиями раньше. Из примеров: улучшение плана выполнения запросов к БД; описание системы AS IS по коду legacy-системы; разбор инцидентов на проме в режиме 24/7; и даже разработка методологии работы с процентным риском. Ничего хорошего такие вакансии не сулят.
К тому же, если в перспективе ты рассматриваешь рост в архитектора или техлида, то уже на старте стоит прокачивать техничку и задаваться вопросами в стиле «почему в нашем случае оптимальнее использовать Rest‑сервис, нежели что‑то еще».
Ну и вообще, в последнее время наблюдаю, что аналитика всё чаще рассматривают как человека, который будет только "городить" интеграции. Складывается ощущение, что этап анализа задачи (изучение вопроса, погружение в предметную область, поиск потребностей, выравнивание понимания и пр.) уже никому не интересен сам по себе, ибо он якобы проведён. Получается такая идеализированная картина: тебе принесли задачу (уже якобы готовую), а от тебя ждут формальной фиксации этой задачи в каком-то документе/спеке (с применением сиквенсов, конечно, т.к. сиквенсы должны быть просто потому, что так все делают и у кого-то в чек-листе даже есть об этом пункт) и непременно описание интеграционных взаимодействий. Не говорю, что так везде, но смещение фокуса такое наблюдаю.
Согласитесь, сложно дать сильную конкретику в вакансии для начинающего специалиста, который зачастую обладает только теоретическими знаниями.
Соглашусь. Скажу больше, наверняка сложно сформулировать конкретику и к опытному специалисту.
Это вообще интересная и многогранная тема. К примеру, как сформулировать требования, чтобы не отпугнуть? Насколько опыт с конкретным инструментом/продуктом/нотацией является действительно критически важным? Точно ли стоит сужать воронку, заявляя идеальный образ кандидата, или стоит перенести побольше в раздел "будет преимуществом", чтобы большее число кандидатов могло заинтересоваться (ведь ряд вещей при желании можно наверстать уже на месте)?
Да, все так очевидно, но вы удивитесь, как продуктивно выстроится диалог, если обратить внимание на раздел с требованиями (основными задачами) и выстраивать речь исходя из этих пунктов.
Вы удивитесь, но куча вакансий (не ваших, я в целом о ситуации) содержит абстрактные формулировки, которые настолько общо описывают требования и обязанности кандидата, что сделать вывода из этого нельзя. Отдельного упоминания заслуживают вакансии, где в требованиях указана конкретика, но её так много и она так разношёрстна, что трудно представить всё это на одном месте, к тому же на плечах одного человека.
В обоих описанных случаях закрадывается подозрение, что автор такого опуса просто сам (а) не в курсе, что требуется команде (заказчикам), поэтому сформулировал так, как получилось.
Никого не хотел обидеть, просто решил поделиться видением "с другой стороны".
Иногда просто приходишь к мысли, что хочется поделиться с миром идеями, мыслями и наработками. Хабр, к примеру, так и наполняется статьями.
Плюс, заметил по себе, что когда пишешь статью, то начинаешь структурировать и иллюстрировать мысли, систематизировать знания и в процессе иногда можешь поймать себя на том, что где-то в отдельных моментах твои знания западают. В итоге, идёшь разбираться с недостающим кусочком пазла и -- профит! -- подрастаешь сам.
Но вот поможет всё это создать личный бренд, можно ли будет его как-то измерить или материализовать -- не знаю. Идея, что тебе будут присылать офферы хороша, но, боюсь, как бы это не было статистическим выбросом. Если бы кто-то из комментаторов привёл реальные примеры (или примеры обратного), было бы интересно почитать.
Я не могу согласиться, что всё плохо, что долго разбираться и что архитектору для 10 элементов обязательно использовать функции препроцессора (видимо, про них речь). Каждой задаче свой инструмент.
Мне реально часто проще использовать именно PlantUML. Понадобится вставить новый элемент на схему, я это сделаю вставкой одной новой строки и модификацией пары-тройки существующих. Все блоки подвинутся, мышкой перетаскивать не нужно будет. Понадобится поменять раскраску группы блоков (например, классов), я это сделаю буквально за пару секунд. И я не ограничиваюсь сиквенсами.
Плюс многие диаграммы не содержат гигантского числа элементов, в таких случаях даже прибегать к продвинутым возможностям не приходится. Я не говорю, что ничего кроме PlantUML не использую, я делюсь опытом и надеюсь, что это будет полезно тем, кто категорично не отрицает этот инструмент и готов им пользоваться.
Мы уже уходим в область философии и личных предпочтений))
Соглашусь, эти 2 момента в явном виде не были проговорены и могло получиться не очень прозрачно. Прокомментирую.
Стрелки можно ставить справа налево, слева направо, делать их двусторонними или вообще без стрелок. Смысл в том, что наконечник — это дополнительный графический символ. Важно само ребро, то есть это дефисы или точки, используемые при задании связи. Что изображено на конце (или обоих концах) ребра — не принципиально. Для позиционирования важно то, что ранг передаётся от левого узла правому (пардон за не очень строгую формулировку). Поэтому запись
B<--Aсформирует то же отношение между узлами, что иA-->B, но ранг будет выше в первом случае для A, во втором — для B. Ниже привожу модификацию ранее рассмотренного примера.Если подходить к вопросу с точки зрения синтаксиса, то можно увидеть, что PlantUML принимает связи вида
A - [norank,hidden] - B, но я бы не делал по двум соображениям: такая инструкция выглядит как потенциально рискованная для рендеринга плюс встаёт вопрос семантики. Остановлюсь на втором соображении более подробно.[hidden]и[norank]совмещать не стоит потому, что эти опции направлены на решение разных задач. Первая опция прячет связь, введённую специально для добавления ранга, т.е. в данном случае ранг связи важен и ради него связь и добавлялась (чтобы искусственно пододвинуть узел на нужное нам место). Вторая опция указывает на то, что ранг от этой связи считать не надо, но семантика этой связи важна и её отображение должно сохраняться.Если же мы смешиваем эти обе инструкции, то стоит задуматься: а точно ли мне эта связь нужна, зачем я её вообще вводил, ведь мне не нужен ни вес связи, ни её визуальное отображение? Ответ, скорее всего, будет отрицательным.
К определённому месту не прибить, а относительно других упорядочить можно. Часто этого достаточно.
Не вижу противоречий. Я тоже его использую за быстроту и то, что не надо много времени уделять тому, как эстетично расставить блоки на экране. Но ведь иногда схема становится большой и/или возникает желание переставить элементы так, чтобы лучше донести какую-то мысль, и вот тут надо переходить на следующий уровень.
Могу ответить иначе: можно заставить PlantUML расставить элементы как надо, а вот заставить draw.io или что-то иное расставить автоматически -- не особо:)
90 или нет, сказать трудно, но точно много. И если до этого навёл красоту, то с добавлением новых деталей по мере развития диаграммы всё может "поплыть". Поэтому сперва предпочитаю максимально проработать детали, а уже потом, если результат автоматики не впечатляет, начинаю влиять на расстановку элементов.
Одно другому не противоречит. Все способы можно комбинировать. А то, что конкретно в раздел с группировкой я не поместил скрытые связи, объясняется тем, что я хотел представить материалы по мере усложнения: сначала то, что лежит на поверхности, что можно пробовать, не вникая во "внутрянку", а потом постепенно усложняя детали.
Если интересен пример, где сочетаются скрытые связи, norank и ractangle, могу предложить обратиться к примеру №2 из упомянутой в конце работы (прямая ссылка, самый последний раздел). Когда готовил данную публикацию, решил не включать этот пример, чтобы статья совсем не разрасталась.
Да, это интересно. Почитаю, спасибо!
Спасибо!
Из статьи выделил следующие утверждения. И хотелось бы поделиться мыслями на их счёт.
и
и
Рассматривая одни и те же факты, разные люди могут находить им разные интерпретации. Именно это я и предлагаю сделать. Посмотрим на данные цитаты сквозь призму отечественной школы проектирования АСУ. Это не современно, но всё же.
В 60-х гг были сформулированы принципы построения АСОиУ, среди которых был и так называемый принцип новых задач. Суть его состоит в том, что ошибочно пытаться с помощью автоматизации решать существующие проблемы и тупо заменять сложившийся ручной (рутинный) труд машинным; появление вычислительных ресурсов (тогда это называли "ЭВМ") должно стимулировать к появлению качественно новых задач, которые ранее либо не решались, либо вообще были немыслимы на предыдущих этапах развития. Иными словами появление новых возможностей должно приводить к новым задачам.
В такой парадигме предъявление новых требований и нежелание остановиться на автоматизации ещё вчерашней рутины выглядит вполне естественным и обоснованным. А значит и приведённые выше цитаты уже не несут в себе парадокса.
Парадокс, как мне кажется, был бы при условии, что люди, обретя новые возможности, всегда удовлетворялись бы оптимизацией существующего положения вещей, не делая шаг вперёд и не пытаясь "выжать" что-то ещё. Хорошей иллюстрацией подобного подхода, как мне кажется, может послужить цитата, приписываемая Генри Форду: "Если бы я спросил людей, чего они хотят, они бы сказали, что хотят более быстрых лошадей."
Спасибо за подробную статью.
Скажите, а в итоге Вам лично зачли участие в этой ассоциации? Интересно просто, "не подходит" это стандартная практика относительно членства в IEEE или кому как повезёт.
Ох уж эта "системная аналитика" :(
Вот мне и было интересно услышать, спасибо!
Спасибо за статью. При прочтении у меня возник вопрос, правда не совсем по прочитанному:)
Случается так, что в районе перекрёстка знаки могут стоять не со всех сторон (дорожные службы так проверяют телепатические способности автовладельцев или ещё по какой причине, мне неведомо). Пример: на Х-образном перекрёстке знак главной дороги стоит с 2х сторон, а с двух других знаков нет. Другой пример: нет "кирпича" и знака одностороннего движения по пути "кольцо" и надо догадаться о необходимости в нужный момент свернуть на безымянный съезд, чтобы корректно заехать на "кольцо", а не оказаться на встречке съезда с него.
Иными словами, целиком на знаки полагаться не всегда можно. И в этой связи у меня вопрос: в 2ГИС при построении маршрутов учитываются такие реалии?
Я почему спрашиваю, сам раз был в ситуации, когда такси, двигаясь по навигатору, бодро заскочило на встречку, не подозревая о таких фантомных предписаниях для автомобилистов.
Банк-отправитель обычно предоставляет услугу внутренней конвертации, когда платёж сперва конвертируется в валюту платежа, а потом "выгоняется". Конечно, если валюта платежа экзотическая или сопряжена со сложностями текущего времени, то, наверное, могут быть нюансы и не всякую валюту можно получить.
Я верно понял, что разрабатывается платёжный шлюз, независимый от конкретного банка и платёжной системы?
Справедливости ради стоит сказать, что базовая валюта карты может разниться от страны/юрисдикции и даже банка, выпустившего ту или иную карточку. В примере, насколько я понимаю, речь про некие нововведения в Беларуси.
Если я верно понял, то предоставляется возможность клиенту запросить результат с округлением до некоторого знака. Если так, то надо быть готовым к тому, что для некоторых случаев может вернуться ноль.
И ещё. Примера ответа в статье не заметил, поэтому, на всякий случай, отмечу, что некоторые источники курсов оперируют такими параметрами, как:
количество единиц валюты в курсе (пример: курс для JPY может быть указан за 100 иен, а не за одноу, см. пример: https://cbr.ru/currency_base/daily/)
признак обратного курса (обратной котировки).
Учёт этих особенностей, как в своё время показала практика, было самым сложным в расчёте конвертации.
У меня возник вопрос: а зачем посреди эксперимента вообще пытаться делать выводы? Это мне напоминает идею 100 раз бросить монету, но уже после 3-х бросков, увидев, что все 3 раза были "орлы", начать верить в то, что и оставшиеся 97 бросков приведут к "орлам".
Есть эксперимент, есть его условия, критерии завершения (время, число испытаний и/или ещё что), есть гипотезы, а значит можно просто дождаться завершения и потом смотреть на отслеживаемые метрики.
Возможно, конечно, я из статьи не уловил мысль, но правда любопытно понять, зачем "подглядывают".
Тоже придерживаюсь такого подхода.
Средств визуализации и полезных техник много. Могу предложить посмотреть статьи в моём профиле (ссылка). На текущий момент только последняя из них не касается вопросов визуализации. Надеюсь, будет что взять на вооружение.
Из скрина с резюме удивил пункт о понимании своей зоны ответственности. Как это может быть требованием? В каждой компании или даже команде ответственность разная, по-разному нарезан функционал между ролями и по-разному выстроен процесс. Соответственно, я бы это рассматривал как условия на конкретном месте работы, а не как входное требование.
Если смотреть по тексту, то больше всего насторожили слова про чтение кода недокументированной системы и пассаж про написание запросов к БД, особенно через ORM. Да, способность по коду понять общую логику полезна, но тут надо трезво смотреть на вещи: не каждый аналитик способен (да и вообще не обязан) разбираться в хитросплетениях каких-нибудь лямбда-функций или сишных алгоритмов.
Такие вещи наталкивают на мысль, что работодатель ищет человека, на которого можно будет сгружать всё, что не понравилось делать остальным. При этом оплата, конечно же, будет ниже, чем у тех, кто "делегировал" эту работу аналитику. Я уже сталкивался с такого рода вакансиями раньше. Из примеров: улучшение плана выполнения запросов к БД; описание системы AS IS по коду legacy-системы; разбор инцидентов на проме в режиме 24/7; и даже разработка методологии работы с процентным риском. Ничего хорошего такие вакансии не сулят.
Ну и вообще, в последнее время наблюдаю, что аналитика всё чаще рассматривают как человека, который будет только "городить" интеграции. Складывается ощущение, что этап анализа задачи (изучение вопроса, погружение в предметную область, поиск потребностей, выравнивание понимания и пр.) уже никому не интересен сам по себе, ибо он якобы проведён. Получается такая идеализированная картина: тебе принесли задачу (уже якобы готовую), а от тебя ждут формальной фиксации этой задачи в каком-то документе/спеке (с применением сиквенсов, конечно, т.к. сиквенсы должны быть просто потому, что так все делают и у кого-то в чек-листе даже есть об этом пункт) и непременно описание интеграционных взаимодействий. Не говорю, что так везде, но смещение фокуса такое наблюдаю.
Соглашусь. Скажу больше, наверняка сложно сформулировать конкретику и к опытному специалисту.
Это вообще интересная и многогранная тема. К примеру, как сформулировать требования, чтобы не отпугнуть? Насколько опыт с конкретным инструментом/продуктом/нотацией является действительно критически важным? Точно ли стоит сужать воронку, заявляя идеальный образ кандидата, или стоит перенести побольше в раздел "будет преимуществом", чтобы большее число кандидатов могло заинтересоваться (ведь ряд вещей при желании можно наверстать уже на месте)?
Вы удивитесь, но куча вакансий (не ваших, я в целом о ситуации) содержит абстрактные формулировки, которые настолько общо описывают требования и обязанности кандидата, что сделать вывода из этого нельзя. Отдельного упоминания заслуживают вакансии, где в требованиях указана конкретика, но её так много и она так разношёрстна, что трудно представить всё это на одном месте, к тому же на плечах одного человека.
В обоих описанных случаях закрадывается подозрение, что автор такого опуса просто сам (а) не в курсе, что требуется команде (заказчикам), поэтому сформулировал так, как получилось.
Никого не хотел обидеть, просто решил поделиться видением "с другой стороны".
Иногда просто приходишь к мысли, что хочется поделиться с миром идеями, мыслями и наработками. Хабр, к примеру, так и наполняется статьями.
Плюс, заметил по себе, что когда пишешь статью, то начинаешь структурировать и иллюстрировать мысли, систематизировать знания и в процессе иногда можешь поймать себя на том, что где-то в отдельных моментах твои знания западают. В итоге, идёшь разбираться с недостающим кусочком пазла и -- профит! -- подрастаешь сам.
Но вот поможет всё это создать личный бренд, можно ли будет его как-то измерить или материализовать -- не знаю. Идея, что тебе будут присылать офферы хороша, но, боюсь, как бы это не было статистическим выбросом. Если бы кто-то из комментаторов привёл реальные примеры (или примеры обратного), было бы интересно почитать.