Характерно, что именно так и воспринимается переименование продукта. Давайте это сделаем в следующей версии, там только текст поменять.
Если у вас был опыт ребрендинга, была ли заранее спланирована архитектура таким образом, чтобы это был быстрый и безболезненный процесс?
В оригинальной статье основной тезис, что можно будучи early adopter можно потерять приватность. Взгляд интересный.
Early adopters это не про рационализм, ими всегда движет энтузиазм. Можно потерять приватность, а можно и жизнь (https://coganpower.com/blog/segway-accidents-result-in-high-rate-of-serious-injuries/).
Влияет ли потеря приватности на отток early adopters вот в чем вопрос.
Спасибо за ответ!
Про производительность, я имел ввиду сравнение извлечения информации из N страниц алгоритмом на шаблонах и алгоритмом на нейронных сетях. На одной и той же конфигурации, конечно.
Данный метод предполагает полное отсутствие настроек, или например, как у IBM https://www.youtube.com/watch?v=4uLRRWaOtRY?
Делались ли оценки производительности алгоритмов на нейронных сетях по отношению к алгоритмам на шаблонах? Интересно посмотреть цифры, или грубую оценку.
Спасибо, критика принята! Я хотел акцентировать внимание на том, что после планирования продукта или версии может быть ложное облегчение, что теперь все зависит от реализации командой девелопмента. В особенности когда видишь прогресс.
Да, спасибо! Продакт / проджект менеджер мне кажется у вас все-таки есть — это вы.
Мне нравится что список запросов виден всем заказчикам. Разделяю такой подход, хоть он и добавляет работы по администрированию.
Спасибо за детали, именно их читать интересно. Есть несколько вопросов. Как я понял у вас работает agile методология. Как с таким подходом удается решать стратегические цели? Например из головы, «к декабрю подсистема API сервисов должна поддерживать частное облако» (это всего лишь пример большой цели). При этом бэклог состоит из частных запросов заказчиков. То есть должна быть и «водопадная» часть: план с проектом.
Заказчики видят приоритет своих запросов. Вы их разбиваете / объединяете при обработке конкретных требований к продукту? Если да, то как это видит заказчик?
Со своими продуктами я не сталкивался с требованием обязательной сертификации определенного вида или третьей стороной. Обычно было достаточно информации о продукте по чеклисту. HIPAA это стандарт, допускается как самостоятельный отчет, так и сертификация третьей стороной. Так же и с VPAT.
Помимо соответствия, есть еще один нюанс, договор с третьей стороной, если она вовлечена в процесс внедрения или обслуживания решения. Вот описание и пример
На сайте HSS.gov есть много подробных материалов и FAQ по теме.
Тема обширная. Главный вопрос, что понимать под «фичей». Это может быть как минимально неделимая функция, например, сохранение. Либо сценарий, например, поддержка jpeg, которая включает загрузку, отображение, сохранение (в зависимости от продукта). Технически убирать минимальную функцию проще чем сценарий. Но выключать сценарий целиком более безопасно, так как он полон — редко влияет на остальную функциональность.
Доклад построен на опыте веб-приложений, когда продукт администрируется производителем. Добавлять, удалять и экспериментировать там проще. В случае on-premise приложений (устанавливаемых на ресурсы клиента) удалять функции сложнее. Основная причина, внезапная потеря функциональности заказчиком (т.н. feature loss). Можно много раз уведомлять об изменениях, но найдется один заказчик, у которого на этой функции будут построены бизнес-процессы. Это может стать причиной судебной претензии.
По моему опыту, если функциональность не входит в конфликт с новыми фичами, то дешевле с ней ничего не делать. Риск потенциальных потерь выше, чем затраты на поддержку.
Пример, как производится удалении куска функциональности у продукта. За два года (2 версии продукта) до предполагаемого удаления делается анонс в release notes. После этого функциональность скрывается, но доступна для использования при помощи ручных настроек в течение еще одного релиза. Потом удаляется полностью.
Статья очень хорошо показывает особенности работы продукт менеджера. Согласен со всем. Хочу дополнить тем, что для менеджера продукта есть опасность свалиться в замкнутый круг реализации требований заказчиков. Сложно противостоять диалогу, когда крупный клиент говорит, что ему не хватает фич A, B и C. Или когда потенциальный покупатель говорит, что раздумывает, потому, что нет фичи D. Чтобы правильно справляться с этим надо помнить продуктовую стратегию: для кого делался продукт, как он распостраняется, и на какие бизнес-сценарии направлен. Помнить так, что если ночью разбудят, то рассказать без запинки.
Если у вас был опыт ребрендинга, была ли заранее спланирована архитектура таким образом, чтобы это был быстрый и безболезненный процесс?
Early adopters это не про рационализм, ими всегда движет энтузиазм. Можно потерять приватность, а можно и жизнь (https://coganpower.com/blog/segway-accidents-result-in-high-rate-of-serious-injuries/).
Влияет ли потеря приватности на отток early adopters вот в чем вопрос.
Спасибо!
Про производительность, я имел ввиду сравнение извлечения информации из N страниц алгоритмом на шаблонах и алгоритмом на нейронных сетях. На одной и той же конфигурации, конечно.
Делались ли оценки производительности алгоритмов на нейронных сетях по отношению к алгоритмам на шаблонах? Интересно посмотреть цифры, или грубую оценку.
Усложение — это вид профессиональной деформации. Стараюсь отучиваться от этого.
Мне нравится что список запросов виден всем заказчикам. Разделяю такой подход, хоть он и добавляет работы по администрированию.
Заказчики видят приоритет своих запросов. Вы их разбиваете / объединяете при обработке конкретных требований к продукту? Если да, то как это видит заказчик?
Помимо соответствия, есть еще один нюанс, договор с третьей стороной, если она вовлечена в процесс внедрения или обслуживания решения. Вот описание и пример
На сайте HSS.gov есть много подробных материалов и FAQ по теме.
Доклад построен на опыте веб-приложений, когда продукт администрируется производителем. Добавлять, удалять и экспериментировать там проще. В случае on-premise приложений (устанавливаемых на ресурсы клиента) удалять функции сложнее. Основная причина, внезапная потеря функциональности заказчиком (т.н. feature loss). Можно много раз уведомлять об изменениях, но найдется один заказчик, у которого на этой функции будут построены бизнес-процессы. Это может стать причиной судебной претензии.
По моему опыту, если функциональность не входит в конфликт с новыми фичами, то дешевле с ней ничего не делать. Риск потенциальных потерь выше, чем затраты на поддержку.
Пример, как производится удалении куска функциональности у продукта. За два года (2 версии продукта) до предполагаемого удаления делается анонс в release notes. После этого функциональность скрывается, но доступна для использования при помощи ручных настроек в течение еще одного релиза. Потом удаляется полностью.