关于软件开发

对于一个处在组建的软件技术组织来说，的确有很多的问题，这包括来自目标项目的和组织内部的。
    就一个成熟的软件工程组织来说。
    首先，她应该确定自己的技术规范，采用什么样的软件工程模型将直接影响项目的过程和结果，如采用的是瀑布式的软件模型，这实际上也是大多数开发小型项目（更准确的说应该是一些小的程序产品）的一般做法，它由需求开始，然后是分析、设计、编程、测试、交付。
    的确，软件开发也确实是按照上述过程实现的。但是，对于一个中型或者以上的项目，问题的凸显是严重的，因为这种模型，无法控制质量、周期、资源和风险等因素的折中。我们开发所依据的需求在整个项目的进展中是不可能一成不变的，绝大多数的需求蠕变瀑布模型是无法控制的。这样的最终结果将导致用户无法认可项目产品的可用性。然后，分析设计、编码实施、测试是一个根据项目规模有着相当时间周期的工作，这是规律性的东西，在环境条件的限制下是无法改变的。在这个过程中你能保证客户的耐心和支付的信心吗？这个问题将直接导致项目的资金风险增高。仅仅这两点就足以使项目流产或者失败。
    一个成功的项目应该有一个明确的技术规范体系指导下工程模型构架，这一点是保证项目成功的决定性因素，这远比几个个人技术能力超群的程序员重要。
    在这样的指导思想下，团队的结构因该是多层次技术人员和管理系统结合的综合体。他要求人员不但具有一专多能的技术素质，同时更为重要的是他们必须是规范化技术体系的一部分，这才是高效团队的基础。现在很多的软件组织无法达到这种团队要求，就将团队的效率的提高的希望寄托在行政管理上，这也是我国计划经济体制留下的最顽固的管理方式，将一个无论什么样的单位或部门以一种类似集中营的形式进行管理。这种管理的弊端我不想多说，您可以在任何一家倒闭的国有企业里找到最好的答案。
    软件工程改进很多公司都在喊，但谁都无法实现。好多公司都是在技术组织组建初期，没有建立一个科学的技术规范体系，随着项目开展，结果造成个人积累远高于组织积累，最终导致由于个人处于利益的原因使得规范化切入受阻，从而使企业的技术体系建立失败。这可以看成是失败过程管理的典型案例。其他公司要好一些吗？就我所接触，很难说。这是回答普遍性问题的开始。
    这个问题，我想我们看看国外就可以有些感悟了，在美国这样的信息化发达的西方国家，他们的规范化执行的很好，为什么？你可能要说，他们的情况不一样，人家素质高，对人身对价值的理解不同，而且他们的环境多好呀。我们能比吗？这些回答有一些是不无道理的。但是，这些回答没有找的核心问题或者说本质所在。从我在国外的同学和亲戚，从事软件工作的情况来看，他们并非比我们更具有很高的觉悟，况且，觉悟这个东西，在这里并不起什么作用，他们环境好，这是事实，的确他们的环境很好，但是，并不只是硬环境，更重要的是软环境。他们工作的回报是可以为自己获得持续的物质获利的，更直白一点，他们每参与一个项目，成果中就拥有属于自己的产权部分，这些都是要体现持续效益的，所以我们才听说美国有很多软件金领，他们工作到35岁退休时已经跻身富人圈了。这与我国的科技企业职务科技成果归属有着本质的区别，人家35岁退休到了我们这里被扭曲成了“高软件的技术寿命是35或者30岁，之后就没有灵感了”，可笑之极。
    现在你知道人家为什么会自发知觉的去执行规范化技术体系了吧，因为组织的目标就是他们个人的目标，他们不会在一些个人积累上有所保留，因为组织目标的加快实现，可以促织个人目标的加快实现。我们身边的组织可能做到吗？在国内一些公司不厌其烦的重复着过河拆桥的过程，需要技术的时候找几个人，东西一做出来立马就炒人。技术人员们不得不从一个技术成功中被提出来，又进入下一个零起点。所以才有那么多的跳槽。个人积累在这种情况下才变得如此的重要，使得很多的技术人员在工作中技术的交流表现得那样的讳莫如深。
     在这样的大环境下，什么软件过程、UP、XP、技术文档、项目管理、规范化体系统统都只能流于形式。所以在CSDN中才有了CODE与程序员隐私的话题。所以才有评估国内ERP实施结果，失败的多成功的少。
     如果，你将公司的技术团队交给我管理，我将首先确定公司的技术规范和过程体系，然后根据这种体系结构的角色要求去物色人选，当然不一定很多人，这要求被选中的人可以担当不同的角色，为保证项目顺利成功的实施，我必须获得激励和惩罚人员的权力和资源。而且这些都因该是可持续的。
先就谈这些吧，相信我们还有很多的交流机会的。