项目和产品的区别

一：软件中的产品和项目有何区别

产品一定是一个或多个项目

但项目不一定会成为产品

产品是有商业目的及性质的项目

比如Mono做为一个开源项目，它并不具有盈利性所以不是产品

而DZ则具有盈利目的，所以是个产品

产品：1.可用，2.高效，3保证用户需求及后续服务

项目：没什么好说的，做的多么好或多么烂都算是项目

二：产品线与产品项目有什么区别？

产品线(Product Line) 是指一群相关的产品，这类产品可能功能相似，销售给同一顾客群，经过相同的销售途径，或者在同一价格范围内。 如果能够确定产品线的最佳长度，就能为企业带来最大的利润

产品项目，指某一品牌或产品大类内由尺码、价格、外观及其他属性来区别的具体产品。

产品项目

产品组合，就是指一个企业所经营的全部产品线的组合方式。在产品线中，每一个具体的产品品种称为产品项目。

三：研究项目与产品开发项目的主要区别是什么？

这类项目主要是进行技术或者产品方案的研究(也称预研类项目)，其特点是结果的不确定性，可能失败也可能成功，或者也可能出现不同的平台或者方案选择。

而产品开发项目的目的就比较明确的，就是把产品做出来。对于采用新的技术平台的产品开发来说，一般会先做个预研项目以确定新技术的可行性和经济性等。

不管是预研还是产品开发，对于项目管理方法论来说应该是一样的，侧重点不太一样。

四：做产品和做项目的区别，产品经理和项目经理什么概念？

产品经理为1个产品的整个生命周期负责。

项目经理为1个产品的需求-->开发的实现情况负责。

评判产品经理的好坏主要依据产品的对外结果（比如赚了多少钱，有多少人用）

评判项目经理的好坏主要依据产品的对内结果，比如需求实现是否符合预期，功能是否100%实现。

五：项目和业务的区别

项目经理负责项目的成功交付。项目常常是一次性奋斗目的，包括规模、期限、预算以及其他方面的制约因素。一个项目经理将会努力调配资源，把控管理问题和风险，需要集中所有必须的力量来完成该项项目。如果项目被看成是产品，项目则会被理解为开发一个产品，需要添加产品新功能，或者创造产品的新版本，或者产品新扩展。当一个项目完成时，项目经理将常会换一个新的项目，很有可能是一个新的与原来丝毫不相关的“产品”。

产品经理则不同，他们必须对产品全权负责以及对产品的整个进程负责。一旦项目被完全理解成产品来看待，项目经理则消失了，取而代之的是产品经理，产品经理将继续经营着产品的整个生命过程。项目一旦成为了产品，产品经理则贯穿于整个过程的始终，确定产品目标，引导团队完成制定的商业目标。

这两种角色面临的同一个挑战是，他们看起来可能是有分歧的对立方。产品可能需要不断地增加产品新功能来满足顾客的需求，而项目经理可能要求在最小的成本内，完成某个项目，以减少交付时间和预算。传统的定义（也包括上面的）常常错误地把项目经理看成一个简单的按时、按预算地完成项目的人，几乎从来不考虑是否满足市场或用户的需求。

六：公司软件开发时的平台,项目,产品有什么区别

软件开发平台：公司用的电脑、操作系统、开发工具等

项目：公司正在开发的软件

产品：公司已经开发完成并使用的软件

七：产品开发中的设计管理和项目管理的区别是什么

这个得看你怎么去定位。若是将某个产品的设计管理作为一个小型叮目进行管理的话，那么设计管理是目标，是项目范围，而项目管理则是方法、工具；反之，若你说的某产品的设计管理是作为某一个已立项目的其中一部分，那么，项目管理是整体，而设计管理是项目管理的局部，它是项目管理的某个阶段过程，因为要开发出一个产品，要经过策划、设计、开发、交付等流程。

此为2者的联系与区别。

八：产品经理跟项目经理的区别是什么？

具体地说：产品经理就是产品的总经理，和产品相关的所有的事情他都可以管。首先，首先产品经理是一个生意人，要对自身产品的持续发展能力、市场竞争能力、以及销售获利能力负责。其次，产品经理是要推动产品上市的整个过程，还要推动客户满意度提升的整个过程。再次，产品经理是横向协调而非垂直领导。需要协调从前端到后端的各种资源一致的协同工作，协调公司内各种资源产品销售服务，协调内部外部的各种资源为你的各种思想服务等等。

项目经理是指对某个项目及执行该项目的团队负有全面责任的管理者。 他的首要职责是在预算范围内按时优质地领导项目小组完成全部项目工作内容,并使客户满意。

精辟地讲：产品经理——靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润的。

项目经理——靠做。项目经理是把事情做正确，把事情作得完美，在时间，成本和资源约束的条件下完成目标。

九：浅析项目和产品有哪些区别

而项目则是在规定好的时间和任务前提下进行操作，达到规定的效果就算是做好了。 查看原帖>>

十：产品视图中的需求跟项目中的需求有何不同

1.概念

需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.

关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".

百事通

而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.

需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:

需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.

从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.

任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.

2.需求分析的任务

开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.

目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.

对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?

然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.

近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.

相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.

事实上,需求文档在开发过程中一直起指导作用.

3.需求分析过程

可把整个软件需求工程......余下全文>>