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