1、人人都是产品经理,读书报告,这本书怎么来,阿里巴巴宽松的文化、分享的氛围是这本书诞生的土壤这本书和我的博客是分不开的，是一个产品的两种表现形式。一个工作仅仅4 年的新人的每周周报的总结,这个人就是PM,是谁？每次K 歌都对着点歌面板评头论足。是谁？逛超市时总在想“这个商品能解决什么需求？”是谁？会给自己的个人发展做战略规划。是谁？一定要在自己的婚礼中讲一个PPT。是谁？会拿用户调研的方法与亲朋好友交流。是谁？装修房子的时候抢着当项目经理。是谁？看电视广告总想在几十秒中提炼出三大卖点。是谁？会给自己的孩子设计各种“功能点”。是谁？访问任何网站都能一下子挑出好几个Bug。.,1 写给一到三岁的PM
2、,产品究竟是什么？ 就是用来解决某个问题的东西。 解决用户的问题和公司的问题。,产品这个东西，可以是有形的实物，也可以是无形的服务，多种多样。我们工作中所做的产品，绝大多数都是在人们的需求，即用户目标和公司的商业目标之间寻找平衡。只考虑用户，公司无法盈利，必然死掉；只考虑商业，光想着公司得好处，用户留不住，公司也会死掉。,产品经理职责,“产品规划、数据分析、用户研究、需求分析、功能设计、项目管理、敏捷方法”,规划产品的生命周期，负责产品的上市策略、定价策略、整合营销策略、销售与分销策略,其实每个人都是产品经理,因为你已经在做： 第一，信息不足以决策； 第二，时间不足以安排周密的计划； 第三，人
3、员不足以支持工作强度和难度；第四，资金不足以自由调配,PM岗位要求,2 一个需求的奋斗史,需求采集的过程，都会有如下几步：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。,用户访谈常见问题,第一，“说”和“做”不一致的问题。 用户倒不是想故意欺骗我们，而可能是：他们被问了自己也没仔细想过的问题，又不想回答不知道第二，样本少，以偏概全的问题。第三，用户过于强势，把我们往沟里带。第四，我们过于强势，把用户往沟里带。,需求采集人人有责,需求采集卡,听用户的但不要照着做,用户跟福特要一匹更快的马，福特却给了用户一辆车。,用户需求：用户自以为的需求，并且经常表达为
4、用户的解决方案。产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。,满足需求的三种方式：改变现状、降低理想、转移需求,Feature List（功能列表）,准备出发：把需求打个包,我们已经做了需求采集，把用户需求转化为产品需求，知道了某个需求的基本属性、种类、商业价值、开发量，现在似乎应该开始写文档、干活了，但经验告诉我们不是这样的：绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度大就不做。,第一，“需求打包”最好打包类似的功能点。第二，需求依赖，功能互相之间有依赖关系
5、。那些只能先做的功能，应该在产品需求列表里注明；功能与人力资源之间的依赖关系也会经常存在，比如有些功能只能由团队里的特定成员来做。第三，需求的粒度大小问题。,战场：产品会议武器：商业需求文档,BRD怎么写,包含哪些内容:项目背景商业价值，功能需求描述，非功能需求描述，资源评估，风险和对策，,少做就是多做,宁肯把一半的功能做的完美也不能把全部功能做成半吊子。尽可能多的放弃。,比如，一个最简单的“评论”功能：既然可以发评论，那么是不是需要改评论？删评论？发的权限是否要管理员设置？那么改的权限呢？删的权限呢？是否可以引用别人的评论？评论被人引用了是否可以再改？如果可以改那么是不是要保留修改记录？如果
6、管理员改了一个评论那么作者是不是不能再改？评论是否要有数量和时间限制？评论要不要翻页？如果要翻页是在本页翻还是打开新页？评论能不能带图片？带了图片那么是不是能上传？能上传之后是不是要删除？是不是要提供自定义评论排序？是不是要xx？是不是 xx？xx？,3 项目的坎坷一生,KO大会后做项目,青春期，又见需求,写文档，写得痛不欲生 要写哪些：BRD（给老大看，要资源，短小精炼，没产品细节）、MRD（要到资源后，市场竞争对手，功能及优先级，商业目的，产物Feature List，业务逻辑图）、PRD（对功能细化，需求开发过程，包括整体说明、用例文档、demo）、FSD（功能详细说明，像用例文档，常包
7、含在PRD中，产品界面、业务逻辑细节，左中右对齐，小数位数。同时，硬件系统、数据库设计表结构设计也由架构师编写） 通常前两个一起写，后两个一起，给技术看,PRD,用例文档-1,整体说明,用例文档-2,单个UC 首先是UC概述：1用例的唯一标识如UC_ordermeal 2、用例名称：点菜 3、业务描述：商业目标，用户目的，为什么要做这个uc 4、需求描述：产品需求，需要实现哪些功能点，这个uc要做什么，去餐厅，点个菜，吃掉。 5、行为者：小明 6、前置条件：小明有空去餐厅 7、后置条件：服务员接受订单去厨房 8、其他说明 其次是UC主体：1、界面描述：截图，界面上各种元素的说明，demo关联。 2、业务规则：用例中的通用规则如小明不吃辣 3、流程描述：主干和分支、异常，描述过程，触发、交互，用时序图、活动图,单个UC,UC主体,pd文档模版,项目的坎坷一生,建议,些Excel 的简单技巧，建议大家还是学习一下，比如条件格式、筛选、单元格有效性、单元格锁定、隐藏等，可以让表格管理起来轻松一点，看起来也美观一点。学一点UML：规范化，提供了一系列的标准图形化的表达方式，把需求开发的过程串起来。（字不如表，表不如图）,
