今年在参与阿里软件的内训师计划，负责PD（Product Designer，也可算是产品经理的半成品吧）入门培训课程的开发，所以一直在找各种机会和同行聊相关的话题，这也是作为课程需求采集工作的一部分，这块我自己分了4期：

 1.  阿里软件，管理软件事业部各产品PD代表（做完后，开始整理课程大纲）；

 2.  阿里软件各产品PD代表（做完后，尽快发布课程的beta版，可用于阿里软件内训）；

 3.  阿里集团各子公司PD代表（完善，仍然用于内训）；

 4.  业界产品经理代表（这部分，聊天对象还在积累中）；

采用深度访谈的原因很简单：无明确问题，先开放式聊天，每个人1到2小时，围绕几条线索“一个需求从采集到实现；一个项目从立项到结束；以PD为中心的组织与流程；零散话题”，大家来谈各自的产品是怎么做的。

相对而言，等到有明确的事情需要验证的时候，问卷就比较合适了，到时候可能会利用自己的网站做数据的收集，提前和同学们说一声也希望大家能帮帮我，：）

4月底，开始了第一期的访谈，参与者是管理软件事业部3大产品“钱掌柜、外贸版、e网打进”的PD代表；5月上旬，进行了第二期访谈，参与者是“阿里旺旺、alisoft.com”的两位PD代表，根据聊天的内容，上个图，是我根据PD @ alisoft做什么、怎么做整理出的，这只是最高层的一张图（点击看大图），也是内训主干的框架，里面的各个部分还有细化的图，后续准备仔细写出来。

最后放出一些可以公开的聊天内容：

需求相关

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

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

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

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

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

项目相关

 Ø  典型项目周期：web based，2周到1个月（不算产品1.0这种大项目）；旺旺，3、4个月。

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

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

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

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

团队相关

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

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

 Ø  讨论了阿里巴巴B2B区分PD和RA（Requirement Analyzer，需求分析师）的做法，PD尽量往前走，偏市场/用户，产品规划；RA往后走，偏实现，写UC，做系统设计。

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

最后提一下这门内训课程，已经开发出5、6个小时的版本，希望以后有机会与同学们分享。

打印  |  类别：设计思想  |  源地址