软件是为了提供价值而存在的，但是价值的兑现形式却多种多样，
彼得·德鲁克 在《卓有成效的管理者》中提到，
知识工作的价值，必须经过转换才能产出成果。
一个电商网站在那里放着，没有什么价值。
只有当有人用它创造了收益，才真正产生了价值。
它的价值体现在交易链路中很小的一个环节。
除了这种面向业务的软件形式之外，
还有一种典型向开发者提供服务的软件。
比如说，一个通用工具，一个框架，一个研发平台，等等。
这些软件所产生的价值，就更不好衡量了。
本文就针对这种情况进行一些反思。
不确定性
为开发者提供服务的软件，它的用户（开发者）并不为这些软件买单，
通常为这些软件买单的是开发者所服务的公司。
即，公司愿意投入一些成本，购买或自研这样的一些软件服务。
所以这些服务的提供者，必须向公司证明这样做是值得的。
这是一件比较难证明的事情。
因为大多数的软件开发任务都有很大的不确定性。
我们很难说一个结果是由单一因素影响的。
另一方面，提供开发者服务之后，用户（开发者）的体验即使能够得以提升，
但是最终效果也未必会有明显提升。
一个更好的兵器，确实能提升武力，
但最后杀了多少敌人，其实跟个人意愿也有很大的关系。
重复劳动
有效的组织代码，其主要目的我觉得不是为了避免重复，
而是为了让复杂的项目变得更容易管理。
类似的，当多个团队都有相似工作的时候，
看起来他们在重复解决同一个问题，但其实业务场景很难是完全一样的。
所以，把大家做的事情整合起来，找出通用方案，
可以不从解决重复劳动的角度考虑，而是考虑，
是否存在一个性价比更高的方案，可以同时解决所有团队的所有问题。
无疑这个通用方案，比起单独解决任何一个问题都更加的复杂。
而且每个团队，还要自行适配到具体的问题中去。
从软件的角度来看，消除重复就意味着建立依赖，
依赖链路变长，整个系统的可靠性，以及人员的沟通效率，都会受到影响。
适合的问题
开发者在日常工作中，确实需要很多外部服务，
但还是需要问一个问题，为什么他们自己不能解决呢？
这可能要涉及 “问题谁最适合去解决” 的话题了。
就像打仗的士兵，实在没有心思在前线造炮弹一样，
每个团队其实都有当前最紧要的事情。
而对于面向开发者提供服务的团队而言，他们所面的问题可能是，
如何让更多的开发者来使用这些服务。
毕竟这些服务的价值，必须需要有人使用才能转化为成果。
有这样的想法在逻辑上是很说得过去的，
但却在无形之中，会对前线开发者，造成一些压力。
因为不但要应对敌人的攻势，还要应对临阵换一批新炮弹的风险。
把事情交给别人做，就会有这样的问题。
根本原因是，这两个团队的考核方式是不同的。
证明一个炮弹是好的，跟证明一个士兵是优秀的，是两回事。
结语
在一些中大型软件企业中，开发者已经是一个不小的群体了。
这样的一个大群体的研发活动，也会催生出很多很多的需求。
本文是反思了一下，为这样的群体提供服务，会遇到哪些难题。
首先是开发者服务的价值，难以衡量，
其实是，消除重复劳动的同时，也会增加整个系统的复杂度，
最后，事情分拆导致的不同考核标准，可能会让一方受到影响。
所以说，事在人为，不在于事而在于人。
历史的转折总是不那么符合逻辑的。