Управление продуктом *

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

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

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

Это несерьёзная статья на серьёзную тему. Есть такое понятие, как JSDD - Job Safety (Security) Driven Development, мы часто видим его в крупных компаниях. От этого не избавлены и небольшие компании, особенно когда в штате всего несколько программистов. Разработчики пишут свой код столь изысканным способом, что, несмотря на очень низкую скорость разработки, их страшно уволить, потому что, кроме них, этот код никто понять не сможет. Давайте попробуем разобрать, почему и как такое происходит.

Глеб Корсунов, CBDO Holyweb, побеседовал с руководителем проектного офиса СберМаркета Дмитрием Ирешевым о том, как построить грандиозные планы и достичь их, и почему правильно организованная коммуникация сотрудников позволяет не потерять мотивацию.

Расскажу, как мы с одногруппником бросили работу в сфере IT и финансов и через год стали зарабатывать вдвое больше, работая на себя. Сначала напишу первую часть — о том, как мы бросали работу. А дальше посмотрим.

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

Этот материал для тех, к кому когда-то подошли и сказали: «Некогда объяснять, ты теперь тимлид (или начальник отдела)». Может быть, теперь вы уже профессионал своего дела, знаете кучу различных инструментов для решения своих задачи. Но давайте посмотрим чуть-чуть с другой стороны и разберем, как вы управляете потоком своих задач. Как справляетесь с работой, которая к вам приходит. Возможно, это поможет немного ее пересмотреть.

Меня зовут Алексей Пименов, я сертифицированный инструктор альянса  ICAgile, аккредитованный тренер и консультант Kanban University. Пионер Kanban-метода в России.  Моя цель — развить и поднять уровень менеджмента. Kanban многие сопоставляют с DevOps-культурой и практиками DevOps, но это всего лишь один из инструментов, который должен быть в вашем менеджерском ящике.

Как UX ресерчеру найти ключ к сердцу РО? Step by step

О том как UX-эксперту выстроить качественную коммуникацию с продактом и с какими проблемами вы можете столкнуться.

Добрый день!

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

Управление продуктом API требует выстраивания отношений и с бизнес-партнёрами, и с разработчиками. (В идеале и с конечными пользователями, но эта опция для провайдеров API крайне редко доступна.)

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

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

Об оптимизации закупочной деятельности мы впервые задумались ещё в 2019 году. Создавать облачный сервис для некоммерческих закупок (закупок для нужд компаний) B2B Altis мы решили в нестандартном для российского рынка партнерстве, когда ритейлер выступает не просто заказчиком решения, но и его соразработчиком. В качестве партнера была выбрана крупнейшая коммерческая площадка электронных торгов B2B-Center. Партнерство открывало доступ к проверенной базе российских поставщиков - 574,6 тысячам контрагентов.

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

В этой статье: продакт овнер – это человек поживший. 
Быстрое решение задач – это как никотин, вызывает привыкание. Продакт не равно эникейщик. Результаты беседы с PO Lead в логистической компании.

МойОфис, российская компания-разработчик офисного программного обеспечения для совместной работы с документами и коммуникаций, объявляет о выпуске релиза 1.0 корпоративной почты нового поколения Mailion и обновлении других компонентов платформы до версии 2.1.

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

Продуктовый подход в менеджменте: история и современность.

Своему появлению product management обязан маркетологу. В 1931 году в отделе маркетинговых исследований Procter & Gamble трудился Нил Макэлрой. Он проанализировал маркетинговые процессы в компании и результат своего исследования изложил в отчете, который уместился в 800 слов.  В нем он впервые предположил, что анализ эффективности продаж должен включать не только оценку маркетинговых инструментов, но и изучение обратной связи от дилеров и непосредственных покупателей. Развивая эту мысль, Макэлрой придумал должность «brand man»: в функционал этого специалиста, по замыслу Нила, входили анализ истории бренда, изучение клиентов и территории продаж.

Именно в 1930-г первые продакт-менеджеры взяли на себя координацию всех (а не только маркетинговых) процессов, связанных с брендом – от разработки новых продуктов до продаж в регионах присутствия.

В 2006 году Яндекс и Google приехали в Петербург в Borland, который сокращал команду. Обе компании одновременно открывали в Петербурге свои офисы на его базе. Тогда к нам пришли замечательные ребята. Мы много общались, но больше всего запомнились слова Толи Орлова. Он сказал, что рост Яндекса на тот момент ограничивает только количество лидов, которые бы могли развивать продукты. Что роли техлида и тимлида очень существенны, и часто рост компании зависит только от наличия сильных лидеров. Тогда мне и захотелось узнать, как им стать.

Меня зовут Владимир Горовой. Я был тимлидом, потом перешёл в менеджмент, руководил созданием разных сервисов, в том числе, Яндекс.Путешествий. Сейчас работаю в Яндекс.Вертикалях. У меня есть разный опыт: менеджерский, разработческий и тимлидский. Всем этим и хочу с вами поделиться.

Привет! Я Ваня Соловьёв, дизайн-директор в «СберЗдоровье». Три года назад я рассказывал, как дизайнеру подружиться с продактом, чтобы вместе создавать сильные решения. В продуктовых компаниях эта тема актуальна и сегодня, поэтому решил сделать апдейт статьи с учётом полученного опыта.

Дизайнерам и продактам она поможет понять, всё ли хорошо у них в работе друг с другом. А если это не так — подскажет, как наладить процесс.

Казалось бы, IT-индустрия бесконечно далека от сборочных цехов Генри Форда. Однако даже труженики нуля и единицы порой чувствуют себя пойманными в порочный круг. День за днём одни и те же таски, каждый обеденный перерыв — одни и те же статьи на Хабре…

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

Вы решили открыть своё дело, создать сайт, запустить рекламную кампанию. Все эти начинания маловероятно принесут вам успех, если одним вечером вы не сядете, и не проработаете качественно УТП. Что же скрывается за этими буквами, и почему любому бизнесу без УТП никуда?

УТП – это уникальное торговое предложение. УТП – это залог того, что клиент купит у вас, а не у кого-то ещё. Почему? Потому что вы отличаетесь от других компаний, предоставляя то, чего они не предоставляют.

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

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

Методы проверки гипотез. Результаты беседы с продактом из ВТБ. Разговор с продактом из ВТБ

Недавно я готовил курс для Нетологии для новичков-продактов. Есть ощущение, что у всех разное представление о том, какие бывают инструменты проверки гипотез и для чего они используются. Информация из статей в медиа разнится между собой. Хочется создать некую универсальную “памятку”, которая разложила бы по полочкам все по этой теме. В рамках статьи я подчеркнул базовые мысли и выводы, к которым мы пришли в рамках стрима с автором канала https://t.me/productgames.

На протяжении 5 лет работы инженером-тестировщиком я всегда старалась найти ходы и выходы, чтобы упростить и оптимизировать процесс тестирования (рутина и монотонность – это не мое). Спойлер: у меня не получилось. В этой статье я хочу вам рассказать историю регрессионного тестирования на проекте, и о том, как у меня не получилось его оптимизировать ручным и авто-тестированием.