摘自某百科：《魏略》蜀军大将魏延认为，长安守将夏侯楙年少，娇生惯养、怯而无谋。今日假若我魏延领精兵五千，背负粮草五千，直由山道深入，寻秦岭而向东，到达子午再往北行。不过十日就能抵达长安。夏侯楙见我军突然出现，必然乘船而逃。如此一来，长安城内只剩下御史、京兆太守而已。长安北门有散民之谷，足以供应我军粮食。而由东方相会合，需要二十日，届时丞相您在由斜谷赶来，必定可以在此与我会师，这么一来，可以一举平定咸阳以西。

子午谷奇谋乱谈

年少时期，我第一次听说魏延的“子午谷奇谋”，也曾感叹可惜诸葛亮没有采纳。十几年后，当我在办公室听着游戏策划和开发吵需求的时候，逐渐理解1800年前诸葛亮没有采纳的理由。

古时候行军打仗，是一件残酷的事。老百姓被官府征召入伍，放下自己的农活，随意培训几天就上战场成为所谓的士兵。而每征召一个士兵，就会失去一个农夫。一旦征召过多，必然出现粮草不足的情况。而没有足够的农民从事农业，必然导致粮食匮乏。为了获取粮食，就只能去“东征西讨”。所谓的“一将功成万骨枯”既是如此。而为了能在破城后获取最大的收益，部队长官一般会放任士兵进城烧杀掳掠，到了史书上就只剩两个字“屠城”。

而刘备和诸葛亮一系，在三国时期的记载中，没有一次“屠城”。客观来说刘备真正发家的地方是从荆州请到诸葛亮后，而荆州益州平原辽阔常年没有战乱，粮食充足，刘备他们不需要屠城，也可以获得足够的粮食；但主观上刘备可能是出于理想主义或者是汉室宗亲的旗号，做到了那个时期下真正的“爱民如子”。到了季汉时期，诸葛亮六出祁山时，诸葛亮没有选择持续的连年征战，而是让士兵有规律的务农，储备粮食。尽管蜀道难，难于上青天，但成都开阔的平原，让当时的成都老百姓过得不错，还有艳丽的特产“蜀锦”远销“国内外”，他们生活的水平比200年初的北方老百姓幸福多了。诸葛亮的善良在史书里没有明写，但是从一行行文字的字里行间中跨越1800年传递给了每一个热爱三国历史的人。

这样一位爱兵如子的统帅，真的愿意让那五千士兵冒险吗？那五千士兵，脱下战甲，也不过就是山间农夫。也许他们背后还有五千对父母，五千个妻子和孩子？这样冒险的决策，对那些后方的亲眷而言，是否太不负责？

可是对于魏延来说，五虎将之后，姜维（当然那时候还不认识）之前，没有人能比他实力和威望更大。对于军人而言，战争年代就是建功立业的黄金时间。倘若能一举攻下长安，他就会成为季汉武官第一名。这样的利益驱使，提出这种冒险的策略也就不难理解了。

当我年纪渐长，体会到战争残酷，感受到人心难测之后，只觉得魏延所谓的“奇谋”不过是异想天开，拿五千条生命赌一个名垂青史的微弱可能。这当然是不被诸葛亮采纳的。就算真的占领长安，那又如何？曹魏已经占领了几乎所有的北方地区，又有一批与曹操出生入死、经验丰富的老将。魏延真能守得住吗？答案也是显而易见的。

那么为什么到了二十一世纪，总会有人讨论“如果”？我想，首先是因为大家真真切切为诸葛亮和姜维连年征战失利感到惋惜；其次，魏延的策略确实有微弱的可能性，“也许”会让季汉取得一定的优势。而他们从没有仔细想过，成功了下一步怎么办，失败了又有多少损失。

软件工程学就是软件开发行业的兵法

目前几乎所有稳定运行的软件，背后都有一个维护团队。这个维护团队一般就做两件事：开发新功能和修复Bug。如何稳定地进行版本迭代、已开发的功能如何保持可用、新功能如何确保不影响旧功能，以及如何让用户对新功能的学习成本降到最低，这些都在软件工程学的讨论范围之中。如果把开发一个软件比作一场战役，那么设计软件即拟定战术，开发软件即招兵买马，上线发布软件即行军出征，软件面对用户时即战场前线。如前线告急，则需要指挥官进行调度，及时补足资源，修复问题。

为了能做到稳定度过开发、上线、维护等流程，软件工程学包含各种开发模型。如瀑布模型、快速原型模型、增量模型、敏捷原型等。初学时会觉得那些模型过于拗口难以理解，但简单来说就是如何分配人力以完成需求分析、软件设计、软件开发、软件发布、软件维护等一系列流程。由于前人使用瀑布模型时，客户无法再软件期间看到预期结果，在软件开发完成后才与客户见面，一旦客户不满意就不得不推倒重来。所以后人提出先设计原型给客户检阅，拟定术语表，确保讨论的内容和目标是一致的。（这也是DDD领域驱动设计的思想）；又或者是将需求细分，完成一个需求的开发后，进行一次发布，即增量模型；又或者，提高交付的次数，使用敏捷模型，以某一个时间长度作为产出周期，每周进行一个反馈（并不要求一定要完成整个功能，而是每周完成一部分成果）。这些优化后的开发模型，思路都是让客户尽早观察到软件开发的过程。

但是目前国内外的软件行业中，大部分团队是不遵循以上的开发模型的。这背后有太多复杂的因素。如客户作为甲方，对自己想要的软件不明确；开发方作为乙方，由于是拿钱办事的一方，为了竞拍得到机会不得不夸下一些海口；而作为程序员，对于需求的理解可能也会和甲方乙方领导略有偏差；当然还有技术选型，性能指标等等一系列需要花费时间进行分析的内容。能够完全按照比较先进的开发模型，是需要甲方乙方及开发整体团队整体实力达到合格线以上（当然笔者无法定义何为“合格线”），并且进行有效的、充分的沟通。

再来说说需求变更。需求变更几乎是软件行业无法避免的事情。或者说，在地球上就没有什么需求是不会变更的。但是软件行业的需求变更，成本往往很难准确评估。软件，实际上是看不见摸不着的数据，我们不过是用显示器窥探里面的内容罢了。对于需求的理解，对于需求变动需要的工作量的评估，不同的人总有不同的评判。但领导并不一定能接受一线开发者的需求变更时间评估，这当然有多方面的因素，如客户要求、如领导和开发人员能力差距或者理解偏差等等。需求变更都会带来大量难以评估的成本。而这正是敏捷模型提出的原因之一。如需求变更，就临时改变方向即可。

关于时间评估，在充分相信程序员的情况下，接受程序员对开发时间的评估是最合理的。但是由于领导对程序员的不信任、或是希望短期内多开发更多内容，强行缩减程序员的开发时间，这在表面上会让功能上线并且看起来还不错，但长期埋的暗雷也就只有开发团队内部人员知晓。但是在这个行业中，每个开发都对着自己的显示器输入英文字母进行编程，领导并不能在短期内判断程序员是否在“摸鱼”忙里偷闲，因此一旦领导遇到几个不够称职敬业的程序员，会让他对这个行业其他程序员产生偏见。

而从这个角度看，开源软件天然接受所有人的Review代码审查，遇到问题就算主库不合并，也可以fork复制一个新仓库进行开发，天然保证这些暗雷总会被找到。这也是为什么程序员们总是更偏向于使用星星很多，知名度广，背后有高手维护的项目。

魏延不会是一个好“开发经理”

回到“子午谷奇谋”，从软件工程学的角度，即可以发现魏延想要在软件上线（大军已出征）的情况下，不顾开发成本（五千士兵），临时调整需求，并且这个需求很有可能导致软件崩溃（引发曹魏愤怒，倾全国之力讨伐蜀国）。而当前网络上关于子午谷奇谋的讨论，也总是停留在“成功了如何如何”。我想这也是为什么在软件开发过程中，领导总会提出“不太合理”的需求吧。

当然，我们目前谈论的是在软件工程学方面，为何临时修改需求且需求难度大时，需要避免做出这样冒险的决定。但这并非绝对。三国时期即有张辽带着陷阵营在孙权大营搅了天翻地覆；而进入二十一世纪前20年，商机遍地，赶着做软件先上线的公司都赚的盆满钵满。从这个角度想，软件工程学之下的合理，到了现实情况又不一定合理，团队能力，甲乙双方的需求和期望，成功的时间窗口，运气等等因素，是那样无法捉摸。一味抱着软件工程学（兵书）照本宣科，也许最后只能落得马谡失街亭的下场。

也许找到了加班的理由？（笑