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

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

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

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

Проектирующие программисты

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

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

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

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

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