До найбільш традиційних методів залучення користувачів відносять їхня участь у проекті на етапах аналізу вимог і оцінки продукту. Однак існує безліч простих і ефективних методів залучення користувачів на більш ранніх етапах, а найчастіше - і протягом усієї розробки продукту. Методи спільної розробки включають підходи, що дозволяють користувачам відігравати роль повноправних партнерів бригади розроблювачів продукту. Скажемо більше, існують методи, що дозволяють бригаді розроблювачів бути рівноправними партнерами користувачів.
Більш інтенсивне залучення користувачів на ранніх етапах проектування і використання методів спільної розробки не можна розцінювати як сумнів у кваліфікації і можливостях бригади по створенню продукту. У всякому разі, ис-пользование цих методів проектною бригадою свідчить про те, що вона постійно знаходиться в курсі вимог користувачів і є гарантією того, що ці вимоги будуть задоволені. Це просто інший набір засобів і методів, що дає проектній бригаді шанс поставити замовнику належний продукт.
У цій главі розглядаються наступні питання.
" Методи залучення користувачів на етапах планування, аналізу требо-ваний, проектування, конструювання, оцінки продукту і розгортання.
" Залучення користувачів у проект.
Є багато причин, по яких залучення користувачів виявляється целесооб-разным в інших сферах розробки продукту, і відповідно, існує багато методів, що дозволяють справитися з цією задачею. Спільна розробка (мал. 6.1) - це метод створення програмного продукту, що дає можливість безпосередньо і завчасно залучити користувачів до задач і прийняття рішень, що визначають уміст системи, ПІ, графіку, інформаційну підтримку, практичність і інші важливі сторони продукту. Приклади методів спільної розробки - методи JAR HJAD.
Спільне вироблення вимог до додатка (Joіnt Applіcatіon Requіrements - JAR) і спільне проектування додатка (Joіnt Applіcatіon Desіgn - JAD) - популярні методи для роботи з законними власниками продукту (чи їхніми уповноваженими представниками) для збору вимог у ході нарад, що відрізняються високим рівнем структуризації і дисциплінованості. Якщо застосовується технологія постачання прототипу на ранніх етапах розробки, можна доповнити вимоги до продукту прототипом ПІ і моделлю логічної бази даних.
Інструментальний набір засобів бригади по розробці орієнтованого на користувача продукту включає багато інших методів. Один з підходів- BUG (Busіness User Group - група бізнесів-користувачів) - більш докладно описується далі в цій главі.
Корисне правило. Варто застосовувати той метод спільної розробки для проекту, що повинний принести чи успіх відповідає строгим критеріям.
Методи залучення користувачів у проект на етапі планування
Користувачі можуть бути не в змозі допомогти в технічних питаннях плани-рования продукту. Як члени проектної бригади користувачі можуть надати підтримку в розгляді технічних аспектів задач розробки продукту. Щирий прихильник інтересів користувачів може працювати з метою залучити до участі в проекті придатних людей у придатне час (мал. 6.2).
Користувачі можуть і не знати, що таке орієнтована на користувача раз-работка продукту, чи мати слабке представлення про розходження в методах і компонентах, що поставляються. Однак інші учасники бригади зобов'язані відповісти на питання користувачів, пояснити мети їхньої участі в проекті, привести деякі приклади.
Ґрунтуючись на цих роз'ясненнях, користувачі, що беруть участь у проекті, можуть подати ідеї про способи своєї участі - включаючи методи, що до цього не розглядалися технічними учасниками бригади. Для досягнення більшої ефективності участь користувачів повинна зміщатися від пасивних видів діяльності до активного партнерства на всіх етапах розробки продукту.
Багато користувачів - експерти у своїй області (наприклад, у керуванні веденням бізнесу, допомоги клієнтам і зароблянні грошей у підтримку діяльності по розвитку). Їхнє глибоке знання ділових задач і способів використання комп'ютерів і ПО грають украй важливу роль.
На етапі планування користувачі можуть істотно допомогти розроблювачам у рішенні наступних проблем.
" Кваліфікація і навички співробітників і керівників, зв'язані з нею воп-росы.
" Кого ще з користувачів ПО необхідно залучити до проекту.
" Указівка джерел залучення інших користувачів і різних джерел вхідної інформації.
" Указівка на вимоги, обумовлені користувачами, дані і процедури, невідомі чи піддава колись фільтрації в рамках чи розроблювача організації-замовника.
" Точка зору користувачів на пріоритети і вимоги до системи.
Досвідчені розроблювачі продукту можуть бути здивовані і збентежені міркуваннями користувачів і ділових людей із приводу вимог і продуктів, а також із приводу використання цих продуктів.
Корисні правила. Варто остерігатися самовпевненості на всьому протязі процесу розробки продукту.
" Упевніться в тім, що керівництво користувачів готове субсидіювати їхнє залучення до проекту в рамках прийнятого підходу. Витрати, зв'язані за участю користувачів, піддаються виміру, оскільки мають потен-циальное значення для удосконалення системи.
" Залучайте реальних користувачів настільки швидко і настільки часто, наскільки це можливо, починаючи з першого дня. На ділові нестатки може надаватися 1-2 години на тиждень. На нестатки проектування може знадобитися 4-8 годин для підтримки однієї наради з користувачами.
" Не ступайте кроку без користувачів-учасників проекту.
Безупинна участь користувачів необхідно на всьому протязі життєвого циклу проекту. Орієнтована на користувачів проектна бригада повинна вміло розподіляти увесь час, присвячене участі користувачів у проекті (т.е, час, затрачуваний на безпосередню роботу з користувачами, і час, необхідний для підготовки цілеспрямованої інформації для користувачів).
Методи залучення користувачів у проект на етапі аналізу вимог
Існує чимало методів залучення користувачів на етапі аналізу требо-ваний, ефективність яких залежить від контексту і специфіки області їхнього застосування.
До найбільш важливих моментів участі користувачів відносяться наступні аспекти.
" Необхідно домогтися залучення й активної участі користувачів у розробці продукту.
" Участь користувачів необхідно протягом усього процесу розробки продукту.
" Варто розширювати границі участі користувачів за межі традиційної > оцінки продукту.
" Необхідно мати у своєму розпорядженні широкий набір методів залучення користувачів.
Кожен метод має свої переваги і недоліками і відрізняється оп-ределенной легкістю у використанні. Однак якщо в розпорядженні орієнтованої на користувачів проектної бригади протягом усього життєвого циклу розробки знаходиться тільки одна група користувачів, бажано мати єдиний, простий і послідовний підхід, що добре працює стосовно до всіх задач циклу розробки. Різні специфічні підходи застосовуються в контексті загального підходу, прикладом якого є використання BUG-груп (метод участі користувачів, що утягує реальних чи користувачів користувачів існуючої системи в процес розробки нового продукту).
Участь користувачів у процесі розробки починається на етапі аналізу требо-ваний і продовжується на етапах проектування, конструювання і тестування. Однак користувачів можна починати залучати до участі в BUG-групі під час планування розробки продукту. Користувачі працюють разом із бригадою по створенню продукту, застосовуючи різноманітні механізми, що включають спостереження, дослідження, презентації, демонстрації, аналіз, методи прискореної візуалізації і прототипирования проектних рішень, сценарії прогонів, вивчення альтернативних рішень, участь у семінарах і тестування практичності. Метод BUG-груп, як і інші методи спільної розробки й оцінки (наприклад, постійний зворотний зв'язок з іншими користувачами), доповнює стендові чи лабораторні іспити продукту на практичність.
Комплектування бригади. BUG-група являє собою розширення орієнтованої на користувачів бригади розроблювачів продукту. Початкове ядро учасників BUG-групи складають уповноважені представники чи замовника АНАЛИТИКИ, проектувальники і розроблювачі прототипів ПІ, а також типові користувачі, що представляють відповідні бізнеси-підрозділи.
У розширену BUG-групу при необхідності входять дизайнери графіки, препо-даватели, інший персонал розроблювачів частини ПО, що не відноситься до ПІ, а також керівники розробки ПО й організації-замовника.
Інформація, яку варто одержати. Ціль складається в роботі з реальними й активними користувачами для оцінки вимог, а також проектуванні для додатка функціональних можливостей і ПІ, даних, логіки задач і загального підходу до ПІ.
Проблемні області, що торкаються явно, включають всі аспекти користувальницького досвіду, що перераховані нижче.
" Визначення користувальницьких профілів.
" Діловий контекст, потік задач (робіт), стереотипи робочого поводження.
" Найбільше задачі, що часто виконуються, і функції.
" Існуючий процес і системні проблеми.
" Бажані удосконалення і передбачувані зміни бізнесів-процесів .
" Послідовність екранів і кроки діалогу при виконанні задач.
" Потреби в даних, а також організація і формат інформації.
" Можливості (функції, ПІ, продуктивність, інформація).
" Пріоритети і компроміси.
" Розташування функціональних кнопок і даних на екрані.
" Переваги у відношенні графічних представлень і термінологічні переваги.
" Впливу, що робляться керуванням змінами.
Як видно з приведеного переліку, обсяг інформації, якому необхідно одержати, досить великий, і її, як правило, варто одержувати ітеративним і эволю-ционным способом. Там, де інформацію одержувати не вдається, вибудовуються опре-деленные припущення і формуються проектні рішення. Припущення под-вергаются перевірці з залученням користувачів.
Важливим моментом, якому необхідно врахувати, є виявлення зайвих эле-ментов у програмному додатку. При переході організації з одного середовища в іншу (наприклад, із середовища мэйнфреймов у середовище робочих станцій) проектувальники виявляють, що деякі дані і функції вже реалізовані і гарне налагоджені протягом тривалого часу. Визначені можливості, один час корисні, виявляються застарілими чи виходять за рамки первісної версії ПО. Однак деякі користувачі і розроблювачі намагаються на це не звертати уваги.
Міць спостереження. Перед початком нарад BUG-групи бригада протягом деякого періоду часу проводить неформальне, але упорядковане спостереження за роботою користувачів. У результаті такого спостереження можна одержати загальне представлення про автоматизовані і неавтоматизовані аспекти робочої, середовища. При цьому вдається ідентифікувати загальні задачі, артефакти, крайності, потреби, перешкоди і характеристики потоку робіт, а також області можливих удосконалень. Результати спостережень аналізуються й узагальнюються для наступного аналізу і формування вхідних даних для проектування. Спостереження, щонайменше , добре вже тим, що породжує відмінний настрій у проектній бригаді.
Корисне правило. Спостереження дає такий чудовий результат, як по-нимание тонких розходжень окремих середовищ і стилів навчання, роботи і использо-вания.
Наступне обстеження. Щоб одержати представницьку вибірку задач і оцінити їхню відносну частоту, наступне обстеження поширюється на більшу кількість користувачів. У ході обстеження користувачі позначають найбільше часто виникаючі і важливі задачі, усвідомлювані потреби і виражають свою позицію. Обстеження використовується для підтвердження результатів спостереження бригади.
Запрошення. Напередодні кожної BUG-наради керівникам бізнес підрозділів направляється запрошення. У запрошенні позначаються теми обговорення, що перед-коштує, і запитується, хто з кінцевих користувачів бізнесів-підрозділів буде учасником наради. Часто керівники прагнуть направити колишніх учасників з метою домогтися визначеного рівня наступності, іноді деяких користувачів указують конкретно.
ДЖЕРЕЛА Залучення користувачів. Користувачі представляють свої робочі підрозділи і відрізняються за рівнем кваліфікації, задачам, стилю роботи і застосовуваним бізнес правилам. У багатьох випадках користувачі не знають один одного чи не працюють постійно разом. Спочатку користувачі не знають учасників проектної бригади. Це може виявитися дійсною проблемою в тих випадках, коли відбувається ротація членів чи бригади участь здійснюється з використанням вилученого доступу, наприклад, за допомогою відеоконференції, за допомогою Іnternet чи іntranet.
Корисне правило. Комплектування бригади являє собою невід'ємну частину BUG-процесу. Щоб одержати якісну вихідну інформацію, зворотний зв'язок і позитивні результати, у бригаді повинний панувати дух відповідальності і довіри.
Аналіз вимог. Після спостереження й обстеження первинний аналіз служить для виділення ключових вимог з вихідних даних. Вимоги приймають форму документованих можливостей для функцій, даних, потоків робіт, ПІ, інформації, практичності й інших важливих сторін продукту. Ці вимоги використовуються для первісного обговорення з учасниками BUG-групи.
Орієнтоване на вимоги проектування є не чим іншим, як представленням можливостей, даних, потоків, ПІ, комплектації настільної системи, доступу до функцій і даних. Орієнтована на вимоги візуалізація -
це матеріалізація проекту вимог для дуже конкретного критичного аналізу проекту разом з користувачами. І проект, і візуалізація можуть мати Дуже наближений і узагальнений характер.
Іноді замість того щоб надавати замовнику первісний проект ПІ, визуализируют орієнтований на вимоги проект на папері з наміром прояснити потреби користувача. При даному способі візуалізації властивості ПІ і практичності представляються і порозуміваються без прив'язки до конкретного проекту. Інформація, отримана на етапі аналізу вимог, є основою рішень, вироблюваних на стадії концептуального проектування, що спрямовано на розробку концептуальних моделей і структур ПІ.
Корисне правило. Випливає по можливості швидше виробляти ориенти-рованный на вимоги проект і здійснювати візуалізацію, що" відбиває розуміння проектною бригадою необхідних особливостей продукту.
Відзначимо один ключовий момент, зв'язаний із проектом вимог і візуалізацією - вони не призначені для чи формалізації додання остаточної форми проектному підходу для ПІ, їх ціль - ясно "озвучити" неявні чи невстановлені вимоги для їхній наступного документування і критичного аналізу. Ще одна важлива задача полягає в з'ясуванні користувальницьких пріоритетів щодо можливостей і швидкості доступу до функцій і даним, тобто виявлення найбільш важливих функцій і даних.
Корисне правило. Результати і рішення BUG-нарад варто представляти у виді ясно викладених документів і поширювати їх серед учасників, щоб вони могли швидко переглянути і зрозуміти ці документи.
Методи залучення користувачів у проект на етапі проектування
З погляду проекту доцільно відкрити всі аспекти проектування ПІ для участі користувачів, точно так само доцільно всі аспекти роботи користувачів відкрити для участі бригади по створенню продукту. Користувачі одержують повний доступ до усіх видів діяльності і компонентам, що поставляються, що традиційно входили в компетенцію розроблювачів продукту.
Корисне правило. Сама тяжка робота для ортодоксального проектувальника ПІ- допустити користувача до розробки і дозволити йому давати ради (чи - подумати страшно - керувати!).
Проект і прототип. У міру того як вимоги здобувають стійкість, орієнтована на вимоги проект і візуалізація починають еволюціонувати убік інтерактивних моделей і прототипів. Конструюється інтерактивний прототип з використанням мови реалізації для продукту, після чого він демонструється користувачам, щоб одержати їхні відкликання. Продовжують проводитися сеанси наскрізного контролю на папері і перегляди проектних рішень з користувачами-учасниками BUG-групи. Однак у міру того як прототип здобуває стійкість, його передають користувачам, що не входять у BUG-групу, для практичного застосування у формальному і неформальному контексті. Зауваження користувачів оформляються документально в ході критичного аналізу проектного прототипу.
З погляду ПІ користувачі можуть брати участь у розробці наступних проектних рішень.
" Поводження середовища робочого столу, інтеграція і погодженість.
" Концептуальні моделі, термінологія і піктограми.
" Послідовності екранів - кроки/уміст, графічний стиль і компонування.
" Усі деталі, що стосуються ПІ, а також загальний користувальницький досвід.
Корисне правило. Моделі повинні бути дуже конкретними і відчутними за рахунок використання реальних користувальницьких сценаріїв.
Вибір альтернатив. Представте варіанти BUG-групі, але зробіть це об'єктивно й у стилі прогону сценаріїв. Подайте позитивні, негативні і нейтральні фактори. Задайте питання, що допускають різні тлумачення. Запитаєте думку користувачів. Якщо бригада заздалегідь не виробила альтернатив, розробіть їх разом з користувачами.
Корисне правило. У своєму прагненні показати користувачам товар обличчям не переборщите, ведучи їх туди, куди вони не можуть піти (чи дозволяючи їм піти туди, куди вони піти не в змозі).
Швидкі цикли: перегляд/ітерація/еволюція. В міру додавання можливостей, даних і механізмів ПІ, а також задоволення запитів користувачів у проект вносяться зміни. Наступні перегляди виконуються доти , поки потреби користувачів і можливості системи не збіжаться. Візуалізація вимог розвивається в інтерактивний прототип ПІ. Прототип має достатню стійкість, щоб дозволити інтерактивна взаємодія користувачів під час практичних семінарів і іспитів практичності разом з користувачами. Прототип може містити визначені функціональні аспекти, що вказують, якої образом реалізуються деякі можливості.
Безупинний аналіз задач. BUG-група стає механізмом непре-рывного аналізу задач. Виявляються зв'язані з задачами аспекти, що могли бути упущені з виду. Як приклад такого аспекту можна привести варіанти задачі, що залежать від визначеної чи дати часу року. Стреси також стимулюють проведення іспитів продукту під час проектування.
BUG-наради. Типове засідання користувачів може тривати біля двох годин. Кожне засідання до деякої міри неформально і складається з декількох етапів, при цьому порядок денний, як правило, включає наступні питання.
" Представлення (модератор, проектувальник, секретар, користувачі і тема).
" Правила зустрічі (відкритість, правдивість і т.д.).
" Поширення матеріалів перегляду (задачі, вікна, питання, специфікації і т.д.).
" Огляд можливостей додатка і ПІ.
" Прогін зразкової задачі.
" При можливості, практичне заняття з прототипом.
" Документальне оформлення результатів наради (рішення, питання і т.д.).
" Планування наступного наради і теми.
Результати наради документуються і поширюються негайно після BUG-наради. Документація використовується для впливу на перераховані компоненти продукту, що поставляються нижче.
" Журнал питань по продукті (для документування проблем і робочих питань) і резолюція.
" План по продукті (зміст, етапність, пріоритети і т.д.).
" Вимоги (можливості, ПІ, інформація і пріоритети).
" Прецеденти (сценарії).
" Проект ПІ/специфікація/прототип.
" Модель бізнесів-об'єктів продукту.
Наради повторюються так часто і довго, скільки необхідно.
Спеціальні групи. У деяких випадках підгрупам приходиться братися за дуже специфічні чи задачі проблеми, що недоцільно вирішувати під час регулярних BUG-нарад. Під егідою BUG-групи по розробці продукту формуються спеціальні групи (Specіal Іnterest Group- SІ). Проміжні і кінцеві результати їхньої роботи координуються BUG-групою і бригадою по розробці продукту.
Корисне правило. Зустріну з BUG-групою варто проводити тоді, коли по-лезная інформація, отримана в результаті переглядів, досягає деякої кри-тической маси. На ранніх етапах проекту наради проводяться двічі в тиждень, на більш пізніх етапах - щотижня.
Робота "у шкірі користувача". В міру просування проекту й уточнення зв'язаних з ним деталей спробуйте використовувати чи прототип модель, виконуючи реальну роботу як користувач. Наприклад, коли користувач вирішує задачу за допомогою існуючих засобів і методів, виконаєте цю задачу паралельно, використовуючи доступну на даному етапі розробки чи модель прототип продукту. Як альтернативу проаналізуйте існуючі і майбутні задачі, крок за кроком проганяючи сценарії їхнього виконання і порівнюючи їх між собою. Це дозволить упевнитися в ефективності вимог проекту і потоку робіт.
Методи залучення користувачів
проект на етапі конструювання
Етап конструювання в розробці ПО звичайно повний сюрпризів і робіт, зв'язаних з усуненням минулих недоліків. Тут приймаються проектні рішення на дуже низькому рівні деталізації, що не були розглянуті чи були пропущені в ході узагальненого чи деталізованого проектування. Ці сюрпризи дуже часто під час чи програмування блокового тестування, коли виявляються проблеми реалізації, чи обмеження недогляди. Приклади подібних чи несподіванок упущених з виду рішень приведені далі.
" Чіткість представлення деякої графіки на пристроях відображення визначеного чи типу з визначеним дозволом.
" Кількість елементів у списку, що повертається в результаті операції пошуку.
" Первісний час відгуку при виклику зображення.
" Непередбачене поводження.
" Незвичайні формати печатки.
Раз за разом рішення приймаються швидко, причому на обмірковування і розгляд відповідного рішення проблеми приділяється небагато часу. У будь-якому випадку для вибору одного з можливих проектних рішень залучається BUG-група. Якщо необхідно прийняти рішення моментальне, BUG-група схвалює відповідь якнайшвидше . У противному випадку використовується така можливість, як підтвердження через електронну чи пошту електронне голосування. Коли дозволяє час, розглянуті можливості аналізуються на найближчій BUG-нараді.
Основний момент тут полягає в тім, що чи проектувальнику орієнтованої на користувача проектній бригаді немає необхідності самостійно приймати рішення, багато хто з який можуть бути критичними з погляду прак-тичности на низькому рівні представлення. Учасником і помічником у прийнятті цих рішень виступає BUG-група.
Методи залучення користувачів
у проект на етапі оцінки продукту
В основному оцінка продукту зв'язана з тестуванням. Існує величезне коли-чество всіляких тестів, включаючи компонентне і системне тестування, тепер можна проводити більш широке обстеження для виміру ступеня користувальницької задоволеності від ПО в окремі моменти часу.
Члени BUG-групи також беруть участь в обстеженні і допомагають аналізувати і пояснювати результати, що є основою для наступних дій проектної бригади. У якості найбільш важливих складових зворотні зв'язки можна вказати рівень задоволеності користувачів системою і конкретними додатками, проблематичні задачі, недоліки в практичності, області, піддані помилками, і області, важкі у вивченні і використанні.
Кращі практичні прийоми
Існує ряд прийомів роботи з BUG-групою, що зарекомендували себе щонайкраще . Нижче перераховані деякі з них.
" Сприяйте комплектуванню бригади, заохочуйте колективну роботу і спільну відповідальність за результати.
" Надайте можливість користувачам втручатися і давати вказівки.
" Якнайшвидше надавайте в розпорядження користувачів конкретну візуалізацію проектних рішень (швидке проектування і прототипирование).
" Якнайшвидше задовольняйте потреби користувачів (ефективні ітерації/еволюція).
" Спілкуйтеся один з одним (навчайте, слухайте, слухайте і відповідайте).
" Будьте прямі, конкретно виражайте свої думки (потреби, пріоритети, альтернативи, можливості).
" Завжди використовуйте питання, що допускають різні тлумачення, щоб одержати вірні відповіді.
" Документуйте усі ваші дії.
"
Існує кілька методів ведення наради, що зарекомендували себе краще інших. Наприклад, прогін сценарію виконання задачі з використанням зображень екранів на прозорій чи підкладці проектуванням відображень екранів інтерактивного прототипу, виконуваного на портативному комп'ютері, набагато більш ефективно, чим вивчення екранів і аналіз їхньої послідовності на основі тільки друкованої копії. У будь-якому випадку користувачам варто надавати копії екранних відображень і сценарії.
Значення позиції бригади. Запам'ятаєте, що вашій справі буде супроводжувати успіх, коли представники користувачів з BUG-групи будуть дякувати вас за те, що їх вислухали. Позиція бригади має величезне значення для успішної взаємодії з користувачами; погане і зарозуміле відношення чи рано пізно проявиться.
Члени бригади повинні вміти слухати своїх користувачів і відгукуватися на їхні нестатки і зухвалі занепокоєння питання: у той же час користувачі повинні уміти вислухати проектну бригаду і вірно відреагувати на висунуті проектувальниками обмежуючі умови. Це сприяє досягненню істотних організаційних і технічних результатів.
Деякі, корисні правила
Будучи досить простим, метод залучення користувачів у проект через BUG-групу вимагає значних зусиль з боку орієнтованої на користувачів проектної бригади і користувачів. Щоб зберегти в користувачів бажання продовжувати спільну роботу в надії одержати віддачу, варто взяти до уваги безліч факторів.
Довіра, доброзичливе відношення, відповідальність і ефективність украй важливі для бригади в її прагненні домогтися зацікавленості від користувачів у ході засідань. Нижче приведені деякі ради, що стосуються способів роботи з користувачами під час спільних нарад.
" Не запитуйте в користувачів: "Що ви хочете?". Більшість користувачів можуть не знати, як відповісти на це питання, багато хто намагаються просто обробитися від відповіді. Замість дайте користувачам можливість виразити свої нестатки за допомогою таких питань: "Які задачі ви виконуєте найчастіше ?", "Які задачі найбільш важкі для вас?" і "Що, ваш^-по-вашому, варто було б поліпшити?".
Користувачі можуть не знати, як виразити свої побажання і нестатки у формі, зрозумілої проектувальникам і розроблювачам.
" Не можна недооцінювати участь користувачів у проекті. Варто визнати важливість вихідної інформації, наданої користувачами, і подякувати їх за витрачений час і зусилля. З користувачами варто зустрічатися регулярно (два^-один-два разу в тиждень; на нараду необхідно відводити до двох годин), а їхнє коло повинне залишатися стійким (ядро + інші).
" Не слід приходити на нараду з кінцевими користувачами непідготовленим. Будьте підготовленим і послідовної (порядок денний, тези, екрани, зображення на прозорій підкладці і т.д.), заохочуйте в користувачах цікавість, стежите ха ходом подій і тримаєте його під контролем.