聊聊我眼里的产品思维
两个问题
一年前，我是一个两年经验的开发，还没形成自己对产品思维的定义，一直以来，我都觉得这个东西有一点“虚”，只有写代码实现功能才是真的，给个文档让我开发就得了，有 bug 改就是了。
其实也会有问题困扰我，只是我一直没有好好地去思考。
Q: 功能为什么要这样子开发？
A: 因为产品让我这么干
Q: bug 是怎么来的？
A: 无非是代码写得不仔细，多个 case 漏考虑了，变量名函数名手抖写错了，基础知识不牢固，比如弄不清楚变量的作用域等等等等各种问题。
现在我的答案
我在现在的公司呆了快一年，经历了一年团队从无到有，从 xjb 开发到现在规范化的开发，看到了一个团队是如何磨合，一个产品是如何迭代，打磨，正所谓读史使人明智，亲身去经历这一段，并且一直站在全局的角度去思考问题，对上面的两个问题又有了新的认识。
Q: 功能为什么要这么开发？
A: 一般公司的产品都是市场导向，因为这么干赚钱，不赚钱的事儿，谁也不会做。我现在把以下几点视作是有产品思维
- 明白公司怎么样能赚钱，不要求细节面面俱到，只是一个大方向，所以有时候 boss 和市场部吹牛，也是可以去听听看的
- 明白公司产品在市场上的地位，和竞争对手的比较优劣，有时候产品经理就会让你做这个功能，你一脸懵逼，为啥？其实有时候真是因为 “别人有，咱也得有。”
Q: bug 是怎么来的？
A:
在这里我们先思考一个问题，一个成熟的团队，市场部门，产品部门，研发部门，测试部门之间应该是一个流水线，也可以理解为责任链，每一个部门的输出是下一个部门的输入。如果把研发当作一个机器人，（实际上按照他们的工作方式看，就是）。
那么，研发做事的风格，就是无脑根据产品给出的东西进行开发，本职工作无可厚非。
所以，只要产品部门的输出没问题，除了代码写得不仔细，应该就不会有其他问题了吧。
并不，实际上有很多 “不是 bug 的 bug”，是因为产品部门的输出有缺陷，我们把研发部门当作一个黑盒，有缺陷的输入当然会导致有缺陷的输出。
因此，有另外一个做事的风格， “杠精”，对于产品给出的东西，不能全盘无条件接收，这也是我们常常说的 “撕逼”，但是 “撕逼” 不是将难以实现的需求怼回去，而是从 “好不好用”，“能不能赚钱” 的角度去思考设计上合理与否，否则，一个研发周期在走到最后才重新改动需求，是非常难受的，尽管锅不是开发的。
我把这种 “杠精” 的风格也定义为 “有产品思维”，也就是以全局的角度看问题，以市场结果为导向看问题，以公司盈利目标看问题，或者说得粗糙一点，就是对自己做的是什么，心里有点 b tree。
感想
这是我参加工作第三年得出的一些结论，仅以此做一个笔记，希望以后的工作里，我会有更深刻的结论。