首页 > 产品设计 > 从阿里软件看产品经理工作
2016
11-18

从阿里软件看产品经理工作

从阿里软件看产品经理工作 - 第1张  | 龙族

需求相关

产品早期多为老板驱动,PD驱动,特别是市场不成熟的时候,我将之不成熟的比作“主动进攻”;后期会逐步转变为用户驱动、销售驱动、服务驱动,更像“被动防守”。

(在主动进攻的时候要加快第一次的迭代速度,以获取最快速的用户反馈,减少风险)

管理需求,特别是日常的小需求,包括收集、状态跟踪,两个团队用excel,两个团队用mantis+excel,一个团队用QC,都ok。用mantis的团队说,mantis适合收集,跟踪,方便记录存档与反馈,但管理还是由各个产品的PD自己做,多用excel。大家都会按需要开产品会,召集产品相关方共同确定接下来一段时间做哪些需求。

(关键是需求的粒度和条目化,后续对条目化需求的跟踪,Excel是很好的方式,但是Excel又无法替代需求文档。)

需求的优先级谁定,安全的做法是谁获益谁负责(俗称老板拍脑袋),但PD是专家,应提供专家意见给老板,当然高层授权的专家负责制也许更好。

(优先级的结构化决策方法,可以从多个维度对优先级进度评估)

部分团队的需求文档直接在wiki上写作,管理。

(很好的方式,直接实现需求到设计实现文档的结构化和条目化,类似现在推Doors等工具都是为了实现需求和设计开发过程的结构化,Word文档一开始并没有,而是后续结构化工具导出的。)

部分团队需求评审与UC评审分开,需求评审偏商业,UC评审偏技术。

(立项前需要还在用户需求和DEMO抛弃原型阶段。立项后的需求重点是UC开发,需求已经转化为产品需求和软件需求。)


项目相关

典型项目周期:web based,2周到1个月(不算产品1.0这种大项目);旺旺,3、4个月。

(迭代周期不要超过1个月。短周期迭代以最快获取用户反馈。)

项目沟通方式各有不同,主要是4个方面:周期分“日”、“周”为单位;形式可以是会议、邮件;发起者不同;参与者不同。但目的相同,都是为了项目成功,所以可以按需选用最合适的方法。

(类似SCRUM中的每日晨会是很好的方式,增加每天工作的计划性)

一般5开发工作日以下的小需求不参加产品会争夺资源,采用搭车的方式做。

(资源分配和决策机制是如何的?在PACE中通过立项和阶段决策分配资源)

一个团队的产品文档实践很高级,拥有整个产品的UC,直接在网页上编写,采用SVN做版本管理,和代码类似,项目启动开UC分支,完成后要合并UC。另4个团队仍然是项目文档的模式,产品文档只在产品1.0的时候出现一次。

(不清楚阿里的产品和项目的关系,按道理应该是现有产品规划和产品需求相关文档,然后才是通过迭代的方式通过产品版本规划分解为多个项目版本。)

一个团队的敏捷实践很值得推广,用白板做看板,把晨会、日报整合,已经写了一篇相关分析。

PD团队人员构成,偏商业+偏技术背景各半比较合理,有团队大部分技术出身,深感对偏互联网的产品“感觉”上不到位,比如对用户体验有心无力。新人过多也是大问题,这也是高速成长团队必然存在的问题,老中青的结构还是必要的,个人感觉1年内的同学不要超过一半,且需要有3年以上的同学,这样才稳定。

(很重要的问题,但是往往是身不由己)

PD不要侵占交互设计师的工作,不要侵占系统分析师的工作,现状是存在很多侵占现象的,这也许和很多历史原因有关,有同学感到不停的在被迫做不专业的事情,犯各种错误……

(PD可以介入些交互设计的工作,需要站在用户视角看产品,但是不适合介入太多系统分析的工作。)

讨论了阿里巴巴B2B区分PD和RA

(Requirement Analyzer,需求分析师)的做法,PD尽量往前走,偏市场/用户,产品规划;RA往后走,偏实现,写UC,做系统设计。(PD的重点仍然是产品规划,用户,产品经营,市场需求,项目版本规划,团队等重要内容)

开始出现专职DM(开发经理)的角色,配合项目经理管理开发过程,比如协调人员、制定开发计划,自己并不是项目的开发人员,而且可以同时担任多个项目的TM。

(团队超过20个人后,项目经理超过2个并行项目后,建议设立开发经理。一个管理到项目计划和需求确定,一个管理后端开发过程)

最后编辑:
作者:云海
产品经理。。。。

留下一个回复