人人都是产品经理总结第三章2

本文对应人人都是产品经理的3.5、3.6两节，其中3.5节重点讲了项目管理中的文档管理、流程管理和敏捷方法，3.6节重点讲了作者亲历的一些项目。

文档管理

1、pd的文档主要分为以下几类（详细的看p156的图）：

商业需求文档：BRD。

产品需求文档：PRD。

需求规范类：PD做什么、用户体验规范：交互规范、视觉规范、文案规范等，主要让负责用户体验的同学负责。

需求管理类：用户调研文档：用户调研的前中后都需要做什么，调查问卷、用户访谈怎么设计等；产品需求列表；产品信息架构：用来描述产品的页面或功能之间的关系，网站地图、导航结构等。

流程管理类：日常发布流程；变更事件流程；

项目管理类：项目管理制度（原则性内容，例如产品会议制度、项目经理、开发经理、测试经理的权责利等）；项目任务书；kick off的ppt；项目组织结构；项目WBS；项目日报周报；项目发布预告及公告；

日常工作类：会议记录；个人日报与周报；

今后不管去哪里工作，这些模板都是自身的知识积累，已经融入了自己的理解，是一笔宝贵的财富，因此，上面所说的各种模板，工作以后需要根据自己的需要进行定制，多思考这些制度与规范，团队大了以后要用制度去约束人，而不是靠人去管理人。

模板主要有三方面作用：让经常看同类文档的人提高效率；让写文档的新人可以尽快上手；让写作者不会漏考虑某些内容。

模板与规范应该在需要的时候自然生成，逐步从简单到全面，不断迭代优化。

2、文档的版本管理问题

一种方式可以使用SVN，但问题是同一时间只能由一个人来编辑，另一种方式用wiki。苏杰文档版本号的含义：第一次给别人看是0.5，以后每次自己的修改，改小数点后第二位，如0.51、0.52等；有过集体讨论后的较大修改，会修改小数点后第一位，比如改成0.6，直到第一次正式对外发布，改成1.0。

流程管理

1、长视者把目的当手段，短视者把手段当目的。

2、通用的做产品的流程（适用于其他行业）：概念->方案->开发->验证->发布->生命周期维护。前两个阶段需要高手做，进入第三个阶段，高手应该去做新项目。新人做老产品，新人不挑活，老产品不容易出事；老人做新产品，老人需要变化才有激情。

3、流程的本质目的在于知识的传递。当年的“英雄”把自己的个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、传承，后人在做这些事的时候起码不会太无助。在这点上，规范、模板的作用也类似，这就是团队的核心竞争力。

4、评审是否可以省略

评审会议主要由以下几个：

产品会议：必须有，决定“做不做、做多少的问题”。

kick off会议：最好开一下，鼓舞士气的，磨刀不误砍柴工。

需求评审：如果项目kick off之后只做一次评审的话，那就是需求评审。

设计评审：表面上看起来经常在时间紧的情况下省略，实际上是在开发人员实力很强的情况下省略，而开发较弱，新人多，业务不熟的团队，则必须进行设计评审。

TC评审：仅次于需求评审，项目KO之后的第二重要评审。

功能评审：也是必须的，且需要项目干系人都参与，功能评审经常采用线下的方式进行，例如邮件里通知大家测试环境地址，然后大家自己去看。

发布评审：可以让开发经理决定是否需要。

上面的几个会议可以分为下面两类：

商业评审：决定做不做，包括产品会议与功能评审，商业评审得出的三个决定是：项目继续、重新定向、项目终止。

技术评审：决定怎么做，包括需求、设计、TC、发布评审。技术评审得出的三个决定是：项目继续、有风险的继续、必须解决某问题后再继续。

商业评审与技术评审最好分开，或者说在任何评审会议上不要同时讨论商业与技术问题，否则会被技术人员带入细节讨论，或者商业人员打击技术人员，或者决策者思维被搅浑。

敏捷方法

实践中的总结

1、项目计划应该不断修正，开始订的项目计划，一个月后很可能已经面目全非，强行遵守是没有意义的，而应该不断的修正。

2、迭代周期内尽量不加任务。如果某次迭代内的任务无法完成，可以为了时间点的要求，移出一部分任务到下一个迭代。

3、持续细化需求，强调测试，测试执行的过程可以用来补充和细化需求。

4、通过不断地发布来分解问题，让需求方不断的，尽早的看到结果。不断地发布是为了把大问题分而治之，先解决最核心的，风险最大的问题。

5、当每周两次发布时，阿里一般选择在周二和周四，如果只有一次的话，周三是个不错的选择。

敏捷过程中的沟通

苏杰书中有一句话写的很好，摘录在此：“无论最终发现什么，我们必须理解并完全相信：每个人在其当时所处环境下，在其能力范围中，做了最大的努力。”

1、每个项目，项目经理都会建立一个即时通信的IM群

2、项目相关的第一封邮件，会把大家的email收集齐。

3、每日站立晨会

4、项目看板视情况而定，板上横向为各个功能点的进度百分比，纵向为项目成员。红黄绿不同颜色的便签可以用来代表不同类型的人物。

作者亲历过的几个项目实战

1、老板项目

老板项目的Time是给死的，但是老板经常是一时说最好怎样，结果我们千万不要理解成必须怎样。订项目计划的时候给自己留一段富裕时间。

Quantity是可变的，开始的时候，尽量把Q搞大，并合理的给出一个巨大的Quantity，然后老板会因为Resource不够而自己砍Quantity，此时pm应该排出各种功能的优先级和所消耗的资源。

由于是老板项目，因此一般Resource资源是很丰富的

2、封闭开发

封闭开发的好处是交流非常方便；小空间更容易产生讨论，参与者更加积极；

3、项目外包

任何一个项目开始的时候，合作的多方必须要明确合作模式、划分权责利。

项目外包的话，乙方应该主动向甲方收集需求，并维护PRD等文档；而开发外包由甲方驱动更合适，走甲方的需求流程，不断给外包的工程师更新需求。项目外包过程中，甲方一定会有验收测试，但是乙方一定要在项目范围内安排比验收测试更详尽的测试，千万不能把找bug的测试寄托在甲方的验收测试上。

三边六拍项目

三边指的是：边计划、边行动、边修改，敏捷开发的过程中就是这样的，重要的是，关键的方向、目标一开始就要清晰，一些原则、约定不能总是改变。

六拍指的是：领导拍脑门决策、领导拍员工肩膀表示信任、员工拍胸脯承诺、领导拍桌子骂娘、员工拍屁股走人、领导和员工拍大腿后悔。六拍之后的关键是吸取经验教训，防止下次再犯同样的错误。

人人都是产品经理总结第三章2相关推荐

人人都是产品经理总结第三章1
产品与项目的区别,产品经理与项目经理的区别 1.产品是解决问题的东西,而项目是一个过程. 2.做产品与做项目的区别: 2.1.产品的生命周期长,从产品的规划.制造.维护和消亡的整个过程都是在做产品,而 ...
《人人都是产品经理》第四章读书笔记及读后感作文2400字
<人人都是产品经理>第四章读书笔记及读后感作文2400字: 最近一直在忙别的学习,以至于好久没有更新公众号了,也好久没有写读书笔记了.<人人都是产品经理>这本书其实早在一个月前 ...
人人都是产品经理总结第五章
以苏杰的经历,刚当上产品经理时,通常做的是需求.项目.团队等任务,但这些都是在确定要做一件事的时候才需要考虑的,是"做多少.怎么做",这一类的问题属于方法论的范畴,到了2009年, ...
人人都是产品经理总结第六章
产品经理的四大修养: 爱生活,让我们充满动力:生活中包含了很多产品设计的实例和很多不完善的地方,需要我们在平时深刻体会,尽量提出自己的看法,产品经理要热爱生活,时刻充满激情.能量和创意. 有理想,让我 ...
《人人都是产品经理》读书笔记 Part 3
Part3--项目的坎坷一生今天分享的是<人人都是产品经理>读书笔记第三部分:项目.照例先给出本部分的思维导图. 这一部分主要讲了从产品到项目.项目启动.需求开发.项目周期.产品经理 ...
三分钟读完《人人都是产品经理》
欢迎关注公众号--<数据三分钟> 一线大厂的师兄师姐结合自己的工作实践,将数据知识浅显道来,每天三分钟,助你成为数据达人.还有面试指导和内推机会. 零.序 1.我们应该养成一个习惯,当看 ...
【总结整理】租房产品创业的三个方向和三个产品---摘自《人人都是产品经理》...
创业产品反思录:从拆解元需求到产品定位人人都是产品经理社区发布于 2018-10-08 08:56:31 举报阅读数:466 10个人,10个月,100万,3款产品,我们在变幻莫测的租房领域 ...
axure 如何设置选项联动_Axure教程｜用中继器做信息流，高仿人人都是产品经理网...
本期给大家带来的是高仿资讯网站"人人都是产品经理网",来看看~ 一.照例先上gif 首页部分中继器部分二.制作思路本次原型的制作主要有四个部分: 浮动导航右侧区域版权信息 ...
给大家几个不花钱看书的办法【人人都是产品经理】
不花钱!很自然的就想到了找人送,但大家的思路还不够开阔,只想到找作者送--我哭,为什么哭最后再说.当然,打完折30块出头也确实有点小贵,我也不希望你花钱,给个好主意-- 忽悠公司团购这本书,让老板送 ...

人人都是产品经理总结第三章2

人人都是产品经理总结第三章2相关推荐

最新文章

热门文章

人人都是产品经理总结 第三章2

人人都是产品经理总结 第三章2相关推荐

最新文章

热门文章

人人都是产品经理总结第三章2

人人都是产品经理总结第三章2相关推荐