Як ви навчаєте своїх клієнтів?

Клієнти потребують певної освіти, тому що вони думають по-іншому. Клієнти думають:

• зміни не є проблемою в будь-який час проекту

• деталі не важливі (винятки ще менше)

• час не коштує грошей (у них узгоджена фіксована ціна)

• одне речення в специфікації можна подовжувати / читати вільно, щоб відповідати фактичним потребам - і це не впливає на договір. (тут ми часто бачимо обговорення "здорового глузду" - приклад: "Звичайно, нам потрібен екран управління рахунками-фактурами, коли ми говоримо про управління бухгалтерським обліком - це здоровий глузд!")

• список продовжується ...

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

Який ваш досвід, який найкращий підхід до навчання клієнтів?

Цього минулого літа я мав дуже схожу розмову з замовником.

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

Я запитав свого замовника, чи є у них пропозиції щодо того, як я можу коштувати за невідомі зміни в рамках цитати. Для мене було запропоновано рішення, включаючи деталізовану надбавку на випадок непередбачених ситуацій у розмірі 15%, яку ми потім працювали б із замовником, щоб визначити їх зміни, щоб використовувати цю надбавку. Зрештою, надзвичайний стан не був використаний повністю, я виставив рахунок лише за виконану роботу.

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

Я просто бажаю, щоб усі потенційні клієнти там були цією професійною і насправді ціною якісної роботи.

Навчіть замовника . Я б хотів, щоб я не був твоїм замовником;)

Серйозно, я розумію, що у вас проблеми, і ви вважаєте, що проблема полягає у замовника. Може, і є, але це не має значення. Змінити клієнтів дуже важко, а змінити спосіб роботи з ними набагато простіше.

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

Тільки одна дрібниця:

зміни не є проблемою в будь-який час проекту

"Незалежно від того, як далеко ви пішли неправильною дорогою, поверніть назад". Турецька приказка

Я люблю це прислів'я, тому коли я можу його використати, я щаслива. Дякую за можливість;)

Ось пара рішень:

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

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

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

Іншим підходом було б закінчити домовленість (менш марні та не розроблені вимоги) як версію 1, а також домовитись про версію 2 з її новими ідеями.

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

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

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

Якщо вам здається, що у вас є більша проблема, хоча у вас є сперечаються "здоровий глузд".

Мало як клієнт багато років тому, де я працював, який читав специфікацію і сказав такі речі, як "Є ВИМОГА ВИМОГА, яку ви робите в XXX"). На що відповідь була: Немає загальних вимог. Єдині вимоги - вимоги в письмовій специфікації. Якщо ви хочете додати або змінити вимоги, будь ласка, надішліть запит на зміну специфікації, і ми приведемо зміну обсягу.

Зрештою повідомлення отримало, але це зайняло тривалий час.

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

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

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