Що стосується розробки програмного забезпечення позаштатних програм, які штрафи повинні мати фірми, коли вони пропускають строки? [зачинено]


12

Я розмовляв із співавтором.

У нього є клієнт, який хотів переконатися, що він доставить вчасно. Клієнт хоче впливати на пропущені терміни.

Поки я не займаюся позаштатною роботою, я не зміг дати відповідь.

Отже, моє питання:

Які наслідки ви (фрілансери) погоджуєтесь зі своїм клієнтом, якщо ви пропустите терміни доставки товарів (окрім звільнення)?


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

4
Тож клієнт мав би фінансову зацікавленість у тому, щоб ви пропустили термін? Це не звучить як дійсно гарна ідея. Це матиме сенс лише в тому випадку, якщо клієнт також має серйозні фінансові втрати, коли ви спізнюєтеся (як у прикладі MainMa).
Док Браун

2
Це здається мені абсолютно прийнятним. Я досить здивований коментарями. Ви очікуєте, що люди заплатять за роботу, не маючи жодних строків і жодних стимулів до виконання цього терміну? "Оцінка задач - прикро неточна" - цього не повинно бути.
NimChimpsky

@DocBrown, імовірно, клієнт має набагато більший остаточний інтерес у дотриманні граничного терміну, отже, оплачуючи роботу із строком. Іноді мені здається, що програмісти не люблять строків та структури. Уявіть, що ви обладнаєте нову кухню, і магазин каже oooooo ні, ми не можемо сказати вам, коли вона буде закінчена, просто зарядить вас за годину. Я пробіг би милю від цього. Програмування якісно не відрізняється від будь-якого іншого проекту.
NimChimpsky

5
Якщо ви оснащуєте нову кухню, вам буде запропоновано збірку як специфікацію. Якщо ви почнете змінювати ріжучу поверхню, плитки, змішувачі та матеріали для раковини, вам за додаткову плату витрачаються як матеріали, так і витрачений час. Неважко зрозуміти, чому в цьому випадку стягується плата, є фізичні стосунки. Зміна вимог до програмного забезпечення часто не відповідає такому ж розумінню, і будь-який контракт, який вимагає, щоб ви доставили X за Y, коли X точно не прибитий, вимагає неприємностей. Все зміниться, невміння рахувати це нерозумно.
Метт Д

Відповіді:


25

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

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

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

Примітка для клієнта:

  1. Багато затримок винні самі клієнти. Причин може бути декілька:

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

    • Прийшов за два тижні до кінцевого терміну і сказав, що не має значення, що проект дотепер робився на Java і використовував Oracle: його обов'язково потрібно переписати на Python та використовувати MySQL, оскільки клієнт вчора прочитав журнал говорячи про те, що ці технології - це майбутнє.

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

  2. Для хорошого проекту важливе значення має хороша комунікація.

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

  3. Ви отримуєте те, за що платите.

    Існують конкретні процедури, які допомагають організувати проект, і фактично програмування повинно зайняти лише 10–15% часу для великих проектів і 15–20% часу для середніх проектів. Ці проекти також повинні робити люди, які знають, що роблять.

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

    Не скаржтеся, що проект - це катастрофа, коли ви готові платити лише за катастрофічні проекти.

  4. Не домовляйтеся про час, необхідний для виконання роботи.

    Я часто стикаюся з такими дискусіями:

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

    Час переговорів - це рецепт катастрофи.

  5. Знайте свої пріоритети.

    Враховуйте правило 90% -кон. Коли проект керується неправильно, незвично бачити розробників, які розповідають, що вони виконували 90% проекту через місяць після запуску проекту. Потім, через місяць, це ще 90%. І через місяць.

    Це може бути дві причини:

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

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

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


3
"Не скаржтеся, що проект - це катастрофа, коли ви готові платити лише за катастрофічні проекти". Чи можу я це використати? Це чудовий пост btw і добре підсумовує ризики з обох сторін.
Метт Д

+1 Дуже хороші бали. Також приємно читати :)
Radu Murzea

5
@MattD: відповіді на Stack Exchange ліцензуються за Creative Commons Attribution-ShareAlike 3.0 Unported, так що так, ви можете. Крім того, сміливо читайте пов’язану публікацію на моєму блозі: Кількісна оцінка часу та вартості: Чому ми завжди помиляємось? , а також відповіді на моє запитання тут: programmers.stackexchange.com/q/158640/6605
Arseni Mourzenko

Чому до цієї публікації в блозі немає частини 4, 5, 6 тощо?
Radu Murzea
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.