User
Это серия из трёх постов предназначена для новичков, которые уже находятся в процессе перехода в IT или только планируют сменить нишу.
Здесь будут собраны базовые термины из IT-индустрии, которые стоит знать начинающим Проджект и Продакт Менеджерам, Продукт-Овнерам, а также тем, кто ещё не определился со своей ролью.
В конце статьи оставлю ссылки на 2 других статьи из серии.
Когда-то очень давно я думал, что оффер в Microsoft — это что-то из разряда фантастики. С тех пор я уже поработал в IBM, и нескольких других крупных компаниях. В других просто получал офферы, но отказывался по разным причинам.
На момент начала прохождения собеседований в Microsoft я уже пол года жил в Португалии и ориентировался только на Европейский / Американский рынки.
В этой статье я бы хотел:
• Поделиться своим опытом и кейсом;
• Рассказать про свой процесс подготовки и тайм менеджмента;
• Подсветить особенности Европейского / Американского рынков;
Буду рад ответить на вопросы и комментарии.
Идеальный Продакт Овнер. Как такого найти?
Толковый Product Owner — связующее звено между бизнесом и разработкой.
Как найти человека, который умеет приоритизировать задачи, разбираться в документации и вести команду к результату в реалиях 2024-2025 ?
Как Product Owner в прошлом с опытом найма специалистов на эту роль, я хочу:
• Поделиться опытом и ключевыми наблюдениями;
• Определить необходимые навыки для Product Owner;
• Предложить эффективные тестовые задания для оценки кандидатов;
• Привести готовый пример описания вакансии.
Буду рад ответить на вопросы и комментарии.
Годы опыта — как стаж в очереди: стоишь долго, а смысла мало.
Мы привыкли мерить компетентность количеством лет на должности, но как часто это обманчивая цифра скрывает настоящие навыки?
Талантливые и мотивированные люди остаются за бортом только потому, что у них нет ‘правильного’ числа лет.
Давай разберёмся, что важнее — формальные годы или реальные скиллы, и есть ли альтернатива привычному подходу на рынке.
Вот бывает такое: ты развиваешь свои навыки, накапливаешь опыт и скиллы, составляешь CV, которое, казалось бы, должно привести к собеседованию и, возможно, офферу. Но рекрутер просматривает его всего несколько секунд, закрывает и переходит к следующему кандидату, оставив твой отклик вообще без ответа.
Почему так происходит и как заставить резюме не просто привлекать внимание, но и задавать нужный тон на самом собеседовании?
👉 В статье, опираясь на свой опыт, расскажу, как правильно выделить свои сильные стороны, и составить свое CV так, чтобы рекрутеры буквально просили тебя прийти на собес, а твое CV задавало тон и вектор коммуникации в выгодную тебе сторону.
Разрабатывать продукт опираясь на интуицию — не прокатит.
Если вы хотите принимать data-driven решения на основе фактов, а не догадок, количественные исследования аудитории — ваш инструмент. Они помогают проверить гипотезы и дать прогноз того, что может произойти в будущем: как аудитория отреагирует на ту или иную фичу, какую монетизацию можно ожидать и т.д.
В этой статье разберемся с тем, как делать выводы на основе полученных данных, как правильно рассчитать погрешность выборки, сколько респондентов вам действительно нужно для получения данных, которым можно верить, и почему даже небольшая дельта погрешности может сильно повлиять на результаты.
В последнее время всё чаще и чаще натыкаюсь на термин data contract. И чтобы не отставать от трендов на рынке data engineering, решил изучить эту тему и рассмотреть тенденции. Постараемся понять, с чем его кушать и стоит ли кушать вовсе.
Краткое и понятное описание подхода RAG (Retrieval Augmented Generation) при работе с большими языковыми моделями.
Думаю, кому-то из вас будет интересно, как организованы процессы развития IT-продуктов в Ozon.
Продукты создаются командами. Деление на команды, а также их интеграция – важная и сложная задача. Каждая компания решает её по-своему, а идеального решения, наверное, не существует вовсе.
Бывает полезно посмотреть на опыт конкретной компании и сравнить с тем, как это устроено у вас. Или прикинуть, насколько вам подходит такая организация, если рассматриваете Ozon как потенциального работодателя.
Вот вам взгляд изнутри, а именно - из той части IT, которая занимается автоматизацией логистики.
Язык программирования — это тоже продукт. Он помогает разработчикам выражать свои идеи так, чтобы их мог интерпретировать компьютер. Может показаться, что развивать язык — это брать последние достижения теории языков программирования, реализовывать их и из года в год выкатывать разработчикам. Это не так. Егор Толстой, Kotlin Product Manager, и Андрей Бреслав, руководитель проекта Kotlin, рассказали, зачем JetBrains бесплатный язык программирования, как он устроен и откуда приходят новые пользователи. Статья вдохновлена выпуском подкаста make sense о Kotlin.
Язык — это в первую очередь рабочий инструмент, который миллионы людей используют ежедневно по много часов. Все эти люди решают разные задачи и сталкиваются с разными проблемами. Для команды разработки Kotlin знание этих сценариев и болей — основной источник идей, как улучшить пользовательский опыт и дать новые возможности программистам.
Мы начали делать Kotlin десять лет назад, а первый релиз вышел зимой 2016 года. Изначально он задумывался как язык, который улучшит жизнь Java-программистов. Сейчас на Kotlin пишут даже приложения для браузеров и iOS. Современный Kotlin — универсальный язык программирования с большим количеством приятных для разработчиков фич, статически типизированный, заточенный под большие проекты и поддержку крупных кодовых баз.
Один из важных вопросов как в нашей жизни, так и в бизнесе, и в IT — вопрос эффективности. Эффективно ли мы планируем наше время, те ли задачи решает бизнес, тот ли код мы оптимизируем? Чтобы ответить на эти вопросы, результат должен обладать главным критерием — измеримостью. Измеримость результата новых фич для бизнеса и IT обеспечивает платформа А/B-тестов. О том, как её можно построить, выдерживать большой RPS и при этом не облажаться уронить прод, я расскажу в этой статье.
В конце статьи вы узнаете, как мы задетектили проблемы инфраструктуры, оптимизация которых значительно повлияла на скорость всего Ozon.
Пару раз на предыдущих местах работы я попадал на проект, где не было документации. Все знания о проекте были у разных коллег, а некоторые части систем вообще были «чёрными ящиками».
Что делать, когда попал в проект без документации? Ответ простой — уходить!
А если серьёзно, отсутствие документации — возможность для прокачки хардов и софтов. Мне приходилось собирать информацию по крупицам и минимизировать bus‑фактор. В статье дам пошаговую инструкцию, чтобы облегчить жизнь тем, кто попадёт в аналогичную ситуацию.
В своей прошлой статье я рассказывал о том, как использовать метрики при разработке продуктов. Статья получилась довольно насыщенная, но теоретическая.
В этой статье я хочу рассказать о том, как на практике применять эти подходы при развитии продуктов. Можно ли опираться только на метрики для приоритизации задач. Что делать, когда у пользователей нет проблем с текущим продуктом.
Как с помощью Jobs To be Done принимать продуктовые решения, и почему сейчас мы используем этот подход для работы над нашими продуктами.
MVP — как много в этом звуке для сердца продакта слилось. Концепция, которая может выручить вначале, позже может уничтожить ваш продукт.