【经验之谈】产品经理，如何掰弯技术人员

互联网时代，产品需求更加多变，产品经理在网络上甚至被戏称为“产品狗”，做产品设计的就是背黑锅的，就是炮灰……关于产品设计与开发实现环节的各种矛盾问题吐槽不少。为更好实现需求，产品经理如何说服 技术人员的讨论已经很多，而对于技术人员该怎样参与到产品设计讨论环节，也值得深思。

很多时候，程序员与产品经理在一个项目上的感观是完全不同的，就如两个盲人摸象，一个 希望摸出牛来，一个希望摸出面包来，显然二者都是不够理性的。 所以在项目管理中，我们要引入迭代和增量。迭代让软件不断完善某个特性，增量支持逐步交付所有特性。二者结合起来使用，可以不断修整逼近真实需求，提早暴露及规避风险。项目交流中，往往遇到的问题有以下三个误区。

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

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

误区二：技术人员过度或过高解读产品经理的需求，过高解读需求事实上也是对需求的漠视。

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

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

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

对于上述三种误区，需求与开发的不对称，关键在于责任、目标与绩效。要解决交流误差，并营造出快乐的沟通氛围、实施出优秀的作品，也并非没有解决之道。

经验一：专职做专事

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

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

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

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

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

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

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

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

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

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

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

文章摘自《程序员》电子刊 有删减

文章来源：艾艺信息