一篇文章，带你读懂程序猿与产品经理的爱恨情仇

回想起上次参与集体活动，是真人射击游戏。我们团队里产品经理数量不多，程序员却有好几十位。那番景象大概不难想象……并非紧张刺激的较量，反倒是一场令人发指的混战。

一个产品经理被 BB 弹打成了狗，突然灵机一动，急忙喊道：我以前确实也编写过代码，我属于这边的人！

其余正在行凶的程序员互相瞅了瞅，觉得颇为触动，不过还是不肯原谅他，接着在地面上痛打了半钟头。

……

我在哈尔滨工业大学就读，专业是信息技术，编写了六年的程序，工作后从事的是项目管理工作。

程序员与产品经理之间的戏谑说法，根本原因在于双方常常产生分歧，分歧产生的原因是彼此分别是需求提出者和需求完成者。分歧的种类也很有限，就是大家经常谈论的那些情形。我既编写过程序，也负责过产品，实际上仍然找不到一套通用的原则，能够化解所有分歧。

担任过产品负责人之后，确实有了全新认识。产品事务与技术开发均在我负责范围之中，审视事物的视角因此截然不同。

以前当程序师的时候，常常觉得客户提出的任务变动很恼人，他们给出的任务要求不切实际很烦人，规定的完成期限不切合实际也很烦人。

担任产品管理职位期间，有时会认为软件开发者常常逃避义务，交付成果时拖延或者质量欠佳。

整体协作过程中，难免会遇到状况，重点在于如何事先防止，以及事后处理。

……

以下是一些切身体会得出的经验性建议：

对于研发人员：做好更改需求的准备

很多固执的程序员会把改需求当成错事。

实际上，在互联网产品这个领域内，改需求肯定会是家常便饭。

我从未做过相关统计，不过我了解到那些已经运营一年的企业，绝大多数都经历过彻底的版本革新，也就是需要对程序进行整体性的重构。这对技术部门的人员而言，无疑是一种煎熬，然而这种经历却是难以避免的。

网络环境更迭速度很快，过去人们常关注微博，现在则多在朋友圈互动。同时，信息获取途径五花八门，产品负责人时常会有新思路和新见解，这些想法未必是事先未考虑周全。

当然，要是老板总是从《易经》中获得领悟，或者从云聚云散花开花谢中找到灵感，让你手忙脚乱地反复修改他的指示，那确实很没意思。

修改需求是常有的事，因此必须做好应对调整的准备，可以采取以下几种方式：

1.1 提高代码的可复用性、可扩展性等等

将那些产品中经常需要用到的各类控件和功能模块，转化为具备极高复用性的代码，当产品需要添加同类功能，或者调整既有相似功能时，将获得显著帮助。

开放性在于各类接口、数据存储及基础框架不宜僵化固定，须尽可能采用灵活的设计方案。例如当前存在五个类别，不应硬编码限定数量，而应表述为可容纳若干个类别，当前实例为五个。

这个道理显而易见，然而部分软件开发者却相当马虎，在构建程序时缺乏长远考虑。

其他代码方面的优势，只要有助于减少产品调整和改进的费用，就需要更加重视。

1.2 根据产品规划来做好充分准备

每一种功能的具体做法都有许多种，挑选时不能只考虑目前的费用高低，还需要着眼于未来整个产品的长远构想。

当前要实现功能 A, 存在方案一、方案二、方案三等选择, 其中方案一投入最低。然而将来需要完成 A、B、C、D 等多项任务, 方案三更有助于整体开销最省。因此应当选择方案三提前布局。

多与产品部沟通，探明未来产品要达成的目标，哪些特性是不可或缺的，哪些特性是或许会包含的，要着眼于长远角度。

1.3 合理预留出修整的时间

开发周期不等于最终时限。功能实现只是其中一环，还需要为质量检测、问题修正以及突发状况预留时间。

有两种情况要多预留出修整的时间。

研发团队对功能信心不足时，需要特别注意，这种情况可能涉及全新领域，或者技术难度大，容易产生大量错误和实现缺陷，因此必须增加时间准备。

产品部门亦对特性存有顾虑，例如在提交要求时透露该特性极有可能需要改动，又或是对特性本身缺乏把握，那么就必须预留更多时段进行修正。

理解需求，防止返工

技术部门往往对任务要求认识不清，外包机构尤其如此。我听过许多案例，几十万聘请外包，最后产品很不理想，完全无法使用。合同已经生效，只能付款，真是损失惨重。

有些技术部门与产品部门共处一室，却依然常常沟通不畅。技术人员不清楚当前开发的功能面向哪些用户，具体提供什么服务，以及如何实现用户价值。

这些并非复杂难懂的道理，也无需钻研透彻，产品经理稍加涉猎即可，这样就能减少不少弯路，也不会轻易需要重做。

有些商品界面能够预先载入数据，或者每次都重新获取，这取决于顾客通常在何种网络条件下操作，产品策划者对此了如指掌。策划者在构思功能时，不会深入到技术实现的具体环节，因此需要开发人员领会前述要求，并作出相应抉择。

要是开发开始前就察觉到实际效果和产品经理设想的偏差，就必须立刻沟通，绝对不能等开发结束，等到所有人都觉得方案不可行时再返工，这样无论哪方面付出的代价都极其高昂。

善于用数据、理论以及通俗的解释来进行沟通

技术人员最不该表达的是类似“这件事无法完成，即便你明白也无济于事”或者“这个太复杂，没心情向你说明白”的言论。当业务负责人听到这些话时，他们很可能会认为是在逃避任务。

正确的方式是：用通俗易懂的客观事实来解释。

嗯，这个弹窗做不了。

为什么现在做不了？是因为代码实现可能要花三个月。

为什么这么久？是因为需要调用底层驱动层面的东西。

调用底层驱动的原因在于安卓系统的框架和协议本身具有这样的设计。

如果想看协议，我可以给你找出来。

循序渐进地阐明，逐一讲清所有缘由，请保持耐心，只要产品负责人是通情达理的，他就能明白你的意思。

他理解了你的说明，这有助于他找到其他可行的替代方案。

哦，我懂了，这个用弹窗形式太复杂。

那我们换作跳转到普通页面吧。

这样问题就解决了。

对于产品：

产品负责人需要在持续更新和调整任务的过程中获得开发人员的接纳和敬重，我认为最关键的是要合情合理。绝不能说出类似“不管怎样都要完成”或者“上级已经安排了，我无能为力”的言论。

对产品功能有规划，并提供给研发

产品经理若对自身产品缺乏基本构想，便构成重大失误，同时这也是导致诸多问题的根本症结。

一年后产品成熟了要给用户解决怎样的问题？

未来半年内产品要做成什么样子？

三个月内产品应该主要提供哪些功能？

这一个月的产品具体方案是做哪些？

这些都要认真去考虑并且规划。

长期的产品蓝图在许多状况下，例如市场波动、人员变动、方向调整，其实作用有限，然而近期目标设定，对开发团队却更为实用。

一般情况下，预计接下来三个月内，产品的功能应该没什么问题，假如老板和产品经理对产品究竟要做成什么样还是不清楚。

要想清楚这些安排，并告知技术部门，促使他们在当前程序中为后续功能预留位置，这是防止代码重复编写最有效的途径。

提供需求要足够具体

这要求产品经理做到两点：

第一，让产品需求文档特别特别具体。

实际并非要求完全依照大企业的产品需求文档来执行。关键在于确保内容完整。需求文件中，必须包含页面构造、界面安排、功能运作方式以及各项功能的具体操作步骤。不能仅凭一张交互示意图就视为完整的需求说明。

你交付了五个界面给技术团队，他们着手开发时，中途向你反映似乎缺少一个部分。你补充制作了一个，技术人员继续工作后，又指出还差一个…最终零零散散凑齐了十个界面，却发现整体功能极不完善，于是决定全部废弃重做。

假如技术团队总是向你询问某个环节的具体执行方式，那么你需要考虑一下，是不是相关的规格说明存在不足之处。

第二，要说明每个需求背后的原因。

先前已经阐述过，一旦程序员领会了任务深层的缘由，便会构思出更为妥帖的设计来达成目标。

绝对不能说『你不必知道原因』，无论如何，不管是他是否询问这个功能的设计理由，都要解释清楚原因。

熟悉基本的研发背景和研发能力

产品经理是否真的需要掌握技术知识，是我所接收到关于产品经理的各种询问里，排名最靠前的五个问题之一。

对于这个议题，我的看法是：必须依据具体要求，掌握必要的基础理论，但并非要弄清执行层面的具体情况。

懂得基本原理、不必精通具体事项意味着产品负责人需要掌握核心概念。

比如开发安卓系统，需要了解安卓系统自带有哪些组件，这样在制定计划时能尽量选用它们。调用一个组件，编写代码或许只需几行，但若要重新设计一个功能界面，可能就要编写成千上万行的代码。

比如在手机网页端的产品，需要了解哪些交互在 H5 平台上比较容易完成，哪些交互会带来很差的体验效果。如果按照 iOS 系统的动画标准来要求 H5 开发，那么制作成本可能会急剧增加。

按需学习，产品经理不应购买《iOS 入门指南》之类的书籍，也不必购买《安卓开发手册》之类的手册，更无需购买《H5 设计实例》之类的实例，这些书籍除了摆设，并无实际作用。

这些开发资料主要描述具体实现过程，对于掌握安卓基础组件或 H5 常见操作毫无用处；而且各产品存在独特属性，代码风格也不尽相同，只需熟悉自己项目的技术环境，有个同学竟然从 C 语言入手学习，实在令人痛心。

以上是我的一些理解。希望对大家能有所帮助。

倘若这篇文章切实降低了你同程序猿或产品运营之间的摩擦，欢迎私下联系或发表评论，我将会感到十分高兴。

#专栏作家#

刘飞是嘟嘟美甲的联合发起人之一，曾在锤子科技担任产品管理职位，同时也是人人都是产品经理专栏的撰写者，并且出版了豆瓣上的《最好的时代：可能是最真诚的创业日记》。他既能用文字表达情感，也能动手设计界面和交互。