Оцінка вартості внесення змін до коду користувача

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

Клієнт просить мене надати оцінку вартості та часу для надання безлічі змін до іншого коду розробника для веб-сайту (php/mysql backend).

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

8

6 Відповіді

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

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

З мого досвіду роботи в якості фрілансеру, треба виконати три основні кроки:

  1. попросіть початкову оплату на 50%

  2. Попросіть остаточний платіж, перш ніж передавати файли

  3. попросіть кілька годин на поточну роботу або роботу, яка, ймовірно, з'явиться з часом

Щасти!

4
додано
запитайте 50% початкову оплату, щоб почати роботу ... hm, чи не так? Я б краще сказати 20%
додано Автор us2012, джерело
4. Прикріпіть до зброї, коли клієнт намагається відступити назад. 5. Будьте готові піти далі.
додано Автор tzerb, джерело
Я думаю, що 50% від остаточного платежу буде найкращим способом, щоб запитати клієнта. Таким чином, йому не сподобається попросити якийсь інший програміст виконувати свою роботу (половина грошей дуже багато, чи не так? Адже невеликий відсоток легше відмовитися), і він буде застряг з тобою до кінця.
додано Автор veganaiZe, джерело

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

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

По-друге, скласти 3 стовпці для оцінки - найкращий варіант (25% ймовірності), середній випадок (50%), найгірший випадок (75%). З двох причин, згаданих у першому абзаці, ви можете обрати найгіршу оцінку. Тоді ви можете додати ще 20% буферного часу. Наприклад, для конкретної вимоги, ваша найкраща оцінка випадку - 2 дні, середній випадок - 4 дні, а найгірший - 5 днів. Додаючи буферний період у 20%, оцінка становить 6 днів.

По-третє, не дайте фіксованої точки оцінювання, а діапазону. Для наведеного вище прикладу ви можете повідомити клієнту, що оцінка становить від 4 до 6 днів. Ваш клієнт може наполягати на оцінці всього списку змін. У такому випадку ви можете скласти мінімальні та максимальні діапазони для всіх вимог. Потім надайте остаточну оцінку в діапазоні, скажімо, від 5 до 6,5 місяців. Це має таку перевагу: ви можете перевищувати оцінку за однією вимогою, але це може закінчити іншу вимогу раніше. В цілому вони скасовують одне одного, і остаточна оцінка затримується.

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

Я дізнався про це в книзі Стіва Макконнелла з книги "Оцінка програмного забезпечення: Демистифікація чорного мистецтва". Я вдячний йому.

1
додано

Ідіть в порядок! Не оцінюйте цілу групу, особливо якщо у вас немає багато досвіду під поясом.

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

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

Ви повинні робити поступову доставку. Скажіть клієнту, щоб приділяти пріоритет користувачам історії та вибрати ті, які будуть доставлені під час першої ітерації. Кожна ітерація повинна тривати 2 тижні або менше, але не більше 3 тижнів! Коли ви закінчите історію користувача (всі його підзавдання закриті), повідомте клієнта та попросіть його підтвердити, коли ви працюєте над наступною історією користувача.

Вам не потрібно платити заздалегідь, це можна зробити після кожної ітерації.

Щасливе кодування!

1
додано

Попросіть погодинну ставку. Не давайте створити багато часу перед вами рахунок-фактуру.

1
додано
Так. "Не давайте створити багато годин ..."
додано Автор Dynamic, джерело

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

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

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

0
додано

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

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

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

0
додано
Ukrainian PHP comunity
Ukrainian PHP comunity
885 учасників

dev-ua/php