Когда-то всё было проще. В достопамятные двухтысячные годы джунов и в самом деле нанимали. Не спрашивали о «релевантном опыте», не требовали ссылки на боевые проекты и не строили сложных лабиринтов из HR-интервью, технических сессий, тестовых заданий и многоступенчатых собеседований. Но прошло 15–20 лет — и всё изменилось до неузнаваемости. Новички (стажёры и джуны) теперь бесправны и даже подозрительны.
За семь лет проведения воркшопов по Story Points я наблюдаю одну и ту же картину: команды изучают технику, применяют её несколько спринтов, а затем постепенно возвращаются к старым паттернам. И если на маленьких масштабах работы с одной командой или тремя кажется что Story Points прекрасный подход, на текущем масштабе — около 50 команд в IT — 60% используют Story Points, 40% не используют - я вижу совершенно иную картину. И вот что интересно: те 60%, которые используют, делают это крайне по-разному.
Причем конверсия в правильное использование Story Points 3 месяца после тренингов составляет дай бог 20%. Проблема не в самом инструменте, а в том, как мы его используем и для каких целей.
Кажется, что главное в поиске работы — хорошее резюме и успешное собеседование. Оказывается, это не так. 19% работодателей учитывают знак зодиака кандидата при найме. А 79% изучают соцсети кандидата и могут отказать из-за неудачного поста.
Звучит абсурдно? Разберёмся, что происходит с рынком труда, и почему даже идеальные кандидаты получают отказы.
Привет, меня зовут Анатолий Чикирев, и сегодня я расскажу вам о Lean-практиках сокращения потерь в IT-сфере. Для начала давайте договоримся о терминологии. Lean и бережливое производство — это синонимы. Я буду использовать оба термина, но речь пойдёт об одном и том же. Но сначала пара слов обо мне и моём опыте.
Я работаю продактом в SM Lab с 2022 года, в целом в IT пришел в 2018 году — тогда я занимался заказной разработкой. Впервые я узнал о бережливом производстве в Высшей школе экономики, где изучил базовую теорию и основные понятия. Уже тогда мне показалось это интересным, но, разумеется, практики ещё не было никакой. Потом я пришел на свою первую работу на завод, где участвовал в пилотном проекте по внедрению Lean с привлечением консультантов. Там я руководил проектным офисом, поэтому сам проект видел больше с административной точки зрения и только несколько раз выходил «в поле» с руководителем проекта, а глубже в суть методологии погрузился уже позже.
Следующим этапом стала работа в международной FMCG-компании, где бережливое производство уже было внедрено, и я пришёл, как говорится, «на готовенькое»: моей задачей было поддерживать систему, развивать её и внедрять новые инструменты и практики, которые предлагала международная команда. Именно тогда я по-настоящему прочувствовал пользу и мощь Lean, увидев, как эти принципы работают на практике в производстве и какой эффект они могут приносить бизнесу.
Когда я перешёл в IT (сразу после той самой FMCG-компании), у меня возник большой вопрос: «А работает ли Lean здесь?». Я понимал, что теоретически — должно. Но как именно это применять? Как перенести инструменты, которые я применял на производстве, на IT-процессы? Поначалу это было неочевидно. Со временем, когда я освоился и в IT, и в роли продакта, и в самой SM Lab, всё встало на свои места. Я разобрался, как Lean может работать здесь, начал внедрять его на практике — и применяю до сих пор.
Когда управляешь миллионами, то подарить несколько долларов одному пользователю - это пустяк. Но из-за ряда системных просчетов доллар превращается в десяток, а там уже и сильно больше...
Чем дольше я работаю в разных системах управления проектами — тем лучше понимаю, насколько разные у команды и руководителей приоритеты.
— Сотрудникам важно легко разобраться в интерфейсе, держать под рукой свои задачи и красивый фон для доски с задачами выбрать 😌
— Руководителям важно знать, кто чем занят, контролировать работу команды и видеть полную картину по проектам 😎
Этот обзор я решила посвятить руководителям, так как сама пару лет назад начала управлять отделом. И теперь мои требования к системе управления проектами сильно возросли. В нем будут обзор возможностей для руководителей в разных сервисах, примеры использования и комментарии из личного опыта. Сотрудником тоже будет полезно о них узнать.
Переименование Scrum Master в Agile Delivery Manager — не просто смена названия на бейдже. Это отражение глубинных изменений в понимании роли, сфокусированной не на фреймворке, а на реальной ценности, которую команда приносит бизнесу. В эпоху потокового мышления и зрелых инженерных практик, где CI/CD — уже норма, лидерство в поставке перестаёт быть вспомогательной функцией. Эта статья — о том, как меняется суть роли, почему Scrum становится слишком узким, и почему переход к модели ADM может стать следующим логичным шагом для тех, кто давно перерос рамки agile 101.
Клиенты бывают требовательными, взыскательными, с невыполнимыми или неподходящими идеями. А если клиент ещё и с другим менталитетом, то коммуникация усложняется вдвойне. Расскажу про свой опыт и на примере жизненных кейсов покажу, как начать говорить с зарубежным клиентом на одном языке. Ведь почти весь мой опыт работы — с клиентами из США и Европы. Причём клиенты разные — от соло-стартаперов до менеджеров и дизайнеров из Google.
Эти истории помогут продактам, проджектам и даже инженерам — всем, кто взаимодействует с заказчиком напрямую.
Привет, Хабр! Меня зовут Рома Ковалевский, я program-менеджер из Берлина с 10+ годами опыта. Работаю с топами из бигтеха США — мои коллеги работали в компаниях вроде Google, Amazon, Apple и других гигантах. Веду собственный телеграм-канал про управление проектами «Менеджер от боженьки». Там — больше полезных постов и инсайтов о карьере проектного менеджера.
Любой бизнес — от индивидуального предпринимателя до крупной международной компании — вынужден адаптироваться под запросы рынка и потребности потребителей. А поскольку сегодня бизнес практически неотделим от ИТ: потребность в изменениях бизнес-процессов = потребности в изменениях в ИТ.
Изменения могут носить эпизодический характер, быть шаблонными и регулярными, малыми и большими по объему, масштабу и бюджету. Однако, изменения — не всегда про улучшения. Иногда, если что-то работает ну уж слишком хорошо, можно это и «ухудшить» в хорошем смысле этого слова. Например, снизить уровень сервиса, или сделать круглосуточную службу некруглосуточной.
Заморозка проекта — редкая, но непростая задача для менеджера. В подобных задачах не всегда бывают готовые решения, как экологично пройти через все этапы процесса. Я расскажу, как мы с командой прошли через заморозку, и поделюсь несколькими советами, как поддержать демотивированную команду и, конечно же, не забыть про себя. Все выводы в этой статье проверены на моем собственном опыте.
Нанимать джунов — это настоящая pain in ass. Откликов приходит больше ста в неделю, а кандидаты отличаются по уровню: одни только вчера окончили курсы, другие — почти мидлы. Пока разберем все отклики, проверим тестовые, проведем собеседования — проходит полтора месяца. А потом найденный сотрудник не проходит испытательный, и все повторяется снова.
Чтобы облегчить поиск, мы в Mindbox настроили конвейер стажировок. Теперь на отбор тратим меньше времени, а получаем разработчиков, знакомых с процессами, проверенных «в бою» и лояльных к компании. В статье — подробная инструкция для нанимающих менеджеров: как построить процесс, проводить собеседования и онбордить стажеров.
Далее >>>
Об авторе
Меня зовут Глеб Ковалев, я ведущий frontend-разработчик в Mindbox. Пару лет назад я начал проводить стажировки для frontend-разработчиков. А сейчас начинающих фронтов мы нанимаем преимущественно через стажировки. О том, как это происходит, расскажу в этой статье.
Никто не любит очереди и ожидания. Мы не любим стоять в очередях и ещё больше не любим лезущих вне очереди. Сверхэффективный ад порой представляют как бесконечную, зацикленную саму на себе очередь... В конце концов, что есть символ неизбывной печали и тоски, как не Хатико.
Знаете, кто ещё больше не любит ожидания? Бизнес. Бизнес очень не любит, когда ожидания копят важные проекты и инициативы. Согласно исследованиям средняя эффективность потока в Delivery составляет 35%, а всё остальное время - задачи ждут. (Данные на основе опросов специалистов — ссылка. Метаанализ тысяч workflow от Nave - ссылка ) Справедливо, что ключевая точка роста для ускорения поставки — уменьшение ожиданий.
Именно об этих "фантастических" ожиданиях и пойдёт речь в статье. Я расскажу о системной работе с блокировками и зависимостями, которые повинны в значительном количестве задержек. Мы погрузимся в необходимую теорию, рассмотрим наш успешный практический кейс в hh.ru и, что особенно ценно, я поделюсь конкретными пошаговыми инструкциями по настройке Jira & n8n, а также способами работать с визуализацией блокеров в удобных плагинах, чтобы вы могли применить этот подход у себя.
Этот материал будет полезен IT-менеджерам, тимлидам, руководителям проектов, delivery менеджерам и руководителям функций — всем, кто стремится более осознанно и эффективно распоряжаться временем и ресурсами.
Насколько важно профильное образование для начала карьеры PM? Из какой профессии можно стать PM? Какие курсы и книги полезны? Какие навыки можно прокачать самостоятельно? Ответы на эти вопросы, и не только, в статье о поиске работы менеджером продукта.
Предыдущая статья цикла: Глава 1: Кто такой продуктовый менеджер?
По мере роста бизнеса стандартные методы отчётности и ручной анализ данных перестают быть эффективными. В условиях высокой конкуренции и динамичного рынка информация устаревает ещё до завершения её обработки. Маркетинговые стратегии теряют свою точность. Управление ассортиментом становится реактивным, а не проактивным. Рассмотрим, как бизнес-аналитика помогает крупным e-commerce компаниям.
Привет, Хабр! Меня зовут Юлия Запольская, я продакт-менеджер в Яндексе, а сегодня еще и гостевой автор Friflex. В этой статье я поделюсь инсайтами, благодаря которым у меня получилось запустить продукт за четыре месяца.
Мой продукт называется CodeRun. В нем можно прокачивать свои навыки в формате решения практических задач по нескольким направлениям: фронтенд, бэкенд, аналитика, ML и мобильная разработка. Еще там можно общаться в коммьюнити (мы его модерируем и всячески поддерживаем), обращаться за помощью в решении задач к редакторам и соревноваться за призы и сокращенную схему найма в Яндекса.
Перенесемся в февраль 2024 года. У коллег была классная идея и ресурсы в виде большого количества контента и задач для тренировки навыков разработчиков, которые долгое время использовались в Яндексе для различных соревнований, но не публиковались для внешних пользователей. А также было огромное желание начать помогать разработчикам, которые очень хотят попасть в Яндекс или начать свой путь в IT.
С помощью этого контента и команды был собран бета-тренажер. Его запустили на узкую аудиторию — и сделали главный вывод, что он «зашел», надо делать.
Было принято решение запуститься в июне 2024 года: оставалось четыре месяца для того, чтобы полностью собрать фактуру, погрузиться и запустить продукт.
Что требовалось сделать? Во-первых, сильно расширить функциональность продукта, потому что она была супер базовая. В публичный запуск с такой функциональностью выходить сложно, потому что рынок конкурентов перенасыщен и важно было показать что-то особенное.
Привет, Хабр! Меня зовут Алексей Панаэтов, я технический лидер Центра геосервисов в МТС Web Services. Каждый руководитель рано или поздно задается вопросом о количественной оценке эффективности команды. Метрики помогают принимать решения объективно, но их очень сложно строить, когда в работе активно используются множества разных инструментов: трекеры задач, системы контроля версии, корпоративный мессенджер и другие. К ним нужно сначала получить доступ, затем выгрузить и обработать нужные данные. Ad-hoc-методы вроде csv-файлов и таблиц Excel подходят для разового анализа, но их тяжело поддерживать.
Я тоже столкнулся с этой проблемой и для ее решения создал и выложил в открытый доступ код CaptainBridge — инструмент, который помогает собирать и строить метрики эффективности команды.
Вот сколько лет делаю разработки для Fresh, а только сейчас узнал кое-какие подробности... Касающиеся жадности 1С до денег и нюансов "любви" 1С к клиентам...
В 1972 году, когда Дон Валентайн основал Sequoia Capital, термину «Кремниевая долина» не было и двух лет. Ветеран зарождающейся полупроводниковой промышленности, Дон помог стимулировать рост сектора персональных компьютеров и сетей. С первым фондом Sequoia в размере 3 миллионов долларов он поддержал как Apple, так и пионера видеоигр Atari. То, что Дон выбрал название «Sequoia», дерево, которое живет тысячи лет, а не назвал фирму в свою честь, никого не удивляет из тех, кто его знал.
В этой статье изложен взгляд на перспективы профессии ИТ-архитекторов. В ней не будет перечня разновидностей со всеми подробностями. Вместо этого будет дискуссия о ценности работы ИТ-архитекторов с некоторыми доказательствами. В конце будет сделан вывод о том, что может ждать профессию в будущем. Вопрос будет рассматриваться с точки зрения управления хаосом.
Меня зовут Кристина Павлив, я руководитель продукта в МТС: с нуля прорабатывала идею и развиваю приложение МТС Field, которым пользуются наши полевые инженеры.
В техническом блоке МТС около 3 тысяч человек занимаются подключением интернета и обслуживанием абонентов. В какой-то момент, чтобы выполнить свою работу, им нужно было зайти и заполнить данные в шести разных системах. Любое уточнение информации шло через диспетчерский центр, а перенос времени визита к абоненту или поиск новых заявок осуществлялись по звонку руководителю. И это все при разъездном характере работы, когда каждая минута на счету, а к абоненту опоздать никак нельзя!
В прошлом году мы создали одно приложение и закрыли все потребности ребят, работающих «в полях». Это была нетривиальная задача: собрать несколько команд, распределить зоны ответственности и наладить взаимодействие с конечными пользователями. В этом посте я расскажу, почему мы не могли избежать роста числа приложений, как выстраивали общение разработчиков с инженерами и какие дополнительные плюсы можно получить от создания «единого окна».