软件工程定义的价值
软件工程领域最核心的价值点通常是围绕：提高软件质量、开发效率、满足用户需求。
- 质量保证（Quality Assurance） ： 软件工程的核心目标之一是确保软件产品的高质量。这包括软件的可靠性、稳定性、可用性、可维护性和安全性。通过实施严格的测试流程、代码审查、持续集成和持续部署（CI/CD）等实践，可以提前发现并修复缺陷，从而提高软件的整体质量。
- 用户中心设计（User-Centric Design） ：以用户为中心的设计强调软件应该围绕用户的需求和体验来构建。这意味着在软件开发过程中，需要进行用户研究、需求分析和用户反馈收集，以确保最终的软件产品能够满足用户的实际需求，并提供良好的用户体验。
- 敏捷开发（Agile Development） ： 敏捷开发是一种以人为核心、迭代和增量的软件开发方法。它强调快速响应变化、跨功能团队合作、持续交付价值以及客户合作。敏捷方法论如Scrum和Kanban等，帮助团队更灵活地应对需求变化，更快地交付软件，并且能够持续改进开发过程。
软件工程实际落地的价值
理论和现实中间往往都有的一定鸿沟。业务需求通过软件工程在实际落地过程中，前期有两道难关要过。一是，针对需求产品设计的PRD文档质量，这个入口文档质量的好坏会直接影响工程人员对需求价值的评估，如果过于复杂工程人员就会挑战设计的合理性以及投入产出比；二是，每个需求基本都会涉及到公司的多部门协作，这个需求对整体也许很有价值，但是拆到各个部门，这个价值的评估就会被削弱，经常会出现部门边界问题的各种争论。
实际案例
在出行领域，一个公司要具备核心竞争力，要么成为优势的流量入口平台，要么成为优势的运力入口平台。而这其中，流量入口平台的价值又要高于运力入口平台，这也造就了高德作为一个流量聚合平台，携众多运力厂商能够与滴滴抗衡的局面。
需求背景：
我们公司作为一个流量和运力都独立运营的出行平台，目前吸引流量的明显能力不够，只能把运力挂靠到各家流量平台去出售服务。但是，在打车需求的低峰期，公司的运力依然处于空闲状态，运力效率得不到满足。
在这样的背景下，公司就想把空闲运力出售给其它流量平台（简称A平台），形成一个共建运力池，对于共建的运力，双方可以共同来使用。但是双方的合作模式如下：
- A平台：
- 负责共建运力的选定和释放。
- 保障共建运力的基本收入，如果收入不足，需要进行补足。
- 我们：
- 负责共建运力的实时服务信息管理，并且及时上报给A平台。
- 负责共建运力的派单策略控制，对于共建运力优先派给A平台的需求。
需求进一步迭代：
在第一期项目完成后，A平台想进一步增强自身管控运力的能力，在双方公司商务的洽谈下，最终确定由A平台负责共建运力的派单。这个项目对于公司整体来说有收益和价值，但是对于我所在的团队来说就不一定了。
我们团队承担的核心职责有两块： 服务运力的管控和智能的策略决策（派单）。如果按照双方的对接约定，A平台后续的发展就是要把运力的管控和派单决策迁移过去，这就相当于把我们团队的核心能力给架空了，这个过程还需要我们的研发人员来进行协助。
说得更直白一点就是：A平台想要替代我们的团队，还要我们来帮助他们提效，更快的灭掉的自己。这对于我的团队来说肯定是抗拒的，但是业务侧在推动这件事情的运作，作为一个研发Leader你怎么来处理这件事情？
基于价值来谈的话
其实在沟通前你就带了立场，你把屁股放在了自己的团队，你就一定会说这个需求对于我的团队没有任何价值，团队协助他们完成这个事情就是为了更快的替代我们，那我们团队根本就没有动力去做这个事情。
这个时候业务人员肯定就会说： “这个事情对于你们团队没有价值，但是对于公司有价值；你们不能只站在自己的视角来考虑问题。”
这个时候双方肯定就会来回掰扯，那么业务价值和软件工程领域的价值怎么来取舍？
如果公司是以业务主导盈利来牵动的，肯定就是业务的价值高于软件工程领域的价值；如果公司是以技术主导盈利来牵动的，这个时候可能会偏向技术工程领域。
我们公司是业务主导来牵动，技术作为手段，肯定要向业务让步。从价值的维度，来谈这件事情肯定拗不过业务侧；并且软件工程领域本身就有很多脏活、累活，没有太多实际的业务价值；那么这些活是不是可以不用干了。
基于领域来沟通
从上面来看，基于价值的维度是没有办法沟通的，业务的价值和技术的价值本身就不是一回事。那就回归到技术本身，事情要不要做业务说了算，事情怎么做技术说了算。
既然事情一定要做，那么我们就要想想怎么做对我的团队伤害更小。团队要深耕自己的核心技术领域，不能主次颠倒让不重要的事情占据了主要位置，这件事情对于我们团队就处于很次要的位置，最好都不要跟团队有关联。那就要基于技术领域来沟通，这个事情属于哪个团队负责。
我们团队的领域职责：管控公司内部运力的服务。那么对于两个公司合作共建运力属于公司内部运力吗？
这个时候就要把定义说清楚，不然双方就很容易纠缠不清。共建运力属于两个公司合作一起管控的运力，那么谁是主要管控方，谁是次要管控方？
从需求背景来看，A平台负责运力的选定和释放，并且承担了司机收入兜底补偿，并且运力的状态还要及时上报给A公司，方便他们及时管控，所以很明显A平台是共建运力的主控方。
定义清楚了，接下来就要讨论谁来做的问题
从定义的角度，这个领域不属于我们团队的范畴了。但是这块功能本身就是一块新的领域，公司内部目前也没有明确的职责划分，那么这块能力归属于哪个团队来做呢？
这个时候，如果你的职责是一个团队负责人，你就比较难去说服其它团队，因为你本身就带了立场，然后说多了就有点像推卸责任。那就要把这个事情上升，要公司级的架构师和技术负责人，来衡量这件事情的归属方。
因为他们的职责和立场，会决定这件事情最终的归属方。这时其实本质上也是对公司级架构师或者技术负责人的挑战，一旦沟通不清楚或者决策错误，就会让下面的人对其产生质疑，甚至失去信任。我之前就碰到过这样的负责人，不是基于客观的事实来沟通，而是基于与团队负责人的关系来决策，最终导致没有团队愿意要他来决策，也让各方对其失去了信任度。
总结一下
软件工程从公司的整体布局来说一定是有其价值的。但是，最终划分到了各个部门、各个团队、甚至各个小组，这个价值就不一定这么明显。如果只基于价值来沟通事情，容易导致事情纠错不清，原因主要有：
- 需求的价值，由业务来决定，并不是由技术来决定。
- 工程领域本身就有一些脏活和累活，这些事情的价值谁来衡量。
- 对于新增的空白区功能，基于团队的价值无法覆盖。
那么软件工程划分边界正常都是基于领域DDD的模式，每个团队的领域是需要定义清楚的。领域内部的事情，不管有没有价值，团队都要做好支撑，因为这个就是你们团队的本职工作。
对于上面这种情况，如果团队Leader思路不清楚，可能也就自己团队默默的干了。但是，团队的Leader要清楚自己团队的价值，不管就经常会导致团队成员加班加点干了不少事情，结果拿不出有价值的产出来证明，导致整个团队都吃力不讨好。
再往上沉淀一层，就是技术人员，一定不能惧怕困难，要有迎难而上的勇气。这个勇气，不是指蛮干的勇气，而是指要有挑战你头脑中未知和难点区域的勇气，如果你在脑力上偷懒了，那么你就会在体力上加倍付出。
