死亡行军与自我革命
在二战时期，除了直接杀死的方式之外还要一个处理战俘的办法，强迫行军，旨在令他们死在途中，这种方式就是死亡行军。在软件工程领域可能不是因为主观上希望整个团队崩溃，但是却在一个又一个的失败之中导致研发团队死亡也被称作为一种死亡行军。而笔者恰好在 2017年底开始经历过这样完整的一个项目，刚好可以聊一聊。
虽有雄心，无力实现
笔者所参与的项目，大致上是一个可交互的服务管理系统，其实比较像 vmware 的一个软件，我们管理的对象是应用本身，但是在设计的过程中，我们不仅仅在技术层面上有所创新，更加在业务层面上也有限制，这时候反而带来了一个很复杂的问题。技术工具 与 业务工具 本质上是有很强的矛盾点的。技术工具的目标是帮助开发者，运维等方便快捷的完成任务，侧重在自由灵活的实现某种能力：比如Jenkins，K8s此类的工具，而 业务工具 是为管理者管理所使用的，更多的是严格的规范管理。举一个这两者交界比较多的软件而言，比如数据分析工具BI等，工具本身提供的是对于多数据源的支持，可视化的支持，这些是开发者所需要的，管理者需要的是开发者最终产生的报表内容，因此我们最终只能选择满足一个客户（当然也可以产生多个产品满足不一样的客户）。因为这样的背景，我们在后续的工作中却发现，我们不仅仅针对管理者的功能没做好（因为企业的管理维度是千变万化的，而所开发的产品只能满足一部分的需求），对于开发者部分的功能也没有做好（因为包含的业务属性，在灵活性方面不得不去做一个妥协）
如图所示，你最终的落脚处一定是: Win-win / Lose-lose 绝非有第三种的可能。
To be or not to be
生活总是充满了苦难，并非我们需要苦难帮助我们成长，只是生活缺少不了苦难。做了一段时间的产品之后，我们也渐渐的发现，整个DMP的产品体系内有一部分的组件是价值较低，但是依然需要有人投入精力进行维护的。我认为这一部分的组件，我认为是低价值的，比如配置中心，用户中心，增强的Eureka等，这些组件依然存在着或多或少的问题，我们无法抛弃他们（还是我们舍不得抛弃它们），梭罗如言：牧羊人继承了羊栏的代价是他的自由。我们也为了这些组件从一个灵动飘逸的团队慢慢的变的沉重和笨拙。
无产者在这个革命中失去的只是锁链。他们获得的将是整个世界。
我们也到了为自己革命的时刻，放弃幻想从新起航。扔掉那些低价值意义不明的组件，深耕于高价值有意义的组件，吾辈亦继承DMP之名，简装上阵。
Make customers succes
如何定义成功，从一个ToB企业的角度，我们的成功显然是建立在成功的帮助客户，亦证：让客户成功是让我们成功的途径。而让客户成功的最重要的因素是找到客户需求，并且帮他满足他的需求，这里面困难之处不能一一道明，不仅仅有客户不知道自己的需求，需求怎么样才算是满足，还有就是如何满足客户的需求。
产品 or 方案
从旧日的经验看来，强推一个通用的产品是可以满足客户的80%的需求，但是这剩下来的20%，我们却不得不花整个项目过半的时间去满足，从客户的角度也会反馈为响应时间过长，而选择一个恰当的开源产品，满足客户的50%的需求，这剩下来的50%的需求可能会花更少的时间来迎合此类客户特定的场景，因此在真正的去客户进行交付的时候，我们的选择不是单一的，如何保质保量的交付才是我们需要考虑的。因此交付的是我们的产品？还是我们的方案？我认为都是可以的。
ToB 即服务
toB 的主战场并非是产品本身如何，而且围绕着产品的交付过程和最终的运维阶段如何保证客户的业务连续性。交付Jenkins亦或者DCS这并非是问题的关键，此两者皆为工作，在充分的考虑之下，我们选择一个更容易交付工具，而客户所期待的并非是我们交付的工具，此基于工具我们究竟可以完成多么完美流程的CICD过程，而我们研发产品的初心不也是因为拓展开源产品所不足，而在此之前，我们应该多加反思，这个项目真的需要使用我们自研的产品吗？
Do not follow your passion
Ben Horowitz 在哥伦比亚大学2015届毕业典礼上的演讲：在你热爱的和你擅长的中，你应该选择哪一个呢？原文链接 且不论其他的同事做的怎么样，对于我来说 kubernetes 在很长的一段时间内都是我的噩梦（至今我的github的status依然是：🖕Fucking Kubernetes），并非是 k8s 做的不够好，而是我并不擅长于此，而在这之中摸爬滚打就变成了在焦油坑中煎熬。
在自己擅长的地方深耕
在网关做到2.x版本的时候，我和何晶都有一段时间不知道给网关增加什么新功能，在之后我们可能选择增加一些额外的功能（当然最终并非是我们在构建），现在回想起来，我觉得这并不是一个好的方式，我们试图在培养同事在不同的技术栈上，比如Skywalking，对于他来说围绕着SW的APM可以做非常多的事情，此时让他再去深入理解k8s，显然是不合适的。围绕着API我们依然可以做很多有趣的尝试，因此让擅长的同事做擅长的事情，这是很重要的一件事情。
因此我们今年也有了 女娲计划 ，并且相较于从前，我们不再是以产品作为唯一的方向，以领域作为方向，这一领域内的知识与工具皆可为我所用。
善假于物也
但是我们总归是有不擅长的领域，而又不得不去做的，我认为此时寻求下外援也不是什么错误，比如K8S可以咨询Kay的团队，倘若真是有所不得，那从外部借助一些力量也是可以的。