安身立命之本
总有人讨论，到底是“技术带动业务”，还是“业务带动技术”。
这确实是一个有争议的问题。
但是在这之前，我们需要知道，到底什么是“业务”。
维基百科上，对“业务”是这样解释的，
企业运用科学方法和生产工艺，生产出可交付用户使用的产品与服务，并以此为企业带来利益的行为。
所以，追求业务发展，是一个商业问题。
企业如果不获利，就不可能活下来，盈利才是企业正常运转的前提。
那么就是“业务带动技术”了吧？
并不尽然。
一些高科技公司，企业的产品就是技术，通过销售技术方案而盈利。
对他们来说，技术进步是业务发展的唯一办法，
不得不通过“技术带动业务”。
因此，当人们向我们矫正，一定要用“业务带动技术”时，
这实际上就是承认了技术革新并不是企业当前发展的瓶颈。
这也没什么错，每个公司都有自己的战略计划。
然而，对于工程师来说，能用自己的技术能力满足业务需求，
是在岗位工作而不被辞退的最低要求，无论这个业务具体是什么。
交付能力
团队也是如此，团队满足了业务发展的需求，就有能力存活下来，
如果没有能力交付，就有可能被解散。
然而，团队交付的项目，并不是最有价值的产品，团队本身才是。
团队内部进行了有效积累，之后才能以更好更快的方式交付新项目。
因此，找到适合团队自身的工程实践，并不是一个好的目标，
这种静态的观点很容易把团队带入误区，认为找到最佳实践就万事大吉了。
而实际上，持续不断的思考，高效的执行，才是最重要的。
从副产品的丰富程度，可以衡量团队是否有意识的进行了积累，
有没有梳理出项目相关的文档或规范，有没有总结出跨项目通用的开发过程，
有没有提取出可复用的类库或组件，有没有考虑团队的影响力和品牌，等等。
只有不断进步的团队，才能应对变化，
只有不断修正自身，不断成长，才能活得更好。
凝聚力
如果我们可以对比不同的团队，就会发现技术方案并不全是由业务场景而决定的。
虽然不同的业务场景，会导致人们选择不同的技术，
但是同样的业务场景，由于人员构成不同，仍然会导致不同的结果。
因此，是“人员”决定了“事情”怎样被解决，而不是反之。
有些事情，离开了那些人，根本就无法完成。
此外，团队成员中进行合作需要寻找平衡点，
两个人有两个人的平衡，多个人有多个人的平衡，
只有互相试探，不断斟酌，才能打磨出更好的合作方式。
因此，好的团队，总是把成员能力培养和沟通合作看做重中之重，
只有团队成员技术水平强大了，才能保证好的解决方案不断出现，
只有团队成员之间合作顺畅了，才能保证高效的工作状态持续发生。
参考
形成团队需要时间，团队成员也需要首先建立关系。他们需要学习如何互相协作，需要了解彼此的癖好、强项、弱项，最终才能凝聚成团队。团队比项目更难构建，专业的开发组织会把项目分配给已形成凝聚力的团队，而不会围绕项目来组建团队。
—— 程序员的职业素养
Don't base your venture on a plan. Instead base it on a strategic foundation. You can have a plan, but know that it will change, probably a lot. The plan is fluid, the foundation is stable.
—— How Google Works
