读书：《人人都是产品经理》-苏杰

 一   产品经理和需求分析

产品经理的大方信仰：好产品改变世界。

产品经理的思维：从产品的角度，可以打造任何一款产品，自己的儿子女儿打造出优秀者的模型？

 

产品核心：高质量的设计抓住用户的交互。

高性能的程序质量决定产品实用性本身。

 

听用户的但是不要照着做。有的用户很危险。

解决方案是站在他自己立场的，不是通用的，属于自定义范畴。

 

要成为产品经理先成为需求分析师：

无视用户想要的东西，探究它真正的渴望，再给出好的解决方案，这就是产品经理存在的价值。

 

满足需求的三种方式：

改变现状；降低理想；转移需求；

产品设计的最高境界是创造需求（brainstorming）。

 

需求分析的过程：

用户需求转化——确定基本属性——分析商业价值----初评实现难度----计算性价比

 

需求的量化：

需求ID  提交人  提交时间 产品模块归属 名称 描述 提出者  提出时间 bug编号 （视为需求）

 

根据人类记忆的特点模块5+2，5-2个比较正常，网站导航以及自己电脑设置目录结构也要符合这个原则

 

需求的种类：

分类：新增功能、功能改进、体验提升、bug修复、内部需求

层次：基础，拓展，增值

很多需求不是为用户做的，为销售，服务，测试团队等做的。

产品需求：产品功能需求和非功能需求

产品包需求：产品需求+市场需求+开发需求+测试需求+服务等需求

 

具体需求举例：

性能需求：论坛需要支持1000人同时在线

培训需求：必须在发布2周前完成客服部的培训

运维部维护需求：如果硬件压力突增，应该报警，具体细节是…

内部数据分析需求：此功能的用户操作日志需要记录

 

雪中送炭的需求和锦上添花的需求

 

对于运维以及开发来说，持续集成自动化监控报警，以及开发中日志模块记录必须是完备的

 

【读到这里感觉产品经理课应该早于开发者，因为通读之后非常有助于提升开发者对需求的理解领悟和把握，不懂运维，测试，产品真正需求的都不是好的开发者，开发者的整体上层思考的素质都在开发之外的这些活水源头，因为这些活水最后都留到开发者的脑海里】

 

 

二 一个需求的奋斗史

需求的商业价值是需求的核心，性价比的重要决定开发

需求的商业价值：重要性、紧急度、持续时间辅助确定商业价值

 

1【绝对不能因为某个需求的商业价值很大就马上去做，也不能因为商业价值不大就不做】

2【绝对不能因为某个需求的实现难度很小就马上去做，也不能因为需求实现难度很大就不做】

3【不要试图满足所有用户，一切皆看性价比】

 

性价比 = 商业价值/实现难度（一般瓶颈为开发量）

 

产品经理对性价比的判断经常有偏差？

产品经理对性价比的判断经常有偏差（其实根本上是产品不精通技术造成的，这个对于同时兼懂产品和技术的项目经理来说可能更容易），产品经常和开发相处就知道的多，经常和销售运营一起就会倾向于考虑商业价值。

 

【古代皇帝和文臣多论不知军事，和武臣讨论不知治国，大概只有自己懂军事和治国才不为所疑惑。】

 

需求pk？

每个产品经理都会拿着自己精心准备的BRD商业需求文档跟人事争下个月的人力资源，即开发工程师，测试工程师等

 

BRD【Business Requirement Document】给老板

MRD【Market Requirement Document】给老板

PRD【Product Requirement Document】给开发者

 

BRD的具体写法：

项目背景：

商业价值：

功能需求描述：功能列表；业务逻辑关系图；简单demo更好;比如故意加一些让老板砍的需求，希望老板不要过度砍我们真正想做的东西。

非功能需求描述：

资源评估：

风险和对策：

 

BRD的目的本质上是让老板思考产品的性价比。

给这次BRD，起一个有意义的名字，配上一副有价值的图，比如魔方计划，彩色魔方图，xxxx事业部   苏杰，有助于团队归属感。

 

【读到这里突然发现对产品经理存在很多误解和偏见，在以往的开发怼产品以及开发和产品干架的理由里，往往以为产品是不懂技术的SB、谁都可以做的、胡乱提需求的、没价值的玩意，但是没有产品，我想老板直接跟开发者沟通将是极端糟糕的体验，不专业的人指挥肯定做出很糟糕的产品；然而目前觉得资深开发转产品，剑开两面，将非常锋利无比。】

 

【少做就是多做】

功能模块虽然只有一两个，但是拥有100%的质量这样留给用户是升级的等待；如果模块功能很多，又是鸡肋，每个都不爽，反而喧宾夺主，自己葬送闪光点，过多消费了用户的注意力和好奇心；对于开发来讲也要遵循这样的原则

 

【四两拨千斤：做得少不如做的巧】

案例：检测空肥皂盒，放台电风扇

我们用不着觉的吃苦耐劳做了很多事情才是贡献，而应该直接从目的出发。内部（技术）的大改动往往是外部（商业）的小改动，在动手之前，应该找找 有没有成本低和收效大的解决方案。

 

【尽可能多的放弃】

看到事物全貌才能孰轻孰重的放弃。

如果不放弃，最终会被需求折腾死。

 

三  项目和产品的区别 

1 项目周期短；产品周期长

2 项目是一项确定的任务；产品需要不断探索和不断修正

3 项目只进行一次；产品可以批量生产

 

案例：裁缝接了做一件衣服，做好一手交钱一手交货，项目结项；裁缝是设计师，设计一款服装，流向市场

 

很多外包作坊喟叹：做项目太累，什么时候才能做产品啊！

产品是项目的实现，但并不是简单累加，两者分不开。

本质上都是通过迭代安排的项目来实现产品的规划。

 

产品经理 VS 项目经理

1 产品靠想，判断力和创造力；项目靠做，执行力与控制力

2 产品内部驱动；项目外部驱动

3 产品侧重用户体验——开发要额外的做很多细节的工作—比如登陆框的优化；项目侧重从开发角度看问题，尽量少做，做自己熟悉的，bug要少，可能会商业价值不足，用户体验不好。

 

两者互补，要想系统化，必须正反合

 

Kick Off:足球比赛开球的意思，引申为项目启动，立项

 

产品经理没有行政上的管理权

产品经理新人不适合做项目经理，通常要混到脸熟，这不单单是个人能力问题

项目经理会根据开发工程师的能力特点、擅长领域等因素因事择人，把开发任务分配给最合适的人。

 

开发工程师自己评估：工作量 = （最乐观+最悲观+最可能）/3

或者 工作量 = （最乐观+最悲观+最可能*4）/6

 

1人天通常按照5小时算，每个人很难保证持续高效，没人打搅，5个小时算不错了

 

根据开发工作量来推算工期（开发和项目经理交互的地方）

工期 = 不存在依赖关系的工作量 + 开发中关键障碍是否延时 + 周例会 + 评审会 + 线上故障处理时间（有的深bug有时候甚至需要一天才能找到）  

 

任务相对独立则可以更多的并行

如果任务互相依赖的严重，就只能串行

 

长期加班对打击士气很大

 

日常项目的资源瓶颈一般在开发阶段

根据工期，确定项目的几个里程碑即监控点，开发结束，测试结束，发布上线

 

沟通方式：

项目晨会；项目日报（测试日报）；评审会；项目变更申请；发布预告；

 

痛不欲生的需求文档：

BRD【Business Requirement Document】给老板

MRD【Market Requirement Document】给老板

PRD【Product Requirement Document】给开发者

FSD 【Functional Specifications Document】给开发者，功能详细说明

UML图：时序图，活动图，协作图等;

Demo产品演示版本：

原型设计工具：visio，ppt,word,Axure….

(产品在不同阶段用到的工具不同，但是对于开发和产品的工具，心中有剑，手上拿树枝也能杀人！)

 

开发者根据产品需求和功能详细说明，开始详细设计代码

比如数据库设计和根据数据量和可扩展性进行代码写法设计

 

商业评审：项目继续，重新定向，项目终止

技术评审：项目继续，有风险的继续，必须解决某问题之后继续

 

需求评审【治之于未有】：不做需求评审，看似节省时间，其实隐藏了很多问题，等到问题发现会耽误更多事。

比如业务规则不合理；产品界面丑陋；功能技术上无法实现；

参与对象：老板，营销，服务人员，用户，开发，测试等，

此时产品经理的需求任务暂时结束

 

设计评审【治之于未有】：在概要设计和详细设计，由开发工程师把对需求的理解以设计文档的形式说给产品经理和产品主管以及测试听！！！！！！！这就是开发对需求的反馈了，这个时候开发者对需求的理解能力，对数据库和站点的架构设计能力就很重要了，只会闷闷的写代码就不OK了。严格来讲，我相信，一般开发者都只是随便设计一下就够用，然而在架构师面前应该是无所遁形。

 

测试评审：测试工程师把对需求的理解讲给产品经理和开发工程师。

 

评审会上参与千万不可以漏掉产品接口人和能做决定的人。

 

开发——设计——设计评审——Coding——单元测试——组件测试——系统测试——自动化测试

 

强大的工程师【开发经理/架构师/系统分析师】会带着普通工程师做概要设计和详细设计，项目涉及数据库和硬件系统改动就要带上运维人员；审核开发者对需求的理解是否正确。

 

编码阶段：代码评审，这是程序员自觉的提高自我修养的过程。

 

开发自测阶段：单元测试。开发自测是开发者的本分之一。

 

一起上，测试阶段：测试者会编写测试方案并不断调整测试方案、方法、技术和策略。内容包含测试目标，测试环境，输入数据，测试步骤，预期结果，测试脚本，形成文档。

 

 

 

 

【这本书虽然关于产品的，但是对于开发者我觉得应该是必读的，开发者养成产品意识有助于促进性能代码；这本书的整体正规流程对于小公司可能过于繁琐，但是对于开发者自己写出清晰的设计文档和开发文档是整体的，往往开发者只是写开发文档，设计文档的编写有助于高屋建瓴的把握整体，完善于程序员自身；本章虽然写的是需求的一生，其实是整个项目的一生，理解其他相关合作者的工作任务，有助于提高工作效率。】

 

那一夜，项目发布，灰度发布和测试

 

发布和部署标准：

1  数据库通过dba确认没问题

2 搜索引擎通过相关人员确认没问题

3 bug库中全部 Closed 或者 Deferred

4 因技术原因造成无法修改bug已经处理好

5 某些没有实现的需求通知到位

6  测试人员在生产环境中回归测试，通知生产环境验证成功，发布成功，全部撤离

 

【项目经理】

发布后，一般凌晨，相关人员别忘了给大家买夜宵。作为项目经理，要发一封邮件-项目发布公告，如果意义重大，就要写的很煽情，比如项目中的种种艰辛（项目过程中积累），对每个参与者的感谢，发布之后的内心感言，产品对公司和用户的革命性意义，贴几张产品的最新图片（经过设计师p图的）甚至公司墙上也贴几张。作为项目经理，应该时刻做到为团队成员争取各种精神、物质的奖励，这种邮件、海报、大老板的回信都是很好的鼓励。如果还有项目经费，组织一次聚餐，开开心心继续合作。

 

 

【让我想起了杭州工作时公司的，因为有相似的情节，有项目经费，做完了就大吃一顿，因为团队非常融洽，每次都很开心；而且下午茶也会让人开心的工作，活力要比没有下午茶的公司氛围好很多，个人觉得】

 

项目小结：比较合适在发布会半个月内完成

碰到了哪些问题；原因是什么；怎么解决的 ；如何避免再犯；

资源评估是否合理；收获了哪些经验；如何提高准确度；商业目的是否达到；

 

 

【看到这块就知道如果开发自身不能独立胜任是有多恐怖了！！！给上面的人留下不好的印象就尴尬了。开发能力不足要及时反省，学习。】

 

注意：保持写日志和周记的习惯。

怕什么来什么，只能拥抱变化

 

项目管理中的及格关键问题：

文档管理：

流程管理：流程要反复做，追求最优解！比如奇瑞汽车有300个评审点。流程化规范化便于交接。

敏捷方法: 敏捷沟通，即时通讯群；晨会；项目日报；项目白板贴便签；项目墙（整个项目的时间轴，团队里程碑，可视化文档）；

 

外包项目不适合敏捷开发？

1 甲方不想砍需求。反正乙方干活，就要多占便宜。公司内部需求往往可以砍，保质不保量。乙方往往保量不保质。

2 甲方验收测试困难。内部可以充分交流但是外包交流困难，验收有考试性质，不允许乙方开发参与，甲方会考虑很多乙方根本没有考虑到的问题。

3 乙方缺乏敏捷开发经验，习惯按照详细设计文档做开发测试，抗拒需求改变。

 

任何情况下，都要做好手头的事情，确保对自己有所收获。

四：团队

偶尔为之的事情需要可行解，经常做的事情要追求最优解。

老板是最好的资源。

大家好才是真的好。

五：别让灵魂跟不上脚步

触及产品的灵魂

达摩克利斯之剑————————KPI

以请教的口吻找高手解惑

六：产品经理的自我修养

1 爱生活，才会爱产品

爱生活------------人生的动力引擎

时刻微笑；永远保持好奇心；乐天；快乐；爱合适的人；

多去不同餐厅吃饭；多旅游；

热爱生活的人时刻充满激情、能量和创意。

 

2 有理想，就不会变咸鱼

理想--------------我们往什么目标和方向去

成功在自己手中。

有明确理想的人，会过的很开心，会获得内心的安宁。

理想可大可小可以变，不过最好别乱变，乱变不利于实现，因为实现需要很多的积累。

要做一个有自己内心认可理想的、内在自我驱动的有理想的人。想做，要做，能做。

理想本质是不断提升自己的能力。

 

自己不成长，公司无法享受到我技术的附加值；

公司不成长，自己无法享受公司福利的附加值；

 

3 会思考，活到老学到老

思考——————————掌握方法

大学没有教育的东西

第一：教知识不教思维

第二：教解题不教选题

第三：教努力不教取巧

第四：教受教不教施教

 

4 能沟通，在什么山头唱什么歌

沟通——————————————团结共进

充分沟通是不存在的。

沟通是为了更好的认识世界，不是为了说服。

 

5 产品经理主义

无论你是男是女，是老是少，是上学还是工作，是否负责某个公司的产品

 

你至少是自己的产品经理，在设计’自己的一生’，想逃都逃不掉。

 

一个人真正成熟的标志之一，就是心中可以容纳互相矛盾的观点而无碍行事。