从事IT行业多年，一路从小杂兵成长为大团队Leader，对于研发整个体系比较清楚，其实大多人都经历过但是都忽略了的研发成本管控的一个关键的点就是研发过程中项目级和产品级的区别。
在IT行业飞速发展的今天，可以将IT公司分大体分为两类：
其实以上两者并不是一定区分那么明显，会根据市场发展需要进行转变，大部分公司的路线都是项目级养活公司，逐渐走向产品级，最终转为产品提供商并做一些产品相关的项目开发，如国内某GPU厂。
(PS：实际上稍微大一点的公司业务复杂程度，多样化程度不亚于过年回家应付七大姑八婆，此处只粗略加以区分）
做产品与做项目有哪些区别，大多数的人面对这个问题还是较为模糊的，甚至简单认为两者是没有区别的，均是程序开发而已。但事实并非如此，做产品与做项目两者之间既存在本质的区别。
做项目侧重于时间驱动，因为时间就是成本，要压缩成本就要压缩时间，在功能上力求操作敏捷、易用、友好，如果在项目时间紧迫的情况下，至少要能保证每个功能都基本能用、主流程不出现bug，若有功能性bug会进行修复。
做项目是以客户的需求为根本，按照客户的商定的需求进行定制开发，不明确的需求要第一时间与客户进行沟通，不在沟通内的将会存在后期扯皮现象。
做产品侧重于功能体验，做产品的时间相对来说比较充足，前期可采用带产品型思维的项目型管控方式，达到项目要求之后，进而不断迭代优化修复优化非功能性bug。（团队管理上，可称之为项目级Demo阶段，即第一阶段）
要开发出有竞争力、受广大客户欢迎的产品为原则，功能响应速度要相对体验好，操作要简便、界面要美观，是多方努力的结果，而且周期往往以半年开始计算。（团队管理上，可称之为产品级Demo阶段，即第二阶段，该阶段的周期为0.5~3倍时间于项目级Demo阶段）
做产品是为了满足某一应用市场而针对性进行一套装软件或一个产品的开发，对于产品的性能以及快速迭代扩展的要求更高，产品的需求也并不像软件项目一样完全明确，存在着后期根据需求、迭代升级的情况。（团队管理上，可称之为产品迭代升级阶段，即第三阶段）
做项目的第一准则是客户的需求，项目的开发人员需要依据客户的需求进行定制开发，并且项目需要保证功能适用于当前客户的使用习惯，性能稳定，主功能流程不存在功能性bug；
项目的质量更加侧重于某一客户的具体需求，保证交付的软件项目程序可运行、维护，实现基本功能即可。
简单来说，项目的代码怎么方便怎么来，一般不会考虑耦合度、代码规范问题，研发尽快完成对应的任务即可，当然技术好的就算是项目型也会有统一的代码规范和较低的耦合度。
产品的质量要求更加侧重于某一行业领域的应用场景，除主功能流程之外，对其他体验细节等进行优化，对代码进行优化，最开始时就会进行整体的一个基本构架，包括编码风格，模块划分等等，同时具备较好的可读性，可维护性和持续开发，使其所匹配的应用性更为广泛，并且对产品逻辑、代码可运维的要求更高。
做产品的性能必须持续优化，因为产品为提升竞争力就必须比同类产品更好用，更敏捷，而且产品是一个不断完善升级的过程，对代码的框架以及维护性都具有更高的要求。
简单来说，产品的代码兼具考虑后期拓展和整体构架，各开发者统一的代码规范，较好的可读性等等，代码也比较健壮，逻辑清楚。
做项目的时间投入一般是根据项目的需求，进行评估。通常是从项目启动、需求调研、功能设计、业务开发、测试运行、验收交付为一个周期。
项目有明确时间约束，什么时候开始，什么时候结束，每个节点都需要一目了然。通常以项目的验收单作为分项的里程碑及整体验收单作为项目的交付证明。
做产品的时间相对来说比较长，产品通常更加关注的是整个产品的规划、开发、推广、维护等。
产品时间一般来说可以明确开始时间却不能明确真正的结束时间，因为产品是一直在进行迭代完善的过程，通常会通过不同的产品版本来区分维护、优化、升级。可以划分为三阶段时间：
老板1（你的老板或者甲方客户）希望做一个即时通讯软件，能实现聊天功能，文件传输功能，能查看哪些人在线，能发表情等等，是否能做？多长周期？成本多少？
该问题需要进一步的沟通需求细节，实现通讯软件达到的具体功能点，以某种形式列出，并且列出类似的几款产品类似的功能，具体确认其功能需要达到哪种程度。才能进一步明确是否可行，周期，成本等，以下列出几种常见的情况：
-情况一：老板1要求的及时通讯是满足基本要求，为人相对好说话，公司内部使用，能基本聊天实现基本功能即可，完成验收。
-情况二：老板1要求的及时通讯是满足飞Q要求，实现基本要求，要达到200人同时在线群聊沟通等，还需要表情文字，gif，文件传输需要达到10MB/S，同时不影响聊天，基本很难验收。
-情况三：老板1使用后发现，QQ能做到多个群聊多人在线，你这个为什么不行，QQ可以同时做屏幕互动，语音这都是基本功能，之前说的基本功能就包括这些，根本无法验收。
-其他情况：只列举三种相对结果好、中、差的情况（往后的问题都是）。
以上第一种情况一般是合作愉快，二就比较棘手，三最后一般是不欢而散，一方吃亏或者可能在法院上见。
老板2想要做一个三维引擎开发，希望将给的图进行三维点云渲染，能将其给的demo点云进行展示和基本的三维场景功能，是否能做？多长周期？成本多少？
-情况一：老板2要求引擎后，能够将其给的点云打到展示的效果，评估时使用该点云评估，完成验收。
-情况二：老板2要求引擎后，能够将其给的点云打到展示的效果，进一步测试时，发现几千万的点云加载慢，上亿的点云面渲染卡顿，进一步探讨可行的解决方案，看情况是否验收。
-情况三：老板2要求引擎后，能够将其给的点云打到展示的效果，进一步测试时，发现几千万的点云加载慢，上亿的点云面渲染卡顿，当初要求就是点云渲染不卡顿，拿行业较好的软件对比，如用opengl只显示不卡，为什么用已有的开源引擎就卡，项目前的点云给的几千几万的点云，评估自然也不同，包括费用，此种情况根本无法验收。
老板3想要做一个白板软件，希望拥有某大厂的白板基本功能，是否能做？多长周期？成本多少？
-情况一：前期对标某大厂的白板，基本功能，按照项目评估费用周期，后期达到基本功能需求，完成验收。
-情况二：前期对标某大厂的白板，基本功能，按照项目评估费用周期，验收时，如某某白板书写的比较顺和自然，可以同时播放4个4K视频，可以各种绘制操作带各种资源，老板3还是懂，一切商讨，看情况是否验收。
-情况三：前期对标某大厂的白板，基本功能，按照项目评估费用周期，验收时，如某某白板书写的比较顺和自然，可以同时播放4个4K视频，可以各种绘制操作带各种资源，此种无法验收，谈的是项目，做的是产品，根本无法验收。
老板4想要做一个物联网服务器平台，实现mqtt通讯，从前端看即可，是否能做？多长周期？成本多少？
-情况一：前期以单个传感器谈，可以实现即可，mqtt自己可以撑几千个，达到基本功能，mqtt是否能撑住不在负责范围内，按照项目评估费用周期，完成验收。
-情况二：前期以单个传感器谈，可以实现即可，达到基本功能，按照项目评估费用周期，后续说mqtt可以承载几万，单实际无法承载，一口说就是之前谈的这个方案行得通，是你代码问题，不然这个方案行不通，项目无意义，不付款，此种狗血剧情，只收了基本功能的钱，还让承担服务器，基本无法验收”。
-情况三：前期以单个传感器谈，可以实现即可，达到基本功能，按照项目评估费用周期，后续说mqtt可以承载几万，单实际无法承载，一口说就是之前谈的这个方案行得通，是你代码问题，不然这个方案行不通，项目无意义，不付款，与此同时，提供其他方案，让乙方写一个可以支撑几万人同时在线的交互服务器，此种狗血剧情真实存在，只收了基本功能的钱（几千），还让承担几十万项目无法实现的后果（其方案本身存在问题，非不积极解决），还要告乙方，基本无法验收。
老板5想要做一个数据处理平台，实现给定的几百文件数据处理，达到功能，是否能做？多长周期？成本多少？
-情况一：前期以处理的数据作为理论依据，完成功能，基本满足即可，完成验收。
-情况二：前期以处理的数据作为理论依据，完成功能，回去测试以几万几十万的数据去测试，发现无法承载，双方沟通，本身做的是基础的钱，不可能对大数据专门做优化处理，看情况是否验收。
-情况三：前期以处理的数据作为理论依据，完成功能，回去测试以几万几十万的数据去测试，发现无法承载，遂说未达到要求，必须达到要求才能给验收，基本无法验收。
很多东西看起来简单，单功能较多，纯工作量都较长，导致原先简单的东西估算成本低于实际付出太多，导致亏本，企业亏本那怎么可能做好。
比如计算器，windows的计算器用起来还不简单吗，但请您认真查看他的功能，发现windows的计算器真不简单，完全复制一个没有十天半个月做不出，而且达到其优化程度，又要付出十天半个月，不信你就自己试试。
比如windows画图，windows的画图看似简单，但请您认真查看其填充的功能，填充功能是要基于算法去做的，而不是简单绘制一下。
所以功能要了解到具体的功能点，模糊的功能点跟甲方沟通好，可能存在的情况，双方达成一致，尽可能对双方有利，输和赢其实并不重要，重要的是你合适我也合适，生意才能长久。
很多东西看起来简单，如理论上mqtt可以承载几万，QChart可以承载几万点，nigix服务器可以承载几百人流媒体延迟500ms以内，这些都是理论上的，实际和理论多半都存在的差距都挺大的，也有确实是符合理论的情况。
比如nigix流媒体，在局域网可以达到500ms，但在多终端的时候，其延迟就会逐渐增大，比如放到公网上，其延迟远远大于3000ms，请不要怀疑，笔者深入研究过某为、某讯、某牛、某构、某家云、某度各家的流媒体服务器方案以及开源的方案，都做过具体的测试，结果其方案官方给出的是3-10s之间，实际根据网络状况有时候啥都没有，有时候5s左右，要500ms以内必须使用其rtc服务。而对应的延时优化，是需要大量的专业人士在服务器、编解码、播放器各端进行各种优化，甚至是私有协议，如某家云的就基于rtc自己二次三年优化升级的，其延时比大厂的还低。
比如一些局域网同传开发，软件号称局域网每秒几十MB，1对60同传，确实可以，忽略了网络条件，如无线情况下，P2P也好，传送120MB的文件同传，实际时间将近2小时，包括某大厂飞屏，过来测试1对多也是直接看不到影子，最后研发了rtp+fec+组播的方案，120MB同传文件可以达到2分钟传完即可。这也有个问题，几年后续因为外围测试环境被拆，更换新环境（干扰比较大），导致5分钟才能传完。
这篇文章想写很久了，以上的思考问题都是博主9年多以来亲身经历的，尤其最近五年对于项目、产品加上自身组建团队0到1的成功经验，一直想进行一定的归纳整理思考。
