This is a topic that got me multiple headaches during "Project Management" class at college 👊🏻(as a sprinter type, I got angry at the idea of getting paid less for being fast 😑)
Right now I think that it depends on the task:
Getting paid per project seems okay as long as you (or your team) feel confident with the deadline, in this case efficiency is rewarded with time that can be used for other activities. 👨🏻💻
Getting paid per hour is useful when there isn't a clear goal and the client wants you to do a bunch of stuff that may be hard to estimate. 👨🏻💻
Maybe having a mixed model could work in a lot of cases: the client pays for a project that can be delivered in a certain amount of time, but anything outside the initial scope shall be payed per hour 🤷🏻♂️
Knowing that estimating how much time is needed is usually hard when the project involves unknown domains or heavily customized functionality, I think a great advice would be to avoid committing to any form of payment before having clear requirements (whenever possible at least) 🧐
Without clear requirements, it can be a business suicide to agree on a project price. I have seen it happening. Optimistic estimations first, and endless fixes and "small" feature additions.
Then the project goes over budget or over expected time. And everyone is frustrated.
On the other hand, if it is charged by hour, but the project still does not have clear requirements, the client can get frustrated because they had some expectations on how long it is going to take and how much money they are willing to spend.
In my opinion, a huge chunk of work should be on making specifications and writing down requirements. Maybe it should be charged separately as a whole. And maybe building a prototype, if necessary, can be another "product".
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a topic that got me multiple headaches during "Project Management" class at college 👊🏻(as a sprinter type, I got angry at the idea of getting paid less for being fast 😑)
Right now I think that it depends on the task:
Getting paid per project seems okay as long as you (or your team) feel confident with the deadline, in this case efficiency is rewarded with time that can be used for other activities. 👨🏻💻
Getting paid per hour is useful when there isn't a clear goal and the client wants you to do a bunch of stuff that may be hard to estimate. 👨🏻💻
Maybe having a mixed model could work in a lot of cases: the client pays for a project that can be delivered in a certain amount of time, but anything outside the initial scope shall be payed per hour 🤷🏻♂️
Knowing that estimating how much time is needed is usually hard when the project involves unknown domains or heavily customized functionality, I think a great advice would be to avoid committing to any form of payment before having clear requirements (whenever possible at least) 🧐
Without clear requirements, it can be a business suicide to agree on a project price. I have seen it happening. Optimistic estimations first, and endless fixes and "small" feature additions.
Then the project goes over budget or over expected time. And everyone is frustrated.
On the other hand, if it is charged by hour, but the project still does not have clear requirements, the client can get frustrated because they had some expectations on how long it is going to take and how much money they are willing to spend.
In my opinion, a huge chunk of work should be on making specifications and writing down requirements. Maybe it should be charged separately as a whole. And maybe building a prototype, if necessary, can be another "product".