Про модель Кано

В бытность свою продуктологом я узнал, что есть такая прикольная штука - модель Кано. Японский профессор Нориаки Кано придумал её в 80-х годах для анализа лояльности и удовлетворенности клиентов продуктом. Он обнаружил, что не все фичи/характеристики одинаково полезны, и что с точки зрения влияния на лояльность клиентов их можно разложить на пять кучек.

Сейчас меня интересуют три из них:
- 🎉 Привлекательные (Attractive) — неожиданные или дополнительные функции, которые вызывают восторг при наличии, но отсутствие их не вызывает неудовольствия.
- 📈 Одномерные (One-Dimensional) — характеристики, которые прямо влияют на степень удовлетворённости: чем лучше, тем выше удовлетворение.
- 🧐 Обязательные (Must-be) — базовые характеристики, без которых продукт не приемлем, но их наличие воспринимается как должное и не повышает удовлетворённость.

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

И подумалось мне, что аналогичная история творится с ожиданиями от разрабатываемых приложений и компетенций программистов. Еще не так давно устойчивость сервисов к отказам сети, возможности мониторинга и сквозной трассировки были удивительными (attractive) особенностями самых лучших и передовых приложений, про это рассказывали на конференциях и хвастали в статьях. А сейчас, когда подходы к решению этих задач стандартизованы, а лучшие практики неоднократно описаны, невольно ожидаешь от разработчика безусловного, обязательного владения этим инструментарием.

Например, когда идет речь о разработке простенького микросервиса в составе большого решения, который принимает команды, скажем, по REST, сохраняет состояние в своей базенке и отправляет события в кафку, я почему-то ожидаю, что без дополнительных слов и указаний этот сервис будет:
- Реализован в концепции stateless, т.е. у него не будет своего состояния и его можно масштабировать без дополнительных приседаний
- Иметь базовый набор метрик (счетчики количества и длительности обработки запросов, обращений к БД, потребления CPU и памяти)
- Сохранять структурированные логи с атрибутом трассировки, позволяющим связать записи, относящиеся к одному запросу
- Реализовывать какие-то базовые механики устойчивости к сетевым сбоям, например Retry с переменным временем ожидания при обращениях по сети к кафке или СУБД.

Т.е. этот набор характеристик в моём восприятии уже относится к обязательным. А вот реализованный Circuit Breaker в этот набор не входит, я его воспринимаю как что-то среднее между привлекательными и одномерными характеристиками - хорошо (но не удивительно) если оно есть, но не так страшно, если его нет.

А у вас какие ожидания перешли из области удивительного в пространство обязательного?