Ніколи не можна дізнатися точну або майже точну ціну, оскільки це залежить від багатьох факторів. Приклад:
Вивчення проблеми
Ви отримали запит на невеликий веб-сайт на базі WordPress. Єдине, що вам потрібно зробити: попрацюйте зі своїм дизайнером, щоб створити привабливу графіку, потім створіть сам веб-сайт (нічого високо технічного, лише набір плагінів для додавання до WordPress), а потім розгорніть його. Робота справді проста, ви процитували це $ 600.
Ваш дизайнер створив перший проект. Замовник пояснив, що вважає це зовсім не привабливим. Те ж саме було і з другим, третім та четвертим проектом. Нарешті, після двох тижнів наполегливої роботи, дизайнер нарешті отримав проект, який був прийнятий замовником.
Але на жаль дизайнера вдарив автобус, і єдине, що у вас було, це JPEG, які він вам надіслав, але не оригінальні PSD, тому вам довелося почати з нового дизайнера. Нарешті, ви отримали графіку і почали свою роботу.
Сюрприз: ви виявили, що плагін A несумісний з плагіном B, що плагін C не працює, як очікувалося, і що плагін D не може бути встановлений на новітній версії WordPress, тоді як плагін A можна встановити лише на цій новітній версії. Тепер вам потрібно зробити багато кодування PHP вручну, і оскільки ви розробник Python і ніколи не писав жодного рядка коду в PHP, це не найпростіша задача.
Тим часом замовник починає надсилати вам страхітливі електронні листи, запитуючи, чому робота ще не зроблена, а термін був тиждень тому. Ви нарешті закінчите кодування PHP, і на вашій машині все працює чудово. Замовник задоволений.
Тоді ви починаєте розгортати веб-сайт на сервері хостингу, щоб виявити, що не тільки веб-сайт виходить з ладу з певною криптованою помилкою, але й хостинг-компанія не підтримує функцію PHP, яку ви багато використовували у своєму коді.
Нарешті, витративши більше 3000 доларів на цей проект, у вас є веб-сайт, який працює і працює. Замовник розлючений через терміни і тому, що "з вами нічого не працює, як очікувалося". Ви б просили 600 доларів? 3000 доларів?
Чому це відбувається?
Те, що я проілюстрував у цьому прикладі, трапляється набагато частіше, ніж ви можете повірити. Чому? Тому що є занадто багато змінних, які ви не можете передбачити і які підвищують ризик. Тут ризик був збільшений на:
- Незрозумілі технічні характеристики, пов'язані з візуальним дизайном,
- Смерть дизайнера,
- Несумісність вибраних плагінів,
- Погана підтримка вибраних плагінів,
- Те, що ви раніше не використовували PHP,
- Різниця між середовищем розробки та виробничим середовищем та відсутністю інсценізації.
Вирішити ці питання можна конкретними підходами:
- Чіткі та точні функціональні та нефункціональні вимоги,
- Управління сценаріями "на автобус" (тобто дизайнер повинен був поділитися з вами кожним документом, щоб він в будь-який момент міг бути мертвим без шкоди для проекту),
- Попередні знання інструментів та мов, якими ви повинні користуватися (що вимагає великої роботи),
- Постановка, інтенсивне тестування тощо.
Єдина проблема полягає в тому, що при такому підході ви повинні сказати своєму клієнту, що він заплатить в першу чергу не менше 5000 доларів, оскільки це фактично ціна вимог, специфікація, дизайн, тестування тощо. Шанси цього клієнта прийняти Ваша цитата надзвичайно низька.
Тож нічого робити?
Якщо ви не можете надати дуже точну ціну, ви все одно можете наблизити, що враховує кожну частину роботи, яку потрібно виконати окремо, при цьому індекс ризику впливає на кожну частину. Чим вище прогнозований ризик, тим вища ціна.
У вас є два способи зробити це:
1. Воєнний спосіб
Якщо ви працюєте над проектами, які відповідають Водоспаду / V-моделі, це може працювати:
Перерахуйте функціональні та нефункціональні вимоги проекту. Отримайте документ, підписаний замовником, так само, як він підписує договір.
Отримавши цей документ, у вас вже є:
Ціна, яку ви вже витратили, збираючи вимоги та створюючи цей документ. Це може представляти важливу суму грошей, оскільки ці документи можуть становити від двадцяти до ста сторінок для звичайного проекту та становити сотні чи тисячі сторінок для великих проектів.
Чітке, точне та повне розуміння продукту, про який ви вимагаєте зробити.
Покрокуйте свою команду поетапно, аналізуючи кожну вимогу та оцінюючи:
Середня ціна цієї частини проекту,
Максимальна ціна без урахування ризику,
Індекс ризику.
Усі три будуть враховані для визначення ціни, яку ви дасте замовнику.
Визначте ризик, який не залежить від конкретної вимоги, а швидше від сумісності між вимогами або системою загалом.
Плюси підходу до води: замовник отримує досить точну ціну, враховуючи, що у вас є чітке бачення роботи та ризики, які можуть виникнути.
Мінуси водного підходу: перед тим, як дати ціну, потрібно написати документ на 200 сторінок. Що робити, якщо замовник тим часом скасовує проект або переходить до вашого одночасно? Весь процес також надзвичайно важкий, і вимоги не можуть змінитися пізніше.
2. Спритний шлях
Якщо ви працюєте над проектами, які підходять для Scrum або інших спритних моделей:
- або не дають загальну ціну проекту, а швидше ціни кожного компонента,
- або ви можете вказати дуже приблизну загальну ціну на початку, а потім дати більш точну та більш точну.
В обох випадках ви повинні мати сильну довіру між вами та замовником, або мати відмінних людей у відділі продажу. Інакше
у першому випадку людина вірить, що ви просто крадете її гроші, просячи невеликі суми знову і знову, і це ніколи не закінчиться,
у другому випадку людина не зрозуміє, чому ти постійно змінюєш ціну, особливо якщо ціна зростає більшу частину часу.
Плюси Agile підходу: замовник може скасувати будь-який момент. Крім того, якщо вона скасовує на ранніх стадіях, у неї все ще є якийсь вихідний код, який працює.
Мінуси Agile підходу: ціна занадто неточна або навіть не дана. Більшість клієнтів не бажають вести бізнес з вами, якщо ви не скажете їм, скільки їм доведеться платити.