运营一个APP，不会写需求文档（BRD）怎么行？
于企业，以及他对于企业有何贡献的信息，就更困难了。传统数据对他而言，大半都毫无意义，尤其是如果信息还是以传统形式呈现，又加上一贯的时间延滞的话，就更加没有意义。不过管理者仍然应该尽量提供信息──不是因为员工要求看到这些数据，而是因为这么做才符合公司最大利益。即使尽了最大的努力，或许还是不可能把信息传递给大多数员工，但是当管理者努力把信息传达给每位员工时，他才有可能接触到在每个工厂、办公室或分店中影响公众意见和态度的人。拥有管理者的愿景 职务安排、绩效标准和信息是激发员工责任感的条件，但是它们本身并不会提供这个动机。只有当员工拥有管理者的愿景时，也就是说，如果员工能站在管理者的角度来看待企业，认为自己的绩效将影响企业的兴衰存亡，那么他才会承担起达到最高绩效的责任。 今天，许多人经常谈到如何赋予员工对工作的自豪感、成就感，以及受重视的感觉，但是别人无法给你荣誉感、成就感和受重视感。员工不会因为公司总裁在信中称呼他们亲爱的同仁而感到更受重视，总裁只是凸显了自己的愚蠢罢了。自豪感和成就感都必须源自于工作本身，无法衍生自工作以外的事物。员工或许极为珍视公司为了感谢他25年来忠诚的服务而颁发的纪念章，但是只有当纪念章确实象征了他在工作上的实际成就时，员工才会感激公司的安排，否则就只会被看成虚情假意，反而容易招致不满。 当员工确实做了值得骄傲的事情时，他们才会感到骄傲，否则就是不诚实，反而有杀伤力。只有当员工确实有所成就时，他们才会有成就感，也只有当他们承担了重要的任务时，他们才会觉得自己重要。真正的自豪感、成就感和受重视感是奠基于积极、负责地参与有关自己工作和工厂社区管理的决策。 最近，切萨皮克俄亥俄铁路公司的员工提供了一个令人印象深刻的例子。1953年11月14日出版的美国《商业周刊》报道了这个故事： 本周一批切萨皮克俄亥俄铁路公司的员工走进董事会的豪华办公室中，展示他们的骄傲与喜悦：他们为重建亨廷顿工厂所构思的模型。 这个模型是由60位铁匠、电工、木匠、引擎技工和学徒出于对工作的热爱，经过六星期马不停蹄的努力（而且大半利用公余时间）完成的。切萨皮克俄亥俄铁路公司高层估计，类似的规划可能要花30个月到3年的时间才能完成，由此可见这次集体努力的规模是多么庞大。 最初之所以会引发这个想法，是因为切萨皮克俄亥俄铁路公司领悟到亨廷顿工厂必须重建，才有办法维修柴油引擎火车头。于是，在厂房中上班的员工开始在午餐时间讨论重建计划。 根据主管斯莱克的说法，1928年建好的旧厂房设计得很糟糕，早就让员工受不了了。举例来说，车轮厂竟然离设厂地点很远，只好大老远把轮子运过来。 那天中午，谈话内容很快就落实为具体方案，每个人都提议如何解决自己厂房现有设计上的问题。他们的上司斯莱克仔细聆听各种建议，并且详做笔记。他找了绘图员把构想画成蓝图，然后邀请所有人参与整个规划工作。最后的成品就是本周在董事会中展示的模型。 整个计划除了让员工很开心外，还有几个极具说服力的优点：整个重建工程的预估成本大约在250万美元，远低于管理层原本预期的1000万~1500万美元，真是大快人心。 当然，需要重建整个厂房的机会并不多，但是管理者不停地会碰到需要设计个人职务或团队工作的问题。 我们总是设法把工作分解为小单位，依照逻辑顺序安排工作流程，但是却没有理由一定要由工程师来为员工分析工作、安排流程，这种做法无非是迷信应该区分计划和执行罢了。我们有充分证据显示，如果负责执行工作的人能预先参与工作的规划，那么计划将会更加完善，这正是工作简化技术的精髓所在。而30年来，这种做法显然非常成功，无论应用在什么地方，都产生一致的成效：工作的规划更加完善、绩效更高、员工也不再抗拒改变。难怪切萨皮克俄亥俄铁路公司早在员工主动参与厂房重建计划之前多年，就已经开始在工厂推动工作简化计划了。工厂中的社区活动 但是参与规划自己的工作并不是培养管理者愿景的惟一方法。员工还必须有机会在工厂社区中担当领导，这是获得实际管理经验的最佳途径。 一个人能在工厂社区中挑起领导重担并赢得尊敬的特质，通常不见得符合管理职位所需要的特质。然而，企业肯定和奖励员工的惟一方式通常都是升迁。无论升迁机会是多么丰富，升迁制度是多么公平，员工中总是会有一些广受尊重的领导人物没能更上一层楼，他们因为失望而开始和公司唱反调，以继续发挥他们的领导才能。难怪有这么多工会领袖选择工会为他们事业发展的舞台，因为企业无法通过升迁制度肯定他们的领导才能。 著名的工会领袖鲁瑟（Walter Reuther）正是其中一个杰出的例子。毋庸置疑，鲁瑟深信自由企业制度不是那么理想，他的想法主要是根据一个前提──好的制度应该早就发掘并且重用像他这样的领导人才。我也认识许多不管在气质或外表上都极端保守的工会干部，他们对工会活不论在工作还是生活中，我们总会产生一些好想法，或者有机会去做一些新的事情，比如领导说，我们的竞争对手做了一个xx产品，让你想想看我们要不要做，或者你想到一个好的产品解决方案，能弥补现在产品的短板，你想把它实现了，如果你刚参加工作，以上情况都没有遇到过，那么你总有过想去开发一个APP，做一个网站，或者想去开一个自己的小店这样的想法吧！当遇到这样的场景，我们要做的第一件事情，不是马上行动，而是去分析这个事情，梳理思路，描绘出蓝图，然后把它表达出来，为接下来的行动争取充足的资源，这些资源包括资金，场地，软件，硬件，研发，运营等。你要获得这些资源，就要说服掌握这些资源的人，告诉他们，你要做一件什么样的事，做这个事需要用到哪些资源，用在什么地方，怎么使用，能获得什么样的收益，用一个系统的思路和语言表达来说服他们，这个系统的思路和语言表达的输出物，就是我们经常说的商业需求文档(BRD), 如果你是创业者，对应的就是商业计划书（BP）.撰写MRD是产品经理或者说想表达自己想法的人，尤其是需要宣讲和汇报工作的人必备的硬技能，今天这篇文章就教大家怎么来系统的写商业需求文档，内容主要包含以下5个方面：在什么情况下需要写BRDBRD的构成要素BRD撰写前的准备工作BRD的撰写BRD的使用场景注意事项一. 在什么情况下需要写BRD在项目的管理流程中，有一个关键的决策的动作叫立项，这个动作不限于在互联网项目的管理，在所有的规范的项目管理流程中也都有，立项是一个项目的风水岭，立项了，就是决定一个产品要正式开始做了，在立项前，往往要进行大量的考察和调研，最后基于调研结果输出一个方案，这个方案就是BRD。在BRD中不只要说明为什么要做，还要说明打算怎么做，以及需要的资源和预期收益，决策者依靠它来决定一个项目要不要立项,撰写的人依靠它来获取资源。所以如果你想让一个项目获得老板，投资人的支持，推动项目立项，就得准备写BRD了！知道了在什么情况下需要写BRD，那么在实际工作中，具体什么时候开始着手写呢，在前面讲需求分析的时候，我们讲了做一个产品前期需求分析的一个过程，这个过程是 发现痛点》分析人群和市场规模 》确定用户需求 》提出产品解决方案 》评估产品需求》管理产品需求，在这六个步骤里面，在第五步，提出产品解决方案并且进行评估后，就可以考虑开始准备着手准备BRD的撰写了。二. BRD的构成要素1. 产品介绍产品介绍就是要简明扼要的说明你要做一个什么样的产品，说明要简短，最好用一句话就能说明白，包括产品的作用，定位，愿景等，要能让看的人快速理解，在这里给大家两种表达的方式建议：一种是从使用者的角度来表达，突出产品的功能和作用，比如qq和微信可以表述成让家人，朋友方便高效的在网上聊天的工具，愿景是打造成全球网民的沟通工具，淘宝可以表述成在网上开店卖东西，也可以买东西的平台，目标是让天下没有难做的生意另一种是从专业人士的角度来描述，因为这个文档是给决策者看的，决策者大多都是行业经验丰富的大拿，可以用比喻的方法来表述，比如做中国版的Facebook，中国的yutube,教育界的淘宝等，用一个大家已经熟悉的产品来说明自己要做的事。2. 产品价值产品的价值就是要告诉决策层，为什么要做这个产品，可以分两个层面来谈：（1）从用户/客户的需求角度来看这个产品满足了用户/客户什么样的需求，从痛点, 使用场景，人群定位层面来谈，比如摩拜等共享单车解决了用户从家到地铁站，从地铁站到公司等这样短途出行的问题，在没有共享单车前，这种短途出行开车找停车位困难，走路太远，坐公交地铁需要排队，买自行车没处放，这样的需求一直没有很好的解决，有了共享单车问题就解决了。（2）从战略的角度来看做这件事能为企业带来什么价值，能获得巨大利润，还是能增加市场份额，还是能延长服务的链条，或者是能形成协同效应等，比如原来做电商，用户粘性差，现在做个购物社区，让用户不仅可以购物，还可以在里面交流，这增加了用户的停留时间，这对企业的好处是用户粘性增加了，营销成本下降了， 还有比如滴滴投资ofo，滴滴是满足用户出行打车的需求，ofo是满足用户短途出行需求，这两个产品的用户人群有重叠，但是使用场景互补，滴滴投资ofo有可能形成协同效应。3. 产品解决方案产品解决方案就是告诉决策者，这个产品大概的框架和轮廓，主要包含以下几个方面：（1）产品形态这个产品架构大概是什么样的，是资讯形态的，社交形态的，搜索形态的，还是O2O的。（2）业务模式告诉决策者这个业务是面向c端的还是面向b端的，还是b端和c端都兼容的，参与者都有谁，怎么来形成闭环等。（3）运营模式采用什么样的运营策略和手段让产品运营起来，比如在教育产品里面非常重要的一个资源是老师，解决老师资源问题有两种方式，一种是自己招聘，另一种是众包，这就是两种不同的运营模式（4）盈利模式盈利模式就是这个产品通过什么方式来赚钱，做企业的目的就是为了赚钱，即使是财大气粗的公司，也考虑这个问题，赚钱的模式包括，广告，增值服务，出售商品等，在这里不再赘述。这一块在前面讲需求分析的时候讲过，在这里不再赘述。4. 市场分析做产品不能闭门造车，还要看看市场上的情况，这个市场分析包括以下几个方面：市场容量有多大，这个数据需要通过对需求的分析，对人群判断后评估得出，决策者会通过这个判断值不值得投入竞争对手分析，看看市面市面上还有哪些玩家，他们是怎么解决的，满足了用户的哪些需求，还有哪些没有满足，投入怎么样，团队怎么样，产出怎么样，与我们对比我们的优势是什么，劣势是什么对市场未来的判断，包括未来市场竞争格局，行业的风险，政策的变化, 行业的发展方向等判断我们在市场上的机会在什么地方，怎么找到突破口，这个机会可以让我们发展成为一个什么样的地位5. 执行计划执行计划就是我们准备怎么来做这个事，在互联网行业，最重要的执行就是产品研发和运营推广，BRD中的计划部分，我们列出产品阶段和目标就可以了，不需要写具体的产品怎么设计，怎么开发，怎么运营，而且后面还会有MRD文档来让你写这些，在这里只要大致的描述就好。比如：第一阶段先用mvp的方式验证用户需求，时间从xxx到xxx时间段第二阶段完善产品，扩大用户规模，时间从xxx到xxx时间段第三阶段，第四阶段等等6. 财务预估财物预估主要的就是预估投入成本和产出收益，这是决策者最看重的部分，没有人愿意只投入不产出，投入成本相对而言是比较容易预估的，可以先看看成本构成，包括人员工资，办公成本，（场地，办公器材，水电等），服务器带宽成本，软件成本（购买一些第三方服务），市场推广成本，然后通过市场价格算出来，而收入预估往往就是吹泡泡，连算的人心里可能都没底，但是这个必须得有，如果你要用广告的方式盈利，可以根据预估的用户数和常见的广告售卖方式比如cpc,cpa等来计算，如果想要靠卖东西来赚钱，可以通过客单价，用户数，转化率等来估算。7. 风险预估风险是指有可能影响产品目标实现，或增加产品成本的行为和因素，在考虑风险的时候，我们不仅要对所有可能出现的风险进行评估，确定风险出现的可能性和严重性，而且要给出对应的规避预案，并明确预案的规避效益。三. BRD撰写前的准备工作BRD是立项前进行评估使用的输出物，其本质是对于前期的调研工作的整理总结和书面化，所以要写好BRD，必须做好前期的准备工作，准备工作最起码包含以下几个方面：用户调研：了解用户真实需求和市场规模行业研究：了解行业过去，现状和未来，了解行业里面的玩家情况解决方案构建：对于发现的问题提出解决方案这一部分在之前讲需求分析的时候，已经讲过，不再赘述了四. BRD的撰写BRD主要使用 word和ppt进行撰写和展示, ?跟其它文档用的工具都差不多，这里没有什么特别要说明的，大多数是用ppt来撰写，格式可以自己觉得怎么美观怎么来，重要的是内容结构和内容的深度，一份BRD中一般包括一下内容：BRD标题：xxxx项目商业需求文档撰写人撰写时间目录产品介绍产品价值产品解决方案市场分析执行计划财物预估风险预估五. BRD的使用场景1. BRD给谁看我们要通过BRD来争取资源，就得说服掌握资源的人，让他们力同意投入，在公司资源一般都掌握在高层手中，比如我们常见的CEO，coo,cfo等，而因我们所处岗位的不同，决策者的角色有可能有变化。一般公司都会有老板，高级管理，中层管理，基层管理人员和基层人员这么几个等级，老板就不用解释了，高级管理人员往往是合伙人级别或者副总裁级别的，中层管理是总监级别的，基层管理人员对应的是小组长，在这种决策模式中，工作是一层层的往上汇报的，如果你是基层的执行人员，就跟玩游戏闯关一样，你写的BRD得经过上面的每一关的审核，你的上面每一个级别的人都得看然后，我们再来看看做一个产品需要的资源，一般会有资金，人力资源（包括研发人员，运营人员，市场人员等），硬件（服务器），场地等，你要获得这些资源，你的BRD还要给掌握这些资源的部门的领导来看，争取他们的同意。所以一般是你的直属领导和直系领导，以及兄弟部门的领导都有可能会看你的BRD.2. BRD使用场景BRD大多数是在立项的会议上辅助演讲进行使用，项目的发起人或负责人通过BRD来向参会者展示关键信息，然后通过语言的讲述弥补细节信息，进行说服，演讲完成后，参会人员会根据自己接收到的信息，结合自己的经验判断进行提问，类似于项目路演的一个过程，这是BRD典型的使用场景六. BRD注意事项1、BRD并不只是简单的写个文档，背后需要有很多准备工作要做；2、在文档中少关注产品细节，多关注产品商业价值的部分；3、文档阅读对象是领导，要逻辑严谨，言简意赅，多准备；4、在真实的基础上，尽量让内容偏向自己有利的一边引导，毕竟是用来说服领导并且争取资源，不是来做工作汇报的；5、BRD大多数是用来演示辅助演讲的，在演示前多做练习和准备。七. 小结文档的目的是辅助你达到自己的目的，上面的讲的内容，并不是标准的格式，只是一种思路的分享，你可以根据自己的情况进行优化调整，不要生搬硬套。作者：木木来源：人人都是产品经理
