Один з найефективніших: штраф за день затримки. Це також робиться для великих проектів, розмір штрафу - це тисячі доларів на день.
Якщо точний термін має значення (наприклад, якщо для Олімпійських ігор розробляється веб-додаток, який здійснюватиме трансляцію події в 2014 році, терміном буде початок Олімпійських ігор у 2014 році), то ефективним заходом може бути те, що в випадок, коли проект запізнюється, компанія взагалі не платить, а також повинна сплатити пеню.
Якщо такі різкі заходи не підходять, то єдиний факт, що добре оплачуваний клієнт піде, якщо проект запізнюється, може зробити свою справу.
Примітка для клієнта:
Багато затримок винні самі клієнти. Причин може бути декілька:
Ніякого SRS, але замість цього два абзаци, що описують згубно те, що клієнт вважає його потребами (і, звичайно, клієнт не хоче платити за збір вимог, вважаючи цей крок втратою часу).
Прийшов за два тижні до кінцевого терміну і сказав, що не має значення, що проект дотепер робився на Java і використовував Oracle: його обов'язково потрібно переписати на Python та використовувати MySQL, оскільки клієнт вчора прочитав журнал говорячи про те, що ці технології - це майбутнє.
Виконуючи свіжий набір вимог на кожній зустрічі. Бонусні бали, коли ці вимоги суперечать майже всім вимогам, що викладені дотепер.
Для хорошого проекту важливе значення має хороша комунікація.
Багато інших затримок пов'язані з відсутністю зв'язку. Практики, в яких замовник протягом місяця не спілкується з компанією і розраховує, що з ним можна буде зв'язатись лише після закінчення продукту та відшліфованого продукту.
Ви отримуєте те, за що платите.
Існують конкретні процедури, які допомагають організувати проект, і фактично програмування повинно зайняти лише 10–15% часу для великих проектів і 15–20% часу для середніх проектів. Ці проекти також повинні робити люди, які знають, що роблять.
На практиці клієнти не готові платити 800 доларів на день аналітику, який створить архітектуру та дизайн програмного забезпечення, і вони не хочуть платити ні за інші кроки, ні. Новачок-албанський програміст, який із задоволенням працює за 50 доларів на день, здається набагато вигіднішим.
Не скаржтеся, що проект - це катастрофа, коли ви готові платити лише за катастрофічні проекти.
Не домовляйтеся про час, необхідний для виконання роботи.
Я часто стикаюся з такими дискусіями:
Розробник: Враховуючи вимоги, я можу це доставити за чотири місяці.
Замовник: неможливо. Проект має бути виконаний за два місяці.
Розробник: ну, якщо ви не вирізаєте деякі функції ...
Клієнт: Я не можу! Усі функції потрібні. Чому ти не можеш виконати роботу за два місяці? Я зв’язався з індійським програмістом, моїм другом, він може доставити це за місяць-півтора, і просить лише половину ціни!
Час переговорів - це рецепт катастрофи.
Знайте свої пріоритети.
Враховуйте правило 90% -кон. Коли проект керується неправильно, незвично бачити розробників, які розповідають, що вони виконували 90% проекту через місяць після запуску проекту. Потім, через місяць, це ще 90%. І через місяць.
Це може бути дві причини:
Коли проект зроблено неправильно, тобто 100% часу присвячено програмуванню, що залишає 0% для збору вимог, архітектури, дизайну та тестування, що трапляється, що програмісти не мають уявлення про роботу, і вони виявляють нові завдання протягом усього життя проекту. Підготовка проекту допомогла б краще зрозуміти всі завдання, які слід виконати.
Коли замовник поспішає, незвично, що деякі компанії швидко доставляють лайно, а потім витрачають величезну кількість часу на вирішення помилок. Деякі компанії працюють лише так, що допомагає їм залишатися конкурентоспроможними і кажуть, що вони виконали даний проект за три тижні, навіть якщо пізніше вони витратили три роки на розв’язання безладу.
Поставлення чітких пріоритетів і вимагаючи правильного виконання проекту допомагає виключити ці компанії зі списку кандидатів.