UXPUB 🇺🇦 Дизайн-спільнота

Cover image for Хороший продукт не появляется случайно
Редакція
Редакція

Опубліковано • Оновлено

Хороший продукт не появляется случайно

#ux

В данной статье используются слайды и заметки из моей презентации 21 июля 2016 года на конференции Design & Content в Ванкувере. Я хочу начать с простого вопроса к вам. Как вы делаете то, что вы делаете? Отбросим в сторону вопрос грамматики и аллитерации. Суть вопроса в том, какие вы производите действия (повторяющиеся и обязательные) для того, чтобы преуспеть в своем деле? Пока вы думаете об этом, я хочу рассказать вам о своем опыте ответа на данный вопрос. 2 PMI процесс. Так мы создавали сайты в 1998 Я приступил к созданию разных вещей в Интернет в 1994 году. Я пережил первую волну интернета, когда мне приходилось работать над плохо управляемыми проектами. Они были настолько перегружены самим процессом, что не имели возможность адаптироваться к текучести создания ПО. Требования, описанные в первый день, становились неактуальными на второй. Плюс, сам процесс вынуждал отменять то, что было согласовано раньше. Такая смена менеджмента пагубно влияла на весь процесс. Вы могли работать над проектом, который был основан на неверных решениях изначально. Это приводило к сбоям в процессе дизайна и технической части, что наносило большой вред продуктам и проектам еще до запуска. Проект MS Проект MS Основным проектным документом была диаграмма Ганта, которая казалась ответвлением Microsoft Project. Если вам довелось застать это время, вы наверняка помните целые стены покрытые проектами диаграмм Ганта. Диаграмма Ганта показывает рабочие процессы и их взаимосвязи. Если вы слышите, как люди обсуждают процессы “водопада”, они явно знакомы с таким рабочим процессом. Диаграмма визуально представляет собой “водопад”, как поток зависимостей. Генри Гант и его диаграмма Генри Гант и его диаграмма Диаграмма была названа в честь Генри Ганта, менеджера времен производственного столетия, который верил в методы научного управления. Научный менеджмент, также известный как тейлоризм, - это структура управления, которая анализирует и синтезирует рабочие процессы. Его главной задачей является повышение экономической эффективности, особенно производительности труда. Это попытка максимизировать экономическую эффективность на заводах и в цехах, за счет минимизации потерь, вызванных неэффективными работниками. Работа Тейлора и Ганта была дискредитирована и к 1930-м годам, от нее, в значительной степени, отказались. Теории были бесчеловечными и подавляли моральный дух рабочих. Поэтому их реализации оказались провальными. Научный менеджмент основывается на понятии, что есть один лучший способ для решения задачи. Также, предполагалось, что, благодаря научным измерениям, вы можете обозначить наиболее эффективные движения рабочего (например, оптимальный способ копания угля) с последующим указанием рабочему, какие движения ему выполнять. Недостатком научного управления было то, что у него не было четких методов внедрения технических инноваций и совершенствования. Несмотря на провал, некоторые части научного управления сохранились и по сей день. Например, использование почасовой оплаты и диаграмм Ганта. Когда я познакомился с работой Ганта в середине 90-х годов, системе было уже 80 лет. Она являлась пережитком, задуманным для эффективного производства чугуна и пороха, которую применили к созданию программного обеспечения и дизайну. 5 Но к началу 2000-х, “трещины” начали появляться в самых чистых методах построения программного обеспечения. Наблюдался рост создания ПО с открытым исходным кодом и низкой стоимостью аппаратных средств. Сейчас уже стало понятно, что многие веб компании первого поколения были провальными из-за того, как они создавали свои продукты. Они пытались адаптировать чистые подходы к разработке ПО, что повлекло за собой реакцию “отказа” систем от такого подхода. К середине 2000-х годов, появилось новое поколение компаний, которые использовали новые, более гибких методов. Появление Agile Появление Agile Такой переход произошел во многом, благодаря группе 17-ти разработчиков ПО, которые встретились в Snowbird (штат Юта) в 2001 году для обсуждения более простых методов разработки. Они согласовали и задокументировали свод правил, которые мы сейчас называем Agile. Эти ценности заложили основу для изменений и адаптивности. Я верю, что Agile и прагматичный дизайн появились до 2006 года, но это самые яркие примеры Я верю, что Agile и прагматичный дизайн появились до 2006 года, но это самые яркие примеры Примерно в это же время, некоторые из сообщества дизайнеров пришли к подобной реализации как и разработчики программного обеспечения. Мы постепенно переставали создавать пачки документов, типа 200 страниц описания концепций и статичных набросков, вместо того, чтобы разглядеть огромную ценность в создании работающего ПО и вносить правки в процессе создания. 8 В 2000-х наметилась тенденция к сокращению циклов бизнес активности и разрыву традиционных бизнес моделей. С развитием технологий, затраты на которые были минимальны, скорость и гибкость уже не были конкурентными преимуществами для бизнеса, но были критично важны для его существования. К концу 2000-х годов, в компаниях Силиконовой долины утверждали, что даже провал является преимуществом, если он наступил сразу. Гибкие методы раскрывали такие неудачи быстрее, и как следствие, лучше. 9 Публичный провал healthcare.gov казался неизбежным для всех, кто принимал участие в его разработке. Сайт, который был создан людьми с использованием методов индустриального века и промышленности должен был быть спасен новой командой разработчиков, которые привнесли популярные методики в Силиконовую долину и Вашингтон. Данная ситуация стала символом окончания борьбы двух противоположных мировоззрений. В этой борьбе основной спор уже решен в пользу прагматизма и гибкости а не жестких методов. Именно внутри этой среды, мы пожертвовали процессами в пользу гибкости. Процесс стал частью устаревших методов и главным врагом прогресса. Инструменты везде Инструменты везде Так как мы начали по достоинству ценить гибкость процессов, у нас появилась возможность использовать данный подход в работе и снизить влияние структурных методов на создание программного обеспечения. Это позволило нам открыть творческие способности и создавать такие решения, которые могут быть очень полезными в повседневной жизни. В тоже время, мы стали той самой индустрией, которая тратит массу времени на обсуждения достоинтсв одного Javascript фреймворка или прототипа ПО п сравнению с другим. Мы готовы бесконечно обсуждать, должны ли дизайнеры писать код, и если да, то на каком языке. Мы стали одержимы скоростью, гибкостью и возможностью достижения их. Хотя лично я верю в быстрые правки и тестирование… 11 когда скорость становится главным критерием, это плохо… очень плохо. 12 Когда мы останавливаемся и спрашиваем себя “как мы делаем то, что мы делаем?”, у нас действительно хорошего ответа. Мы стремимся назвать инструмент, который мы используем. Спросите дизайнера, как он рисует и более часты ответ будет: “в Sketch”. Это тоже самое, что спросить опытного плотника, как он создает предмет мебели. И он ответит: “с помощью молотка”. Итак, позвольте мне вернуться к изначальному вопросу… “как вы делаете то, что вы делаете?” Этот вопрос мучил меня последние несколько лет, и я спросил множество людей. Самый частый ответ был такой… 13 “Когда как” - это ужасный ответ. Но это логичный ответ в условиях нашего существования в индустрии, в которой ценится быстрая реакция и скорость мысли. Задумайтесь о вашей реакции, когда вы слышите ответ “когда как” на важные вопросы. Вопрос: Капитан, как вы управляете самолетом? Ответ: Когда как. Вопрос: Доктор, как вы будете делать операцию? Ответ: Когда как. Вопрос: Ты любишь меня? Ответ: Когда как. Существует две проблемы с ответом “когда как” на вопросы. Первая. Вы не уверены в том, что то, что вы делаете, вы делаете действительно хорошо. Это означает, что вы не нашли для себя какой-либо подход, который дает вам возможность многократно достигать успешного результата. Вторая. Это неправда. Есть целый набор вещей, которые вы делаете инстинктивно: решаете проблемы, пишите, рисуете, изучаете поведение, собираете и анализируете данные. Вы просто не нашли ту закономерность, которая существует для постоянного успешного результата. 14 Перед началом любой дискуссии или обсуждения, согласитесь, что все, что вы делаете не является судьбой. Вы должны понимать, что создание продукта или чего-либо еще - это не просто невидимая рука помогает вам. То, что вы делаете, может быть достигнуто при помощи повторяющихся действий и шаблонов. Это не означает, что удача или планирование времени не являются переменными, но они не единственные переменные. Это также не означает, что процесс гарантирует успех, но он склоняет вас к нему. 15 Если вы считаете, что для поиска рынка сбыта достаточно бросить много вещей в стену и надеяться, что что-то “зайдет”, то говорить о методе планирования очень трудно. 16 Если вы верите в шанс. В таком случае, вы могли бы начинать любой проект с доски мечты. И вы утверждаете, что ваш проект стоящий, потому что вы знаете “секрет”. Если вы в это верите, любое обсуждение процесса - пустая трата времени. 17 Я не верю в это. Я не верю в случайности. Я верю в то, что лучшие продукты не появляются случайно. 18 Знакомы с этим? Это часть презентации, в которой Spotify объяснял как они внедрили Agile. Всякий раз, когда я начинаю говорить о намеренном создании продукта, это самый яркий пример того, как не быть жестким. Два момента касательно диаграммы выше:

  1. Данная диаграмма - самое простое объяснение повторяющегося дизайна. Я не думаю, что если вы хотите создать автомобиль, вы сначала придумаете скейтборд. Это означает, что, очевидно автомобиль можно создать на основе мотоцикла.
  2. Второй момент состоит в том, что мы так и не сможем поговорить о следующем слайде презентации…

19Другой слайд, о котором говорят меньше, говорит о том, что вам необходим план того, как вы делаете то, что вы делаете. Грубые наброски адаптивной архитектуры это то, что отдаляет нас от визуальных досок. Но что же такое грубые наброски адаптивной архитектуры? 20 Такие архитектуры являются набором связей, которые мы используем для понимания динамических окружений. В импровизационной музыке грубая архитектура темпа и тональности. До тех пор, пока музыканты не нарушают эту архитектуру и слышат друг друга, они могут создавать бесконечную музыку. 21 В импровизационном театре грубая архитектура представляет собой набор правил типа… скажи “да, и”, “добавь информацию после и”, “избегай вопросов”. Если вы спросите комика, как он импровизирует, он не ответит “быть смешным”. Он расскажет вам о наборе правил, которые позволяют ему быть смешным.

Самую лучшую грубую архитектуру для создания продуктов я подсмотрел…

22 в футболе. Футбол является динамической средой с изменяемыми переменными, на которые должны реагировать игроки и тренеры. Команды стараются двигать мяч по полю бегая или пасуя, в разных играх. В условиях наших реалий, все, что нам необходимо знать о футболе - это то, что он является примером грубой архитектуры. И защитная и атакующая игра имеют одну конечную цель - победа в игре. Для тренера нет смысла заранее определять, каким образом пойдет ход встречи до выхода игроков на поле. Тренер не знает, какой вид игры его команды будет иметь больший успех. Также, нет особого смысла давать каждому игроку возможность делать на поле все, что они считают нужным. Для победы в игре необходим высокий уровень координации и командная работа. 23 На протяжении своей карьеры, тренер будет выводить свою команду на сотни, если не тысячи игр. Описания стратегий этих игр собираются в план игр. Если вы никогда не смотрели футбол, такие планы выглядят вот так… 24 На самом деле, это не сильно важно, понимаете ли вы, что конкретно задумал тренер в этой игре. Самое главное - понять архитектуру игры. Процесс игры согласован и имеет четкий план действий в конкретной ситуации. Когда тренер говорит: “давайте отнесем Статую Свободы”, каждый игрок понимает, что это значит и что ему необходимо сделать. В нашем мире, когда вы скажете “давайте создадим MVP (самый полезный игрок)”, хоть кто-то поймет, о чем вы говорите? Разве каждый из нас понимает свою роль в игре? Если вы когда-то смотрели футбол, вы видели, как тренеры держат ламинированные карточки. 25 На этих карточках возможные варианты поведения игры и решения таких ситуаций. Это позволяет тренеру быстро принимать решения в зависимости от создавшейся ситуации. У тренера может быть описано 1000 игр, но он использует только одну для определенной ситуации. План игры План игры Такие карты содержат в себе описание игровых ситуаций. Такие карты тренер создает на протяжении всей своей карьеры. Это своего рода ответ тренера на вопрос “Как они делают то, что они делают”. 27 Я убежден, что нам также необходимо создавать такие планы игр при создании продуктов. Нам необходимо иметь такие наборы возможных вариантов для возможности создавать продукты быстрее и эффективнее. Создание планов игр того, КАК создавать продукты - важно для каждой компании, но многие этого не делают. 28 29 30 Наличие утвержденного формата для документирования игр, очень важно для работающего плана. Игры подобны кулинарным рецептам, где необходимо иметь стандартный формат (ингредиенты, процесс приготовления...), который будет легко читать и воспринимать. Ваш план игры также должен иметь утвержденный формат. Конечно же, вы можете создать любой шаблон, но вот некоторые моменты, которые можно взять из футбольных игр. 31 Назовите свою игру - названия игр помогут создать общий язык. Вам необходимо удостовериться, что ваши определения понятны каждому. Когда бежать - обозначьте ситуации, когда начинать игру. Так как много игр могут быть уместны на любом этапе жизненного цикла продукта, есть игры, которые нужно играть только в определенных ситуациях. Зачем бежать - если команда играет хорошо, что они ожидают? Почему эта игра важнее чем другие действия команды, которые могли бы также принести пользу. Роли - обозначьте существующие роли в игре и что ожидать от каждого игрока. Как бежать - определите этапы игры. Какие повторяющиеся действия необходимо предпринять для этой игры. Советы - все, что команда должна знать или полезные ресурсы. 32 Я вижу много команд в Facebook, которые играют в такие игры. Дизайн спринты. Дизайн спринты - это небольшая игра, которая является особой частью большой игра, целью которой является общий прогресс. У спринтов есть набор общих и отдельных действий, выполняя которые, вы можете достигнуть ожидаемого результата. Они содержат повторяющиеся шаги. Дизайн спринты - это 5 дней, которые предполагают четко прописанные действия и роли. Даже при том, что дизайн спринты отличаются, они имеют общую архитектуру. Использование спринтов особенно полезно на ранних стадиях создания продукта, но могут использоваться на протяжении всего процесса. http://ux.pub/oficialnoe-rukovodstvo-po-google-design-sprint-metodologiya-dizajn-sprintov/ 33 Карты контента, прототипы, локализация, аудит, планы запуска… это игры. Все, что вы делаете с использованием повторяющихся действий - это игра. 34 Вы можете использовать много игр… 35 … а некоторые можете использовать редко. 36 Мышление терминами плана игры позволит вам охватить процессы, направленные на постоянное улучшение, так как у вас всегда есть возможность удалить старые игры и постоянно создавать новые. 37 Игры можно группировать по вашему усмотрению… возможно вам больше понравится метод дизайн мышления Стенфордской D-School. Организуйте ваши игры так, чтобы было четко видно каждую стадию. 38 Организуйте более развернутую модель. 39 Игры можно группировать по дисциплинам 41 или ситуациям. Команды могут увидеть себя в таких ситуациях, и здесь есть игры, в которые уже играли. Итак, если вы хотите проверить идею, у вас есть возможные варианты. Если вы хотите расставить приоритеты или определить самое главное, есть игры, в которые нужно играть, если продукт не работает. 42 Поэтому, когда в следующий раз вас спросят “как вы делаете то, что вы делаете?”, просто покажите им свой план игры.


Перевод статьи Jon Lax

Топ коментарі (0)