高级产品经理谈：产品人员的技术修养 | 墨叽第十聚回顾文

今天分享的话题是产品人的技术修养。用这个主题是因为我个人有过开发经验然后对开发本身很感兴趣。我最开始做的事信息系统之类的产品，这一类产品需要很强的技术背景现在我主要是负责一款app的产品。不仅是有处理后台经验，还有做客户端前台的心得。

产品对技术都是在做产品过程中遇到的一种场景就是我们想让开发区实现一款产品，在实现的过程中也会对产品提出一些意见，就会出现以下的对话。

以上的这些对话开发以及听的很多了，最后他会有什么反应呢。

网上有一个经典的对联：

上联：这个其实很简单

下联：原理细节我不管

横批：明天上线

开发工作的评估开发工作量是交给技术经理或者技术自己评估的，但产品经理不知道评估是否是正确的。

一般面对这个问题会有两派的争论，正方和反方。

如果我们懂技术就能考虑产品有哪些功能的时候就能自己确定是否可以实现，成本有多大等等，更好的情况就是我们自己上手折腾。

而缺点是容易忘记自己是不是应该思考功能本身，也就是说这个功能应不应该做，做成什么样，应该在什么时候来完成，这些才是产品经理应该思考的东西。

同事呢，太纠结于技术本身容易忍不住说出自己的技术方案说出来，掺和到团队成员的专业领域，其实你懂的很多东西都是皮毛，但是你轻易的去和他们讨论，很容易被他们鄙视。把自己太多的东西投入技术，很容易分散自己的精力。

我个人的观点：产品本身是需要技术的，但是不要钻研太深，只需要有技术的意识就可以了。

我们需要知道的不是产品的技术实现，而是了解到导致整个开发和PK这个问题背后的原因是什么？那么其实很简单，就是沟通不顺畅。

我们要明白学习技术的目的，不是要去开发这些需求，也不要去码代码。而是明白技术能够做什么，能够在功能的实现可行性做取舍。理解开发说的话，站在他们的角度上思考问题。

这是我列的一个金字塔模型

从了解技术的层次来看，最基本的我们根本不需要了解代码本身，我们只需要把自己的产品逻辑数清楚。同时把产品相关的概念进行抽象画去处理，这样至少能够在逻辑实现和别人站在同一水平线。

如果我们已经有了一定的基础知识，通过一些手段能让开发瞬间理解。在这个基础上我们能跟进一步去提出解决方案或者能提出开发可能会遇到的困难，发现一些开发没有注意到的一些技术细节，这样会更好。

如果能够做到这一点，甚至能够做到和开发讨论具体实现细节，那你基本就是大牛级别了。

点到为止，一切从产品出发：无论理解技术有多深，都应该点到为止，不要纠结于技术本身，而是从产品出发。

底层：如何清晰的梳理业务逻辑！

希望大家能掌握两个维度的能力。第一个就是产品自身的业务逻辑，这和开发没有直接的关系，而是我们要清楚的自己的产品应该实现什么样的功能以及可能需要经历哪些步骤。

从根上来说就是根据每一个产品的不同使用场景和具体的流程来梳理产品的一个业务逻辑。

比如说电商导购的话他要处理的就是电商的购物流通；如果是内容管理系统的产品，无论是前台和后台要梳理的是每一步的一个状态流，包括内容中按钮是否开启，你的内容是否被转发，点赞或者评论，那么在点赞转发过程中又会触发系统什么样的其他行为。

举个例子，下面是我在设计过程中的业务流程：

我现在是做的一款艺人经纪找工作的产品，这里面详细的梳理出来一个人报名一个通道需要哪些业务流；发布通告在接收到艺人的报名之后应该要触发什么动作。

在我们熟悉自身的业务逻辑之后如果能够熟悉一些常见的技术功能的实现逻辑的话那就更好了。这里我总结出的常见的业务逻辑：

数据采集逻辑：

如果需要采集产品的基本数据，需要知道通过app的什么样的点击操作，把这些操作手机起来，让服务器记住你的这个数据，并且咱后台显示出来。

推送逻辑：

在收到push的时候，我们的服务器端是如何进行底层的交互的。那么业内的实现方案是怎么样的，比如常链接的方式是怎么样子的以及安卓和ios在这些逻辑上的区别。

数据展示逻辑：

至少知道app在收到数据之后进一步解析出现在我们面前的。包括页面的布局，刷新。

数据的存储逻辑：

了解服务端和客户端的数据存储以及关于存储数据的模式。

下一层：

在懂得技术术语的情况下和开发有效的沟通。

从三个方面训练自己

1 基本术语的理解。列举几个开发过程中的术语；

2 除了基本属于之外，还要了解开发人员之前所说的黑话；

3 怎么能够帮开发躲坑。

但是无论你都了解很多东西，但是还是会和开发争论。

当开发和质疑时你需要冷静，心平气和。之后就要讨论问题，理清产品逻辑找到问题所在，很多时候开发会找你理论一方面开发没有理解产品设计的思路，另一方面就是他自己针对这个产品有自己的看法。在这里推荐使用场景话的方法解释。

场景化的方式：

让开发从用户的场景使用这个产品，思考这个功能。如果能让他顺着你的思路在这个场景下完成这个产品的逻辑，那你基本就赢了。

有些时候我们用什么方法解释对方都会坚持自己的看法，建议就不要争论下去了，无非就是先有蛋现有鸡的问题，这时候就要先暂停，回去想好再进一步沟通。

这里并不是让大家一味的妥协，对于一些原则性的问题是不能退让的，还有一些基本产品设计逻辑。

如果以上的方法都不管用的话，终极大招就是找开发的老大，但是前提是你需要有充足的产品设计理由。

无论是用什么方法说服对方，一定要注意话术，对事不对人，避免人身攻击。

如何培养技术感，这里给大家一些建议。

兴趣：兴趣是最好的老师。对于我自己而言呢，我是很享受自己写的代码，被运行被实现。

找几本书籍看，这里推荐O‘Reilly深入浅出系列——Head First。最后就是实践，自己亲自敲代码，感受开发的想法。

就是希望天下猿汪是一家