Вот тут и суть. С 15-летним опытом в IT я с трудом понимаю, что зашифровано в этих словах.
Я уверен, что в этих формулировках накопленный опыт, боль и желание сделать хорошо.
Но, например, разработчиков из поколения Z сложно заставить прочесть даже одну страницу инструкции по процессам. А сидеть и расшифровывать для них этот документ не стал бы.
У этой работы есть целевая аудитория. И задача — эффективно и быстро создать продукт и уменьшить лишнюю коммуникацию и уточнения. Если не ориентироваться на аудиторию и задачу, даже самую хорошую документацию выкинут, к сожалению.
Как мне кажется, когнитивную сложность надо начинать снижать с упрощения стиля изложения подобных документов.
По полгода тратится, чтобы формулировки были максимально точными и без ошибок.
Это когда в школах учебники по математике переусложнены, потому что автор не хочет выглядеть дилетантом в глазах коллег-математиков, хотя пишет книгу для семилетних детей.
При такой сложности текста оперативка типичного разработчика кончается на третьей странице, у дизайнера — на первой. Руководитель разработки со всей ответственностью прочтет всё и, может, что-то запомнит.
Надо делать так, чтобы придуманная архитектура была понятна всем: заказчикам, разработчикам, тестировщикам и дизайнерам. А для этого надо выйти за пределы формата.
Мне кажется, я не очень понял, что именно показать. Могу в личке ответить на вопросы. Этот способ нивелирует некоторые минусы из приведенных в статье, но у меня пока нет длительного опыта использования.
Через ArgoCD менеджерим микросервисы самого приложения, а не инфру для него. И настраиваем сами микросервисы через Helm.
ArgoCD Application — это CRD. В большинстве случаев ставим один раз и часто изменяем через web интерфейс. Поэтому не проблема обернуть его в чарт.
Конфигурируем через файлик values_еще одно окружение.yaml. А Helm создает манифесты: apiVersion: argoproj.io/v1alpha1;kind: Application:
Определяем:
в каком кластере разврачиваем,
с какими префиксами,
в каких неймспейсах,
какой вариант values файла использовать из самого микросервиса (dev, stage, test...).
набор микросервисов
можно откатить если что-то наредактировали в web интерфейсе
можно независимо версионировать запускаемый набор микросервисов
Можно и вручную развернуть для отладки и дебага, можно и встроить в какой либо процесс депоя через hook. И все площадки приложения оказываются в файлах, которые легко можно сравнить в IDE:
values.yaml,
values-dev.yaml,
values-stage.yaml,
values-....yaml,
values-test.yaml.
Получается, что есть чарты для запуска микросервисов и есть чарт для запуска их всех в каком-то кластере через ArgoCD
Еще думал туда попробовать job добавить для проверки наличия в кластере всех операторов перед запуском в нем микросервисов. И не нравится, что ArgoCD плохо за собой прибирается, может, сборщик мусора удастся впихнуть.
Кандидаты бояться быть слишком узкими для разных компаний, а компании устали читать про общие навыки и ищут конкретного человека и не хотят тратить время на то, чтобы разбираться, что кандидат имел в виду.
Вы, видимо, не нанимали и не отсеивали людей, не читающих вакансии и жмущих на автомате кнопку «откликнуться». Обожаю спрашивать вопрос «Что вы думаете о вакансии?».
Тут нет дороги в две стороны. Хочешь чтобы тебя заметили, придется напрячься
Ну давайте разграничивать тестовое новичка и тестовое для мидла. Новичку только польза от сделанных тестовых даже потом на себесе и чтобы в github что-то было
А мидл может мнить, что несколько его часов вне текущего работодателя хоть что-то стоят. А на деле он больше сольет денег на попытку себя продать ради подобной разовой маленькой работы. Прикиньте как надо замарочиться, чтобы документально через бухгалтерию провести оплату никому ненужного результата по тестовому заданию для десятка людей
Тут не ясно на что откликались и какие требования были в вакансии. Отклик в один клик - это не трудозатраты, а сотни откликов у работодателя - проблема. Для обработки этой сотни требуется терпение и выдержка.
А для оценки своих тестовых - идите на курсы с преподом, по какой причине тестовые должны бесплатно оценивать?
И вообще, доказать, что вы — это не ChatGPT, теперь проблема кандидатов.
А выполненное тестовое надо прикреплять к резюме, особенно новичкам, чтобы другим компаниям было легче сразу определить компетенции.
А если нужны дизайнеры разбирающиеся в определенной области, вообще беда. Потому, что многие специализированные системы требуют понимания предметной области и не всегда могут быть решены общепринятыми подходами.
А еще и умеющих в исследования, CJM, JTBD и того меньше
Чего хочет рынок?
По моим ощущениям, дизайнеров, которых не нужно переучивать или доучивать.
Рынок хочет, чтобы специалист решал проблемы бизнеса и команд, а не рассказывал, как хорошо знает Фигму за зарплату мидла :)
Даже войтишник джун может быть ценным кадром, если попытается совместить прошлый опыт с навыками в томже дизайне и начнет продавать эту специализацию.
Со стороны HR найти нормальные кадры среди откликов в «один клик» адски сложно. Задаешь вопрос: «Что вы думаете о нашей компании и вакансии?», а в ответ: «Я не читал, вас так много...». И прекратите придумывать эти дурацкие метрики про улучшение чего-то на 29%-71%
Кто был тот первый, кто написал, что выдуманные проценты по улучшению чего-то увеличивают шансы? Представляете абсурдность ситуации, когда резюме читает специалист с 10+ лет опыта, который понятия не имеет, как он смог бы померить свою эффективность. Зато вот кандидат с опытом джуна смог измерить.
Если задаться вопросом, какую проблему решает компания и как ты можешь ей помочь в решении своими навыками, найти работу будет проще.
Вы плохо читали, не поняли, о чем была речь в комментарии, и отклонились от сути статьи, в рамках которой было начато обсуждение.
Если ничего не знать про двери, помещение, здание и инженерные коммуникации, назначение систем и их особенности работы, требования безопасности и требования эксплуатации, никакой речи о хорошем пользовательском опыте не может быть и речи.
Мне показалось или вы считаете экспертизу в UX отдельной профессией? И раз уж вы дизайнер, значит, не UX-специалист?
В рамках любой профессии существует множество направлений и специализаций. Врач, специализирующийся на глазах, называется окулистом, при этом это все равно врач.
Я уверен, со временем поймете, что UX — это про работу с опытом пользователя в рамках абсолютно любой системы, и не везде вам позволят «выкидывать двери», потому что вы считаете это отличным UX.
Извините, но я не готов воспринимать деньги как ключевой фактор. Если забить на другие факторы ради денег, в долгосрочной перспективе проиграешь, как минимум в собственной гибкости и умении адаптироваться в рамках изменяющейся среды
UX — это запланировать поставить петли от дверей в правильном месте, чтобы люди нормально могли пользоваться дверью и она открывалась.
UI — это предложение формы петель, цвета двери и формы ручки.
API — это знание о том, каких размеров дверь, какие проемы и какая форма косяков, чтобы петли были незаметными и позволяли двери полностью открываться и не бить стену ручкой.
Я в этом комменте увидел только отговорки, почему мне не надо изучать ничего нового в смежных специальностях. Просто подождем, когда другие станут другими, правильными и хорошими, и тогда можно тоже работать на общее благо.
Со своим 14-летним опытом в IT готов подписаться под каждым словом автора. Хорошая работа строится на уважении к коллегам и изучении их проблем.
ЦА продукта - пользователи, ЦА работника - его коллеги, а потом уже пользователи
Вот тут и суть. С 15-летним опытом в IT я с трудом понимаю, что зашифровано в этих словах.
Я уверен, что в этих формулировках накопленный опыт, боль и желание сделать хорошо.
Но, например, разработчиков из поколения Z сложно заставить прочесть даже одну страницу инструкции по процессам. А сидеть и расшифровывать для них этот документ не стал бы.
У этой работы есть целевая аудитория. И задача — эффективно и быстро создать продукт и уменьшить лишнюю коммуникацию и уточнения. Если не ориентироваться на аудиторию и задачу, даже самую хорошую документацию выкинут, к сожалению.
Как мне кажется, когнитивную сложность надо начинать снижать с упрощения стиля изложения подобных документов.
По полгода тратится, чтобы формулировки были максимально точными и без ошибок.
Это когда в школах учебники по математике переусложнены, потому что автор не хочет выглядеть дилетантом в глазах коллег-математиков, хотя пишет книгу для семилетних детей.
При такой сложности текста оперативка типичного разработчика кончается на третьей странице, у дизайнера — на первой. Руководитель разработки со всей ответственностью прочтет всё и, может, что-то запомнит.
Надо делать так, чтобы придуманная архитектура была понятна всем: заказчикам, разработчикам, тестировщикам и дизайнерам. А для этого надо выйти за пределы формата.
Мне кажется, я не очень понял, что именно показать. Могу в личке ответить на вопросы. Этот способ нивелирует некоторые минусы из приведенных в статье, но у меня пока нет длительного опыта использования.
Через ArgoCD менеджерим микросервисы самого приложения, а не инфру для него. И настраиваем сами микросервисы через Helm.
App -> (App Helm dev, stage, prod) -> Argo Application -> Argo Helm (dev_1_cluster, dev_2_cluster, dev_3_cluster)
ArgoCD Application — это CRD. В большинстве случаев ставим один раз и часто изменяем через web интерфейс. Поэтому не проблема обернуть его в чарт.
Конфигурируем через файлик values_еще одно окружение.yaml. А Helm создает манифесты:
apiVersion: argoproj.io/v1alpha1;kind: Application:Определяем:
в каком кластере разврачиваем,
с какими префиксами,
в каких неймспейсах,
какой вариант values файла использовать из самого микросервиса (dev, stage, test...).
набор микросервисов
можно откатить если что-то наредактировали в web интерфейсе
можно независимо версионировать запускаемый набор микросервисов
Можно и вручную развернуть для отладки и дебага, можно и встроить в какой либо процесс депоя через hook. И все площадки приложения оказываются в файлах, которые легко можно сравнить в IDE:
values.yaml,
values-dev.yaml,
values-stage.yaml,
values-....yaml,
values-test.yaml.
Получается, что есть чарты для запуска микросервисов и есть чарт для запуска их всех в каком-то кластере через ArgoCD
Еще думал туда попробовать job добавить для проверки наличия в кластере всех операторов перед запуском в нем микросервисов. И не нравится, что ArgoCD плохо за собой прибирается, может, сборщик мусора удастся впихнуть.
Ветки - кажутся не семантическим решением для этой задачи
Сейчас экспериментирую с Helm поверх Application. Вместо ApplicationSet или CI/CD генерации - вся мощь Helm
Прям по делу.
Кандидаты бояться быть слишком узкими для разных компаний, а компании устали читать про общие навыки и ищут конкретного человека и не хотят тратить время на то, чтобы разбираться, что кандидат имел в виду.
В эпоху нейронок это уже отсеивает тех, кому надо, от тех, кто кнопку нажал. А это фильтр для 90% резюме. Лучше сначала рассмотреть тех кто хочет
И сколько платите за тестовое если не секрет? Может и грейд для этого есть?
Как считаете время потраченное на тестовое?
Платите за результат любого уровня? Даже если тестовое не сделали или прислали ерундк?
Платить за тестовое, которое напишут с помощью нейронки - сомнительный способ расходовать деньги компании
Вы, видимо, не нанимали и не отсеивали людей, не читающих вакансии и жмущих на автомате кнопку «откликнуться». Обожаю спрашивать вопрос «Что вы думаете о вакансии?».
Тут нет дороги в две стороны. Хочешь чтобы тебя заметили, придется напрячься
Ну давайте разграничивать тестовое новичка и тестовое для мидла. Новичку только польза от сделанных тестовых даже потом на себесе и чтобы в github что-то было
А мидл может мнить, что несколько его часов вне текущего работодателя хоть что-то стоят. А на деле он больше сольет денег на попытку себя продать ради подобной разовой маленькой работы. Прикиньте как надо замарочиться, чтобы документально через бухгалтерию провести оплату никому ненужного результата по тестовому заданию для десятка людей
Мир иначе работает
Тут не ясно на что откликались и какие требования были в вакансии. Отклик в один клик - это не трудозатраты, а сотни откликов у работодателя - проблема. Для обработки этой сотни требуется терпение и выдержка.
А для оценки своих тестовых - идите на курсы с преподом, по какой причине тестовые должны бесплатно оценивать?
И вообще, доказать, что вы — это не ChatGPT, теперь проблема кандидатов.
А выполненное тестовое надо прикреплять к резюме, особенно новичкам, чтобы другим компаниям было легче сразу определить компетенции.
Ага.
А если нужны дизайнеры разбирающиеся в определенной области, вообще беда. Потому, что многие специализированные системы требуют понимания предметной области и не всегда могут быть решены общепринятыми подходами.
А еще и умеющих в исследования, CJM, JTBD и того меньше
Рынок хочет, чтобы специалист решал проблемы бизнеса и команд, а не рассказывал, как хорошо знает Фигму за зарплату мидла :)
Даже войтишник джун может быть ценным кадром, если попытается совместить прошлый опыт с навыками в томже дизайне и начнет продавать эту специализацию.
Со стороны HR найти нормальные кадры среди откликов в «один клик» адски сложно. Задаешь вопрос: «Что вы думаете о нашей компании и вакансии?», а в ответ: «Я не читал, вас так много...». И прекратите придумывать эти дурацкие метрики про улучшение чего-то на 29%-71%
Кто был тот первый, кто написал, что выдуманные проценты по улучшению чего-то увеличивают шансы? Представляете абсурдность ситуации, когда резюме читает специалист с 10+ лет опыта, который понятия не имеет, как он смог бы померить свою эффективность. Зато вот кандидат с опытом джуна смог измерить.
Если задаться вопросом, какую проблему решает компания и как ты можешь ей помочь в решении своими навыками, найти работу будет проще.
Вы плохо читали, не поняли, о чем была речь в комментарии, и отклонились от сути статьи, в рамках которой было начато обсуждение.
Если ничего не знать про двери, помещение, здание и инженерные коммуникации, назначение систем и их особенности работы, требования безопасности и требования эксплуатации, никакой речи о хорошем пользовательском опыте не может быть и речи.
Мне показалось или вы считаете экспертизу в UX отдельной профессией? И раз уж вы дизайнер, значит, не UX-специалист?
В рамках любой профессии существует множество направлений и специализаций. Врач, специализирующийся на глазах, называется окулистом, при этом это все равно врач.
Я уверен, со временем поймете, что UX — это про работу с опытом пользователя в рамках абсолютно любой системы, и не везде вам позволят «выкидывать двери», потому что вы считаете это отличным UX.
Вот тут вы сильно ошибаетесь про долгосрочную перспективу развития навыков коммуникации и использования расширенной компетенции в смежных областях
Это очень узкий взгляд на UX специализацию, считать, что главное предложить избавится от двери и механизма ее открытия
Извините, но я не готов воспринимать деньги как ключевой фактор. Если забить на другие факторы ради денег, в долгосрочной перспективе проиграешь, как минимум в собственной гибкости и умении адаптироваться в рамках изменяющейся среды
Хороший UX - это подумать как людям будет удобно ходить и сделать так, чтобы им было удобнее ходить через твою дверь
UX — это запланировать поставить петли от дверей в правильном месте, чтобы люди нормально могли пользоваться дверью и она открывалась.
UI — это предложение формы петель, цвета двери и формы ручки.
API — это знание о том, каких размеров дверь, какие проемы и какая форма косяков, чтобы петли были незаметными и позволяли двери полностью открываться и не бить стену ручкой.
Я в этом комменте увидел только отговорки, почему мне не надо изучать ничего нового в смежных специальностях. Просто подождем, когда другие станут другими, правильными и хорошими, и тогда можно тоже работать на общее благо.
Со своим 14-летним опытом в IT готов подписаться под каждым словом автора. Хорошая работа строится на уважении к коллегам и изучении их проблем.
ЦА продукта - пользователи, ЦА работника - его коллеги, а потом уже пользователи