作为一个老牌的传统行业老大，自然也有一套自己的完整研发流程。但是，由于国内外研发的项目的区别，以及人员工作节奏的不同，原有的瀑布式研发流程自然也并不完全适应国内的研发中心。国内的项目，都集中在行业的中低端领域，价格竞争激烈，高端产品的技术优势在这一市场中无法带来很多的价值。同时，国内的工程师，说句实在话，工作比国外的同事努力得多，你得用足够多的工作量和足够快的工作节奏喂饱他们，否则很容易产生惰性。基于这些特点，我将一些敏捷开发的概念融入了现有的流程中，也参考了这周刚刚介绍的Design Sprint的一些想法。管理、流程都只是手段，能够开发出好产品才是最重要的。
先看一下现有的流程。如果仔细理解这些流程，也不得不佩服德国人在流程设计上的抽象能力。
第一阶段：验证产品技术，排除技术风险；调研市场，生成MRD；
第二阶段：验证需求，生成PRD；使产品符合公司的整体战略，技术上可以复用，生成ARD（Architecture Requirement Document）
第三阶段：证明需求可实现，找到需求解决方案，生成PSD（Product Specification Document）；是产品结构化可复用的解决方案ASD（Architecture Specification Document）
第四阶段：研发，保证产品符合验收条件，通过核心用户测试（Beta test）
第五阶段：准备上市，准备所有上市的材料、文档。
每个阶段之间，都有一次公司各个大佬都参加的评审会，称为Gate。
在传统行业，这一套流程并没有太大的问题，特别是针对高端硬件的研发项目，更利于风险控制和管理。但是，针对中国研发中心的任务，弊病也是很明显的：
1. 研发周期过长。从开始研发到上市，最短也需要1-2年时间。
2. 需求不够灵活。从流程上可以看到，MRD/PRD这些需求文档，和真正的研发过程相差了很久，在2年的研发过程中，需求的变更需要更多的流程。市场瞬息万变，特别对于软件来说，2年之后的技术肯定已经天翻地覆，需求需要更加敏捷地管理。
但是，在传统行业大公司呆过的人可能会深有体会，不走流程，也就意味着没有资源，游戏规则是一定要遵守的。于是，针对本地的快速研发流程，改进如下：
1. 重新定义MRD/PRD里的需求级别。原先的需求，分为三个等级：Must-have/Shoud-have/Could-have。一般的项目，大部分都是Must-have级别，也就是一定是要在研发阶段完成的。高级别的需求太多，优先级不够明确，也是研发周期过长的原因之一。因此，根据KANO模型，我重新划分了级别：基础功能Must-have；亮点功能Excite-to-have（对应Should-have），期望功能Nice-to-have和无差别功能（对应Could-have）。同时，大幅度减少Must-have的占比，只将整个项目的基础功能，如协议、架构等，作为Must-have优先级。尽量完成多的Should-have功能，Could-have基本不做。
2. 缩短研发周期至6个月。对于大的软件项目，宁愿分为多期完成，每一期完成之后，根据市场的反馈重新定义需求。我们不期望2年憋一个大招，而是期望小步快跑。
3. 在第四阶段（研发），部分采用敏捷开发模式，2周为一个周期，不断将迭代的产品更新给核心用户，并得到反馈。而不是在研发完成之后，做一次大规模的beta test，因为那时候即便发现问题，也已经为时已晚。
4. 借鉴Design Sprint，将UI/UX设计，从项目中抽离出来，分配尽可能多的资源。传统企业往往重视技术而不重视用户交互，可以做出很多大而全的软件，而做不出小而美的方案。给予UI/UX相对独立的环境，矫枉过正，加强对UI/UX的重视。
流程是手段，不是目的，这门课让我开拓了眼界，每周的作业虽然经常拖稿，但写作是强迫自己去思考的一种方式。课程给了我一个武器库，从中选择最适合自己的武器，应用到具体的工作中，也是我参加这门课的目的。同时，武器库的使用，也需要小步快跑，不断试错，而不是等到学完之后，再放一个大招。
