今年在参与阿里软件的内训师计划,负责PDProduct Designer,也可算是产品经理的半成品吧)入门培训课程的开发,所以一直在找各种机会和同行聊相关的话题,这也是作为课程需求采集工作的一部分,这块我自己分了4期:
 
 1.  阿里软件,管理软件事业部各产品PD代表(做完后,开始整理课程大纲);
 
 2.  阿里软件各产品PD代表(做完后,尽快发布课程的beta版,可用于阿里软件内训);
 
 3.  阿里集团各子公司PD代表(完善,仍然用于内训);
 
 4.  业界产品经理代表(这部分,聊天对象还在积累中);
 
采用深度访谈的原因很简单:无明确问题,先开放式聊天,每个人12小时,围绕几条线索“一个需求从采集到实现;一个项目从立项到结束;以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 based2周到1个月(不算产品1.0这种大项目);旺旺,34个月。
 
 Ø  项目沟通方式各有不同,主要是4个方面:周期分“日”、“周”为单位;形式可以是会议、邮件;发起者不同;参与者不同。但目的相同,都是为了项目成功,所以可以按需选用最合适的方法。
 
 Ø  一般5开发工作日以下的小需求不参加产品会争夺资源,采用搭车的方式做。
 Ø  一个团队的产品文档实践很高级,拥有整个产品的UC,直接在网页上编写,采用SVN做版本管理,和代码类似,项目启动开UC分支,完成后要合并UC。另4个团队仍然是项目文档的模式,产品文档只在产品1.0的时候出现一次。
 
 Ø  一个团队的敏捷实践很值得推广,用白板做看板,把晨会、日报整合,已经一篇相关分析
 
团队相关
 
 Ø  PD团队人员构成,偏商业+偏技术背景各半比较合理,有团队大部分技术出身,深感对偏互联网的产品“感觉”上不到位,比如对用户体验有心无力。新人过多也是大问题,这也是高速成长团队必然存在的问题,老中青的结构还是必要的,个人感觉1年内的同学不要超过一半,且需要有3年以上的同学,这样才稳定。
 
 Ø  PD不要侵占交互设计师的工作,不要侵占系统分析师的工作,现状是存在很多侵占现象的,这也许和很多历史原因有关,有同学感到不停的在被迫做不专业的事情,犯各种错误……
 
 Ø  讨论了阿里巴巴B2B区分PDRARequirement Analyzer,需求分析师)的做法,PD尽量往前走,偏市场/用户,产品规划;RA往后走,偏实现,写UC,做系统设计。
 
 Ø  开始出现专职DM(开发经理)的角色,配合项目经理管理开发过程,比如协调人员、制定开发计划,自己并不是项目的开发人员,而且可以同时担任多个项目的TM
 
最后提一下这门内训课程,已经开发出5、6个小时的版本,希望以后有机会与同学们分享。