Интеграция
Чтобы приступить к обсуждению, вначале надо поговорить об интеграции. Интеграция — это…
действие или случай объединения в единое целое.
Частая интеграция помогает людям более эффективно решать задачи:
- Вы и я заблудились в лесу. Мы договариваемся разделиться, исследовать обстановку и периодически возвращаться на условленную поляну, чтобы интегрировать наши находки (например, я нашёл воду, вы нашли убежище).
- Учитель проводит еженедельную проверочную работу. Оценки за неё не влияют на табель, но она предназначена для интеграции на нескольких уровнях: 1) для закрепления пройденного за неделю материала и 2) для проверки прогресса учеников, на основании которой планируются будущие уроки и выявляются слабые места. Эта проверочная работа помогает «свести всё воедино» и «понять, как у нас дела».
- IKEA закладывает интеграцию в конструкцию своей мебели. Собирая мебель от IKEA, можно на время зайти в тупик (если запороть какой-то шаг), но практически невозможно довести неправильную сборку до конца, разве что если проявить недюжинную фантазию.
- Проектировщик горных велосипедов собирает/изготавливает опытный прототип и делает на нём пробную поездку. Эта поездка интегрирует ряд дизайнерских решений с реальными условиями дороги.
- Команда из пяти человек пытается периодически интегрировать вклад всех участников в проект и «посмотреть, всё ли сходится». Команда дизайнеров регулярно встречается, чтобы покритиковать друг друга и «убедиться, что их дизайнерские решения имеют прочное и веское обоснование».
Проще говоря, интеграция снижает риск и помогает нам решать задачи. И так во всём.
Agile и интеграция
Вот мысль, которая может помочь UX-проектировщикам, пытающимся разобраться в Agile.
Как и многие из подходов к проектированию, которые вам знакомы и близки, Agile основан на частой интеграции. Самоорганизующиеся команды, работа напрямую с заказчиком, ретроспективы, ежедневные планёрки, самодостаточность, сосредоточенность на «рабочем продукте» и качестве, дробление работы на небольшие части, — всё это поощряет более частую интеграцию.
Существует, однако, ключевое различие, когда речь о разработке ПО, и об этом различии стоит поговорить. Недавно я описывал Lean и Agile своей подруге, которая занимается дизайном обуви. Она отметила:
Похоже на то, как мы проектируем обувь — тесно сотрудничаем с инженерами, придумываем прототип, проверяем его, оттачиваем дизайн и подготавливаем его к производству. Дизайнер проектирует обувь: у некоторых подход не очень технический и есть только замысел и набросок, а у других — более технический. Дизайнер выбирает материалы. Директор по материалам находит и закупает их. Инженеры занимаются подгонкой, затратами, маржей, возможностью изготовления такой модели, качеством и производством.
Звучит знакомо. Разница в «готовности к массовому производству».
Обувь итерационно проектируется, а затем массово производится. Некоторые пытаются распространить эту модель на ПО. Проектировщик может разработать и собрать прототип, периодически показывать этот прототип пользователям, постепенно совершенствовать его и — когда его всё устраивает — передать «этот проект» инженерам для «сборки» или «производства». В этом процессе присутствует интеграция, но в момент передачи — лишь частичная. У прототипа «нет потрохов»… он как здание без ОВКВ, канализации, электричества, без жителей и без структурной целостности.
В отличие от опытного прототипа обуви, который можно надеть на пробежку, прототип программы на самом деле ещё не «работает». «Писать код» — это и значит заниматься проектированием ПО. Код — это и есть «проект», готовый к «сборке» (многократной) сервером сборки. Так что без кода проектирование не завершено.
И это, возможно, не страшно. Произошло обучение (и частичная интеграция), и полученные знания достаточно ценны. Множество агентств работают таким образом, потому что их заказчики хотят увидеть продукт, «точно как он будет выглядеть». Но вы навлекаете на себя ряд знакомых рисков, принимая этот подход:
- Преждевременная сходимость
- Проект технически нежизнеспособен
- На стадии проектирования рассчитывали на «большой кусок»
- Прототип «хорошо ведёт себя на тестировании», но на самом деле не удовлетворяет потребностей пользователя
- Вы упускаете возможность ранней поставки заказчику продукта, имеющего ценность (и получения знаний)
- Вы упускаете возможность раннего вовлечения инженеров в обмен идеями
- Конечный продукт не полностью воплощает то, что технически достижимо
К делу
Так вот, перейдём ближе к делу. Теоретически, предназначение Agile — предотвращать эти риски. Но Agile — как и многие другие вещи в безжалостном мире бизнеса — зачастую не может тягаться с вездесущей угрозой помешательства на результате, театра успеха и сокращения издержек. Поверьте мне… она существовала задолго до Agile.
Как объяснила моя подруга — продуктовый дизайнер ПО:
Если у меня есть выбор — начать с подробного проектирования или попытаться работать по Agile, я всегда выберу начать с подробного проектирования. Почему?То, о чём ты говоришь, происходит редко. Всегда надо «выкатывать, выкатывать, выкатывать». Мы не переориентируемся. Мы не совершенствуем. Владелец продукта хочет только поставить «Выполнено» в Jira. Минимально жизнеспособный продукт — это оправдание, чтобы выпустить фигню и забыть о ней. Я гарантирую, что если тщательно подойду к тестированию прототипа, то у меня получится лучше, потому что его увидят пользователи. Будет не НАСТОЛЬКО замечательно, как если работать по идеальному Agile, но лучше, чем ничего. То есть у меня сложности даже с тестированием удобства интерфейса. Так что, знаешь… да, в теории всё это прекрасно, но так не бывает.
Agile для проектировщиков (в теории)
В теории, закономерности вроде Agile должны быть огромным подспорьем для проектировщика. Можно работать итерациями и доставлять заказчикам штуки, которые работают (и не ломаются). «Первый проход», вероятно, будет труден и сосредоточен в основном на сборе данных по ключевым вопросам. С каждой последующей итерацией «штука» будет оживать, выполненная всё более добросовестно и гладко. Необязательно выпускать её для всехпользователей — сойдёт и закрытый бета-тест — но ПО по своей природе хорошо приспособлено к быстрым итерациям и совершенствованию. Это больше похоже на проектирование услуг и управление каким-нибудь рестораном, чем на проектирование товаров для массового производства. Еда не поддельная, услуга тоже… но вы продолжаете совершенствовать.
Что важно, никто не запрещает мыслить более целостно… просто вы будете итеративно откалывать по кусочку от вашего большого целостного комка (примерно так же, как в контексте Agile подходят к архитектуре). Команда вам скажет спасибо за целостную картину.
Agile для проектировщиков (на практике)
Это была теория. На практике с помощью закономерностей Agile можно «выкатить» посредственный продукт очень скоро либо потрясающий продукт относительно скоро. Сокращаемые издержки можно сокращать быстрее. Возможности можно ловить и пускать в дело быстрее. Это такой чёрный ящик с силовыми функциями, подталкивающими к частой интеграции.
Проектировщики часто уверены, что:
- Проектировщик должен «определять и проектировать», а инженер должен печатать/собирать/строить
- За инженером нужен глаз да глаз, и без проектировщика он всё испортит
- В контексте спринтов и работы бок о бок с разработчиками ПО нет места глубокой, творческой, целостной работе над проектированием
- Agile — поскольку его проектировали не проектировщики — непременно каким-то образом настроен против потребностей проектировщика (и пользователя)
- Agile по своей структуре ориентирован на результат и поощряет работу в режиме фабрики функционала
- Agile поощряет мелочное, скучное мышление, и в итоге команда не видит дальше собственного носа
- «Технари» стремятся командовать парадом, все козыри у них на руках, а проектировщики должны защищать себя, чтобы хорошо работать
Страдание.
Agile (враг или же…)
Короче говоря, Agile — враг. По словам моего знакомого проектировщика:
По-моему, Agile, как его ни определи, на практике — именно то, с чем я воюю за эффективное проектирование в организациях, где/с которыми работаю.
На что я ответил:
С этого места поподробнее. А то в моей работе это — традиционные взгляды менеджеров среднего звена, косвенные метрики, театр успеха, управление по целям, фиксация на результате, недальновидность, недостаток измерений, традиционный подход к финансам и бюджету, противоречие между фокусом на человеке или на команде, короткие контракты, недостаток психологической безопасности и ментальность тянитолкая. Agile тут ни при чём.
А другой проектировщик поддакнул:
Давайте не будем толочь воду в ступе. Враг и настоящих Agile-энтузиастов, и специалистов по UX/проектированию в 2018-м — это, как говорит Джон, недальновидное, ориентированное на результат мышление, подстёгиваемое сосредоточенностью на краткосрочных финансовых целях, а также весь комплекс культурных последствий этого мировоззрения.
Я предвзят. Я согласен.
Что же теперь?
Так каково же наше положение? Проектировщики имеют право беспокоиться. По крайней мере, в каскадной модели никто не орёт «выкатываем» раньше времени, посреди проекта. У проектировщика есть время, чтобы работать, а не скакать по конвейерной ленте спринтов. А так как искомую «штуку» собирают большим куском, у них есть время на целостный подход к задаче проектирования с самого начала. «Хороший» каскад всегда лучше злоупотребления Agile.
«Хороший» каскад всегда лучше злоупотребления Agile.
Что же можно сделать? Я вижу два широких подхода:
- Размежеваться
- Расти над собой всем вместе
Размежеваться — значит продвигать процессы, где проектировщики окапываются выше по течению, чем разработчики ПО (старое доброе «проектирование, потом сборка»). В среде, погрязшей в работе на результат, это не самая плохая идея. Может случиться хороший проект. Разработчикам, возможно, даже понравится, ведь умеренно хорошее проектирование всегда лучше фигового.
Расти над собой всем вместе тяжелее. Это значит…
- Открыться всем возможностям частой интеграции.
- Прочно закрепить кроссфункциональные команды по разработке продукта.
- Продвигать качественное проектирование в контексте кроссфункциональных команд.
- Продвигать такой итерационный подход, который выгоден пользователю (не останавливаться, когда тестирование успешно пройдено и руководство требует перехода к следующему проекту). Результаты важнее итогов.
- Способствовать совместному проектированию с разработчиками ПО и другими заинтересованными лицами.
- Ограничивать работу «против течения» — вместо этого нужно стремиться сотрудничать с другими участниками команды и пройти этот путь вместе.
- Вникать и приспособляться в сотрудничестве с участниками своей команды, подстраивать свои рабочие договорённости и процессы под достижение наилучших результатов (и довольных участников команды). Раз вы проектировщик, то, вероятно, можете с этим помочь.
Вывод
В заключение я хотел бы поделиться личным наблюдением. Единственный способ побороть недальновидность и сокращение издержек — показывать прекрасные результаты. Если результат работы не ощущается, то, как её ни делай, появится чувство «движения к провалу» и отступление обратно к фиксации на результате. Любой «улучшенный» способ работать чреват злоупотреблением.
Я считаю, что проектировщики как никто другой способны помочь команде разработчиков ПО «расти над собой», прекрасно выполняя свою работу и помогая каждому стать (чуть-чуть) лучшим проектировщиком.
Что же касается ненависти проектировщиков к Agile… могу сказать, что Agile представляет собой некие закономерности, которые в определённый момент (и в определённом контексте) «сработали». Уверен, проектировщики могут понять, каково черпать вдохновение из многих традиций, чтобы разобраться со своей задачей. Акцент на частой интеграции, надеюсь, вам знаком. В Agile ключевой момент — использование этой частой интеграции для достижения высокого качества, а не посредственности.
Перевод статьи John Cutler: “Is Agile the Enemy (of Good Design)?”
