То что происходит в мобильной разработке показательно.
Измеримо, благодаря системам трекинга и публичных отсчетов.

Много замечательных инструментов на каждом участке, которые помогут вам с этим. У нас дэже может быть уже внедрено: continuos integration и delivery. Они автоматизируют вашу работу, они отвечают за сам процесс — те отвечают на вопрос как вы это делаете. Но не отвечают на вопрос Что вы делаете, что надо сделать.

Что именно происходит на стыке получения обратной связи и планирования. Как данные превращаются в результат, который заносится в системы планирования и уходит в разработку.

Не важно как хорошо вы проектируете, тестируете или определяете ценность. Как только вы выпускаете что то — оно начинает жить своей жизнью и меняться в той степени которую вы не планировали и не можете контролировать.

Активный опыт использования изменяет самого пользователя.
Другими словами, это изменяет проблему, которую мы пытаемся решить

Mы полностью вошли в экономику обслуживания — сервисов. Сервис имеет совершенно иное представление о создании ценности.

Вместо вещи которая портируется в продукт, и предлагается клиенту в обмен на деньги, ценность сервиса не всегда четка обозначена и очевидна до тех пор, пока кто нибудь не проявляется и не начинает пользоваться вашим сервисом с вашей помощью или взаимодействовать с вами

Мир сервисов, в котором мы живем, все больше усложняется.
Сложные системы — это те, которые невозможно полностью смоделировать, не предсказать или проконтролировать или даже понять. У них есть свойство быть очень устойчивым, а также очень неряшливым, и это ведет к неизбежному и непредсказуемому отказу и ошибкам

На самом деле, вы пытаетесь контролировать их слишком тонко: будь то обучение инженеров с помощью отказов на техническом уровне или просто попытка слишком тчательно понять то, что происходит, и что может произойти дальше

Что происходит, когда вы переводите неудачи в успех?

Все эти вещи происходит в мире, где обыденная жизнь глубоко поглощена цифровой средой.
Становится все труднее и труднее получить опыт, который бы не включает в себя некоторую промежуточную программную составляющую.

Вы можете сказать, что мы все еще создаем вещи, объекты, которые должны быть неизменчивыми и стабильны после того, как мы сделали
но облом, который все это тоже рушится
софтверизация меняет то ккак мы пользуемся обычными вещами а стало быть и ценность от их использования и ценность их самих. Софтверизация иногда несет вплодь до обезценивания физических вещей
Кому теперь нужны наличные деньги? Ценность нала занижают все целеноправлено

Если подумать о "Бренде" как о представителе обещания что-бы заполнить/оправдать для нас набор ожиданий пользователей, то основа обещания бренда смещается/уходит от доставки стабильности, надежности и неизменности

он переключился на наблюдение за бесконечной дискуссии где природа продукта / характер продукта или сервиса непрерывно меняется в ответ на то, как люди испытывают это. И это смещающееся обещание оказывает на глубокое влияние IT и то как мы это воспринимаем.

ИТ больше не про то как, главным образом, делать за кулисами сезарную фабрику по производству семян более и более эффективно.

Это про то как обеспечить постоянный диалог и доставку сообщения к клиенту в этом процессе и учавствуют операции, разработка, дзайн и маркетинг

IT становится основной средой, которая позволяет дизайну стать непрерывным

Ну, неудачи и ошибки это здорово.
Давайте ошибаться, так часто, быстро и периодически, как только сможем.

Но провал сам по себе — это просто провал. если разговор, который у вас есть с вашими клиентами, не течет в том направлении, что значима, для каждого вовлеченного, они превращаются в набор абсурдных действий ошибок

Мы должны понимать, как цифровой бизнес, мы не просто являемся поставщиками предоставления softwere. Этот сервис о помощи справиться с целями

Причина, по которой я предоставляю услуги онлайн-выставления счетов, заключается в том, чтобы помочь мне своевременно производить оплату, поэтому я могу управлять рентабельным/профильным/профессиональным бизнесом

причина, по которой веб-сервисы amazon на год опережают конкурентов в облачных продуктах, заключается в том - это то, что не заботится о том, что там делает бизнес или какой уровень облачных сервисов там стекается. Они заботится о том, кто их клиенты и как они, и что они пытаются усвоить, и о том, как лучше и лучше помочь им решить проблемы.

Они буквально, непрерывно выпускают новые возможности, которые лучше помогают решить проблемы и начинать видеть новые - до такой степени, что уже кажется что они читают ваши мысли, потому что это так.

Когда вы проектируете сервис, а не / вместо программное обеспечение, вы должны учитывать полностью взаимодействие клиентов с вашей организацией, бизнес процессами и сотрудниками

Ок, мне нравится идея ваше сервиса и я готов подписаться.

Как в действительности понимять - КАК это работает в деталях детстве? как мне это применить? Как я переношу свои системы и свои данные и тренирую своих людей? как я получаю помощь с ними когда, мне это понадобится? Как я интегрирую это с остальной частью своего бизнеса? Какмне быть с сервисом зная, что мы не можем избежать того, что ошибки неизбежны/отказ невозможен?

И когда Бэкофис, бэкэнд, архитектура становится неотъемлемой частью пользовательского опыта, - это означает, что мы должны проектировать для сотрудников точно так же.

Нам нужно понять их jobs-to-be-done в точке что должно быть сделано чтобы начать помочь клиентам с их jobs-to-be-done

Во-вторых, нам нужно все продумать с точки зрения минимизации задержки и максимизации обратной связи - это неразрывная пара и по факту мы внедряем одно чтобы появилось/включилось другое

Вы можете сказать, что это мантра LeanUX - как мы максимизируем нашу способность учиться на данной единице работы и выжать максимум знаний из каждой проделанной работы. Но нам нужно расширить эту мантру на весь жизненный цикл сервиса и его операций:

Мы не делаем sprint demos в ajile разработке чтобы дать представление пользователям о том что мы собираемся выпускать. мы делаем это для того чтобы понять на сколько правильно мы поняли потребность. прежде чем выпустить.

Мы не делаем DevOps и continues delivery чтобы похвастаться количеством деплоев. Мы делаем это чтобы сгенирировать метрики и поделиться знаниями чтобы понять качество и релевантность всех обновлений.

Про клауд компьютинг

Мы должны расширить эту мантру на
как на взаимодействие клиента и компании , так и на все то взаимодействие внутри которые делает это возможным, где бы то ни было: между dev & ops или design & dev или два куска микросервисной команды A и два мира команды микросервиса B

Мы не выпускаем промежуточные/betta версии в гибкой разработке, чтобы рассказать людям о том, что мы собираемся выпустить. Мы делаем это, чтобы получить обратную связь о том, насколько действительно мы понимаем, ожидания до того как выпускаем

Мы не делаем DevOps или продолжаем доставку, чтобы мы могли похвастаться количеством развертываний/deployes в день. Мы делаем это, чтобы мы могли генерировать метрики и обмениваться знаниями, чтобы понять качество в релевантности тех, которые развертываются/deployes

Мы не используем облачные вычисления, чтобы просто уменьшить инвраструктуру или перевернуть с CAPEX на OPEX. Мы делаем это, потому что это минимизирует затраты и, что более важно, частоту экспериментов и адаптаций в реальном мире с реальными клиентами в режиме реального времени.

Когда неудача неизбежна нужно прекратить проектировать инженирить из экзистенс и напротив начать проектировать в возможности выжить и флориш к существующему
или
Вы должны прекратить попытки переделывать существующий порядок вещей и вместо этого спроектировать/создать возможность достигать и выжить и идеализировать поток в его настоящем

И разговор не в том что вам нужно класторизовать базы данных в датацентрах это так же сходит на уровень UI.

Когда неудача неизбежна и непредсказуема, нельзя просто сесть, расслабится и заняться проектированием того, что вы знаете там будет/случится/ проектировать для того что вы знаете.

Когда неудача неизбежна нужно изменить отношение к этому, чтобы воспользоваться этим

вы должны фактически начать выходить и искать его и превзойти его. вы знаете, что это есть где-то там, лучше избежите/выйдете из ситуации если будете знать/предполагать чем не будете

Это то, где такие вещи, как gamedays & chaosmonkey и "Blameless post mortems ", включаются в игру

Они все о том что вместо того, чтобы бояться провалов и превратить их в еще больше информации, которую можно использовать для изучения и улучшения

Речь не только о DevOps, инфраструктуре или ИТ

когда у вашей компании есть служба безопасности (когда, а не если), насколько хорошо ваш руководитель буде общаться?

поведение вашей компании перерабатывает/перевооружит ваш бренд или деградирует его

Если ваш маркетинговые компании или переделанное предложение не идут не так, как ожидалось. Винишь ли ты себя или ценишь тот опыт между тем, что ты ожидал случится и тем что произошло на самом деле, как информация об обучении

если мы собираемся принять решения дизайна в качестве решения проблем серьезно, нам нужно начать сдавать нашу привязанность к этой всей идее «сделано», выстраивая и понимая ее правильно

Суть service Design не в том чтобы делать хорошо спроектированные карты пользовательских взаимодействий, которые больше чем сама жизнь, чтобы распечатать на принтере и повесить на стену.

Дизайн должен стать «непрерывным процессом» понимания поведения пользователя и понимания того, как он меняется в условиях полученного опыта и меняющегося среды вокруг него

Для того чтобы это случилось операции должны стать обратно вводными данными в дизайн.

Традиционно мы рассматриваем операции как место, которое мы хотим быть тихими/ невидимыми

мы не хотим ничего слышать в ответ, потому что это бы означало одно из двух: мы все правильно поняли, сделали и выиграли, или же иначе эта поддержка успешно сдерживает разочарование в день

Вместо этого нам нужно начать выходить на улицу и, фактически, искать этот ценный объектив /ценное видение, как работают продукты и службы, когда выйдят за пределы нашего контроля

Нам нужны люди в системе, которые глубоко погружаются в опыт использования сервисом, чтобы начать понимать то, что они видели

нам нужно начать слушать реальность, но действовать нам нужно начать по тому, что мы слышим

Вся обратная связь в мире не имеет значения, пока вы не позволяете операциям и окружающему миру который показывает вам, начать влиять на ту работу которую вам необходимо сделать следующм