Что относится к ограничениям проекта
Разбираемся с проектными ограничениями
Всем давно известно, что любому проекту присущи ограничения: обычно вспоминают про сроки, бюджет и качество. Вы, конечно, помните заезженную байку из серии «выберите только два из трёх» — ограничения интересны в первую очередь тем, что они взаимосвязаны.
На деловой игре «Египет бросает вызов», которую я проводил в прошлую пятницу, этот вопрос мы немного обсуждали с группой, однако мне показалось, что обычное объяснение — «ограничения есть, они таковы и они взаимосвязаны» — слишком поверхностно. Признаюсь, особой глубины в данной теме я не вижу, однако некоторыми соображениями готов поделиться.
Соображение первое — сколько всего ограничений?
Разумеется, мы включим в список упомянутые выше сроки, бюджет и качество. Но полон ли такой список? Для проектов среднего и большого размера, думаю, нет: следует добавить в него ещё и охват, при этом я бы не стал объединять охват и качество в единую сущность, как предлагают некоторые методологии.
Поясню на примере той самой деловой игры: изначально фараон хочет пирамиду, и он готов сформулировать требования к этому конечному продукту. Выявленные и задокументированные требования ложатся в основу критериев качества, нарушать которые (то есть выходить за ограничения) проектная команда просто так не должна. В то же время по ходу проекта от заказчика прилетают новые идеи и инициативы, вплоть до дополнительных продуктов проекта. Охват проекта меняется, становясь отдельным ограничением, связанным с остальными и находящимся под управлением проектной группы. Можно, к примеру, успеть в те же сроки и те же деньги сделать пирамиду поменьше, зато добавить к ней пристройку (другой охват взамен ранее согласованного качества).
Но только ли охват следует добавить в список? Знатоки PMBoK, конечно же, вспомнят, что в данном талмуде источнике знаний рассматривается аж шесть ограничений, иллюстрируемых причудливой формой:
На мой взгляд, прежде чем придумывать дополнительные ограничения следует разобраться с их природой. К примеру, ресурсы зачастую выступают ограничением, так как бывают не в том количестве или не того качества (компетенций), как требуется, несмотря на наличие денег для их приобретения или привлечения. Но важно помнить, что ресурсы — внутреннее дело проекта, а не проблема заказчика. Да, менеджеру проекта приходится озадачиваться вопросами ресурсного обеспечения, но выносить их решение или даже обсуждение на клиента можно далеко не в каждом случае. В отличие от сроков, бюджета, качества и охвата — слов, понятных заказчику.
Не менее запутанная ситуация и с рисками. Мне кажется, что управление рисками не следует смешивать с управлением ограничениями проекта.
Итак, во многих случаях необходимым и достаточным будет список из четырёх пунктов. Соль и перец добавляем по вкусу.
Соображение второе — действительно ли ограничения жёстко взаимосвязаны?
Разумеется, мы можем привести друг другу массу примеров жёстких связей — дёргаешь за одно, меняются другие. Однако не следует забывать про такие понятия как производительность, эффективность и технологии. Одну и ту же работу/задачу можно выполнить разными способами, и вполне возможна ситуация, когда, скажем, сроки проекта резко сокращены, а в установленные деньги и качество попасть всё равно можно.
Соображение третье — что делать с ограничениями?
Источники знаний по управлению проектами зачастую не детализируют этот вопрос, рекомендуя менеджеру «держать руку на пульсе«, а также «контролировать ключевые параметры проекта«. Это прекрасно, но что конкретно нужно делать? По моему мнению, список действий менеджера проекта по работе с проектными ограничениями предельно прост. При выявлении выхода или угрозы выхода за установленные органичения менеджер должен:
Соображение четвёртое — «водопад» и Agile смотрят на ограничения по-разному
Многие из нас привыкли действовать следующим образом: заказчик ставит задачу, мы определяем способ её решения, формируем перечень работ, из него получаем оценку сроков и оценку бюджета. Далее согласовываем с заказчиком и приступаем к выполнению. Обратите внимание: мы изначально фиксируем два ограничения (охват и качество), а другие два (сроки и бюджет) являются производными.
Совершенно другая картина в гибких подходах. Получив задачу мы договариваемся о сроках и бюджете первой итерации (спринта), и только затем определяем чего именно получится достичь за выделенные сроки и деньги. То есть охват и качество являются следствием ограничений по календарю и финансам. Такой подход поддерживает общие идеи Agile вроде:
Получается, что прежде, чем планировать проект и работать с проектными ограничениями, следует определиться с подходом к выполнению проекта.
На фото: проектный офис игры, которая была в пятницу, готов к работе, но пока даже не догадывается, что его ожидает.
Основы управления проектами (8 стр.)
Типы ограничении проекта
Технические или логические ограничения
Технические ограничения связаны с последовательностью, в которой должны выполняться операции проекта и показаны на рис. 3.1.А.
Сеть проекта для каркаса дома должна отражать последовательность трех операций:
заливка фундамента, строительство каркаса, возведение крыши.
В сети для проекта нового программного обеспечения можно последовательно расположить операции:
проектирования, кодирования, испытания в сети. 
Рис. 3.1. Примеры ограничений
Ограничения на количество ресурсов
Отсутствие или нехватка ресурсов могут весьма значительно повлиять на технические ограничения.
Потенциал для конфликта ресурсов несут параллельные операции.
Предположим, что вы занимаетесь планированием приема по случаю бракосочетания, который состоит из 4 операций:
план,заказ оркестра,украшение зала и закупка легкой закуски.
Для выполнения каждой операции требуется один день.
Нет технических причин или зависимости одной операции от другой (см. рис. 3.1.B ).
Однако, если все операции будет выполнять один человек, ограничение на количество ресурсов потребует, чтобы операции выполнялись последовательно или сериями. (см. рис. 3.1. С ).
Зависимость ресурсов имеет приоритет над технологической зависимостью, но не нарушает ее;
В редких случаях существуют физические ограничения, когда выполнение обычно параллельных операций ограничивается условиями контракта или окружающей среды.
Виды ограничений на количество ресурсов
Люди являются наиболее очевидным ресурсом проекта.
В редких случаях некоторые умения взаимозаменяемы, но при этом, как правило, теряется производительность.
Материалы
Задержка в выполнении многих проектов часто объясняется нехваткой материалов.
Если известно, что может возникнуть недостаток наличия материалов и это может сказаться на проекте, они должны быть включены в сетевой план проекта.
Оборудование
Очень часто оборудование не рассматривают, как ограничение.
Наиболее распространенной ошибкой является то, что считают, что имеющихся ресурсов более чем достаточно для выполнения данного проекта.
Например, если для выполнения проекта требуется один экскаватор в течение 6 месяцев, а организация имеет 4 экскаватора, то часто считают, что данный ресурс не вызовет задержки в выполнении проекта.
Однако если существует несколько проектов, то имеет смысл в целях экономии использовать общие ресурсы.
Такой подход требует проверки наличия ресурсов для всех проектов и предусматривает резерв оборудования для конкретных потребностей проекта в будущем.
Текущие активы
В некоторых проектах текущие активы рассматриваются как ресурс, поскольку они ограниченны.
Если текущие активы поступают в недостаточном количестве, поскольку промежуточные выплаты производятся ежемесячно, то использование материалов и рабочей силы следует ограничить, чтобы сохранить наличные деньги.
Такая ситуация связана с проблемой движения денежной наличности.
Классификация проблем календарного планирования
Большинство имеющихся сегодня методов календарного планирования требует, чтобы руководители проекта классифицировали его по ограничению времени проекта или по ограничению на количество ресурсов.
Если ответ положительный, то проект ограничен по времени, если нет, то проект ограничен по количеству ресурсов.
Метод распределения ресурсов
Исходные положения
Эти ограничивающие допущения не существуют на практике, но они упрощают процесс изучения.
Для руководителей проекта, которые являются новичками в этом деле, на практике легче иметь дело с дроблением операций и изменением уровня ресурсов, если это необходимо.
Проекты, ограниченные по времени
Если потребность в конкретном типе ресурсов колеблется, то управление затруднено и использование ресурса может быть весьма неэффективным.
Практики решают эту проблему, используя метод выравнивания ресурсов, который уравнивает или сглаживает потребность в ресурсах.
Все методы выравнивания приводят к отсрочке исполнения некритических операций для снижения пика потребностей и восполняя их нехватку.
При демонстрации этого примера будет использован только один тип ресурсов (например, плотники); в рамках этого типа все ресурсы взаимозаменяемы.
На рис. 3.2 представлен пример сети, ES графика потребности в ресурсах и график использования ресурсов.
Затемненные области на графике потребности представляют границы календарного графика для каждой операции.
Рис. 3.2A. Ограниченная по времени сеть
Поскольку было заявлено, что проект ограничен по времени, целью будет сокращение пика потребностей в ресурсах и, таким образом, повышение степени их использования.
Любая из этих операций может быть задержана, чтобы сократить пик потребности в ресурсах от 5 до 4, используя 2 единицы времени простоя. Выбор, очевидно, будет сделан в пользу операции, которая имеет наименьший риск опоздания (вероятно, операция D, поскольку она имеет наибольший простой).
Схема загрузки ресурсов при раннем старте (ES) ID RES DUR ES LF TS 0 1 2 3 4 5 6 7 8 9 10 11 12 A 2 2 0 2 0 2 2 B 2 6 2 10 2 2 2 2 2 2 2 C 2 4 2 6 0 2 2 2 2 D 1 2 2 10 6 1 1 E 1 2 6 10 6 1 1 F 1 4 6 10 0 1 1 1 1 G 1 2 10 12 0 1 1 Общая загрузка ресурсов 2 2 5 5 4 4 4 4 1 1 1 1 
Рис. 3.2B. Ограниченная по времени сеть
На рис.3.3А показаны результаты задержки операции B.
Рис. 3.3А. График выравнивания ресурсов. Результаты задержки операции В
Рис. 3.3B. Показаны результаты задержки операции D
На рис.3.3В показаны результаты задержки операции D.
Рис. 3.3C. График выравнивания ресурсов. Результаты задержки операции D
Обратите внимание на различие в графиках ресурсов. Важным моментом является то, что ресурсы, необходимые на время существования проекта, были сокращены с 5 до 4 (20%) и использование ресурсов возросло с 57% [необходимые 34 единицы ресурсов в целом (5х12)] до 71% [34/(4×12)].
Кроме того, график был выровнен, что означает облегчение в управлении,
Обратной стороной процесса выравнивания потребности в ресурсах является потеря эластичности сетевого графика, которая происходит в результате сокращения резервов времени выполнения работ.
Риск того, что какие-то операции могут задержать проект, также увеличивается, поскольку сокращение резервов времени выполнения работ приводит к появлению большего числа критических и/или почти критических операций.
Стремление слишком сильно выровнять график ресурсов рискованно. Тогда каждая операция становится критической.
Обычно для выравнивания ресурсов проекта используются операции, которые имеют наибольший резерв времени их выполнения. Это объясняется тем, что с такими операциями связан наименьший риск.
Допущения проекта
Ограничения проектов
Тройное ограничение относится к фазе исполнения проекта, так как именно на этом этапе чаще всего возникает ситуация, что кто-то из сотрудников что-то не успел сделать. Обычное оправдание: «Хотел сделать хорошо, поэтому не справиться с остальными задачами».
Постарайтесь донести мысль, что некоторые вещи не нужно пытаться довести до идеала. Нужно соблюдать баланс, делая работу максимально качественно, но учитывая ограниченность по времени и ресурсам.
Во ФРИИ мы стараемся следовать методологии Lean Startup. Это значит, что создается минимально работоспособный прототип продукта, на котором проверяется — будет ли работать идея в целом. А дальше, если работает, можно уже допиливать отдельные моменты.
Как правильно ставить задачи (цели) по проекту
Рекомендую пользоваться принципом SMART. Как это расшифровывается:
S (Specific — «конкретный»): цели проекта определяются четко и конкретно, чтобы все участники и вовлеченные в процесс люди понимали, что и зачем делают. Неконкретную формулировку допускают часто и она плохо влияет на дальнейшее планирование. Например, задача:»сделать хороший сайт» достаточно абстрактна: нужно четко сформулировать, что именно мы хотим получить на выходе.
A (Achievable — «достижимый»): нужно требовать, чтобы исполнители приложили усилия, но при этом оглядываться на реальный мир и имеющиеся ресурсы. Не нужно ставить цели, которых не достигнуть, даже если вся команда будет работать 24 часа в сутки. Например, спланировать полет на Марс за 2 месяца нереально — для этого требуется гораздо больше времени.
R (Relevant — «последовательный»): все цели должны укладываться в общую концепцию, соотноситься со стратегией развития бизнеса. Например, если вы фокусируетесь на какой-то нише, то нужно развиваться именно в ней. Если не будет результатов, можно рассмотреть и другие ниши, но последовательно.
T (Timed/Timebounded — «измеримый во времени»): для целей нужно намечать временные рамки, не только конечные, но и промежуточные. Например, если сайт должен быть готов через месяц, нужно оценить сроки выполнения всех подзадач и четко сформулировать их сотрудникам и подрядчикам.
Как показывает практика, если не задать критерии по SMART, то с большой вероятностью можно как минимум сорвать дедлайн по проекту.
Чек-лист по планированию проекта
1. Составить полный список задач (SMART);
2. Распределить ресурсы на каждую задачу, убедиться, что их достаточно;
3. Построить взаимосвязь между задачами — можно ли выполнить их параллельно, последовательно, какие нужно завершить до начала реализации следующих;
4. Определить критический путь, учесть риски по срокам и переносу времени исполнения;
5. Исходя из плана и ресурсов высчитать себестоимость проекта для выставления сметы заказчику.
Треугольник проекта
Реализации проекта подразумевает обязательное планирование. Планирование это разработка модели проекта в специализированном программном продукте к примеру MS Project. В процессе планирования команда проекта вписывает проект в ограничения проекта. Ограничения проекта можно разделить на три группы:
Желание заказчика или клиента получить максимальный результат (большой коттедж) в сжатые сроки (желательно за две недели) и за «смешные» деньги ( к примеру за 1000$). Можно ли реализовать такой проект? Большинство из Вас ответят НЕТ. Я бы сказал, МОЖНО, картонные коробки еще не перевелись. Как Вы уже наверно догадались это был пример того что в центре любого проекта лежит качество. И если заказчик или клиент пытается поставить нереальные сроки или бюджет при это заказывая уникальный продукт, он всегда жертвует получить продукт низкого качества. Хотя большой бюджет или длительные сроки не гарантируют качество продукта проекта, но одновременно сокращение предложенных исполнителем сроков и бюджетов может привести к продукту низкого качества. Это связано стем что строя модель проекта исполнитель (подрядчик) вписывает имеющуюся у него технологию реализации проекта. Изменение ограничений приводит к повышения вероятности наступления рисковых событий, а они всегда «бьют» по качеству.
Для чего нужны ограничения на время выполнения задачи в MS Project
В случаях, когда Вам необходимо контролировать время начала и завершения задачи, Вы можете наложить ограничение на время выполнения задачи. Под ограничением в MS Project понимается условие, которое накладывается на срок начала или завершения задачи. В MS Project существует три группы ограничений: 1. Гибкие ограничения. Гибкие ограничения учитывают зависимости между задачами и не привязывают задачу к конкретной дате. К гибким ограничениям относятся:
2. Умеренно жесткие ограничения. Умеренно жесткие ограничения не дают начаться или закончиться задаче раньше или позже указываемой даты. Умеренно жесткие ограничения учитывают зависимости между задачами. К умеренно жестким ограничениям относятся:
3. Жесткие ограничения. Ограничения этой группы не учитывают зависимостей между задачами и жестко привязывают задачу к конкретной дате. К жестким ограничениям относятся:
Если для задачи не принципиально когда начнется или завершится задача, на нее не следует накладывать жестких ограничений. Накладывая жесткие ограничения, Вы лишаете себя выгоды от автоматического пересчета плана проекта. Если ограничение не является необходимым – измените его.
Зачем это нам нужно?
Более детальный разбор этапов
Планирование
По американской методологии PMBOK планирование занимает порядка 50% всего времени, что особенно подчеркивает его значимость.
Планирование лучше начать с разделения проекта на части (Work Breakdown Structure — WBS), где каждая фаза разделена на более мелкие задачи. Это помогает понять объем работ и учесть все нюансы.
Рис. 2 — Структура разделения проекта на подзадачи (WBS)
Графики работ
Очень удобный и практичный инструмент для этого — диаграмма Ганта. По сути, это календарный план, который учитывает взаимосвязь между поставленными задачами, а также показывает ресурсы, необходимые для их выполнения.
Самый простой вариант диаграммы можно сделать в Exсel: слева в таблице находится название работ, а все остальные столбцы — даты.
Рис. 3 — Диаграмма Ганта, Microsoft Exсel
Если работа выполняется в конкретную дату, она заполнена цветом. Такая схема четко отображает объем работ, сроки и последовательность их выполнения.
При наличии визуальной картины выполняемых задач работа над проектом существенно упрощается, так как они привязаны к календарному графику.
Рассмотрим пример диаграммы Ганта, построенной в MSProject.
Рис. 4 — Диаграмма Ганта, Microsoft Project
Слева указаны названия задач, которые подразделяются на этапы (выделены красным) и подзадачи (выделены черным), а также отображена длительность этих задач и календарные даты, когда они выполняются. Справа — графическое представление данных задач и даты их выполнения. Также указаны необходимые ресурсы.
(Обычно ресурсы — это люди, привлеченные для выполнения той или иной задачи. Мы конкретно указываем, какие именно лица должны ее выполнять.)
Задачи соединяются между собой стрелочками: таким образом, постоянно есть графическое представление работ (их очередность и взаимосвязь).
Справа внизу есть график по ресурсам, где указана загрузка каждого человека. Очевидно, что при чрезмерной нагрузке часть задач, скорее всего, не будет выполнена — поэтому требуется всегда оценивать, насколько у вас загружены люди на проекте и реально ли сделать все в нужные сроки.
Такая наглядная картина позволяет оперативно и четко корректировать текущую ситуацию: смещать задачи, увеличивать длительность, искать дополнительные ресурсы, аутсорсинг и так далее.
Визуализация данных также позволяет определять критический путь проекта. Если не вдаваться глубоко в академические определения, это те задачи, при изменении длительности которых изменяется дата окончания проекта. Например, если на дизайн ушло больше времени, чем планировалось, то конечная дата сдачи проекта сдвигается.
Работы, выделенные на графике синим (например, тестирование и наполнение сайта контентом) не влияют на срок сдачи проекта. Таким образом, на данной схеме мы видим, какие работы можно сдвигать, так как они не влияют на срок сдачи проекта, а какие нельзя.
Убедитесь, что концепция решает задачу
На одном из учебных семинаров мы дали слушателям бизнес-задачу и соответствующую бизнес-цель. В процессе выполнения практического задания мы периодически предоставляли дополнительные подробности требований. На каждом этапе мы просили слушателей предложить решение задачи на основе имеющейся информации. К концу выполнения задания у слушателей были похожие идеи решения, но редко кто решал исходную задачу!
Примерно то же происходит в реальных проектах. У команды могут быть ясные цели, создается спецификация, выполняется разработка и тестирование, но на протяжении проекта никто не проводит проверку на предмет соответствия целям. Заинтересованное лицо может предложить «блестящую» новую функцию, которую хочет реализовать. Команда добавляет ее, потому что это кажется разумным и интересным. Но несколько месяцев спустя оказывается, что несмотря на наличие массы крутых функций система не решает исходной задачи.
Говоря о концепции, мы подразумеваем весь продукт. Он будет изменяться относительно медленно при определении со временем стратегии продукта или развитии бизнес-целей. Границы же относятся к определенному проекту или его итерации, в которых реализуются возможности продукта, как показано на рис. 5-1. Границы более динамичны, чем концепция, так как заинтересованные лица изменяют содержимое каждой версии в соответствии с ограничениями графика, бюджета, ресурсов и качества. Границы текущего выпуска должны быть четко определены, но границы будущих выпусков тем менее четко определены, чем более дальняя перспектива рассматривается. Задача команды состоит в управлении границами конкретного проекта разработки или улучшения как определенным подмножеством стратегической концепции продукта.
Рис. 5-1. Концепция продукта охватывает границы каждого запланированного выпуска и тем менее четко определена, чем более дальняя перспектива рассматривается
Перекрывающиеся границы
Федеральное агентство приступило к огромному, рассчитанному на пять лет проекту по разработке информационной системы. На раннем этапе процесса агентство определило бизнес-цели и концепцию системы, которые не будут существенно меняться на протяжении пяти лет. Запланировано 15 выпусков частей всей системы, каждая из которых создается отдельной проектной командой и у каждой есть собственное определение границы проекта. Некоторые проекты будут выполняться параллельно, потому что часть из них взаимосвязаны и время реализации различается. Каждое определение границ должно соответствовать общей концепции продукта и перекрываться с границами других проектов, чтобы ничего не упустить и четко определить рамки ответственности.
Влияние заинтересованных сторон
Успешным проектом можно назвать проект, результаты которого удовлетворяют основных заинтересованных сторон.
Успех проекта оценивается удовлетворенностью заинтересованных сторон, чем больше заинтересованные стороны удовлетворен полученными результатами проектами тем больше можем считать что проект реализуется успешно. Если заказчик полностью удовлетворен полученными результатами (если это возможно ;)) можно считать проект успешно завершенным.
Для большинства длительных проектом наблюдается ситуация, когда видение продукта проекта у заказчика меняется таким образом, что изменение настолько масштабы, что легче закрыть это проекта и инициировать новый. У каждого из участников проекта есть свое видение успешного результата так что основная задача руководителя это согласование желаний и возможностей участников проекта. Инструмент для согласования это план-график проекта.
В последнее время большую популярность приобретают понятие инновационные проекты. Отличительной чертой данных проектов является то что заказчики проекта представляет результаты проекта только в виде качественных параметров. Продуктом инновационного проекта может быть любой результат, главное что бы он соответствовал ожиданиям заказчика.
К примеру, результат инновационного проекта внедрения информационной системы может быть описан как: «высокоэффективная система с большой скоростью обработки данных и простым интерфейсом». Под такое определение может попасть любая система от мобильного приложения до большой сложной информационной системы с разделенными серверами.
Критерии приемки результата проекта
По каждому из элементов содержания проекта, приведенному выше, указывается, как заказчик и мы сами поймем, что результат действительно соответствует ожиданиям? Это обычно самая сложная часть описания содержания проекта, т.к. степень неопределенности еще слишком высока, а договариваться нужно уже тут, на берегу,пока работы не начались.
Настоящее искусство – это сформулировать критерии так, чтобы они были действительно удобны в использовании и не вызывали разночтения.
Например, для элемента “Обученные пользователи” (подкатегория “Обученные бухгалтера по работе с дебиторами”) критерием приемки может быть “Бухгалтер может выполнить следующие операции: ввод акта сверки, согласование счета и т.д. самостоятельно не более чем за 1 минуту”.
Зачем нужна WBS
WBS – крайне полезная вещь в планировании проекта и вот почему:
WBS – если не единственный, но точно самый эффективный способ наглядно отразить весь объем проекта. WBS фокусирует внимание не на процессе а на ожидаемом результате, и создает нужный «посыл». В идеале в разработке WBS участвует заказчик или его представитель и вся команда, что позволяет а) обеспечить единое понимание результатов проекта и его объема б) увидеть важность и вклад отдельных элементов в общий результат С помощью WBS можно наглядно обосновать необходимости в финансах или человеческих ресурсах, так как против конкретного описанного объема возражать гораздо сложнее, чем против «да что там системку написать, посадите программиста и все». WBS помогает предотвратить риски и изменения или по крайней мере значительно (очень значительно!) снизить их вероятность и влияние, так как именно здесь всплывут многие неочевидные ранее вещи и «а мы хотели совсем другое» (и так и должно быть, для этого инструмент и предназначен). На уровне WBS уже можно определить и согласовать контрольные точки проекта (как для решений о продолжении проекта после очередного этапа, так и для контроля затрат человеческих и финансовых ресурсов).
Уже на этом этапе хорошо бы донести до заказчика вашу позицию «Если задач нет в WBS – их нет и в проекте». Во-первых, все постараются при разработке или при согласовании немного больше, а во вторых – у вас появится хороший рычаг влияния на будущее.
Ограничения проектов
Тройное ограничение относится к фазе исполнения проекта, так как именно на этом этапе чаще всего возникает ситуация, что кто-то из сотрудников что-то не успел сделать. Обычное оправдание: «Хотел сделать хорошо, поэтому не справиться с остальными задачами».
Постарайтесь донести мысль, что некоторые вещи не нужно пытаться довести до идеала. Нужно соблюдать баланс, делая работу максимально качественно, но учитывая ограниченность по времени и ресурсам.
Во ФРИИ мы стараемся следовать методологии Lean Startup. Это значит, что создается минимально работоспособный прототип продукта, на котором проверяется — будет ли работать идея в целом. А дальше, если работает, можно уже допиливать отдельные моменты.