Як переконати клієнта, який не є технічним, у тому, що його специфікацію потрібно спростити?

Часто я стикаюся з ситуацією, коли до мене приходить новий клієнт із додатком, який має буквально 100-ти непотрібних функцій, і цілком зрозуміло, що потрібно різко спростити, щоб проект мав шанси на успіх. Як ви переконаєте клієнта скористатися підходом до мінімального життєздатного продукту та спростити його?

редагувати:

Тож поточна відповідь - забезпечити клієнту оцінку часу / витрат для величезної програми. Мені не надто подобається ця відповідь, оскільки вона не стосується реальної проблеми у цій ситуації. І це - це погана практика розраховувати масштабну програму, а потім спробувати створити її з початку роботи. Мені набагато комфортніше спочатку будувати невеликий, простий фундамент MVP. А потім додайте невеликі функції до цієї основи по черзі. Тож як я переконаю клієнта підійти до створення програмного забезпечення таким чином?

Оцінюючи, скільки грошей / часу буде коштувати, щоб зробити ці сотні функцій високою якістю. Дуже мало клієнтів покладуть гроші туди, де є рот.

Два слова: Історії користувачів.

Я дізнався, що найшвидший спосіб допомогти клієнтові отримати Clue® - це змусити їх розповідати мені історію користувача для кожної потрібної функції або сторінки. Трапляється кілька речей, серед яких:

1. Вони повинні подумати про те, що насправді повинна робити сторінка / функція.
2. Коли ви запитаєте детальніше та детальніше ("а потім? ... а потім? ..."), вони починають розуміти, що все це не виникне, коли магічні космічні мавпи ™ влітають і роблять це у вихідні дні.
3. Вони стають справжніми партнерами у процесі створення. Це означає, що вони зрозуміють, чому змінити свою думку про щось, що вже на 80% завершено, спричинить а) затримку графіку та б) збільшення витрат.

Серйозно. Історії користувачів від власників - один з найкращих інструментів, які я знаю, щоб принести хоч якусь розумність процесу.

Обговорюючи аспект вартості та часу виготовлення, попросіть оцінити вимоги ("повинен мати", "повинен мати" та "приємно мати"), щоб мінімальний життєздатний набір продуктів, необхідних для функцій, є "must have" у версії 1, а потім залиште решту вимог у набори відстаючих, які могли б бути виконані як спринти після першої версії. Сподіваємось, несуттєві «приємно мати» підуть на задню частину упаковки і до того моменту, коли ви дістанетесь до тих спринтів, нові, більш важливі (з фактичного досвіду роботи з продуктом), випливуть на вершину.

Клієнт повинен оцінити те, що ви розглядаєте вартість свого бізнесу та важливість швидкого отримання продукту, і ви не відмовляєтесь від їхнього "приємного", ставлячи їх у відставання.

Редагувати, щоб відповісти на редагування ОП: Щоб переконати клієнта, чому краще заздалегідь випустити мінімальний життєздатний продукт, поясніть, що поки продукт не буде використаний реальними користувачами, важко знати, чи буде він успішним (особливо з точки зору зручності використання). Якщо замовник вагається випустити ранній продукт на всю свою базу користувачів, рекомендуємо зробити «обмежену бета-версію», коли вона доступна лише цільовій підмножині своїх клієнтів. Скажіть, що зворотний бік такого підходу - це довгий і дорогий цикл розробки з пізнім визначенням того, що продукт є непридатним. 37 Signals дали кілька хороших посилань на це: отримання реальної роботи та переробка . Real Getting доступний в Інтернеті безкоштовно.

Основною причиною вашого розчарування ситуацією, ймовірно, є сприйняття та введення в оману / неправильні терміни, які використовує замовник. Замовник зазвичай не звертається до вас із переліком вимог , але список бажань щодо кожної речі, про яку він міркує, може бути їм корисним. Це не всі вимоги, оскільки замовник ще не витратив час, аби подумати, чи справді потрібна кожна функція .

Це не обов'язково завжди є проблемою

Якщо у вашого замовника є гроші на всі ці функції і він готовий розлучитися з ним, і вам не дуже важливо вирішувати реальні, реальні проблеми, які має клієнт, то це може бути дуже прибутковим проектом. Це трапляється дуже просто, дуже рідко, і для більшості розробників це вбивство душі, тому що ви можете заздалегідь відчути, що проект не буде успішним для замовника врешті-решт (навіть якщо він фінансово успішний для вас як розробника). Це також є високим рівнем ризику, оскільки ви, ймовірно, закінчите проект із фіксованою вартістю з великою невизначеністю, і це дійсно важливо неправильно оцінювати ризик для великих проектів.

Що робити, якщо це проблема?

Давайте припустимо, що ви не в такій рідкісній ситуації. У цьому випадку ви хочете вирішити два основних недоліки у списку побажань, як це наведено:

1. Навряд чи замовник має правильне уявлення про витрати на розробку такого великого переліку вимог, тому навряд чи ви отримаєте контракт на ту суму грошей, яка вам насправді потрібна для цього.
2. Навряд чи цей список побажань точно і коротко описує справжню проблему, яку має і хоче вирішити замовник.

На мій досвід, вам потрібно вирішити проблему 2, щоб виправити 1. Перехід до реальної проблеми означає, що ви, розробник, тепер маєте необхідний внесок для творчих стрибків у вирішенні проблеми способами, про які сам замовник ніколи не думав. Ці рішення, ймовірно, будуть значно дешевшими та швидшими, ніж реалізація повного списку бажань.

Як це виправити?
Як каже Меттью Флінн у своїй відповіді - почніть з того, щоб клієнт визначив пріоритет з вимогами. Це не завжди просто, але змушуйте їх це робити. За потреби скористайтеся фразою "Якби хтось тримав пістолет до голови, яку єдину вимогу ви б зберегли?". Під час цього процесу ви часто виявляєте, що клієнт насправді не має дуже чіткого уявлення про те, що означають індивідуальні вимоги. У такому випадку зробіть те, що пропонує Пітер Роуелл, і змусьте клієнта працювати над Історіями користувачів. Ви та замовник почнете розуміти проблему та вимоги набагато краще, і тоді ви можете повернутися до визначення пріоритетів. Повторіть ці дії так часто, як вам потрібно, поки ви не відчуєте себе комфортно, що знаєте достатньо, щоб вирішити проблему замовника .

Як це відповідає на питання розробки рішення? Після того, як у вас є пріоритетний перелік вимог, ви маєте ввести необхідний внесок, щоб запропонувати клієнту процес поступового розвитку. Не потрібно називати це Agile, але ви можете запропонувати розбити договір на менші шматки для кожної вимоги (або нероздільний набір вимог) та доставити їх по черзі з підтвердженням замовника. Або ви можете розібратися та скористатися багатьма ресурсами, доступними в Інтернеті та офлайн, щоб переконати замовника, що їм в інтересах співпрацювати в одному з стильних стилів розвитку. У будь-якому випадку ви можете надати свою контрактну / проектну пропозицію у формі, яка чітко пропонує ці складові вимоги у пріоритетному порядку, кожна зі своєю власною вартістю та висновком. Тримайте цю моркву перед замовником,

Я спершу спробую пояснити, що їх вимоги не є реалістичними, і подати їм набір зустрічних вимог. Поясніть, що це вирішить їх проблему простіше та швидше, тим самим з меншими витратами та ризиками. Не намагайтеся перетворити це на технічну дискусію, клієнт про це не переймається. Клієнт дбає про те, щоб вчасно отримати хороший продукт, вирішити свою ділову справу. Якщо клієнт не відступає, або приймайте договір і виконайте роботу, або відхиляйте та пояснюйте клієнту, чому ви не можете прийняти відповідність для проекту у цій формі.

Подібно до того, що запропонували інші люди, але дещо інше, я б припустив, що все, що може бути клієнтом, може бути дійсним, але вони повинні ПЕРЕВІРИТИ. Який предмет потрібно зробити спочатку. Який предмет потрібно зробити другим. Найголовніше, якщо у вас не вистачає часу, які предмети найменше зашкодять не мати. Розставте по черзі кожний елемент від 1 до 732 (або що завгодно) і заповніть їх у тому порядку.

Історичний приклад заявки, яка закінчилась за бюджетом та за графіком через надмірні вимоги, - це Віртуальний файл справи ФБР. Він мав на меті замінити кілька десятків існуючих додатків, і всі вони повинні були працювати повністю, одразу, при перемиканні. Проект був остаточно скасований. Що було б успішним, - це створити структуру та поступово замінити окремі програми в новій системі. Натомість політика та міжусобиці призводять до того, що кожен із зацікавлених сторін програми заявляє, що їхнє додаток було найважливішим, і кожен золото здобув свої характеристики "must haves" з усіх функцій, які вони хотіли, додавши до існуючої програми. Зрештою, обсяг запитів на зміну, що пишеться щодня, перевищував кількість дійсно написаних щодня.

Я бачив, як "я маю все це" працювати у 2 випадках. По-перше, великий фінансовий клієнт (використовуючи водоспад усіх речей) мав 40 різних систем (наша компанія зробила одну з 40), замінившись та оперувавши одним махом. Інтеграційне тестування та спілкування були величезними проблемами. Я вважаю, що в конференц-дзвінках вони спалили близько 100 тис. Доларів на день (коли ви рахуєте ставку оплати всіх за дзвінки). В обох випадках було потрібно сильних переговорників, щоб скласти список того, що потрібно буде доставити, а потім прибити всіх ніг до землі. Не було переміщення цілей, ані переговорів. Обидві роботи закінчилися вчасно та на спец. Один був набагато більший за бюджет, а інший - бюджетний. Для цього вам потрібні дуже хороші менеджери проектів, які знають, що може доставити їх команда (такий, хто може сказати, що функція Q займає 3.

Не маючи чудових прем'єр-міністрів, переговорів та показників, я б радив підштовхувати клієнта до поступових поставок. Якщо вони все-таки хочуть одразу всю золоту цеглу, їм, можливо, краще послужити, допомагаючи їм знайти якусь іншу консультацію. Іноді найкраща відповідь - "ми не можемо вам допомогти".

Коротка відповідь: Я б прислухався до свого замовника і знайшов із ними підхід середнього рівня.

Я б запропонував послухати замовника і, залежно від їх бюджету та термінів, розділити проект на фази (реліз, реліз2 тощо).

Тоді ви можете продовжити оцінку кожної фази результатів, бюджету та визначення пріоритетності необхідних функцій, які має надати програма.

Таким чином, визначення обсягу роботи та результатів - це шлях в майбутньому :)

Як зазначають інші відповіді, пріоритетність є дуже важливою. Зручний спосіб зробити це через метод MoSCoW . Але ви можете почати з поділу всього списку, інакше сам список функцій поставить перед вами (або вашим клієнтом) проблеми з розумінням :)

Поруч із цим у вас є проблема дивитися на проблему в цілому. Ви, ймовірно, можете вирішити це, сидячи зі своїм клієнтом і пройти наступні кроки:

• Пройдіть по всьому світу за допомогою функцій та вилучіть із них категорії
• Визначте пріоритети (використовуючи MoSCoW) категорій і, можливо, визначте ієрархію (одна основна категорія з типовими функціями, категорії для основних предметів, категорії для конкретних варіацій основних предметів). Це може змінити категорії, визначені на попередньому кроці (завдяки новій статистиці).
• Перегляньте кожну функцію по черзі та віднесіть їх до категорії
• Визначте пріоритети (використовуючи MoSCoW) елементи в топ-х категоріях.

Це дасть приємний та конденсований вигляд зверху вниз запитуваних функцій, а також ви зможете визначити різні ітерації, починаючи з основи та розширюючи її за допомогою інших функцій.