理清业务团队开发和业务的关系

关于开发是否应该深入了解业务，听到两种我觉得不正确的类型：

我的观点是要想当一个优秀的开发者，必须懂业务，不是为了跟产品 PK，而是为了预判未来的发展方向，好指导自己写的代码可以适应未来更久的时间。

懂业务，目的不正确型。

作为一个开发，不知道多少人经常会在耳边听到这么一句话：多了解业务，多了解业务。

但是大部分情况下并没有告诉你为啥要了解业务。

可能有些人心里会有这么一个答案：懂了业务可以在需求评审的时候可以跟产品 PK，指出他的需求不合理，然后给出一个合理的方案，这就是你对于业务的价值，然后就可以体现你的业务思考了；另外对于你觉得不合理的需求，还可以砍掉。

这是我听到最多的关于为什么开发要懂业务的观点了，我以前也是这么认为的，但是当我真正的作为一个业务 owner 之后，逼得我不得不去了解业务，我才觉得这个观点不完全对，方向都是错的。

上面观点的核心目标就是跟产品 PK，把产品作为开发的敌人去看待。现在网上很多这样的调侃，产品和程序员是对立的。

在产品的眼里，程序员天生就是爱砍需求。

而在程序员的眼里，会因为不会砍需求被老板教育，不要啥需求都接，要学会砍需求。

实际上，懂业务不是为了去指导产品设计，而是为了预判未来的发展方向好指导自己写的代码可以适应未来更久的时间。

懂了业务之后是去发现前端的“价值点”，不是为了跟产品 PK。。。。

你如果去指导产品做产品，反过来想想如果让产品指导你做开发，那能靠谱吗?

我很赞同玉伯说的专业度的问题，作为开发就是要在开发的专业度上表现出来，效率让产品业务都觉得不可思议。而不是让你的产品、业务能力表现出来让他们觉得不可思议(不是不行，但是这样很难，先把自己专业的搞好再说)。

另外还有一些是基本不怎么了解业务，就喜欢专研技术，这种想法基本是工作年限不超过三年的同学。刚毕业，对业务没有什么感知，觉得做技术的技术才是王道，整天喜欢研究各种新技术，处于一种被动接需求的状态。

这种情况就很容易在晋升的时候无法说清楚业务价值，到底自己做的东西有什么用，给公司带来了什么价值，因为在做需求的时候本来没有去思考过业务价值，所以没办法形成闭环，仅仅只是零散的需求。

实际上，我们应该这样做，在业务的背景之下，我们可以主动的发现问题、定义问题、解决问题、优化效果，拿到结果。这才是创作个人业绩的正确路线。

如果不懂业务，怎么将技术放到业务里去？不放到业务里去怎么体现技术的价值？

你不能光讲我做了一个什么东西，这个东西多么多么好，这个业务价值如果没有体现出来，那就是没用的。

上面分析了两种思维模式的差别，以及我觉得正确的思考方向。

作为一个在业务团队的开发者，我们做一件事的时候，需要时刻提醒自己，要想清楚三个问题：

你们觉得作为一个业务团队的开发，业务和技术的关系应该是什么样的呢？