《人人都是产品经理》的读书笔记.docx

人人都是产品经理的读书笔记1.写给-1到3岁的产品经理 1.1为什么要做产品经理-世界需要 Tips：好的产品不需要用户思考 例子A：路牌标识不明 例子B：Z字形的好看盲道为盲人增加行走障碍 => 花哨的视觉效果不一定好 例子C：回收、不可回收垃圾桶的区别：无标识的垃圾桶 -> 有标识的垃圾桶 -> 写明什么东西可回收什么东西不可回收的垃圾桶 例子D：宏伟得像会议室、无标识、带门把手让人不知道是推是拉的厕所门 VS 简洁的、带标识、无把手必然是推的厕所门 1.2我们到底是不是产品经理 产品是同时解决用户问题和公司问题。 一个对比： 传统意义下的产品经理偏重于产品已经做好以后，怎样管理、销售，偏重于市场、商业端 软件行业的产品经理偏重于产品“从无到有，从有到优”的过程 差异的原因，导致对产品经理的要求： 原因A：传统行业较成熟，创新小，用户习惯难改变 VS 软件行业是新兴行业，要创新，占领用户并主导用户习惯 => 要求产品功能本身的规划 原因B：传统行业的产品为实物，需要打通供应链 VS 软件行业的产品为虚拟物品，复制成本低，较少考虑供应链，一个细节改进可以增加千万用户 =>要求细节 原因C：传统产业产品生命周期几年 VS 软件行业产品生命周期几个月 => 项目过程不复杂，要求兼顾项目管理 原因D：传统行业靠产品本身价值赚钱，买产品的人未必用 VS 软件产品大多免费，盈利模式多元，直接面对海量终端用户 => 要求用户研究、数据分析 原因E：传统产品用户花钱买，不爽凑合着用 VS 软件产品用户免费买，不爽换同类产品 => 要求重视用户体验 非典型产品经理，不需要全能 现在产品经理的三大变化方向：产品管理团队、事业单位经理的任用、更专业取向 在一线员工眼中，管理是在资源不足的情况下把事情做成的能力。通常表现为： 信息不足以决策；时间不足以安排周密的计划；人员不足以支持工作强度和难度；资源不足以自由调配。 1.3我真的想做，怎么入行 做产品的大前提是喜欢做产品，同时是喜欢做产品经理而不是喜欢做用户。 例子：对于某游戏，用户想我怎么玩可以赢更多的钱，产品经理想为什么这么设计。 对于应届生，面试官最看重的是有没有激情，是否机灵好学，逻辑思维是否清晰，沟通是否流畅。其他(比如对行业的熟悉)会次要。 对于工作几年的人，不管以前是做什么的，都可以转行做产品经理。建议先在本质工作上找到产品有关的事情做些尝试，并且考虑从产品经理周边的职位做起。 例子：原来做开发的,利用参与需求评审的机会，多思考，对需求提出合理建议。以后做产品经理，可以从“需求分析师”切入。 1.4一个产品经理的-1到3岁 作者本身学生物 入行头半年，打杂：不负责产品的任何模块，写框架已被别人搭好了的需求文档，但他好学，主动熟悉工作中的技能。 入行半年后，学习“怎么做”：以product designer的身份负责网店版的某些模块，决定某个功能怎么做，比如写需求文档，配合做demo，跟进开发、测试、发布的过程。但是很看重自己负责的模块，缺乏整个产品层面的权衡认识。 入行一年，开始问“做不做，做多少”：在完全掌控需求采集、分析、筛选的过程中学会权衡取舍，砍功能也下得了手。 入行两年，项目与团队：新项目企业邮局，学习到除产品需求以外的东西，比如项目管理、流畅、敏捷方法。体验到操心的感觉，从接受别人的会议邀请，到给别人发会议邀请；从有事才去找人帮忙，到尽量去了解周边团队在做啥，并施加影响；从一个人做事，到做好自己本职工作，其他交给团队，再到主动定规范，把工作分出去。 入行三年小结，战略与修养：参与产品的可行性研究；思考产品经理的基本修养：爱生活，有理想，会思考，能沟通；立志做老师，完成“三个一工程”：一个网站，一门课程，一本图书 Tips:公司想做的产品很多，要从中挑出值得实施的，果断放弃很重要，放弃的原则与价值观、战略有关 2.一个需求的奋斗史 Tips:相比较“接到一个任务，然后把它完成”，对于产品经理，更重要的是“发现一个问题，然后设法把其转化为一个任务来解决”。 2.1从用户中来到用户中去 2.1.1用户是需求之源 人的需求，根据马斯洛的需求层次理论，可划分为五个层次，由低到高，分别是：生理需求、安全需求、社交需求、尊重需求、自我实现需求。 产生需求的原因是：生活中存在“理想与现实的差距”，人类很自然地产生“减少甚至消除这个差距”的愿望。 通过研究需求，可以增强对用户的理解。理解用户，是产品经理的重要素质之一。 例子：小明要电钻 -> 要在墙上打洞 -> 要挂上画 -> 屋子太空旷，不温馨 => 安全需求和社交需求 用户与客户的区别：用户，也叫终端用户，是使用产品的人；客户是购买产品的人。 相对于客户的需求，我们更重视您的用户的需求 => 用户是需求之源。 UCD，以用户为中心的设计 UBD，以老板为中心的设计，适用于没太多精力做用户研究、公司老板最了解用户且能抓住商机的创业小团队。 试图满足所有用户的需求是一个灾难，会让产品变成一个臃肿不堪、谁都不满意的四不像。 我们应该优先照顾其中一部分用户的需求。这种优先要考虑到产品的商业目标。 例如：对于已经成熟且拥有市场霸主地位的产品，比如qq，应关注核心用户的需求；对于刚刚起步的产品，先满足大量的一般用户的需求。 2.1.2你真的了解用户么？ 许多用户对所有产品了解甚少。 先描述自己，创建人物角色persona是一种快速描述用户的方法。persona的内容包括：职业、预算、爱好、性格、行业信息、计算机和互联网使用情况、用户目标、商业目标 用户研究方法可用一张二维图表示：横向是用户的说和做。“眼见为实耳听为虚”，看到用户怎么做比听他们怎么说更真实，但只了解怎么做是不知道背后原因的。纵向是定性与定量。定性研究偏向于找出原因，定量研究偏向于证实。 做用户调查的目标是：坚决杜绝“经组织决定，用户需要一个xx功能”，要是实在在地把用户当做需求之源。 2.2需求采集的大生产运动 要根据资源多少采用合适的用户研究方法。若资源少，查二手资料后和同事讨论，猜测用户怎么想怎么做。 需求采集有以下步骤：明确目标 -> 选择采集方法 -> 制定采集计划 -> 执行采集 -> 资料整理 -> 下一步的需求分析 2.2.1定性地说：用户访谈 用户访谈的常见问题： 1.说与做不一致。 例子：索尼做用户调查，发现用户更喜欢黄色游戏机。当索尼让他们随意挑选游戏机时，更多用户挑的是黑色游戏机。 对策：让用户可以和产品交互的情况下访谈；要区分用户说的事实与观点。“我做了啥，遇到啥问题”这种事实比“我认为”这种观点可信度高。 2.样本少，以偏概全 例子：只找本市的用户，优先拨打留了手机的用户，愿意来公司做访谈的用户 对策：在访谈报告中注明可能引起偏差的因素；增量访谈，即先少量调查，若结论有变，再加大样本量 3.用户过于强势，把我们往沟里带 例子：漫无目的地侃 对策：；牢记访谈目的，若话题不对，赶紧往正道上掰 4.我们过于强势，把用户往沟里带 例子：在访谈时指出用户哪里理解不对，说自己产品多么好 对策：牢记访谈目的，管好自己的嘴 Tips:避免固定问题；更关注为什么，而不是怎么做；听用户说但不要照着做；避免讨论技术；鼓励讲故事；避免诱导性问题(如果有xx功能，你会使用么？) 例子：记一次用户大会的提纲 明确目的：比如产品卖点确认，需求收集，用户体验改进。这样在争取开用户大会的资源时有说服力 资源确定：时间、地点、人物、材料、备用方案 现场执行：辅助工作、主流程 结束以后：资料整理、运营宣传 2.2.2定量地说：调查问卷 调查问卷可以挖掘出用户中大多数的沉默与骑墙一派，并且他们还是典型用户。 调查问卷与用户访谈的区别：前者是封闭式问题，后者是开放式问题 Tips:作答时间不超过10分钟；问题顺序：简单问题 -> 需要思考的、敏感的问题 -> 被访者个人信息 调查问卷的常见问题： 1.样本偏差 对策：尽可能覆盖目标群体中的各种类型的用户，比如性别、年龄、行业、收入，并保证这个比例接近全体比例；若无法做到样本合理性，在调查报告中要注明潜在的筛选条件。 2.样本过少 对策：若样本个数少于100，列出人数，而不是百分比 3.问卷内容的细节问题 对策：问题表述应无引导性，问“你是否喜欢某个产品”而不是“你喜欢某个产品吗”；准备几种形式的问卷，减少答案的顺序偏差；先小规模试答，反馈修改后再大面积投放。 例子：记这本书的实际问卷 问卷目的：收集读者反馈 样本对象：本书读者、博客读者、对产品经理感兴趣的人 调查渠道：网站、博客 时间计划：收集3个月 问卷内容：简单问题 -> 需要思考的、敏感的问题 -> 被访者个人信息 2.2.3定性地做：可用性测试 步骤：招募测试用户 -> 准备测试任务 -> 测试过程，组织者应观察并记录 -> 询问用户的主观看法 -> 研究分析 可用性测试的常见问题： 1.做得太晚，发现问题也于事无补了。 对策：在产品的各个阶段都做可用性测试。对于无任何成型的产品，拿竞争对手的产品给用户做；对于只有纸面原型的产品，拿手绘的产品给用户做。 2.觉得可用性测试太麻烦，干脆不做 对策：只做一个用户，并简化步骤，也比不做好 3.明确是测试产品，而不是测试用户 对策：不要用“可用性测试”的术语，而是说“来试用我们的新产品，提点意见”，减轻用户压力 4.测试过程中，组织者该做和不该做的 该做的：告诉用户持续时间，做哪些事情；让用户在使用产品时说出自己的思考过程；送个小礼品 不该做的：引导与暗示 例子：产品改版的一次冒险 可用性测试做得太晚，想想后怕 Tips：对于改版，要和平演变，而不是暴力革命，要让用户逐渐适应：从部分分级页面改起；新旧版本并存；小面积实验；傍上用户已经习惯的风格 2.2.4定量地做：数据分析 关键的是对数据的解读，数据分析只能发现现象，并不能了解原因。所以数据分析常伴随用户访谈。 数据分析的常见问题： 1.过于学术，沉迷于“科学研究” 对策：重视综合性价比，不需要“显著性检验”，要的是对数据的敏感。 2.虽然数据不会主动骗人，但我们经常无意或有意地误读数据 对策：对于无意误读，学习统计学只是；对于主动误读，保持中立态度 3.平时不烧香，临时抱佛脚 对策：在产品设计时就把数据分析的需求加进去，比如统计每个按钮的点击次数。 日志分析的商业价值 例子：分析登陆次数 在对产品熟悉的基础上，做方向性假设。这里假设有方法使某类用户更多地登录 ->提取相应数据并分析,得到一些现象，最好是之前没发现的现象。这里做一张二维图，横轴时间，纵轴活跃情况。趋势可分为四个阶段。 ->尝试解释。这里发现可分为两类登录：经销商登录和用户登录 ->用户调研修正解释。这里是电话调研+登门拜访，发现有两个入口的登录。 ->指导产品的发展方向。这里的商业价值在于：1）考核每个经销商下面的用户活跃度，来让他们更好地服务用户；2）有实际意义的是用户入口的登录，因此产品优化的重点应在用户入口 2.2.5需求采集人人有责 从用户那里直接得到的需求，是一手需求；老板或销售人员的需求，是二手需求。 在新产品诞生前，没有用户、运营、销售时，要主动地去潜在的目标用户那里采集需求；产品运行一段时间后，用户和相关工作人员都有了，与用户的直接接触变少，但会收到中间的工作人员反馈的需求和用户提的需求。 销售人员有时只重视眼前利益，提的需求不一定好，一手需求很重要。 二手需求的理解偏差可以用单项需求卡片这个工具来弥补。 需求分析卡片的理念是：产品的需求工作不只是需求分析人员的事，而是涉及产品的每个干系人的义务，至少得参与“采集”的过程。 一个需求分析卡片，至少得有需求编号、需求描述、来源、场景 尽可能多地采集需求的一些方法：现场调查，和客户一起工作；AB测试，小规模地测试A和B的情况；日记研究；卡片分类法，把需求写在便利贴上，观察用户怎么给产品划分模块；粉丝用户主动提需求 2.3听用户的但不要照着做 对于用户提的解决方案仅仅站在自己立场上考虑，对于用户提的存在明显逻辑矛盾的需求，要谨慎考虑。 2.3.1明确我们存在的价值 需求分析要做的是把用户需求转化为产品需求。 例子A：用户向福特要一匹快马，福特给了一辆车 例子B：对于“小明要电钻 -> 要在墙上打洞 -> 要挂上画 -> 屋子太空旷，不温馨 => 安全需求和社交需求”，我们可以给电钻+油画，也可以油画+强力胶，或者摆个书架，可能更省钱也更温馨。 用户需求 VS 产品需求 用户需求：用户自以为的需求，并且经常表达为用户的解决方案 产品需求：经过我们分析，找到的真实需求，并且表达为产品的解决方案。 需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。 需求分析是“首先：树叶-树枝-树干，其次：树干-树枝-树叶”的分析过程，既不能漏掉提炼用户需求的过程，透过需求看本质，也要让树干分解掉，好让执行人员知道要做什么东西。 这是短期利益与长期利益的权衡，只满足用户需求是短期利益，但为了长期需求，我们要找到用户的真实需求。 满足需求的三种方式 改变现状：开发某个产品，最常用也最笨的方法。 降低理想：“丑话说在前头” 转移需求：寻找更强烈的需求展现给用户，让他不纠结于原来的需求。 例子：电梯不够用 改变现状：增加电梯个数 降低理想：告诉用户，隔壁那个楼等的时间更长 转移需求：鼓励用户爬楼梯锻炼身体；电梯门口装镜子让等的人搔首弄姿不至于无聊 也谈创造需求 基于用户、产品、市场的充分理解的突发奇想有的会得到用户认可，但更多的是天马行空。 作为新人，先做用户提出的需求，而不要胡乱分析用户需求。 2.3.2给需求做一次DNA检测 需求DNA检测过程：需求转化 -> 确定基本属性 -> 分析商业价值 -> 初评实现难度 -> 计算性价比 需求转化 采集单项需求卡片 -> 头脑风暴 -> 每人分一块，转化为产品需求 -> 整理记录成产品需求列表 用户需求与产品需求是多对多的关系 过滤掉不靠谱的用户需求 例子：对于用户需求“删除之前需要确认”，产品需求可能是“数据回收站：删除的数据进入回收站。若误删，可以去回收站找回数据。” 确定需求的基本属性 这些基本属性包括：编号、提交人、提交时间、模块、名称、描述、提出者、提出时间、Bug编号 需求种类知多少 需求按分类分，可分为：新增功能、功能改进、体验提升、Bug修复、内部需求 产品功能需求+产品非功能需求=产品需求 产品需求+市场需求+开发需求+测试需求+服务需求+.=产品包需求 需求按层次分，可分为：基础、扩展、增值 雪中送炭要好于锦上添花 分析需求的商业价值 商业价值可用重要性、紧急性、持续时间来衡量。 这是需求列表中的最核心部分，甚至在列表中再增加一条“商业价值描述”，即卖点，说明对用户和公司会提供什么价值 对于商业价值，要在需求讨论会产品团队集体讨论，叫上干系人，比如销售、服务等 初评需求的实现难度 把技术人员代表拉进来参加讨论会，甚至让他们先自行讨论后再决定。 不考虑硬件成本，再加上在产品、开发、测试、服务中开发资源是瓶颈，开发量成为实现难度的指标。 由于需求未定，先做允许误差大的初评，在项目启动后再做更精确的评估。 性价比 性价比=商业价值/实现难度 在实际中，多跟工程师接触，实现难度会定得偏高，多跟销售运营的人开会，商业价值会定得偏高。 例子：对于Firefox的网页显示问题，虽然很好解决，但是用的人极少，所以商业价值极低，导致这个需求性价比低。 2.4活下来的永远是少数 需求筛选的过程：需求打包 -> BRD制作 -> 产品会议 -> . -> 立项 2.4.1永远忘不掉的那场战争 以前没有战争的原因：以前公司按产品线划分部门，对于某产品，有自己的产品设计师、开发与测试人员。 现在有战争的原因：现在公司按职能划分团队，每个产品由原来的产品人员做，但是开发与测试人员是流动的，各个产品团队要竞争人力资源。 准备出发：给需求打个包 做项目的终极目标是：多快好省，即范围大、时间短、品质高、资源省。需要在这4个因素中做平衡。 在产品需求列表上，按性价比大小，对每一行需求的工作量相加，看能做多少，这就是需求打包。 需要注意的几点： 1.需求打包最好打包类似的功能点 2.需求依赖，功能互相之间有依赖关系；功能与人力资源之间有依赖关系，比如某功能只能由特定的人做 3.需求的粒度大小问题。细化粒度，发现需求中价值相对低的部分，对于需求列表里的每一行，工作量最好不超过5人天 战场：产品会议 参会人员：各个部门的老板、各个产品的产品经理和设计师 时间：一个月一次甚至更长 过程：回顾上一次产品会议通过的项目进展如何 -> 用商业需求文档争取资源 武器：商业需求文档 BRD：Business Requirement Document，商业需求文档 MRD： Marketing Requirement Document,，市场需求文档 PRD：Product Requirement Document，产品需求文档 BRD包括的内容：项目背景、商业价值、功能需求描述、非功能需求描述、资源评估、风险和对策 2.4.2别灰心，少做就是多做 例子：“自动上架”需求的确定，一开始只是雏形，但越讨论加的功能越多，接着因为资源限制的原因，加的功能一个个砍掉，最后发现和最初方案是一样的。这是一个“见山是山，见山不是山，见山还是山”的过程。 情愿吧一半的功能做到尽可能完美，也不要把全部功能都做成半吊子。 最爽就是“四两拨千斤” 例子：肥皂生产时有漏包问题，请了一堆专家解决，最后拿着电扇对着生产线末端吹，把控肥皂盒吹掉。 技术上的大改动往往是商业上的小改动。 尽可能多地放弃 例如：对于“评论”功能，若不放弃一些需求，要被自己折腾死。这些需求比如：“考虑评论翻页”、“考虑评论带图片”、“考虑被人引用后可否修改”。 有资源空出来，去做意义更大的功能或产品。 2.5心急吃不了热豆腐 一个需求的生老病死 1.需求采集，转2 2.待讨论，转3 3.需求讨论会，若暂缓，转6，若通过，则进入需求打包，转4，否则拒绝 4.需求打包通过的，转产品会议5，若不通过，转暂缓6 5.产品会议通过的，转开发，若不通过，转暂缓6 6.暂缓状态，满足重启条件后，转2 需求管理的附加值 统计每个“提交人”的需求数量=>某个人的工作情况 统计“提交时间”、“发布时间”=>产品发展是增速还是减速 统计每个模块的需求数量=>用户对哪些模块感兴趣 统计每个分类的需求数量=>产品是在成长期还是成熟期 统计需求的商业价值、性价比变化=>看产品的发展空间有多大 有一些专业的需求管理方法和工具，比如Rational RequisitePro 和需求一起奋斗 产品经理的重要素质之一-热爱产品 3.项目的坎坷一生 3.1从产品到项目 做产品 VS 做项目 1.做产品时间周期长，从规划到制造到维护，没法确定合适结束；做项目时间周期短，有明确的起始和结束时间。 2.做产品要不断修正判断，给出创新；做项目目标明确，像执行任务 3.产品面向大量的通用用户；项目相对个性化 例子A：找裁缝给自己做件衣服，是做项目，裁缝的设计被服装厂拿去生产，是做产品 例子B：某网站在国庆前要做一个专题，是做项目；新闻频道持续更新，是做产品 做产品的过程，是通过一个又一个项目实现的 产品经理VS项目经理 产品经理靠想，做正确的事，看其所领导的产品是否符合市场需要，是否能给公司带来利润，内部驱动，最重要的是判断力与创造力。 项目经理靠做，把事情做正确，在时间、成本和资源约束的条件下完成目标，外部驱动，最重要的是执行力与控制力。 为什么让产品经理管项目 让项目经理管项目，他们会倾向于简化项目，尽量少做，但做出来的东西商业价值不足，用户体验不好。 让产品经理管项目，关于导致不断加需求导致项目无法按期完成，影响团队士气。 要有个平衡。 3.2一切从kick off开始 立项过程：需求筛选 -> 立项 帅哥美女，我们需要你 产品经理没有行政上的管理权，要向不同团队的主管要人 PD新人不适合做项目经理，因为和团队没混熟，沟通会不顺畅 项目督导委员会由项目成员的老板组成，他们负责承担责任，以及提供资源。下面是项目经理。项目经理下面是PD、开发经理、测试经理、UE、服务团队 别忘了最初的约定 立项阶段的项目计划，要再次评估工作量并推算出工期，除了更准确，还要考虑谁来做。 估算的工作量=/6 按每人工作5-6小时算，留出余量时间，还要考虑任务间的依赖关系，尽量不加班。 沟通从头开始 常用沟通方法：项目晨会、项目日报、评审会、项目变更申请、发布预告及公告 不可或缺的誓师大会 15分钟的kiff off传达的内容包括： BRD里的项目背景；项目意义目的目标；需求、功能点概述； 项目组织架构； 项目计划； 约定沟通计划 任何时候都要心里有“树” 做项目的本质是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡 WBS：Working Breakdown Structure，工作分解结构 可套用WBS模板来方便项目管理。WBS模板像一棵树，比如 -产品模块级项目 -项目准备 -过程管理 -立项 -时间计划 -项目总结 -心得体会 -数据分析报告 -需求 -实施 -测试 -服务 3.3关键的青春期，又见需求 新人可以先做一些执行层面的任务来熟悉产品和团队。可以写文档来练手。 3.3.1真的要写很多文档 BRD、MRD是写给老板看的 PRD、FSD，是写给技术人员看的 产品需求文档,PRD PRD的模板目录： 1）总体说明 1.1）修订历史 1.2）项目概述，参考kick off 1.3）功能范围，给出业务逻辑图，角色职责、与周边系统的关系，全局商业规则 1.4）用户范围 1.5）词汇表 1.6）非功能需求，如性能需求、数据监控的需求 1.7）其他说明 2）UC部分 包括视觉层面的描述,界面细节，交互细节，文案细节 学一点UML：类图、用例图、状态图 略 用例文档：UC 略 再学点UML：时序图、活动图及其他 略 Demo也要我们做么 Demo最好由UE部门的人做，也就是美工。 Demo会经历从抽象到具体的过程：纸面demo -> 线框图(用word,PPT,visio) -> 视觉效果图 概要设计与详细设计 1.不以写的东西是需求还是设计区分，而以业务或技术区分。例如，某编辑框长度由PD确定，但如何在数据库中存储由工程师决定 2.细枝末节的设计要沉淀出产品规范。 3.3.2需求活在项目中 评审，一个头两个大 评审的目的在于防止问题随时间放大 三次评审：需求评审、设计评审、测试评审 需求评审会中两类人要在场：能做决定的人；此项目相关的产品接口人 再看需求的生老病死 几个重要的会议： 项目开始前的需求讨论会，PD带着自己的需求为有限的开发测试资源PK，若通过状态变为“需求中” 项目中需求阶段的需求评审会，PD收集意见反复修改需求，若通过状态变为“开发中” 项目中需求阶段以后的和开发、测试人员确认细节 -> 开发提交测试以后的功能评审会，让项目干系人确认功能 3.4成长，一步一个脚印 需求冻结后修改需求要更慎重 开发阶段，旁观者说 设计 -> 设计评审 -> 编码 -> 单元测试 测试阶段，大家一起上 TC编写 -> TC评测 -> 冒烟测试 -> 功能评审 -> 测试 商业准备工作同步进行：PD写卖点文档、产品更新公告；运营的做策划推广方案；服务的做产品帮助 Bug眼中的项目 Bug描述的几个关键点：缺陷级别，所属产品、项目，Bug名称，Bug描述 Bug的几种状态：open，rejected，updated，fixed(修复后更新到测试环境)，closed，reopened，deferred(暂不修正) 使用Quality Center管理，所有操作都有记录 那一夜，项目发布 发布评审 -> 预发布 -> 发布 -> 线上验证 使用SVN管理代码版本 对于用户影响大的升级，采用“分流发布”或“灰度发布”，即让一部分用户先用，再决定更大发布的时机 正式发布前要填写“发布申请单”，让关键人物签字 发布时间一般选择在晚上 以终为始，项目小结 发布后在公司邮件组里发“项目发布公告”，做好内部宣传 + 物质奖励或聚餐 -> 发布后半个月内写项目小结 项目小结内容：遇到何问题，如何解决和避免；商业目标是否达到；资源评估是否合理 通过写项目的日报或周报，项目小结就水到渠成 怕什么来什么，只能拥抱变化 对变更事件，制定流程做控制，对于过大过晚的变化，项目经理有权决定是拒绝，还是上报大老板定夺 对搭车事件，找内容相关的项目，尽早而不要在需求冻结后再提 对紧急事件，由高层老板确认后自上而下推动 对于多个项目并行时的资源不足，遵循“慢车让快车”的原则 3.5山寨级项目管理 3.5.1文档只是手段 建立自己的文档规范 把文档除去公司的烙印，融入自己的理解，以后不管在哪工作，只要做的还是产品，这份文档规范就是一笔财富 模板作用知多少 模板本质作用：让经常看同类文档的人提高效率；让写文档的新手可以尽快上手；让写作者不会漏考虑某些内容 对于成熟的团队和产品，在项目开始前就约定好各种模板、规范与流程。这些模板、规范与流程最好在产品1.0版发布，进入1.1版的升级阶段，但还未研发2.0的时候迭代生成。 偶尔为之的事情不必形成模板。 多人协作与版本管理 产生文档版本管理的本质需求是多人合作，协同办公 windows系统的共享文档(互斥修改) -> google docs -> wiki (随时更新整个产品的PRD) 玩转office足矣 3.5.2流程也是手段 项目 VS 流程 项目只做一次，追求可行解；流程要反复做，追求最优解 流程的本质目的 随着产品越来越大，个人英雄主义就变得无用。这些英雄把个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、继承，后人在做这些事时起码不会显得太无助。在这点上，规范、模板的作用也类似。这就是团队的核心竞争力。 那么多评审，可以省么 产品会议：必须有，决定“做不做，做多少”很重要 kick off会议：最好开，鼓舞士气 需求评审：分别是PRD，UC,demo评审，根据实际情况合并部分评审 设计评审：开发实力强可以忽略 TC评审：省的话，验收测试要更细致 功能评审：必须有 发布评审：不一定 商业评审与技术评审 商业评审决定“做不做”，是产品会议和功能评审 技术评审决定“怎么做”，是需求、设计、TC、发布评审 技术评审要避免抓闲人、科普会、批斗会的情况 3.5.3敏捷更是手段 从书本到实践 瀑布模型 -> 敏捷方法 敏捷方法的特点：有计划，更要拥抱变化；迭代周期内尽量不要加任务，可以移除一部分任务到下一次迭代；集中工作，小步快跑；持续细化需求，强调测试；不断发布，尽早交付，把大问题分而治之 项目中的敏捷沟通 即时通信IM群、每日站立晨会、项目看板 与外包团队的敏捷尝试 例子：作者是甲方代表，负责项目实施的乙方是家大外企。甲方想用敏捷方法，乙方想用传统瀑布模式，因此冲突不断。表现在：项目外包使甲方不愿意砍需求；敏捷导致提交测试的产品与最初需求间有变化，这在公司内部运行得很好，但由于甲乙方没有一起办公，配合困难；乙方缺乏敏捷的经验和意识，在没有详细设计文档的情况下技术人员按自己想法开发测试，没有与需求人员沟通 3.6物竞天择适者生存 3.6.1亲历过的特色项目 如何做好老板项目 时间是给死的 质量是可变的，把质量搞大，派出各种功能的建议优先级和所耗资源，让老板砍功能 资源时丰富的，尽量多要 秘密行动，封闭开发 临时的团队在一个会议室办公，交流方便，但是环境差，让人疲惫，时间上限最好是两三个月 开发外包？项目外包？ 略 3.6.2一路坎坷，你我同行 边计划，边行动，边修改不可怕，这在敏捷开发常见，关键是目标和原则不可变。 拍脑门，拍肩膀，拍胸脯，拍桌子，拍屁股，拍大腿也不可怕，怕的是不吸取教训。 几个项目的成败 例子：做了5个项目，大部分是失败的，这很正常。 第一个项目没有过压力测试。 第二个项目转移给别的团队，没有高层支持，在需求阶段叫停。 第三个项目在市场调研阶段叫停，因为收集的信息让我们觉得不值得做。 第四个项目成功，发布后不断升级、运营。 第五个项目和其他公司合作，开始规划宏伟，但最后延期半年。 一次只有七天的战斗 略 4.我的产品，我的团队 4.1大产品，大设计，大团队 4.1.1产品之大 时间之大：产品生命周期 不同阶段的5种用户：创新者 -> 早期追随者(较少，需求目的性强，专家用户) -> 鸿沟 -> 早期主流用户 -> 晚期主流用户(很多，中间用户和新手，抵触新产品，此时营销手段很重要) -> 落伍者 不管哪个阶段，先明确主打哪种类型的用户，再决定做什么产品满足相应的需求 空间之大：商业、产品、技术 大产品的铁三角：商业、产品、技术 任何一个公司必有它的强项与弱项，它不可能也没必要再这三方面都很强，一是因为构建“性价比团队”的考虑，二是因为都强的话互相压不住反而造成内耗，所以更重要的是找到自己公司的那个突出刀尖，即公司的DNA 例子：Google是技术主导，Apple是产品主导，阿里巴巴是商业主导，现在加大对技术的投入 4.1.2设计之大 新人会考虑不全面，分不清啥是精华，啥是糟粕，建议学习产品的人先看几本入门的书，学习华为的任正非引进管理体系时的策略“先僵化、后优化、再固化” 产品设计的五个层次 从抽象到具体，从概念到完成 战略层：商业目标和用户需求 范围层：明确“做多少”，功能规格说明和内容需求 结构层：交互设计，信息架构，这里的产出物包括软件的业务逻辑图、网站的站点地图 框架层：界面设计、导航设计、信息设计，确定页面长什么样子 表现层：视觉设计，比如页面配色、字体字号 我用五个层次来写书 第一轮搭建框架，精细到第四级目录，介绍每一级的主要内容 第二轮填充文字，把积累的文字做剪切 第三轮理顺逻辑 第四轮调整风格，增加图表和照片。使书更生动活泼 第五轮后期制作，编辑同学和前辈帮忙评审 对应互联网产品设计的五个层次：战略、范围、结构、框架、表现 设计的“现实与浪漫” 设计的三个层次： 第一层次：本能水平。产品要有用，满足用户的某种需求 第二层次：行为水平。产品要能用好用，顺利解决用户的问题，在反馈、容错和简化上做好。 第三层次：反思水平纯心理需求，比如像花一样的台灯、iphone 4.1.3团队之大 想当年，一个比一个猛 略 从几个人到一家公司 创业小公司，一人做好几件事 成熟公司，有了分工，人员可分为商业、产品、技术、支撑四大块。 接口人存在的价值 问题过滤，合并相似问题，会由相关部门中比较资深的同学来担任 最好接口人跟公司里多数人已混熟，减少部门合作时的陌生人之间的沟通成本 我身边的矩阵型组织 职能型组织：把相同职责的人划分在一个部门里，有利同类资源贡献，但部门只对“上面”负责，不对客户负责。 项目型组织：把各种职责的人组成一个个项目组，有利快速推进项目，但是会资源浪费。 矩阵型组织是上述两种组织的融合。 最好不由一个人兼任矩阵型组织的“双头领导”，而是让管事的产品经理提供建议，官人的部门经理决定对员工的考核。 4.2游走于商业与技术之间 4.2.1心思缜密的规划师 PD是产品经理及其带领的产品规划师、产品设计师和需求分析师。产品经理和产品规划师，更偏向产品前期的规划，比如产品的市场定位、各个版本发布的时间计划，商业目标、用户需求是思考的重点。产品设计师侧重于功能级的设计，在某个模块上很像一个小产品经理。即PD偏市场、用户，RA偏实现、技术。 从概念设计到信息架构 产品概念图是概念设计的产物，产生于需求采集之后、需求筛选之前。我们要通过概念图来理清思路，找到应该“做什么”，并将其整合为一个系统。 画出产品概念图的方法：1）在思维导图上改，比如对需求做简单分类，写些注释；2）大家在白板上讨论改进 概念图要重点突出两点：1）产品与外界的关系；2）产品内部的关系：不涉及数据流，重点描述不同角色在系统里的身份 概念设计是为了团队沟通，完成后，开始信息架构，信息架构是为了设计更合理的方式，把信息传递给用户。 PD的出身及其优劣势 PD的出身各种各样，你之前做的事情是你擅长的，是你的优势，也是你的劣势。 例子：开发工程师转产品经理，可以在初期就判断那些事情不靠谱，但是会让技术压倒商业，在业务逻辑没确定时就考虑过细的实现难度问题。 4.2.2激情四射的设计师 规划师让产品有用，满足用户的某些需求；设计师让产品好用，用户用起来舒服。 用户体验部门的职责可细分为：用户研究员、交互设计师、视觉设计师、前端工程师 产品新首页诞生记 ->e网打进的产品Portal改版：加重营销内容，将访客转化为付费用户。 ->确定Portal需要哪些页面和导航菜单的结构 ->确定每个页面的元素 ->PD手绘纸面demo ->UE制作线框图demo ->UE制作视觉效果图，PD安排销售、服务等做demo评审 ->上线后的持续监控和改进 当交互设计遇到敏捷开发 交互设计适用于传统领域、成熟公司；敏捷开发适用于新兴行业、创业公司 信息展现设计的例子 例子：显示若干城市12个月的降雨量 表格 -> 按雨量标记不同颜色的表格 -> 用雨滴大小表示数据 -> 在地图上标上城市，用户可滑动时间轴看到雨量变化 聊聊细节，文案设计 文案问题分为三个级别：错别字、病句、错误标点；用词不统一、不准确；语言风格不统一、产品气质不统一 产品的文案越少越好，用户都是凭着自己的感觉使用产品 4.2.3“阴险狡诈”的运营师 运营师：不是直接向用户介绍功能，而是有个“把功能转化为卖点”的过程。 产品与运营的战与和 运营只能把人带来，而把人留住要靠产品 运营有时为了更直接的商业目标，比如PV(Page View)，做了短视的事情，一段时间后PV就下降，PV背后的目的-增加网站用户数没有达到。 个人博客运营实例 KPI定为体现高用户数的“RSS订阅数” 推广方法：发出以产品经理值得.系列的重量级博文；UCDChina、CSDN专家博客、Q