软件产品定价/成本估算
我总是在估算成品软件（或编程工作）的成本/价格方面遇到困难，所以这里有两个关于它的问题。
问题 1：
你被要求写一段代码来换取现金（完成后该代码的所有权利都属于买家）。你知道大概需要多少小时（+-25%），以及大概的复杂性（即你是否可以在睡梦中写出来，或者一旦完成就会遭受严重的精神倦怠）。产品是用编译语言（C、C++ 等）编写的。
你（你会）如何选择这份工作的价格？
问题 2：
假设你花了几个月的时间写了一些东西，现在已经完成了，现在想（尝试）出售它。
产品将非常“利基”，并且不可能将其出售给大量人群（它是 SDK、游戏引擎、库或类似的东西，而不是文本编辑器 - 需要它的人数会很小）。 “开源”是不可能的。
您知道大约花费的小时数、文件的总大小、LoC，并且您拥有包含整个开发历史记录的存储库。
结果可以在有或没有源代码访问的情况下出售，用于商业或非商业用途，或者您可以（尝试）出售软件权利。
您如何确定以下各项的价格：
- 该软件的权利？
- 具有源代码访问权限的商业用途？
- 没有源代码访问权限的商业用途？
- 非商业用途？
I always had trouble with estimating cost/price of finished software (or programming work), so here are two questions about it.
question 1:
You're asked to write a piece of code for cash (all rights to the code belongs to buyer once you're done). You know approximate number of hours it will take (+-25%), and approximate complexity (i.e. whether you can write it in your sleep or will suffer severe mental burnout once you're done). Product is written in compiled language (C, C++, etc.).
How do you(would you) pick price for the job?
question 2:
Let's say you spend a few months writing something, this thing is now finished, and now want to (try to) sell it.
Product will be extremely "Niche", and it won't be possible to sell it for large numbers of people (it is SDK, game engine, library, or something like that, not a text editor - number of people that would want it will be small). "opensourcing" it is out of the question.
You know approximate number of hours you spent, total size of files, LoC, and you have a repository with entire development history.
The result can be sold with or without source code access, for commercial or non-commercial use, or you can (try to) sell software rights.
How do you determine price for:
- Rights for that piece of software?
- Commercial use with source code access?
- Commercial use without source code access?
- Non-commercial use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
产品定价与成本估算无关，只是价格通常应该高于成本。
定价更多地与：客户将为该软件支付多少钱？定价是一项很难正确掌握的技能 - 如果你说出价格而客户不眨眼，那么你的价格可能太低了......
因此，对于单一客户端（定制）软件的建议是将价格设置为你认为的最高价格。认为他们会付钱。如果编写软件的成本（以工时计算）高于他们支付的价格，则不要接受这份工作。
对于现成的软件来说，这同样棘手，因为您需要知道市场的规模。假设有 1000 个潜在客户，那么您需要知道有多少人会以特定价格购买您的产品。显然，随着价格上涨，买家会减少。同样，定价与构建软件的成本无关，而与人们愿意花多少钱有关。
因此，如果 500 人愿意以 20 美元的价格购买，但只有 200 人愿意以 30 美元的价格购买，那么如何定价就变得更加明显了(*)。找出这些数字的唯一绝对准确的方法是实际销售您的产品，但您可以进行市场调查（例如询问您的潜在客户）以了解他们愿意支付的费用。 （将此与单一客户项目进行对比，在单一客户项目中，您无法询问客户他们愿意支付多少钱...）
因此，一旦获得最佳价格，您就可以计算预期回报（预期销售数量乘以按价格）。如果这低于您的成本，请不要编写软件...
(*) 我应该说了解您的市场规模在这里非常重要。如果您向市场中的 20 个人询问是否愿意以 20 美元的价格购买，并且有 10 人回答“愿意”，那么您可以假设您的市场中有 50% 的人会以 20 美元的价格购买。通过了解您的市场大约有 1000 人，您可以将其乘以得知 500 人会以 20 美元购买。如果不知道你的市场规模，知道 50% 的人会以 20 美元购买它是无关紧要的。
Product pricing has nothing to do with cost estimation, except for the fact the price should generally be more than the cost.
Pricing is more to do with: how much will the client pay for this software? Pricing is a difficult skill to get right - if you say a price and the client doesn't blink you've probably gone too low...
So the advice for single client (bespoke) software is to set the price at the highest you think they'll pay. If the cost of writing the software (in terms of man hours) is higher than the price they'll pay, don't take the job.
For off-the-shelf software it's just as tricky, as you need to know the size of your market. Say there are 1000 potential customers, you then need to know how many people will buy your product at a particular price. Obviously, as the price goes up you'll get fewer buyers. Again, the pricing has nothing to do with how much the software will cost you to build, it's to do with how much people will be willing to spend on it.
So if 500 people will buy it at $20, but only 200 will buy it at $30, it becomes more obvious how to price it(*). The only absolutely accurate of finding out these figures is to actually sell your product, but you can do market research (eg. ask your potential customers) to find out what they'd be willing to pay. (Contrast this with single client projects where you can't ask your client how much they're willing to pay...)
So, once you've got your optimum price, you can calculate your expected return (expected number of sales multiplied by price). If this is lower than your cost, don't write the software...
(*) I should say how knowing the size of your market is important here. If you ask 20 people from your market about whether they'll buy it at $20, and 10 say yes, you can assume 50% of your market will buy it at $20. By knowing your market is about 1000 people, you can then multiply this up to know 500 people will buy it at $20. Without knowing the size of your market, knowing that 50% of people will buy it at $20 is irrelevant.
您可以在 Neil Davidson 的（免费）书中找到一些有趣的见解：http://www.neildavidson。 com/dontjustrollthedice.html
You can find some interesting insights gathered in a (free) book of Neil Davidson: http://www.neildavidson.com/dontjustrollthedice.html
您确实需要阅读 Joel 的 [/rant/humor/froth] 对此 http://www .joelonsoftware.com/articles/CamelsandRubberDuckies.html
You really do need to read Joel's [/rant/humor/froth] on this http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html
对于问题 1，找到您所在地区的常规小时费率并不难，只需记住添加您在项目上花费的所有时间，而不仅仅是编写代码的实际时间......还有，在估算如何实施一个软件项目需要多长时间，始终牢记霍夫施塔特定律;-)
“即使考虑到霍夫施塔特定律，它总是比您预期的时间更长。”
对于问题 2，尽管现在有点过时，但我仍然认为 Carl Shapiro 和 Hal R. Varian 的《信息规则》是有关该主题的最佳书籍。这个问题确实没有简单的答案，但是这本书将使您很好地了解定价时应考虑的因素。
Google 图书：信息规则
For question 1, it's not that hard to find the regular hourly rate in the area you are in, just remember to add all the hours you spend on the project, not just the actual hours spend writing code... also, when estimating how long it will take to implement a software project, always have Hofstadter's law in mind ;-)
"It always takes longer than you expect, even when you take into account Hofstadter's Law."
For question 2, even though it's a bit dated by now, I still find "Information Rules" by Carl Shapiro and Hal R. Varian to be the best book on the topic. There really is no easy answer for this question, but this book will give you a good understanding of the factors you should take into account when setting a price.
Google books: Information Rules