Если отбросить троллинг из комментария, то как быть с тем, что гражданин принадлежит к нескольким категориям? Утром автомобилист, а вечером пешеход, а завтра самокатчик. Или так, сегодня здоровый и внимательный, а завтра усталый и хромой, и не можешь увернуться.
Можно сначала определить кого мы считаем топ-менеджером. Для нашего примера можно взять CFO. Его в последнюю очередь будет интересовать какую ERP систему использует бухгалтерия. Главное, чтобы финансовая культура была впорядке. Допустим сценарий такой: отчетность формируется не вовремя. CFO спрашивает у главного бухгалтера почему. Ответ может быть «много операций делается вручную и решением может быть использование автоматизированной системы». CFO на встрече с CIO озвучивает проблему. CIO собирает команду: руководитель проекта от IT, главный бухгалтер и выделяет бюджет.
В данном сценарии какая выгода от внедрения будет у CFO? А у CIO? Напомню, что CFO прежде всего интересует отчетность во время — а это задача главного бухгалтера.
В этой схеме заказчик — главный бухгалтер. А исполнитель CIO, который уже выбирает исполнителя. В общем схема не очень простая.
Для топ-менеджмента, участвующего в проекте важно
1. Не потратить деньги впустую. Другими словами вы не должны завалить проект
2. Проект должен результаты, которые он может показать, в том числе и в своем резюме. Поэтому презентация для топ-менеджмента не связана с функциональностью продукта, customer development и т.д.
Последний пункт может быть связан и с именем продукта. К сожалению есть разница между
— «Налажена финансовое планирование через внедрение 'условного SAP'....»
и
— «Налажена финансовое планирование через внедрение 'никому не известной ERP'....»
p.s. Статья хорошая, таких должно быть больше в секции управления продуктом.
Из опыта добавлю, что на практике все работает немного с другой стороны. Топ-менеджер подписывает бумаги, но не он один принимает решение. Есть пользователи продукта, ключевой пользователь (условно бухгалтерия и главный бухгалтер). Именно они цель опроса.
В эффективности продукта топ-менеджера должны убедить внутренний заказчик, кто будет пользоваться продуктом.
Можно добавтть, что это вариант для вежливого общения. С внешними контрагентами/заказчиками. Или просто вежливая форма. В вежливой форме еще важно и приветствие, и вступительная часть.
При общении внутри компании и команды в подписи чаще всего будет просто имя.
Я не совсем понял про цифру 2, можете пояснить? Помимо особенностей зрения, есть еще физические ограничения по работе с мышью и клавиатурой.
Для теста проверил. На странице Яндекса для перехода на первый результат поиска нужно нажать tab 27 раз. При этом Narrator будет пытаться читать каждый проходящий элемент.
А чтобы отправить этот коментарий совсем непонятно как использовать tab. Элементы не выделяются при фокусе. Но похоже что 2 раза.
Нет, в ya.ru и duckduckgo та же проблема с результатами поиска. На странице результатов нельзя просто перейти по Tab на найденные страницы. Фокус перемещается по куче скрытых ссылок.
Попробуйте сами. При поиске на google при нажатии на tab будет окно «перейти к основному контенту?». То есть при использовании клавиатуры переход к результатам поиска в google будет tab, enter
Хорошая тема, я пропустил первую статью и с интересом ее прочитал.
При планировании интерфейсов рассматриваете ли вы все типа ограничений, или только визуальные? Их обычно выделяют в группы: визуальные, слуховые, возможность работы мышью, возможность работы клавиатурой и т.п. Можно для примера посмотреть VPAT шаблон.
Еще для меня показательный пример страницы Google и Яндекс. Если открыть обе страницы, то фокус будет сразу в поиске — это правильно. После поиска, если нажать tab, то в Google предложат сразу перейти на результаты. А в Яндексе будет фокус скакать по невидимым и невыделяемым ссылкам. Тому кто работает с VoiceOver или не использует мышь, страница Гугл поиска будет предпочтительнее.
Конечно статьи про юридическую часть нужны. Особенно про нюансы, например:
— Пообещали функциональность в новой версии через почту, телефон, сайт. Вовремя нет реализации. Заказчик идет в суд. Примеры кейсов в России если есть.
— Сравнили свой продукт с продуктом конкурентов. Конкурент пошел в суд. Тоже интересны примеры.
В этом и была идея — слом классики, выбор новых способов. Несмотря на странность этого подхода, мы имеем современное искуство. Не играем на струнной гитаре, а используем примочки для перегрузки и искажения звука. Синтетические звуки и прочее.
Мне кажется такие отзывы мир уже проходил с Авангардом. Нет пояснения, почему сравниваются именно эти параметры, а не другие.
Есть вполне официальные термины: массовая культура (для больших групп) и элитарная культура (для узкого круга). Массовая должна как раз и охватывать большое количество людей сразу. В этом нет ничего плохого.
То есть раньше Вивальди тоже был доступен узкому кругу, а ярмарочные пляски большинству.
Это что значит? Что исходники с низкой вероятностью утекут?
Я имею ввиду, что если взять вероятность утечки исходников умножить на вероятность того, что они будут исследованы хакерами, на вероятность того, что будет найдена используемая уязвимость, то общая вероятность угрозы будет крайне низкой.
Общая безопасность информационной системы зависит от многих факторов. Это может быть ПО, к которму нет доступа извне. Или само ПО может мониториться на предмет подозрительной активности внутри сети.
Все же мне кажется, что пример про уязвимости в утекшем коде больше теоретический. Я буду рад увидеть реальные примеры.
Единственное, что я сам нашел — это найденную уязвимость в утекшем коде Boeing 787 https://www.wired.com/story/boeing-787-code-leak-security-flaws/.
Эта уязвимость не могла использоваться на практике из-за наличия других инструментов защиты.
Мой случай частный, конечно, но все компании, с которыми я работал имели строгие политики по безопасности кода. Плюс есть стандарты, соответствие которым требуют заказчики.
Сокрытие кода не инструмент повышения безопасности, так как есть методики поиска дыр и в скомпилированном варианте. То же дизасемблирование.
Открытие исходников также не инструмент повышения безопасности. Исследовать его будут единицы. Я бы приглашал по контракту конкретных специалистов на на анализ возможных дыр. Взгляд со стороны всегда полезен.
Баг баунти хороший дополнительный способ. Он, кстати, чаще используется, чем видно в публичном поле. В схеме вендор — клиенты.
Но это все если отходить от темы эскроу. Риск выявления проблем с безопасностью кода из-за утечки исходников из депозитария крайне низкий.
И спасибо за комментарии! Это всегда делает тему живой
Скажу, что идея с архивом и ключом мне нравится. Будет работать при определенных условиях.
Вижу несколько моментов. При использовании архива обязанность за сохранность кода переходит к клиенту. Не каждый готов ее брать на себя, с учетом того, что сервис аудита уже оплачен. Плюс надо назначить ответственного за хранение и новых версий тоже. Средства шифрования должны быть разрешены к использованию в стране, и должны быть инструменты для шифровки дешифровки.
Минимальный набор состоит из самого хранения исходников и сопровождения escrow договора. То есть должен быть штат юристов, которые ведут договор и проверяют наступление условий.
Следовательно, условно базовая подписка состоит из количества поддерживаемых проектов и количества сопровождаемых договоров.
Расширять можно, как вы правильно заметили, проверкой качества архива. Можно предоставлять технический персонал для помощи в развертывании у клиента и т.п.
Есть более продвинутые бесплатные альтернативы для robotic process automation (RPA).
В данном сценарии какая выгода от внедрения будет у CFO? А у CIO? Напомню, что CFO прежде всего интересует отчетность во время — а это задача главного бухгалтера.
В этой схеме заказчик — главный бухгалтер. А исполнитель CIO, который уже выбирает исполнителя. В общем схема не очень простая.
Для топ-менеджмента, участвующего в проекте важно
1. Не потратить деньги впустую. Другими словами вы не должны завалить проект
2. Проект должен результаты, которые он может показать, в том числе и в своем резюме. Поэтому презентация для топ-менеджмента не связана с функциональностью продукта, customer development и т.д.
Последний пункт может быть связан и с именем продукта. К сожалению есть разница между
— «Налажена финансовое планирование через внедрение 'условного SAP'....»
и
— «Налажена финансовое планирование через внедрение 'никому не известной ERP'....»
p.s. Статья хорошая, таких должно быть больше в секции управления продуктом.
В эффективности продукта топ-менеджера должны убедить внутренний заказчик, кто будет пользоваться продуктом.
При общении внутри компании и команды в подписи чаще всего будет просто имя.
Спасибо, это интересно. Я не знал о таких возможностях скрин ридеров.
Для теста проверил. На странице Яндекса для перехода на первый результат поиска нужно нажать tab 27 раз. При этом Narrator будет пытаться читать каждый проходящий элемент.
А чтобы отправить этот коментарий совсем непонятно как использовать tab. Элементы не выделяются при фокусе. Но похоже что 2 раза.
Попробуйте сами. При поиске на google при нажатии на tab будет окно «перейти к основному контенту?». То есть при использовании клавиатуры переход к результатам поиска в google будет tab, enter
При планировании интерфейсов рассматриваете ли вы все типа ограничений, или только визуальные? Их обычно выделяют в группы: визуальные, слуховые, возможность работы мышью, возможность работы клавиатурой и т.п. Можно для примера посмотреть VPAT шаблон.
Еще для меня показательный пример страницы Google и Яндекс. Если открыть обе страницы, то фокус будет сразу в поиске — это правильно. После поиска, если нажать tab, то в Google предложат сразу перейти на результаты. А в Яндексе будет фокус скакать по невидимым и невыделяемым ссылкам. Тому кто работает с VoiceOver или не использует мышь, страница Гугл поиска будет предпочтительнее.
— Пообещали функциональность в новой версии через почту, телефон, сайт. Вовремя нет реализации. Заказчик идет в суд. Примеры кейсов в России если есть.
— Сравнили свой продукт с продуктом конкурентов. Конкурент пошел в суд. Тоже интересны примеры.
Я указал, что когда появился авангард в исскустве он тоже воспринимался в штыки. Классическое: «Я сам могу нарисовать этот квадрат»
Есть вполне официальные термины: массовая культура (для больших групп) и элитарная культура (для узкого круга). Массовая должна как раз и охватывать большое количество людей сразу. В этом нет ничего плохого.
То есть раньше Вивальди тоже был доступен узкому кругу, а ярмарочные пляски большинству.
Я имею ввиду, что если взять вероятность утечки исходников умножить на вероятность того, что они будут исследованы хакерами, на вероятность того, что будет найдена используемая уязвимость, то общая вероятность угрозы будет крайне низкой.
Общая безопасность информационной системы зависит от многих факторов. Это может быть ПО, к которму нет доступа извне. Или само ПО может мониториться на предмет подозрительной активности внутри сети.
Все же мне кажется, что пример про уязвимости в утекшем коде больше теоретический. Я буду рад увидеть реальные примеры.
Единственное, что я сам нашел — это найденную уязвимость в утекшем коде Boeing 787 https://www.wired.com/story/boeing-787-code-leak-security-flaws/.
Эта уязвимость не могла использоваться на практике из-за наличия других инструментов защиты.
Сокрытие кода не инструмент повышения безопасности, так как есть методики поиска дыр и в скомпилированном варианте. То же дизасемблирование.
Открытие исходников также не инструмент повышения безопасности. Исследовать его будут единицы. Я бы приглашал по контракту конкретных специалистов на на анализ возможных дыр. Взгляд со стороны всегда полезен.
Баг баунти хороший дополнительный способ. Он, кстати, чаще используется, чем видно в публичном поле. В схеме вендор — клиенты.
Но это все если отходить от темы эскроу. Риск выявления проблем с безопасностью кода из-за утечки исходников из депозитария крайне низкий.
И спасибо за комментарии! Это всегда делает тему живой
Скажу, что идея с архивом и ключом мне нравится. Будет работать при определенных условиях.
Вижу несколько моментов. При использовании архива обязанность за сохранность кода переходит к клиенту. Не каждый готов ее брать на себя, с учетом того, что сервис аудита уже оплачен. Плюс надо назначить ответственного за хранение и новых версий тоже. Средства шифрования должны быть разрешены к использованию в стране, и должны быть инструменты для шифровки дешифровки.
Следовательно, условно базовая подписка состоит из количества поддерживаемых проектов и количества сопровождаемых договоров.
Расширять можно, как вы правильно заметили, проверкой качества архива. Можно предоставлять технический персонал для помощи в развертывании у клиента и т.п.