今年在参与阿里软件的内训师计划，负责 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个小时的版本，希望以后有机会与同学们分享。