兵法与项目管理
孙子兵法有云：“凡战者，以正合，以奇胜。” 讲的是从战略是正面要刚得住，而依靠一支尖刀部队打开战场的僵局，而获得战场的胜利。项目管理也应担如此，然而往往大部分的项目截取了后半段而忽略了前半段，呜呼哀哉。
现代软件工程也存在着形如蒙代尔三角，质量，成本，风险。当控制得了风险和成本，那就不能要求太高的质量。
当要求质量和成本，那就得面临巨大的项目风险（System/360 Operating System），而这一切就取决于你如何选择，对于传统的ToB项目来说，成本相对固定（固定的工期和固定的人员投入），而此时我们为了追求可以结项拿钱，我们不得不降低软件的成本，而低质量的交付软件意味着没有二期项目，而二期又是大部分的ToB赚钱的核心。那对于企业来说，这样难道是无解之道？那当然不对，对于企业来说，聪明的你一定会想到，为什么我们不从源头解决这个问题，卖的贵一点不就好了，但是很抱歉，当你的价格上升的时候，就意味着你的竞争力下降，那你又如何获得这笔订单呢，对于一个充分成熟的市场，寄希望于单方面的提高价格是困难的，那还有什么办法，既然涨不了价格，那我可以降低人员成本，这也是大部分企业的选择，如何降低员工成本，又分为降低员工的工资，和提高员工的效率。聪明的企业往往选择后面一种，企业培训，采购更好的协作平台，使用更好的合作模式，都是在提高员工的效率。但显然这个路也是有尽头的，而且异常的难做。有没有什么轻松的办法呢？降低工资这个太影响士气，往往不到生死存亡的时候并不会选择这样的方式，啪，灵光乍现，我可以让员工承担更多的职能，这样的话，不就可以了？原本的开发可以兼职售前，售后，交付。这样我们可以成本上直接降低，我们就可以大幅度的提高软件质量，降低成本。但是这条路和上面的路类似，有一个不得不去面对的问题，让员工变成一条龙开发工程师，就真的会让企业的成本降低吗？我的答案是否定的，我们可以把身兼数职的人比喻成特种兵，自古以来有依靠特种兵完成全面战场胜利的案例吗？显然是没有的，中国的先人早就知道，好钢用在刀刃上。因为这样的复合型人才是极为的稀缺的，正如以奇胜的那个单独的军事单位，而在漫长的软件开发过程中，我们是正面战场需要的是精密合作的怀揣不同技能的人才，无论多么富有才能的人，最终也得面临精力的衰退。
再说说，全栈工程师，有人对全站工程的误会很深，觉得是全栈即是全都做，非也非也，在经济学的奠基之作《国富论》中早已提出，分工是提高社会效率的有效方式，而且全都做和这个相悖的，显然是错误的，而真正的全栈的含义是，如何有效的进行分工，之前的分工模式以简单粗暴的前端，后台，项目经理等等角色为分工，这样的分类是低效的，而且全栈的存在正是对这个分工的反思，我们为什么要用固定的角色分类来进行分工，技能的熟练程度，对业务的理解，这些都分工值得参考的依据。
John.Boddie在1987年出版的《Crunch Mode》一书提出了“两难境地”，处于“两难境地” 的项目面临着无法达到最初目标的威胁，而项目团队在努力想要跨越该困境。软件工程本身就会面临这样的两难境地，或长或短，短期的两难境地是常见，也是无法避免的，而长期的两难境地会变成“死亡行军”，Ed.Yourdon在1997年出版的《Death March》一书提出，而这个词也同样是由那些被迫在“死亡行军”项目中行走的人们发明的，通常用来描述进度表几乎不可能完成的项目，说明项目参与者的周围弥漫着的是难以忍受的潜在的失败气味。在漫长的死亡行军中，就很难保证项目的质量，团队的士气，而终点也不再具有真实的意义，人们纷纷在中路就死亡了，一个无法抵达的终点和没有终点又有什么区别呢。