享受工作

软件工程的实际困境

做软件设计外包行业也好几年了，常常会碰到要与外行人合作，这种外行主导内行的事情对于工程师来说是非常痛苦的。大概在2013年，我和一位高级工程师合作参与了一个电商项目，甲方客户要求尽我们最快的速度将新功能上线。看了需求和做了代码分析后，我们俩都怀疑自己学过“软件工程”，看懂代码做二次开发已经耗费掉大量的时间，我们根本没时间去增加新功能。所以后来只要遇到这类赶工上线的项目做二次开发，我是拒绝的。

在我看来，甲方和技术方的项目合作更像一场博弈和拉锯战。大家有共同的努力目标是项目的顺利交付，但甲方的交付期望和支付能力相差甚远，技术方的交付结果和交付质量有待考究，大家不相上下。甲方金主爸爸不听劝是常见问题，从开始规划功能不停地做加法，从原型策划到UI到交互，一路灵感迸发，最后的结局永远是修不完的bug。软件开发团队“无条件”接受甲方的需求，一开始就冲刺加班加点地加新功能，几个月后就慢下来了，所有时间都在修 bug，没精力去加新功能。这是软件开发的一个特定规律。

换个角度来说，外行人的误解，可能也很大程度上和“码农”自己自身特点有关，这个群体常常在幕后，很少发声，即使发声也很难用通俗易懂的话向大众传达清楚。“码农”这个群体不是科学家，不是发现个有趣的规律就能发表论文取得名与利，他们要确保自己的作品要有用而且还得安全不出事，还得考虑成本讲究可行性。爱因斯坦谈及科学规律时说“什么东西都要越简单越好，要简单到不能再简单为止”，而码农们的座右铭应该是“魔鬼在细节中”。在软件开发中犯细微的错误，结果可能就非常糟糕，从未编程开始一个很小的int类型错误很可能就会导致整个系统的崩溃。比如今年波音今年737 Max的停飞事件，软件是要控制飞机做动作的，一旦出错就飞机就一头栽地上了！问题出在波音737 MAX机型上的迎角读数分歧警 器在波音所有MAX机型上都没有被激活，但波音“不是故意将其关闭的”。后续发现的更多软件问题，波音737 max机型至今被禁飞没人再购买，赔偿问题也是一个大问题。所以，软件不仅是个工程，而且比传统工程难得多，一旦为了赶工，十有八九是糟糕透顶的结局。

大到波音这样体量的公司，小到外包客户定制一个软件，都是面临“压缩工期”、“压缩成本”、“赶快上线”这样的赶工问题，这就是软件工程的实际困境。

雪上加霜的行业乱象

从历史的角度来说，软件行业从一开始就是一个糟糕的行业，项目总是再延期，好不容易交付软件后又总是出现各种毛病和错误。这样的“宿命”，也导致了“码农”这个群体特别喜欢自黑。就拿Windows操作系统来说，用久了重装系统是所有人痛苦的经历，客户不满意是必然的，因为根本不可能有什么售后服务，而且还有大量黑客、计算机病毒时刻在攻击着，真的是一门非常不省心的生意。

从各类开发方法论的角度来说，软件行业也是相当令人头疼的行业。比如比较熟悉的几类软件开发方式，敏捷开发（Agile），极限编程(extremeprogramming)，TDD（Test Driven Development ）测试驱动开发。比较糟糕的开发方式有，诸如由啥也不懂的混蛋来驱动项目的开发，还有，升职驱动式的开发，这类工程师只做可见度高的、容易升职的工作，这种软件开发方法论在大公司很常见。简历驱动式的开发，善于在项目里使用最新最酷最炫的不成熟技术，方便在自己简历上多加几个酷炫关键词，只要这个人离职后继无人，只能重新再开发一 次。还有一种是KPI制度造成的，可以叫欲盖弥彰式的开发，当软件出现问题的时候，别让人发现是我的代码带来的问题，开发过程中得注意如何掩饰自己的无能。还有一种叫God Only Development，开发过程指手画脚，不管兼容性，不管用户体量，任何问题都是开发人员的问题。

不受约束的赶工是软件项目最大的敌人

据Project Smart 的一份调查统计，大约94%的软件项目经历过多次从零开始重新开发的。这个数字虽然非常吓人，不过和我多年的从业经验吻合，绝大多数项目会因为新的设计、新的技术或者新的架构重构一次。重构也成了软件开发行业的项目管理、演化和创新的一种手段，大多数的项目都在不停的升级过程中经历一次又一次重构。这是行业非常普遍的现象。

造成项目不停重构最重要的原因，是一个“快”字。软件行业发展至今，快速上线是最重要的，第一时间服务客户是最重要的，最快的添加新功能是最重要的，最快速度修复BUG是最重要的，处于抢跑快跑的竞争梯队是最重要的。为了更快，就要设置更短的deadline，就要更加聪明更加高效的工作，要加更多人或者加更多班。所有人心里都明白，匆匆忙忙并没有让项目更快或者更有效率，只是让项目开发设计人员压力倍增精力涣散效率低下，最终项目质量很不稳定很脆弱。

某个角度上来说，任何试图匆忙完成开发，都会消耗开发人员大量的情绪和精力，最终造成项目效率低，软件兼容性差。经常会能碰到一类“管窥效应”的客户，一旦目标锚定在完成开发上线，就压根没心思没时间花在做测试上面，似乎测试不是开发的一部分。这样的项目时间安排，最终造成大量的时间用于debug，用于修补bug和hack代码。

这和《稀缺》一书说的贫穷陷阱是类似的。穷人的财富资源都消耗在了刚需上，没有闲钱投资；穷人的时间和精力都用在了短期利益上，没空闲时间投资自己的成长，即使闲下来，也是及时行乐，习惯性透支未来资源，压根没有做长期规划的打算。软件开发团队也一样会发生这种“稀缺”危害，开发任务繁重，就总要权衡，就会引发认知能力下降，引发带宽不足，做出错误决定，没有时间精力投资在软件质量与开发效率上。专注解决眼前紧急的事情，忽视真正重要的事情，这种管窥效应一旦形成，长此以往，团队会造成人才流失，把好开发者逼走，开发越来越没效率。

曾在20世纪六十年代末领导IBM公司300人的团队开发操作系统的计算机思想家弗瑞德里克·布鲁克斯（Fred Brooks），他在完事后专门写了一本书叫《人月神话》，提出两个感慨：

第一个感慨是，1个人干12个月的活，绝对不是12个人在1个月内能干完的。项目用的程序员越多，平均每个人出活的速度就越慢。所以实际上是没办法规划什么“人/月”的，但是，给客户规划的时候，销售不得不写清楚具体的“人/天”。这一点矛盾，难以调和。

布鲁克斯这本书出来，人们才充分认识到软件工程的难度，现代软件工程要求，软件产品必须达到下面这五个目标，称之为“DRUSS” ——

Dependable，可信赖，让顾客真能指望上你这个软件；

Reliable，得可靠，不能总出毛病；

Usable，软件是给人用的，得让人能够上手；

Safe，用的时候不能出安全事故；

Secure，它得不容易被黑客攻击才行。

现代主流最成熟的操作系统，包括 Windows, Mac 和 Linux，各自都有接近一亿行代码，虽然大致实现了这五个方面的要求，但其中仍然还有大量的毛病，要频繁升级修复。而且这三大操作系统是经由前几代，几十年的失败和错误积累沉淀下来的，不是一朝一夕之功，不是一两个行政命令能催生出来的，一旦有外行人横加干预，那项目更不可能顺利产出。一方面没有足够经验沉淀，另一方面有外行人干预，任何有可能萌发操作系统的种子都有可能被扼杀在萌芽阶段，没有任何机会演化生长成操作系统，这也是我们国家始终没有研发出自己的操作系统最重要的原因。

所以，想要让一项涉及多人的工程项目稳定运行，开发过程必须先慢下来，约束好需求的“得寸进尺”。

该如何放缓速度进而优化开发流程

做到磨刀不误砍柴工，首先是找专业和敬业的人，其次是减缓进度，让业务需求与开发团队完成有效的磨合和掌握适合的开发节奏，最后约束产品的需求增长，平衡好商业诉求与工程开发的冲突，提高产品的模块自动化和兼容性。

开发流程和开发工具都不会让项目怎么能运行起来，最核心的关键是人。1987 年的时候，布鲁克斯写了一篇文章叫《没有银弹》，软件工程的根本问题，是人的问题。招募最有天赋的人才是最关键的，不是刻意去招募最聪明的，或者最有经验的，而是寻找那些有激情、懂规划和有行动力的人才。自我的人，一定不能允许这类人留在团队，破坏性巨大。再者是尽可能让整个开发团队一起工作，不要允许个人英雄主义和独狼开发者，要善于让集体贡献责任和成果。“Plans are nothing, but planning is everything”。尤其在项目开始的早期阶段，一定要预留足够的时间来完善计划，至少争取要每周收集反馈并调整计划。再专业的团队，都很难保证所有的预先计划都能完整的被实施，大概率上来说，计划不是要不折不扣的实现的，计划的目的是应对各种变化，是要经常进行修正的而不是一成不变的。

其次，明确短期目标和长期战略。制定短期目标，方便项目成员的注意力能够更好的聚焦在完成关键工作上。尤其外包合作的过程中，不要凭直觉做决定，否则整个项目开发团队都会觉得莫名其妙的，更无法理解一个陌生业务的复杂性。

最后，还有考虑及时响应市场的诉求。这些冲突累计在一起，导致主导软件开发的这个人，必须得能够理解高度复杂的东西才行。像这样的人才，都是绝对的帅才。主动软件工程就好比带兵打仗，最起码的把人安全带到战场，不逃逸、不哗变、不闹事、都能吃饱饭就不错了。

最后的最后，一分钱一分货，不要妄想花吃麦当劳的钱又能同时享受丽思卡尔顿The Ritz-Carlton的五星服务。

Andy

芦苇科技 创始人、CEO

芦苇科技-广州专业软件外包服务公司

提供微信小程序、APP应用研发、品牌设计等专业服务，专注于互联 产品咨询、品牌设计、技术研发等领域