Именно на этом и хотел сделать акцент. Сканирование с устройства прямо в папку (почту, ECM) удобнее чем открытие приложения и сканирование в него. Это поддерживают уже и относительно недорогие устройства. Новым технологиям для связи со сканером уже места нет.
Согласен. Еще зависит от роли пользователя. Если для одной странички, то можно и камерой. Но если уже страниц 5, то я сам лучше дойду до сканера с автоподатчиком.
Например, весь пакет Microsoft Office. В нем документация заменена поиском действий в поле «Tell me what to do».
Инсталлятор MS SQL Server. Почти любой инсталлятор работает в режиме визарда, то есть поясняет сам себя, но MS SQL наиболее сложный пример.
Даже сейчас осуществим. Например, на нейросетях, которые будут анализировать действия пользователя и предлагать нужный инструмент или решение. Cortana сейчас в связке с O365 умеет читать и анализировать переписку, предлагая задачи для планирования. Можно и не знать о кнопке New Task.
Еще альтернатива: поле в офисе Tell me what do you want to do. Я до сих пор не могу найти где в Word находится Replace. Но пишу туда, и мне предлагается вариант. Раньше я бы полез в справку.
Документация останется в специфичных областях, где ее наличие выработано практикой. Например, инструкция к самолету: «Если у вас горит индикатор пожара, откройте мануал на странице N»
Согласен. Особенно сложно с продуктами с длинной историей. У меня почти не получается, но я вижу в этом будущее.
На этапе проектирования самопоясняющая функциональность затратна. Но это окупится. Справку читают только если что-то сломалось
Я встретил другую крайность. Есть в Питере энергосбытовая компания Петроэлектросбыт. У них удобный сайт и личный кабинет. При этом, если открыть справку, то вы скачаете pdf «ЛИЧНЫЙ КАБИНЕТ ПОТРЕБИТЕЛЯ, РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ» на 43 листах.
Есть еще один подход — полностью избавиться от документации и баз знаний. Можно использовать это как требование к продукту. То есть проектировать его так, чтобы он пояснял сам себя. Каждое требование должно отвечать на вопрос: “поймет ли пользователь функцию без пояснений в документации”
Характерно, что именно так и воспринимается переименование продукта. Давайте это сделаем в следующей версии, там только текст поменять.
Если у вас был опыт ребрендинга, была ли заранее спланирована архитектура таким образом, чтобы это был быстрый и безболезненный процесс?
В оригинальной статье основной тезис, что можно будучи 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. Чтобы правильно справляться с этим надо помнить продуктовую стратегию: для кого делался продукт, как он распостраняется, и на какие бизнес-сценарии направлен. Помнить так, что если ночью разбудят, то рассказать без запинки.
Инсталлятор MS SQL Server. Почти любой инсталлятор работает в режиме визарда, то есть поясняет сам себя, но MS SQL наиболее сложный пример.
Еще альтернатива: поле в офисе Tell me what do you want to do. Я до сих пор не могу найти где в Word находится Replace. Но пишу туда, и мне предлагается вариант. Раньше я бы полез в справку.
Документация останется в специфичных областях, где ее наличие выработано практикой. Например, инструкция к самолету: «Если у вас горит индикатор пожара, откройте мануал на странице N»
На этапе проектирования самопоясняющая функциональность затратна. Но это окупится. Справку читают только если что-то сломалось
Я встретил другую крайность. Есть в Питере энергосбытовая компания Петроэлектросбыт. У них удобный сайт и личный кабинет. При этом, если открыть справку, то вы скачаете pdf «ЛИЧНЫЙ КАБИНЕТ ПОТРЕБИТЕЛЯ, РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ» на 43 листах.
Если у вас был опыт ребрендинга, была ли заранее спланирована архитектура таким образом, чтобы это был быстрый и безболезненный процесс?
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. После этого функциональность скрывается, но доступна для использования при помощи ручных настроек в течение еще одного релиза. Потом удаляется полностью.