程序员来说是很不公平的。在国内，只会照抄别人代码，一点都不懂创新，凡事依靠别人，快下班就盯着表看的程序员是不少，这种人一般很难有什么前途。但是，优秀的不断进取的程序员也很多。由于国内没有象CMM这样的软件规范或者很少，所以这类优秀的程序员不少都是干着系统分析员甚至PM的活，拿着程序员的工资。这类程序员虽然在起步时会吃很多亏，而且是主动找亏吃，然而几年之后与前一种程序员的社会地位会出现明显的分化。当上进的程序员们作为PM进行商务谈判的时候，前者还在各个公司里频繁跳槽，跳来跳去都不满意。有些扯开了，回到我们的话题。
日本的软件规范与CMM有惊人的相似，其中至少有35%以上都是几乎一模一样的。最近经济不景气，东京倒闭了160家软件公司，这个数字是今年6月份的，还在不断增加。这些公司纷纷抢滩上海，招收技术人员。如果去这样的公司应聘就要考虑清楚了，进去可以学到他们的规范和质量控制，可是要想从程序员成为系统分析员或PM，比登天还难。往往一个程序员进去干了好几年，对自己的那一块熟的不得了，而对隔壁同事所做的东西一窍不通。拒传华为正在尝试CMM4（华为印度研究所已经通过CMM4），对在华为工作的程序员们来说可谓福祸难料。当然，已经作到PM或QA或者热爱CODING的朋友例外。 需求分析本身也存在着时间分配的问题。第一遍需求分析花的时间会最长，分析员们在客户的各个部门之间几乎把腿都跑断，把口水说干，就是为了确立一个初期的需求模型。所有的文档将会提交给PM进行复审并签字，不合格的打回重做。反馈表随之将提交给客户，第二遍第三遍等等等等接踵而来，与客户反复讨论和磋商，反复提交文档和表格，目的只有一个，明确需求。当PM最终合并了所有文档并确立需求之后，最终生成的需求文档将提交给客户的各部门负责人签字。这些文档将作为合同的附件添加，以便在将来项目变更或者碰到重大问题时和客户扯皮的重要依据。
需要说明的是，客户并非都是蛮不讲理，但是说实话，颇有无奈，国内目前的项目大多数客户为了不让自己的钱白花，经常变着法子提需求。在启动阶段明确需求并签字，无论最终情况如何，一份详尽的书面文档可以解决很多口头承诺或概念模糊的文档带来的许多问题。
上世纪八十年代初美国搞星球大战计划，拖跨了苏联。大家对那段历史有些含糊，很多人认为苏联人上了美国的当。其实并不完全如此，苏联人的情报机构无孔不入，并非那么容易上当受骗。实际上当时美国国防部已经开始着手NMD系统软件的需求分析，前后耗资数亿美圆，耗时两年，仅仅是做需求分析，终于发现存在着在当时技术上无法达到的高度，随后项目被放弃。详尽的需求分析有一个额外的好处就是对一些双方都很陌生或者从来无人尝试的领域将是一个决定是否进行项目的判断标准。有时候，这种大项目在签单时双方都没有绝对把握保证可以出成果，一旦在需求分析阶段发现难以逾越的技术难关，就会放弃项目。