开发人员也需要有点产品思维

听公司内部大佬的产品思维分析，以自我的视角的整理一下, 本文分为三个部分：

什么是产品思维

做为一个研发，要精准定义产品思维有点难，简单理解是针对在满足用户需求的前提下提供较好的解决方案。首要条件是满足用户诉求，进一步成就用户，其次产品针对的不是个体，二是群体，就要求将个体诉求进行一个抽象，提升普适性，进而给出一个完整的产品解决方案。

针对研发人员，相对于了解怎么去创造性或模仿竞品给出一个解决方案，更应该关注理解产品给出的解决方案：

通过了解产品的全貌，知其然，进而认识设计的逻辑，知其所以然。

产品思维要求我们知其然也知其所以然，这样可以避免我们只是一个工具人。工具人是一种可替换的资源，你可以，别人也可以的。研发自我定位应该是资产，而不是资源。资源是消耗品，可替代性高。资产不一定能升值，但至少保值，其价值体现在能和产品一块共同创造产品。可以从三个纬度来说明为什么需要产品思维：

我们都是社会性动物，需要被认同。这个可以参考马斯洛需求层次理论存在不仅仅是为了解决温饱问题，需要有更高层次的精神诉求。试想一下当我们提出一个观点时，都希望被认可，被赞同。同理产品也是人，也需要被认同。但我们参与到产品中，了解事情的意义之后，能共同参与讨论，提供建议，这对自身而言更加具有归属感，从而能提升我们整个的投入度来协助产品完成这个事情。
提升研发效率。修路或修桥，一般都是两端并行开始，最后合拢，这样才是最快的一种方式。应用到我们工作中也是一样的，只有产品和技术齐头并进一块把事情做好，而不是一端来做这个事情。理解产品背后的逻辑，提前储备相关的人或技术，一定开始做具体的事情，快速取得效果。
增强信任感。人与人之间先相知才会相爱，没有相知，也就没有一起沟通的基础。同样的逻辑如果我们都不知道产品的需求是什么，不了解为什么需要做，怎么会信任产品，怎么能做好事情。了解产品需求的原由，结合现状给出合理的建议，减少双方的摩擦，这样才能互相理解。理解是合作的基础，也是信任的必要条件，否则：

当然具备产品思维之后，还是需要回归到我们技术本身，需要做到源于需求又高于需求。服务好业务的同时，也需要对业务的进行抽象，从而产出技术的规划。

技术人员做为产品需求的实现者，会需要了解更多的产品细节，有些细节可能在需求文档中没有体现，之前有类似的可能就那样做了。这是我们的职责，但需要进一步转换为我们的优势，也就是能自底而上的了解整个产品、业务的全貌：

多看和多用。当了解一个需求细节时，需要主动多想想上下游的依赖，多去看看相关需求文档，用户手册等，也可以多体验线上的系统。把一个个孤岛系统串联起来。
多问和多想。很多时候我们都会陷入一种我以为你知道，所以就没有写。但发现问题或者不理解时需要多问问，问问题的过程中也能了解更多的前因后果，帮助我们更好的理解背后的逻辑。同时站着用户的角度，帮产品一块思考有没有更好的解决方案。也可以从技术角度给出些合理的方案，例如是否应该先借助 xx 验证，然后再落地。
追求极致。对我们自身业务属性的同时，也去看看竞品是怎么做的，是不是别人的交互流程更顺畅，页面体验会更好。或者有没有其他日常使用的系统体验更好，流程更短，能和业务结合从而有更佳的方案。

做为研发同学，我们的产品思维不是如何去设计产品，重在理解产品设计背后的逻辑是什么。理解背后的逻辑，帮助产品，提高实现的效率，同时也降低风险。有时候产品也是很迷茫，需要的不一定是赞同，如果从技术角度发现不可行，对产品来说也是一种『解脱』。同时了解产品，最主要的还是帮助我们做好规划，从而升职加薪。