1.产品调研

产品的调研属于市场范畴，由市场部门负责。产品调研是为了提高产品决策质量，解决存在于产品设计及产品上线后销售中的问题而系统、客观的收集、分析市场综合情况的行为。所以与内部产品不同的是，外部产品调研需要撰写市场需求文档即MRD，只有符合公司战略和市场需求的产品，方可进入产品立项阶段。而内部产品调研由于不涉及市场环境，为了产品设计流程的敏捷和高效，不需要提交调研产出物。经过确认必要且可行的产品，可直接进入产品立项阶段。

2.产品立项与评审

产品立项是产品设计项目流程的起点，产出物主要为《产品立项说明书》。产品经理负责产品立项时的文档撰写以及项目时间和人力计划安排。产品立项后， 直接进入立项评审流程。立项评审是对产品立项说明书和项目计划的综合评审。立项评审各节点的负责人需要填写《产品立项评审表》，评审通过时评审自动流入下 一节点直至归档。立项评审通过后直接进入产品详细需求及设计阶段。

3.产品需求与DEMO设计

产品需求是项目流程的重要组成部分。主要由产品经理负责，对内部业务需求进行详细的调研分析。根据需求，产品经理需要设计业务流程以及构建产品框 架，使产品能够满足业务方需求；同时与技术部门协同确保产品方案能够顺利实现。当产品需求明确后，需要设计产品线框图即DEMO展示，确保良好的可用性和 用户体验。详细交互情况需要在产品需求说明书中注明。本阶段主要产出物为《产品需求说明书》，以及产品DEMO。应用工具主要为Visio、Axure等。当需求阶段结束后，进入需求评审流程。另外，需求变更一般是在设计阶段，用户的需求发生变化时进行的，当需求评审结束后进入开发阶段时的需求变更应该尽力避免。

4.需求评审

需求评审需要业务需求、产品、技术共同参与，由该项目产品经理对产品的需求说明书以及DEMO做详细汇报，并解答各方面疑问。参与的评审人员需要填写《产品需求评审表》，评审通过后项目自动流入UI设计流程。需求评审的结束是项目的里程碑。

5.UI设计与美术评审

UI设计主要是针对产 品表现层的设计，包括框架、元素、界面、文字等等的标准化设计。与DEMO的线框图不同，经过UI设计后，经过确认产出物产品原型需要直接作为前端开发的 标准。因此UI设计结束后，需要进行美术评审，征求公司领导和相关产品负责人对产品原型直观印象，直到最终原型确定进入前端开发流程。部分内部产品不涉及 UI设计的，可直接进入技术开发。

6.技术开发及前端开发

通常情况下，技术开发在需求评审结束后即可开始介入。即根据产品需求文档和DEMO原型，开始架构产品底层，由架构师负责。随后展开源码撰写的技术 段工作，主要由技术部门负责。当产品UI标准及美术交互原型完成后，根据底层开发情况，可以开展产品前端开发。部分网站产品如板块变更，不涉及底层开发部 分的，可直接进行前端开发。

7.测试及上线

当开发完成时，由测试部门（测试部门在需求阶段即可参与项目）撰写用例并测试。新产品需要首先发布到测试平台使用测试，网站产品进行大范围改变时，需要上线测试版经过客户熟悉和认可后方可正式上线。

8.产品跟踪

了解业务使用情况，同时针对产品使用过程中出现的问题进行修复；当业务需求变化时，及时对产品进行升级或进行二次开发。产品经理需要在产品的生命周期中持续跟进产品。

产品版本控制

Firefox的trunk、branch、Nightly版本和Release 版本的区别

mozilla/firefox的开发主要是这样的，
首先是有一个trunk，可以理解为主干，code name是seamonkey，不断的有新的代码加入，包括新的feature, bug
fix等等，每天会从trunk上check out一次代码，做一个build，这个就是trunk的nightly build。

每次准备要出一个新版本的时候，会做一个branch，可以理解为分支，和trunk独立起来，这样在trunk上加入的新代码就不会影响
branch的稳定。branch主要做bug fix和小的功能性的修改，branch加入代码的要求相对严格，除了得到review和super
review外，还需要得到dirver的approve。aviary就是firefox 1.0的branch的code
name,在release之前每天也会check out代码做一次build，这个是属于某个branch的nightly build。

branch中需要改的bug都改完后，mozilla.org的QA就会同意做最终的release（通常在最终release前会有几个
release condidate，都是为了确保最终发布产品的质量)，会在branch上打一个tag，然后check
out代码，做build，正式发布。

有一些branch，mozilla.org会决定长时间的维护，也就是在release了一个版本后，会在branch上继续加入一些重要的
bug fix。比如mozilla1.0, 1.2, 1.4, 1.7以及firefox
1.0都是或者曾经是这样的branch。这样的branch即使在release以后仍然有代码加入，所以仍然会做属于这个branch的
nightly build，然后在合适的时候发布minor release，比如firefox 1.0.1,
1.0.2等等。现在的所谓的firefox1.0.4其实就是aviary目前(真正的1.0.4发布前)的nightly build。

这些过程，看图最直观了:

你的1.0+的nightly实际上是trunk的nightly,在没有branch之前，版本就没有改，哪天1.1出了branch，你再取得1.1 branch上的nightly,就可能是1.1a或者1.1b了，再看trunk，可能就是1.1+的了。

说了这么多，也不知道说清楚没有。