Помоги проекту - поделись книгой:
Как только концептуальный документ будет готов, стадия планирования завершится (см. рис. 4.3). Команда должна располагать информацией, необходимой для успешного проектирования в соответствии с поставленными целями. Если работа над концепцией велась в той последовательности, которая показана на рис. 4.2, команда должна приступить к проектированию, поскольку основные направления ей были известны заранее.
Перечень неудачных положений концепции (которых следует избегать)
За свою профессиональную карьеру мне приходилось читать десятки концептуальных документов и самые плохие из них содержали одни и те же стереотипы. Плохо составленные концепции не имеют целостности, не предлагают никакого плана и не выражают совокупности мнений. Вместо этого в них излагаются размышления и прописные истины. Если в концепции нет четкого взгляда на то, что должно быть сделано, руководители команд никогда не станут работать с душой, обрекая проект на провал. Герой фильма «Бойцовский клуб» («Fight club») Тайлер Дурден (Tyler Durden) говорит: «Если вы воткнете себе сзади перья, то все равно не станете курицей». Если вы создаете документ с надписью «концепция» на титульном листе, это еще не означает, что в результате вы получите именно концепцию. Можно делать все по правилам, проводить совещания, пользоваться формализованными документами и все же упустить всю суть, ради которой и создается концептуальный документ. Точно так же, как титул «руководитель проекта» не означает волшебного превращения всего, что вы делаете в действии руководителя, присваивание какому-нибудь документу название концептуального не означает, что он возымеет описанный выше эффект.
В табл. 4.1 представлено несколько типичных формулировок, встретившихся мне во внушительно выглядевших концептуальных документах, которые обесценивали их в глазах руководства проектом.
Таблица 4.1. Типичные примеры неудачных концептуальных положений
Примеры концептуальных положений и целей проекта
В данном разделе я приведу несколько примеров удачных концептуальных положений и целей проекта, исходя из собственного опыта. Кое-что в деталях я изменил, но это не помешает составить представление о том, на что направлен проект и какие цели могут преследоваться на основе предложенной концепции.
Вот примеры вполне удачных концептуальных положений:
• SuperEdit 3.0 – это инструмент редактирования, предназначенный для опытных литературных редакторов, позволяющий облегчить их работу, ведущуюся по пяти самым распространенным сценариям, более надежный и быстродействующий по сравнению с SuperEdit 2.0.
• Superwidgets.com станет ведущим веб-сайтом Интернета, предназначенным для приобретения разного рода небольших приспособлений и устройств снабженцами средних по величине компаний. Он сделает весь процесс приобретения простым, легким и надежным.
• В версии 5.5 Helpdesk Automated Services Site (HASS) будут учтены десять самых распространенных претензий, предъявленных пользователями из числа преподавателей и студентов университета, при этом исключаются любые негативные влияния на среднюю производительность, надежность или на время отклика системы.
В качестве примера удачных целей проекта приводится перечень, использовавшийся разработчиками наладонного органайзера Palm Pilot:[25]
1. Габариты. Устройство должно помещаться в карман рубашки, быть достаточно легким, чтобы не выглядеть громоздким.
2. Стоимость. Устройство должно стоить меньше, чем органайзер элитного класса (около 300 долларов США).
3. Простота. Устройство должно быть в обращении не сложнее бумажного листка, готово к работе сразу после включения и иметь простые элементы управления.
4. Синхронизация с персональным компьютером. Компьютер должен стать основным средством взаимодействия с пользователем.
Удачно сформулированные цели проекта, подобные перечисленным, отличаются простотой и ясностью и описывают порядок вещей, который должен сложиться по завершении работы. Следует помнить, что простота является обратной стороной сложности. Было весьма не просто конструктивно и технологически создать устройство, удовлетворяющее всем обозначенным целям. Представленные ранее примеры удачных концептуальных положений могут оказаться трудновыполнимыми для подобных проектов. В зависимости от того, что именно означают понятия «ведущий», «более простой в использовании» и «самые важные претензии», они могут обернуться немалыми трудностями в реализации проекта.
Обоснование концептуальных положений и целей
Требования, изложенные в концептуальных положениях или в целях проекта, должны быть раскрыты или объяснены в других разделах документа. Значение этих положений для
Концепции должны быть наглядными
Концепции, или по-иному, системы взглядов, названы именно так потому, что они предполагают обращение к нашей способности сформировать визуальное представление какого-то конечного результата. Разглядывая какую-нибудь картину, мы одновременно воспринимаем несколько уровней заложенной в ней информации. Многим самым сложным концептуальным положениям и идеям изображения придают наглядность – изображения воспринимаются намного быстрее и понятнее, чем словесные описания. Я десятки раз в своем офисе вел переговоры с программистами или с разработчиками архитектуры компьютерных систем, которые настойчиво пытались докопаться до сути приводимых аргументов, и все заканчивалось лишь тогда, когда кто-нибудь из нас, в конце концов, подходил к доске, воплощал идею в эскизе и спрашивал: «Вы именно это имели в виду?» После чего обычно раздавался взрыв хохота, вызванный осознанием того факта, что мы затратили впустую уйму времени, пытаясь объяснить суть объектной модели или конструктивных особенностей на словах или на пальцах, в то время как сделать это с помощью доски и фломастера было намного проще и быстрее. Думаю, что в американской культуре основной упор делается на развитие навыков устной речи и умение производить математические выкладки, а не на развитие артистических и изобразительных способностей, поэтому многим профессионалам для приобретения соответствующих навыков требуется некоторая практика. Я убежден, что мы многое теряем, забывая об эффективности выражения идей изобразительными средствами.
Все лучшие образцы концептуальных документов включали элементы визуализации в виде набросков, макетов или прототипов конечного вида продукта, получаемого при условии следования предложенной концепции. Все они сопровождались пояснительными материалами и предварительными прикидками, которые позволяли получить достаточное представление о сути идеи и помогали целям, изложенным в концепции, укрепиться в сознании изучающих ее людей. Благодаря этому становилось понятным, что макеты далеки от конечной версии создаваемого продукта. Слишком далеки. Зато они являются ранней попыткой наполнить содержанием идеи, заложенные в концепцию, и являются своеобразным предположением, позволяющим обсуждать саму работу, а не только представление о ней, предложенное концепцией.
Макеты и прототипы зачастую воспринимаются консервативно настроенными инженерами и программистами намного лучше, чем любые диаграммы объектных моделей или примеры кода. В отличие от этих привычных форм абстрактного отображения информации визуальные прототипы показывают нечто пока не существующее, но вполне осуществимое в будущем. Архитекторы небоскребов и конструкторы автомобилей создают множество физических макетов и прототипов, помогающих им осмыслить идеи, над которыми они работают, и получить на них отзывы со стороны. Создатели кинофильмов для тех же целей используют доску с эскизами, изображающими сцены из фильма. В концептуальных документах, претендующих на качественное исполнение, не следует избегать подобных технологий. Демонстрация эскиза конечного вида продукта позволяет каждому осмыслить его вклад в общее дело. После этого входящие в команду разработчики нацеливаются не просто на создание того или иного компонента, у них возникает представление о том, где и в чем этот компонент найдет применение, когда разработка программного продукта будет завершена.
Наглядное представление неочевидных вещей
Если проект не имеет никакого отношения к пользовательскому интерфейсу или к интерактивному общению с пользователями, это еще не означает, что он не может быть наглядно представлен. Следует задаться вопросом, какие изменения произойдут в случае реализации проекта? Возможно, концепция касается устранения некоторых чисто человеческих проблем или неудовлетворенностей (медлительность серверов, склонность баз данных к частым сбоям и т. д.). Все это может быть наглядно показано путем демонстрации (или симуляции) одного и того же веб-сайта до начала и после окончания работ, или прототипа, позволяющего сравнивать последовательность необходимых действий пользователя до и после, выражая тем самым, насколько все может упроститься с применением новой архитектуры или новой структуры базы данных.
Существует множество способов визуализации идей, сколь бы абстрактными или технократическими они ни казались. Если проект позволит пользователям проводить меньше времени за рабочим столом, нарисуйте рядом с этим столом пустой стул. Если проект ускорит работу базы данных, покажите два демонстрационных ролика, отражающих ее работу до и после. Если отказоустойчивость встроенной системной API-функции повысится на 10 %, предоставьте показания тестовой программы, используемой для измерения данного параметра до и после реализации проекта. Как бы это ни было скучно для команды, но ей нужно дать наглядное представление о границах индивидуальной работы.
Если конечный результат работы не может быть наглядно представлен даже в виде эскиза, макета или схемы, я готов утверждать, что концепция вряд ли будет правильно истолкована. Если вы не в состоянии найти какое-нибудь визуальное представление того, что изменится в этом мире под влиянием проекта, стоит призадуматься, не направлен ли этот проект на создание совершенно бесполезных вещей или достаточно ли он понятен, чтобы быть успешно претворенным в жизнь.
Искусство представления вида будущего изделия и визуализации идей, особенно если к этому процессу привлекаются результаты изучения потребительского спроса, является прерогативой проектировщиков. Иногда их называют дизайнерами потребительских товаров, проектировщиками изделий или даже специалистами по художественному конструированию. Искусством визуализации идей и превращению абстрактных замыслов в детали того, что увидят потребители, можно овладеть только на профессиональной основе. Хотя подобный талант присущ некоторым разработчикам и руководителям проектов, немногим из них удается обратить его в истинное мастерство. Если ставятся цели добиться простоты использования продукта и удовлетворения потребительских запросов, то услуги дизайнеров должны быть востребованы на самых ранних стадиях проработки проектов, а привнесение этого аспекта в концепцию должно стать лишь одним из возможных естественных вкладов в проект со стороны этих специалистов. Если эти услуги дизайнеров привлечены на достаточно ранней стадии и руководство обеспечило реальное внедрение приложенных ими усилий в проект, то это приведет не только к чисто внешней привлекательности продукта, но и будет способствовать повышению его потребительских качеств.
Ежедневное поклонение концептуальным положениям
Один из оригинальных экземпляров Конституции США помещен в музейное хранилище в Вашингтоне, округ Колумбия, за толстыми листами из сверхпрочного стекла. Хотя этот экземпляр хранится в безопасном и надежном месте, я уверен, что в таком формате его читали немногие. Когда идеи недоступны или остаются в тени, они постепенно уходят в небытие (если только из-за особой ценности их не делают музейными экспонатами). Даже в краткосрочных проектах легко утратить ту общую для проекта канву, в которую должны вписываться ежедневные решения, и недостаток видения основных идей способствует возникновению этой разновидности энтропии. Люди могут быть загружены до предела и успешно работать над решением частных задач, но без частой сверки курса с общими ориентирами им будет довольно трудно понять, что все они движутся в правильном направлении. Концепция, или сборник основных идей и целей проекта, является частью общего процесса, и поэтому она должна постоянно присутствовать в коридорах и офисах людей, выполняющих свою работу.
Чтобы концепция всегда была на видном месте, несколько ключевых целей проекта должны быть оформлены в виде плакатов, расположенных в наиболее людных местах. Их открытое обсуждение должно вестись на еженедельных или ежемесячных совещаниях после предварительной публичной зачитки. Если командой используется демонстрационный экран или другие вспомогательные средства визуализации, то ключевые моменты должны быть отображены на первом слайде или первой странице. Большинство сотрудников в любое время должны быть в состоянии назвать основные цели проекта, по крайней мере, те из них, к которым они имеют непосредственное отношение или за реализацию которых несут личную ответственность.
Но этих мер явно не достаточно для поддержания концепции в актуальном состоянии. Лишь то, что люди ее запомнили, еще не означает, что они ее используют в своей работе. Сохранение актуальности концепции требует усилий со стороны руководства команды. Оно должно постоянно обращаться к тем самым мотивам, которые и привели к созданию самой концепции.
В процессе работы над реализацией проекта на каждом совещании по подведению итогов или постановке задач обращайтесь к следующим вопросам:
1. Насколько точно концепция отражает наши цели, определенные для этого проекта?
2. Помогает ли концепция ведущим и рядовым сотрудникам принимать решения, а также отклонять запросы, не имеющие к ней отношения?
3. Есть ли достойные обсуждения изменения концептуальных положений, позволяющие положительно ответить на два первых вопроса?
Если руководство организации в состоянии сохранять актуальность концептуального документа, то предоставляет такую же возможность и всем остальным. Концепция и цели проекта сохраняют жизненные силы и могут служить постоянным источником мотивации и ясности действий всей команды.
Но это вовсе не означает, что концепция должна подвергаться частым корректировкам. Наоборот, существенные изменения, после того как проект наберет полные обороты, должны быть событием исключительным. Но, как и в случае с поправками к Конституции, вполне вероятно, что при определенных обстоятельствах вносимые изменения будут вполне оправданы. И такая возможность позволяет сохранять у всех четкость представлений и осмысленность основных концептуальных замыслов.
Выводы
• Концептуальные документы являются квинтэссенцией всех остальных материалов планирования и находят свое выражение в едином обобщенном плане.
• Документирование приносит пользу и создателю концепции, и всей команде. Тем самым закладываются основы для проведения дискуссий и рабочие ориентиры, не зависящие от нашей «дырявой» памяти.
• Степень детализации вашего концептуального документа зависит от особенностей команды и самого проекта.
• Цели команды должны быть производными от целей, определенных в концепции, а индивидуальные цели, в свою очередь, от целей, поставленных перед командой.
• Хорошая концепция отличается простотой, запоминаемостью, целенаправленностью, способностью консолидировать усилия участников проекта и вдохновлять их на его реализацию.
• Объем не является эквивалентом качества. А краткость требует больших усилий.
• Концепция должна сохранять актуальность за счет ее повседневной сверки с решениями, принимаемыми в ходе реализации проекта.
Упражнения
1. Выберите какой-нибудь фильм или книгу, которые, по вашему мнению, вызывают вдохновение. Благодаря каким качествам фильма возможен этот эффект воздействия? Представьте себя режиссером фильма. Составьте краткие концептуальные положения фильма, перечислите те качества фильма, которые вы хотели бы иметь в его окончательной версии. Если вы выбрали такой фильм, посмотрите DVD-комментарии, чтобы услышать, как создателям фильма удалось добиться такого воздействия на зрителей.
2. Закройте глаза и представьте, на что по завершении будет похож проект, над которым вы работаете. Если завершенный проект преобразовать в художественный фильм, на что будет похож его саундтрек? Будет ли это фоновая музыка (приглушенная музыка, которую можно услышать в лифтах и комнатах ожидания)? Танцевальная музыка? Панк-рок? Подберите для проекта музыку из кинофильма, воспользовавшись помощью специалистов команды, и раздайте им компакт-диск или список воспроизведения.
3. Исследуйте историю прорицателей. Выберите любых двух из следующего списка: Ганди, Малкольм Х, Торо, Будда, Сократ, Иисус Христос или Конфуций. Какими были их мировоззренческие концепции? Как они развивали свои идеи? Что они делали для выражения этих идей? Для их продвижения и популяризации?
4. Выберите какой-нибудь день и подсчитайте, какой процент вашего времени ушел на чтение составленных кем-то письменных документов. Обязательно включите сюда текстовые сообщения, электронную почту, моментальные сообщения, веб-сайты, доски объявлений, письма из дома, а также документы, имеющие непосредственное отношение к проекту. Не забудьте подсчитать время, затраченное на записи этих подсчетов. Это упражнение поможет вам понять, почему с учетом всего времени, потраченного на чтение, так важно уделять внимание составлению концептуальных документов.
5. Что может произойти, если чьи-то индивидуальные цели вступают в конфликт с целями команды или проекта? Кто должен разрешить подобную ситуацию? Какие действия нужно предпринять?
6. Когда настанет время для команды написать концептуальный документ или технические условия, распечатайте несколько копий Конституции США и оставьте все это на стуле любого из авторов технических условий с запиской: «Они составили технические условия для целого правительства всего на шести страницах. А сколько понадобится тебе для описания отдельной характеристики?» Как на это отреагирует команда?
7. В начале каждого проекта составьте общий для всех список жаргонных слов, нерекомендуемых к употреблению. Выберите слова, которые, по вашим сведениям, имеются в лексиконе ваших людей, но у которых есть более приемлемые и понятные синонимы (которые нужно предложить). Поместите список на публичном wiki-сайте и позвольте людям по мере работы над проектом вносить в него дополнения.
8. Чтобы развеселить команду, составьте антиконцепцию. Каким вам видится наихудший вариант концепции? Что в него может быть включено? Как он может быть написан и каким может быть его объем? Посмотрите, можно ли придумать концептуальные положения еще хуже тех, которые в качестве неудачных примеров приводились в этой главе.
9. Определите всех представителей команды, которым можете доверить соавторство с вами по составлению концептуального документа. Запишите свои доводы на этот счет. Если бы вам пришлось выбирать кого-то одного из вашей организации на роль ведущего автора концептуального документа, то кто бы это мог быть?
Глава 5. Откуда берутся идеи
Видимо, не стоит удивляться тому, что идеи исходят от людей. В истории человечества еще не было примеров, когда бы источником идей служили груды камней, кучи навоза или пучки дротиков. Идеи не берутся из самоучителей, они не зарождаются на творческих семинарах или в мозговых атаках, которые могут стать лишь проводниками идей, их источником все же являются люди. Из этого следует, что именно благодаря индивидууму, а не каким-то там процессам, методологиям или комиссиям, в проектах зарождаются идеи и находятся способы их воплощения в жизнь.
Итак, в зарождении идей нет ничего волшебного. Нам всем (в той или иной степени) свойственны озарения. Не стоит забывать, что в самой природе людей, как, впрочем, и всех живых существ, заложены творческие и познавательные начала, помогающие в решении возникающих проблем. Несмотря на то что в современной жизни опыт применения этих начал может быть сведен к минимуму, они все же присутствуют. Наш биологический вид выжил в первую очередь благодаря тому, что мы находили способы справляться с трудностями и изобретали соответствующие инструменты и методы, позволяющие их преодолеть. (Хотя вполне уместно задать вопрос, не эта ли склонность к изобретательству принесла в наш 21 век больше проблем, чем было решено с помощью тех же изобретений.)
В реализации проектов способность отыскивать ценные идеи играет весьма важную роль от первого и до последнего дня работы. Удачные идеи нужны уже на ранней стадии принятия решений, относящихся к планированию, при проектировании, при создании качественного программного кода и при успешной реализации всех пожеланий пользователя. Сфера применения этих идей может быть разной (например, некоторые из них окажут влияние на проект в целом, в то время как другие найдут отражение лишь в одной программной строке), но процесс их выработки и выбора в общем-то схож. В этой и следующей главах я раскрою суть этого процесса. В этой главе я уделю основное внимание тому, как генерировать идеи и развивать творческое мышление, а в главе 6 расскажу, как управлять творческим процессом и распоряжаться имеющимися идеями.
Для иллюстрации процесса работы над идеями я воспользуюсь, главным образом, этапом проектирования (см. главу 2), который затрагивает период времени приблизительно после готовности общего плана (например, концепции) и до начала разработки программного продукта. Если реализация вашего проекта организована несколько иначе, ничего страшного: материалы этой главы вам все равно пригодятся. Приводимые в ней советы достаточно легко применить к любой ситуации, требующей решения проблем и выработки идей.
Разрыв между требованиями и решениями
По причинам, не поддающимся полному объяснению, многие люди испытывают затруднения при планировании творческой деятельности. В большинстве прочитанных мною книг по разработке программных продуктов и управлению проектами вопрос о том, как от списка требований к конечному продукту перейти к качественному проекту, освещен весьма поверхностно. Календарные планы обычно содержат предполагаемые даты подготовки требований и выработки технических условий, но в них практически нет никаких указаний на то, что происходит между этими датами (рис. 5.1).
Рис. 5.1. Проектирование зачастую выглядит как некий таинственный переход от первичного планирования к выработке технических условий
Смириться с этим можно только в том случае, если предстоящая работа продолжительна по срокам, предельно проста и понятна. Неопределенность этого периода времени сглаживается заурядностью предстоящей творческой работы. В противном случае неопределенность процесса проектирования продукта предрекает команде неудачу.[26] Если должны быть решены более сложные проблемы, команде потребуется время для оценки различных подходов и изучения наилучших из них перед тем, как полностью посвятить себя их решению.
Как и путешественнику, стоящему на распутье, знание нужного конечного пункта («Домой, пожалуйста») еще ничего не говорит о лучшем маршруте («Все три пути, по крайней мере, с того места, где я нахожусь, выглядят одинаково»). Мудрые путешественники ищут тот путь, который меньше всего похож на тупик. Возможно, они пройдут немного по каждому из маршрутов или найдут лучшую точку обзора (холм, гору или дистанционно-управляемый спутник-шпион, находящийся на геостационарной орбите), позволяющую получить больше информации. Чем протяженнее предстоящее путешествие, тем больше времени нужно потратить на разведку маршрута.
Для заполнения пробела существует два простых средства. Во-первых, это выработка качественных требований, во-вторых, проектные исследования. Тесная взаимозависимость этих двух аспектов предопределяет возможность их пересечения по времени реализации.
Качественные требования и ошибки
В главе 3 я в общих чертах объяснил, что такое требования и какая роль им отводится в процессе планирования. Проще говоря, качественно составленные требования эффективно сочетают в себе потребительские запросы и (или) задачи проекта с достаточной ясностью изложения, позволяющей их выполнить любому исполнителю. Качественные требования могут не определять способов решения проблемы, но должны содержать ее четкую формулировку, чтобы кто-нибудь, обладающий достаточной компетенцией, смог уверенно работать над ее решением. Практически все команды программистов и проектировщиков, с которыми мне приходилось сталкиваться, проводили, по крайней мере, неформально, процесс выработки требований, возможно, в самом простом виде: путем обмена сообщениями по электронной почте со списками требований, разбитыми по пунктам, состоящим из одного предложения.
Требования имеют решающее значение. Они являются отправной точкой для зарождения идей и потенциальных решений. Если в требованиях определено, что «это будет сарай зеленого цвета», то все задействованные в проектировании специалисты будут думать о всем разнообразии зеленых сараев. Из этого можно извлечь двоякую пользу. Во-первых, из рассмотрения исключается масса ненужных идей (можно будет с легкостью поставить на место тех, кто уже заготовил эскизы голубых космических кораблей). Во-вторых, проектировщики получают возможность задавать вопросы, ведущие к дополнительным исследованиям требований. Эти вопросы могут быть вполне конкретными, например: «Подойдут ли светлые оттенки зеленого или нужен только темно-зеленый цвет? Какова должна быть площадь сарая?», или более общими, например: «Для чего будет использоваться сарай? Предусматривается ли чердак? Он и обойдется недорого, и в хозяйстве пригодится». В зависимости от того, кто несет ответственность за выработку требований и проектирование (см. главу 3), принимать решения, какими должны быть ответы на эти вопросы или предлагать их измененные варианты, будут разные люди, наделенные соответствующими полномочиями. Но стремление задавать вопросы, уточняющие требования и повышающие их качество, должно поощряться.
Итак, чем больше внимания уделено выработке требований, тем выше шансы на то, что проектировщики найдут соответствующие им решения. Если требования не сформулированы, проектировщикам придется работать на собственный страх и риск (то есть если вы ведете проектирование, не имея требований, в ваших собственных интересах составить их самостоятельно). В качестве примерного руководства по улучшению требований я привожу краткий перечень типовых ошибок, которых следует избегать во время разработки этих требований.[27]
Обязательно планируйте обсуждения и последовательные уточнения требований. Поскольку требования вызывают вопросы у проектировщиков, вполне вероятно, что некоторые из этих вопросов окажутся настолько существенными, что потребуют частичного пересмотра самих требований. Кто бы ни нес ответственность за выработку требований, он должен запланировать подобные мероприятия, предусмотрев начало обсуждений с проектировщиками на достаточно ранней стадии, позволяющей учесть их мнения, или создать условия для корректировки требований на более поздней стадии, после того как уже будет предложен ряд ценных идей. Требования должны формироваться вокруг сути решаемых проблем, а не вокруг конкретных путей их решения, чтобы в дальнейшем меньше приходилось подвергать их корректировке.
Постарайтесь отыскать все ошибочные предположения. Требования нередко основаны на мнимых предположениях о потребностях или желаниях заказчиков или пользователей. Формирование списка возможных требований может вестись по электронной почте или в виде неформальных перечней, и каждый может предположить, что их тщательное исследование и всестороннее рассмотрение проведено кем-то другим. Если вы руководите проектом, то подобных предположений делать не стоит. Вы должны настойчиво задавать уточняющие вопросы, такие как «Зачем это нужно?», «Какую проблему с помощью этого требования можно решить?», «Кто выдвинул это требование?» Подобные вопросы помогают высветить истинную суть предположений. Помните, что людям свойственно заблуждаться или неосознанно распространять ложную информацию.
Постарайтесь выявить все упущения. Самые грубые ошибки в составлении требований связаны с упущениями. Они могут носить как частичный, так и общий характер. Частичные упущения заключаются в пропуске одного из аспектов требования (например, при указании поля данных пропущен его формат), а общие – в пропуске какого-нибудь требования целиком (веб-сайт должен быть на греческом языке и поддерживать работу в Firefox 1.0). Упущения могут допускаться по двум совершенно разным причинам: либо заказчику безразличен данный аспект проблемы, либо этот аспект важен для него, но он о нем не подумал или забыл включить в перечень. Тут, как и в случае с ошибочными предположениями, именно руководитель проекта должен выявить все информационные пробелы и определить одну из двух причин их возникновения.
Определите относительный приоритет каждого требования. Поскольку всем нам свойственно включать в список покупок все, что только нужно и не нужно, то по отношению к требованиям крайне необходимо определить важность каждого из них относительно всех остальных. После установки относительного приоритета становится значительно легче вести переговоры между специалистами, отвечающими за выработку требований, и специалистами, отвечающими за разработку конечного продукта (подробнее вопросы приоритетов рассмотрены в главе 12).
Постарайтесь уточнить или исключить все случайно вкравшиеся неоднозначные понятия. Такие слова, как
Используя одну из постановок задач, рассматриваемых в главах 3 и 4, рассмотрим один из вариантов качественной формулировки отдельного требования:
Результаты поиска должны легко и быстро читаться большинством пользователей. Приоритет – 1. Наша цель состоит в том, чтобы постепенно сделать работу с системой поиска намного удобнее. Мы изменим внешний вид имеющейся на данный момент страницы результатов поиска за счет устранения пяти наиболее существенных пользовательских претензий и решения пяти наиболее важных проблем, которые будут выявлены в процессе предстоящей оценки эргономики существующего дизайна. Страница с обновленным дизайном станет единой страницей для отображения результатов поиска, появляющихся после ввода аргументов во все основные поисковые поля (в навигационной панели, в домашней странице, в покупательской корзине), а если это не повлечет за собой значительных затрат, то и для отображения результатов поиска с использованием всех имеющихся поисковых полей.
Естественно, возможна и более глубокая детализация, но даже столь краткое описание, состоящее всего из нескольких предложений, способно уберечь требование от множества просчетов, допускаемых при формулировке. Обратите внимание на то, что в требовании определены намерения, а не сами вопросы переработки дизайна страницы. Чем глубже детализация требования, тем выше риск, что оно станет накладывать на дизайн излишние ограничения. Насколько целесообразна глубокая детализация, зависит от распределения полномочий и мастерства разработчиков.
Исследование проекта
Теперь, после того как мы согласились (а ничего другого, собственно, и не оставалось) с тем, что требования играют весьма важную роль, можно обсудить, как исследовать основанные на этих требованиях идеи.
Поскольку требования уже изложены, проектировщики могут обследовать ограниченную ими область, представляющую собой довольно большое пространство потенциальных путей решения любой отдельно взятой задачи, которое называется пространством решения проблемы. В зависимости от требований это пространство может быть весьма обширным; например, существует несметное количество способов обустройства дома, приготовления еды, создания системы учета, веб-сайта или чего-нибудь еще, за что вам платят деньги. Итак, пока у вас не сложится некоторое представление об имеющихся возможностях (на основании предварительного исследования этой области), останавливаться на каких-нибудь ранее найденных решениях неразумно. Первые же пришедшие в голову идеи вряд ли будут удачными, поскольку вы все еще находитесь в процессе изучения путей подхода в пределах пространства решения проблем и выработки представления о своих возможностях.
На рис. 5.2 показано пространство решения проблем, определяемое на основе имеющихся требований. Как только проектировщик приступит к исследованию идей, удовлетворяющих требованиям, пространство решения проблем станет расширяться. Его расширение обусловлено тем, что в процессе ранней проработки какого-нибудь вопроса или эскиза вскрывается все больше и больше ранее не замеченных решений и возможностей. Например, требование может иметь следующую формулировку: «Веб-сайт должен обеспечивать полнотекстовый поиск на всех страницах», но при этом, скорее всего, ничего не будет сказано об используемой для этого поисковой машине, о способах настройки поиска или о способах встраивания пользовательского интерфейса поиска в структуру веб-сайта. То есть кто-то должен исследовать все многообразие существующих возможностей. (Несмотря на это, пространство решения проблем в конечном счете сужается, о чем мы поговорим в следующей главе.)
Рис. 5.2. Конструкторские замыслы возникают на основе формулировки задачи
В зависимости от характера требований границы пространства решения проблем могут различаться. Если на поиск альтернатив отпущена всего лишь неделя, а стоимость производства готового изделия должна составлять лишь 10 долларов, это пространство крайне ограничено. Проектировщик будет вынужден довольствоваться весьма скудным выбором альтернативных вариантов. Вообще-то можно ведь задать и абсолютно невыполнимые требования (например, создать вечный двигатель или решить задачу NP-заполнения в полиномиальном времени). Время, бюджет, компетентность и определенные проектные критерии – все это оказывает влияние на форму или размер пространства решения проблем. Этим частично объясняется то огромное влияние, которое оказывает выработка требований на процесс проектирования.
Также этим объясняется, почему должна быть обратная связь между проектированием и выработкой требований. Если выясняется, что некоторые требования, учитывая ограниченность пространства решения проблем, удовлетворить невозможно, они должны быть каким-то образом скорректированы. И наоборот, если проектировщику пришла в голову фантастическая идея, которая отвечает целям данного проекта и для реализации которой нужно внести изменения в требования, то обсуждение соответствующей корректировки будет уже в интересах клиента, заказчика или бизнеса.
Неудивительно, что работа чаще всего приобретает инновационный характер при условии, что ответственность за выработку требований и проектирование возложена на одного и того же человека (то есть кто-то в недавно созданной компании, в научно-исследовательской лаборатории или группе наделил его соответствующими полномочиями). При этом он может единолично регулировать любые изменения, как в требованиях, так и в вопросах проектирования.
Страх перед просчетами и размышления о прогрессе
Возможно, многие стараются уклониться от участия в проектировании, опасаясь проводить исследования под пристальным взглядом других людей. Когда мы исследуем собственную работу (например, пытаемся оптимизировать алгоритм или подправить документ), то делаем это без свидетелей. Мы можем свободно проверять самые сомнительные или странные идеи, самостоятельно оценивая собственные действия. А занимаясь проектированием в составе команды согласно графику общей работы, каждый проектировщик будет проводить исследования на виду у массы людей. Все создаваемые им эскизы или прототипы придется публично демонстрировать и открыто обсуждать. Если люди не верят в конструктивность высказываемых им критических замечаний, то не удивительно, что они боятся участвовать в процессе проектирования.[28]
В отличие от процессов отладки и документирования, при проектировании большинство из нас не знает, чем измерить объем работы. Вместо наблюдения за ростом или убыванием цифровых показателей, руководитель должен рассчитывать на собственные (возможно, не столь богатые) знания процесса проектирования или на собственную субъективную оценку творческого прогресса (которая может отсутствовать или быть, на его взгляд, недостоверной). К этому примешивается опасение, что излишняя структуризация работы наложит ограничения на творческий полет мысли проектировщиков, а недостаточная структуризация может вообще увести проект в неизвестном направлении. (В конце главы 6 я даю обещание объяснить в следующей главе, как все-таки справиться с этой задачей.)
В общем, я считаю, что творческая работа – неважно, с чем именно она связана, со строительством мостов, проектированием космических кораблей или конструированием веб-сайтов – страдает от множества стереотипов. Руководители и лидеры должны быть первыми, кому от них следует избавиться. К процессу поиска идей можно отнести два наихудших стереотипа, или ложных понятия, которые выражаются следующими вредными фразами: «плохих идей не бывает» и «нестандартное мышление». Исследуя эти фразы и стоящие за ними ошибочные представления, я раскрою несколько простых путей рассуждения о творческом процессе и дам совет, как отыскивать удачные идеи.
Поделиться книгой: