Согласен, что «люди-оркестры» выгорают. Мы как раз не ищем таких.
Речь не о том, чтобы один аналитик делал за всех, а о том, чтобы в команде были мыслящие партнёры, которые видят продукт целиком, задают критические вопросы и формулируют гипотезы.
Мы ждём от продуктовых аналитиков опыта в работе с продуктом: эксперименты, метрики, влияние на решения, на бизнес. Это и есть суть продуктовой аналитики. Нет, необязательно быть прекрасным кодером или иметь финансовый опыт, но для получения результатов нужно писать код на SQL, Python и проводить анализ. То, что я описал – это не про человека оркестра, а стандартные требования к продуктовому аналитику.
Хорошая мысль про тандем. Когда роли дополняют друг друга – это прекрасно работает. Я обычно начинаю с другого конца — сначала разбираюсь, зачем вообще тандем нужен и правда ли он решит проблемы команды
на собеседованиях мы не гонимся за количеством. эффективное выполнение задач, которые не нужно решать, сводит ценность приложенных усилий к нулю.
в первую очередь смотрим на мышление: как человек рассуждает, на что обращает внимание, как формулирует гипотезы и проверяет логику решения. навык мышления можно и проще проверять без ИИ, поэтому не вижу никакого двойного стандарта.
навыки владения инструментами (SQL, Python, ИИ) и умение решать типовые задачи тоже важны, но вторичны. мы смотрим на них на первом этапе, а дальше даём два продуктовых кейса без «правильного ответа» – чтобы увидеть, как человек мыслит, структурирует и делает выводы.
если кратко: навык работы с ИИ нужен, без него никуда, но это второй приоритет. Умение мыслить и анализировать самостоятельно – первый. без первого не будет второго.
у нас четыре основных этапа отбора: два технических интервью, встреча с HR и интервью по ценностям. если всё проходит успешно, мы можем попросить контакты коллег для рекомендаций.
алгоритмические задачи (leetcode) у нас есть, но фокус на том как кандидат мыслит, а не на оптимальном решении.
задачки на листочке решать не нужно, но если нужен листочек – можно им пользоваться. Предлагаем простой онлайн редактор для кода.
у нас все аналитики (маркетинговые, продуктовые) пишут код (Python, SQL) для расчетов в исследованиях, экспериментах и так далее. это код не для прода (аналитики – не инженеры), а для вычислений
согласен, что перечисленные практики важны. мы к ним тоже постепенно приходим, но видим в них не отправную точку, а следствие любопытства.
сначала человек начинает задавать вопросы, спорить, что-то инициировать – и мы помогаем этому импульсу найти форму (в виде аналитической модели, исследования, обзора, доклада, и так далее).
я в своём ответе как раз говорил о том, что мы делаем до этого шага – чтобы это любопытство и инициатива вообще появились. мы стараемся создать среду, где безопасно предлагать, где инициативу не гасят, где руководитель не приходит с готовыми ответами.
1. а) примерно на 70% б) на 8 — для текущего состояния бизнеса
важный момент: мы как компания не маленькие — можем позволить себе ждать и выбирать нужных кандидатов. но и не настолько большие, чтобы нужно было нанимать постоянно и много.
2. развитие BI и витрин важно, но да, вторично по сравнению с развитием членов команды.
что делаем для этого:
развиваем менеджеров (у нас есть внутренние курсы)
разговариваем и поощряем инициативу (101, сбор ОС)
стараемся приходить с вопросами и проблемами, а не с готовыми решениями
уменьшаем рутину и операционные задачи
если видим, что человек начал приходить с идеями, ответами, инициативами, предложениями — значит это то, что нам нужно)
у нас получается нанимать людей, которым хорошо в компании и нравится решать задачи продукта. из-за этого и бизнес видит пользу и растёт. статья в том числе про это)
ну вот внизу посоветовали какую-то другую модель, мы еще не пробовали, пока не можем ничего сказать, но затестить можно) если нужен только текст, без сложной углубленной логики - почему нет
видели тоже, можно достраивать промпт, что-то в духе "не разбивай текст на строки, если это не обосновано нехваткой места в строке". сотни вариантов, но придется вручную, да)
Привет! Да, конечно пользуемся, но подходим осознанно, потому что переиспользование поднимает ответственность кода и усложняет его поддержку. Всегда используем на уровне core библиотек: api client, тулкит, логгер, аналитика. Стараемся выносить общую бизнес логику в общих частях, вроде чатов или авторизации. На уровне страниц и ui виджетов бизнес логику чаще делим по платформам
мы используем Detox для e2e перед релизами и Detox с кастомным mock сервером для компонентных UI тестов по аналогии, как работает cypress + msw на вебе
я думаю, что тут проблема с перерендером в случаях, когда надо использовать маску на инпуте. можно посмотреть в сторону input-mask-ios , либо на стороне кода постараться минимизировать количество ререндеров (менять value через ref, не использовать стейт для значения)
проблем стало правда гораздо меньше, но вот наш большой проект переводить на новую архитектуру тяжеловато из-за большого количества зависимостей на внешние библиотеки, из-за различных собственных внутренних обвязок и анимаций. Мы запланировали переход в следующем году, так что нам еще предстоит проверить, всё ли там решено
объясню, то имел в виду под тем, что все разрабочики за счет стека получились универсальными. наши ребята из фронтов могут писать мобильные приложения, потому что там тоже реакт. а раз уж залезли - иногда залезают и в нативный код, прокачиваются
ребята из нативных разработчиков остались с нами не все. но, кто остался, обучился разработке на react. И теперь помогают в нативной части, если там есть проблемы, а в остальное время кодят веб и приложения
ребята из бэкенда тоже могут залезть в код, узнать, как что работает, некоторые даже пишут простые компоненты, потому что у нас везде typescript. Это происходит, если задача не сложная, а у разработчика есть желание развиваться в фулстак. И так же они могут это делать и на вебе, и на мобильных приложениях
получаем своего рода фулстаков из всех разработчиков, которые хотели бы смотреть за границы своей специализации
Согласен, что «люди-оркестры» выгорают. Мы как раз не ищем таких.
Речь не о том, чтобы один аналитик делал за всех, а о том, чтобы в команде были мыслящие партнёры, которые видят продукт целиком, задают критические вопросы и формулируют гипотезы.
Мы ждём от продуктовых аналитиков опыта в работе с продуктом: эксперименты, метрики, влияние на решения, на бизнес. Это и есть суть продуктовой аналитики. Нет, необязательно быть прекрасным кодером или иметь финансовый опыт, но для получения результатов нужно писать код на SQL, Python и проводить анализ. То, что я описал – это не про человека оркестра, а стандартные требования к продуктовому аналитику.
Хорошая мысль про тандем. Когда роли дополняют друг друга – это прекрасно работает. Я обычно начинаю с другого конца — сначала разбираюсь, зачем вообще тандем нужен и правда ли он решит проблемы команды
на собеседованиях мы не гонимся за количеством. эффективное выполнение задач, которые не нужно решать, сводит ценность приложенных усилий к нулю.
в первую очередь смотрим на мышление: как человек рассуждает, на что обращает внимание, как формулирует гипотезы и проверяет логику решения. навык мышления можно и проще проверять без ИИ, поэтому не вижу никакого двойного стандарта.
навыки владения инструментами (SQL, Python, ИИ) и умение решать типовые задачи тоже важны, но вторичны. мы смотрим на них на первом этапе, а дальше даём два продуктовых кейса без «правильного ответа» – чтобы увидеть, как человек мыслит, структурирует и делает выводы.
если кратко: навык работы с ИИ нужен, без него никуда, но это второй приоритет. Умение мыслить и анализировать самостоятельно – первый. без первого не будет второго.
у нас четыре основных этапа отбора: два технических интервью, встреча с HR и интервью по ценностям. если всё проходит успешно, мы можем попросить контакты коллег для рекомендаций.
алгоритмические задачи (leetcode) у нас есть, но фокус на том как кандидат мыслит, а не на оптимальном решении.
задачки на листочке решать не нужно, но если нужен листочек – можно им пользоваться. Предлагаем простой онлайн редактор для кода.
ИИ просим не пользоваться на собеседованиях.
у нас все аналитики (маркетинговые, продуктовые) пишут код (Python, SQL) для расчетов в исследованиях, экспериментах и так далее. это код не для прода (аналитики – не инженеры), а для вычислений
согласен, что перечисленные практики важны.
мы к ним тоже постепенно приходим, но видим в них не отправную точку, а следствие любопытства.
сначала человек начинает задавать вопросы, спорить, что-то инициировать – и мы помогаем этому импульсу найти форму (в виде аналитической модели, исследования, обзора, доклада, и так далее).
я в своём ответе как раз говорил о том, что мы делаем до этого шага – чтобы это любопытство и инициатива вообще появились. мы стараемся создать среду, где безопасно предлагать, где инициативу не гасят, где руководитель не приходит с готовыми ответами.
привет, спасибо за комментарий! отвечаю:
1.
а) примерно на 70%
б) на 8 — для текущего состояния бизнеса
важный момент: мы как компания не маленькие — можем позволить себе ждать и выбирать нужных кандидатов. но и не настолько большие, чтобы нужно было нанимать постоянно и много.
2. развитие BI и витрин важно, но да, вторично по сравнению с развитием членов команды.
что делаем для этого:
развиваем менеджеров (у нас есть внутренние курсы)
разговариваем и поощряем инициативу (101, сбор ОС)
стараемся приходить с вопросами и проблемами, а не с готовыми решениями
уменьшаем рутину и операционные задачи
если видим, что человек начал приходить с идеями, ответами, инициативами, предложениями — значит это то, что нам нужно)
почему?
у нас получается нанимать людей, которым хорошо в компании и нравится решать задачи продукта. из-за этого и бизнес видит пользу и растёт. статья в том числе про это)
окак, выглядит так, как будто упор на английский язык, нет? с русским так же хорошо работает?
ну вот внизу посоветовали какую-то другую модель, мы еще не пробовали, пока не можем ничего сказать, но затестить можно) если нужен только текст, без сложной углубленной логики - почему нет
просто покаламбурили немного, с кем не бывает... 😅
видели тоже, можно достраивать промпт, что-то в духе "не разбивай текст на строки, если это не обосновано нехваткой места в строке". сотни вариантов, но придется вручную, да)
Привет! Да, конечно пользуемся, но подходим осознанно, потому что переиспользование поднимает ответственность кода и усложняет его поддержку. Всегда используем на уровне core библиотек: api client, тулкит, логгер, аналитика. Стараемся выносить общую бизнес логику в общих частях, вроде чатов или авторизации. На уровне страниц и ui виджетов бизнес логику чаще делим по платформам
мы используем Detox для e2e перед релизами и Detox с кастомным mock сервером для компонентных UI тестов по аналогии, как работает cypress + msw на вебе
привет, прости, немножко задержался с ответом
я думаю, что тут проблема с перерендером в случаях, когда надо использовать маску на инпуте. можно посмотреть в сторону input-mask-ios , либо на стороне кода постараться минимизировать количество ререндеров (менять value через ref, не использовать стейт для значения)
привет, спасибо за вопрос!
проблем стало правда гораздо меньше, но вот наш большой проект переводить на новую архитектуру тяжеловато из-за большого количества зависимостей на внешние библиотеки, из-за различных собственных внутренних обвязок и анимаций. Мы запланировали переход в следующем году, так что нам еще предстоит проверить, всё ли там решено
привет! да, конечно, всё уже работает)
привет! завтра отпишусь и постараюсь ответить на вопрос) забрал
самое главное — результат, а он у нас отличный :)
привет!
объясню, то имел в виду под тем, что все разрабочики за счет стека получились универсальными.
наши ребята из фронтов могут писать мобильные приложения, потому что там тоже реакт. а раз уж залезли - иногда залезают и в нативный код, прокачиваются
ребята из нативных разработчиков остались с нами не все. но, кто остался, обучился разработке на react. И теперь помогают в нативной части, если там есть проблемы, а в остальное время кодят веб и приложения
ребята из бэкенда тоже могут залезть в код, узнать, как что работает, некоторые даже пишут простые компоненты, потому что у нас везде typescript. Это происходит, если задача не сложная, а у разработчика есть желание развиваться в фулстак. И так же они могут это делать и на вебе, и на мобильных приложениях
получаем своего рода фулстаков из всех разработчиков, которые хотели бы смотреть за границы своей специализации