序
最近在整理自己的书，发现了一本放在不起眼的位置，我找了很久都没找到的书，就是这本《人月神话》。这本封页写的是20周年经典纪念版，买这书的时候，我还在五山上大一。从今天回看这本书对我的影响，这是一本带我入行的好书。虽然不如《软件工程》这课程一样科班化，但是却如圣经一般指引着我走在信息行业的大路上。
神话
软件工程
对于管理这样的课程，按照经典的西方大学的课程安排，是不开本科课程的，毕竟管理属于一个需要背景知识与实际经验的范畴。不然，学完了软件工程这门课，毕业生的定位是怎么样的呢？没有实战的程序开发经验，他可以承担软件工程中众多角色的哪一个？
- 需求分析？
- 架构设计？
- 数据库设计？
- 编码人员？
- 测试与质量管理？
- 配置管理？
- 交付管理？
- 运维管理？
按照我的经验，大部分人应该连编码人员的角色都应付不来，除非上过北大青鸟这种速成班，或者在规范的企业实习过具有良好编码习惯的毕业生。
北大青鸟的毕业生，让人感觉急功近利，4年的课程，哪里是半年能突击完成？只是一个会编码缺缺少灵魂的行尸走肉。而后者，是根据我自己的经验总结的，大部分的本科生心比天高，却难以有担当，因为他以为他看过猪跑，实际上他看到的只是老鼠。
自缚
这是一个挺可笑的世界。因为我总是不在主流上，有时候我真的很迷糊到底是他们可笑，还是我自己可笑。
比如到底是业务重要还是程序写的多更重要？没有业务，程序屁都不是。这是一个标榜以加班为荣的职业，可是真的有必要加班吗？到底是因为前期的需求与设计的资源够没够，导致了后期编码阶段出现问题后，靠大量的程序员把前期留下的问题解决掉？
很多人不同意我的观点，认为做了再说，毕竟互联网谁也不知道用户究竟怎么想。可是，没有一个设计好的架构，业务一转向，大家都懵逼，前期的工作基本都白费，靠的又是苦逼的程序员加班。
由于这种模式久了，需求也省了，架构设计与数据库设计也省了，最后程序员直接顶上。如果这是一个高配的程序员，原本就具有架构和需求工程的能力，事情当然边的简单。可这明明是三个人的活，意味着他的专业性和工作量，一个顶三，这是多么不专业的做法？
活干多了，人未必会长进。每个项目都如救火队员一般，缺乏全盘考虑，每次都为了无法遇见的问题拖延了时间和项目进度，而且项目的效果也不好。虽然不成功的经验也是一个让人长进机会，可是，有多少人真的能坐下来总结项目经验，梳理自己的职业历程，然后再投入下个项目然后避免相同的错误呢？
他已经走人自己人生的死循环，不是简单的停下来或者换一家公司就能解决的问题。他的思维定式，怕也是很多人的写照。
十年信息化感悟
我一直把我本科毕业的时间，作为我入行的时间。我的理论基础与编程经验，基本上都是本科阶段完成的，研究生阶段算是拓展了我科学思维的广度，对我在计算机上的技能的提高不算太大。
其实软件行业范畴很大，传统产业的信息化部门，也是这个行业重要的一个参与角色，重要的stockholder之一，未来的职业化发展是CIO，如果我没理解错的话。
作为有着几年编码经验与几年甲方经验的我，我想说说自己的感受：
资金规划不合理
根据财政信息化的要求，一个信息化项目必须
- 当年申报确定立项与否并核准建设金额
- 次年3月资金到位，经过采购流程后约6月份动工
- 建设当年11月份要做用户验收并准备支付一笔项目资金
- 第三年年末准备最终验收，支付最后一笔资金
这基本上就是一个信息化项目的建设过程，前后最少跨越3年，而且第一年申报的方案与第二年采购的方案与最后验收看成品的方案必须基本保持一致，最多不能超过5%的变更。
在信息化预算中，建设费用的2.5%作为设计咨询费，3%作为工程监理费，2%作为验收测评费。
所以资金规划的不合理一共有二:
- 财政资金的拨付时间与支付率的压力造成了资金纵向分布不合理
- 财政信息化投资的各项比例严重失衡造成了资金横向分布不合理
资金纵向分布不合理
主要是项目当年的支付压力很大，资金只能结转1年，并需要提供各种证明的材料。从签订合同到年底只有半年时间，市面上水平参差不齐的软件开发商，基本不考虑使用专业的需求人员与设计人员，商务团队把项目直接抛给技术团队，商务团队答应的功能需求到了技术团队就予以推翻。
在这样的一个纵向分布不合理的情况下，符合企业最大化的利益便是，把此前已经成型或者购买的一个系统经过简单的改造，视作已经完成了系统开发，推给甲方，企图通过让甲方改变工作方式与操作方式来适应这个系统。
资金横向分布不合理
在《人月神话》一书中谈到，编码只占了整个系统开发的六分之一的时间。
- 三分之一时间：计划
- 六分之一时间：编码
- 四分之一时间：初期测试
- 四分之一时间：系统测试
具体的时间，当然可以调整，但是每一块工作如果要效率最大化的话，必须是通过文档作为产物，在不同的层面的角色中传递。软件项目管理与设计是仿造建筑项目的，在建筑项目中设计与建设是分开的，因此必须要有足够的资金支持。项目2.5%-3%的设计咨询费，会是一个合理费用让设计与建设分开吗？
让自己设计，接着自己建设，最大的问题就在于，承建方的考虑是这个系统怎么才能设计的最少，建设量最小，投入产出比最高。无论甲方用什么方式，都无法保证，这个项目的确是有利于自己，设计从自己的业务出发，效用是提升业务处理的能力，这对于承建方而已只是附加的，基本只要说得过去，项目就可以竣工了。
与其说各个单位投入了巨资，却无法建设好信息化项目，除了本身的项目风险外，资金的横向分布不合理加剧了系统失败的风险。
需求工程不到位
《人月神话》中，一个理想的团队，如同一个外科医生医生团队，由：
- 一个主刀医生，
- 一个副手
- 几个程序员
- 一个工具维护人员
- 一个测试人员
- 一个语言专家
- 一个项目经理
- 一个编辑文档的人员
光有主刀医生，没有一个好的麻醉医师与护士，没有负责记录医嘱的参与者，没有一些有资历可以咨询的专家，没有人去协调手术室与手术需要的工具安排，这个手术的成功性有多大？
而需求就是这个主刀医生对病人做的诊断，经过与患者的沟通后定下的治疗方案。在医疗行业，通过必须的检验手段，获得各种指标，并经过相关的委员会同意时，才能进行手术。
在软件行业，通常沟通需求的是售前人员或是商务代表，大部分是不具备主刀能力的人，而需求工程用到的场景分析，用例调查，数据流分析，业务重构，开会讨论与个别谈话调研，需求卡片与需求文档确认，在我跟进的项目中基本没有一个团队用到。
所有人都知道，在需求调研、架构设计、代码编写、测试上线这四个阶段，同样的问题越往后的代价越大，而需求工程做不好，意味着后面程序员苦逼而得不到认可的工作是必然的。在这个时候，程序员会自发的想到，需求不合理，组内有合适的机制去协调或提前评估这个问题吗？我猜想华为中兴应该是有的，而很多其他的企业应该是没有的，剩下的只有项目经理、产品经理与程序员之间仇人似的关系。
以其昏昏使人昭昭，这是不可能的事情，而在我们这个行业却比比皆是。
三位一体弊端多
需求、设计、编码三位一体，就是当前传统软件开发商的根本问题，或许也是总多创业团队的模式，并不是说这个模式注定失败，而是说这个模式失败的风险很高。
由于三位一体，开发商的角色就变成了与业主方对立博弈的状态。看起来开发商的所有出发点都是好的，但是实质上要把手里有的东西低成本的交给业主，这才是他真正的目的。手上有的东西，不一定是企业级的东西，安全与稳定性以及扩展性并不一定能达到商用的水平，但是业主方缺没有评价与核实的方法。
需求与设计的方案，并没有经过相关的有经验的专家进行评审，因此并不具备客观性、专业性与科学性。由于监理的费用非常少，源于建筑行业的监理，是完全没有担负起技术把关与质量控制的工作，有的只是和稀泥，讨好业主方，而不是从起专业角度去考虑问题。
如果这样的局面长期存在，那些专业的公司就会无法支撑下去，意味着劣币驱逐良币的情况再次发生。由于资金分布不合理导致的无效市场机制，会让专空子的商家获得高额的利润，踏实专业的从业人员得不到应有的资金保障，导致这个生态系统不断的失衡。直到投身互联网行业，并不是因为这个行业好，而是这个行业市场化程度高，经营不善会立马倒闭，使得资源流向更合理与梗完善的生态。
需求不专业，架构不专业，编码也不专业，即便工作年限再多，在市场上也是卖不起价，所以不是岁月催人老，而是能力真的少。以至于项目周期不断逾期，项目风险从一开始就变的很大。
技术陈旧不出新
由于开发商的挣钱模式是把老东西包装一下卖出去，那么商务就是他们最重要的投入，技术只是一个配合。毕竟活下去比活得好，重要得多，而在整个原始而又混乱的南方市场，技术得不到应有的重视，开发人员也没达到应有的水平高度，于是大部分的高新企业都在CMM0到CMM1的状态徘徊。
别看企业资质都有ISO9001与CMMi5的资质，由于整个行业的混乱与不专业，导致了按照专业化开发的企业，难以生存，既要保持专业度，又要获得好的市场收入，这还是一个具有挑战性的任务。
混乱的市场，缺乏专业的从业人员，导致在传统的软件行业中缺乏有效的技术积累，所谓的创新只是一种针对评审标准的游戏。在互联网行业由于获得了超额的利润，仍然会有创新的土壤，毕竟互联网行业在整个大行业中并不算太大，起创新的能量是很局限的。
新技术通常是对开发效率或者技术特性有着新的呈现，大部分的公司沿用旧的技术，一方面是因新技术不够稳定，另一方面是新技术开发的成本比老技术的高。但是与这公司打交道的经验让我体会到，他们用老技术做出来的东西，往往还不如新技术开源的项目质量高。
测试不善频掉链
按照标准的测试要求，在通过模块测试、集成测试与系统测试后分成阿尔法测试与贝塔测试，前者是关于系统的内部人员测试，后者是外部人员测试。内外区分应该以开发商为边界，开发商内部测试为阿尔法测试，加上业主方的一部分人测试为外部测试。
当前乱象是，根本没有通过集成测试与系统测试，也不做阿尔法测试，直接做贝塔测试，把用户当作小白鼠。项目的开发人员也没有这种意识，尤其是通过北大青鸟这种培训机构或者自学成才的程序员，根本就没有所谓工程的概念。明明是泥水工，却担任起了项目主管的责任，终究还是一个泥水工。
不重视测试，是我这6年项目甲方的切肤之痛。
运维不力愁煞人
因为支付压力，遗留问题清单上满满的都是待解决的问题。由于项目的大部分钱已经支付了，所以运维的响应是非常的缓慢，因为这个设计不合理的项目，要让他变的高效可用，是不太可能的。
运维人员往往对开发过程并不了解，于是在处理问题的时候，变得异常的不专业，基本无法解决问题，直接造成业主方承担系统不能投入生产的直接责任。
最是痛心科班生
面对这么一个现实，作为科班出身的我，是很难过的。我采取过各种办法，尝试提高项目的质量与可控性，尝试固定技术路线，试过要求按照需求与架构文档来做确认文档，组织过第三方专家组对项目进行项目状态评审。
不过困难重重也好，放弃总是容易的，坚持才是难能可贵的。
结语
匠人
周末，看了NHK的片子《和食双神：最后的约定》，讲的是91岁的小野二郎与73岁的早乙女哲哉之间的故事，和食之巅的两位大神，相互赏识，相互比拼，彼此之间成为他人无可取代的存在。两人数十年如一日光顾彼此的店铺，没有语言上的交流，只为品鉴手艺，感知彼此对食材原味的提炼以及在料理中倾注的心思。
他们约定一定要工作到100岁，或许这就是当代的俞伯牙和钟子期了，自己的强大是因为对手的存在，大家共同的成长。
我
现在看到《人月神话》中对编程的乐趣做的描述，我依然会很兴奋：
- 这是一种创造事物的存粹快乐。
- 这种快乐来自于开发对他人有用的东西。
- 快乐来自于与整个过程体现出的一股强大的魅力–将相互啮合的零部件组装在一起，看到他们以精妙的方式运行着，并收到了预先所希望的效果。
- 这种快乐是持续学习的快乐，来自于这项工作的非重复特性。
- 来自于在易于驾驭的介质上工作。
- 编程不仅满足了我们内心深处进行创造的渴望，还唤醒了每个人内心的情感。
看着匠人的身影，自己多少也会受到触动，为了做好手上的活，是要用一辈子的。