大部分公司都是业务型团队，业务驱动不是技术驱动。一直觉得业务型团队没有太多技术含量，用的技术也都是比较成熟的。他们对技术没有特别的创新需求，他们最大的敌人是业务。越是大型项目业务场景就越是复杂，所以他们大部分时间都在理解业务，进行业务构架并最后落地到代码结构（可以理解为框架、封装、抽象、规范等）。他们不会像技术型团队，为了解决某个技术点花费几天甚至几个月，所以影响他们效率的绝对不是技术本身。
那影响业务团队的效率会有哪些呢？我和很多一线研发接触下来发现，难的不是写代码本身，难的是思路。如果有人帮他们拆分好、设计好，随便找个中级开发也能很快的实现。
1.业务场景的复杂，特别是半路加入的小伙伴，他们往往只知其一不知其二，哪怕是从一开始就在的小伙伴往往也只知道和自己关系密切的业务。缺少全局观，这样设计出来的东西自然会有很多隐藏的坑，然后为了填坑就会打很多补丁，补丁多了代码的可读性和可维护性自然就低了！这样开发效率自然就下去了。
缺少刨根问底的精神，其实只要你多问，再复杂的场景也能问清楚。
填坑方式：少用打补丁方案，如果觉得不合理宁愿重新做也不要将就。别用时间不允许用当借口，相信我你后面填坑和升级迭代所多花的时间何止这些。不合理的设计不仅影响迭代速度，甚至会出现很多本来可以实现的最后因为之前的坑无法实现，重点是这个坑你是知道的。
2.框架，一个框架的好坏直接影响团队成员的开发效率。这点我相信大部分人都比较有体会，越是复杂的业务场景越是需要一个为他而生的框架。
但是再好的框架如果没有标准和规范来约束很快就会变得乱七八糟的。我这里想强调的是除了标准和规范之外还需要通过review来检查他对框架的理解和使用情况。全review，越是新来的小伙伴越是需要，经过几次的review修改他的习惯也就改过来了。而且在review的过程中他也能更加清楚框架的细节，你也能从中了解到他的想法。全review虽然很花费时间，但是他的收益绝对值得你去花这些时间。（相当于1对1的辅导；整体风格统一；提高代码质量；思想的交换；等）
合理封装抽象，封装抽象减少重复开发，但是一定要合理，过度封装过度设计不仅不能提高开发效率还让开发更加复杂。有时候还真的不如拷贝多份代码来的快。
工具，严格来说它应该算是框架的一部分。一个适合的工具会节约你很多时间。不要为了做工具而做工具，工具的需求应该是建立在项目和现状痛点上。也不要说项目那么赶哪里有时间做工具，它后面所给你节约的时间要远大于你开发它的时间。没时间真的不是理由，如果用这个做为理由后面会越来越累越来越没时间。
3.一线管理者能力，沟通成本，业务经验，流程，等细节无一不影响这团队成员开发效率。想要提高人效就不能忽略任何一个细节，解决本质痛点，效率自然高了。让项目开发周期趋向于编码时间，你就赢了。这些问题我统称为细节，只能说具体问题具体分析，现在还无法总结出通用的方法论，等我想到应该如何描述总结再来补充。
