## 产品设计体会(十)——团队合作
上周的阿里软件PD交流会旺旺的刘庚聊了一个PD如何与工程师合作的话题,很有共鸣,正好本周网店的交流会是我组织的,所以也整理了一下自己的想法,并且通过一个需求采集的练习,让各位工程师、QA、PD、UI把对合作沟通的期望提了上来,当时只是做了一些简单的整理,这次的周报不妨再顺一下。
第一,综合大家的需求,权重最高的居然是一个很大的话题:“流程”,但仔细想想就一点都不奇怪,一群理性的人很明白“没有规矩,不成方圆”的道理,当事情由人来控制的时候,总给人一种不安全、不稳定的感觉,而有流程可依的时候,心里就比较踏实。(人治和法治的区别也就在此)
具体到实施方面,大家再次认同,需求确认的时候相关人员一定要都参加,以免后期再发生QA、开发对需求理解的脱节;如时间允许,开发应该尽早参与到需求评审中;……
另外有一点提到非常多的就是需求变更的流程,说明大家对“需求总是在变”这件事情已经是深恶痛绝并且有些恐惧了,但同时又意识到需求的本性就是“总在变”,所以非常希望有一个流程化的规定来严格控制这件事情。
但好的流程是需要执行的,感觉在实施的时候还是有些困难,网店现有的发布流程不能说完善,但很简单实用,如果能做到严格执行,相信已经可以减少很多问题了。
第二大的问题就是“沟通”,团队合作必不可少的一个环节。站在PD的立场上,我们会把自己作为产品的中心,这个角色注定要和各种各样的人交流,客户、老板、开发、运营、测试、客服、合作部门等等。
开 发们提出了很有意思的一点,希望大家在交流的过程中避免情绪化。人性的弱点决定了在争论的过程中每个人都希望自己得到认同的,而这点往往导致思路的变形, 不再是考虑产品怎么做更好,而是去想如何说服对方。我自己是觉得沟通中还有一点重要的就是每个人都要主动一点,这样才能形成互动的氛围,也可以减少信息不 畅引起的问题。
第三点是PD要不断提高自我修养,大家希望PD给出的文档在质量再更进一步,准确、全面、简洁,即时更新、保持最新。我自己觉得还有另外几点也是需要PD自己不断努力的,比如考虑问题的全面性,有空多了解一点技术等等。
话题太大,时间有限,不再多言。
- 前言
- (一)——变态吧,开始帖周报了
- (二)——数据分析
- (三)——性价比:做不做?
- (四)——需求管理
- (五)——有关流程
- (六)——再谈流程
- (七)——需求探针
- (八)——产品与项目
- (九)——关于学习
- (十)——团队合作
- (十一)——市场扫描
- (十二)——少而精
- (十三)——再说需求分析
- (十四)——做过的几个项目
- (十五)——PM、PD、UE与UI
- (十六)——Feature List
- (十七)——PD的几种文档
- (十八)——概念设计
- (十九)——UPA年会的流水账
- (二十)——有关改版
- (二二)——封闭开发
- (二三)——用户研究
- (二五)——当交互设计遇到敏捷开发
- (二六)——PD就是出来卖的
- (二七)——大产品设计
- (二八)——细节之文案
- (二九)——产品设计的五个层次
- (三十)——“体会”导读的思维导图
- (三二)——零散的体会
- (三三)——用户大会
- (三四)——土老板破冰必杀技
- (三五)——QA与测试
- (三六)——再理解“敏捷”
- (三七)——可用性测试
- (三八)——项目外包!=开发外包
- (三九)——CSDN专访精编版
- (四十)——销售渠道
- (四一)——用户创意无限
- (四二)——又是零散体会
- (四三)——说说评审会
- (四四)——项目外包不适合“敏捷”?
- (四五)——外行眼中的技术分工
- (四六)——UML学习摘录(上)
- (四七)——UML学习摘录(下)
- (四八)——资源战争与BRD
- (四九)——产品市场化
- (五十)——终点:Matrix
- (五一)——敏捷的估计与规划
- (五二)——MS Office使用心得
- (五三)——产品文档与规范
- (五四)——PD招聘广告词
- (五五)——项目Kick Off
- (五六)——《需求工程》培训记录
- (五八)——《项目化管理》培训记录