写在前面
本文是一个前端看完了一本产品书，结合日常工作，有感而发。写了一些这本书带给我的思考，我工作中的困惑以及对未来的一些想法。
作为一个前端开发，从业以来第一次跟产品打交道是进入zhy之后，之前产品经理于我而言，只是一个title，现在已经是具体的个体们了。
从前，作为一个驻场前端，我的任务就是把设计稿变成web界面，把逻辑用js表达出来，用户需求就摆在那儿，用户自己也摆在那儿。最让我痛苦的是交付前1-2天的通宵。
现在，grooming、需求评估成了日常。
某一天，有人告诉我我需要去思考产品的需求是否合理，有没有更好的方案。坦白说，刚听到的时候我是震惊并抗拒的。毕竟它严重超出了我的专业范围，甚至了解范围。
但是随着一个一个迭代过去，事情的发展也逐渐超出了我的预期。
至少一年前的我是无法想象有一天我会捧着一本名叫《从点子到产品》的书，副标题《产品经理的价值观与方法论》。
封面就告诉你说，这本书是写给产品经理的。
但好在我的theory是万事万物都是相通的，看一本教你做好产品经理的书，不代表不能帮助你成为一个更好的前端啊。
所以我还是毅然决然地翻开了它。
1. 用户痛点与产品价值
前几天群里发了一个我们产品的订单，是个大客户，有个同事跟我聊说，我们产品真的值这么多钱么，他会啥要花这么多钱买我们的产品呢。我义正严辞地说，我们产品当然值啦。然而其实一直以来我的内心也有这个疑问。
"解决了用户的痛点"才是让用户使用我们产品的主要因素，以及体现产品价值的关键
书上的这句话解答了我的疑问，我们的产品解决了用户的痛点，帮助用户降本增效，给用户带来了收益，所以他愿意花钱购买我们的产品。
我想起了很久之前有个大佬说产品定价，就是看我们的产品每年能替用户省下了多少钱，除以10，就是我们的定价。
确实如果有个产品能让我的成本每年少一千万，我为什么不愿意每年付他一百万呢。
找到产品的核心价值
我目前在做的这个产品已经有快5岁了，成长曲线也是比较起伏的，我加入的时候应该是它比较低谷的阶段。大家都处在一个迷茫的阶段。每个人提起这个产品都是说找不到方向，还在寻找方向类似的话语。
现在回想起来，真的，还好当时我对产品一无所知，所谓无知者无畏，我一直都是充满信心在开发。
而今年我们有了一个比较明确的方向，正如书中说的，找到产品的核心价值。
有了核心价值，一切需求都围绕它展开，即使前进路上有冰山，绕过去，方向始终是那个方向。有了明确的方向，确实能感觉都大家信心更强了，对于产品也有了更高的期待，自然愿意付出更多的心力，这种正反馈必然能够帮助产品向上走。
达到可用与最小成本的平衡
现在做每个需求的时候，最关注的是PRD里的价值点，每个迭代过程中增加小需求的时候也会记得问一句是否有价值。我们都希望每个需求都是针对用户的痛点，能够实实在在地解决用户的问题。而不是我们花了大力气去做，最后发现根本没有人使用。
2. 从需求到功能
我们可能会常常想用户有什么需求，我们就提供，往往忽了略从需求到功能之间还有一条很长的路。
用户不会把界面和逻辑通通事无巨细地给到你，通常就只有一个想法。
就好像我们都有点外卖的需求，但这个需求和美团APP之间隔了多少代iphone呢。
回到一开始提到的去思考产品的需求是否合理，其实准确地说是思考用这个功能来满足需求是否合理，能否满足，是否是最优解。
人们对于针对使用或期望使用的产品、系统或者服务的认知印象和回应
所谓用户体验，在我看来，就是让用户能够得到他们想要的，并且轻松、顺利地得到。
我现在的这个产品，是有一定的使用门槛的，在开发的过程，我尝尝感觉到产品会在专业用户和大众用户之间摇摆，希望大家上手就能用，但是很多功能确确实实又是需要用户具备一定的知识。这种摇摆就会导致在用户体验上很容易出现问题，往往会出现两头不讨好。专业的用户希望进来我就可以自己发挥，然而为了兼容大众用户将入口设置的比较简单；而大众用户从简单入口进来后发现一些很专业的东西又容易被劝退。这之间的平衡如何掌握或许市场才能验证吧。
比起100万个普通粉，宁愿要100个脑残粉
前几天一个消息震惊了我，我们的产品要跟公司的另一款产品合并。
刚听到这件事的时候，我的内心是充满疑惑和抗拒的。大概是因为这个变动太大，充满了未知，而未知总是令人感到恐惧的。
但是未知往往也是充满期待和惊喜的。
进入瓶颈期或许是大多数产品无法避免的，而改变往往是走出瓶颈的唯一方式(其实我还蛮好奇这个需求的衍生过程的)。但是无论这个改变有多大，过程如何，我们必须要保证现有用户的体验，无论是怎样的目标，都不能以牺牲现有用户的体验为代价。
3. 产品管理
管理这个词对我来说很近，我要管理的东西很多，我混乱的桌子，我整齐的文件夹，我的学习计划，我的生命线等等等等。而产品管理这个词于我似乎很遥远，管管代码比较亲切。什么是产品管理呢？
产品经理要不要懂技术
有一个懂技术的产品经理真的很棒，你们沟通起来是没有障碍的，他可以听懂你的话，明白你的难处，知道如何发挥你的优势。就很棒！
我印象很深的有一次一个需求我评估了一下发现有个难点很不好搞，我跟我们产品经理沟通了一下，真的就我说了他就理解了，表示确实是这样的，当时我真恨不得抱起他转两圈呀。所以网上很多程序员吐槽产品经理的段子我一直共鸣不了。
其实懂这个词是一个很宽泛的词，入门也可以是懂，精通也是懂，会写java是懂，了解它的运作机制也是懂。
我觉得产品经理不需要会写代码，不需要懂使用的语言，使用的框架，但一定要懂我们用的框架能做什么不能做什么，为什么能做为什么不能做。这样背景下的需求必然是具备可行性的，不至于出现根据手机壳颜色自动设置桌面背景的需求。
正在写PRD。。。
这是我们产品经理的签名。真有意思。
最开始开发需求的时候我是不看PRD的，因为不知道他是个啥，后来偶尔想起来会去看一下，看看要做啥。而最近的一些需求我都会认真阅读PRD，你能从中看到这个需求的来源，它的目的，它的意义，它解决的问题，它期望的效果。
最近一次需求，因为不是我评估的，前期少了很多思考，做的时候确实遇到不少问题，我在看完PRD之后改变了第一版开发方案，因为它给我提供了新的思路，还是一个更省时省力的思路。
取势、明道、优术
曾经有一段时间我很疑惑为啥每个迭代都有需求，咋没有真空期的呢，后来发现原来需求茫茫多，出现在我面前的都是VIP需求。
所以有个东西叫做需求池，池子里有红鲤鱼绿鲤鱼。。。池子里有各式各样的需求，紧急且重要、不紧急但重要、紧急不重要、不紧急不重要。书上提到了如何判断是否重要，我觉得还是很靠谱的
- 不做，会造成严重的问题和恶劣的影响
- 做了，会产生巨大好处和极佳效果
- 跟核心用户利益有关
- 跟大部分用户权益有关
判断是否紧急
- 不做，错误会持续发生并造成严重影响
- 在一定时间内可控但长期会有糟糕的影响
- 做了，立刻能解决很多问题、产生正面的影响
- 做了，在一段时间后可以有良好的效果”
懂技术，写好文档，理清需求转变为完整的方案是不是就能把产品管理的不错了。
4. 技巧和方法
书的最后一部分讲了一些产品经理工作中可以使用的方法和技巧，我觉得不仅适用于产品经理吧。作为一个前端，跟我的适配度也是杠杠的。
处理问题
在工作中，我觉得最不爽的就是有问题，但是最开心的也是有问题。
不爽在有问题，说明我没做好，不是没考虑全面就是没考虑很全面。
开心在于，有问题就代表有能学到新东西啦。
发现问题 - 分析问题 - 解决问题 - 总结归纳
沟通
前面说产品懂技术，跟开发沟通起来就很顺畅，毫无障碍，那么开发想要无障碍地跟产品沟通，也需要懂产品相关的知识，这也是我读这本书的意义之一呀。
成长
我一直坚信成长不是一蹴而就的，它是一个漫长的过程，你可能永远也感觉不到自己的成长，但是某一天你会想起从前会发现，啊，我已成长至此。
1年多以前我刚进入这个公司，开始做这个产品，我记得我们master在一块智慧屏前，给我手写了我们这个产品的历史，介绍了它的背景故事，发展故事，前因后果，如此种种，当时听了只是感叹，外加觉得master好厉害哇，再没有更深的思考。而现在会在每个需求中去想到它的发展过程，去完善它的因果关系，去设想它的未来。
1年多以前我是个遇到问题就百度google，解决了很有成就感的小前端。现在我会先分析，回去看源码，去找到问题的根源所在，找到解决办法。
我永远承认自己的无知，永远追求知识。
兴趣和热情
人的一切痛苦，本质上都是对自己的无能的愤怒。
我不知道作者咋想的，要在兴趣和热情标题下写这么一句话，我第一次听到这句话的时候就很不喜欢这句话，这大约就是对自己的无能的愤怒，多么讽刺。你改成，唯有热爱可抵岁月漫长，多好。
但是他说的兴趣不是天生的，我非常认同。
我很热爱前端这份工作，对它的兴趣是我不断去学习的动力。我不认为它是天生的，而是我在认真的做着这份工作，我能在其中发现很多很多的乐趣，在写出一段好代码时，在解决一个难题时，在掌握一门新技术时，那种快乐时无与伦比的。凡此种种，都是我去做先，兴趣随之而来。
结语
感觉越写越放飞自我，越写越离题了，最后再找补一下。
看《从点子到产品》这本书，带给了我很多启发，很多思考。它分析了很多现实中的案例或成功或失败的原因，或者能帮助你少走很多弯路。
作为一个前端，也对产品的种种工作有了更多的了解，希望有机会能在实践中验证理论。
