Как изменить процесс

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

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

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

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

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

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

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

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

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

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

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

* * *

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

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

В статье были также приведены знакомые многим «крики души» потерпевших: «Из-за этого компьютера мне кажется, что я идиот!» – и не менее знакомые восклицания апологетов: «Пользователи сами не знают, чего хотят, а даже если знают, то все хотят разного. Они просто невнимательно читали руководства и плохо изучили программу!» В заключение Стивен приводит такое интересное наблюдение:

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

А в самом деле – вам есть что на это ответить?