软件项目需求分析怎么做？管理职责和流程怎么确定

(一)软件项目中，需求究竟该怎么分析？

对于软件开发团队而言，软件开发的全过程是：做什么 -> 怎么做 -> 做 -> 成果检验 -> 交付部署；其中，“做什么”对应的是需求分析过程，“怎么做”对应于软件架构设计过程，“做”对应于开发过程，“成果检验”对应于测试，部署由运维团队执行后，如果达到用户的要求，则软件上线后进入软件的运行生命周期。
而在实际的软件项目开发中，“做什么”，“怎么做”和“做”是紧密结合在一起的，“做”，“成果检验”和“交付部署”通常也会是一个持续交付过程，“成果检验”的内容会受到“做什么”的影响，开展“做什么”阶段的时候，也要考虑到如何部署和交付。所以软件开发的全过程，都是紧密结合在一起的，如果刻意划分为独立的几个阶段，忽视其作为一个整理的综合影响，每个环节的实施过程必然会遇到因上一阶段考虑不周全带来的问题，从而影响整体开发效率。
今天，我们首先来谈一下软件项目中，需求究竟该怎么分析？

正确的需求分析决定了我们产品的方向，需求分析搞错了，做再多都是浪费。只有方向对了你才能走出迷途，方向错了，你只能迷失！基于此，我们的需求分析可分为两个阶段，第一个阶段是收集需求，第二个阶段是处理需求。 

收集需求
需求的来源有很多，需求的处理方式也不尽相同。有效的收集需求，将收集到的需求去伪存真，是产品设计环节中最重要的一环，如同大厦的地基，地基不坚实，大楼是盖不起来的。而且我们在收集到需求时，要第一时间与用户交流沟通，尽量走到用户中去了解他们的想法，深入了解目标用户在真实环境下的感受，尽可能地挖掘用户的原始需求，充分了解用户真实场景，才能真正更好地服务用户，打造出他所想要的产品。
1、还原场景
如果只是单独看用户提出的需求，你很难分析到用户的真实需求，就像有些英语单词一样，你必须放到那个语境下面去了解，才能找到用户背后真实目的。
我们可以从以下场景进行分析：
基于什么环境：地铁/办公室/室内/公共场合/走路/夜晚/户外......深入情景周围的细节中去。
基于什么用户：具备什么特征，比如身份、收入、区域.....
基于什么行为：行为或操作流程，比如购物流程、操作习惯、行为认知.......
场景分析也就是需要考虑具体什么环境（时间、地点、情境）什么类型用户的什么动机，想达到什么目标，以及人与人的关系。如实地分析记录下来，如果偏差或缺乏信息，之后的分析就会有所偏差。
2、多问几个为什么
用户需求的传递过程中总是存在着无法完全理解吸收的问题，导致所收集的需求不一定就是用户的真实需求，这时你需要做的是找到需求的提出人，多问几个为什么。这个需求提出人可能是用户，也可能是运营，也可能是技术，你多问几个为什么的时候，也就能发觉用户背后的需求。
3、数据分析
数据是客观反映产品的重要指数，也是收集需求的重要来源，前期收集的数据需要是可靠、客观的，而且数据是零散的，在进行数据分析前一定要有明确的中心，划定一个界限，收集同一个框架内的数，同时单独的数据是死的，有对比的数据才有意义。为了避免主观意识的影响，同一份数据可参考其他人员的分析结果。
4、多和别人沟通/头脑风暴
一个人的力量是有限的，当我们吃不准的这个用户需求的时候，可以把这个需求拿出来和用户讨论一下，进行头脑风暴一下，人多力量大么，当我们吃不准一个需求的时候，大家都认为的那个结果就是需求分析的结果。

处理需求
处理需求的阶段，也是产品经理将需求进行筛选，梳理业务流程，设计产品架构的阶段。
1.需求筛选、分类
尽管我们保持严谨的态度收集大量的需求，其中还是有很多需求是“伪需求”，甚至是不合理的，我们第一步就需要将这些需求进行“清洗”，择优去重、去伪存真。
2.设置优先级
一般来说，从需求类型来看，基本型需求>期望型需求>兴奋型需求；
从需求来源来看，战略性需求（用户提出）>功能性需求（核心功能）>业务性需求（拉活、存留）>体验性需求（提升用户体验）。需求优先级判断最常用的是用四象限法则去评定优先级，另外可以使用RICE评定方法，KANO模型等。
3.竞品分析
由于在这个阶段，产品经理不仅要定义目标用户、产品使用场景，还要确定核心功能，产品流程等等，因此通过竞品（如果有）来辅助处理需求是一种很有效的方法。
通过相似竞品的用户定位、功能反推竞品的需求，与自己的需求进行对比；将自己的需求代入竞品中，看流程是否符合逻辑；与竞品进行对比，分析需求的异同。
4.需求评审
在这个阶段之前，作为产品经理对于产品应该有了一个完整的模型，但仅仅是理论上的模型，确保UI、UE、前端开发、后台开发、测试参与，从产品开发流程的各个角度对需求进行拆解、分析。需求评审可以看作是产品开发的初始化或者预开发。
需求分析是基于用户沟通、背景认知、人性理解，层层还原一个需求本源的过程。我们对一个需求的还原程度越高越准，越有机会在后续产品设计给出合理的方案。

（二）一个软件项目中需求管理与职责和流程问题

【案例正文】
我所在的公司是个50几人的小公司。现在我分到一个五人的项目开发组，可事实上，这个项目的开始都已经两个月了，还只有两人在写文档，其它人都有事在忙其它的了，项目由暂由公司的上一层领导。两人中，其中就有我也负责写需求文档，事实上我刚毕业，专业和软件没一点关系，但没办法，没其它人了，我只得也上了。我没学过软件工程，不知道一个项目下来应该具体怎么操作。但我觉得我现在这样，就很有问题。

首先，功能性需求都确定不下来，我想我以我为主先把自己的想法写下来，然后项目组成员一起讨论确定下来，但是这个讨论因为没时间，事实上其它成员也没关注这项目，就一直没有进行。我不能只等着，于是就往下写，然后是写用例，再写活动图了。

可现在麻烦的事，那个间接领导有时间时，会检查一下我的文档，然后他突然有了个想法，要加上什么什么功能，又要去掉什么什么功能，然后我又按他要求修改；下次他检查时，结果又是这样，搞得面目全非，我也形成不了自己的思想体系，只有揣摩他的意思。两月下来了，觉得还在考虑功能部分，真是失败啊。难道这就是RUP 开发的迭代过程。还是我们管理有问题，我的想法有问题，大家指教。

我觉得应该定下功能性需求，然后再根据功能写用例，再从开发角度上细化用例，根据用例写时序图，根据时序图确实类，再画图，组件图什么的。大家觉得应该这个过程是什么样的，是不是我有问题了？

分析：我正在执行的项目中担任施工经理，其它关键岗位的人员情况：
1、项目经理：没有做过EPC的项目，但是善于搞好各方面关系，善于听取一些意见，喜欢所有的事情他来做主，喜欢所有的部门经理均给他汇报。
2、质量经理：一个外聘的很负责任的老同志，但是做事情比较粗糙，不会使用计算机。脾气比较急躁，不允许任何人插手他的事情，否则就发脾气或不管这件事情。在现场处理事情带有一定的倾向性。
3、安全经理：一个是非婆。自学通过了安全注册工程师考试，仅做过一个项目……

分析：首先，感觉你这个项目组好像是在做一项预研的工作。而且公司对整个项目的重视程度可能还不够。
其次，可能是由于商务上的一些问题造成项目迟迟没有正常开展，虽然现在都是再写文档，很有可能项目一启动，文档就不会太大的改动了，很有可能会很忙。
再次，工作中没有一件事情是没有用的，刚毕业，可以利用这个时间好好弥补一下以后工作中需要的知识，充分理解一下公司的运作方式和项目相关的资料，流程等等。结识同事，建立关系。文档的编辑，可以更好的帮助你在下来的工作中清楚需要做什么？做到什么样？
最后，鼓励你坚持下来，实际的工作和在学校中的想象是不一样的。祝你工作顺利！

分析：作为你来说，首先你如果想学好应该好学一点，我认为总能找到一个老师。然后，认真地讨论应该干什么应该怎么干。你先问清上层领导的意见，确定准了以后再实施。有的时候领导们确实又临时改变意见的时候，这时候没办法作为年轻的你就多工作一下，也当时化悲痛为力量。加油！你会成功的！

分析：我觉得重要问题有两点：
1.项目小组职责不明确，缺乏明确的项目经理；
2.项目范围没有确定，这是软件项目最忌讳的；
你现在还处在需求分析阶段，就是要把项目的
各种需求确定下来，把项目的范围确定下来，为后续的工作做好铺垫.

分析：对于需求确定来说本来就是一件很难的事情。特别是工程性项目。看了全文个人认为应该属于研发性的项目，而研发性的项目需求前期确定一开始就需要有一个需求调研和立项的过程。你们的公司对这个项目不是很重视，或者人力资源不是很充足，或者还没有下定决心来投入如果说你的公司连需求都没有调研过，没有立项过，那这个项目到底要做什么就没有人知道了。对于写需求文档那都是在调研以及立项文档中都已经确定了的。你要写的是详细的需求规格说明书，并不是你自己凭空可以想出来的。

分析：我不是简单的把问题归到公司就行了。有些流程和制度，公司必须重视和制定，才能使的工作有章法可依。这才是关键。案例中的主人公，目前只能提建议，至于效果如何要看公司如何做。如果你有信心，把这个事情做好了，你就是no1。

分析：
1、项目不大，时间上没有过多限制。不知道是公司对项目不重视还是考验楼主；
2、（不知道是订制项目还是公司内部项目，如果订制的话，去客户那调研是必需的）对需求最了解的好像是那个领导，因此应该跟领导多沟通，确保自己真正了解需求，之后再做文档 

分析：

1：您现在所做的工作，仅是以后工作的铺垫
2：也许您的工作经验还不足，领导先安排您熟悉以下公司的情况，顺便要你帮着打打杂
3：当您的公司派其他专业人员参与进来后，您的项目算正式启动了
4：您千万别因当前的工作有所情绪

分析：对于需求确定来说本来就是一件很难的事情。特别是工程性项目。不知道楼主所说的项目是属于哪种，看了全文个人认为应该属于研发性的项目，而研发性的项目需求前期确定一开始就需要有一个需求调研和立项的过程。如果说你的公司连需求都没有调研过，没有立项过，那这个项目到底要做什么就没有人知道了。对于写需求文档那都是在调研以及立项文档中都已经确定了的。你要写的是详细的需求规格说明书，并不是你自己凭空可以想出来的。
你应该做好与领导的沟通，详细的确定需求再写说明书。这样就不会出现不知道写什么好了。
就你的描述，这个项目的团队也还没有形成。根本称不上是项目组。
楼主可以借这个项目提高自己这方面的能力，个人认为对你并没有什么坏处。但需要注意的是不要一味的抱怨，应该好好思考一下你该怎么做。

分析：从LZ透漏的信息的来看，这个项目合同额肯定不高，就说项目不大，你的疑惑大概很多人都碰到过，一般小公司小项目大致是这么做的。
你所说的间接领导，他可能就是对这个项目的需求最清楚的一个，不直到让你开工之前给你讲过一些相关的需求和行业知识没有，这样的项目这样的做法，经验就显得很重要，如果是我，我不会安排刚毕业的来做需求文档。
所以阿，多和你说的间接领导沟通，争取他对你的理解的斧正，抱怨是没有用的，不要完全按照书上的东西办事，事实证明这样的做法也是可以成功的。

分析：说句直来直去的话，这个问题根本不是什么奇怪的问题，在中国目前小软件企业中，这种问题太常见了。
这就是典型的“不规范的公司＋无经验的员工”所产生出来的现象！
据楼主说，这是一个5人的开发组，那么这么小的一个团队，如果一定认为是管理问题，我觉得有点上升得太高了。这么少的几个人，如果在工作方式和沟通上都出现了问题，我觉得主要还要归咎于项目组每个人的工作经验和工作态度，包括你们的那个间接领导。
当然，具体的情况我不清楚，不能在这里给出什么具体的建议，但是作为项目的管理者——那个间接领导——至少要先在项目组内部统一对项目的认识、项目的迫切程度、项目的时间要求、项目的重要性等基本信息，否则从何谈起说大家在做一个项目呢？
作为项目的成员之一——楼主——至少要主动和领导以及项目成员沟通，对自己手头的工作有一个基本的认识，在这个基础至少再提出自己的合理化建议，并说服领导或者征得领导的同意然后再开展工作。
我觉得目前的问题根本不是什么项目管理问题，也不是什么RUP过程的问题，这些还都谈不到呢，根本的问题是你们还没有形成一个项目团队，没有形成一个项目内部管理体系（哪怕是很简单的，比如项目例会、项目日报、项目过程管理等）。
这就是一个小公司，自身不具备成型的OSSP，人员经验又不足，也不具备基本的PDSP，自然就会发生这种现象。
还是先从提高楼主自身的工作经验来出发吧，别考虑太多了。

分析：
1、客户是谁？用户是谁？先将这两个问题解决了，找到关键干系人，就知道跟谁沟通，向谁汇报，对谁负责。
2、关注WBS，解决的问题可以先粗后细，先开始做WBS,在需求上面在细化下去(大目标先定)，先将工作包做清楚了在开始写你要写的东西。
3、将计划与执行进行跟踪，将所有的人工作纳入计划中来，变无序为有序。

分析：我不太懂软件研发的项目经理，但是，可以明确的是：
你们的公司对这个项目不是很重视，或者人力资源不是很充足，或者还没有下定决心来投入。
但是，这对你并不是坏处，这对你应该来说是机会：
1。如果这时个重点项目，或者人力充足的话，不会你刚刚参加工作就能从事这样的岗位。
2。在这种情况，领导对项目目前的进展不抱太大的期待（请原谅我直言）。所以，即使项目出现问题，你也会得到谅解的，除非有人想整你，但是你刚到公司这基本上不可能。
3。这可能是你来公司后不可多得的机会去施展你的才能，让公司认识你的潜力和价值。也是你获得实践经验的大好时机。其实，公司是怎么认识你的，不就是看你做的每一件事情吗？不就是看你的做事态度吗？
4。不要对领导的意见抱有抵触的情绪，你所了解的东西，和你的视角相对会有很多的局限，你的领导往往会有更多要关注的东西，他也不一定会有时间给你讲清楚。你要学会站在他的位置思考，多请示，汇报，多思考。
剩下的事情，我认为相对就要简单的多，就是两个“谦虚谨慎”和“不耻下问”。

分析：如果有必要,你可以把需求当作一个项目在做,只不过它与另一项目交织在一起而已.没有人一开始就完全将需求弄得清楚,否则项目管理也没有意味了!
重要的是,你需要将需求中的关键点找出来,这样你不会在做到最后才发现,原来......后悔已经来不及了!!!
就这个案例本身不是一个简单的需求问题,是个管理问题,尽管大家在此讨论时不会给出一个一定有效的方子,但是至少可以理一下思路,明确可能存在问题的地方,然后再对症下药!
各位提到的需求明确或管理需求,追根究底,还在于管理流程要理顺!那个间接领导时不时要"灵感"突发,你有什么办法控制?

分析：我基本上同意楼上各位的分析，管理需求。我提出一个问题：如果客户是老板，需求能清晰能管理能明确能量化吗？如果客户是我们自己呢？我想也未必能达到软件开发或项目管理中的需求能清晰能管理能明确能量化，这只是一种理论的状态而已。
用专业的人来做专业的事。

分析：作需求的时候就是这样的，很多的想法一时间不能描述清楚，慢慢的时间过去了，反而清晰起来，不断地往上面添加，但是这里有一个风险，就是思路不清。最后功能全部写出来了，逻辑上却变得格外的复杂，或不可实现。
建议你用MindManager来梳理一下功能流，看看他的走向是怎么样的。我不知道你们的文档的要求是怎么样的，但是MindManager确实能够帮助你的领导看清楚他有时间就过来改动的功能们到底是怎样关联在一起的。有了这样的图，也许你也能够理解他的目标，你的领导也能够理清思绪。

分析：在这个项目里，老板实际上变成了客户（我怀疑最终满足了这个客户，项目的结果可能就是玩完了），要做好这个客户的管理；
另外项目的目标是什么？看起来，好象没有谁对这个项目负责，你只是个做文档的，有一点需要提醒的是：你需要明白老板认为你是谁，如果老板默认你为项目经理，那你目前状况和以后的情况都是比较糟糕的！如果没有，你只有建议权，那就当是一个学习的机会吧！

分析：根据你说的情况，这只能叫做几个相关不相关的人以一种不好的方式在做一件事，而不是项目组在做项目。这不是RUP 开发的迭代过程，管理问题更多些。
需求为什么由间接领导来定呢，是否其他项目的需求也是由领导来定的。如果是，则你们公司一定有办法把自己的需求推销给客户，那么你可以把领导的需求当作客户的需求。但是沟通要更加充分一些，不要今天一句、明天一点，那样永不成型。
另外两个人在写什么文档呢，是需求、还是可行性分析、还是规划、还是设计呢。
还有，开发的过程中需要的步骤和图要根据实际需要来定，不要根据书本来定。

分析：感觉你的项目还没有开始完全进入项目的状态。
文中所说的很多问题都是需求分析的问题，很多你的工作现在明显都在需求分析的过程，还没有清楚的知道客户的真正需求，这不是RUP的问题，而是RUP要求首先实现的客户基本需求，再此基础上迭代实现的增加需求。
第一，还是因该彻底的分析你的客户需要的是什么功能。
很多时候客户不断的变化，是正常的，首先你要去发掘客户的真实需求是什么，一般来说可以通过快速原型和客户不断沟通来做到的。
我觉得如果对于你来说没有时间作原型，就尽量确定最基础的需求是那些。而且必须得到客户的确认。然后你再开始作用例设计-〉类设计。
第二，管理顾客的需求
客户的需求不断变化，但是不是每次客户的需求都要立刻对应的，RUP的好处就在于你往往可以把那些变化的需求放到下一个迭达中去。这样不会影响你这回迭代的开发。

（三）软件项目开发流程以及人员职责确定

实行软件工程项目管理：
项目经理（负责人）：项目经理（负责人）对整个项目负完全责任，是指导、控制、管理和规范某个软件和软/硬件系统建设的人，项目经理（负责人）是最终对客户负责的人。
软件项目经理（负责人）：软件项目经理（负责人）对一个项目的所有软件活动负完全责任，控制一个项目的所有软件资源，按照软件约定与项目经理（负责人）打交道。
软件工程组： 软件工程组是负责一个项目的软件开发和维护活动（例如：需求分析、设计、编程和测试）的人员（包括管理人员和技术人员）。
系统工程组： 系统工程组是负责下列工作的人（既有经理也有技术人员）的集团：规定系统需求；将系统需求分配给硬件、软件和其它成分；规定硬件、软件和其它成分之间的界面；以及监控这些成分的设计和开发以保证它们符合其规格说明。
系统测试组：系统测试组是一些负责策划和完成独立的软件系统测试的个人（既有经理又有技术人员）的集团，测试的目的是为了确定软件产品是否满足对它的要求。
软件质量保证组： 软件质量保证组是一些计划和实施项目的质量保证活动的个人（既有经理又有技术人员）的集团，其工作的目的是保证软件过程的步骤和标准得到遵守。
软件配置管理组： 软件配置管理组是一些负责策划、协调和实施软件项目的正式配置管理活动的个人（既有经理又有技术人员）的集团

总体流程如下：
计划阶段－》需求分析阶段－》软件开发阶段－》测试阶段－》完成
一、项目计划阶段
项目计划草案和风险管理计划作为第一步，当有一个商业机会后，根据公司高层负责制定的初步商业计划书来完成项目的计划草案，确定、分析项目风险并确定其优先级，还要制定风险解决方案。本阶段的目的是确立产品开发的经济理由。
当确定开发之后则制定软件开发计划、人员组织结构定义及配备、过程控制计划。
（1）项目计划草案
项目计划草案应包括产品简介、产品目标及功能说明、开发所需的资源、开发时间和里程碑。
（2）风险管理计划
也就是把有可能出错或现在还不能确定的东西列出来，并制定出相应的解决方案。风险发现得越早对项目越有利。
（3） 软件开发计划
软件开发计划的目的是收集控制项目时所需的所有信息，项目经理根据项目计划来安排资源需求并根据时间表跟踪项目进度。项目团队成员根据项目计划以了解他们的工作任务、工作时间以及他们所依赖的其他活动。
可将计划分成总体计划和详细计划，总体计划中每个任务为一个里程碑，详细计划中必须将任务落实到个人。
软件开发计划还应包括产品的应收标准及应收任务（包括确定需要制订的测试用例）。
（4）人员组织结构定义及配备
常见的人员组织结构有垂直方案、水平方案、混合方案。垂直方案中每个成员充当多重角色。水平方案中每个成员充当一到两个角色。混合方案则包括了经验丰富的人员与新手相互融合。具体选择根据人员实际技能情况进行选择。
（5）过程控制计划
过程控制计划的目的是收集项目计划正常执行所需的所有信息，用来指导项目进度的监控、计划的调整，确保项目按时完成。
二、需求分析阶段
需求分析阶段的目的是在系统工作方面与用户达成一致。
（1）软件需求规约
详细说明系统将要实现的所有功能。
（2） 用户界面原型
可以有三种表示方法：图纸（在纸上）、位图（绘图工具）、可执行文件（交互式）。

三、软件开发阶段
本阶段从物理上实现目标系统。采用了面向对象方法。
（1）软件架构
说明软件的组织结构、部署结构及运行环境。
（2）类设计
定义类之间的关联和类的属性、方法。
（3）数据库设计
定义数据库表之间的关联和各个表的字段。
（4）编码和单元测试
按照设计文档进行编码，每完成一个模块应进行单元测试。
（5）集成系统
按软件组织结构的要求将各个子系统组合起来。
四、测试阶段
测试的目的是在发布之前找出程序的错误。包括：核实每个模块是否正常运行（参考设计文档）、核实需求是否被正确实施（参考需求文档）。
（1）测试计划
收集和组织测试信息，为测试工作提供指导。
（2）测试数据
尽量使用真实数据。
（3） 测试报告
记录测试结果，详细描述问题，提出解决办法。
（4）帮助文件和用户操作手册
五、 管理软件开发过程
有以下几方面地工作：
（1）组织会议
讨论会议、总结会议等。
（2）评审程序
对各个阶段的工作结果进行审核。
（3）协调人员
（4） 配置管理
使用一些配置管理工具进行开发文档管理，如：visual sourcesafe，teamsouce等
六、 各参与角色的具体职责描述及对人员的要求
（1） 项目经理
职责：
1、制定产品的目标。
2、制定各个工作的详细任务表，跟踪这些任务的执行情况，进行控制。
3、组织会议对程序进行评审。
4、综合具体情况，对各种不同方案进行取舍并做出决定。
5、协调各项目参与人员之间的关系。
人员要求：
对产品有激情，具有领导才能。
对问题能正确而迅速地做出确定。
能充分利用各种渠道和方法来解决问题。
能跟踪任务，有很好地日程观念。
能在压力下工作。
（2）系统分析员
职责：
1、了解用户需求，写出《软件需求规约》。
2、建立用户界面原型。
人员要求：担任系统分析员的人员应该善于协调，并且具有良好的沟通技巧。担任此角色的人员中必须要有具备业务和技术领域知识的人才。
（3）设计员
职责：
1、定义类的方法和属性以及各个类之间的关联，画出类图。
2、进行数据库设计。
人员要求：掌握面向对象分析与设计技术，统一建模语言(uml)。
（4）程序员
职责：按项目的要求进行编码和单元测试。
人员要求：良好的编程技能和测试技术。
（5）测试员
职责： 执行测试，描述测试结果，提出问题解决方案。
人员要求：了解被测试的系统，具备诊断和解决问题的技能，编程技能

小结一下：
可行性研究：一般只有大型的项目才有。
一、需求分析
1、采集、整理需求，写出需求说明书（叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。详细说明系统将要实现的所有功能。）
需求设计文档（主要把握以用户需求说明书为基线原则。主要内容与用户需求说明书相似，用户需求说明书是需求说明书站在用户角度、使用通俗语言编写的，软件需求规格说明书则是开发者角度、使用开发者的语言编写的，主要差异在于前者是对外的，后者是对内的，通过前者得出后者。）
二、架构设计
（一）概要设计
1、系统结构设计：定义和设计软件的模块化，软件系统各模块之间的关系。
2、数据设计：定义数据库功能模块表结构。数据库设计要考虑到以后的扩展性。
（二）详细设计：逐个地给出各个层次中的每个程序的设计考虑。
三、编码
代码规范
四、软件测试
开发人员内部测试（内测）、交给客户的公开测试（公测）