产品经理跟程序员友好相处的3个技巧

在几年前的一场面试，对方问我：“有没有和程序员吵过架？”当时的我颇稚嫩，岂图想在面试中体现自己的完美，回答道：“没有”，对方皱眉头嘀咕：“真的没有吗？”后来面试结果不了了之。

现在回想起来，做产品跟程序员长时间共事，并不是没有过争执，只不过不管大吵小吵，最终我们依旧回归到工作上，一起打磨产品。

本文不教请客吃饭人情世故，而是从产品经理专业角度，提出几个可以跟程序员友好相处的技巧；当然，本文提到的几个技巧已经过本人实践，有过泪水和笑声，如有雷同纯属巧合。

了解背景：我们的做事立场有何不同

首先，我们先了解一下程序员与产品经理做事出发的立场有什么不同：

日常工作流流程简述为：

• 产品经理梳理需求，通过文档向程序员表达需求逻辑；
• 程序员按照需求文档开发，期间会涉及到：需求调整、bug处理不等修整；
• 产品经理验收，再梳理出优化或新的需求。

整体上，程序员的工作事项都围绕着需求，需求正来自产品经理，因此程序员但凡对需求有任何想法或疑问，都得和产品经理商量，这种从属关系在某种程度上很容易陷入主观和客观之间的抽离。

再结合目前，的确存在产品经理专业能力参差不齐的现象，如果遇到需求来源复杂身不由己，说不清道不明，相处关系自然会贴上“对事不对人”的标签。

程序员日常看原型、评审需求、分析文档和梳理逻辑框架，对需求抱着一个中心思想那就是：这个需求能不能做，能做就能做，不能做就不能做，不存在凌磨两可，凌磨两可也只是时间问题。

不难发现，我们常爱调侃程序员是直男，实际上与他们常年工作的思维模式有着密切关系，写程序是直线思维，相对来说比较严谨的，产品经理口中的用户体验、产品质量、交互效果，在他们眼里都是：我要怎么实现这个需求。

这段背景秉承开个头让产品经理尝试去理解程序员的思考逻辑，再以此为要点贯彻到我们工作常见的几个场景里，对应技巧可以是哪些。

一、尝试去寻找解决方案

不太清楚会不会真的有产品经理对程序员提出“要求APP的主题颜色能根据手机壳自动调整”这样的需求，但我们常说的“技术可行性”的确是产品需求的硬性前提条件之一。我们通常会这么跟程序员打交道：

1. 在提供方案前咨询程序员需求可行性，程序员不一定深入调研、有空或好沟通；
2. 直接找案例的实现效果，实际情况、技术框架或系统不一定适用；
3. 凭直觉和经验觉得可行，产品经理更倾向于独立思考，高效直接。

第3点最常见，后续也最容易引起挑战，毕竟组织架构或者跨部门工作流程，都会导致产品经理经测试孤军作战去推动项目需求。

我曾在一个项目重构上提出优化ES搜索规则，但搜索结果的权重差如人意，程序员让我接受现实：涉及全文检索，列表显示的结果无法完全精准”，一时僵局，后来在CSDN找到类似案例，把解决方案的链接发过去，程序员解决思路就通了。

所以我们可以在梳理需求时，提炼可预测的技术难点，并且学会寻找可解决的方案备着：如果是小程序、微信、企业微信生态的产品，我们可以多逛逛微信开发社区，了解开发、运营文档更新的内容，了解官方的开放规则。

如果是自主开发的系统，也可以逛逛CSDN、简书，或者直接带着问题去百度。切记是有场景才去找解决方案，而不是沉浸式理解学习，毕竟我们是奔着解决问题，而不是为了做一个懂技术的产品经理。

二、尝试去说明业务背景

• “你为什么这样设计？”
• “你的需求出于什么目的？”
• “看不懂你写的A和B是什么关系”

程序员这三连问是不是很熟悉？是不是常常问得让人语塞，或者反复解释逻辑，仍然存在“代沟”，很正常。

回忆我们的需求链前常常是有很多繁琐的业务问题、业务流程，不少需求需要产品经理经过深入调研，梳理出一套具备可被标准化的系统架构，如果不是像电商那类ToC的产品，在我们日常生活就能理解到位的操作流程，程序员更难通过一次评审、一份文档或零碎沟通理解到位。

因此我们除了原型、需求文档，还会配套输出业务流程图、产品流程图，帮助他们了解业务背景，但仍不够。

我们可以尝试对程序员说明业务背景，通过这些方式：

1. 在梳理需求中的业务沟通会议带上部分有意愿的程序员或负责人，让整个项目团队都理解难，让整个项目团队都参加也难，所以抽一部分擅长对外沟通的人员，让他们在后续项目出现这类问题时，可以帮助产品经理引导思路或梳理开发内部的工作；
2. 讲产品方案前，带上业务同事代表或我们额外整理一些有关业务的示例如数据图表或业务文档，帮助程序员理解业务日常工作所面对的痛点、一些专业话术实际上与什么信息对标。

当然，我建议不直接和每个程序员或单个程序员对接挑战，而是通过转移矛盾的方式，将对象变成一个组或负责人，用其它层级的利益点去推动这件事情，可能会事半功倍。

比如，我和某个后端程序员说不通，那我就叫上测试、前端或者他的组长一起来理解我为什么这样考虑产品方案：“你们有什么更好的建议或者方案都可以拿出来一起探讨”，让项目组更多人理解背景，何尝不是一件省心的事呢？

三、尝试去跟进项目

现在有不少公司将产品经理的工作职责精细化，产品经理只需要输出需求文档，项目管理或跟进的工作则由项目经理全权负责，我对这种模式的优缺点保留意见。首先，我先抛出项目过程中所遇到的风险点都有哪些，不限于：

1. 功能模块、项目排期进度是否如期；
2. 需求理解、所呈现的效果是否到位；
3. 产品文档是否有遗漏的地方，是否满足开发要求。

以上任意一点，在程序员启动开发后，一旦项目反馈机制不够健全，产品经理都可能不知情，而错失在开发期间及时补充完善的机会，最终可能导致产品质量有问题。

所以你还会认为，我们产品经理在评审到交付前就没事情可做，让项目经理去跟进就可以了吗？那当然不是了。

没人抗拒产品经理“不请自来”，我们可以厚着脸皮参加到程序员的站会中去，旁听他们工作进度，有什么技术难点、有什么模块可能被遗漏、有什么风险点被一句带过没下文；

我喜欢观察开发排期或者项目管理系统，在那里可以清晰看到开发对需求细分的模块（是否有遗漏），每个需求点的估时（是否赶得上交付或安排在节假日前上线等风险）；也可以反哺自查产品经理设计方案内容：整体需求框架是否清晰易理解、层级流程是否合理、闭环异常状态等等。

四、写在最后

产品经理跟程序员友好相处的技巧只有3个吗？

我想远不止，但不难发现，技巧的核心都是1个方向，那就是“产品经理多做一点”，世界也可以变得更美好：多做一点思考，跳出自己只是个产品设计者的框架，让自己更全面更专业，相信程序员也会自主思考道：我该怎么跟产品经理友好相处。

本文作者 @Miss思思

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！