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

从阿里软件看产品经理工作需求相关

　　产品早期多为老板驱动，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个并行项目后，建议设立开发经理。一个管理到项目计划和需求确定，一个管理后端开发过程)