Думаю, ни один участник команды не станет спорить с тем, что хороший пользовательский интерфейс — ключевое условие успеха продукта. Увы, на этом согласие заканчивается. В командах, одолеваемых проблемами с пользовательским интерфейсом, нередко отсутствует работа с прототипом пользовательского интерфейса, или члены команды не могут договориться о том, как организовать эту работу. Часто проблемы с пользовательским интерфейсом — самое серьёзное испытание, грозящее сорвать план реализации проекта.

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

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

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

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

Прототип даёт команде разработчиков множество преимуществ.

• Возможность сосредоточиться на решении ключевых задач.

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

Из собственного опыта

Когда в NuMega решили создать TrueTime, новую программу-профайлер, было ясно, что интерфейс для неё придётся создавать «с нуля». Но на что должен быть похож новый интерфейс? Какие действия наиболее важны для пользователя? Ознакомившись с положением в отрасли, мы обнаружили массу хороших продуктов, в целом составляющих весьма развитый набор ПО. Однако все существующие программы перегружали пользователя информацией, что, с нашей точки зрения, является недостатком, так как это очень затрудняет выполнение самой важной задачи продукта — поиск проблем с производительностью программ. Теперь мы знали, к чему стремиться: нужно сделать так, чтобы поиск проблем с производительностью с помощью нашей программы требовал не больше трёх щелчков. Вся команда сообща работала над созданием интерфейса, чтобы решить эту просто сформулированную, но такую трудную задачу. Мы решили не усложнять интерфейс и разработали новый подход к навигации по сложной иерархии функций, в которой зачастую таятся проблемы с производительностью. В результате первый выпуск TrueTime принёс нам премию «Best of Show», присуждаемую журналом Comdex/Byte Magazine. Основным фактором успеха была концентрация усилий команды на решении определённых задач.

• Точность

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

• Планирование

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

• Документация

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

• Тестирование

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

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

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

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

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

• Задачи, которые скорее всего придётся решать новым пользователям программы

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

• Задачи, которые чаще всего решают постоянные пользователи программы

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

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

• Прототипы на бумаге

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

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

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

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

Из собственного опыта

Бумажные прототипы могут быть чрезвычайно эффективны, но если команда не верит в результативность этой методики, использовать её нельзя. Чтобы побороть эту проблему в NuMega, мы отправили всю команду на однодневный методический курс, который читали в институте UEI (Usability Engineering Institute). Особое внимание в этом курсе уделялось работе с бумажными прототипами. Это был замечательный способ продемонстрировать участникам команды, насколько важны и эффективны могут быть прототипы на бумаге. Этот курс изменил наши представления о разработке ПО.

• Инструменты RAD

Создание прототипов с помощью инструментов для быстрой разработки приложений (RAD, Rapid Application Development), — вероятно, самая популярная методика. Подходящим можно считать любой инструмент, позволяющий быстро создать наглядную функционирующую модель пользовательского интерфейса.

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

• Описания

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

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

Рассмотрим пример с бумажным прототипом. Если вы попросите пользователя выполнить некоторую задачу, ему придётся «щёлкнуть» ряд элементов интерфейса. При этом часть работы придётся делать вам, управляя механикой интерфейса и имитируя для пользователя работу компьютера. Вам придётся собственноручно выкладывать перед пользователем новые «диалоговые окна», наблюдать затем, какие «кнопки» он выбирает, и убирать «окна», когда пользователь «щёлкает ОК»

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

Из собственного опыта

Во время разработки TrueCoverage, первого продукта NuMega для отображения результатов исполнения кода, команде снова пришлось искать форму пользовательского интерфейса. Чтобы помочь нам в этом, наш специалист по инженерной психологии (совмещавший эту должность с работой технического писателя) вдвоём с ведущим разработчиком создали бумажный прототип пользовательского интерфейса. Затем мы попросили других участников команды выполнить ряд задач, самых важных, по нашим оценкам. Когда новоявленные пользователи закончили свою работу, мы проанализировали их успехи и неудачи. Мы также собрали их отзывы и опробовали ряд новых подходов, решая проблемы, с которыми они столкнулись. Затем мы попросили поработать с прототипом других сотрудников компании, в частности менеджера по продукции и персонал технической поддержки, и также получили их отзывы. Наконец, мы испытали прототип за пределами компании, чтобы узнать, какое впечатление он произведёт на реальных пользователей. Мы выполняли доводку интерфейса очень быстро, прорабатывая до десятка прототипов в неделю. Действительно, во время проведения фазы тестирования нам удалось обнаружить ряд крупных проблем со слиянием данных. Страшно подумать, сколько времени отнял бы поиск и решение этих проблем обычными методами: наверное, не меньше, чем время полного цикла работы над выпуском, а может и больше. За короткое время (в сумме не больше двух недель) мы закончили проектирование интерфейса. Он не был совершенным, в дальнейшем пришлось вносить небольшие изменения. Но ещё до начала написания кода у нас была готовая на 90%, проверенная пользователями конструкция. Проработанный пользовательский интерфейс позволил точнее спланировать реализацию проекта, а тестировщики и создатели документации смогли если не опробовать программу на деле, то хотя бы разобраться в её особенностях раньше, чем она была написана.

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

Специалисты по инженерной психологии отвечают за решение следующих задач:

• Формулирование требований к прототипу пользовательского интерфейса

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

• Формулирование требований к прототипу программы установки

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

• Формирование первоначального впечатления от продукта

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

Из собственного опыта

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

• Создание графики, изображений, значков и цветовых схем

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

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

• Лицензионное соглашение

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

• Упаковка

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

• Документация, электронная справка и дополнительные материалы

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

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

• контроль хода работы над пользовательским интерфейсом, как текущий, так и по завершении каждого существенного этапа работы над проектом;

• консультации и санкционирование мелких изменений пользовательского интерфейса;

• создание или поиск элементов графического оформления продукта;

• надзор за созданием упаковки, лицензионного соглашения и формирование первоначального впечатления от продукта (см. выше);

• внутренняя и внешняя проверка ПО: хотя для крупных изменений может не остаться времени, небольшие изменения могут быть вполне возможны — это поможет лучше подготовиться к работе над следующим выпуском;

• визуальный контроль за ПО для обеспечения соответствия стандартам платформы, для которой ПО создано.

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

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

Если спросить у разработчиков, нужны ли им внешние отзывы при разработке пользовательского интерфейса, в ответ почти всегда можно услышать «Да». И всё же в жизни совсем мало команд получает внешние отзывы о своих проектах, особенно в начале работы. Дело в том, что трудно дать отзыв о том, чего ещё нет. Описанная в этой главе методика позволяет более успешно собирать внешние отзывы.

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

Фундаментальная идея этой главы в том, что основные элементы пользовательского интерфейса должны быть «на местах» уже в начале работы над проектом. Их нельзя существенно изменять, если мы хотим уложиться в первоначальный план. Бесспорно, инновации не только возможны, но и необходимы, однако работу с ними нужно завершить на этапе работы с прототипом. Именно поэтому следует быстро проверять и отрабатывать разные варианты. Протестировав прототип заранее, вы избавляете себя от необходимости вносить значительные изменения в будущем. Даже при возникновении новой идеи, представляющей прорыв в данной области, сохранится уверенность в том, что текущие идеи в состоянии удовлетворить потребности рынка, что позволит уложиться в план. Я не говорю, что во время реализации проекта нельзя вносить небольшие изменения. Как правило, во время разработки возникает масса полезных идей, существенно повышающих ценность программы с очень небольшими затратами. Многие из них вполне могут быть реализованы без риска срыва плана или возникновения серьёзных проблем.