Благодарю за конструктивный и подробный комментарий!
Очень приятно подискутировать с человеком, который вежливо и аргументированно излагает свою позицию!
Безусловно, согласен с вами, что фото может оказывать влияние не бессознательное принятие решения. Причем как в положительную, так и в отрицательную пользу. При этом прошу отметить, что в статье даны точные указания по тому, какое фото должно быть, чтобы оказать именно положительный эффект. При этом это не является must have. В статье приведены рекомендации, а придерживаться их или нет - это решение остается на усмотрение кандидата. И я бы не стал делать вывод о всей статье, на основании лишь этого фактора.
Что касается того является CV продуктом или продающим документом, на мой взгляд - не так важно, как мы его назовем. Важен продуктовый подход, который применятся к CV, который помогает понять потребности твоей ЦА, и сделать так, чтобы достичь нужного тебе результата, за счет удовлетворения этих потребностей.
Также абсолютно согласен, что hr, должен принимать решения, основываясь на компетенциях кандидата. В статье иного и не было сказано. И тут мы с вами не противоречим друг другу.
Если говорить о полезности статьи, то я сужу по метрикам, а не по субъективным мнениям в комментах. А метрики показывают, что статью сохранило 36 человек и более 50 подписались на мой канал, что гораздо лучше подтверждает полезность статьи, чем несколько токсичных комментариев.
Но ваш комментарий мне понравился! Благодарю! Всегда буду рад обсудить вашу точку зрения и придти к объективному выводу, который будет полезен аудитории! ?
Задача - получить больше откликов И задача - защитить ПД
Это разные задачи. Разные задачи должны решать разные продукты. Один продукт не может решать все задачи. Это как шампунь - один против перхоти, второй - освежающий, третий - для жирных волос.
Если вы будете пытаться решать все задачи одним продуктом, то получите плохой продукт.
CV - это продукт для устройства на работу. Для защиты данных нужно использовать другой продукт, а не пытаться закрыть эту задачу при помощи CV.
Согласно JTBD пользователь нанимает продукт для решения определенной задачи. Разберем на вашем примере. Допустим, под ценностями подразумеваются украшения.
Я как пользователь нанимаю драгоценности для того, чтобы выглядеть эффектно, чтобы (например) произвести впечатление.
Дверь с замком - это другой продукт. По JTBD формулировка будет следующей:
Я, как пользователь, хочу закрывать дверь на ключ, чтобы защитить ценности от воров.
Как вы видите, разные продукты решают разные задачи. Теперь вернемся к примеру из статьи.
Если мы говорим о CV, то я как соискатель хочу сделать свою CV конверсионным, чтобы быстрее выйти на работу. В рамках этого JTBD была написана статья, и все советы направлены именно на то, чтобы сделать CV конверсионным.
Если же вы говорите про защиту от мошенников, то это другой продукт. Я как, владелец, персональных данных, хочу выкладывать резюме на надежных сервисах, чтобы защитить мои персональные данные от мошенников.
Для решения защиты ваших данных вы должны использовать другой продукт, например HH, который несет ответственность за ваши данные. А не пытаться путем исключения информации из резюме, защитить свои персональные данные, и тем самым делать резюме менее удобным для рекрутера и снижать конверсию в отклик.
1) Неужели, это неизвестно специалистам по кадрам?
я не специалист по кадрам. Я менеджер продукта. И эта статья написана именно с продуктовой точки зрения, где рекрутер рассматривается, как пользователь вашего CV
2) Это напрямую запрещено законодательством многих стран.
Эта статья написана для России, иначе я бы писал ее на другом языке. Учитывая, что на HH, большинство CV с фото - наше законодательство этого явно не запрещает.
3) Если вам неизвестна причина, то тоже подскажу - предотвращение возможной дискриминиции.
Это единственный весомый аргумент. И я слышал мнение, что рекрутер должен оценивать вас по навыкам в CV, а не по фото. Но дефицит квалифицированных кадров на рынке настолько велик, что профессиональный рекрутер в хорошей компании точно не будет так делать. А другие компании вам и не нужны.
4) я не вижу иной причины требовать наличие фото в резюме, кроме как подаергнуть кандидата какому-то дискриминационному фильтру. Если у кадровика плохая память на резюме - пусть приклеивает стикеры или ищет профессию, не требующую работы с резюме.
никто не говорит о требованиях. Это рекомендация. Есть разница. Повторюсь еще раз, в данной статье применен продуктовый подход к CV, пользователем которого является рекрутер, а вы извлекаете выгоду в виде отклика. С точки зрения продукта абсурдно создавать дополнительные преграды для пользователя на пути к целевому действию.
5) Кадровик не присылает мне своё фото, как того требует элементарная вежливость.
Ваша цель получить работу в крутой компании, или реверансы от кадровика?
Итого, единственный аргумент против фото - это подвергнуться дискриминации. Но впереди у вас будет еще много этапов, где вас увидят, и этот риск реализуется.
Зачем вам нужна компания, где вас будут дискриминировать? Тогда уж лучше реализовать этот риск на более раннем этапе, чтобы инвестировать меньше времени в общение с неэтичной компанией.
Таким образом получается, что предоставление фото а резюме в любом случае обернется вам только плюсом.
Но спасибо, что подробно изложили свою позицию! Было интересно подискутировать! У меня нет цели любой ценой доказать вам свою позицию. Скорее, интересно в ходе дискуссии и обсуждения разных мнений выработать оптимальное решение, которое принесет пользу читателям.
В статье я привел аргументы, почему фото в CV может быть полезно. Вы без аргументов просто высказываете оценочное суждение, что так делать не надо. Аргументируйте свою позицию, пожалуйста. Пока, это выглядит просто как безосновательный наброс)))
Хорошо, что у вас однозначное убеждение по этому вопросу. Но, к сожалению, практика показывает, что то, что очевидно для вас, очевидно далеко не для всех.
В идеальном мире, конечно, продакт должен участвовать во всех исследованиях своего продукта. Но мы живем не в таком мире.
Когда я участвовал в UX-х, то исследователи говорили, что это круто, потому что к ним продакты редко заглядывают. Это был первый сигнал к написанию статьи.
Помимо этого, могу сказать со стороны продакта. Крайне сложно попасть на все UX-ы. Они могут пересекаться с другими важными встречами и в принципе календарь продакта загружен так, что есть соблазн полностью делегировать UX-тесты исследователю и дизайнеру и заняться другой работой. Это второй сигнал.
Но, как и сказал выше, правильно соблюдать баланс.
Практика показывает, что некоторых высокопоставленных заказчиков тяжело приучить к Jira/Я.Трекер. Для них, как для пользователей, это неудобный канал постановки задач и коммуникации. Обычно задачи от таких заказчиков прилетают в чате или ставятся голосом. Как следствие, задача ставится нечетко, и аналитику приходится несколько раз переделывать задачу.
Гораздо эффективнее заставить встречу с такими заказчиками, снять с них их потребности, зафиксировать все договоренности в Jira. Таблица, в данном случае, лишь вспомогательный инструмент, который понятен всем и позволяет сделать быстрый overview всех задач, сроков и приоритетов.
Естественно, после обсуждения, мы заводим все задачи в Jira, где детально описываем задачу после обсуждения и фиксируем все договоренности.
Такой процесс помогает: - избежать переделок задачи и дополнительных трат ресурса аналитика - синхронизировать всю команду - сделать работу аналитика прозрачной для всех заказчиков и выровнять их ожидания
Есть чисто бизнесовые задачи, которые не проходят через продакта. Я их перечислил в комментарии выше. В данном случае важно синхронизироваться с командой и убедиться, что никто не подвинул чужие задачи, так как мы шарим ресурс аналитика с бизнесом. Более того, в процессе встречи гораздо легче найти компромисс по приоритетам. Ни раз было так, что каждый закзчик считал свою задачу важной, но в процессе обсуждения выяснялось, что чья-то задача может 1-2 недели подождать. Кажется, что 1 час в неделю не такая большая инвестиция, которая позволяет избежать потерь времени аналитика и других членов команды на выяснение почему чья-то задача была выкинута из спринта. При этом выстраиваются очень прозрачные и доверительные отношения в команде между командами бизнеса, продукта, аналитики и маркетинга.
В данном случае вы рассматриваете исключительно ситуацию с багом. Я говорю о более широком круге задач, которые не связаны с багами на проде, но требуют ресурса аналитика. Например:
подготовка стратегии. У бизнес-заказчика есть дедлайн по защите стратегии. Для того, чтобы определить приоритетные направления, нужно сделать сегментацию текущих пользователей по размеру аудитории и бюджету. Может быть сегмент пользователей, который мы считаем перспективным, но он не выделен на дашбордах. Для идентификации сегмента может потребоваться выгрузка по кастомному набору параметров.
Проведение профессиональных выставок, на которых выступают заказчики. Может потребоваться аналитика, чтобы презентовать интересные цифры на конференции.
Маркетинговые кампании, для определения параметров которых может потребоваться информация по целевой аудитории в разрезе городов, чтобы понять, в каких городах стоит вкладываться в продвижение.
Наша продуктовая команда шарит ресурс аналитика с бизнесом. Чтобы избежать ad-hoc задач. Мы построили этот процесс, который позволил договариваться о приоритетах на следующий спринт и избежать сдвига других задач. Таким образом, как бизнес, так и продукт имеют прозрачное понимание по ресурсам аналитика, срокам выполнения задач и приоритетам.
Это классная практика. Однако, что в Яндексе, что в Авито я сталкивался с тем, что у бизнес-заказчиков могут быть свои проекты: конференции, к которым нужно подготовиться, GR партнерства, защита стратегии и т.д. Именно для таких проектов мы и договаривались по приоритетам, если ресурса аналитика не хватало.
Табличка лишь часть процесса. Во многом проблема была из-за отсутствия синхронизации между заказчиками. Регулярный синк помог отладить эти вопросы. Табличка нужна лишь для фиксации договоренностей и результатов
Это зависит от культуры в компании. У нас в Авито четкое планирование и никто в конце спринта не прибегает. Все задачи проходят грумминг с разработкой и расписываются на квартал. Более того, уже сейчас мы верхнеуровнего понимаем наш эклог до конца года и уже прорабатываем задачи, чтобы прогруммить их с разработкой до старта нового квартала.
Я согласен, что управление проектами - это отдельная компетенция, но продакт - это зонтичная профессия. Продакт должен понимать и в:
Исследованиях (для этого есть UX-исследователи)
Дизайне (для этого есть дизайнеры)
Аналитике (для этого есть аналитики)
Управлении проектами (для этого есть проджекты)
Более того, в крупных компаниях наличие навыков управления проектами для продакта - это must have.
Когда меня нанимали в Яндекс, мне прямым текстом говорили, что ожидают, что продакт будет совмещать еще и функции проджекта.
Иван, благодарю!
1) Нужно отвечать себе на вопросы:
Довольны ли вы результатом?
Если нет, то почему?
Что вы можете сделать, чтобы в следующий раз результат был иным?
2) Собирать фидбек от коллег
3) Регулярно читать профессиональную литературу и статьи и думать, как это можно применить в своей работе.
Благодарю за конструктивный и подробный комментарий!
Очень приятно подискутировать с человеком, который вежливо и аргументированно излагает свою позицию!
Безусловно, согласен с вами, что фото может оказывать влияние не бессознательное принятие решения. Причем как в положительную, так и в отрицательную пользу. При этом прошу отметить, что в статье даны точные указания по тому, какое фото должно быть, чтобы оказать именно положительный эффект. При этом это не является must have. В статье приведены рекомендации, а придерживаться их или нет - это решение остается на усмотрение кандидата. И я бы не стал делать вывод о всей статье, на основании лишь этого фактора.
Что касается того является CV продуктом или продающим документом, на мой взгляд - не так важно, как мы его назовем. Важен продуктовый подход, который применятся к CV, который помогает понять потребности твоей ЦА, и сделать так, чтобы достичь нужного тебе результата, за счет удовлетворения этих потребностей.
Также абсолютно согласен, что hr, должен принимать решения, основываясь на компетенциях кандидата. В статье иного и не было сказано. И тут мы с вами не противоречим друг другу.
Если говорить о полезности статьи, то я сужу по метрикам, а не по субъективным мнениям в комментах. А метрики показывают, что статью сохранило 36 человек и более 50 подписались на мой канал, что гораздо лучше подтверждает полезность статьи, чем несколько токсичных комментариев.
Но ваш комментарий мне понравился! Благодарю! Всегда буду рад обсудить вашу точку зрения и придти к объективному выводу, который будет полезен аудитории! ?
На мой взгляд странно подход без фото общепринятым, когда в том же hh и Авито Работа почти все CV с фото))
Задача - получить больше откликов
И задача - защитить ПД
Это разные задачи. Разные задачи должны решать разные продукты.
Один продукт не может решать все задачи. Это как шампунь - один против перхоти, второй - освежающий, третий - для жирных волос.
Если вы будете пытаться решать все задачи одним продуктом, то получите плохой продукт.
CV - это продукт для устройства на работу.
Для защиты данных нужно использовать другой продукт, а не пытаться закрыть эту задачу при помощи CV.
В данном случае вы путаете теплое с мягким.
Согласно JTBD пользователь нанимает продукт для решения определенной задачи.
Разберем на вашем примере. Допустим, под ценностями подразумеваются украшения.
Я как пользователь нанимаю драгоценности для того, чтобы выглядеть эффектно, чтобы (например) произвести впечатление.
Дверь с замком - это другой продукт. По JTBD формулировка будет следующей:
Я, как пользователь, хочу закрывать дверь на ключ, чтобы защитить ценности от воров.
Как вы видите, разные продукты решают разные задачи. Теперь вернемся к примеру из статьи.
Если мы говорим о CV, то я как соискатель хочу сделать свою CV конверсионным, чтобы быстрее выйти на работу. В рамках этого JTBD была написана статья, и все советы направлены именно на то, чтобы сделать CV конверсионным.
Если же вы говорите про защиту от мошенников, то это другой продукт.
Я как, владелец, персональных данных, хочу выкладывать резюме на надежных сервисах, чтобы защитить мои персональные данные от мошенников.
Для решения защиты ваших данных вы должны использовать другой продукт, например HH, который несет ответственность за ваши данные. А не пытаться путем исключения информации из резюме, защитить свои персональные данные, и тем самым делать резюме менее удобным для рекрутера и снижать конверсию в отклик.
Разберу ваш комментарий по пунктам:
1) Неужели, это неизвестно специалистам по кадрам?
я не специалист по кадрам. Я менеджер продукта. И эта статья написана именно с продуктовой точки зрения, где рекрутер рассматривается, как пользователь вашего CV
2) Это напрямую запрещено законодательством многих стран.
Эта статья написана для России, иначе я бы писал ее на другом языке. Учитывая, что на HH, большинство CV с фото - наше законодательство этого явно не запрещает.
3) Если вам неизвестна причина, то тоже подскажу - предотвращение возможной дискриминиции.
Это единственный весомый аргумент. И я слышал мнение, что рекрутер должен оценивать вас по навыкам в CV, а не по фото. Но дефицит квалифицированных кадров на рынке настолько велик, что профессиональный рекрутер в хорошей компании точно не будет так делать. А другие компании вам и не нужны.
4) я не вижу иной причины требовать наличие фото в резюме, кроме как подаергнуть кандидата какому-то дискриминационному фильтру. Если у кадровика плохая память на резюме - пусть приклеивает стикеры или ищет профессию, не требующую работы с резюме.
никто не говорит о требованиях. Это рекомендация. Есть разница. Повторюсь еще раз, в данной статье применен продуктовый подход к CV, пользователем которого является рекрутер, а вы извлекаете выгоду в виде отклика. С точки зрения продукта абсурдно создавать дополнительные преграды для пользователя на пути к целевому действию.
5) Кадровик не присылает мне своё фото, как того требует элементарная вежливость.
Ваша цель получить работу в крутой компании, или реверансы от кадровика?
Итого, единственный аргумент против фото - это подвергнуться дискриминации. Но впереди у вас будет еще много этапов, где вас увидят, и этот риск реализуется.
Зачем вам нужна компания, где вас будут дискриминировать? Тогда уж лучше реализовать этот риск на более раннем этапе, чтобы инвестировать меньше времени в общение с неэтичной компанией.
Таким образом получается, что предоставление фото а резюме в любом случае обернется вам только плюсом.
Но спасибо, что подробно изложили свою позицию! Было интересно подискутировать! У меня нет цели любой ценой доказать вам свою позицию. Скорее, интересно в ходе дискуссии и обсуждения разных мнений выработать оптимальное решение, которое принесет пользу читателям.
Поэтому, еще раз, спасибо!
В статье я привел аргументы, почему фото в CV может быть полезно.
Вы без аргументов просто высказываете оценочное суждение, что так делать не надо.
Аргументируйте свою позицию, пожалуйста. Пока, это выглядит просто как безосновательный наброс)))
Целевая аудитория вашего CV мошенники или рекрутеры?)))
Если так боитесь мошенников, то можете направлять свое CV голубями)))
Повторение — мать учения)))
Хорошо, что у вас однозначное убеждение по этому вопросу. Но, к сожалению, практика показывает, что то, что очевидно для вас, очевидно далеко не для всех.
В идеальном мире, конечно, продакт должен участвовать во всех исследованиях своего продукта. Но мы живем не в таком мире.
Когда я участвовал в UX-х, то исследователи говорили, что это круто, потому что к ним продакты редко заглядывают. Это был первый сигнал к написанию статьи.
Помимо этого, могу сказать со стороны продакта. Крайне сложно попасть на все UX-ы. Они могут пересекаться с другими важными встречами и в принципе календарь продакта загружен так, что есть соблазн полностью делегировать UX-тесты исследователю и дизайнеру и заняться другой работой. Это второй сигнал.
Но, как и сказал выше, правильно соблюдать баланс.
Практика показывает, что некоторых высокопоставленных заказчиков тяжело приучить к Jira/Я.Трекер. Для них, как для пользователей, это неудобный канал постановки задач и коммуникации. Обычно задачи от таких заказчиков прилетают в чате или ставятся голосом. Как следствие, задача ставится нечетко, и аналитику приходится несколько раз переделывать задачу.
Гораздо эффективнее заставить встречу с такими заказчиками, снять с них их потребности, зафиксировать все договоренности в Jira. Таблица, в данном случае, лишь вспомогательный инструмент, который понятен всем и позволяет сделать быстрый overview всех задач, сроков и приоритетов.
Естественно, после обсуждения, мы заводим все задачи в Jira, где детально описываем задачу после обсуждения и фиксируем все договоренности.
Такой процесс помогает:
- избежать переделок задачи и дополнительных трат ресурса аналитика
- синхронизировать всю команду
- сделать работу аналитика прозрачной для всех заказчиков и выровнять их ожидания
Не соглашусь с вами)
Есть чисто бизнесовые задачи, которые не проходят через продакта. Я их перечислил в комментарии выше. В данном случае важно синхронизироваться с командой и убедиться, что никто не подвинул чужие задачи, так как мы шарим ресурс аналитика с бизнесом. Более того, в процессе встречи гораздо легче найти компромисс по приоритетам. Ни раз было так, что каждый закзчик считал свою задачу важной, но в процессе обсуждения выяснялось, что чья-то задача может 1-2 недели подождать. Кажется, что 1 час в неделю не такая большая инвестиция, которая позволяет избежать потерь времени аналитика и других членов команды на выяснение почему чья-то задача была выкинута из спринта. При этом выстраиваются очень прозрачные и доверительные отношения в команде между командами бизнеса, продукта, аналитики и маркетинга.
В данном случае вы рассматриваете исключительно ситуацию с багом. Я говорю о более широком круге задач, которые не связаны с багами на проде, но требуют ресурса аналитика. Например:
подготовка стратегии. У бизнес-заказчика есть дедлайн по защите стратегии. Для того, чтобы определить приоритетные направления, нужно сделать сегментацию текущих пользователей по размеру аудитории и бюджету. Может быть сегмент пользователей, который мы считаем перспективным, но он не выделен на дашбордах. Для идентификации сегмента может потребоваться выгрузка по кастомному набору параметров.
Проведение профессиональных выставок, на которых выступают заказчики. Может потребоваться аналитика, чтобы презентовать интересные цифры на конференции.
Маркетинговые кампании, для определения параметров которых может потребоваться информация по целевой аудитории в разрезе городов, чтобы понять, в каких городах стоит вкладываться в продвижение.
Наша продуктовая команда шарит ресурс аналитика с бизнесом. Чтобы избежать ad-hoc задач. Мы построили этот процесс, который позволил договариваться о приоритетах на следующий спринт и избежать сдвига других задач. Таким образом, как бизнес, так и продукт имеют прозрачное понимание по ресурсам аналитика, срокам выполнения задач и приоритетам.
Это классная практика. Однако, что в Яндексе, что в Авито я сталкивался с тем, что у бизнес-заказчиков могут быть свои проекты: конференции, к которым нужно подготовиться, GR партнерства, защита стратегии и т.д. Именно для таких проектов мы и договаривались по приоритетам, если ресурса аналитика не хватало.
Табличка лишь часть процесса. Во многом проблема была из-за отсутствия синхронизации между заказчиками. Регулярный синк помог отладить эти вопросы. Табличка нужна лишь для фиксации договоренностей и результатов
Это зависит от культуры в компании. У нас в Авито четкое планирование и никто в конце спринта не прибегает. Все задачи проходят грумминг с разработкой и расписываются на квартал. Более того, уже сейчас мы верхнеуровнего понимаем наш эклог до конца года и уже прорабатываем задачи, чтобы прогруммить их с разработкой до старта нового квартала.
Спасибо! Рад, что статья оказалась полезной! ☺️
Пожалуйста! Всегда рад проконсультировать по продакт-менеджменту! ?