Дилемма кодирования обезьян

Это цитата из интервью с практиком с техническим опытом и ролью:

  

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

Я называю это «дилеммой обезьяны кодирования». Я уверен, что многие из вас, кто работает с UX, столкнулись с аналогичными ситуациями, в которых роль человека UX, конструктора взаимодействия или подобного рода несколько рассматривается как «угроза» для удовлетворенности работой разработчиков. Я согласен с тем, что внедрение нового опыта, такого как UX, означает разделение обязанностей и потерю власти в некоторых областях для других ролей.

Мой вопрос : какие подходы (процессы, инструменты, методы и т. д.) вы используете в своей работе как эксперт по UX, конструктор взаимодействия или аналогичный, чтобы преодолеть «дилемму обезьяны кодирования»?

Я также хотел бы узнать больше об этом, если вы знаете какие-либо ссылки.

100 голосов | спросил Pariya Kashfi 21 Mayam15 2015, 09:38:50

12 ответов


30

Использовать диалог, а не направление,

Использовать разговоры, а не принуждение


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

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

директива против совместной модели

Директивный подход является слабым по многим хорошо документированным причинам.

  • Разработчики чувствуют себя безмолвными, невовлеченными и недооцененными в процессе.
  • Процесс подавляет обратную связь вверх или замедляет ее.
  • Отсутствие обратной связи и итерационных механизмов делает ее медленной и неэффективной ... и многое другое

Совместная разработка

Включение коллажей в коллабораторы введите описание изображения здесь>> </p>

<p> Модели совместного развития обычно используют концепции совместной собственности, разговоров и итеративного развития для достижения нескольких целей: </p>

<ul>
<li>
<strong> Избегайте синдрома обезьяны кода </strong>, предоставляя разработчикам (и другим заинтересованным лицам) право собственности и активную роль в принятии решений. </li>
<li>
<strong> Улучшение двухсторонней связи </strong>, разрушая стены /силосы /функциональные барьеры, которые могут замедлить открытое сотрудничество. </li>
<li>
<strong> ускорить разработку </strong>, предоставив экспериментальный /прототипический /итеративный, а не линейный процесс, что приведет к более быстрому обнаружению ошибок /ошибок и ускорению разработки продукта. ... и другие преимущества. </li>
</ul>
<p> В рамках совместной модели развития <strong> профессионал UX становится посредником, а не директором </strong> деятельности продукта. </p>

<ul>
<li> Содействуя совместному процессу проектирования, руководствуясь идеями, облегчая разговоры и разделяя ответственность за процесс разработки продукта, профессионал UX <strong> максимизирует вклад участников команды </strong> вместо направления ресурсов команды для выполнения работы. </li>
</ul>
<p> Здесь есть много инструментов и фреймворков для облегчения совместной разработки: </p>

<ul>
<li> <p> <strong> Рамки </strong>, такие как Agile, Spiral, Lean и другие, обеспечивают общую структуру и руководство для совместной разработки продукта. </p> </li>
<li> <p> <strong> Поведенческие модели </strong>, такие как <a href= Flow , гиперфокус , Иерархия потребностей , N-Ach и другие помогают создавать психологические модели для мотивации разработчиков и дизайнеров в командной среде.

  • Методы командных процессов , такие как дизайнерские интервью, раскадровка, структурированное мышление и другие, обеспечивают совместные рекомендации по выполнению определенных задач внутри производственного процесса.

  • Надеемся, что эти термины /концепции станут отправной точкой для ваших дальнейших исследований.

    ответил tohster 21 Maypm15 2015, 21:00:27
    63

    Большинство разработчиков, с которыми я работал, имеют мнения о UX, и часто они могут быть действительными. Большую часть времени они вызывают больше головных болей, чем хотелось бы, но это в основном связано с отсутствием общения в команде. Коммуникация - это противоядие в этом случае. Я расскажу о некоторых передовых методах и идеальных сценариях, которые должны помочь проиллюстрировать некоторые стратегии для решения этой проблемы:

    Хорошие разработчики

    Хороший разработчик отложит команду UX, когда возникнет проблема, которая может повлиять на пользователя - не потому, что они обезьяны, которые не знают, что делать, а потому, что они уважают, что ваша роль - исследовать и решать проблему , Если у них есть мнения о том, каким может быть решение, они должны делиться им, но в равной степени с UXer вы должны спросить их, есть ли у них какие-либо мысли о том, как проблема может быть решена. Это не значит, что вам нужно бежать с ним, но, возможно, это лучшая идея! Вы никогда не знаете.

    Хорошие дизайнеры

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

    На практике

    Один пример того, что я делал ранее в течение цикла UX, исследующего определенную функцию (пусть и достаточно большую), должен был пригласить одного или двух разработчиков на начальные стартовые встречи и некоторые последующие семинары. Таким образом, они получат хорошее представление о том, чего вы пытаетесь достичь и почему, и имеете возможность предоставить информацию и отзывы. Это дает им чувство собственности в результате, что бесценно в поддержании морального духа команды. После этого, по мере того, как проекты развиваются, и обратная связь запрашивается у PO и т. Д., У меня иногда появлялись бы разработчики, чтобы получить их на итерациях дизайна. Это не всегда идеально, но если вы пропустите эту часть, вам по крайней мере рекомендуется организовать встречу, когда вы передадите проект от дизайна до разработчика. Таким образом, все стороны могут озвучить свои проблемы и напомнить друг другу о своей роли в этом процессе. (Надеюсь, что сдача встречи идет само собой разумеется ... но вы были бы поражены!)

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

    Дальнейшее чтение

    Одна действительно замечательная книга о UX, в которой есть раздел о взаимоотношениях между UXers и командой в целом, находится под Cover User Experience Design от Cennydd Bowles и James Box http : //undercoverux.com/. Это немного датировано в некоторых аспектах, но оно наполнено большим пониманием и вечным советом.

    ответил Chris 21 Mayam15 2015, 11:46:16
    29

    Это о организационной структуре и классическом менталитете силоса.

    Потерять силосы.

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

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

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


    Материал для чтения:

    Smashing Mag: Разрушение силосов, часть 1: Последствия работы в изоляции

    Leisa Reichelt: Сейчас все делают стратегию и Стратегия doesnâ € ™ t жить в силосе (или нет такой стратегии, как UX)

    FoolProof: Разрыв организационных силосов а>

    ответил Roger Attrill 21 Mayam15 2015, 11:56:01
    9

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

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

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

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

    P.S. Я бы подумал, что пользователь UX может попасть в описание «волшебной» обезьяны, так как многие люди рассматривают кажущиеся очень логичные аспекты исследований и испытаний, которые практикующие UX выполняют, чтобы быть своего рода «темной /черной» магией.

    ответил Michael Lai 21 Mayam15 2015, 10:02:03
    9

    Здесь уже есть отличные ответы.

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

    Разработка, основанная на тестах

    Из различных стратегий разработки программного обеспечения Test Driven Development (TDD) является одним из самых популярных в настоящее время.

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

    Тесты должны захватывать:

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

    Большая часть этого определяется работой UXer.

    Тесты могут быть написаны на достаточно естественном языке (см. Cucumber ) или используя язык программирования (надеюсь ) формат, понятный не программистам; что-то вроде этого:

    описать («преобразователь расстояния», function () {
        он («преобразует дюймы в сантиметры», function () {
            ожидать (преобразовать (12, «в») в («см»)). toEqual (30.48);
        });
    
        он («преобразует сантиметры в ярды», function () {
            ожидать (Конвертировать (2000, «см»). в («ярды»)). toEqual (21.87);
        });
    });
    

    TDD с ориентацией на человека

    Комбинация ориентированной на человека конструкции (что означает, что UX управляет дизайном системы и, следовательно, ее реализация) с TDD становится все более распространенным.

    Процесс выглядит примерно так (много сделано для большей ясности и сосредоточено на ключевом сообщении):

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

    Важно отметить, что тесты служат мостом между дизайном и реализацией. Аргумент часто вращается вокруг того, кто должен написать тест, с вариантами:

    • Дизайнер UX - нам нужно документировать многие из того, что тестирует в любом случае, поэтому вместо того, чтобы писать что-то в одном месте, которое затем преобразуется в тест, он платит, чтобы просто написать его дважды в синтаксисе который может быть легко преобразован в тест.
    • Личность QA
    • Разработчик - разработчикам часто приходится писать дополнительные тесты для внутренних блоков кода в любом случае и лучше всего разбираются в синтаксисе.

    Моим аргументом является то, что если рассматривать технологию round-trip engineering , то UXers должны быть теми, кто пишет тесты, которые захватывают большую часть их работы.

    Что это значит для разработчиков?

    • Во-первых, хорошие тесты обеспечивают хорошо очерченные спецификации .
    • Тесты сохраняют разработчиков много времени , так как код тестируется автоматически, а разработчик должен проверять все предыдущие действия с каждым изменением (чтобы дать один пример, структурированное поле ввода даты, которое я разработал, 64 тесты, большинство из них представляют собой случаи использования атома, такие как «если пользователь находится в частичном времени дня и нажимает TAB, выбор должен перемещаться на частичный месяц», если разработчик должен вручную проверить каждый вариант использования после его реализации вместе со всеми предыдущими вариантами использования, было бы 2080 тестов для запуска)
    • Тесты уменьшить количество ошибок .
    • Тесты позволяют разработчикам писать лучший код , так как они могут улучшить код, не опасаясь его нарушения.

    Хорошо, так что для всего этого нужно, что нужно? Разработчики должны писать код с четко определенными требованиями в форме тестов.

    Означает ли это, что «говорят, что делать?». Ну, в некотором смысле да. Но рассмотрите альтернативы - просто давая короткое предложение требуемой функции и надеемся, что разработчик выполнит надлежащее задание на проектирование и , чтобы написать тесты?

    Я бы сказал, что разработчики будут счастливее быть частью процесса HCID /TTD, чем любая стратегия, которая не позволяет ни одного из этих компонентов, ни обоих этих компонентов.

    Конечно, это все равно не означает, что мы не будем вовлечены в процесс проектирования, но вы должны помнить, что и их личность, и перспектива в системе понятны, чем их пользователи или дизайнеры UX.

    ответил Izhaki 22 Mayam15 2015, 00:30:36
    7

    Включение разработчиков в UX

    Разработчики умны и, как правило, хотят понять почему и «потому что это в спецификации» просто создает еще один разумный вопрос , почему он находится в спецификации? Объяснение, защита и получая все уважение, но вот конкретные действия, которые я нашел для создания рычагов:

    Пусть разработчик видит и чувствует проблемы пользователей

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

    Со-дизайн

    Хорошо организованный дизайн-семинар не только собирает множество идей, но и четко общается. Ключевой частью двустороннего диалога является то, что «скрытые gotacha's», которые позже могут появиться, и загрязнение конструкций обнаруживаются на ранней стадии. Таким образом, дизайнер не воспринимается как «поверхностный», а скорее часть команды, занимающейся nitty gritty.

    Разрешить разработчикам получать некоторые мнения

    Гибкая среда с надежным циклом обратной связи позволяет принимать решения в ближайшем будущем в любом случае. Позже, если требуется коррекция курса, ее можно сделать, и у вас все еще есть отличный результат для пользователя. Предоставление разработчикам любимого дизайна через два возможных результата (а) он очень сильно зависит от пользователей, и вы узнаете что-то, возможно, новое (б) оно плохо влияет на пользователей, и разработчики учатся лучше управлять UX. UX действительно нуждается в «праве вето», но использование этого в нужном месте и времени имеет решающее значение.

    Дизайн для реализации

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

    Образование

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

    Также, начиная с нетехнического приема, может быть задействован Дизайн повседневных вещей Дональда Нормана

    Настроить уровень взаимодействия по интересам разработчика

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

    ответил Jason A. 21 Maypm15 2015, 20:55:13
    4

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

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

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

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

    ответил Peter 21 Maypm15 2015, 17:32:13
    3

    Я думаю, что здесь ключевое слово - отличить сообщение от разработчика, что нужно сделать, и сообщить разработчику, как это сделать.

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

    Если разработчик UX уважает разработчика, разработчик UX не будет рассказывать разработчику, как это сделать. Разработка касается того, как делать то, что нужно сделать. Сосредоточьтесь на интерфейсе и оставите реализацию до разработчика.

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

    ответил Walter Mitty 21 Maypm15 2015, 14:41:45
    3
      

    Мой вопрос: какие подходы (процесс, инструменты и методы и т. д.) вы используете в своей работе как эксперт по UX, конструктор взаимодействия или аналогичный, чтобы преодолеть «дилемму обезьяны кодирования»?

    Я обновляю свое резюме и нахожу новую работу.

    К сожалению, для обоих кодеров и пользователей UX роль вашей роли в роли «кодирующей обезьяны» - это организационная культура. Самые большие красные флаги, которые я нашел, являются: a) Орг огромен и б) организация зациклилась на методологиях водопада.

    С Waterfall я обнаружил, что UX все чаще становится высокооплачиваемой ролью заметки. (Ну, надеюсь, высокооплачиваемый). Наша единственная работа - рисовать изображения для управления.

    Переход на Agile помогает. Это не излечивание, но приносит больше сотрудничества - как для команд UX, так и для разработчиков.

    Моя нынешняя проблема заключается в том, что я пытаюсь получить команду разработчиков, которой годами промывают мозги обезьянами. Они не знают, что делать дальше, когда мы спрашиваем «так, devs, что вы думаете?» :)

    PS (Это отличный вопрос!)

    ответил DA01 21 Maypm15 2015, 18:00:42
    2

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

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

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

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

    Затем вы разрабатываете новые отношения и завершаете отношения, которые не работают для вас по мере необходимости.

    ответил Adam Davis 21 Maypm15 2015, 17:12:34
    1

    Совместный не коллективный дизайн

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

    Совместная подразумевает ввод из разных ролей: (люди + опыт + Знание + перспектива и т. д. для достижения общей цели или цели. Результатом является сильное и жизнеспособное решение проблемы.

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


    UX - о методах и процессах и меньше о мнении

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

    - иметь четкую совместную модель разработки (лучше всего работает) с четкими и стандартизованными входами и выходами.

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

    - Привлекайте всех соответствующих людей в своей команде на ранних этапах доработки и экстернализации UX как можно больше: Понятно, что никто не любит быть в положении, когда они всегда реагируют на кого-то другого Работа! Люди любят испытывать чувство контроля над тем, что они делают, от консультаций, а не с информированием.

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

    - Согласиться с некоторыми принципами дизайна и создать библиотеку шаблонов, которая документирует различные варианты использования. (Quick Gain)

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

    ответил Okavango 22 Maypm15 2015, 18:14:44
    1

    Как и в борьбе с реальным расизмом, роль расизма лучше всего решать путем объединения людей. Работайте вместе, в одной команде.

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

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

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

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

    Возможно, иногда вы можете выглядеть дураком, но кому это нужно. Также, вероятно, вы можете ступить на пальцы людей, поэтому будьте осторожны и смиренны (но продолжайте это делать). Когда маленькие практики становятся нормой, тогда иногда можно начинать предлагать более крупные.

    ответил Jonny 22 Maypm15 2015, 19:54:54

    Похожие вопросы

    Популярные теги

    security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132