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

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

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

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

Здравствуйте! Я Александр Шульман, руководитель компании Active, в которой мы уже несколько лет занимаемся амбициозным проектом — пишем продукт для обеспечения кибербезопасности и достигли первых результатов: полгода назад мы получили аккредитацию от Минцифры, попали в реестр отечественного софта и у нас открылись продажи. Я хочу поделиться своим опытом и представлениями о рынке кибербезопасности с вами с позиции управленца, а не от лица специалиста ИБ, хочу рассказать о своих разочарованиях, открытиях и о том, как в итоге у нас в команде родилась идея сделать свой вклад в рынок ИБ. Мне кажется, что это многим будет интересно, т.к. рынок ИТ активно движется в сторону информационной безопасности по причинам регуляции и по причине роста реальных угроз, а значит, все больше менеджеров и управленцев столкнется с вызовами по кибербезопасности.

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

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

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

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

Всем привет! Мы (Олег Герцев и Лиля Кондратьева) работаем в сервисном центре Positive Technologies и отвечаем за поддержку MaxPatrol SIEM и MaxPatrol VM соответственно.

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

Ранее коллеги, работающие с PT Sandbox и PT NAD, рассказывали, с решением каких вопросов сталкиваются инженеры. Мы решили не останавливаться и в этой статье хотим приоткрыть завесу тайны над буднями специалистов поддержки уже других продуктов, приведя несколько историй на основе реальных событий. Кстати, пока мы готовили этот текст, так вдохновились, что придумали несколько тематических ребусов, к которым перейдем в самом конце. Пока же – ныряем в будни техподдержки!

RFM-анализ — это анализ клиентской базы на основе истории покупок, проще говоря, сегментация по частоте, давности и сумме трат.

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

Часто слышу и читаю о том, что крупные компании создают свои миссии. Или подобные документы, которые заявляют что-то абстрактное “за все хорошее, против всего плохого” или про то, как они меняют мир, ничего для этого мира и не делая. Все тезисы взяты из головы и совпадения случайны. 

Но есть примеры, когда компании декларируют более “приземленные” и рабочие принципы своей работы или модели действий (никого не рекламирую). Следуют им компании или нет – другой вопрос. Мне было интересно не это, а скорее то, как компании приходят к подобным декларациям. Если и вам интересно это узнать, то делюсь. 

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

Привет, Хабр! Меня зовут Николай, я аналитик компании Simbirsoft. Мне довелось участвовать во многих проектах, и на каждом из них заказчики понимали задачи и роль аналитика по-своему. Поэтому вопрос ролей аналитика на проекте —  мои личные кровь и пот боли: часто в одном лице хотят видеть и разработчика, и продвинутого тестировщика с пониманием процессов автотестирования, и многое-многое другое. Тем не менее, многие требования находят отражение в навыках и интересах аналитика, но эти требования ещё нужно правильно сформулировать при поиске.

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

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

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

Привет! Я Елена Бычкова, CJO в Альфа-Банке. Сегодня хочу поговорить с вами про коллаборации. Это слово мы видим в статьях и включаем в презентации, уже не задумываясь о смысле. А что же такое коллаборация? Запуск карты X5 от Альфы — коллаборация? Однозначно да. Встреча выпускников спустя 10 лет после школы? 

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

В статье разберёмся в непонятках с коллаборациями: разложим термин по полочкам и узнаем, как прокачать навыки сотрудничества. Что самое приятное — учиться вы будете на чужих (то есть моих) ошибках. 

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

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

Я расскажу вам мои советы о том, как не потерять себя, команду и клиентов 🙂

Нишевание: определение целевого сегмента

В спокойное время важно определять для себя ниши. Важно оказывать услуги по определенным целевым сегментам. Небольшие компании, как правило, работают в 1-2 сегментах.. Но если же времена становятся трудными, то лучше выживает тот, у кого как можно больше клиентов в разных направлениях (т.е он берется за большинство проектов).

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

В 2022 году нарушение логистических поставок авто привело к  открытию нового рынка. Итогом текущий сегмент PHPDev — авто — не пострадал., которые до сих пор активно выходят на рынок.

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

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

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

Получилось ли у нас улучшить UI по этому принципу — узнаете из статьи.

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

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

Разбираемся, как ребрендинг маркетплейса отражает стратегию компании в борьбе за лидерство на рынке, и как «Яндекс» пытается разрешить главный парадокс интернет-торговли

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

Привет, Хабр! Меня зовут Калаш, и я больше 11 лет в IT. Запустил несколько интернет-магазинов, мобильное приложение, программу лояльности с нуля. Консультирую и менторю начинающих продактов. Проверил более 2300 проектных работ студентов курса для продакт-менеджеров в Яндекс Практикуме. Мои студенты отлично справляются с проектами, где нужно работать с метриками, но незаслуженно мало внимания уделяют дереву метрик. Незаслуженно — потому что этот инструмент помогает организовать продуктовый процесс так, чтобы работа с метриками была согласованной и прозрачной.

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

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

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

Как с помощью Jobs To be Done принимать продуктовые решения, и почему сейчас мы используем этот подход для работы над нашими продуктами.

Крупными и опытными командами получена неумолимая статистика:

Не более четверти времени команды идет на процесс разработки. А, что еще хуже, существенная доля времени - от 5 до 15% и вовсе не связана с производственным процессом.

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

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

В начале апреля мы выпустили большое продуктовое обновление 2.8. В том числе он затронул «МойОфис Образование»: продукт версии 2.8 был улучшен для ещё более удобного и эффективного выполнения академических задач. Какие возможности появились в обновлённом решении и как они могут быть полезны при работе с документами, читайте под катом.

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

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

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

Привет! Меня зовут Ксения, я уже больше 7 лет занимаюсь релизами и сейчас работаю релиз-менеджером в RuStore. Сегодня хочу рассказать больше об этой роли, в каких случаях он вам нужен (спойлер, не всегда) и когда её можно переложить на другого сотрудника.