розум gap_ з питанням відстеження програмного забезпечення

Це кошмар віковий менеджера проекту; меткі специфікації і фіксованої ціни проекту. Чому не всі визнають, що люди будуть робити все можливе, і йти на гнучкість і реалізм час і матеріали (T & M)? У ці дні, здається, схиляється до сильної фіксації ціна проектів розробки програмного забезпечення, зрештою, фіксований бюджет таким чином, це не має сенсу, щоб не зафіксувати ціну, а також. Проблема в тому, як багато досвідчених прем’єрів знаєте, речі не все так просто.

Питання є одним з ризиків, а хто приймає його. З фіксованої вартості проекту ризик вважається постачальника, з T & M це клієнт, який бере на себе ризик. Це «ризику», як передбачається, Ризик перевитрати, іншими словами, якщо проект не буде завершений у строк вартість ресурсів для продовження роботи на ньому будуть нести одну сторону або іншу.

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

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

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

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

Ми називаємо це “Турбота Gap”, і ми навчилися робити це, тому що реальність у великих проектах в тому, що рідко буває тільки один пробіл. Необхідність “Управління Gap” так само велика, як повинні визнати це, в першу чергу. Навіть Agile / SCRUM проекти можуть зазнати невдачі, якщо ви не в змозі належним чином “Управління Gap”.

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