国内应用软件面队项目管理的若干问题

随着企业信息化建设的深入和国际交流的增加，应用开发的项目管理越来越受到重视。国内企业客户的应用软件开发项目管理存在哪些问题和差距？这更可能是一个实际问题，而不是理论问题。以下是基于作者在集团用户、外资企业、国内民营企业的项目经验和思考进行的初步探讨。
项目管理的意识
不能真正区分项目实施和项目管理的任务，这是目前普遍存在的问题。可以概括为“没事干”和“没人干”并存，往往是开发骨干兼任项目经理造成的。一方面，如果设立一个专职项目经理，专门从事项目管理，没有任何分析、设计、编码、测试等具体的技术实现工作。，会觉得“无事可做”或者打零工。另一方面，由于主要或全部精力忙于具体的技术工作，各种项目管理任务(如:项目分析/评估、项目计划制定/检查/调整、上下级沟通、专业资源配置、项目组织调整、项目财务控制、风险分析/对策等。)都不可避免的被忽视，没有人做项目管理，造成项目控制“过劳”的问题。
在中小型项目中，管理任务不一定饱和，合格的项目经理还可以担任项目技术主管或业务顾问。关键是要有区分项目管理的意识和责任感。
项目成本基础
项目管理的本质是必须在规范、成本(成本、资源)和进度之间取得平衡。目前国内系统集成企业普遍不建立专业工程师的成本结构和应用控制体系。因此无法建立和实现项目成本的指标、考核和控制，导致公司和项目经理之间职责不清。说白了，项目经理可以不计成本申请资源，“在韩信越多越好”，而公司却进退两难。如果它同意，可能投资太多，如果它拒绝，就必须承担项目失败的责任。上级经理成了项目经理。
没有专业资源成本结构的建立，就没有办法实现项目成本管理，也就没有真正的项目管理。
项目管理体系
一个标准化的、实用的项目管理体系，必须因企业而异，因项目而异。一般来说，应该是项目管理原则、企业/行业特点、项目规模/性质、企业开发文化/品质等多种因素的综合产物。生产流程应由具有一定理论素养、丰富的标准化项目实施经验和总结能力的资深项目管理专家，结合企业具体情况制定，并通过培训、试实施、调整等方式实施。
目前在国内比较普遍的，还是企业没有项目管理体系，仅仅依靠个人经验来实施项目管理；还是书生制度，照搬教条，纸上谈兵，束之高阁。这样一来，不仅实际的项目管理无所可依，而且项目监理层也很难实施对项目的间接监控和支持。
专业服务机构
国际企业级应用软件开发机构基本分为产品研发和专业服务。由于国内市场成熟度较低，以直接面向客户需求的项目式开发为主，应该是专业服务型的技术组织架构。
目前国内差距主要在于:一是公司战略将项目实施部门定位为成本中心配合系统产品销售，但未能作为独立核算的业务单元或业务方向；第二，基本采用层级式的业务管理组织结构，但缺乏业务管理与专业管理(如运营经理、资源配置、资源开发、行政助理、项目会计、项目质量监控等)分工合作的矩阵式结构。);第三，缺乏设计和结构的垂直专业深度。
专业服务的组织架构差距，使得专业服务部门的市场定位模糊，发展方向混乱。平时不利于专业团队的建设，不能持续有效的发展和提高技术团队的专业素质；在售前活动中，不利于组织售前支持和程序化控制售前风险；项目实施过程中，不利于项目资源的合理及时配置，运营监管和项目监管不能有机结合，保证项目监控状态。
项目计划
项目计划是项目经理实施项目管理控制的依据。目前存在的差距主要有:一是项目计划的制定不够严谨，随意性大，可操作性差，在实施中无法遵循，如项目计划过于粗糙，分解落实不足；任务、进度和资源没有落实。二是整个项目缺乏详细的项目计划贯穿始终，甚至采用每周制定下周工作计划的周项目计划法。其实质是“项目失控合法化”。第三，没有对项目进度进行足够的检查(与进度相比)和控制，以维护项目计划的严肃性。
项目计划的分解或“粒度”是一个需要仔细权衡的问题。规则越细，控制越大(笔者见过精细到每人0.25小时)，但项目管理成本越高；或者反过来，达拉斯到大礼堂根据中国目前的情况，我个人认为，3个月以下的项目至少要细化到2-3人天；对于超过半年的项目，至少需要一个人-周。
如果项目经理不熟悉项目的专业领域，项目计划应该由项目技术负责人和班组长(团队)具体起草，因为他们最熟悉工作内容和具体资源的适应性，项目经理要沟通、调整、平衡、确认，并承担最终责任。
项目风险意识
项目风险意识就是失败感。每当我们开始一个项目的时候，我们往往会期待项目投产的那一天能够成功，但是我们有没有想过疲惫之后失败的挫败感？做项目不比卖产品。卖出一个产品就是成功，项目投产就是成功。产品是静态的项目是动态的；有质量问题的产品可以更换和保修。项目一旦失败，时间无法倒流，失去的客户可能是市场竞争优势和机会。风险意识是对这种结果的可能性的警惕。这样，我们将仔细处理项目业务需求、技术解决方案和组织管理的许多问题。
目前市场竞争激烈，市场不够成熟，可能导致应用开发项目的恶性竞争风险。客户希望以物美价廉来增加需求、降低价格和进步；怕出门，厂家会拍着胸脯保证。忽视必要的科学可行性分析和评估，签订不可能的服务合同，项目还没开工，就已经注定了风险之高。事实上，这种风险是相互的。制造商可能会损失金钱和声誉，客户可能会损失金钱和业务发展。
业务参与意识
客户购买IT系统是为了更好地发展业务。应用软件把通用计算机变成了专用的业务系统，因此应用软件渗透着业务系统和策略，成为应用软件乃至IT系统的灵魂。所以世界上成功的案例都是业务部门始终参与，这是保证项目成功的底线之一。
不幸的是，我们经常看到技术人员“独立地”开发“创新的”系统。理由是:他们认为应用开发是IT的事情；认为业务人员的知识受限于手工或当前的方法；业务人员太忙，无法参与项目；商务人士要求太高，太啰嗦，所以经常变换要求。虽然这些理由不无道理，但归根结底，应用项目来源于业务部门的需求，最终为业务部门所用。业务参与度不够，不仅可能导致业务偏离的隐患，还可能因为业务人员不了解、不认可而夭折。