软件行业真是太难了！
最近有一次，Javaeye老炮群里开始讨论一些技术和管理边界的问题。这些问题，到底是归入技术范畴还是归入管理范畴，到底是用技术方案解决还是用管理方案解决，是很难权衡的。
其中一个就是是软件复杂度的度量问题。
软件的复杂度度量，这是一个难题。但最最最最难的地方在于怎么和不懂软件的老板解释这个复杂度问题。这是所有项目经理，产品经理面临最难的问题了。
举个例子来说，竞业公司美亚公司出了小程序，本公司的大老板看的不错，也想做一个自己的。于是他给研发组下了命令，两周之内要完成。但公司内部以前从没做过小程序，光基础功能搭建时间都超过这个时间限制。请问该怎么办？
A。答应下来，死命加班干
B。给老板解释这个看上去很简单的小程序背后的复杂度，争取两个月内完成？
C。离职。
我想大部分情况下呢，也许有人会选B，但是老板大手一挥，你们怎么干是你们的事，我要的两周完成。于是最后硬着头皮只能选A，但是时间实在来不及，干了一个半月才搞定，而且还很多小bug，老板还是不满意。这样，三五个项目之后，员工辞职了，技术主管也吃不消了，产品经理也没法干活了，小程序因为bug过多，不得不停止使用。结果是双输。
这个场景的核心问题在于，不同的产品的复杂度能否比较，能否度量。比如说美亚公司的小程序只有两个星期做好，是因为他有很多基础组件，而我们没有。于是两边相减，差了10个差异度。但实际上我们没法比较。研发和产品的复杂度都是隐藏在软件界面背后的，这是一个黑箱，特别对于不懂的人来说。
对于一个不懂技术的CEO来说，他只有两个选择，相信你和相信他自己。开明的boss相信你，自信的boss相信他自己。所以有本书叫《人件》，软件开发本质上还是管理人的过程。我在2016年做过一整年的技术顾问。深刻体验到那些小型的，处于互联 边缘的企业，在IT投资总额一定的情况下，要么吃下外包软件的苦果，要么吃下自建团队的苦果。最大的区别无非是那边更苦点，那边可以挺的久一点，小软件可以租用，但是有些需要定制的系统，就没办法了。并没有特别好的解决方案。
不同的产品复杂度能否比较，能否度量？老板说，我们抄下淘宝吧。我们能不能用合理的，理性的，逻辑的，非技术人员能够听明白的言语去说清楚“淘宝”两个字背后的巨大的复杂性？
说到这里，群里大佬说了两个字“死抗”
接着他又补充：“复杂度的评估整个行业都是不成熟的，没有很好的办法”
软件开发确实如此，不要看整个行业发展的很好，淘宝如何，阿里如何，腾讯如何。但都是通过资源堆出来的。因为对于软件复杂度无法很准确的估算，于是我们的计划经常调整，发布时间经常delay，简直就是常态。
如果不想delay，就只能是996，开高薪，烧人头。
那么复杂度测不准的情况下，老板又催着要的情况下，软件开发怎么进行？
唯一目前可选的方案就是敏捷方法+持续交付了。
敏捷方法+持续交付就是让飞机飞起来，哪怕是个纸飞机也行。
一边手工补漏洞，一边继续造飞机，把纸飞机变成铁飞机，把铁飞机变成737，把737变成太空战舰，还不能让飞起来的飞机掉下来。
有难度吧？确实很有难度。
敏捷方法+持续交付实际上为了解决需求的不稳定性和技术复杂度度量的问题。或者快速试错，或者快速试对，不管怎么说，研发部总是能随时交出一个可运行的系统。于是大家都很开心，觉得自己设计的万亿淘宝系统可以启用了。当然实际上，研发部只是交出了一个小卖部系统而已。
从事开发行业这么多年以来，我已经无数次告诉过客户，告诉过老板，我们会在某年某月某日上线。但说实话，我自己是没有底的，我也不能保证100%能做到100%上线！但我能保证这架飞机能在最后一天飞起来，至于这架已经飞起来的飞机到底能飞多久，能不能在它掉下来之前修好剩下的部分。这就是软件的“艺术”了，真正的“艺术”！
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！