《人人都是产品经理》读感

这本书在产品经理界也算有名了,不少产品读的第一本书就是这个,而且也有不少人看了这本书之后踏入产品这个大坑。我之前也看过产品相关的书,第一本是《结网》,还有就是交互方面的,因为前端和交互实在太密切。

前几天正好在公司书架上看到这本,封面灰常不起眼,就拿下来准备随意看看。看了之后很意外的发现,里面说到的很多问题竟然是我真实遇到的,于是花了一下午仔仔细细看了一遍,感觉受益匪浅。

我看的重点在第2章到第4章

 

需求的奋斗史 

1. 需求采集人人有责

应该让整个项目组的人都参与进来,特别是开发,让他们对项目有归属和责任感

2. 分析需求的商业价值 -> 初评需求的实现难度

3. 不要试图满足所有用户,一切皆看性价比     性价比=商业价值/实现难度(开发量)

4. 需求PK

对于备选的需求,进行PK,大家讨论哪些需求值得做

 

项目的坎坷一生

1. 项目VS流程

项目只做一次,流程要反复做,所以要追求最优解

团队人少、项目少、每个人都产品的一切都很了解,对需求的响应速度也超快,基本上产品口头描述之后,马上开始编码,然后产品或开发凭感觉点几下之后就发布了。

人多起来,多个项目并行,每个人参与多个产品线,再靠个人英雄主义是不行的,这时候出现的流程和规范都是一种管理的方法,产品在“快”和“稳”的平衡上,也要稍微向“稳”偏移。

 

2. 项目周期的各种会议

立项之前的产品会议:决定做不做,做多少,大方向

kick off会议:项目背景、意义、需求功能点描述、项目组织架构、项目计划、沟通计划,可以和需求评审一起进行,安排在需求评审的前15min

需求评审:prd,uc,demo评审

技术评审:开发描述自己负责的功能模块,以及采取的方案,确定技术方案之后进行排期

发布评审:开发决定是否需要

 

3. 敏捷更是手段

迭代周期内尽量不加任务

尽早交付,不断发布

 

 

我的产品,我的团队

1. 团队之大

职位并不关键,在想明白做一个产品要完成哪些事情,做这些事情需要哪些能力的人,团队处于什么阶段之后,应该设置哪些职位的答案就自然出来了。

2. 接口人

接口人存在的价值:有些事情需要多个部门之间来配合,比如产品上线之后,PD遇到日常的Bug处理、其他产品的开发这类事情。

产品上线初期,暴露出的问题可能不多,开发有精力应对,随着用户数的增加,暴露出的问题越来越多,更头疼的是很多问题是类似的,占据了日常工作大部分的时间。

这个时候,需要一个接口人,这个人一般会让部门中比较资深的同学来担任,起到问题过滤的作用,可以解决大部分一般同学搞不定的问题,并对相似问题进行合并。

 

3. 矩阵型组织

横向是产品线,对客户负责

纵向是资源线、部门线、为了资源共享。

产品经理/项目经理主要管事,有成就感;部门经理主要管人,有权力。

 

 

这本书可以作为产品经理启蒙,但是那个时候看着本书应该不会有太多共鸣,因为压根没有遇到过问题。作为在初创团队待了近两年的人,深感技术虽然重要,但没有想象中那么重要,没有好的产品,好的项目管理流程,技术再好也是浮云。

 

最后,不会交互的产品不是好前端

 

 

 

 

2 Responses

  1. PT says:

    敢问==学姐现在毕业在哪里工作呢?

Leave a Reply

:wink: :-| :-x :twisted: :) 8-O :( :roll: :-P :oops: :-o :mrgreen: :lol: :idea: :-D :evil: :cry: 8) :arrow: :-? :?: :!: