Многопрофильные команды разработки

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

По этой гипотезе, команда, в которую входят представители со стороны пользователей, программистов, руководителей, маркетологов, юзабилити-специалистов, может сработать более эффективно. Исходя из моего опыта, такой метод «круглого стола» не дает сколько-нибудь значимых результатов. У каждого участника собственные цели и проблемы, все они различны, а тот, чьи цели наиболее весомы, обычно не способен понятно излагать свои проблемы. Много хуже – программисты, неизбежно держащие в своих руках тотальный контроль над программными артефактами, в итоге тайно управляют всей командой, словно серые кардиналы.

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

Программисты-проектировщики

Программисты стали первыми, кто «добровольно» вызвался сразиться с проблемами неискушенных в технологиях пользователей. Не имело значения, что у них не было для этого подходящих инструментов и наблюдались значительные различия в культуре, – другие кандидаты все равно отсутствовали. Программистам, будто случайным свидетелям катастрофы, было поручено оказать «первую помощь» интерфейсам только потому, что им «посчастливилось» работать в смежной области. Невозможно представить программиста, не обладающего энтузиазмом и гордостью в отношении своей деятельности и способности решать трудные задачи, потому их так привлекла сложность проектирования взаимодействия, где им пришлось приложить максимум усилий. Это породило весьма ядовитую шутку: «Проектирование у программистов – это те двадцать минут перед тем, как они начинают писать код».

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

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

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

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

Откуда вам это известно?

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

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

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

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

Если просто ответить «Не знаю», такой вариант могут принять, а вот попытки угадать будут обречены на провал. Хуже того, стоит вам начать гадать, глядя в сторону, программисты – те, кто кровно заинтересован в процессе, – спишут вас со счетов, как шарлатана, не удостоив и словом.