产品设计体会(5004)如何与工程师合作

2007年秋,一次PD交流会上,一位同事聊了PD如何与工程师合作的话题,很有共鸣,所以也整理了一下自己的想法,并且通过一个需求采集的练习,让各位开发、测试、PDUI把对合作沟通的期望提了上来,整理如下。

第一,综合大家的需求,权重最高的居然是一个很大的话题:“流程”,但仔细想想就一点都不奇怪,一群超级理性的人很明白“没有规矩,不成方圆”的道理,会喜欢被规则管理而不是被人管理,当事情由人来控制的时候,总给人一种不安全、不稳定的感觉,而有流程可依的时候,心里就比较踏实。(人治和法治的区别也就在此)

具体到实施方面,大家再次认同,需求确认的时候相关人员一定要都参加,以免后期再发生测试、开发对需求理解的脱节;如时间允许,开发应该尽早参与到需求评审中;……

另外有一点提到非常多的就是需求变更的流程,说明大家对“需求总是在变”这件事情已经是深恶痛绝并且有些恐惧了,但同时又意识到需求的本性就是“总在变”,所以非常希望有一个流程化的规定来严格控制这件事情。

但好的流程是需要执行的,感觉在实施的时候还是有些困难,网店现有的发布流程不能说完善,但很简单实用,如果能做到严格执行,相信已经可以减少很多问题了。

第二大的问题就是“沟通”,团队合作必不可少的一个环节。站在PD的立场上,我们会把自己作为产品的中心,这个角色注定要和各种各样的人交流,客户、老板、开发、运营、测试、客服、合作部门等等。

开发们提出了很有意思的一点,希望大家在交流的过程中避免情绪化。人性的弱点决定了在争论的过程中每个人都希望自己得到认同的,而这点往往导致思路的变形,不再是考虑产品怎么做更好,而是去想如何说服对方。我自己是觉得沟通中还有一点重要的就是每个人都要主动一点,这样才能形成互动的氛围,也可以减少信息不畅引起的问题。

iamsujie补:经常发现,有同学会把对人的反感转移到对人的观点的反对上,这很可怕。)

第三点是PD要不断提高自我修养,大家希望PD给出的文档在质量再更进一步,准确、全面、简洁,即时更新、保持最新。我自己觉得还有另外几点也是需要PD自己不断努力的,比如考虑问题的全面性,有空多了解一点技术等等。

iamsujie补:一定要懂一点技术,有的工程师你可以和他讲商业价值,而另外一些你与他讨论一些技术实现更有效,当然不是技术细节。此外,获得认同的最好办法不是自己反复的解释某个观点,而是引导对方说出你想说的观点。)

话题太大,不再多言。

------------------------------------------------------------如果你想第一时间看到最新内容, 就猛击此处订阅吧!

《产品设计体会(5004)如何与工程师合作》有10个想法

  1. PD不懂技术肯定不行,但PD肯定不如工程师懂技术。当工程师说有技术难度时,是换工程师,还是换设计?

  2. iamsujie
    能说说做技术的转PM、PD的优势和劣势么?谢谢了

  3. @军师
    简单的说,优势是懂技术,可以在早期判断出业务的技术可能性;劣势也是懂技术,可能在早期陷入技术细节的快乐探索过程,而对业务的考虑不充分。
    关键是个度,能把握好就是高手嘞,:)

  4. @iamsujie
    阿,受教了,努力中~你得快点写了,我看的太快了,过几天要没有看的了~

  5. 看了你写的文章很好,呵呵.我个人认为:PD不一定非懂技术,但一定要了解技术,因为PD是全方位的思考问题,包括运营,推广,设计,等一系列工作.与工程师的合作,只是其中的一小部分而已,但是项目主线是不变的,在这个与工程师的交互当中,我认为是最难把屋的,因为工程师对项目的理解程度直接影响到后期上线的运营,那么这时候要多听听工程师的意见了,但作为PD一定要站在一个听取者的角度去考虑工程师的意见,然后作出最终性的决定,所谓万变不离其宗,这一点对PD很重要的.就像你说的,要把握好这个"度",呵呵.

  6. sujie好,我看你的博客有好几天了,受益匪浅.
    我也是一个产品经理(实际是产品设计师,不过老板希望我成长起来,承担更多管理方面的工作).
    由于我对技术不了解,希望sujie兄可以介绍一些文章或者书籍供参考学习,让晚辈少走弯路.

    多谢sujie兄.

    iamsujie Reply:

    @洪仔, 可以先看看基本经典的书,比如《产品经理的第一本书》、《第二本书》,我也不懂技术,至少这几年感觉瓶颈还不是很严重~

  7. 拜读,受教了—-获得认同的最好办法不是自己反复的解释某个观点,而是引导对方说出你想说的观点—-确实如此,可是怎么引导呢,这个内功需要修炼阿

发表评论

电子邮件地址不会被公开。 必填项已用*标注