Т.к. я не программист, и как таковой практики экстремального программирования не имею, то буду рассматривать данную методологию именно в общем смысле, т. е. как подход, проецируемый многими на различные области разработки чего-либо.
Почему я вообще решила высказать своё мнение? Дело в том, что в команде, в которой я работаю на данный момент, навыки XP (экстремального программирования) являются одним из очень желательных условий при приёме на работу как программистов, так и проект-менеджеров (ПМ).
Далеко не все пиэмы (проект-менеджеры) имеют опыт сотрудничества с проектировщиками (справедливости ради отмечу, что и обратные случае тоже редки). А если и имеют, то не со мной)) Я неспроста называю себя именно проектировщиком, а не просто интерфейсщиком, скажем, потому, что я не умею «тупо» (не в значении «глупо») исполнять. Это, с какой-то стороны, недостаток: даже там, где моё идологическое внедрение не требуется, я не могу заткнуть в себе порывы поучить кого-то о том, что, мол, вы чё, ребяты, низя так над пользователями издеваться, они вам не дешёвая рабсила.
Так вот. Я уже не первый раз сталкиваюсь с ситуацией, когда мне пытаются «навязать» (ну, не всегда в виде принудиловки)) разработку проекта небольшими участками. Мол, тогда лучше переделывать, результаты сразу видны (даже в самых неорганизованных структурах есть начальники либо заказчики, которые требуют) и прочая и прочая. Так вот – это крайне неэффективный подход, если говорить о разработке проекта с точки зрения всего, что связано с юзерской деятельностью. Чтобы понять почему – подойдём с другого конца, и поговорим об этом самом ux/ui проектировании. Естественно, с моей точки зрения (я тут недавно узнала на практике, что если программисты могут в паре работать — уже хорошо, если проектировщик+дизайнер+верстальщик = вообще чудесно, но проектировщикам двоим вместе работать – сразу вилы и смерть: разница во взглядах, несовместимая с дееспособностью проекта).
У меня лично в проектировании работает принцип от общего к частному. Сначала вы рисуете овал лица, тип внешности (расу, так сказать), отличительные особенности. Потом глаза наполняются цветом, губы улыбкой, лицо морщинками, уши волосами, а голова причёской. Не наоборот. В моём представлении.
Вот представьте себе два варианта постановки задачи рисования портрета:
- 1). Так, значит, нам главное – это нос без горбинки и голубые глаза. Ну, и пусть это будет женщина. Остальное не волнует нас, потом как-нить придумаем. Главное, чтобы заказчик видел, что работа кипит. А ему вот голубые глаза всенепременно нужны, фетиш у него;
- 2). Нужен портрет женщины-китаянки. Скажем, возраста 30-35 лет, деловой женщины, следующей тенденциям моды и всякого хай-тека, которая (чуть усложним) проводит выходной на пикнике с ребёнком и его друзьями.
Почему я предпочту вариант номер два? Потому что я не смогу нарисовать первый вариант. Вроде чего проще – нарисовал чётко оговорённые прямой нос и голубые глаза, потом ты дорисовываешь остальные элементы в соответствии с чёткими указаниями. Возможность ошибки практически исключается – ты всё делаешь по ТЗ, пожелания заказчика полностью учитываются.
Не смогу потому, что велика вероятность того, что в итоге получится какая-то большая крокодила, которая по улице ходила. Потому что, допустим, нарисую я голубые глаза. Ок. Заказчик обрадовался, а через недельку говорит: не хочу европейку, хочу китаянку. А у китаянок (простите, если мышление стереотипное, но мы тут всё больше образами размышляем) глаза карие. То есть выход раз: мне придётся перерисовывать глаза (а, значит, и весь портрет, если это красками сделано). Выход два: мне придётся оставить голубые глаза, но показать, что это продвинутая девочка молодая, которая носит сильно голубые линзы (неестественно выглядят) и волосы у неё тоже розовые. И т. д.
В варианте номер два я вижу чёткую картинку: есть китайской расы женщина, умудрённая жизнью и чуть уставшая, вероятно умная и которая любит (а может и наоборот, не любит… это уж как я нарисую) проводить целый день в компании детей. Всё. Задача поставлена. Про цвет глаз и прямоту носа, цвет волос и приблизительное выражение лица я и сама уж как-нить соображу. Я смогу это нарисовать, потому что я буду знать, каков конечный результат нужен – к чему мы стремимся.
Так вот, первый вариант (для меня, опять же) – это многочисленные переделки, нервы, психи даже, я бы сказала. А также постоянное осознание того, что мне приходится работать только потому, что нужно сделать проект. И конечный результат не волнует никого, на самом деле. Заказчику главное, чтобы нос, глаза, волосы были сделаны так, как ему хочется и в такой одежде, в какой ему надо.
Во втором случае возможна ещё одна проблема – в моей голове может появиться несколько образов (довольная домохозяйка, скучающая акула бизнеса, безразличная уставшая мамаша и проч.) и мне захочется их все обрисовать. Но тут разница есть – я если и обрисую их все, то по своей личной инициативе, потому что МНЕ так хочется, потому что мне нравится придумывать и отображать свои мысли, потому что мне нравится решать различные задачи и делать эти решения красивыми. И я довольна – свой творческий потенциал мне удалось раскрыть, так сказать. И я довольна тем, что в меня верят и не указывают какой бантик ей в косы заплетать. И заказчик рад – все его требования выполнены, а вариантов он получил, как минимум, два (меньше я, наверное, никогда и не делаю).
Да и закачика (либо пиэма) работа по второму сценарию характеризует как человека, который осознаёт, что ему нужно, который знает, что он хочет получить. При этом, даже не обязательно, чтобы он мог сформулировать свои мысли чётко — их я и сама могу сформировать. Мне главное понять от него, чего он хочет. Чётко. Таким образом я смогу понять чёткое позиционирование продукта (а, значит, и возможные направления его развития, что, конечно же, я учитываю при проектировании).
А это очень сложно многим пиэмам обрисовать. Ибо, чтобы спозиционировать проект – требуется много чего выкинуть (зачастую, в среднем). Многие же, напротив, страдают синдромом «вороны» – хватаю все, что блестит, красиво типа. так что позиционирование проекта – наверное основополагющее вот то самое, что я от проект менеджера хочу услышать. этого уже достаточно, чтобы наша совместная работа была продуктивной. Потому что задания типа «иди туда, не знаю куда, сделай то, не знаю что» – они в своём процессе бесконечны. Плюс это неуважение и к проекту, и ко мне, как проектировщику (мол, ты делай варианты, думай тут за нас, а мы только критиковать будем). А своё непонимание и невидение проекта некоторые (не)умело скрывают за подходом аля экстремальное программирование.
Ещё одно немаловажное замечание о проектировании: это, как мне кажется, прежде всего чутьё. Это очень интуитивный процесс. Это хождение по лезвию бритвы, так сказать. Пока ты полностью не расставишь акценты (точнее, пока их не расставит заказчик/ПМ), не вычленишь главное – ты не сможешь сделать оригинальный, наиболее подходящий конкретно к данному проекту интерфейс. Ты можешь опираться на свой собственный опыт и взгляд, но в итоге может понадобиться переделывать, ибо не совпадет с мнением и взглядом заказчика (не значит, что плохо — просто твоё мнение может быть другим: не тебе ж знать, как бабло с этого рубить собираются). А зачем нам такое неуважение к собственным труду и времени. Немного сместишь акцент с одной сферы на другую и всё – даже смысл проекта уже может кардинально поменяться, а, значит, и UX (и, следовательно, UI) уже будет совсем иным. Унификация – это хорошо, но там, где имеются стандарты. Например, форма логина – унифицируй себе. Хотя в каждом новом проекте, я её всё равно «обуникаливаю». Даже форму выбора языковой версии можно сделать каждый раз разной. Даже такие мелочи могут зависеть об общей нацеленности проекта.
Так что отсюда следует одна важная задача пиэмов – это ограничивать фантазию. Если очень-очень грубо привести пример, то так может выглядеть: я не очень хорошо понимаю цель проекта, ибо мне сказали о мелочах, но самого главного так и не объяснили. Я имею в голове несколько вариантов. От структуры и навигации пляшет всё остальное. А всё остальное отрисовать – это тоже ого-го сколько времени. Т. е. мы теряем время на мои предложения различных вариантов, и они ещё, заразы такие, всё не нравятся. Нравятся другим, но не нравятся менеджеру проекта. Они, видите ли, не соответствуют ожиданиям этого менеджера. Так, а кто тебе виноват, если ты мне не ожидания свои рассказал, а какими цветами рюшечки должны быть выделены и ширину сайдбара в пикселях?
Так что, когда менеджер чётко обозначивает границы «от сих и до сих» и тем самым максимально снижает вариативность, то легче и быстрее становится работать всем. А это с экстремальным программированием уже слабо коррелируется.
Правда, есть один плюс у экстремального программирования (обычно он годится для небольших и несложных проектов, где, собственно, не так много сложных моментов и не так много задач, к которым требуются оригинальные и правильные решения). Это подход от частного к общему. Т. е. нарисовал ты голубые глаза и прямой нос, а дальше уже все остальные элементы просто привязывай к тому, что есть. Ничего не переделывай, а делай все элементы отдельно и потом их просто соединяй в одну картинку. ДА, вероятность «странного» результата весьма высока. Но, кстати, она многих устраивает. Это, в основном, либо проектировщики-халтурщики, которым абы сделать, а там хоть трава не расти. Либо программисты (экстремальные, наверное). Насинг персонал, просто, ну, другой у программистов подход к юзерэкспириенсу. Это сами программисты говорят, кстати, не я.
Поэтому и называется экстремальное программирование. Потому, что относится к программированию, как к таковому, и разработке функционала. И, почитав книжонки об XP, я заметила, что обсуждение всего процесса и всех методик начинается уже с самого процесса программирования. Т. е. стадия проектирования как бы уже есть по-умолчанию. И, что очевидно, проектирование было не «экстремальным». Поэтому не стоит впихивать «невпихуемое» и проецировать непроецируемое. Кстати, если стадия проектирования в этих книжках не упоминается, то это значит что? Что она уже пройдена? Или что её вообще нет и не было? По хорошему, она обязана быть. Но, учитывая то, что они так, с лёгкой руки, всё перерабатывают прямо на лету, при этом о проектировании (точнее, перепроектировании) опять ни слова, то как-то складывается ощущение того, что такая стадия у авторов отсутствует как класс.
Вывод здесь такой: жнецом, швецом и дудцом, простите, требуется быть как раз проект-менеджеру. Потому что к каждому специалисту нужен свой подход. Алилуйя!
Автор: Александра Денисова.