【第59期】技术人员如何参与产品设计讨论：激活那一潭死水

很多时候，程序员与产品经理在一个项目上的感观是完全不同的，就如两个盲人摸象，一个希望摸出牛来，一个希望摸出面包来，显然二者都是不够理性的。

所以在项目管理中，我们要引入迭代和增量。迭代让软件不断完善某个特性，增量支持逐步交付所有特性。二者结合起来使用，可以不断修整逼近真实需求，提早暴露及规避风险。项目交流中，往往遇到的问题有以下三个误区。

误区一：技术人员不断推翻产品经理的需求

在一些传统企业中，技术人员往往是权威，而产品经理往往是新聘或提拔的高管，无论是产品经理还是技术骨干，都受其职业规划和眼光的影响，并不能对整个公司或整个项目进行高瞻远瞩的规划，而企业的决策者们游离于技术骨干与产品经理之间，往往造成整个项目的需求和目标崩溃。

这种现象最后往往表现为：产品通过实施已经做好了，最后在技术人员那变成了“服务器不支持部署”，最终不了了之；或表现为：产品经理好不容易做好了一个需求，且能够实施，会上宣讲完后，技术骨干说“销售部早就试过这种技术，现在的客户端也不支持，培训销售人员使用软件至少要三个月”，使整个需求崩塌。

误区二：技术人员过度或过高解读产品经理的需求

过高解读需求事实上也是对需求的漠视。

我们经常遇到的现象是：当项目周期到了，审视整个项目进度却没有达到一半，开会讨论时收集的意见是“产品经理不是说UI界面很重要吗？我们已经设计了8套界面，至于软件核心我们还没有开工”、“这套产品我们规划了手机、PC和平板三个介质，所以我们分别在三个平台上进行了测试，软件代码还没有开始”。

误区三：技术人员对需求无动于衷

技术人员对需求无动于衷的现象往往表现为：你让我做移动项目吗？但我的PC客户端还在开发呢？你要的写代码，可我们还在做上个项目的培训呢。

对于上述三种误区，需求与开发的不对称，关键在于责任、目标与绩效。我们很容易理解，如果一个新项目突然给一个守旧的团队来实施，而且告知如果实施不达成就会受到惩罚，又或者告知如果实施成功将不再采用旧的标准来维系软件，可想而知整个项目组成员的抵触心理是何等强大。

要解决交流误差，并营造出快乐的沟通氛围、实施出优秀的作品，也并非没有解决之道。我多年从事Web开发和团队管理，在此分享四点经验。

经验一：专职做专事——不要对技术人员有复合事务要求或过高奢求

人们往往容易犯的错误是对别人有过高的需求。我们当然希望保洁员阿姨都能写出优秀的代码，上得了厅堂、下得了厨房，但这种求大求全的现象，往往最后什么也做不成。

所以在管理团队过程中，告诉团队：你不需要有过多的实施，你只需要专心做一件事，而且下班后就开开心心回家，第二天一早会有递增需求清单等你实施，绝不会让一个程序员去做“需求收集”，也不会让一个美工去“顺便写下CSS”这样的需求。

看起来这种思路很保守，但事实是有效和安全的。不可能要求所有成员都是复合型人才，员工什么都能做还打工干嘛，早就自己去当老板了。

经验二：不管结果如何，你先给我做出来，责任我来承担

项目经理或产品经理对于责任的担当是第一位的，作为经理要灌输给团队的理念是：你只要按我的需求做好事情，所有责任我会来担当。唯有如此，才能建立起一个敢进敢退的团队，而不应简单地将责任推诿给成员。

承担责任的前提并不仅仅是勇气或魄力，更需要智慧。往往经理能看到的层面，不是其他成员能看到的。可以设想当年iPhone研发时，分别在屏幕、传感、移动互联网等技术上投入，而原本从事PC开发的麦金塔团队成员并不能理解，但事后这些技术都很好地整合到了产品上。

在我们的项目管理中也同样需要“暗箱推进、事后串联”的能力。比如前瞻性地安排成员在UI、硬件、软件、需求等多方面并行开发，而事后可以良好地将这些技术“干货”整合起来，即使团队成员有离散，也不会影响整个项目。

经验三：同衣同袍、上下齐心

有什么比平等更重要呢？和团队成员一起上班、下班、一起吃快餐、一起找解决方案，远比一纸公文或是高高在上更有效。不要奢望通过远程电话会议、QQ、邮件能解决一切交流问题，面对面的交流，永远是最重要的传感渠道。

经验四：可以不说话，但有工具可以让你参与

有人说：需求有差异、实施有软肋，那就开会解决呗。“程序猿”们往往是口头表达的弱者，或是漠视口头交流（事实上他们不是没能力交流，而且往往在会上一言不发、会后牢骚万千，并在社交网络上活跃异常），原因很简单“写代码都已经很累了，为什么还要交流这么多”、“我又不是经理，为什么要参与交流”、“我只赚代码编程的钱，又没有人付我参与交流的报酬”。

针对这样的现象，经理应该允许并给予充分的尊重，我们要做的是：允许哑巴成员，但我会有其他的工具让你参与。包括线上调查、月报周报、团队拓展、日志记录、报表收集，甚至是生日Party等场合，在与员工同衣同袍的基础上，充分地让员工得到交流，从而解决交流的鸿沟。

PS：

a：这种事情早读君在项目中也遇到过，有“想法”的技术人员要进行对症下药，合适的人做合适的事。

b：专职做专事，术业有专攻，特别在一个团队中，对模板层的控制很难去界定，能对前后端代码修改当然是好事，但改完之后不要出现BUG，给他人增加不必要的时间。

c：最后推荐第51期的文章，做一名有产品思维的程序员，详情点击阅读原文