Я работал и с такими, и с такими. Мне куда интереснее с технарями.

Вообще мультидисциплинарные специалисты самые крутые.

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

О! А как ты совмещал юх продукта и аджайл?

Мы кажись уже говорили ранее об этом)

Не помню

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

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

Вот об это есть хорошая статья в хуиксе

Юзеры всегда косячат

Простите, что так пропал - решали тут на работе сложную задачу про волка, козу и капусту, которых надо переправить на другой берег в режиме Scrum’а (скрам-мастер, распевание скрам-псалмов по утрам и перевешивание стикеров с места на место прилагаются). Поскольку меня злобно у вас украли, я хочу отомстить ЭТОМУ ВАШЕМУ СКРУМУ и сказать про него от себя пару ласковых.

Точнее, про сам СКРУМ я рассказывать не буду - про него уже отхоливарено столько, что на двадцать гражданских войн хватит, - но хочу порассуждать о том, как СКРУМ взаимодействует с UX.

Взаимодействует он, прямо скажем, херово. Классический СКРУМ (насколько к нему вообще применимо слово «классический») предполагает, что у нас есть 3 роли - СКРУМ-мастер, продакт овнер и толпа разработчиков, разношерстных как средневековые бриганды. Продакт овнер определяет приоритеты и переживает, СКРУМ-мастер устраивает стендапы и перевешивает стикеры, а бриганды берут под козырек и совместно пилят фичи в рамках спринта - двух недель или, там, месяца.

По замыслу СКРУМ-фундаменталистов, в этот момент должна устанавливаться благодать как на картинах эпохи романтизма (пейзане и пейзанки, коровы на залитом солнцем лугу и так далее); в реальной жизни вместо этого в итоге выстраивается типичная картина Брейгеля-старшего (алкашня, писающие собаки, разруха и уныние), особенно если говорить про UX-составляющую.

Почему так происходит? СКРУМ предполагает, что команда разработчиков обладает так называемыми Т-компетенциями: каждый специалист со временем прокачивается по смежным навыкам, и в идеальной перспективе аналитики начинают разбираться в коде, а разработчик - пропитываться аналитическими компетенциями, а все вместе они начинают учиться хитростям профессии QA. Сам по себе подход здравый: T-образные компетенции помогают балансировать нагрузку на команду и всем скопом наваливаться на задачи по аналитике и разработке.  Ряд идеологов, впрочем, останавливается на делении на аналитиков и разработчиков, но общей сути это не меняет - все в команде начинают заниматься всем, попутно пропитываясь духом продукта, развивая чувство локтя и так далее.

Вся эта схема работает ровно до того момента, пока в СКРУМ не вклинивается UX. И вот тогда начинаются интересные вещи:

1. Наши бриганды - аналитики, девелоперы и QA - с жутким скрипом учатся UX-подходам, не понимают этой штуки и начинают творить лютую продуктовую фигню.
2. В процесс привлекается UX-дизайнер, который с порога начинает ЛЮТО, БЕШЕНО страдать: выполнение его работы требует долгих исследований и танцев с бубном, которые выходят за рамки спринта (что с точки зрения СКРУМа грешновато - все должно вписываться в спринт и преображаться в конкретный командный артефакт), а ту работу, которую он может сделать руками здесь и сейчас, он делает за три дня и сразу начинает скучать.
3. «ДАВАЙТЕ НАУЧИМ ЭТОГО СРАНОГО ДИЗАЙНЕРА КОДИТЬ ЧТОБЫ НЕ ПРОСТАИВАЛ» - начинает вопить СКРУМ-мастер и оказывается не прав, потому что большинство UX-дизайнеров органически не любят кодить и этому учиться не будут. Кроме того, если он даже будет кодить - кто ж будет исследовать и делать миллион подготовительных приседаний к дизайн-работе, которые требуют массу времени и сил?
4. «ДАВАЙТЕ РАСШАРИМ ДИЗАЙНЕРА СРАЗУ НА НЕСКОЛЬКО КОМАНД» - озаряет еще кого-нибудь, и бедного дизайнера начинают рвать на задачи нескольких команд сразу, от чего у него теряется весь фокус на задачах, подрывается командный дух и появляется ощущение, что он вернулся в старое-доброе агентство с 10 проектами в параллели и 20 менеджерами над головой.

5. «ЛАДНО ЛАДНО ДАВАЙТЕ ПРОСТО ПУСТИМ ДИЗАЙНЕРА РАБОТАТЬ НА ОПЕРЕЖЕНИЕ» - великодушно решает какой-нибудь сердобольный продакт овнер и разрешает дизайнеру планировать свою работу самостоятельно в отрыве от основного СКРУМ-процесса. И в этот момент для UX-дизайнера весь СКРУМ исчезает как с весенних яблонь дым: измученный дизайнер начинает работать по собственному, напрочь отвязанному циклу, перевешивая задачи на своей крохотной досочке и ориентируясь на единственную цель - давать основной СКРУМ-команде вовремя макеты.

На этом все выдыхают, успокаиваются и продолжают работать дальше. И все бы ничего, кабы не одно «но» - это уже не СКРУМ единой командой, а постоянное жонглирование разными методологиями и разными циклами разработки со всеми сопряженными рисками. Некоторым людям и особо либеральным Scrum-мастерам это ок, но многие упоротые СКРУМ-мастера начинают от того беситься и выть «УЧИТЕ ДИЗАЙНЕРА КОДИТЬ» и «УЧИТЕ РАЗРАБОТЧИКА ХУИКСУ». Наверное, где-то работает и такой подход с прокачкой, но в нормальном виде я его пока не встречал.

И не только я: на Западе очень многие проходились по сложным отношениям СКРУМа и UX, в том числе наши любимые гуру-деды из Норман-Нильсен Групп.

Так что если вас угораздило женить UX и СКРУМ, готовьтесь рвать задницу - не себе, так окружающим. Жизнь - все-таки сложная штука.

#изкрестьянскогобыта

Читала)

Ну вот. Ничего лучше нет, как быть впереди разработки - на 2-5 недель)

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

Хм... Меня сейчас по факту так и поставили. Совпадение или реально переосмысление, хз)

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

https://www.youtube.com/watch?v=QrNi9FmdlxY Норм)

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

Все равно мы показываем 1 экран, и скролить до пагинации не нужно