Лекція 14. Управління програмним проектом
Що таке управління?
У різних джерелах можна знайти різні визначення поняття «управління»:
1) елемент, функція організованих систем різної природи, що забезпечує збереження їх певної структури, підтримку режиму діяльності, реалізацію їх програм і цілей. (СЕС);
2) керівництво, напрям чий-небудь діяльності. (www.mega.km.ru);
3) зміна стану об'єкту, системи або процесу, що веде до досягнення поставленої мети (словник по кібернетиці).
З погляду останнього визначення, істотним є:
наявність мети управління;
наявність (можливість) дії, що управляє;
наявність вимірювань стану об'єкту або процесу;
обмеженість управління.
Що таке проект?
Слово «проект» має достатньо багато значень. Походить від латинського projectus, що означає «кинутий вперед». Під проектом зазвичай розуміється деякий достатньо складний вид діяльності, управління яким є також достатньо складно і при успіху може принести добрий результат. Відомо декілька визначень проекту:
1) довільний ряд дій або завдань, що має певну мету, яка буде досягнута в рамках виконання деяких завдань, певними датами, що характеризуються, почала і закінчення, межами фінансування і ресурсами (Р. Керцнер);
2) одноразова робота, яка має певні дати почала і закінчення, ясно певну мету, можливості і, як правило, бюджет (Д. Люіс);
3) тимчасове зусилля, вживане для того, щоб створити унікальний продукт або послугу з певною датою почала і закінчення дії, що відрізняється від дій, що продовжуються, повторних, і вимагаючого прогресивного вдосконалення характеристик (PMI).
Проект – це.
В этих определениях в той или иной степени отражаются следующие существенные характеристики проекта:
Мета проекту.
Унікальність.
Обмеженість в часі.
Обмеженість ресурсів, що виділяються на виконання проекту.
Складність.
Невизначеність.
Передбаченість.
Іншими словами, проект – це достатньо складний вид діяльності, яким складно управляти через його унікальність і обмеженість ресурсів і часу. Ця обставина вносить до проекту елемент невизначеності, а правильно організоване управління робить результати передбаченими.
Управління проектами
Відомо декілька визначень управління проектами:
Набір перевірених принципів, методів і методик, вживаних для ефективного планування, складання графіка, управління і відстежування результатів роботи (PMI)
Планування, організація, контроль і управління ресурсами компанії, виділеними в рамках певного проекту. (Керцнер – Kerzner)
Спеціалізація загального менеджменту, що визначає застосування стандартних керівних навиків планування, організації, комплектування персоналом, просування, а також управління і контролю для досягнення певної мети проекту (Фатрелл).
Якнайповнішим можна рахувати визначення, сформульоване PMI в Зведенні знань по управлінню проектами (PMBOK): «Управління проектом (Project Management - PM) – це наука і мистецтво керівництва і координації людських і матеріальних ресурсів впродовж життєвого циклу проекту шляхом застосування сучасних методів і техніки управління для досягнення визначених в проекті результатів по складу і об'єму робіт, вартості, часу, якості і задоволенню учасників проекту».
Управління проектом засноване на двох китах (принципах):
Уміння – знання принципів і методів управління проектом.
Навики – досвід в області управління – застосування уміння для досягнення цілей в конкретних умовах
Історія управління проектами
Хотя разработка методов и приемов управления была начата еще в начале прошлого века, как дисциплина управление проектами начало складываться в 50-х годах XX столетия, что было вызвано необходимостью координации работ в крупных проектах по разработке вооружений и освоению космоса (США). Разрабатывались методы управления крупными проектами, среди которых наиболее известными являются:
Метод критичного шляху – МКП (CPM – Critical Path Method) .
Метод аналізу і оцінки програм PERT (Program Evaluation and Review Technique) .
60-80 рр. минулого століття характеризуються широким розповсюдженням методів управління проектами, створенням комп'ютерних програм на базі МКП, PERT і розробкою нових методів і програм правління проектами.
З 90 рр. XX ст. головним чином завдяки зусиллям PMI (Project Management Institute) управління проектами стає професією і галуззю знань.
В даний час в США майже не залишилося компаній, які не використовують формальні методи управління проектами. У Росії формальні методи в проектах використовує незначне число підприємств. Більшість з цих інноваторів працюють на ринку інформаційних технологій. Згідно дослідженню, проведеному консалтинговою компанією Interthink, 97,5% компаній в США і Канаді використовують формалізовані підходи до управління проектами, а 22,5% компаній використовують повністю проектно-орієнтований підхід для всіх своїх проектів.
У Росії і Україні ж ситуація прямо протилежна. По оцінках експертів, тільки 5% компаній використовують ті або інші формальні підходи до управління проектами.
Категорії управління проектами
У загальному випадку виділяють наступні групи категорій:
Цілі, визначувані очікуваними результатами проекту.
Критерії успіху і обмеження: вартість, терміни, якість.
Основні важелі управління: ресурси і технології.
Допоміжні важелі управління.
Невизначеність, пов'язана з ризиками виконання проекту.
Трикутник обмежень проекту
Ці три основні обмеження (терміни, витрати і якість результату) взаємозв'язані. Для ілюстрації взаємозв'язку використовують трикутник обмежень, в якому якість, час і гроші інтерпретуються площами внутрішніх трикутників. У цьому трикутнику центр і верхня вершини фіксовані, а нижні вершини можуть переміщатися. Трикутник ілюструє, що будь-яке скорочення фінансів або часу веде до скорочення якості, а збільшення якості може бути досягнуте за рахунок збільшення фінансування або термінів.
Не проекти – це .
До непроектам відносять ті види діяльності, пряме управління якими неможливе або досить просто. До не проектів можна віднести:
Програма – широкомасштабне зусилля, направлене на досягнення деякої комплексної мети.
Виконання сталого процесу – діяльність, яка виконується багато разів і постійно: конвеєрне виробництво, обробка замовлень, ведення бухгалтерії. Має конкретну мету і виділені ресурси, але не є унікальною або складною і не пов'язана з конкретними термінами. Управління такими процесами, що повторюються, відносно просте.
Рішення творчої задачі. Тут є конкретна мета, унікальність і складність, але, як правило, немає обмежень за часом і ресурсам
Що повинен знати менеджер проекту?
PMBOK: 9 галузей управлінських знань
PMBOK (Project Management Body of Knowledge – Зведення знань по управлінню проектами) – міжнародний стандарт складу знань по управлінню проектами, який розроблений і розвивається Інститутом Проектного Менеджменту (Project Management Institute - PMI). Відомі версії цього стандарту від 1996, 2000 і 2004 рр. PMBOK містить описи складу знань по наступних 9 розділам (галузям знань) управління проектами:
Управління інтеграцією проекту (Integration)
Створення плану проекту (Project Plan Development)
Виконання плану проекту (Project Plan Execution)
Контроль змін в проекті (Integrated Change Control)
Управління об'ємом робіт (Scope)
Ініціація (Initiation)
Планирование объема работ (Scope Planning)
Формалізація об'єму робіт (Scope Definition)
Верифікація (Scope Verification)
Управління змінами об'єму робіт (Scope Change Control)
Управління часом виконання (Time)
Визначення складу робіт (Activity Definition)
Визначення взаємозв'язків робіт (Activity Sequencing)
Оцінка тривалості робіт (Activity Duration Estimating)
Складання розкладу проекту (Schedule Development)
Управління вартістю (Cost)
Планування ресурсів (Resource Planning)
Оцінка вартостей (Cost Estimating)
Розробка бюджету (Cost Budgeting)
Контроль вартості (Cost Control)
Управління якістю (Quality)
Планування якості (Quality Planning)
Забезпечення якості процесу (Quality Assurance)
Контроль якості результатів (Quality Control)
Управління персоналом (Human Resource)
Організаційне планування (Organizational Planning)
Підбір кадрів (Staff Acquisition)
Розвиток команди проекту (Team Development)
Управління комунікаціями (Communications)
Планування взаємодії (Communications Planning)
Розподіл інформації (Information Distribution)
Оцінка виконання (Performance Reporting)
Адміністративне завершення (Administrative Closure)
Управління ризиками (Risk)
Планування управління ризиками (Risk Management Planning)
Ідентифікація рисок (Risk Identification)
Якісний аналіз рисок (Qualitative Risk Analysis)
Кількісний аналіз рисок (Quantitative Risk Analysis)
Планування реагування на ризики (Risk Response Planning)
Моніторинг і контроль рисок (Risk Monitoring and Control)
Управління закупівлями і постачаннями (Procurement)
Планування закупівель (Procurement Planning)
Планування пропозицій (Solicitation Planning)
Отримання пропозицій (Solicitation)
Вибір постачальників (Source Selection)
Управління контрактами (Contract Administration)
Завершення контрактів (Contract Closeout)
SQI: 34 компетенції IT менеджера
Інститутом якості ПО (SQI - Software Quality Institute) розроблений керівною документ (Body of Knowledge) для сертифікації менеджерів програмних проектів (SWPM – SoftWare Project Management). У цьому документі міститься список 34 компетенцій, якими повинен володіти менеджер програмного проекту. Список роздільний на три основні категорії:
Методика розробки продукту
Навики управління проектів
Навики управління персоналом
Методика розробки продукту
Процеси оцінювання - визначення критеріїв для відбору
Знання стандартів процесу
Визначення продукту - ідентифікація клієнтського середовища і вимог, що висуваються до продукту
Оцінка альтернативних процесів
Управління требованиями- моніторинг зміни вимог
Управління субпідрядниками - планування, управління і здійснення контролю
Виконання початкової оцінки - оцінка ступеня трудності, рисок, витрат і створення графіків
Відбір методів і інструментів - визначення процесів відбору
Підгонка процесів - модифікація стандартних процесів з метою задоволення вимог проектів
Відстежування якості продукту - контроль якості в процесі розробки продукту
Розуміння дій з розробки продукту - вивчення циклу розробки ПО
Навики управління проектів
Створення структури післяопераційного переліку робіт
Документування планів - ідентифікація ключових компонент
Оцінка вартості - вартості завершення проекту
Оцінка трудовитрат - необхідних для завершення проекту
Менеджмент рисок - ідентифікація, визначення дії, обробка рисок
Відстежування процесу розробки - контроль процесу розробки
Складання графіка - розробка графіка і ключових стадій проекту
Вибір метричних показників
Відбір інструментів менеджменту проекту - вибір методик і інструментів
Відстежування процесів - моніторинг сумісності членів команди
Відстежування ходу розробки продукту - моніторинг ходу розробки за вибраними метричними показниками
Навики управління персоналом
Оцінка продуктивності - оцінка дій команди, направлених на підвищення її продуктивності
Питання інтелектуальної власності - розуміння ступеня впливу критичних проблем
Організація ефективних зустрічей - планування і проведення
Взаємодія і спілкування - з розробниками, керівництвом і іншими командами
Лідерство - навчання проектних команд для отримання оптимальних результатів
Управління змінами - забезпечення ефективного управління змінами
Успішне ведення переговорів - вирішення конфліктів і ведення переговорів
Планування кар'єрного зростання - структуризація і управління ходом реалізації кар'єри
Ефективне уявлення - використання письмових і усних навиків
Набір персоналу - вербування і співбесіда з членами команди
Відбір команди - висококомпетентних фахівців
Створення команди - формування, керівництво і підтримка ефективної команди
Управління командою проекту
Управління програмним проектом включає вирішення трьох основних завдань:
Підбір і управління командою
Вибір процесу
Вибирання інструментальних засобів
З безлічі питань управління командою проекту будуть розглянуті три:
Ролева модель команди
Моделі організації команд
Спілкування в команді
Ролева модель команди
Склад команди визначається досвідом і рівнем колективу, особливостями проекту, вживаними технологіями і рівнем цих технологій. Склад команди визначається також типом виконуваних робіт: під замовлення або виробництво коробочки.
У представленій моделі виділені наступні основні ролі:
Менеджер проекту – головна дійова особа, що володіє знаннями і навиками, необхідними для успішного управління проектом. Його основні функції:
Підбір і управління кадрами
Підготовка і виконання плану проекту
Керівництво командою
Забезпечення зв'язку між підрозділами
Забезпечення готовності продукту
Проектувальник – це функція проектування архітектури високого рівня і контролю її виконання. У невеликих командах функція розподіляється між менеджером і розробниками. У великих проектах це може бути цілий відділ. Основними функціями проектування є:
Аналіз вимог
Розробка архітектури і основних інтерфейсів
Участь в плануванні проекту
Контроль виконання проекту
Участь в підборі кадрів
Розробник – роль, відповідальна за безпосереднє створення кінцевого продукту. Окрім власне програмування в його функції входить:
Контроль архітектурних і технічних специфікацій продукту
Підбір технологічних інструментів і стандартів
Діагностика і дозвіл всіх технічних проблем
Контроль за роботою розробників документації, тестування, технологів
Моніторинг стану продукту (ведення списку виявлених помилок)
Підбір інструментів розробки, метрик і стандартів. Контроль їх використання.
Тестувальник – роль, відповідальна за задоволення вимог до продукту (функціональних і нефункціональних). У функції тестувальника входить:
Складання плану тестування. План тестування складає один з елементів проекту і складається до початку реалізації (розробки) проекту. Час, що відводиться в плані на тестування може бути зіставно з часом розробки.
Контроль виконання плану. Найважливіша функція контролю – підтримка цілісності бази даних зареєстрованих помилок. У цій базі реєструється:
хто, коли і де виявив, опис помилки, опис стану середовища;
статус помилки: пріоритет, хто вирішує
стан помилки: висить, в розробці, дозволена, проблеми
Ця база повинна бути доступна всім, оскільки в тестуванні беруть участь всі члени команди.
Розробка тестів. Сама трудомістка частина в роботі тестувальника. Тестування повинне забезпечити повну перевірку функціональності при всіх режимах роботи продукту.
Автоматизація тестування включає автоматизацію складання тестів, автоматизацію пропуску тестів і автоматизацію обробки результатів тестування. З причини важливості автоматизації тестування, іноді вводять нового учасника – інженера по автоматизації.
Вибір інструментів, метрик, стандартів для організації процесу тестування.
Організація Бета тестування – тестування майже готового продукту зовнішніми тестерами (користувачами). Цю важливу процедуру треба продумати і організувати у разі розробки продукту коробочки.
Інженер за якістю. У сучасному уявленні розглядається три аспекти (рівня) якості:
якість кінцевого продукту – забезпечується тестуванням
якість процесу розробки (теза: для підвищення якості продукту треба підвищить якість процесу розробки)
якість (рівень) організації (теза: для підвищення якості процесу треба підвищити якість організації робіт).
В деяких випадках функції інженера за якістю покладаються на тестувальника. Насправді вони ширші – два наступні рівні якості. Тут приведені функції, відмінні від функції тестувальника:
Складання плану якості. План якості включає всі заходи щодо підвищення якості (на всіх рівнях). Має довготривалий характер. План тестування – його оперативна складова.
Опис процесів. Опис процесів є їх формалізацією. При описі вводяться метрики процесу, що впливають на якість продукту.
Оценка процессов включает регистрацию хода выполнения процессов и оценку значений установленных метрик процессов. Выявление «слабых» мест и выработка рекомендаций по улучшению процессов.
Поліпшення процесів - перевизначення процесу, автоматизація частини робіт, навчання персоналу.
Технічний письменник або розробник призначеної (і інший) для користувача документації як частини програмного продукту. Функціями технічного письменника є:
Розробка плану документування, який включає склад, терміни підготовки і порядок тестування документів.
Вибір і розробка стандартів і шаблонів підготовки документів
Вибирання засобів автоматизації документування
Розробка документації
Організація тестування документації
Участь в тестуванні продукту.
Технолог розробки ПО забезпечує виконання наступних завдань:
Підтримка моделі ЖЦ – створення служб і структур по підтримці працездатності прийнятої моделі ЖЦ ПО.
Створення і супровід середовища збірки продукту. Функція особливо важлива на завершуючих етапах розробки або при використанні моделі прототипирования. У такій ситуації збірка проводитиметься достатньо часто. Середовище збірки повинне бути підготовлена заздалегідь, збірка повинна проводитися швидко і без збоїв. З урахуванням збірки версій це не просте завдання.
Створення і супровід процедури установки з тим, щоб кожна збірка встановлювалася автоматично з урахуванням версії і конфігурацій середовищ.
Управління початковими текстами – супровід і адміністрування системи управління версіями початкових текстів.
Моделі організації команд
Теорія ієрархії потреб
Потреби людини пов'язані з властивостями людської особи. Психіка людини украй складна, і достатньо повних теорій потреб людини ще не побудовано. Проте, зараз існує ряд теорій, що описують види і взаємини потреб, на підставі яких розробник виробів може діяти достатньо упевнено і добиватися добрих практичних результатів.
Одной из наиболее распространенных теорий является теория иерархии потребностей английского ученого Авраама Маслоу (Abraham Maslow), выдвинутая им в 50-е годы нашего века. По Маслоу, существует 5 групп или уровней потребностей:
Основні або фізіологічні потреби – такі, як потреби в їжі, одязі, житло і так далі, які визначаються біологічною природою людини
Потреби в захищеності від “ударів долі”, таких, як нещасні випадки, хвороби, інвалідність, убогість і ін., які можуть порушити можливість задоволення потреб попереднього рівня, – фізіологічних потреб
Соціальні потреби, тобто потреби в спілкуванні, взаєминах з іншими людьми. По Маслоу, потреби кожного рівня пов'язані з можливістю задоволення потреб попереднього рівня, і соціальні потреби викликані прагненням більш повно задовольнити потреби в захищеності
Потреби визнання або потреби “Его”. Це – потреби в престижі, пошані тих, що оточують, славі і так далі
Потреби розвитку – найвищий рівень потребностей- потреби в самоудосконаленні, або потребі розвитку.
По Маслоу, перехід до потреби більш високого рівня відбувається, якщо потреба попереднього рівня задоволена на 100%; сучасні психологи вважають, що цей відсоток менший - близько 70% і навіть менш. Ієрархія потреб конкретної людини багато в чому визначається рівнем розвитку його психіки, вона міняється від людини до людини і різна у однієї людини в різні періоди його життя. З розвитком психіки людини потреби більш високого рівня стають важливішого в порівнянні з потребами нижчого рівня.
Можна вважати, що всі ці види потреб існують не тільки для окремої людини, але і для колективів людей, зокрема підприємств і суспільства в цілому.
Peopleware – людський чинник
Проблеми людського чинника пов'язані з тим (виявляються в тому), що люди, що беруть участь в проекті:
Всі разные – по характеру, темпераменту, активності, цілям – немає двох однакових людей.
Всі схожі – участь в проекті об'єднує людей спільністю цілей, пошуком шляхів досягнення цих цілей.
Розрізняються за типом (індивідуалісти – члени команди, генератори ідей – виконавці, відповідальні, – безвідповідальні).
Постійні і мінливі – люди, як правило, проявляють постійність своїх звичок і властивостей характеру, але при цьому здатні проявляти «протилежні» якості: індивідуаліст – командні якості, виконавець – генерувати ідеї .
Багатообразні – треба розуміти, що різноманіття людей є основною гарантією виживання людства взагалі і можливості виконувати ІТ проекти зокрема.
Адміністративна модель (теорія X)
Это традиционный стиль управления, связанный с иерархической административно-командной моделью, которую используют военные организации. В основе лежит теория X, которая утверждает, что такой подход необходим, поскольку большинство людей по своей природе не любит работу и будет стремиться избежать ее, если у них есть такая возможность. Однако менеджеры должны принуждать, контролировать, направлять сотрудников и угрожать им, чтобы получить от них максимальную отдачу. Девиз теории и модели: Люди делают только то, что вы контролируете. Или в более мягком варианте: Люди делают то, что они не хотят делать, только если вы их контролируете.
Характерні риси моделі:
Владна піраміда.
Чіткий розподіл ролей і обов'язків.
Чіткий розподіл відповідальності.
Проходження інструкціям, процедурам, технологіям.
Роль менеджера: планування, контроль, ухвалення основних рішень.
Переваги моделі: ясність, простота, прогнозованість. Модель добре поєднується з каскадною моделлю життєвого циклу і застосовна в тих же випадках, що і каскадна модель. Модель ефективна у разі сталого процесу.
Недоліки моделі пов'язані з тим, що адміністративна система прагне самозбереженню (стабільності) і погано сприйнятлива до зміни ситуації – нові типи проектів, застосування нових технологій, оперативна реакція на зміну ринку. Крім того, в адміністративній моделі погано уживаються індивідуалісти і генератори ідей.
Модель хаосу (теорія Y)
У основі моделі хаосу лежить Теорія Y, яка є повною протилежністю Теорії X. Основна теза Теорії Y: робота — природна і приємна діяльність і більшість людей, насправді, дуже відповідальні і не ухиляються від роботи.
Характерними рисами моделі хаосу є:
Відсутність явно виражених ознак влади
Роль менеджера – поставити завдання, забезпечити ресурсами, не заважати і стежити, щоб не заважали інші
Відсутність інструкцій і регламентованих процедур
Індивідуальна ініціатива – рішення з проблеми приймається там, де проблема виявлена
Процес нагадує творчу гру учасників на основі дружньої соревновательности
Переваги такої моделі в тому, що творча ініціатива учасників нічим не зв'язана і потенціал учасників розкривається повною мірою. Це буває особливо ефективно у разі, коли для вирішення проблеми потрібний пошук нових підходів, методів, ідей і засобів. Команда стає командою «прориву», а робота проходить у формі гри, мета якої – пошук якнайкращого результату. Процес нагадує випадковий пошук, коли ідеї і рішення народжуються при живому і як би випадковому обговоренні проблем в коридорі, їдальні на пікніку. Зібрати таку команду в робочій кімнаті і влаштувати обговорення за регламентом часто просто не вдається – це команда творчих індивідуалістів.
Недостатки модели связаны с тем, что при определенных условиях команда прорыва может стать командой провала. Причинами провала могут быть:
Творча соревновательность переходить в конкуренцію спочатку ідей, а потім – осіб.
Процес починає переважати над метою проекту – висловлені ідеї не доводяться до кінця і змінялися новими ідеями, переважання отримують «красиві» ідеї, лежачі в стороні від основних цілей проекту.
Люди, здібні до генерації ідей, рідко володіють терпінням доведення ідей до повної реалізації
Модель хаосу – це те, що потрібне для освоєння нових земель. Модель хаосу не противоречит адміністративної моделі – вона її доповнює і може ефективно з нею бути сусідами.
Відкрита архітектура (теорія Z)
Адміністративна і хаотична моделі є двома «крайнощами», між якими знаходяться безліч моделей, що поєднують переваги «крайніх» моделей. Однією з таких моделей є модель відкритої архітектури, заснована на Теорії Z. Ця теорія була сформульована Уїльямом Оучи на основі вивчення досвіду японського стилю управління. Теорія Z припускає наявність внутрішнього механізму управління, заснованого на впливі з боку колег і групи в цілому. Додаткову дію надають культурні норми конкретної корпорації.
Основний принцип моделі можна сформулювати так: «Працюємо спокійно. Працюємо разом». Особливостями цієї моделі є:
Адаптація до умов роботи – якщо робимо незалежні модулі, то розходимося і робимо, якщо потрібна архітектура бази даних, то збираємося разом і обговорюємо ідеї.
Колективне обговорення проблем, вироблення консенсусу і ухвалення рішення – не всі можуть погодиться, але ухвалене рішення є колективним і через це – обов'язковим для всіх.
Розподілена відповідальність – відповідають всі, хто обговорював, виробляв, приймав.
Динаміка складу робочих груп залежно від поточних завдань.
Відсутність спеціалізації – учасники міняються ролями і функціями і можуть при необхідності замінити один одного.
Завдання менеджера – активна участь в процесі, контроль конструктивності обговорень, забезпечення можливості активної участі всіх.
Відкрита архітектура є гнучкішою, такою, що адаптується, настроюється на ситуацію. Вона дає можливість проявити себе всім членам команди – в ній можуть уживатися і індивідуалісти і колективісти. Колективне обговорення висловлених ідей дозволяє залишати тільки прагматичні ідеї.
Спілкування в команді
Комунікації
Основним чинником в розробці програмного забезпечення є можливість комунікації (спілкування учасників проекту). Спілкування може проводитися в різних формах від строго формалізованого (стандартизована документація) до повністю неформалізованого (питання-відповідь сусідові, обговорення в неформальній обстановці).
Ухвалення рішень – компроміс і консенсус
Метою спілкування в команді розробників є обговорення поточних проблем і питань і ухвалення рішень.
Ухвалене в результаті обговорення рішення може бути досягнуте в результаті компромісу або в результаті консенсусу. У чому різниця цих результатів?
Почнемо з визначень (Глоссарій.ру):
Компроміс – угода, досягнута за допомогою взаємних поступок.
Консенсус (колективна думка) – загальна для конкретної групи думка
Компроміс:
Це середнє рішення, яке може опинитися гірше за кожне з варіантів
Досягається шляхом взаємних поступок
Може бути прийнятий більшістю
Консенсус:
Це оптимальне рішення, поєднуюче краще із запропонованих варіантів
Досягається шляхом обговорення, аналізу і генерації нових ідей
Приймається загальною згодою