Производство фильмов


Производство фильмов – занятие непомерно дорогостоящее, как и создание программного обеспечения. Голливуд снимает фильмы дольше, чем мы производим программы в Кремниевой Долине, и нам есть чему поучиться у них. Действительно дорогостоящая часть – это непосредственная съемка фильма. Все эти камеры, сцены, техники, актеры ежедневно съедают многие тысячи долларов. Хорошие фильмопроизводители четко контролируют эту стадию и заранее планируют все подробнейшим образом. Тратя время и деньги на создание подробных раскадровок и съемочных расписаний, они экономят кучу времени и денег во время съемок.
Процесс создания фильма можно разбить на три крупных стадии: подготовка, производство, доводка. На стадии подготовки появляется и дорабатывается сценарий, выполняются работы по дизайну, нанимаются актеры и персонал для съемок, находятся инвесторы. На стадии производства зажигаются софиты, включаются камеры, режиссеры выкрикивают указания, актеры играют роли. На стадии доводки происходит монтаж фильма, запись звукового сопровождения и проработка маркетинговой кампании. Эти стадии достаточно хорошо соответствуют стадиям разработки программного обеспечения.
На стадии подготовки руководители занимаются проектированием взаимодействия для продукта, нанимают программистов и находят инвесторов. На стадии производства зажигаются мониторы, компиляторы включаются в работу, руководители выкрикивают указания, а программисты пишут код. На стадии доводки отлаживается код, пишется документация, прорабатывается маркетинговая компания.
Важная особенность этого трехстадийного процесса: подготовка позволяет минимизировать длительность стадии производства. Зеленый свет началу съемок стоит невероятно дорого, поэтому экономия нескольких дней съемки может возместить многие недели работы на стадиях подготовки и доводки. Подготовка к съемке занимает год и более, интенсивные съемки – пару месяцев, а доводка – еще многие и многие месяцы.
Более того, по мере роста технической сложности фильмов (что получится, если скрестить фильм с компьютером?) все меньше остается производственной работы, которую можно выполнить без тщательного предварительного планирования. Если планируется дуэль кинозвезды и созданного на компьютере пришельца на лазерных мечах, эта дуэль будет сниматься на фоне синего экрана и в действительности не состоится, поэтому все действия актера вплоть до мельчайших движений и направления взгляда следует спланировать.
Создатели фильмов знают, что у них будет лишь один шанс сделать все верно, поэтому никогда не забывают о стадии подготовки. В мире компьютерной разработки многие руководители считают, что смогут все починить в следующей версии, поэтому давление в области планирования снижается. Это предположение обходится ужасающе дорого.
Сегодня создавать программы так же сложно, как фильмы, однако процесс разработки по преимуществу игнорирует этот факт. Мне встречаются в основном команды разработчиков, которые тратят несколько дней или недель (максимум) на планирование и проектирование, затем от 6 до 18 месяцев – на программирование, затем всего пару месяцев занимаются отладкой, тестированием и документированием. Подозреваю, нам многому следует научиться у киноиндустрии. Если бы мы больше времени тратили на стадию подготовки, на проектирование, то смогли бы сэкономить массу дорогостоящего времени программистов.
Стадия подготовки в киноиндустрии – самая дешевая. Затраты на создание раскадровки дорогостоящей погони со взрывами и специальными эффектами не очень велики. Чтобы внести радикальные изменения, достаточно ластика, карандаша и какого-то времени. Тщательная детализация на бумаге экономит миллионы в тот момент, когда включается камера, а в автомобили набиваются каскадеры и взрывчатые вещества. Подготовка – это инвестиции во время, которое экономит наличные средства и повышает вероятность успеха.
Если режиссер передумал и хочет взорвать вертолет вместо поезда, то на стадии подготовки сделать это просто и обойдется недорого. Подобные изменения во время съемки практически самоубийственны. Создатели фильмов это знают, а потому не торопятся во время подготовки, а во время производства следуют этим планам.
Для уже существующих продуктов цикл искажается еще больше. Ежегодное обновление возможностей для уже вышедшего на рынок продукта может вообще не оставлять времени на предварительное проектирование. Руководитель разработки продукта просто ведет перечень возможностей, запрошенных клиентами, и каждый год без лишних церемоний вручает этот список программистам.
Как и в случае производства фильмов, стадия тщательного проектирования продукта в процессе разработки может дать огромные преимущества. Создавая на бумаге подробный план для продукта, мы исключаем многочисленные неопределенности в программировании, а также существенно снижаем риски, обычно сопутствующие выпуску продукции, основанной на программном обеспечении.
Хорошая сделка
Руководство должно взять на себя ответственность и включать проектирование в процесс до того, как начато программирование. Если проводить аналогии, проектирование взаимодействия – это архитектура, а не дизайн интерьеров. Проектирование взаимодействия определяет, куда будет залит бетон фундамента, точно так же, как и самый подходящий материал для занавесок или портьер на окна. Проектировщики взаимодействия должны получить моральные полномочия диктовать форму и конституцию продукта программистам. Это приведет к серьезным культурным сдвигам, но после таких перемен программисты станут счастливее, а вы получите выгоды от значительно более совершенного продукта.
В обмен на такую власть сообщество проектировщиков взаимодействия также должно принять определенную ответственность. Во-первых, проектировщики должны войти в число лиц, кровно заинтересованных в исходе игры. Они должны сойти с боковой линии, откуда сейчас дают советы программистам, разрешая тем принять полную ответственность за успех продуктов. Недостаточно просто иметь правильные идеи. Необходимо добиться применения этих идей на практике, и единственный способ это сделать состоит в том, чтобы проектировщики взаимодействия встали ближе к точке риска. Программисты приближаются к этой точке с каждой строкой кода.
Кроме того, проектировщики взаимодействий должны фиксировать свои предложения в письменной форме.
Документируйте замысел, чтобы дать ему жизнь
Один из действительно жестких уроков, которые мне пришлось усвоить за прошедшие годы, таков. Хорошее и даже отличное проектирование бессмысленно, если не воплощается в жизнь. И оно никогда не воплощается в жизнь, не будучи описанным подробно, точно и со всеми деталями, причем в терминах, имеющих смысл для программистов. Описание должно быть письменным, включать исчерпывающие подробности, сопутствующие свидетельства и примеры. Оно должно быть напечатано и переплетено во множестве экземпляров. Его следует лично представить команде разработчиков. Вице-президент разработки в этот момент должен присутствовать, кивать и улыбаться. Еще лучше, если это будет президент компании.
Необходимо, чтобы проектировщики писали, кадрировали, анимировали, прототипировали свои решения настолько полно и подробно, чтобы программисты могли считать эти решения чертежами и писать на их основе код. Необходимо описывать достаточное количество ситуаций, давая разработчикам уверенность в том, что решение достаточно надежно, чтобы дожить до реализации.
Проектирование в письменной форме подобно плану сражения. Каждый знает свою роль, обладает критической и своевременной информацией. Все могут действовать сообща и гармонично, создавая продукт, ориентированный на конкретного пользователя.
Программисты прибегают к довольно действенной «пассивно-агрессивной» тактике. Не вступая в конфронтацию, призванную разрешить вопрос, они избегают внимания к нему и втихую предпринимают – или не предпринимают – определенное действие. Как пассажир, который направляет каноэ, исподтишка наклоняясь то влево, то вправо. Одна из моих любимых бизнес-аксиом – «если этого нет на бумаге, значит, это не существует» – в мире проектирования программного обеспечения верна, как нигде. Если что-то не записано, более чем вероятно, что это будет неправильно истолковано или опущено. Дело в том, что мотивация программистов очень сильно расходится с мотивацией пользователей. Недостаточно исключить диалоговое окно из описания, проектировщик обязан явным образом указать, где программист не должен по собственной инициативе добавлять лишнее окно. Программистам нравятся диалоговые окна. Они считают, что оказывают пользователю услугу, добавляя в свободные минуты пару дополнительных диалоговых окон. А пользователи эти окна ненавидят, потому что диалоги их изматывают и снижают производительность.
Проектировщик взаимодействия, как архитектор, сдает набор чертежей, регламентирующий продукт, который должен быть создан. Но, несмотря на сходство, между чертежами и проектировочными документами есть и большие различия. Чертежи обладают большей емкостью. Единственная линия чертежа может обозначать стену из ста тысяч кирпичей. Когда речь идет о взаимодействии, емкость улетучивается. На описание поведения ста страниц кода может уйти сто страниц документа. С минимальной долей шутки я заявляю, что достаточно детализированная спецификация неотличима от кода, эту спецификацию реализующего. В идеальном мире разработчики будут предоставлять проектировщикам целый год для проектирования, а затем программистам три месяца на создание кода. В сегодняшнем мире все наоборот.
Из этого следует, что проектировочный документ должен, это неизбежно, опускать некоторые моменты. Проектировщик должен иметь не только чувство качественного проектирования, но и понимать, что именно сейчас важно. Проектировщик взаимодействия должен решать, какие части программы необходимо спроектировать, а какие можно оставить на откуп программистам.
Все мои проектировочные документы построены по принципу спирали, как газеты. Заголовок новости содержит всю значимую информацию. Первый параграф повторяет новость более подробно. Следующие три параграфа повторяют новость еще раз, еще более подробно. В оставшейся части статьи, которая может занять несколько колонок, содержится вся история в мельчайших подробностях. Все это позволяет читателю получить необходимое, не разгребая ненужные детали.
Проектирование влияет на код
Многие ошибочно полагают, что проектировщики взаимодействия делают дизайн интерфейса пользователя. Без дизайна интерфейса, несомненно, не обойтись, однако в процессе проектирования интерфейс играет второстепенную роль, примерно как упаковка продукта. Дизайн интерфейса должен выполняться после того, как определено назначение и поведение интерактивного продукта. Некачественный продукт в красивой и красочной упаковке – продукт по-прежнему некачественный.
Специалистов по дизайну интерфейса обычно приглашают в момент, когда работа над продуктом завершена или близится к завершению, возможности для проектирования в основном уже упущены, и здесь усилия проектировщика – не важно, насколько героические – имеют ограниченное действие.
Проектирование взаимодействия может радикальным образом изменить процесс реализации, хотя это не означает, что проектирование затрагивает только вопросы реализации. К примеру, программисты могут ожидать, что проектировщик опишет внешний вид важного диалогового окна. А проектировщик может пожелать заменить это окно чем-то другим, например панелью инструментов. При этом он не интересуется программной реализацией диалоговых окон и панелей инструментов.
Поскольку проектировщик взаимодействия может оказать серьезное влияние на создание тех или иных фрагментов программы, в то же время избегая деталей реализации, мы считаем проектирование процессом определения продукта. По сути дела, проектировщики определяют внутреннюю часть продукта путем определения внешней. Взаимодействие с пользователем описывается очень подробно и очень точно, тогда как вопросы реализации остаются на совести программиста.
Проектировочные документы приносят пользу программистам
Помните вопрос «Когда проект готов?» из главы 3 «Пустая трата денег»? Основное назначение документов, созданных проектировщиком взаимодействия, в том, чтобы ответить на него. В общих чертах проектировочный документ – это надежный механизм контроля процесса программирования. Он – то же самое, что сценарий и раскадровка для производства фильма, он проясняет для всех участников принципы работы, материалы, необходимые для создания и применения, а также условия, выполнение которых позволяет сказать, что работа завершена. Как правило, в процессе разработки труднее всего контролировать этап написания кода, более других связанный с рисками, поэтому непонимание «готовности» обходится довольно дорого.
Прозрачный документ помогает руководству компании точнее понять, что создает компания, и таким образом сконцентрировать усилия предприятия в нужном направлении. Руководство получает в свое распоряжение более точное определение продукта, подходящее для инвесторов, партнеров, сотрудников и коллег. Это гарантирует, что все рабочие усилия компании направлены на достижение одной цели.
Программистам нужен сильный и умный лидер. В конце концов, они сильные и умные, они предпочитают, очевидно, чтобы их возглавляли равные по рангу, а не нижестоящие. Как утверждает Джерри Вайнберг (Jerry Weinberg), всем известно, что «плохих руководителей найти проще, чем хороших программистов». Это ставит хорошего программиста более выгодное положение, несмотря на номинальный авторитет руководителя в корпоративной иерархии.
Руководитель разработки продукта слаб, если не способен точно и убедительно описать то, что создает его команда. Как правило, руководство выражает свои желания с помощью ничего не значащих критериев фиксированных сроков сдачи и с помощью торговли функциями. О слабости таких инструментов мы уже говорили. Лишь программистам доподлинно известно, как будет выглядеть законченный продукт, поэтому они в большей степени властны над проектом, чем руководитель.
Я работал с программистами, которые испытывали неприязнь к выполнявшей проектирование сторонней компании. Они знали, что моя работа заключается в «проектировании» и что это самая творческая и самая интересная часть их работы. Однако поработав с нами, они поняли, что мы не только не отнимаем у них работу, но и делаем ее более качественной.
Недавно мне довелось побывать на одном собрании, где присутствовали язвительные программисты клиента, не предупрежденные о нашей роли. Один седобородый программист по имени Фред выступал особенно энергично. Стоило нам высказать идею или представить какой-либо способ отображения информации для пользователя, Фред нападал на нас. Он очень умен и излагал свои мысли четко и громко. Всякий раз когда мы демонстрировали слайд, иллюстрировавший изменение взаимодействия, он закатывал глаза, снисходительно улыбался и отпускал замечание по поводу того, что мы не осознаем, «каких героических усилий это потребует» от него и от его команды. Он все время давал понять, что наши решения не облегчают, а осложняют его работу.
Под конец, когда собравшиеся стали разбредаться, нашей команде удалось поговорить с Фредом наедине. Мы объяснили ему, что наша задача сделать программу проще и мощнее с точки зрения конечного пользователя, и что мы полностью осознаем: наши решения требуют серьезных дополнительных размышлений на уровне программирования. Мы настаивали, что нас интересует только конечный пользователь. Внезапно на лицо Фреда нашло выражение потрясения. Он воскликнул: «Вы бросаете мне серьезный технологический вызов!» Его отношение полностью изменилось, как только он осознал, что мы принесли ему грааль всех программистов – сложную проблему, достойную решения.
Никоим образом не пытаясь ему угрожать, мы дали ему то, чего он больше всего желал: шанс еще раз проявить себя, как самого умного, самого изощренного, самого опытного программиста.
Его отношение изменилось, как только он осознал, что мы отняли лишь запутанный человеческий аспект программирования, который ему так не нравился, а ему осталось лишь одолеть чисто алгоритмическую начинку программы. Мы стали для него благодетелями, а не врагами.
Проектировочные документы идут на пользу маркетингу
В большинстве некомпьютерных предприятий на этапе определения продукта работают профессиональные маркетологи. В бизнесе программного обеспечения маркетологов исключили из процесса. Здесь им достаются лишь запросы новых возможностей. Если они требуют исправления дефектов, программисты попросту швыряют им в лицо жесткий график проекта с вопросом: «И как я могу что-то исправить, если вы не даете мне времени?» Руководитель отдела маркетинга не смеет потратить это драгоценное время, потому что не просто нарушит этим график, но и покажет всем, насколько график лжив, и программисты в будущем смогут безнаказанно заваливать все сроки. Маркетологи знают, что список функций – слабый механизм, и часто стремятся к участию в процессе определения продукта. К сожалению, маркетологи, похоже, неспособны давать указания, которые показались бы программистам полезными или осмысленными.
Одно из наиболее важных преимуществ усиленного процесса проектирования, а также доскональной документации, как части этого процесса – польза, которую извлекают маркетологи. Маркетологи рассказывают проектировщикам, какие потребности или желания пользователей надеются удовлетворить. Проектировщики взаимодействия изучают таких людей, чтобы определить их цели и создать набор персонажей. Точные определения персонажей пользователей – важная часть проектировочной документации, и эти определения становятся точкой фокусировки усилий по маркетингу. Программисты работают только с кодом, но персонажи одушевляют этот код. Маркетологи работают с каналами, рынками, средствами массовой информации, реселлерами, но персонажи одушевляют все эти сущности. Наконец, у программиста и маркетолога появляется общая точка отсчета.
По существу, проектировщики взаимодействия играют роль посредников для профессиональных маркетологов. Проектировщик – это человек, способный переводить с языка маркетологов на язык программистов. Когда у маркетологов нет четкого понимания, они могут описать свои заботы проектировщикам, а те разовьют мысль в терминах персонажа. Затем проектировщик сможет перевести проблему в спецификацию взаимодействия. Более того, маркетолог увидит, как выполняются его запросы, и может быть уверен, что ему не придется искать покупателя для голого инженерного продукта.
Разработка персонажей пользователей – дело, как правило, очень знакомое профессиональным маркетологам. Они часто выполняют подобные упражнения, определяя персонажи покупателей продукта. При этом изучаются каналы распространения и демография вместо целей и сценариев, поэтому персонажи обычно получаются иными, однако всегда оказывается, что они полезны маркетологам для планирования. Маркетологи получают возможность четко изложить покупателю, каким образом продукт облегчит жизнь пользователям.
Проектировочные документы помогают в разработке документации и технической поддержке
Любой технический писатель скажет вам, что качественное проектирование избавляет от необходимости писать невероятные объемы документации. Чем меньше сложного взаимодействия, тем меньше пространных объяснений. Авторы документации получают возможность больше времени потратить на более высокие уровни взаимодействия. Вместо того чтобы, за руку водить пользователя по запутанным джунглям непонятного интерфейса, они могут выйти на другой уровень и потратить силы на более интересные пользователю вопросы решения проблем предметной области. Вместо рассказа о том, где хранятся файлы системы инвентаризации, документация может поведать о принципах инвентаризации, что определенно принесет больше пользы.
То же верно и для технической поддержки. Чем лучше проектирование, тем меньше звонков от пользователей. Как показало проектирование сканера Peacock, описанное в предыдущей главе, проектировочный документ радикально снижает потребность в технической поддержке.
Проектировочные документы помогают руководителям
Из всех участников наибольшую выгоду от проектировочных документов получают руководители разработкой продуктов. Упреждающее описание того, что необходимо создать, ускоряет весь процесс разработки, делает его более взвешенным, менее рискованным, менее дорогостоящим. Эффективность процесса разработки повышается, и он больше не управляется клиентами.
Прежде всего, проектирование означает большую предсказуемость. Проектирование продукта означает, что фаза программирования будет более предсказуемой. Кроме того, и успех продукта становится легче прогнозировать и оценивать. Это два наиболее рискованных и дорогостоящих аспекта разработки программных продуктов. Они сокращают стоимость производства и побеждают миф о непредсказуемости рынка. Эд Форман, вице-президент по разработке продукта Elemental Drumbeat, говорит:
«Выгоды от услуг проектирования измеряются сэкономленными месяцами напряженной работы».
Проектировочные документы выгодны компании в целом
Какова сущность построения успешного бизнеса? Все участники должны работать вместе для достижения одной цели. Любая неразбериха или разлад в целях рассеивает усилия двояко. Во-первых, вы теряете усилия тех, кто идет в неверном направлении, а во-вторых, их усилия сдерживают тех, кто пытается идти в нужном направлении. Если один человек в каноэ гребет в противоположном направлении, команда уже не может всерьез претендовать на призовое место. Успех требует гребли в одном направлении, и любая сила, отвлекающая внимание одного человека, наносит вред всем.
Более того, точно осознавая, что вы делаете, вы избежите траты сил на то, чего вы точно не собираетесь делать. Ни одна компания не может себе позволить тратить силы на вещи, не относящиеся к делу.
Избавляясь от управления, ориентированного на фиксированные сроки сдачи, и торга по поводу функций продукта, документальное описание продукта направляет все внимание компании на его качество, которое неизбежно радикально повышается. Качество, в свою очередь, умножает запасы самого бесценного актива компании: лояльности клиентов.
Кто отвечает за качество продукта?
Если за качество продукта отвечает каждый, это означает, что за качество продукта не отвечает никто. Слишком уж легко предположить, что решением проблемы качества займется ваш коллега, пока вы работаете над чем-то еще. Программисты несут ответственность за уничтожение всех дефектов кода. Отдел продаж отвечает за закрытие сделок, а маркетологи – за упаковку и позиционирование. Однако в настоящий момент нет лиц, отвечающих за качество и пригодность продукта. Иногда этим лицам не хватает инструментов, чтобы обнаружить и разрешить проблему.
Иногда не хватает умения, чтобы выразить решение. Иногда у них нет авторитета, достаточного для того, чтобы их решение было реализовано. Как мы видели в предыдущих главах, написание кода подрывает способность программиста думать о целях пользователя. Руководителям разработки и без того есть чем заняться, они не могут концентрироваться на деталях поведения продукта. Маркетологам не хватает технической подготовки, и это снижает их способность общаться на технические темы, а значит, подрывает доверие к ним со стороны программистов. При отсутствии тщательно документированного проекта нет надежды на его правильную и эффективную реализацию.
Главная рекомендация этой книги: за качество продукта в конечном итоге должен отвечать проектировщик взаимодействия. Необходимо разрешить ему определять содержание и поведение программы. Он должен работать со списком функций, и даже график разработки, в основном, должен быть на его совести. Он защищает пользователя и должен обладать властью над всеми внешними аспектами продукта.
За всю эту власть проектировщик взаимодействий получает и ряд очень серьезных обязанностей. Без такого сочетания авторитета и ответственности программисты не будут уважать проектировщиков и вернут себе контроль над продуктом. Проектировщики должны быть кровно заинтересованы в успехе. Мандат доверия команды проектирования взаимодействия включает проектирование реальных, простых в применении, привлекательных продуктов, позволяющих пользователям достигать практических целей, не отказываясь от целей личных. Более того, проектировщик взаимодействия должен создавать исчерпывающие письменные спецификации, исходя из которых программисты и будут строить продукт. Проектировщик взаимодействия должен предоставить маркетологам прозрачные описания пользователей и того, как продукт удовлетворяет потребности этих пользователей. И самое важное – он принимает на себя ответственность за качество конечного продукта.
Включение проектирования в процесс
В предыдущей главе мы видели, что многие профессионалы, предлагавшие свою помощь в проектировании взаимодействий, не добились успеха. Речь шла о юзабилити-специалистах, промышленных дизайнерах и других, кто пытался и не смог решить эту проблему. В настоящее время в индустрии не существует группы, способной решить эту проблему.
Ряды проектировщиков взаимодействий медленно пополняются, и здесь следует иметь в виду, что важнее правильно подготовить процесс разработки к включению проектирования, а не нанять самых талантливых проектировщиков взаимодействий. Самое важное – принять решение, что программированию будет предшествовать проектирование. Самый блестящий проектировщик мира ничем не поможет, если продукт на следующей неделе переходит на стадию бета-тестирования.
Многие империи, производящие программное обеспечение, выросли на усилиях очень молодых и очень неопытных программистов. Вероятно, они получали свободу действий в вопросах программирования, а сочетание невероятной ответственности с безграничными полномочиями часто становится плавильным тиглем, рождающим великие вещи. Те же правила действуют в проектировании взаимодействия. Если человек получает ответственность за качество продукта и соразмерные полномочия, то он может принять на себя эту ношу независимо от своего опыта. Если взять подходящего человека и дать ему полную власть над качеством и поведением продукта, вы получите продукт намного, намного лучший, чем если этого не сделать. Проблема не в людях, но в процессе. Разумеется, при прочих равных всегда лучше нанять специалиста с подходящим опытом. Однако если специалисты не вписываются в бюджет или просто не существуют, менее опытные проектировщики все равно лучше, чем совершенно неподконтрольные программисты.
Что значит быть «подходящим человеком»? Лучше всего подойдет человек, отдаленный от процесса реализации продукта настолько, чтобы он мог легко ставить себя на место пользователя. Это может быть и программист, но определенно не из числа тех, что будут создавать эту программу. Иначе возникает слишком большой конфликт интересов.
Откуда берутся проектировщики взаимодействия
Как бы там ни было, вам необходимо выбрать проектировщика взаимодействий. Начав искать, вы обнаружите разочарованных проектировщиков взаимодействия практически в каждой высокотехнологической компании: это технические писатели, к которым программисты обращаются за помощью; менеджеры продуктов с полками, заставленными книгами по дизайну интерфейсов; эргономисты, заговаривающие о более ранней интеграции в разработку; маркетологи, подчеркивающие, что прикупили стереосистему с минимально возможным количеством кнопок; программисты, которые пишут очень мало кода, но с которыми стремятся работать другие программисты. В действительности, когда в компании станет известно, что какой-то проект начнется с фазы проектирования взаимодействия, наверняка кто-то вызовется отвечать за качество продукта.
При найме проектировщика на полный рабочий день хороший кандидат не обязательно назовет себя проектировщиком взаимодействия. Вам нужны люди, понимающие, какие ограничения накладывает техническая сторона дела, и горящие желанием проектировать, и таких людей, обладающих самой разнообразной подготовкой, можно найти в самых различных средах. Нанимая людей в свою группу проектирования, я прошу их пройти испытание на конкретной задаче, поскольку знаю, что сведения в резюме бывают весьма разнообразные. В моей студии несколько проектировщиков в прошлом были техническими писателями, руководителями разработки, сотрудниками технической поддержки, дизайнерами. Многие из моих проектировщиков имеют степени в гуманитарных областях, но есть также люди со степенями в физике, архитектуре, информатике и промышленном дизайне.
Опыт работы в технической поддержке или документировании дает проектировщикам перспективу для оценки потребностей типичного пользователя. Менеджеры продуктов знают о нуждах и заботах программистов в процессе разработки. Дизайнеры и промышленные дизайнеры страстно увлечены элегантным дизайном и обладают способностью такой дизайн создавать. Проектировщики с гуманитарным образованием, работавшие в области высоких технологий, сочетают познания в технологии со способностью ясно выражать свои мысли.
Создание команд проектировщиков
Обсуждение способов организации и управления командой проектировщиков может занять целую книгу. Здесь же я затронул лишь некоторые методы проектирования, чтобы прояснить, что имею в виду под «проектированием», но не пытался изложить методологию проектирования целиком. Тем не менее, мой опыт управления командами проектировщиков дал возможность выделить несколько ключевых принципов.
Команды должны быть небольшими. Чтобы продвигаться вперед, проектировщикам необходимо общее видение. Для каждого продукта я отряжаю команду из двух или трех человек, которым время от времени могут помогать и содействовать другие специалисты. В сложных проектах могут возникать ситуации, когда у продукта появляется несколько различных интерфейсов, и в этот момент можно разделить проблему на несколько частей: каждой отдельной команде по части. Но до этого момента у семи нянек дитя будет без глаза.
Изолируйте команду от руководителей и программистов. На старте проекта проектировщикам будет необходимо поговорить с другими людьми, работающими над продуктом, чтобы получить четкую формулировку проблемы и дать определения персонажам. После этого проектировщикам требуется независимость в исследовании тупиковых путей; так они получают наилучшие решения, и делать это могут только в уединении.
Назначьте человека, отвечающего за документирование работы команды. Все участники вносят вклад в создание документации, но у нее должен быть «владелец», придающий эффективность процессу.
Дайте команде время, чтобы собраться с мыслями. В разгаре проекта, когда основные проблемы уже решены, имеет смысл ответить на конкретные вопросы команды. В начале проекта команда должна тщательно все продумать и представить свои соображения в виде стройной концепции. Когда моя студия полностью прорабатывает структуру продукта для клиента, мы предоставляем документацию и свои проекты с неформальными контрольными точками по мере необходимости. На первой презентации мы очерчиваем проблему, представляем персонажи и описываем, какие задачи должно решить проектирование. На каждой из последующих презентаций мы более подробно описываем проект продукта.
Управляемый процесс, сосредоточенный на проектировании вместо программирования, позволяет компаниям избежать игры с огнем высоких технологий. Они заранее могут узнать, что должно понравиться пользователям и как это обеспечить. Они будут знать, когда процесс разработки завершен, а у специалистов различных дисциплин появится единое, объединяющее видение продукта.
<< | >>
Источник: Алан Купер. Психбольница в руках пациентов. 2007

Еще по теме Производство фильмов:

  1. 1.10. Надзорное производство Производство по пересмотру судебных актов в порядке надзора
  2. МЕТОДИКА ИСЧИСЛЕНИЯ СОВОКУПНОЙ ПРОДУКЦИИ СФЕРЫ МАТЕРИАЛЬНО-ВЕЩЕСТВЕННОГО ПРОИЗВОДСТВА И СФЕРЫ ПРОИЗВОДСТВА НЕМАТЕРИАЛЬНЫХ ФОРМ БОГАТСТВА И УСЛУГ В ДЕНЕЖНОМ ВЫРАЖЕНИИ
  3. ПРОИЗВОДСТВО
  4. Тема 5. ПРОИЗВОДСТВО ЭКОНОМИЧЕСКИХ БЛАГЗАДАНИЯ
  5. 4. Учет вспомогательного производства
  6. 27. Издержки производства
  7. Раздел III. Затраты на производство
  8. 8. ПРИКАЗНОЕ ПРОИЗВОДСТВО
  9. ИЗДЕРЖКИ ПРОИЗВОДСТВА
  10. Глава 6. ПРОИЗВОДСТВО
  11. 20.Основное производство
  12. 15. ПЛАНИРОВАНИЕ ПРОИЗВОДСТВА
  13. МАТЕРИАЛЬНОЕ ПРОИЗВОДСТВО
  14. 39. КОНКУРСНОЕ ПРОИЗВОДСТВО
  15. 4.5. ПЛАН ПРОИЗВОДСТВА
  16. 40. ОРГАНИЗАЦИЯ ПРОИЗВОДСТВА