产品经理如何抓住程序员的心

产品经理（Product Manager）是任何新创产品的关键角色，他定义了产品的需求规格，找出产品的价值所在。而一个成功的产品代表结合了好的产品需求规格，以及能够依据这个需求规格实作出来的工程团队。我们说产品经理负责产品原型设计，而开发团队负责整个产品的开发，两者缺一不可。由此可知产品经理与程序员团队之间的关系有多么重要。

为了帮助产品经理与程序员团队的合作更紧密，一起打造更好的产品，以下几点是我的建议：

1.定义清楚这个产品

这是最基本也是重要的，重要的事情说三遍：「定义产品」、「定义产品」、「定义产品」，为什么这么根本的事情还作不好呢？很多时候是组织的问题，没有人专职负责，例如：

产品经理就是老板。但是老板太忙了，只定义了核心需求，而没有定义细节规格。于是程序员就得自己脑补，最后做错了被骂又重做。

销售客服来兼职产品经理。销售很了解如何告诉世界这个产品有多棒，但是却不一定能够发现需求并定义清楚这个产品，这两者的技能是不一样的。并且很容易发生传声筒现象，直接把单一客户的需求告诉程序员，而非经过一致的产品思考规划以及使用者体验设计。

我们会在之后的文章继续探讨什么是好的规格文件。它代表了使用者应该要有什么体验、产品有哪些功能和行为，以及功能的开发优先级。除了基本的用户需求，也应包含产品框架界面流程和关键的测试案例。

2.建立良好的沟通渠道

就算规格写的再清楚，开始实作之后就会有一堆问题冒出来。如果没有人可以问或是等不到产品经理的回复，开发人员就会开始脑补这个功能，硬着头皮继续做下去（然后又做错了被骂，需要重做）。或是就停下来，找其他低优先的事情来做。无论怎样都是很大的浪费。

建立一个良好的沟通渠道，让程序员可以很快地跟产品经理问到答案。这里如果整个项目开发有专业的项目经理负责，沟通会变得流畅许多。

3.不要负责项目管理

如果没有专职的项目经理（Project Manager），那么产品的开发者必须亲自来负责项目进度。不要让产品经理去兼项目管理。项目管理的重点在于执行及发布产品、协调开发、测试与营运团队。让产品经理来做很大程度上会造成两方关系的紧绷，压榨程序员的故事不断真实上演，就是因为由不了解软件工程的人负责项目管理所导致的。

在知名的Scrum敏捷软件开发方法中就提到：产品经理决定作什么，让整个程序开发团队决定如何做及可以做多少。

4.不要告诉程序员开发团队怎么做，告诉他们要做什么

很多产品经理喜欢把需求描述成解决方案，指定了一个不可行或者是成本效益很低的作法，而不是告诉程序员他们想要达到的目标，或是想要解决的问题根本是什么。

F-16是史上最成功的战斗机之一，在一开始设计的要求是需要超过两马赫的速度，首席设计师问了美国空军为什么飞行速度这么重要，答复是「飞机必须可以从战斗中逃脱」。最后的设计并没有超过两马赫，但是却可以让飞机很敏捷的逃脱，透过了无框的坐舱、抬头显示器，让飞行员有更好的视野。可倾斜的座位降低了重力影响。飞行控制杆是安装在右手边上，而非传统的在两腿之间，用来辅助在高G值时转弯。这些设计不但也能达成设计目标，更降低了生产成本。

这个问题其实不只产品经理，工程师本身也常犯这个错误，常常可以在讨论区看到有人问「请问这个指令X怎么用」，然后底下的讨论怎样都无法完全解决他的问题，直到有人问「为什么你需要这个X？」，他回答「因为他要做Y功能」，大家恍然大悟用X来解决根本是错的，应该用指令A就可以很简单的解决了。

在大多数的情况下，程序员比产品经理更清楚知道哪个实作方案最适合。

5.相信程序员专业性

产品经理负责产品的专业体验，而工程团队负责如何正确的构建产品。相信程序员的专业，就是让开发团队可以实行任何他们认为建构一个有质量产品需要的作法，例如撰写自动化测试、面对编程、建构CI持续整合环境，Code Review代码复审等等。这些工作虽然不直接与产品需求相关，却对工程质量有很大的影响。这些事情现在不做，在项目开发几个月之后，很快就会吞噬整个项目进度和质量。

以上五点可以帮助产品经理和程序员开发团队更愉快的合作，但是请记得无论开发团队再优秀，如果产品经理无法定义出一个值得建造的产品，一切也是枉然。