引言

小说被认为是一个民族的秘史，作者陈忠实以巴尔扎克的这句名言，作为小说的题记，表达了他创作史诗性小说的宏大野心。小说被认为是一个民族的秘史，这句话并不适用于所有的小说，有时候他是一个人的秘史，或者是一群人的。但是在白鹿原，以及跟陈忠实同时代的作家的大多小说里，这句话再合适不过了。白鹿原所选取的这个时间段—清末民初到建国前夕，正好是我们民族从农耕文化向现代文化，艰难转型的一个时期。漫长的封建专制的淫威，早就扼杀了绝大部分平民，百姓本就微弱的参政议事。作者借白嘉轩之口，引出了一条贯穿全书的主线，没有皇帝了，往后的日子咋过呢？

2000年封建制度瓦解后的半个多世纪里，那些没有名字的中国人，只在虚构的小说里留下最后的样子。时代更迭的大浪褪去，在被洗刷过的海岸上，我们只能从一条被晒干的鱼身上得知，这块泥潭里曾经有这样的生命挣扎过，他们狰狞扭曲的最后的样子变成风干的标本，而标本是不会说话的，没血也没肉，他们的形象最终在历史里被统一成一场运动，被统一成一个阶级，被统一成一类思想，被统一成一股力量，被统一成一个事件，被统一成一句口号，被统一成一种声音，被统一成一样的命运。这些被统一的我们已然在历史中看到，而那些被过滤掉的不足以记录下来的，作为个体的不自知的，不被接纳的，它们最终在小说里得以秘密的呈现，他们并不汹涌如巨浪，更像埋在地底的黑色的暗流，秘而不宣、缓慢又哀伤。

小说背景

白鹿原小说的背景就是陈忠实的老家，关中平原的一个村子，五六十年代的作家写时代的都离不开两样东西，一个是家族，一个是家乡。家族往往成了故事的整个的结构，它的串线。家乡就是整个小说的文化的背景。（隐秘的高粱地，豪放的酒干，撕裂的秦腔，干枯的黄土地，男人关着黝黑的身子，女人是生育的机器，老人的皱纹里都嵌着泥土，这里伸展着一切粗犷，以至于野蛮、沉默又顽强，他和温热阴冷的江南的情绪是不一样的，它不是哀怨，它有点生猛的悲怆、更加单一、也更加具有原始的力量。）

1. 评审

哼哧哼哧写完需求文档，为了保证产品的质量，需求方案还必须要通过各方的评审，方可进入开发阶段。产品需求是产品每个干系人的事情，项目中的需求阶段通常会围绕着写作、评审、修改、评审的循环展开。评审就是项目中相关的几个小团队坐在一起，一方讲另外一方听，并确认统一认识，消除误解，及时发现偏差，防止问题随时间放大。不做评审看似省了时间，但往往隐藏了问题，待到其爆发的时候会耽误更多的事，而且会在谁负责的问题上纠缠不清，与其亡羊补牢，不如尽早在流程上预防，所谓防病优于治病。

项目中最重要的三种角色，就是PD（Product Designer/Product Director）、开发人员、测试人员，由此派生出三次评审：需求评审、设计评审、测试评审。

1.1 需求评审

需求评审是PRD评审、UC评审、DEMO评审的统称，评审会上PD把PRD和UC说给开发测试听，DEMO评审则由UE的同学主讲。在做出比较大的PRD之后马上安排一次评审，当然也会有UC和DEMO的半成品，以期尽早发现问题，比如业务规划的不合理、产品界面太丑陋、某功能技术上无法实现等。

PRD的评审，会重点关注偏商业的内容，强烈建议叫上老板、营销人员、服务人员甚至用户一起来听。PRD通过以后，PD们会和UE的同学一起细化UC和DEMO，而开发的同学也会同步进行一些开发前的准备工作，比如细化和修正项目计划、部分统计的设计。

接下来的DEMO评审决定了产品的外观项目，干系人最好都来把下关。而UC评审更偏重技术实现，商业团队的成员可以选择参加。

1.2 设计评审

设计评审是在概要设计与详细设计完成之后进行，由开发工程师把对需求的理解，以设计文档的形式说给PD、测试听。

1.3 测试评审

测试评审俗称TC评审，是在TC编写完成，测试开始执行之前进行，由测试工程师把对需求的理解，以TC的形式说给PD开发厅。

每一种评审都可能有多轮，会上没问题就快速的通过，有小问题当场确认，大问题带回去。原则是改动较多的话，必须再次评审，审议不大可以通过。评审会议的组织者可以考虑都由QA担任，作为项目过程管理的一部分，也可以考虑由每次评审的主讲人发起。

需求评审会的组织过程中，特别要注意两种容易漏掉的参与者，大家可以扩展应用到各种评审会上。一是能做决定的人，因为评审的时候，各方不可避免的会对需求有不同理解，从而出现争论，而很多问题都是公说公有理，婆说婆有理，谁也说服不了谁。这个时候啊，就需要有人能拍板，有人能负责。二是与此项目有关的产品接口人，他的参与可避免太晚发现与其他系统有冲突，修改起来措手不及，作为PD肯定是希望只要有点儿关系的人都来参加会议，但现实中呢是不可能的，所以必须识别出对当前项目来说谁更重要。

再看需求的生老病死，之前是从某个需求本身的状态变化来看，现在我们把它融入项目再审视一番。除纯技术项目外，PD是产品不断改进的原动力，所以项目前期PD主导的环节比较多，而一个需求就在这些环节中生老病死了。我觉得可以用几个会议来概括，项目大小有不同，所以这里的会议不需要严格理解成会议室里一群人正襟危坐，有可能是两三个人围在电脑前的几分钟交流。

2. 项目中的各个阶段

项目开始之前，在产品团队内部，分析需求商业价值的需求讨论会、多个产品间的产品会议上，PD们带着自己的需求参与讨论，为那仅有的开发和测试资源PK，人性的本能让每个人都极力维护自己提出的需求，并设法反驳别人，当然了出发点都是为了用户，最终也会达成一致，活下来的需求会确定需求负责人，状态变为需求中。

2.1 需求阶段：

项目中的需求阶段：项目启动之后PD就得抓紧时间完成需求的开发，不时召集需求评审会，大家一起讨论这样做有哪些问题，PD收集到意见反复修改需求直至最后一次评审通过，需求得以确认，状态变为开发中。当然，之后的需求微调总是无法避免，但需求冻结的里程碑要求在这之后就不要轻易改动了。

朗朗晴空 日照当头 静静深夜 月涌江流

心似晴空 理想当头 行似深夜 智慧江流

人生代代 无穷无已 你来我往 谁为先手

人生如棋 黑白相间 局里局外 一生好走

放上《人生如棋》的填词，让它陪伴我一同成长。本文的行文逻辑：以几张图的形式引入概念。

曲三，围棋基本死活形状之一。被包围的棋子围有成拐弯的三个交叉点，也叫“弯三”。红框处是死活要点，此时黑棋被白棋围住：白棋先手于红框处落子，做成两眼成为活棋。黑棋先手于红框处落子，白成死棋。

直三：基本死活之一。一块棋被围，其眼位是直线形状的三个交叉点，称为“直三”。形势，若轮黑方走，下在A位可做活；若轮白方走，在A位破眼，黑子只有一只眼，黑被白杀。在对战中，后手做成直三往往是不能够做活的，因为当己方走完，对方会直接在A位破眼。

对于直三、曲三的死活结论是——先手活，后手死。

打劫：简称“劫”，也称“劫争”、“争劫”。对局双方从开劫、提劫、找劫、应劫、再提劫，直至消劫的整个过程，均可概括称为“打劫”。

黑白双方都把对方的一个棋子围住，这种局面下，如果轮白下，可以吃掉一个黑子；如果轮黑下，同样可以吃掉一个白子。因为如此往复就形成循环无解，所以围棋禁止“同形重复”。根据规则规定“提”一子后，对方在可以回提的情况下不能马上回提，要先在别处下一着，待对方应一手之后再回提。

如下图，轮白下子时，白棋先手于红框处落子，白吃黑一子；此时，黑不能立即回提白子，必须寻找劫材，即在别处下一着，待白方应后，再回提白子。但是，并非所有的劫材都会导致对方应一手，在价值判断取舍的情况下，对方也可能不应劫而解消劫争，“劫胜”也叫“消劫”。

产品 VS 项目

产品：解决问题的东西。

项目：只会进行一次，包含多项互相关联的任务，并且有绩效、时间成本、范围限制的一项工作，项目是一个过程。

做产品 VS 做项目

我们从三个方面来比较做产品和做项目。

第一，从生命周期的角度来看，做产品的生命周期相对较长，关注的是整个产品从规划到制造、维护、消亡的过程。而项目有特定的指标，所以生命周期较短。通常在项目开始以前就有明确的起始和结束的时间，通过验收则表示项目的生命周期就算完成。

开始做一个产品的时候，没法明确这款产品何时结束，一般会随着时间的推移、市场的变化、公司战略调整等因素，渐渐走向生命周期完结。所以会有一个已经结项的项目，但不会有一个已经完成的项目，只有不断完善中的产品，除非它被新产品替代。

第二，从具体要做的事情来看，做产品的过程会有更多的探索。随着各种内外部信息的变化，产品负责人需要不断地修正自己的判断，给出合适的创新。而项目在开始的时候就已经有明确的目标，更注重计划与控制。项目的过程很像是执行一个任务。无论是做产品还是做项目，都需要与团队成员的协调沟通，对未来一段时间做出计划。

第三，从产出物的角度来看，产品是可以批量生产，或者提供给大量用户，所以相对通用。通常考虑用有限的资源去满足更多的，更能有回报的需求。而项目只能进行一次，意味着每次都是定制的，个性化的。通常为了满足特定的需求，产出物也比较个性化，这就意味着项目要满足那个特定的需求。当然，我们会看到有的项目产出，经过改造成为更通用的产品，或者有的产品也可经历个性化定制及做项目。

产品经理 VS 项目经理

一个是product manager，一个是project manager，工作都需要跨团队，工作范围也有重叠，简称还都是pm。

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

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

产品经理关注的是做正确的事，关注的是产品生命的周期，关注的是产品是否能赚钱，是否能持续的赚钱。因此产品经理必须要能够规划整个产品的架构和发展路线，能够确定产品的定位和受众，能够预计产品真正的价值和效益。

项目经理是需要正确的做事情，即按照产品规划制定的项目目标，正确地做事情，项目能够按照目标完成，则项目就是成功的。即使项目的产品不能真正盈利，那往往也是产品规划出现了失误。项目经理关注的是项目能否按既定的目标顺利完成。产品究竟应该规划哪些功能点，那是产品经理的事情，是项目范围的输入。

产品经理是内部驱动，项目经理是外部驱动。对产品经理来说，最重要的是判断力与创造力。产品经理决定做不做，做什么，做多少，保证方向正确。它是产生一个想法，我要把它实现。对项目经理来说，最重要的是执行力与控制力。项目经理决定怎么做，谁来做，何时做，保证方法得当，即接到一个任务，要把它完成。

做项目的终极目标就是多快好省，即范围大、时间短、品质高、资源省。但又要马儿跑，又要马儿不吃草的事情是没有的，所以我们通常是在上述四个要求中做平衡。一般采取敏捷方法，有比较固定的迭代周期，一般是二到四周；有一个人员相对固定的团队，即项目资源确定；此外任何时候都要保证项目品质，最后能变的只能是量，项目范围。

当有了项目时间长短，可以按经验的比例，估计出留给开发的时间有几天，团队里有多少开发工程师也是知道的，所以可以直接算出有多少可用工作量，同样以人天为单位。之前把产品需求列表按照性价比从大到小排序过，从上往下看每一行后面还都对应着一个工作量，现在只要做一个简单的加法，一行又一行的从上到下，依次纳入项目，能做多少一目了然。这个动作叫做需求打包。

而对这些需求的整体描述，也就是商业需求文档里的功能说明。当然了这只是一个基准，可变因素非常的多，所以每次产品会议都要准备好几个项目让大老板们选，每个项目也有可能在产品会议，被砍掉部分需求，所以可以先相对随意的超出可用工作量。

需求打包几个需要注意的地方：

第一，需求打包最好打包类似的功能点，是否类似取决于需求的基本属性，一般来说，业务上的逻辑关系密切的需求才会包含在一个项目里，这也很好理解啊，否则就是一个纯粹修修补补的小需求项目了。实际操作中，打包多大，更多的是取决于这一点。更好的方法是需求在打包以后通过业务逻辑图的方式实现可视化，可以更直观的给别人讲解。

第二，需求依赖，功能之间互相有依赖关系，那些只能先做的功能，应该在产品需求列表里注明，功能与人力资源之间的依赖关系，也会经常存在。比如有些功能只能由团队里的特定人员来做，在这里评估工作量的时候不会考虑谁来做的问题，在正式立项以后，组建团队的时，候会重点考虑，当然长期来说为了避免这类风险，提升与平衡团队成员的力才是王道。

第三，需求的力度大小问题。

商业价值很高的功能，如果细分的话，会发现其中也有价值相对低的部分，所以需求的力度应该尽量细，前提是细化引起的管理成本上升，也在可接受的范围内。比如大开间办公区里的灯，不太可能用一个开关控制，也不可能每个开关只能控制一盏灯，具体细掉多少要根据具体情况具体分析，在需求列表里出现的任意一行，工作量最好不要超过五人天。

一般来说，产品会议一个月一次，当然这和产品性质有关。如果产品周期比较长，那也可以两三个月一次。当某个产品团队开始登场亮相的时候，一般要回顾上一次的产品会议通过的项目现在进展如何，是否需要调整时间进度，是否需要追加资源，是否有重大需求变更，已经发布的项目有什么问题？这样一方面是为了让大老板们更新对各个项目的信息，更重要的是为了积累经验，让今后产品会议上的决策越来越合理，回顾之后就是最关键的部分，拿出准备好的商业需求文档。每个产品都会拿出三五个，占满二到三倍的潜在资源，这里说的潜在资源是指相对固定的开发测试人员，因为技术人员有对产品的熟悉问题，所以在短时间内，不可能太多的人同时转去做其他产品，这也就意味着潜在的人力资源数量是在一个值附近做微小浮动的。所以我们也可以认为，在一定程度上，资源的争夺是以产品间的争夺为辅，产品内多个项目的争夺为主。很有意思的是，这三五个商业需求文档，通常是产品团队里不同的人做出来的，所以内部也会争夺的你死我活。

接下来的重头戏是一直提到的商业需求文档，刚刚把需求打好包，接下来就要描述一下这个包了。这就是商业需求文BRD。它是参加资源争夺战的武器。BRD、MRD、PRD这几个词是从商业的描述，渐渐过渡到对技术的描述。我经历的团队在实际操作中通常只写两种文档，一个是给大老板们看的BRD，包含了BRD以及MRD的部分内容。另一个是在项目中写的PRD。

BRD怎么写都包含哪些内容呢？项目背景、我们在哪里？为什么要做这个项目？解决了一个什么问题，可以列出一些数据说明项目的必要性、商业价值，我们去哪里。最关键的重点，做这个项目有什么价值，预测一下相关数字的变化，提出这个项目的商业目标功能需求描述。（非功能需求描述：通过做哪些事情来达到目标，把打包好的需求描述一下，可以通过功能列表的形式表达，但最好画出业务逻辑关系。）

资源评估第二个重点，大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后才能做出决策。有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策。说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定了。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突。这时候提出来也是让老板们把下关。