user10398747

user10398747

14 лет в продакт менеджменте. Веду 2 канала в телеграм @startuphunt - тут про стартапы @inspired_pm - тут про управление продуктами
Пикабушник
Дата рождения: 24 июня
110 рейтинг 0 подписчиков 4 подписки 7 постов 0 в горячем

Реальность тех. собеседований в 2025 году (часть 2)

4. Различия в форматах собеседований в стартапах и крупных технологических компаниях

С развитием искусственного интеллекта и растущим скептицизмом в отношении традиционных собеседований по программированию мы наблюдаем растущий разрыв между тем, как проводят собеседования крупные технологические компании и более новые компании.

Традиционные работодатели FAANG в основном остаются приверженными своим существующим форматам, с небольшими корректировками. Как сказал нам один из руководителей отдела подбора персонала FAANG:

«Инерция этих процессов колоссальна. Эти компании выстроили целые рекрутинговые машины вокруг своих текущих процессов, имея многолетние данные калибровки. Они не хотят вносить кардинальные изменения без убедительных доказательств того, что альтернативы будут работать лучше в масштабе».

С организационной точки зрения изменения в процессе собеседования часто курируются руководителями инженерных подразделений, которые предпочли бы дождаться пожара, чем создавать потенциальную проблему при первом же запахе дыма.

Несколько компаний среднего размера перешли к более реалистичным, открытым задачам по кодированию, которые лучше отражают реальную работу. Примерами мест, где используются более реалистичные собеседования, являются Stripe, Coinbase и OpenAI. Вместо того, чтобы решать вопросы LeetCode, кандидаты решают такие проблемы, как:

  • Проектирование механизма запросов

  • Реализация хранилища «ключ-значение»

  • Проектирование базы данных in-memory для обработки транзакций

Стартапы на ранней стадии пошли ещё дальше — они часто заменяют традиционные задачи по программированию на домашние проекты, в которых прямо разрешено использовать инструменты на базе ИИ. Янгшун Тэй, основатель GreatFrontEnd, активно продвигает этот подход на LinkedIn и делится опытом того, как его команда успешно внедрила такую практику, чтобы лучше оценивать реальные навыки решения задач у кандидатов:

«Я пришёл из Big Tech и хорошо знаю недостатки типичного интервью. Поэтому я использую немного другой подход при найме фронтенд-инженеров в GreatFrontEnd:

Никакого LeetCode

Домашнее задание

Домашнее задание — это список дел (что?!)

Оценивается продуктовое мышление

Кандидаты, успешно прошедшие домашнее задание, заранее знают, какие будут вопросы на интервью, и могут спокойно подготовиться

За само участие в интервью предусмотрен бонус (...)

Важно понимать, что такой процесс найма требует больше времени по сравнению со стандартными LeetCode-интервью и плохо масштабируется при большом количестве кандидатов.»

Этот сдвиг в подходе к найму служит двойной цели: он лучше отражает реальные условия работы и одновременно помогает бороться с растущей проблемой мошенничества при оценке кандидатов. Один из основателей AI-стартапа на стадии посевных инвестиций в районе залива (Bay Area), с которым мы поговорили, оценил, что как минимум 20% кандидатов явно жульничали во время традиционных тестов по программированию. Проблема касается не только стартапов: один из близких друзей Эвана, интервьюер в Amazon, признался, что половина из последних десяти кандидатов явно использовали ИИ-инструменты на дополнительных экранах во время формально наблюдаемых оценочных тестов. Встраивая такие инструменты напрямую в процесс оценки, компании адаптируются как к реалиям современной рабочей среды, так и к вызовам, связанным с обеспечением честности этих оценок.

Инновации в подходах к технической оценке сегодня зарождаются в небольших, более гибких компаниях, в то время как крупные технологические корпорации лишь наблюдают со стороны. Это интересный переворот исторической тенденции: в течение последнего десятилетия практики проведения собеседований, разработанные Google и другими техногигантами, постепенно перенимались мелкими компаниями, стремившимися повторить их успех. Теперь всё наоборот! Вопрос лишь в том, когда — и случится ли вообще — работодатели из FAANG адаптируются к этой новой реальности.

Правда в том, что крупные технологические компании вряд ли будут менять процессы найма без ярко выраженных негативных сигналов после интервью — например, значительного количества увольнений, о которых никто не жалеет, и которые можно напрямую связать с ошибками в отборе кандидатов.

Скорее всего, Big Tech ограничится незначительными изменениями, вроде возвращения к очным интервью в краткосрочной перспективе. Они понимают, что текущий процесс собеседований по сути является игрой, но он действительно помогает выявлять тех, кто готов серьёзно вложиться в интенсивную подготовку. К сожалению для кандидатов, готовность преодолевать произвольные алгоритмические задачи хоть немного, но всё же коррелирует с теми качествами, которые присущи успешным инженерам в реальной работе — и этого достаточно, чтобы оправдывать сохранение существующего порядка.

Возникает вопрос: насколько жизнеспособны традиционные подходы к собеседованиям в эпоху больших языковых моделей (LLM)? По мере того как ИИ-инструменты всё лучше справляются с типичными алгоритмическими задачами, используемыми на интервью, их ценность как индикатора квалификации неизбежно снижается. В будущем ни одному инженеру не придётся вручную писать код для задач вроде проверки сбалансированности скобок или обхода бинарного дерева — вместо этого он просто даст правильный запрос ИИ, и тот сгенерирует нужное решение. Компании, которые внедряют более реалистичные, проектно-ориентированные оценки, уже сейчас адаптируются к тому, как на самом деле будет выглядеть инженерная работа в ближайшие годы.

Ясно одно: кандидаты сегодня сталкиваются с раздвоенной реальностью. Чтобы попасть в Big Tech, нужно готовиться к классическим алгоритмическим интервью. Но параллельно важно развивать навыки, которые позволят успешно проходить более открытые, практико-ориентированные оценки в других компаниях.

5. Стратегии подготовки по уровню опыта

Мы обнаружили, что оптимальная стратегия подготовки значительно варьируется в зависимости от уровня опыта, а относительная важность различных компонентов интервью меняется с карьерным ростом. Вот закономерности, которые мы наблюдали:

Для младших инженеров с опытом работы от 0 до 2 лет мы сочли эту подготовку наиболее эффективной:

  • 80% времени — на алгоритмы и задачи по программированию

  • 20% времени — на подготовку к поведенческому интервью (behavioral interview)

Технические требования для младших позиций значительно возросли, и теперь владение базовыми алгоритмами и структурами данных стало обязательным. Успешные кандидаты на junior-уровне, как правило, решают от 150 до 200 задач по программированию разной степени сложности перед интервью.

Прежде всего, ты должен стать сильным разработчиком — всё остальное вторично.

Инженерам среднего уровня с опытом от 2 до 4 лет подходит более сбалансированный подход к подготовке:

  • 50% — задачи по программированию

  • 25% — системный дизайн

  • 25% — подготовка к поведенческому интервью

На этом этапе компании ожидают от кандидатов не только уверенные навыки реализации, но и формирующееся архитектурное мышление. Самые успешные кандидаты среди тех, с кем мы работаем, развивают системный подход к проектированию, сосредотачиваясь на понимании базовых строительных блоков, которые можно комбинировать и адаптировать под конкретные задачи, а не просто заучивать готовые решения.

Для инженеров старшего уровня с опытом от 5 до 8 лет хорошо работает следующая структура подготовки:

  • 50% — системный дизайн

  • 20% — программирование

  • 30% — поведенческие интервью

На этом уровне ключевое отличие — это способность проектировать надёжные и масштабируемые системы, при этом чётко объясняя компромиссы в архитектурных решениях. От senior-инженеров также ожидается, что они умеют работать с неопределённостью: задают уточняющие вопросы, формулируют разумные допущения, если информация неполная.

Самая распространённая ошибка, которую мы наблюдаем у кандидатов на senior-позиции — недооценка подготовки к поведенческому интервью. Это критическая ошибка: на этом уровне компании оценивают не только технические навыки, но и потенциал к лидерству, умение разрешать конфликты и соответствие корпоративной культуре.

Мы видели, как технически сильные кандидаты проваливали интервью или получали понижение уровня только потому, что не смогли убедительно рассказать о своём вкладе, описать, как они влияли на кросс-функциональные команды, или показать осознанность в отношении собственных ошибок и сложностей. Подготовка к поведенческому интервью — это не формальность. Она оказывает существенное влияние на итоговое решение о найме, особенно на senior-уровне и выше.

Инженеры уровня Staff и выше сталкиваются с другим типом вызова:

  • Кодинг — это уже базовое ожидание; ошибка здесь может быстро привести к отказу.

  • 90% отличий между кандидатами определяется по системному дизайну и поведенческим/лидерским аспектам.

На этих позициях компании смотрят далеко за пределы навыков реализации: они оценивают архитектурное видение, кросс-функциональное лидерство и умение общаться на уровне руководства. Успешные кандидаты на Staff+-уровне демонстрируют стратегическое мышление, связывая технические решения с бизнес-результатами во время обсуждения системного дизайна.

Ведущие AI-лаборатории, такие как OpenAI, имеют свои особенности в подходе к найму. Вместо того чтобы делать упор на традиционные лидерские качества, они жёстко отбирают кандидатов по "родословной" и громким достижениям. Явными фаворитами становятся кандидаты из элитных и известных компаний, AI-стартапов, престижных университетов, а также те, у кого есть яркие, легко подающиеся достижения, которые можно эффектно презентовать. Без всего этого кандидатам приходится преодолевать серьёзное сопротивление, даже если они обладают выдающимся техническим уровнем.

Эффективная практика

Стоит признать реальность: процесс технических собеседований превратился в специализированную игру, всё дальше отходящую от повседневной инженерной работы. Это далеко от идеала — но такова сегодняшняя практика. Компании выбрали стандартизированные методы оценки, которые далеко не всегда отражают реальные рабочие задачи, и этот разрыв нередко вызывает разочарование у инженеров.

Хорошей новостью является то, что правила игры общеизвестны. По сути, это «секретное рукопожатие», которому нужно научиться, чтобы попасть в эти компании. Процесс может показаться произвольным, но при должной подготовке ему вполне можно научиться. Любой, кто достаточно предан делу, может освоить эти шаблоны и значительно улучшить свои показатели.

Мы осознаем свою предвзятость; как платформа для подготовки к собеседованиям, мы, очевидно, верим в ценность структурированной практики. Данные говорят сами за себя: кандидаты, которые занимаются осознанной практикой, постоянно превосходят тех, кто этого не делает, независимо от природных способностей или уровня опыта. Закономерности очевидны в тысячах результатов собеседований.

Если вложение в формальные пробные собеседования не соответствует вашим предпочтениям или бюджету, это вполне понятно, и есть множество альтернатив: найдите друга, который работает в вашей целевой компании, познакомьтесь с коллегами в сообществах Reddit или Discord или создайте учебные группы с другими соискателями. Конкретный метод имеет меньшее значение, чем фундаментальный принцип, что собеседование — это навык, который улучшается с практикой, обратной связью и итерацией.

Что точно не работает — это полагать, что повседневная инженерная работа подготовила тебя к интервью. Интервью — это выступление, и оно требует отдельной, целенаправленной подготовки. Умение думать вслух, держать себя под давлением, ясно излагать мысли во время решения задач — всё это навыки, которые развиваются в условиях, приближённых к реальному интервью. Без такой тренировки даже очень сильные инженеры могут не справиться с тем, чтобы показать свой уровень внутри искусственных рамок интервью-процесса.

6. Положительные стороны

Рынок найма в техе в 2025 году кардинально отличается от «золотой лихорадки» 2020–2021 годов. Маятник резко качнулся от «пожалуйста, возьмите наши деньги» к «докажите, что вы того стоите» — и инженеры это ощущают на себе. Давление выросло, конкуренция стала жёстче. Но это не повод сдаваться!

Крупные технологические компании — такие как Amazon, Apple, Microsoft, Google и Meta — в совокупности по-прежнему держат около 40 000 открытых вакансий. Даже те команды внутри этих корпораций, которые формально не расширяются, продолжают нанимать на замещение ушедших сотрудников — несмотря на параллельные волны увольнений.

Сектор искусственного интеллекта продолжает стремительно расти. Компании вроде OpenAI, Anthropic и множество стартапов, работающих над AI-инфраструктурой, активно нанимают. Не стоит поддаваться мрачным прогнозам о скорой замене инженеров. Реальная ситуация с наймом показывает, насколько бизнесу по-прежнему нужны технические специалисты для достижения своих целей. Многие AI-компании предлагают компенсационные пакеты, сравнимые с уровнями 2021 года, особенно для инженеров с релевантной экспертизой или выраженным потенциалом к обучению в смежных с ИИ направлениях.

Инженеры, которые сейчас добиваются успеха, понимают, что современные тех-интервью по сути превратились в отдельный, странный вид спорта — со своими произвольными правилами и специфическими традициями. Они относятся к интервью как к выступлению, а не просто к технической проверке, и тратят время на подготовку соответственно.

Поскольку ИИ продолжает менять то, как выполняется инженерная работа, процессы собеседований также должны будут эволюционировать, поскольку они не могут продолжать проверять навыки, которые ИИ делает устаревшими. Но на данный момент мы застряли в этой неудобной переходной фазе, где вам нужно освоить как старые алгоритмические игры, так и новые, более практичные оценки.

Рискуя констатировать очевидное, в Hello Interview мы видим четкую закономерность: существует сильная корреляция между инвестициями в подготовку и успехом на собеседовании. Кандидаты, которые уделяют время структурированной практике, по-прежнему с большей вероятностью получат несколько предложений, даже в этой более избирательной среде.

Игра может быть сложнее, но, по крайней мере, свод правил публичен. При достаточной осознанной практике и правильной стратегии подготовки для вашего уровня вы все равно можете выйти победителем, даже на этом более жестком рынке.

Выводы

Снова Gergely.

Большое спасибо Эвану и Стефану за то, что они обобщили то, что они видят на рынке технологий. Они собрали большую часть этих идей, взаимодействуя с разработчиками с помощью Hello Interview , сервиса пробных интервью и подготовки к интервью, соучредителями которого они являются.

Вот несколько интересных мыслей, над которыми я размышляю:

Более жёсткий рынок труда стал ожидаемым последствием окончания эпохи нулевых процентных ставок. Год назад мы анализировали, что это изменение будет означать для инженеров. Один из главных выводов тогда — готовиться к более сложной ситуации на рынке: рост конкуренции, меньше возможностей «попробовать разные варианты», особенно тяжело приходится инженерным руководителям. Это подтверждают и наблюдения Эвана и Стефана, которые работают на передовой найма. В каком-то смысле, поскольку такой эффект был предсказуем, его проще принять как одну из причин текущих трудностей с поиском работы.

ИИ сейчас на пике интереса, и ведущие компании в этой сфере уделяют большое внимание «родословной» кандидатов. Немного неожиданно было узнать от Эвана и Стефана, насколько сильно такие компании, как OpenAI, Anthropic и другие крупные игроки, отбирают кандидатов по предыдущим местам работы и достижениями. Хотя, если подумать, в этом нет ничего странного — когда у тебя тысячи заявок, почему бы не выбирать из самых громких имён в индустрии?

Это ещё раз напоминает: даже если ты уже работаешь в сфере AI, попасть в топ-компанию из менее известной — почти невозможно без весомой репутации в отрасли. Если цель — однажды попасть в такую компанию, стоит готовиться к карьерному пути в несколько шагов: начать с менее известных мест, заниматься реальной AI-разработкой, накапливать опыт и переходить в более узнаваемые компании. И только потом — возможно — появится шанс войти в число избранных.

Устройство на работу теперь требует гораздо больше времени и усилий. Разработчики всё чаще жалуются на то, насколько трудоёмка подготовка к тех-интервью. Если речь идёт о компаниях с алгоритмическими собеседованиями в духе Leetcode — недовольство вызывает объём подготовки. Если же формат предполагает объёмное домашнее задание — раздражает само выполнение задания, которое может занимать часы, а то и дни.

Как компетентный инженер, ты, скорее всего, считаешь, что работодатель должен и так понимать, что ты умеешь делать свою работу. И логично было бы просто поверить в твой опыт, пропустить всю эту бессмысленную оценку и сразу предложить оффер, верно?

Но с точки зрения менеджера по найму, новый сотрудник — это всегда риск. И мало что хуже, чем найм, который не оправдал себя — из-за нехватки навыков, мотивации или по любой другой причине. Интервью как раз и нужны для того, чтобы проверить, подходит ли кандидат по уровню и действительно ли он хочет эту работу.

Если раньше, в 2020–2022 годах, рынок был на стороне кандидатов, то сейчас — это уже рынок работодателей. В такой ситуации почти наверняка придётся вкладывать больше времени в подготовку к интервью и прохождение самих процессов. Хорошая новость в том, что такая подготовка не пропадает зря. Форматы интервью не меняются слишком быстро, и наработанные навыки будут полезны в течение долгого времени.

Ожидания растут и будут расти. В Uber мой тогдашний менеджер сказал мне, что ожидания производительности в Uber шли только в одну сторону для одного и того же уровня : вверх. Это было связано с тем, что бизнес быстро рос, и от любого нового сотрудника ожидалось поднять планку. Это означало, что со временем ожидания «нормы» для любого уровня карьеры продолжали расти. Через некоторое время это стало казаться естественным, но было странно к этому приспосабливаться!

Я чувствую, что мы наблюдаем нечто подобное в более широкой отрасли сегодня. Из-за большого количества квалифицированных, способных инженеров, претендующих на работу, ожидания растут на всех уровнях карьеры, и именно поэтому понижение уровня становится более распространенным.

Если вы получили предложение о понижении уровня: прежде всего, поздравляю с получением предложения! На этом рынке труда это само по себе достижение. Полезно принять во внимание текущую ситуацию на рынке труда, прежде чем слишком разочаровываться в таком результате. И если вы еще не получили предложение, знайте, что рынок сейчас жестче, чем был за последнее десятилетие, поэтому поиск работы занимает больше времени, чем раньше.

Если вы в настоящее время находитесь на рынке труда или проходите собеседования и заметили какие-либо изменения в процессах подбора персонала, пожалуйста, поделитесь ими в комментариях.

Показать полностью
1

Реальность тех. собеседований в 2025 году

Процессы собеседований меняются на тех. рынке, который одновременно и остывает, и разогревается. В некоторых секторах идёт сокращение, в других — бурный рост. В такой двойственной реальности важно понимать, как адаптироваться. Глубокое исследование с бывшим штатным инженером/руководителем в разработке компании Meta Эваном Кингом и Стефаном Маем

Широко известно, что рынок найма в техе сегодня заметно охладился по сравнению с 2020–2022 годами. Количество вакансий для инженеров-программистов снизилось во всех крупных регионах, а доля полностью удалённых позиций продолжает постепенно сокращаться. В то же время, по другим метрикам видно, что рынок начинает восстанавливаться — по крайней мере, для инженеров старшего уровня. Об этом говорилось в прошлом месяце в статье "Состояние рынка найма стартапов и scaleup-компаний глазами рекрутеров". Всё это создаёт ситуацию нестабильности и неопределённости, через которую предстоит пройти и кандидатам, и работодателям.

Эта статья — попытка прояснить, как меняются технические собеседования, через призму того, что видят сами инженеры, проходящие интервью. Чтобы разобраться в этом, я обратился к Эвану Кингу и Стефану Маю, сооснователям стартапа по подготовке к интервью — Hello Interview. До запуска своего проекта Эван четыре года работал Staff Engineer в Meta, а Стефан — шесть лет был менеджером инженеров в Amazon и затем старшим менеджером инженеров в Meta. Оба провели сотни собеседований, причём Стефан также выступал в роли нанимающего менеджера. С момента запуска Hello Interview они помогли тысячам инженеров подготовиться к интервью и собрали большой объём информации о текущем состоянии рынка и ожиданиях работодателей.

Я связался с ними после прочтения их практичного, свежего анализа собеседований системному дизайну, чтобы узнать, как разработчики проходят собеседования в стартапах и Big Tech в нынешних условиях, особенно по сравнению с тем, что было несколько лет назад. Сегодня мы рассмотрим:

  1. Новая реальность найма технических специалистов . Восстанавливающийся рынок все еще значительно ниже пика 2021–2022 годов.

  2. Анализ рынка найма в сфере технологий . Искусственный интеллект (ИИ) и связанные с ним секторы популярны, а вот фронтенд/бэкенд/мобильные приложения — нет. Новичкам сложнее, чем опытным инженерам.

  3. Изменения в процессе собеседования. Форматы собеседований по DSA и системному дизайну остались прежними, но стали более требовательными. Снижение уровня стало более распространенным явлением, а подбор команды незаметно превратился в еще одно препятствие, которое необходимо преодолеть.

  4. Форматы интервью различаются между стартапами и Big Tech . Стартапы используют более практичные интервью и инструменты ИИ, в то время как Big Tech кажутся менее гибкими в изменении подхода.

  5. Стратегии подготовки на основе опыта. Советы для начального, среднего, старшего уровня, персонала+технических специалистов и для EM.

  6. Положительные моменты. В крупных технологических компаниях растет число сотрудников, наблюдается бум вакансий, связанных с искусственным интеллектом, а план проведения собеседований стал общедоступным.

На этом слово предоставляется Эвану и Стефану:


1. Новая реальность найма технических специалистов

Три года назад, если вы были компетентным инженером-программистом с 3+ годами опыта, рекрутеры, вероятно, заваливали ваш почтовый ящик предложениями. Компании боролись за инженерные таланты, предлагали кандидатам необычайные компенсационные пакеты, а в некоторых случаях даже закрывали глаза на плохие результаты собеседований, чтобы быстрее нанять сотрудников. Ажиотаж найма в сфере технологий в 2020–2021 годах был исключительным; сейчас многие вспоминают этот период со смесью ностальгии и недоверия.

Если перенестись в 2025 год, то ландшафт изменится кардинально. Будучи соучредителями HelloInterview.com, мы наблюдали за этими изменениями в первом ряду, наблюдая за десятками тысяч инженерных собеседований в компаниях всех размеров. В этой статье мы хотим рассказать вам о том, как будут проходить собеседования в 2025 году, используя реальный опыт кандидатов, проходящих собеседования сегодня.

Мы заметили, что объемы найма в Big Tech выросли примерно на 40% в годовом исчислении. Эти данные получены от кандидатов, которые в настоящее время работают в компаниях на поздней стадии, из которых подавляющее большинство использует нашу платформу для подготовки к собеседованиям, которые они уже запланировали. Это дает надежный показатель общих тенденций найма в сфере технологий, поскольку у кандидатов на нашей платформе есть непосредственные, конкретные даты собеседований. Рост числа кандидатов, получающих больше собеседований, говорит о том, что худшая часть технологической зимы 2022–2023 годов уже позади, и что есть более привлекательные вакансии, к которым стоит готовиться. Тем не менее, мы работаем на принципиально ином рынке с новыми правилами, ожиданиями и вызовами.

Цифра восстановления в 40% — это только часть истории. Да, в целом найм технических специалистов медленно возвращается, но это выборочное стратегическое восстановление, которое заставляет некоторых квалифицированных инженеров бороться с процессами, которые теперь стали более требовательными и менее снисходительными. Компании, которые когда-то отчаянно пытались заполнить вакансии, теперь действуют методично и осторожно, отдавая приоритет точности в решениях о найме, а не скорости и объему.

То, что мы наблюдаем, — это не просто коррекция рынка; это тонкий, но существенный сдвиг в стандартах оценки. Хотя основная структура собеседований в Big Tech остается в основном неизменной, планка сместилась примерно на одно стандартное отклонение выше по всем направлениям, и результаты, которые обеспечили бы оффер в 2021 году, сегодня могут даже не пройти этап отбора.

2. Анализ рынка найма технических специалистов

Вот наш взгляд на текущую ситуацию на рынке труда.

Избирательное восстановление

Судя по количественным показателям, наем сотрудников в сфере технологий находится на твердой восходящей траектории. Отслеживание трендов TrueUp.io показывает, что количество вакансий в сфере технологий выросло с минимального уровня в 163 000 в 2023 году до примерно 230 000 в настоящее время, что составляет примерно 41 %.

Реальность тех. собеседований в 2025 году Разработка, Собеседование, Программирование, Работа HR, Длиннопост

Количество открытых вакансий в сфере технологий в технологических стартапах, технологических единорогах и публичных технологических компаниях. Источник: TrueUp

Рост числа вакансий на 42% соответствует тому, что мы наблюдали внутри компании по показателям использования HelloInterview и объему пробных собеседований, когда мы корректировали данные по кандидатам, у которых запланированы собеседования.

Однако до лихорадочных высот 2020-2022 годов нам еще далеко. Тогда пик открытых позиций составлял почти 500 000. Нынешнее восстановление, хотя и значительное, вернуло нас лишь к 46 % от того пика.

В отличие от предыдущих циклов найма на работу в сфере технологий, когда прилив поднимал все лодки, сегодняшний рынок характеризуется крайней избирательностью. Компании стали гораздо более разборчивы в выборе места для размещения персонала, причем различия в возможностях зависят от специализации, уровня опыта и престижа бывших работодателей.Специализация домена

Инженеры в определенных областях специализации видят много актуальных вакансий, например:

  • Инфраструктура ИИ

  • Machine learning

  • Разработка приложений генеративного ИИ

Эти сферы найма напоминают пик 2021 года: часто с множественными предложениями, агрессивной компенсацией и ускоренными процессами собеседований.

Например, инженер из Bay Area, специализирующийся на инфраструктуре ИИ в Google, недавно получил конкурирующее предложение от команды по инфраструктуре ИИ Meta, общая компенсация которого превышала 1 миллион долларов. Ранее в Google такие цифры обычно резервировались для руководящих должностей. Но получение большой прибавки к зарплате при смене компании, при этом оставаясь на том же уровне, не является единичным случаем; мы видим аналогичные по размеру компенсационные пакеты для специалистов по высокопроизводительным вычислениям, проектированию систем ML и специалистов по ответственной разработке ИИ .

Инженеры в «основных (core)» областях видят меньше возможностей. «Основные области» относятся к фронтенду, бэкенд-сервисам, мобильной разработке и аналогичным областям. Стартапы более поздних стадий, которые ранее содержали несколько команд в этих областях, объединились с более мощными full-stack инженерами. Сосредоточение на полном цикле приводит к снижению общей численности персонала, меньшему количеству вакансий и более избирательному процессу найма. Мы видим, что кандидатам с сильным опытом в этих областях часто требуется много времени, чтобы получить должность, и когда они получают предложение, рост компенсации редко превышает их текущий доход.
Примечание от Gergely: ранее мы видели, как нативные мобильные инженеры сталкиваются с более жестким рынком труда , и что переход full-stack является разумной стратегией для того, чтобы быть более трудоспособным..

Старшие инженеры все еще могут привлекать множество предложений, особенно те, у кого есть опыт, непосредственно связанный с наймом компаний. Это может быть глубокая экспертиза в предметной области (например, работа в области инфраструктуры при собеседовании для инфраструктурных команд, работа в области финансов при собеседовании в FinTech и т. д.) или это может быть глубокая экспертиза в области технологий, которая важна для работодателя. Между тем инженеры с менее универсальными навыками сталкиваются с нелегкой задачей. Узкие навыки часто формируются в результате работы в таких компаниях, как Google или Meta, где люди специализируются на собственных системах, инструментах и технологиях, которых не существует на широком рынке.

Разница в уровне опыта

Текущий рынок также сильно разделен по этапам карьеры, что создает кардинально разные реалии для инженеров в зависимости от опыта:

Джуны и выпускники сталкиваются с самой большой проблемой. Мы поговорили с соискателем работы из Индии, который окончил IIT — самый престижный университет компьютерных наук в стране. Они поделились тщательно поддерживаемой таблицей своего поиска работы:

  • 6 месяцев поиска

  • 100 компаний, с которыми удалось связаться; все они нанимают сотрудников из IIT

  • 4 начальных интервью

  • Ноль предложений

Компании, которые когда-то поддерживали активные программы набора в университеты, резко сократили их, что вызывает беспокойство, поскольку это может привести к нехватке опыта, которая будет влиять на отрасль в течение многих лет, и может проявиться в «пропавшем поколении» инженеров. Это может создать общеотраслевой дефицит талантливых специалистов раннего и среднего возраста, что может привести к торможению инноваций, поскольку все меньше свежих взглядов приходят в отрасль и бросают вызов устоявшейся практике.

Мидлы: больше циклов собеседований до предложения. Под инженерами среднего звена мы подразумеваем профессионалов с 3-4 годами опыта работы в уважаемых компаниях. Кандидаты с таким опытом, как правило, добиваются собеседований, но количество циклов собеседований, которые они проходят, чтобы получить предложение, существенно возросло.

Например, успешный инженер среднего звена из Bay Area с 4-летним опытом работы в Amazon прошел одиннадцать полных циклов собеседований в различных масштабируемых и технологических компаниях, прежде чем получил свое первое — и единственное — предложение!

Старшие и ведущие инженеры с востребованными специальностями: премиальная оплата и множество предложений. Компании готовы платить значительно выше рыночной ставки за подтвержденный опыт в области искусственного интеллекта, инфраструктуры и безопасности. У таких кандидатов часто есть возможность выбирать между конкурирующими предложениями и вести агрессивные переговоры.

Один из недавних подопечных Эвана — главный SDE, работающий в Bay Area в одной из групп Microsoft по инфраструктуре ИИ. Этот главный SDE получил конкурирующие предложения от NVIDIA, Snowflake, Meta и других мест — и все это в течение одного месяца!

Менеджеры инженеров сталкиваются с жестким рынком . В 2022–2023 годах в сфере технологий прошла масштабная организационная реструктуризация, в результате которой были ликвидированы целые уровни управления , и с тех пор компании не спешили восстанавливать эти должности. В результате многие квалифицированные инженерные руководители теперь конкурируют за значительно сокращенный пул возможностей. Усиление конкуренции изменило стандарты найма.

Технические способности, которые раньше игнорировались менеджерами, теперь тщательно оцениваются, а навыки проектирования систем также становятся непререкаемыми. Раньше менеджеров часто нанимали в первую очередь из-за их лидерских качеств, но сегодня им нужно доказать лидерские качества, а также быть практическими специалистами в области технологий, разработки и проектирования программного обеспечения.

Приоритеты в руководящих ролях также кардинально изменились. Многие технологические компании ранее фокусировались на навыках работы в крупных организациях, чтобы выстроить согласованность в больших командах. Сегодня эти компании ищут старших руководителей, которые могут сосредоточиться на исполнении (execution) и поддерживать более высокий уровень руководства; они обычно не ищут старших руководителей, которые хотят оставаться на высоком уровне, заинтересованные только в управлении кораблем.

Этот переход к тому, что от руководителей инженерных отделов ожидают практического участия, подпитывает давние дебаты о различии между руководителями инженерных отделов и техлидами. В конце концов, сегодняшние руководители инженерных отделов ужасно похожи на вчерашних техлидов! Это изменение меняет то, чего компании ожидают от своих руководителей инженерных отделов.

3. Изменения в процессе собеседования

Собеседования в сфере технологий меняются, и ниже приведены самые значительные изменения, которые мы заметили за последние несколько лет.

Интервью DSA: повышенная техническая планка

С одной стороны, фундаментальная структура технических интервью радикально не изменилась. С другой стороны, ожидания стали значительно более высокими. Компании просто устанавливают более высокий стандарт того, что представляет собой проходной результат.

На собеседованиях по структуре данных и алгоритмам (DSA) инженеры сталкиваются с заметно более сложными проблемами на каждом этапе процесса. Один старший инженер проходил собеседование в Google в 2021 году и сделал это снова в прошлом году. Они рассказали нам:

«Раньше я думал, что «сложные» задачи LeetCode никогда не задаются в Google. Теперь [в 2024 году] они, похоже, стали нормой».

Помимо чистой сложности, мы видим больше акцента на полноте внедрения. Интервьюеры теперь обычно ожидают такие вещи, как:

  • правильная обработка ошибок

  • надежная проверка входных данных

  • чистый код

  • …все в тех же временных рамках, что и раньше.

У вас не будет причин проходить собеседование с тем, кто не все полностью правильно понял. Такова мрачная реальность того, что происходит, когда в списке кандидатов на собеседование очень много квалифицированных специалистов.

Собеседования по системному дизайну: более высокие ожидания

Собеседования по системному дизайну претерпели столь же драматический подъем. Кандидаты на руководящие должности, с которыми мы общаемся, сообщают, что от них ожидают демонстрации знакомства с современными концепциями распределенных систем, которые ранее могли быть ожидаемы только на уровне персонала.

Специализированные знания даже проникли в стандартные собеседования. Например, геопространственное индексирование когда-то считалось узкоспециализированным, но теперь стало обычным явлением в популярных вопросах по проектированию систем, таких как «найти друзей поблизости», приложениях типа Yelp или платформах совместного использования поездок, таких как Uber. Теперь мы советуем кандидатам всех уровней иметь хотя бы базовые знания о таких концепциях, как геохеширование и пространственные структуры данных (например, quadtrees или R-trees) — как бы глупо это ни звучало. Те же тенденции применимы и к DSA: больше кандидатов, больше конкуренции, более высокая планка для найма.

Один кандидат на должность инженера, с которым мы работали, действительно выделялся. Он проработал в Google в Сиэтле почти 15 лет и впервые с тех пор вернулся на рынок. Он был ошеломлен ожиданиями на современных собеседованиях по сравнению с тем, что было, когда он присоединился к Google. Как человек, никогда ранее не работавший с системами обработки потоков, он был разочарован тем, что компании, в которых он проходил собеседование, ожидали от него глубокого знакомства с такими понятиями, как семантика «точно в одно мгновение» (exactly-once semantics), методы оконной обработки (windowing techniques) и алгоритмы водяных знаков (watermarking algorithms). Он сказал нам:

«Я создавал и поддерживал критически важную инфраструктуру более десяти лет, но внезапно от меня стали требовать специальных знаний в областях, совершенно не связанных с моей специализацией. Это просто раздражает».

Легко сопереживать. В то же время легко увидеть, как роскошь выбора кандидатов приводит к этому. Этот рост технических ожиданий не является произвольным; при сокращении объемов найма компании могут позволить себе быть более избирательными, и многие специально ищут инженеров, которые могут внести вклад в более широкий спектр проблем. Инженеры с глубокой, но узкой специализацией имеют меньше возможностей в этой среде.

Понижение уровня

Похоже, понижение уровня — это новая тенденция. С ростом планки найма и текущей рыночной конъюнктурой мы видим, что кандидаты регулярно получают предложения на уровень ниже их текущей должности, особенно на руководящих должностях и на уровне персонала.

В одном случае Стефан работал с кандидатом в Meta, который позже успешно прошел собеседование на руководящую должность, но предложение было отозвано, и вместо этого ему предложили должность среднего уровня. Это понижение уровня было связано с новой политикой, требующей от кандидатов иметь не менее шести лет опыта для руководящих должностей. Лично мне очень неприятно видеть, как компании подобным образом принуждают таланты. - когда компании вот так заставляют талантливых людей работать. Кандидат в итоге принял предложение, не имея возможности получить более подходящий вариант.

Эта тенденция особенно выражена среди инженеров уровня Staff: многим из них предлагают позиции уровня Senior, даже если они соответствуют, но не превосходят явно требования уровня Staff. Компании, учитывая снижение конкуренции за таланты, начали применять более жёсткую политику грейдов (левелинга). В итоге многие кандидаты соглашаются на предложения ниже своего текущего уровня (например, Staff соглашается на Senior), поскольку потратили месяцы на поиски работы.

Долгосрочные карьерные последствия этого значительны, так как часто требуется 2-3 года, чтобы вернуться на прежний уровень. Несмотря на это влияние на траекторию карьеры, мы видим, что процент принятия предложений c понижением уровня значительно увеличивается, поскольку кандидаты отдают приоритет стабильности на неопределенном рынке.

Эволюция командного матча

Возможно, самым значительным структурным изменением в процессе собеседования стала эволюция подбора команды. Это процесс, популярный сейчас в Meta и Google, когда кандидаты сначала проходят собеседование, но не получают предложения до тех пор, пока не подберут себе команду.

Такой подход к подбору команды получил более широкое распространение в крупных технологических компаниях, но с несколько неприятным нюансом: он все чаще работает как дополнительный фильтр, а не на благо кандидата.

По нашим наблюдениям, подбор команды представляет собой новый набор «собеседований» с менеджерами по персоналу, которые должны пройти кандидаты. Это позиционируется как процесс взаимного отбора, но на деле становится еще одним препятствием, которое кандидаты должны преодолеть, прежде чем получить предложение.

Meta в частности пересмотрела свой процесс найма в 2024 году, исключив большинство аспектов своей давней программы «учебного лагеря», в которой новые сотрудники сначала присоединялись к компании, а затем находили свою команду во время учебного лагеря. Вместо этого они внедрили систему подбора команды, которая требует от кандидатов обеспечить соответствие команде, прежде чем получить окончательное предложение.

Результаты оказались проблематичными для многих кандидатов. Один staff инженер, с которым мы работали, прошел все технические раунды в Meta с сильными и положительными отзывами, четыре месяца простоял в ожидании командного матча. Что еще хуже, к тому времени, когда командный матч завершился, все их конкурирующие предложения уже были просрочены!

Когда совпадение, наконец, состоялось, предложение оказалось значительно ниже первоначальных ожиданий, а возможности для переговоров в отсутствие альтернатив практически отсутствовали. Мы видим, что в последнее время в Meta, похоже, удалось устранить отставание в подборе команды, но ожидание в течение многих месяцев остается обычным явлением, особенно на более конкурентных рынках, таких как Нью-Йорк.

Действительно, некоторые компании, похоже, используют задержки в подборе команды стратегически как тактику переговоров. Между тем, процессы подбора команды трансформировались из предоставления кандидатам вариантов в дополнительные уровни проверки, где квалифицированные кандидаты часто оказываются отсеянными или в подвешенном состоянии.

Подбор команды превратился в фактическое второе собеседование, несмотря на попытки компаний представить его иначе. Из наших бесед с менеджерами по подбору персонала мы узнали, что обычно они проводят собеседование с десятью кандидатами на одну должность. Эти менеджеры настоятельно рекомендуют кандидатам тщательно готовиться к этому этапу и адаптировать свои презентации специально для команды, в которую они хотят попасть.

Стефан советует кандидатам планировать этот этап и использовать его в своих интересах. Действительно, процесс подбора команды медленный, но это может создать возможность синхронизировать предложения, запланировав собеседования без подбора команды на более позднее время. Наличие нескольких предложений дает решающее преимущество в переговорах.


Продолжение в части 2. (из-за ограничений Pikabu не влезло)

Показать полностью 1
3

Yahoo - давно забытый гигант, пытающийся вернуть былую славу

На днях появилась занятная новость, Google могут заставить продать Chrome. И вот среди потенциальных покупателей вдруг всплыло имя Yahoo. Реакция в сети была примерно такая: "Ого, а они вообще ещё живы?" Спойлер: живы! И, что ещё интереснее, Yahoo переживает некий "ренессанс", до былой славы пока далеко, но в родной Америке они по-прежнему большие ребята. По трафику новостей №1, в спорте №2, в email №2, а в финансах снова №1. 8 из 10! американцев хотя бы раз в месяц заходят на сервисы Yahoo. Неплохо для "призрака прошлого" 👻.

Немного истории. Yahoo появилась в 1994 году, когда многие из нас даже не знали, что такое интернет. На пике капитализация компании превышала 125 млрд. $, а Google им в своё время предлагали купить себя за... 1 млн. $. Отказались. А ведь мы могли Яхить, а не Гуглить. Тем интереснее возможность текущей покупки, тут явно будет сумма на несколько порядков выше.

Потом долго были на вершине, и началось стремительное падение. Ошибок было много: неудачные покупки вроде Tumblr, упущенные тренды вроде мобильных приложений, бесконечная чехарда с руководителями... В итоге Yahoo в 2017 году продали Verizon за символические 4,5 миллиарда долларов.

И вот теперь - вторая молодость. Новый CEO Джим Ланзон в недавнем интервью рассказал, что, когда он пришёл, каждый продукт Yahoo требовал апгрейда. Аудитория огромная, но всё выглядело устаревшим, а монетизация слабой.

Что они делают сейчас:

- Сокращение штата, закрытие старых рекламных платформ.

- Новые версии всех ключевых продуктов (новости, спорт, финансы, почта).

- Найм новых лидеров.

- Развитие сильных направлений и внедрение AI-решений.

- Ищут новые источники дохода помимо классической рекламы.

По сути, Yahoo снова строят компанию внутри старого бренда.

В современном интернете Yahoo воспринимается как "винтаж", а конкуренция за внимание пользователей безумная. Тем не менее, если им удастся превратить этот "камбэк" в устойчивый рост, Yahoo точно попадёт в учебники по бизнесу, как из один примеров перезапуска 💪

P.S. Про другие интересные стартапы можно почитать на моем канале StartupHunt

Показать полностью
1

Прыжок веры (Leap of Faith)

Прыжок веры (Leap of Faith) Openai, ChatGPT, Космос, Видео, YouTube, Длиннопост

Прыжок веры

Послушал интервью c CPO OpenAI (очень рекомендую), мне понравилась его мысль, что при создании продуктов на базе LLM нужно исходить не из текущих возможностей, а предполагать, что существующие ограничения будут преодолены через 3-6 месяцев. Такой подход может показаться рискованным, но именно он позволяет создавать прорывные решения.

Наверно потому-что сегодня день космонавтики, эта идея напомнила мне один из эпизодов романа «Тёмный лес» Лю Цысиня, который я неоднократно многим рекомендовал

В книге, когда человечество сталкивается с угрозой вторжения инопланетян, перед одной из научных групп встаёт задача - как отправить человека на "переговоры". Все расчёты показывают, что это невозможно из-за колоссальных энергозатрат. Но руководитель проекта делает радикальный шаг - отправляет в космос не человека, а только его мозг, надеясь, что инопланетяне обладают достаточными технологиями, чтобы его расшифровать и восстановить сознание и в итоге это сработало.

По сути он совершает тот самый leap of faith - вера в то, что за пределами наших знаний и возможностей есть нечто, что поможет нам преодолеть любые ограничения. При создании новых продуктов часто приходится делать такие прыжки, данных мало, или нет времени на их сбор, что-то новое придумывается или еще что-то.

Сегодня хочется вам пожелать не бояться делать такие прыжки, люди первыми полетевшие в космос, столько их сделали, и все у них получилось и у вас получится. 🙂

С Днём космонавтики! 🚀

Показать полностью 1 1
1

Полное руководство по контрпродуктивности разработчиков

На сцену выходит контрпродуктивность разработчиков.

Продуктивные разработчики тратят больше времени и энергии на деятельность с высокой отдачей. Контрпродуктивные разработчики тратят больше времени и энергии на деятельность с низкой или отрицательной отдачей. Этот перекос часто лишь в незначительной степени поддается контролю (а иногда и полностью выходит из-под их контроля). Это объясняет, почему одни и те же разработчики в разных условиях могут быть гораздо более (или менее) продуктивными.

Полное руководство по контрпродуктивности разработчиков Разработка, Разработчики, Управление людьми, Программирование, Эффективность, Telegram (ссылка), Длиннопост

Этот пост о том, куда уходит время/энергия. Да, индивидуальные знания, навыки, мотивация и привычки имеют значение. Но в большинстве организаций эти вещи меркнут по сравнению с ежедневными задачами и окружением разработчиков. Вместо того чтобы измерять производительность отдельных разработчиков, лучше сосредоточиться на устранении известных источников низкой/отрицательной отдачи. Возможно, когда вы возьмете эти вещи под контроль, вы сможете начать фокусироваться на «производительности» команды.

Действия для вашей команды:

В течение следующих двух недель отслеживайте, когда ваше время попадает в эти области.

Действия для руководителей:

Где вы можете сдвинуть время, затрачиваемое на эти области, в сторону более значимых областей?

Примечание: Для краткости я использовал «потраченное время» вместо «потраченного времени и энергии». Это различие важно, поскольку в течение дня у нас не одинаковый уровень энергии. Предположим, что я имею в виду «потраченное время и энергию».

Реактивная, незапланированная работа

  • Время, потраченное на реактивную, незапланированную работу, которая устраняет только самые неотложные проблемы. Сюда относятся незапланированные сбои в системе, инциденты безопасности или другие чрезвычайные ситуации, которые можно было бы предотвратить с помощью лучшего планирования или мониторинга.

Такое ощущение, что я целыми днями тушу пожары. Вместо того чтобы писать код, я играю в "ударь-крота" с системными проблемами.

Переключение контекста и стартовые затраты

  • Время, потраченное на переключение контекста и «стартовые затраты» на переход от одной задачи к другой, настройку и сбор необходимых вещей для выполнения работы.

  • Время, потраченное на освоение новых частей кода.

  • Время, потраченное на то, чтобы сориентироваться в задачах, над которыми вы работали, но приостановили работу.

  • Время, потраченное на то, чтобы «войти в курс дела» после долгого и утомительного совещания.

Как только я вхожу в зону, мне приходится переключаться на другую задачу. У меня уходит еще полчаса на то, чтобы вернуться к тому, на чем я остановился.

Каждый раз, когда мне приходится переключать контекст, я словно начинаю свой день заново. Это так выматывает.

Нет, у меня нет «секунды». Потому что секунда превращается в полчаса.

Административная работа и работа по соблюдению нормативных требований, не приносящая ценности

  • Время, потраченное на административную работу, которая не имеет прямой ценности для клиентов или команды.

  • Время, потраченное на получение разрешений на использование определенных инструментов (или на то, чтобы обойтись менее эффективными инструментами в это время, или когда вы вообще отказываетесь от них).

  • Время, потраченное на выполнение требований, которые не позволяют эффективно снизить риск для клиентов или бизнеса.

  • Время, потраченное на выполнение глобальных обязательных процессов без возможности адаптировать их к местным особенностям.

Сегодня я потратил три часа на заполнение форм, чтобы получить доступ к инструменту, который является стандартным для моей работы.

Неэффективное планирование

  • Время, потраченное на оценку, составление спецификаций, обсуждение и презентацию концепций и работ до «последнего ответственного момента». Часто это часть деятельности по планированию, которая в значительной степени носит исполнительный характер. Написание спецификаций и предложений и отсутствие ценных или совместных доработок идей.

  • Время, потраченное на неестественное или неэффективное разделение работы на части для планирования спринта, сгорания, метрик спринта и т. д. Добавление бесполезных концепций работы поверх реальной работы.

У нас было двухчасовое совещание по поводу функции, которая не будет создана еще полгода. Какая пустая трата времени.

Мы потратили недели на планирование, а теперь требования изменились. Все эти усилия кажутся бессмысленными.

Мы вообще ничего не планировали и просто начали кодить. Теперь мы несем ответственность за это.

Издержки управления зависимостями

  • Время, потраченное на координацию и управление зависимостями, которые можно было бы спокойно устранить.

  • Время, потраченное на ожидание результатов от других команд, которые отстают от графика, что приводит к задержкам в вашей работе. Теоретически вы можете выполнять и другую работу, но зачастую она не имеет высокой ценности.

  • Время, потраченное на совещания и обсуждения для согласования с другими командами, когда более упорядоченный процесс коммуникации (или менее структурированный, более встроенный) мог бы быть эффективным.

Мне кажется, что половина моей работы заключается в том, чтобы гоняться за новостями от других команд. Почему мы не можем просто иметь четкий план и придерживаться его?

Мы постоянно ждем другую команду. Такое ощущение, что успех нашего проекта не зависит от нас.

Неэффективные совещания и коммуникации

  • Время, потраченное на неэффективную коммуникацию, неэффективные встречи, синхронные встречи, которые должны быть асинхронными, и асинхронные встречи, которые должны быть синхронными. Это включает в себя обработку « зашумленной» информации, где сигнал был потерян.

  • Время, проведенное на совещаниях и других мероприятиях, где то, что должно быть сказано, не было сказано из-за низкой психологической безопасности, осуждения, страха возмездия и необходимости многократно повторять эти действия.

  • Время, потраченное на повторение одной и той же информации для разных аудиторий одним и тем же способом. Мы ожидаем, что информация будет переконтекстуализирована для разных аудиторий, но если это одна и та же информация, то это контрпродуктивно.

  • Время, потраченное на сканирование сообщений на предмет актуальности и « наверстывание» информации.

Мы только что провели часовую встречу, которая вполне могла бы обойтись электронной почтой. Теперь весь мой день насмарку.

Мы продолжаем проводить эти встречи, но никто не высказывается, потому что боится критики. Это бессмысленно.

Мы пытались решить этот сложный вопрос с помощью электронной почты и в итоге не поняли друг друга. Нужно было быстро созвониться.

Избыточный инструктаж и ввод в курс дела для руководителя

  • Время, потраченное на инструктаж и ввод в курс дела руководителей, потому что они слишком заняты, чтобы принимать непосредственное участие в работе.

  • Время, потраченное на то, чтобы вернуть людей в курс дела или информировать их о ходе работы, потому что они были слишком заняты, чтобы продолжать участвовать в происходящем.

Мой руководитель настолько не в курсе дел, что мне приходится тратить несколько часов каждую неделю на то, чтобы его просветить.

Я проинформировал своего руководителя на прошлой неделе, а сегодня он задал те же вопросы. Они вообще слушают?

Поиск консенсуса и задержка принятия решений

  • Время, потраченное на поиск консенсуса среди большой группы людей, когда решения можно было принять на месте.

  • Время, потраченное на принятие поспешных решений на местах, которые можно было бы лучше принять при участии еще нескольких человек. Принятие ключевых решений без соответствующей поддержки и информации..

  • Время, потраченное на адаптацию к быстрым и реактивным изменениям, спущенным сверху.

Значит, мы собираем еще одну встречу, чтобы решить то, что уже решили на прошлой неделе? Отлично.

Мне кажется, что мы находимся в цикле принятия решений. Мы обсуждаем, решаем, а потом снова сомневаемся в себе.

Решение было принято без участия тех, кто действительно работает над проектом. Теперь нам придется переделывать его.

Неэффективные механизмы сотрудничества

  • Время, потраченное на работу в одиночку, когда совместная работа была бы более эффективной, и наоборот.

  • Время, потраченное на использование транзакционных процессов и подходов к работе в ситуациях, которые должны быть кооперативными. И использование методов сотрудничества и «высоких ощущений» в ситуациях, которые могут быть безопасными для взаимодействия.

Если бы мы поработали в паре, это было бы сделано за час.

Я не могу выкроить ни секунды, чтобы поработать над этим в одиночку.

Недостаток помощи и поддержки

  • Время, потраченное впустую из-за отсутствия помощи, трудностей с получением помощи, того, что люди слишком заняты, чтобы помочь, или культуры, которая не одобряет просьбы о помощи.

  • Время, потраченное на поиск нужного человека или отдела, который мог бы помочь в решении конкретной проблемы, приводит к необходимости бегать по кругу.

Я мог бы решить эту проблему за пять минут с небольшой помощью, но все «слишком заняты», чтобы ответить на простой вопрос.

В конце концов я нашел нужного человека, который помог мне, но на это ушло три дня беготни.

Неэффективная документация

  • Время, потраченное на написание документации, которую никто не читает, или отсутствие документации, которая могла бы сэкономить людям время и улучшить их работу.

  • Время, потраченное на интерпретацию спецификаций или контекста, однажды или дважды оторванного от источника.

Сегодня я потратил два часа на расшифровку устаревшей документации. И до сих пор не нашел ответа.

Плохо поддерживаемый код и документация

  • Время, потраченное на навигацию или работу с трудным для понимания или плохо поддерживаемым кодом, документацией и т. д., без исправления проблем по мере их возникновения.

Код настолько запутан, что кажется, что это археология, а не программирование.

Костыли

  • Время, потраченное на "костыли", которые сами по себе работают медленнее, но при этом создают дополнительную путаницу для других членов команды.

  • Время, потраченное на документирование и объяснение "костылей" другим членам команды.

  • Время, потраченное на пересмотр и поддержку "костылей".

Сейчас в коде так много хаков, что это похоже на хождение по минному полю. Один неверный шаг - и все взорвется.

Я потратил половину своего дня на документирование "костыля", который просто запутает следующего человека, который его увидит.

Неэффективный онбординг

  • Время, потраченное на то, чтобы ввести новых членов команды в курс дела (которое можно было бы эффективно оптимизировать), не имея достаточно времени для обмена более широким контекстом и налаживания отношений.

  • Время, потраченное на повторное освещение основных деталей проекта для новых сотрудников из-за отсутствия стандартизированных материалов или процедур по введению в должность.

  • Время, потраченное на исправление ошибок и недоразумений, возникших в результате неполного или поспешного процесса введения в должность.

В первую неделю новые сотрудники тратят время на то, чтобы разобраться в нашем запутанном процедуре настройки.

Создается впечатление, что каждый новый член команды изобретает колесо заново, потому что наш онбординг настолько неорганизован.

Проблемы с инструментами

  • Время, потраченное на то, чтобы заставить работать нестабильные инструменты, использовать устаревшие инструменты или заставить инструменты работать вместе. Это включает в себя ручную переустановку инструментов и многократную настройку среды вручную.

  • Время, потраченное на использование неподходящего инструмента для работы, более медленную работу и создание большего количества ошибок или "костылей".

  • Время, потраченное на неэффективную диагностику - что-то не работает, и вы пытаетесь выяснить причину, а у вас нет инструментов/возможности наблюдения, чтобы быть эффективным. В некоторых случаях вы оставляете проблемы открытыми. В других случаях на то, чтобы докопаться до сути, уходит гораздо больше времени.

  • Время, потраченное на решение конфликтующих версий библиотек или пакетов, когда они могли бы быть стандартизированы в разных проектах.

Если бы у меня был монетка за каждый раз, когда мне приходилось вручную переустанавливать свое окружение разработчика... У меня было бы много монет.

Мы автоматизировали эту задачу, но инструмент, который мы использовали, настолько сложен, что теперь никто не знает, как его починить, если что-то пойдет не так.

Ручные, автоматизируемые задачи

  • Время, потраченное на выполнение ручных, объемных, повторяющихся задач, которые являются хорошими кандидатами для автоматизации. Сюда также входит исправление ошибок, вызванных выполнением этих задач вручную.

  • Время, потраченное на ручное обновление зависимостей, когда можно было бы использовать средства автоматизации для поддержания их в актуальном состоянии.

Почему я все еще делаю это вручную? У нас есть технология, чтобы автоматизировать это! Такое ощущение, что мы застряли в 2004 году.

Ожидание в медленных процессах

  • Время, потраченное на ожидание медленного процесса без возможности контекстного переключения. Вы не можете делать что-то еще, но вы ждете.

  • Время, потраченное на ожидание завершения вычислительных задач, таких как сборка или преобразование данных, которые можно было бы оптимизировать.

Я пытался работать в многозадачном режиме во время ожидания, но переключение контекста только усугубило ситуацию.

Переработка, проверка, обратная связь и преждевременная конвергенция

  • Время, потраченное на работу над чем-то без подтверждения предыдущих предположений, поскольку это снижает эффективность того, что вы делаете прямо сейчас.

  • Время, потраченное на преждевременную фиксацию чего-либо, часто для того, чтобы «показать что-то» руководителям, когда лучше было бы начать с минимума и развивать его со временем.

  • Время, потраченное на задержку из-за отсутствия немедленной обратной связи. Да, вы можете заняться чем-то другим в ожидании, но при этом вы несете затраты на переключение контекста, а ценная задача, требующая обратной связи, оказывается отложенной.

  • Время, потраченное на работу с неполным контекстом или информацией, когда ваша работа могла бы быть более обоснованной и эффективной (или ваше время могло бы быть лучше потрачено на обучение).

  • Время, потраченное на погоню за идеальной информацией или полной уверенностью, когда достаточно просто принять правильное решение.

  • Время, потраченное на попытки расшифровать, как люди переводят потребности клиентов, когда лучше было бы установить прямой контакт. Время, потраченное на работу с поспешно собранными исследованиями или на то, что не было изучено правильными методами.

Я бы хотел, чтобы мы просто проверили это, прежде чем создавать. Теперь мы вынуждены отказаться от этого.

Нам следовало просто запустить его и начать отслеживать отзывы.

Я могу сказать, что эту историю пользователя придумал менеджер по продукту. Я не уверен, что он действительно понимал данные или отзывы.

Думаю, я буду продолжать, исходя из предположения, что это правда. Но доказательства очень шаткие.

Создание малоценных функций

  • Время, потраченное на создание того, чем не пользуются клиенты, что слишком сложно или перепланировано, или ориентировано только на краткосрочную прибыль, что перекладывает расходы на будущих разработчиков.

  • Время, потраченное на выдуманные проекты из-за задержек с обратной связью и направлением, а также из-за необходимости оставаться занятым во время затишья и пробелов.

  • Время, потраченное на « продвижение по службе», предназначенное исключительно для проверки отдельных разработчиков.

Я создал эту функцию, которой никто не пользуется. Это все равно что строить мост в никуда.

Что ж, моя оценка работы показала, что я слабоват в этой области, поэтому мы придумали этот проект, над которым я мог бы поработать, чтобы проявить себя.

Конечно, мы закрыли клиента, но это довольно слабый результат.

Невыпущенный код

  • Время, потраченное на код, который простаивает без дела, не получая обратной связи и не принося пользы.

  • Время, потраченное на то, чтобы не интегрировать код и не увидеть, как он сочетается с общей кодовой базой.

Мой код просто пылится, потому что его еще не выпустили.

Кто знает, пройдет ли он вообще проверку.

Мы находимся на пятой фазе этого проекта и еще ничего не сделали. Забавно, правда? Хотя отчетность выглядит неплохо.

Искусственные сроки и спешка

  • Время, потраченное на неэффективную работу, чтобы уложиться в искусственные сроки, что часто приводит к сверхурочной работе даже в условиях деградации.

  • Время, потраченное на поспешную работу и ошибки в пути, ощущение спешки.

  • Время, потраченное на выполнение работы раньше, чем это необходимо, или раньше, чем работа, которая может быть более ценной.

Мы спешим уложиться в сроки, которые кто-то придумал из воздуха, и при этом теряем кучу ресурсов.

Я работаю примерно на 50 %. Я не принимаю хороших решений.

Плохое соотношение времени и энергии

  • Время, проведенное в периоды плохого соотношения времени и энергии. Например, послеобеденные встречи для задач, требующих глубоких размышлений, и утренние встречи в период наилучшей концентрации.

  • Время, потраченное на отдых и подзарядку, но неэффективное из-за прерываний. Вы менее эффективны, когда пытаетесь продуктивно работать позже в течение дня.

Почему мы проводим мозговой штурм в 16:00 в пятницу?

Они запланировали рутинное совещание по обновлению в мои самые продуктивные часы. Вот и весь мой поток.

Каждый раз, когда я говорю, что пойду на настоящий обед, я оказываюсь на дурацком звонке в Zoom.

Несоответствие навыков

  • Время, потраченное на то, что плохо соответствует навыкам. Либо что-то, что выходит за рамки навыков сотрудника, либо что-то, что ниже его квалификации.

Мне не хочется признавать это, но я далеко не в теме..

Мне скучно, и я наполовину выдохся

Потеря знаний

  • Время, потраченное на повторное изучение информации, было потеряно, когда из компании ушли люди, у которых не было возможности передать эти знания.

Наш ключевой эксперт ушел, и теперь мы тратим недели на то, чтобы заново выучить то, что он знал.

Никто из команды не встречался с клиентами. Это безумие.

Упущенные возможности

  • Время, которое НЕ БЫЛО потрачено на высокоэффективную работу, обмен ценным контекстом, перекрестное обучение других людей и следование технологическим тенденциям. Это упущенные возможности, на которые другие пункты списка не дают вам уделить внимание.

  • Время, потраченное на то, чтобы не исправлять вещи, упомянутые в этом списке, особенно если если не исправление чего-то усложняет исправление в будущем.

Я хотел бы иметь время для работы над более значимыми проектами, но я застрял на выполнении неотложных задач.

Я бы хотел потратить один день на то, чтобы эти "порезы от бумаги" исчезли.

Эффекты второго и третьего порядка

  • Время, потраченное на менее эффективную работу, обусловлено эффектами второго и третьего порядка всех вышеперечисленных пунктов, включая потерю морального духа и уверенности, психологический удар, «отказ от работы» и отключение от нее.

Все эти мелкие неэффективные действия начинают сказываться на моральном духе команды. Это нисходящая спираль.

Деньги хорошие, и я хочу сохранить свои возможности. Я не могу изменить это место.

Я что-то упустил?



p.s. а еще я пишу про управление продуктами в своем тг-канале Inspired Product Manager.

p.p.s. статья является переводом

Показать полностью 1
1

Deep research: «ChatGPT vs Perplexity»

OpenAI часто упрекают в недостаточном внимании к продуктовой составляющей. Критикуют, что компания никак не может перестроиться с роли исследовательской лаборатории на полноценную коммерческую структуру.

В то же время Perplexity активно делает акцент именно на продукте. Их CEO в одном из недавних интервью заявил, что ключевое конкурентное преимущество компании заключается именно в тщательной работе над продуктовой частью.

Я решил провести небольшой эксперимент и сравнить два похожих инструмента — Deep Research от OpenAI и аналогичную функцию у Perplexity.

Deep Research однозначно рекомендую для проведения «кабинетных» исследований — лично я уже сэкономил пару десятков часов работы, подписка себя с лихвой окупила.

На первый взгляд оба продукта предлагают глубокое погружение в тему с подбором максимально релевантных источников. Но при детальном изучении становятся очевидны различия:

1. Интерфейс и пользовательский опыт:

ChatGPT (OpenAI)

-Интерфейс заметно ориентирован на технологии. Пользователю предлагается множество моделей, среди которых непросто разобраться. Непонятно, какая модель лучше подходит именно для Deep Research.

Deep research: «ChatGPT vs Perplexity» ChatGPT, Искусственный интеллект, Исследования, Чат-бот, Стартап, Будущее, Тренд, Длиннопост

Выбор модели

-Deep Research встроен в основной интерфейс. После использования режима кнопка становится неактивной, требуется дополнительный клик для повторного использования, мне так показалось удобней.

Deep research: «ChatGPT vs Perplexity» ChatGPT, Искусственный интеллект, Исследования, Чат-бот, Стартап, Будущее, Тренд, Длиннопост

Выбор режима Deep Research

Perplexity

-Более интуитивный интерфейс, ориентированный на конечного пользователя. Несмотря на то, что Perplexity использует множество моделей (OpenAI, Claude, Gemini, Grok), параметры выбора значительно упрощены.

Deep research: «ChatGPT vs Perplexity» ChatGPT, Искусственный интеллект, Исследования, Чат-бот, Стартап, Будущее, Тренд, Длиннопост

Deep Research от Perplexity

-Deep Research вынесен в отдельную вкладку, но при необходимости мелких уточнений приходится вручную переключаться обратно или открывать новое окно. Также можно забыть выключить Deep Research, из-за чего простой запрос уходит в долгий режим обработки.

-Режим «Auto» вводит в заблуждение: на практике не всегда понятно, когда именно запускается Deep Research. Запросы вроде «сделай Deep Research на тему...» не всегда приводят к ожидаемому результату.

2. Точность, скорость и качество ответов:

ChatGPT (OpenAI)

-Ответы обычно более глубокие и тщательно проработанные, но подготовка занимает больше времени (по ощущениям примерно вдвое дольше, чем у Perplexity).

-Почти всегда запрашивает уточнения, что позволяет получить более релевантный результат, но при этом увеличивает время взаимодействия.

Deep research: «ChatGPT vs Perplexity» ChatGPT, Искусственный интеллект, Исследования, Чат-бот, Стартап, Будущее, Тренд, Длиннопост

Уточенние от OpenAI

При больших и сложных запросах (например, сравнение 9 поставщиков по 30 параметрам) начинает выдавать ошибки или не справляется с объемом информации.

Deep research: «ChatGPT vs Perplexity» ChatGPT, Искусственный интеллект, Исследования, Чат-бот, Стартап, Будущее, Тренд, Длиннопост

Ответы от ChatGPT

Perplexity

-Работает быстрее и не требует предварительных уточнений, сразу выдавая готовый результат, что удобно.

-Однако иногда это приводит к тому, что результаты получаются менее точными, и пользователю приходится повторять запросы несколько раз.

-При сложных запросах также теряет часть информации, не сообщая об этом напрямую: в моём случае вместо сравнения 9 поставщиков по 30 параметрам выдал только 4 поставщика по 20 параметрам без уведомления об ошибке.

3. Тарификация:

ChatGPT (OpenAI)

Deep Research ограничен: тариф Plus — 10 запросов в месяц, тариф PRO — 120 запросов.

Deep research: «ChatGPT vs Perplexity» ChatGPT, Искусственный интеллект, Исследования, Чат-бот, Стартап, Будущее, Тренд, Длиннопост

Я достиг ограничения в 10 запросов в месяц от OpenAI

Perplexity

-Бесплатный тариф предоставляет до 5 запросов Deep Research в день.

-На платном тарифе нет ограничений.

4. Представление результатов:

ChatGPT (OpenAI)

Результат можно копировать с встроенными ссылками. Для экспорта результатов в PDF предлагается инструкция, явно неудобная и неподходящая массовому пользователю.

Deep research: «ChatGPT vs Perplexity» ChatGPT, Искусственный интеллект, Исследования, Чат-бот, Стартап, Будущее, Тренд, Длиннопост

"Простенькая" инструкция как получить PDF

Perplexity

Позволяет удобно экспортировать отчет в PDF или DOC, оформленный в виде полноценного исследования со ссылками и источниками. Тут явно подумали о том, как будет использоваться это исследование.

Deep research: «ChatGPT vs Perplexity» ChatGPT, Искусственный интеллект, Исследования, Чат-бот, Стартап, Будущее, Тренд, Длиннопост

Итоговое сравнение на примере сотрудников:

Если предположить, что это наши сотрудники, которым дали задание провести исследование, то оба инструмента похожи на начинающих сотрудников :

- Perplexity — прилежная девочка-практикантка: очень старается, стесняется уточнить детали, чтобы не подумали, что она чего-то не знает, красиво оформляет результаты, но иногда ей не хватает знаний и глубины, готова перерабатывать, боится потерять работу.

-ChatGPT — умный студент: знает очень много, уточняет детали, с но не особо задумывается о том, как удобно будут использовать полученные данные, явные проблемы с софт скилами, сами как-то разберетесь, не нравится не пользуйтесь, уходит ровно 18:00, у него и так дел полно, не очень боится потерять работу, занят получением новых знаний.

В целом оба инструмента довольно простые в использовании, Perplexity пользоваться чуть удобнее, и большинство моих задач решает. Видно, что продакты там действительно чуть больше думают о пользователях.Подписка стоит недорого, и если финансы позволяют, я бы брал оба инструмента, тем более в подписке не только Deep Research. Если что-то важное исследуете, запустить в обеих системах, можно рассматривать как два независимых кабинетных исследования. Если все же есть ограничения, а отчетов нужно делать много, то я бы взял Perplexity, все таки 10 запросов в месяц у OpenAI, по крайней мере в моем случае, это маловато, особенно когда во вкус входишь.

p.s. а еще я пишу про управление продуктами в своем тг-канале Inspired Product Manager

Показать полностью 8
11

Чему могут научить Симпсоны менеджеров по продукту и стартаперов

В 2005 году я увлекся популярным сериалом «Симпсоны». Я смотрел все предыдущие сезоны и пытался поймать каждую новую серию по мере ее выхода. Однако со временем я перестал следить за сериалом. Недавно, выбирая, что  посмотреть, мой выбор снова пал на «Симпсонов».  Судя по всему создатели не собираются заканчивать, а ведь уже уже 35 сезонов!

Несмотря на долгую историю, «Симпсоны» продолжают смешно шутить и затрагивают интересные темы. В другом не менее известном мультсериале даже придумали мем «Это уже было в Симпсонах», подчеркивая широкий спектр того, о чем они снимали серии.

Чему  могут научить Симпсоны менеджеров по продукту и стартаперов Стартап, Управление проектами, Симпсоны, Tesla, Гомер Симпсон, Предпринимательство, Провал, South Park, Автомобильная история, Длиннопост

Это уже было в Симпсонах

Среди многих тем, которые затронули «Симпсоны», —, конечно же, управление продуктом. В этой статье будет рассмотрен одна из серий, в которой можно найти множество типичных ошибок управления продуктами в компаниях. Серия называется «О, брат, где ты?» (Сезона 2, Эпизод 15), которая впервые вышла в эфир в 1991 году (еще до того, как некоторые из вас родились).

В этом эпизоде Гомер обнаруживает своего давно потерянного брата Херба Пауэлла, который является генеральным директором крупной автомобильной компании Powell Motors.

Чему  могут научить Симпсоны менеджеров по продукту и стартаперов Стартап, Управление проектами, Симпсоны, Tesla, Гомер Симпсон, Предпринимательство, Провал, South Park, Автомобильная история, Длиннопост

Херб и Гомер

Компания сталкивается с трудностями и нуждается в переменах. План Херба состоит в том, чтобы Гомер спроектировал новую машину, полагая, что Гомер, является типичным представителем целевой аудитории. Херб надеется, что автомобиль, разработанный Гомером, найдет отклик у похожих на него людей по всей Америке.

К сожалению, план не сработал, и полученный продукт полностью провалился.

Давайте рассмотрим основные ошибки управления продуктом.

Некомпетентность продакт-менеджера

Гомеру, у которого нет опыта ни в области управления продуктами, ни в автомобильной промышленности, поручили создать новый автомобиль.

Чему  могут научить Симпсоны менеджеров по продукту и стартаперов Стартап, Управление проектами, Симпсоны, Tesla, Гомер Симпсон, Предпринимательство, Провал, South Park, Автомобильная история, Длиннопост

И я хочу платить тебе 200 тысяч $

-Знаешь, почему я дал тебе эту работу?

-Потому что ты считаешь меня гением?

-Нет, я не считаю тебя гением.

-Потому что ты думаешь, что я энергичный

- Я не думаю, что ты энергичный

-Потому что ты думаешь, что я хорошо работаю с другими?

-Нет, нет, нет, нет!

-Гомер, я дал тебе эту работу, потому что ты заурядный.

Это правда, что люди с разным профессиональным опытом могут добиться успеха в управлении продуктом. Однако новичкам в этой области в идеале следует начинать с небольших, менее важных проектов. Эта стратегия позволяет  минимизировать риски и получить ценный опыт, прежде чем брать на себя более важные обязанности. В данном случае решение Херба привлечь Гомера было продиктовано их семейными связями и желанием применить нетрадиционный подход к спасению компании. К сожалению, это поспешное решение усугубило положение компании.

Несмотря на неудачу Гомера в этом эпизоде, в реальной жизни есть примеры людей, преуспевших в управлении продуктом без предварительного опыта в этой области. Например, Илон Маск произвел революцию в автомобильной промышленности с помощью Tesla, несмотря на то, что у него нет традиционного автомобильного опыта. Однако, в отличие от Гомера, Маск уже имел успешный опыт работы в мире бизнеса, в первую очередь с PayPal. Опыт Гомера  же включал в себя работу инспектором по безопасности на АЭС Спрингфилд, что не дало ему необходимых навыков или опыта для управления продуктами в автомобильной промышленности.

Приход Илона Маска в автомобильную промышленность был подкреплен видением и стремлением к инновациям, , что показывает, что даже новички могут оказать значительное влияние при правильном мышлении, преданности делу и хорошему базису в других  близких областях.

Отсутствие анализа рынка и потребностей клиентов

Компания Powell Motors столкнулась с серьезными проблемами при анализе рынка и определении потребностей клиентов. На совещании топ-менеджмента обсуждается плохая работа компании, но никто не может точно определить истинные причины кризиса. Даже  предположения менеджеров кажутся абсурдными:

-Каждый день мы сдаем позиции японцам, и я хочу знать, почему?

- Недобросовестная торговая практика?

-  Идиоты в Вашингтоне?

- Может быть цыганское проклятие?

Чему  могут научить Симпсоны менеджеров по продукту и стартаперов Стартап, Управление проектами, Симпсоны, Tesla, Гомер Симпсон, Предпринимательство, Провал, South Park, Автомобильная история, Длиннопост

-Каждый день мы сдаем позиции японцам, и я хочу знать, почему?

Топ-менеджеры также кажутся оторванными от реальности при обсуждении названия новой модели:

- Вы придумали название для нашей новой экономичной модели?

- Вам это понравится, шеф! Персефона!

-Персефона? Что это за название, черт подери?

- Она была греческой богиней весны и возрождения.

Чему  могут научить Симпсоны менеджеров по продукту и стартаперов Стартап, Управление проектами, Симпсоны, Tesla, Гомер Симпсон, Предпринимательство, Провал, South Park, Автомобильная история, Длиннопост

Персефона

Когда Гомера назначают на новую должность, Херб проводит крайне поверхностные исследования рынка. В итоге все ресурсы компании направлены на разработку продукта, основанного исключительно на мнении одного покупателя, а само исследование было сделано некорректно:

-Хорошо, тогда я хотел бы большую.

- У нас нет большой.

-Почему нет?

-Американцам не нужны большие машины

-Ну, дайте мне машину помощнее.

- Извините, у нас нет мощных автомобилей.

-Почему нет?

-Потому что американцам нужен хороший пробег, а не мощность.

- Скажи милому человеку, из какой ты страны.

-Америка!

- Слышите, болваны? Вот почему нас убивают на рынке! Вместо того, чтобы послушать, чего хотят люди, вы говорите им, чего они хотят.

Когда команда пытается спросить Гомера о его предпочтениях, это тоже не приводит к четким результатам:

-Итак, какую машину вы бы хотели, мистер Симпсон?

-Я не знаю.

Херб переоценивает роль менеджера по продукту, назначая Гомера единственным арбитром истины, предполагая, что остальные клиенты разделяют все его желания и потребности. Гомер не консультируется с потенциальными клиентами или экспертами и не проверяет свои предположения на практике. В результате команда сосредотачивается на создании автомобиля, который исключительно удовлетворяет видение Гомера об идеальном автомобиле, не принимая во внимание рыночную конкуренцию и тот факт, что у других пользователей могут быть совсем другие предпочтения.

Хотя некоторые лидеры отрасли, такие как Генри Форд, действительно добились успеха, полагаясь на свое видение и интуицию, такие примеры редки и часто включают исключительных людей с глубоким пониманием рынка. Форд сказал,

Если бы я спросил людей, чего они хотят, они бы ответили, что это более быстрые лошади.

Однако для большинства продакт-менеджеров очень важно проводить тщательное исследование рынка и привлекать потенциальных клиентов для выявления их потребностей и предпочтений. Такой подход значительно снижает риск разработки продуктов, не отвечающих требованиям рынка.

Неадекватная стратегия и нечеткое определение целевого рынка

Концепция Херба о создании автомобиля для среднего американца была слишком расплывчатой и лишенной конкретики.

-Я хочу, чтобы ты помог мне спроектировать машину. Автомобиль для всех Гомеров Симпсонов.

Компания была сосредоточена на выпуске очень доступных автомобилей. В начале эпизода они заняты выбором имени для бюджетной машины, что становится очевидным, когда Херб предлагает Гомеру выбрать себе машину.

- Знаешь, чего они мне стоили? В них железа на 40 баксов.

Чему  могут научить Симпсоны менеджеров по продукту и стартаперов Стартап, Управление проектами, Симпсоны, Tesla, Гомер Симпсон, Предпринимательство, Провал, South Park, Автомобильная история, Длиннопост

В них железа на 40 баксов

Не понимая стратегии и не имея никаких ограничений, Гомер проектирует автомобиль, который даже по сегодняшним меркам  кажется довольно дорогим. Цена автомобиля составила 82 тыс. $, несмотря на то, что в то время автомобили для массового рынка стоили от 10 до 15  тыс." class="formula inline">.

- Сколько стоит это чудовище?

-82 тысячи долларов.

Никто не задумывался, сможет ли целевая аудитория, представленная Гомер Симпсонами, позволить себе такую машину.

Известным примером компании, совершившей подобные ошибки, является Segway. Segway PT  был помпезно представленпредставлел в 2001 году. Ожидалось, что он произведет революцию в городском транспорте. Однако продукт не оправдал ожиданий прежде всего из-за неясного целевого рынка, высокой цены и ограниченной практичности. Целевая аудитория Segway PT не была четко определена, а его цена около 5000 долларов делала его недоступным для среднего потребителя.

Как и в случае с эпизодом «Симпсоны», эти примеры иллюстрируют важность наличия четкой стратегии и определения целевого рынка в управлении продуктом. Понимание потребностей, предпочтений и финансовых возможностей целевой аудитории имеет решающее значение для разработки продуктов, которые находят отклик у предполагаемых клиентов и добиваются успеха на рынке.

Плохое взаимодействие с командой и авторитарное управление

Гомеру дана невероятная власть, о которой многие продакт-менеджеры могут только мечтать:

- Направляйте все свои вопросы мистеру Гомеру Симпсону, человеку с видением. Человек, который поможет этой компании выбраться из ямы. Человек, который навсегда изменит американский транспорт!

Чему  могут научить Симпсоны менеджеров по продукту и стартаперов Стартап, Управление проектами, Симпсоны, Tesla, Гомер Симпсон, Предпринимательство, Провал, South Park, Автомобильная история, Длиннопост

Все вопросы направляйте мистеру Гомеру Симпсону.

Команда общается с Гомером, используя технический жаргон, который он не понимает, не пытаясь объяснить свои решения.

- Ставим что-то бортовое и реечный руль...

Изначально команда не доверяет Гомеру и старается не допускать его к процессу принятия решений.

- Мистер Симпсон, ваш брат сказал вам помочь нам с этой машиной, не так ли?

-Да.

-Почему бы вам не принести нам кофе?

Однако генеральный директор снова вмешивается, предоставляя Гомеру неограниченную власть, фактически превращая его в диктатора, который отдает приказы без обсуждения или учета мнения команды.

В общении с командой Гомер выявляет несколько пользовательских проблем, но тут же предлагает решения, не позволяя команде предлагать оптимальные альтернативы. Например, Гомер освещает проблему общения с шумными детьми в машине:

- Иногда дети сидят на заднем сиденье, орут, бесят. Вы  наверняка что вы можете сделать с этим?

Однако когда кто-то предлагает решение, не устраивающее Гомера, это приводит к тяжелым последствиям:

-Ты уволен! За что мы ему платим?

Чему  могут научить Симпсоны менеджеров по продукту и стартаперов Стартап, Управление проектами, Симпсоны, Tesla, Гомер Симпсон, Предпринимательство, Провал, South Park, Автомобильная история, Длиннопост

Человек с видением

Попытки команды эскалировать на руководство не увенчались успехом:

- Я рад, что ты нервничаешь, потому что это значит, что мы на правильном пути.

Даже несмотря на негативные отзывы от членов команды, генеральный директор отказывается их слушать. В одной из сцен он просит дать отзыв о Гомере, попросив полностью исказить смысл сказанного:

-Гомер Симпсон — блестящий человек с множеством продуманных практических идей. Он обеспечит финансовую безопасность этой компании на долгие годы.

Отсутствие MVP, итеративного подхода и обратной связи

Херб настаивает на том, чтобы ему не показывали новую машину, пока она не будет полностью закончена.

- Этот проект является нашим главным приоритетом. Все остальное на паузу, я не хочу ничего видеть, пока он не будет закончен.

Гомер, конечно же, не знаком с ключевыми понятиями управления продуктом, такими как «MVP» (минимально жизнеспособный продукт) и «итеративный подход». У него нет четкого плана по разработке и внедрению автомобиля, что приводит к таким проблемам, как непоследовательность дизайнерских решений, увеличение затрат и сложности с контролем процесса разработки.

При разработке автомобиля Гомер не просит обратной связи от потенциальных клиентов и не прислушивается к советам экспертов, которые могли бы значительно улучшить продукт. Вместо этого он полагается исключительно на свои собственные идеи и предпочтения.

Когда продукт, наконец, представлен потребителям и экспертам, он вызывает полное недоумение..

Чему  могут научить Симпсоны менеджеров по продукту и стартаперов Стартап, Управление проектами, Симпсоны, Tesla, Гомер Симпсон, Предпринимательство, Провал, South Park, Автомобильная история, Длиннопост

Реакция клиентов

Известным примером продукта, допустившим подобную  ошибку, является запуск Google Glass в 2013 году. Продукт представлял собой очки со встроенным компьютером, призванный революционизировать то, как люди взаимодействуют с технологиями. Однако Google Glass были запущены без MVP, что привело к высокой цене, проблемам конфиденциальности и отсутствию четких вариантов использования.

Google Glass не получал отзывов от потенциальных клиентов во время разработки, что привело к тому, что продукт не нашел отклика на рынке. Когда он наконец был представлен публике, он был встречен со скепсисом и большим количество негатива, что вынудило Google прекратить выпуск продукта в его первоначальном виде в 2015 году.

Этот пример подчеркивает важность включения MVP, итерационных подходов и обратной связи с клиентами в управление продуктом. Так компании могут избежать дорогостоящих ошибок, улучшить продукты и повысить вероятность успеха на рынке.

Перегрузка продукта излишними функциями

Гомер попадает в ловушку, добавляя в автомобиль множество функций, элементов дизайна и функций, не упрощая дизайн и не удаляя ненужные компоненты, что делает продукт в целом трудным для понимания и менее целостным.

Стоит отметить, что некоторые из предложенных Гомером функций действительно отражают его подлинные потребности:

-Мне нужно место в этой машине, чтобы поставить мой напиток… Я сказал поставить МОЙ напиток. Вы знаете Super Slakers, которые продаются в Kwik-e-Marts. Чашка такая БОЛЬШАЯ.

-Знаешь этот маленький мячик, который ты надеваешь на антенну, чтобы найти свою машину на парковке.

Другие предложения сбивают с толку и кажутся излишними:

-Некоторые вещи настолько шикарны, что никогда не выйдут из моды, например, хвостовые стабилизаторы и  пузырьковых сводов и пушистых ковров

-Когда я включу двигатель, пусть люди думают, что наступает конец света.

-Я хочу клаксон здесь, здесь и здесь. Ты никогда не сможешь найти свой клаксон, когда злишься. И они должны играть «Ла Кукарачу».

Чему  могут научить Симпсоны менеджеров по продукту и стартаперов Стартап, Управление проектами, Симпсоны, Tesla, Гомер Симпсон, Предпринимательство, Провал, South Park, Автомобильная история, Длиннопост

Первое демо продукта

В результате из-за чрезмерного количества функций автомобиль становится слишком дорогим в производстве и не оправдывает ожиданий большинства потенциальных покупателей. Это служит своеобразным предостережением для менеджеров по продуктам, для избежания перегрузки функциями и фокусе на удовлетворении основных потребностей своей целевой аудитории. Простота и удобство использования часто важнее длинного списка функций, которые могут не иметь существенной ценности.

Известный реальный пример продукта, пострадавший от перегруженности функциями, — Juicero. Эта высокотехнологичная соковыжималка была разработан для производства свежевыжатого сока с использованием запатентованных пакетов для сока, и была оснащена избыточными функциями, такими как подключение к Wi-Fi, сканер QR-кода для проверки свежести пакетов для сока и чрезмерно сложной механической системой,. чтобы выжать сок. Дорогой и сложный дизайн сделал ее менее привлекательной для потребителей, которые могли выбрать более простые и доступные альтернативы приготовлению сока. Juicero в конечном итоге потерпел неудачу на рынке из-за своей высокой цены и ненужных функций.

Учимся на ошибках Гомера Симпсона в управлении продуктами: основные выводы и предложения

Мы рассмотрели шесть важнейших проблем управления продуктом, с которыми столкнулись Гомер Симпсон и Херб Пауэлл:

  1. Некомпетентность продакт-менеджера

  2. Отсутствие анализа рынка и потребностей клиентов.

  3. Неадекватная стратегия и нечеткое определение целевого рынка.

  4. Плохое взаимодействие с командой и авторитарное управление.

  5. Отсутствие MVP, итеративного подхода и обратной связи

  6. Перегрузка продукта излишними функциями.

Не повторяйте ошибок Гомера Симпсона в своей профессиональной практике. Найдите время, чтобы посмотреть этот выпуск и поразмыслить над опытом своих коллег или даже над своими прошлыми ошибками.

Чему  могут научить Симпсоны менеджеров по продукту и стартаперов Стартап, Управление проектами, Симпсоны, Tesla, Гомер Симпсон, Предпринимательство, Провал, South Park, Автомобильная история, Длиннопост

Настоящий Гомер Симпсон ( Шедеврум)

Возможно, этот эпизод поможет вам извлечь ценные уроки и предотвратить подобные ошибки в вашей профессиональной практике.

Помните о важности подготовки, исследования рынка, анализа потребностей клиентов и разработки четкой стратегии с четко определенным целевым рынком. Хорошие коммуникативные навыки с и навыки управления проектами также являются важными факторами успеха.

Используйте принципы MVP и активно используйте обратную связь для более эффективного достижения желаемых результатов без излишней траты ресурсов и времени. Вдумчиво выбирайте функции продукта, исходя из реальных потребностей пользователей, и избегайте перегрузки продукта ненужными функциями, которые могут усложнить его использование и увеличить затраты на разработку и эксплуатацию.

Интересно, что автомобиль, спроектированный Гомером и его командой, позже был воссоздан в реальной жизни, но исключительно для участия в шуточных соревнованиях.

Чему  могут научить Симпсоны менеджеров по продукту и стартаперов Стартап, Управление проектами, Симпсоны, Tesla, Гомер Симпсон, Предпринимательство, Провал, South Park, Автомобильная история, Длиннопост

Автомобиль Гомера Симпсона

Он еще раз напоминает о ценных уроках, которые менеджеры по продуктам могут извлечь из этой серии, улучшить свои навыки и избежать подобных ловушек.

p.s. ну и “по классике”, в конце концов генеральный директор обвинил продакта в крахе компании ?

-Прощай Херб, из-за меня ты потерял свое дело, свой дом и все свое имущество. Может быть тебе было лучше, если бы я никогда не появлялся в твоей жизни.

-Может быть мне было лучше??? Может быть??? Кретин, конечно мне было бы лучше! Прошу запомнить, что у меня больше нет брата!

p.p.s. Если вы дочитали до конца, то вам наверняка понравится мой тг-канал Inspired Product Manager, где я ищу нестандартные способы донесения информации?, разбавляю своим опытом и яркими примерами!
Подписывайтесь!

Показать полностью 12
Отличная работа, все прочитано!