大家好，我是 哈士奇 ，一位工作了十年的"技术混子"， 致力于为开发者赋能的UP主, 目前正在运营着 TFS_CLUB社区。
💬 人生格言：优于别人,并不高贵,真正的高贵应该是优于过去的自己。💬 📫 如果文章知识点有错误的地方，请指正！和大家一起学习，一起进步👀 🔥 如果感觉博主的文章还不错的话，还请 👍 关注、点赞、收藏三连支持 👍 一下博主哦 🏆 CSDN博客专家认证、新星计划第三季全栈赛道MVP 、华为云享专家、阿里云专家博主 🏆
专栏系列（点击解锁） 学习路线（点击解锁） 知识定位 🔥Python全栈白皮书🔥 零基础入门篇 以浅显易懂的方式轻松入门，让你彻底爱上Python的魅力。 语法进阶篇 主要围绕多线程编程、正则表达式学习、含贴近实战的项目练习 。 自动化办公篇 实现日常办公软件的自动化操作，节省时间、提高办公效率。 自动化测试实战篇 从实战的角度出发，先人一步，快速转型测试开发工程师。 数据库开发实战篇 掌握关系型与非关系数据库知识，提升数据库实战开发能力。 爬虫入门与实战 更新中 数据分析篇 更新中 前端入门+flask 全栈篇 更新中 django+vue全栈篇 更新中 拓展-人工智能入门 更新中 🔥全域运营实战白宝书🔥 运营角色认知篇 初识运营，明晰运营的学习路径 高转化文案速成篇 三种文案形式，抓住特点才能下笔如有神。 策划活动与执行篇 更新中 新媒体运营篇 更新中 社区运营篇 更新中 私域社群运营篇 更新中 运营数据分析篇 更新中 低成本渠道推广篇 更新中 网络安全之路 踩坑篇 记录学习及演练过程中遇到的坑，便于后来居上者 网安知识扫盲篇 三天打鱼，不深入了解原理，只会让你成为脚本小子。 vulhub靶场漏洞复现 让漏洞复现变得简单，让安全研究者更加专注于漏洞原理本身。 shell编程篇 不涉及linux基础，最终案例会偏向于安全加固方向。 [待完结] WEB漏洞攻防篇 2021年9月3日停止更新，转战先知社区等安全社区及小密圈 渗透工具使用集锦 2021年9月3日停止更新，转战先知社区等安全社区及小密圈 点点点工程师 测试神器 - Charles 软件测试数据包抓包分析神器 测试神器 - Fiddler 一文学会 fiddle ，学不会倒立吃翔，稀得！ 测试神器 - Jmeter 不仅是性能测试神器，更可用于搭建轻量级接口自动化测试框架。 RobotFrameWork Python实现的自动化测试利器，该篇章仅介绍UI自动化部分。 Java实现UI自动化 文档写于2016年，Java实现的UI自动化，仍有借鉴意义。 MonkeyRunner 该工具目前的应用场景已不多，文档已删，为了排版好看才留着。
文章目录
- ❤️🔥 决策判断型问题的解决思路
- ❤️🔥 解析型问题的解决思路
- ❤️🔥 沟通协调型问题的解决思路
在上一章节，我们为各位小伙伴介绍了 “产品经理” 日常面临的一些问题，接下来我们就介绍一下，面对这些问题 “产品经理” 都是如何去解决的。
❤️🔥 决策判断型问题的解决思路
决策判断型问题的解决思路有如下 三段式 的解决思路，接下来我们以一个案例来进行整体的分析还原一下，案例如下：
来自老板的需求，他想将产品增加一个聊天室的功能。经过我们的一个开发成本计算，可能会需要 2名 开发人员的 20天 开发周期，20天 的测试周期，如此高的开发成本浪费了大量的时间和人工成本上线一个不知道又没有人用的功能，所以要不要舍弃其他功能的开发和上线？ 这就是一个摆在 “产品经理” 面前的一个最严峻的问题。
如果我们想要去解决这个决策判断的问题，解决的思路有三个：
- 首先我们需要
明确问题的成本和收益
- 关于成本：如果我们开发聊天室这个功能会消耗怎样的
时间成本、人力成本以及机会成本。尤其是机会成本，如果开发了 聊天室 功能，而其他的功能的效果要比聊天室功能更好的话，这里损失的就是机会成本。- 关于收益：老板不可能没来由的想要开发一个聊天室功能，该功能肯定是对当前用户是有帮助的，那么对多少用户有帮助？有多大的帮助？这样类似的效果最好能够量化出来。
- 用数据来
明确出客观可衡量的标准作为成本和收益的对比。
- 除了成本和收益之外，还需要
明确当前状况，指代如下内容
- 产品目标是什么？当前的产品处于什么样的阶段？
- 这里就要求我们将目标
向前看，基于以终为始的思路来判断当前的状态是否符合规划的方向，如果产品的设计初衷没有社交领域方面的规划，而当下却又去做一个群聊的功能，是否对达成核心目标是有帮助的？- 如果有帮助，则继续去推进该功能。如果没有帮助，那么确确实实可以相对的延后，甚至不做。
- 明确当前状况，更需要明确预期的达成的目标。
- 最后一个要说的就是
给出投入产出的最优解
- 判断当前新功能是否对产品目标有较大的
正向影响，如果有，毋庸多说、直接开整即可。- 如果权衡之后发现
不符合产品的定位，则果断延后，甚至于可以直接放弃。- 最常见的情况是
部分符合目标，可能与产品目标、定位有一点点的相关，但是相对的又无法进行有效的评估。这种情况下，建议可以将优先度进行降低，给出一个最小的可行性方案(也就是不需要两个人或者说不需要40天的解决方案与小规模验证的操作)，轻量级的小成本试错的决策型判断解决思路。
以上就是通常的决策型问题解决思路。
❤️🔥 解析型问题的解决思路
同样的，依然举一个例子来进行整体的分析，案例如下：
我们的产品刚刚上线了一个 "评论" 功能，怎么样才能让用户更多的发表评论？ 关于这样的一个问题，依然是有 3个 解决的思路。
- 第 1 个：
明确问题的现状
- 这个功能是做什么的？为什么要做这个功能？当初设计这个功能的时候有着怎样的一个期望？该功能相比较其他的一些功能有什么不一样的地方？可以给到用户使用的理由？
- 像以上这些问题，都需要我们先去确认，然后再进行解析。
- 第 2 个：
进一步梳理问题产生的逻辑链
- 如果想要让用户发表评论，应该如何设计产品流程去触发 “评论” 的一些场景？比如说用户看完一篇文章的时候，引导用户表个态、发表一下阅读感受等等。
- 在这样的一个环节内，我们可以为用户做什么？以及说，当用户完成了 “评论” 这个流程，我们可以给到用户一个什么样的反馈？
- 这些都是可以梳理达成目标、完成这样一个功能的使用，需要哪几个环节。
- 第 3 个：
在整个问题链条中设置关键控制点，找到影响问题的关键点
- 这些控制点如果完成了，有可能我们的问题也就顺利的解决了。
- 就这些要被解决的问题，我们可以提出多个可能所带来的问题的假设。比如
假设用户会使用这样的功能，在这个基础之上给出调整点，观察调整过之后对结果的影响- 针对 “发表评论” 的功能，设计一些诱发的因素，比如说可以发评论来获得积分，或者说发表评论获得一定的奖励，比如一些类似于 “评论家” 、“最佳答主” 等等的荣誉奖励。利用这样的一些控制点，查看用户是否会因为此而带来长期的留存，或者说愿意持续的使用 “评论” 的功能。
- 如果有正向的影响，则继续优化；如果没有，则放弃等等。
其实我们会发现，针对这样的解析型问题，就需要把这些问题具象化，将问题的整个逻辑链路去梳理清楚，并且在这些链路里面去设计一些能够让问题有正向解决方案的关键点。去做实验，如果用户触发了，确实能够让问题有一个良好的解决，就应该让这一些问题的解决方案进一步的强化，该模式与 “决策判断型问题” 的小规模试错的解决思路比较相似。
❤️🔥 沟通协调型问题的解决思路
继续举例子，以此来说明 “沟通协调型问题” 。如下：
假设我们需要让兄弟部门实现一个接口，接口的目的就是让兄弟部门产出的内容能够在我们自己的平台上显示出来。最典型的例子就是，我们的产品可能是一款工具型产品，但是我们想要在工具型产品上展示新闻。但是我们自己没有生产新闻的能力，但是我们可以让新闻部门的同事将他们产出的内容直接嫁接到我们的产品上，这个时候肯定是需要对方支持的。
在寻求支持的这个环节里，依然是有 3个 方法步骤。
- 第 1 个：
找到沟通双方的共同目标（也就是需要回答对方为什么要把他们的内容给到我们）
- 对方的目标是什么？我们的目标是什么？这两种目标有哪些部分是可以交集的？
- 兄弟部门的目标是内容的曝光、内容的点击；而我们的目标则是借助内容去提高用户的让停留时长，从而进一步达到留存的目的。这两者之间的目标是互相匹配的情况下，那么这件事情就能够继续推进下去。
- 第 2 个：
明确合作目标、合作期限、合作结果利益分配的规则
- 这里需要计算双方达成共同目标，分别都需要投入多少的成本。比如说对方只需要投入一个接口开发的成本，而我们需要投入基于这个接口开发的完整的解决方案。
- 在这个解决方案里，我们需要考虑更多的能够帮助兄弟部门带来的曝光量，曝光量就是兄弟部门希望获得的收益；我们的收益就是基于内容的曝光量带来的用户停留时长与留存。这样的一个合作方式，所寻求的往往是双方都认可的目标，这些都是需要提前说清楚的。
- 第 3 个：
明确接口提供人、对接的方式、及时同步信息，定期的向双方汇报
- 这里需要明确双方的参与人员、双方的接口提供人员，以及干系人(领导)都需要知道，尤其是双方的领导需要达成共识。
- 及时同步合作的信息，并且向双方去汇报合作的进展，让整个沟通协调的信息是公开透明的。
- 如果能做到这一步的话，其实整体的沟通、协调、推进的过程应该会更加的容易了。
以上就是 “产品经理” 遇到问题之后主要的解决思路。
