В первый раз с санкциями я столкнулся пять лет назад. Они не выглядели шумными, с публичными заявлениями. Просто одна крупная западная компания перестала продавать компонент другой крупной западной компании. Без объяснения причин. Это привело к потерям в несколько сотен тысяч долларов. Но закончилось относительно хорошо, так как компонент не был критичен, и его удалось заменить. Когда похожая ситуация повторилась через несколько лет, она ударила сильнее, поскольку «санкционированный» модуль уже участвовал в критической части функциональности. Это научило меня всегда учитывать риски отключения независимо от продукта или страны.
Идеально устойчивый продукт тот, который разрабатывается полностью собственными силами, с использованием открытых технологий. Но если рассматривать рынок в целом, то какие особенности ПО делают его наиболее независимым от ограничений.
Пару лет назад я стал следить за тем, что происходит в среде продукт-менеджмента. Преимущественно, конечно, на российском и ближайших рынках. Сейчас я готов сделать вывод, что вся видимая активность: сообщества, конференции, статьи, воркшопы – это шумиха, попытки потешить свое эго и теории ради теории.
Сразу признаюсь, чтобы не выглядеть обличителем, я довольно долго делаю продукты, и я также писал статьи и делал доклады ради тщеславия. Возможно, и эта статья написана с такой же целью.
Недавно я опубликовал статью по теме code escrow – депонированию исходного кода, как страховке для заказчиков. Исходная статья короткая, если вы не читали, то проще быстро пройтись по ней. Но вкратце, code escrow — это процесс размещения исходного кода вашего приложения в стороннем репозитории, к которому заказчик имеет доступ при определенном условии. Обычно это нужно если компания-разработчик уходит с рынка. И это является своеобразной страховкой клиентов.
Эту тему я обсудил не только в комментариях на Хабре, но и вне его. И было несколько интересных вопросов, которые считаю полезным опубликовать вместе с ответами.
Чаще всего термин эскроу (escrow) используется при оплате покупок или передачи работы по фрилансу. Эта, скорее короткая заметка, чем большая статья, описывает применение code escrow — депонирование исходного кода.
Неважно маленькая ли вы команда или большая компания, развиваете ли вы известный на рынке продукт или делаете новый стартап. В какой-то момент к вам придет заказчик с вопросом: «А что произойдет, если вдруг ваша компания закроется?». Ни известное имя, ни размер команды не гарантирует того, что продукт будет существовать и внезапно не исчезнет.
Сканирование документов по сети с одной стороны вроде бы есть, но с другой стороны не стало общепринятой практикой, в отличие от сетевой печати. Администраторы по-прежнему ставят драйвера, а настройка удаленного сканирования индивидуальная для каждой модели сканера. Какие же технологии есть на данный момент, и есть ли у такого сценария будущее.
Ребрендинг, переименование продукта случается не так редко, как может показаться. Вот несколько возможных причин.
Название устарело в современном мире
Несколько продуктов объединяется под одним зонтичным брендом
Компания, вместе с продуктами поглощается другой компанией
Название стало вызывать плохие ассоциации
В целом, новое имя может дать импульс, привлечь внимание, правильно спозиционировать продукт на рынке. Придумать новое название — это только малая часть, где-то 1% от всех задач. Необходимо проделать большой объем технической работы, которая не привносит новых сценариев, или решает проблему заказчика. Просчитать возврат инвестиций на эти «не функциональные» затраты невозможно. Это и есть боль продакт менеджера.
Это текст уже публиковался в англоязычной секции. Однако, я подумал, что читать, а также комментировать, может быть удобнее на русском.
Неважно опытный ли вы менеджер продукта, или только в начале карьеры, вы всегда будете держать в голове большой список запросов от ваших клиентов. Что нужно делать в первую очередь, как обрабатывать эти запросы?
Приоритезация запросов базируется на нескольких принципах. В качестве основы используется соответствие требований стратегии продукта и профилю клиента. Например, если ваш софт ориентирован на малые организации, то делать интеграцию с SAP не должно быть той вещью, которую вы будете делать в первую очередь.
Но какую часть вашего бэклога должны составлять запросы пользователей? Если ответ 100%, то это не совсем верный ответ. Возможно, выглядит странно, то это так.
Если вы не любите читать длинные тексты, то ответ такой: если ваш продукт зрелый, и давно на рынке вы не должны уделять много внимания запросам пользователей.
Представим, что вы как менеджер продукта делаете идеальное приложение. Оно продумано, ориентировано на определенный сегмент рынка. Инновации, big data, machine learning. И это действительно так. Как же можно запороть релиз на финишной прямой. Инструкция по неприменению.
Очень много статей и книг о работе менеджера продукта, рассматривают вопросы стратегического мышления и инноваций. Безусловно, это базис. Мне же нравится обращать внимание на ежедневные рутинные задачи. Одна из таких работа с запросами пользователей и требованиями к продукту.
Аксиомой является то, что запросы на функциональность от пользователей не являются требованиями к продукту. Запрос может быть легко разделён на несколько требований, и наоборот, одно требование состоять из нескольких запросов от пользователей.
You can always count product manager’s strategy skills like innovative thinking, blue ocean approach and others. But on daily basis we use more practical tools and approaches. This article is about working with feature requests and product requirements.
The main axiom of managing requests is that feature requests from customers, partners and internal teams are not requirements to the product. This is because every request can be split into several requirements or, otherwise, several requests can be combined to a single requirement.
Когда говорят о навыках, которыми должен обладать продукт менеджер на ум сразу приходят стратегическое мышление, планирование, управление новыми требованиями, общение с заказчиками. Однако, гораздо больше более приземленных задач, с которыми менеджер по продукту / владелец продукта должен уметь справляться. Одна из таких — управление совместимостью. Для меня — это, возможно, наиболее трудная задача.
It doesn’t matter if you’re an experienced product manager or took charge of a product recently you always be thinking about a large list of customers’ requests. What you should do first. How you should process them.
Feature prioritization is based on multiple principles. Basic are aligning to company vision, product strategy, and customer profile. For example, if you’re targeted to small businesses or home offices doing SAP integration request shouldn’t be in your first place.
But what share feature requests take in a product backlog? An answer like “it is full of customers' requests” isn’t correct. It seems strange but true.
If you’re not happy to read long texts the advice is “you should not give attention to customers' requests if your product is mature”.
