软件开发项目管理制度项目管理规范制度

软件公司刚成立,如何制定规章制度?及如何激励员工

刚成立哪儿来那么多制度~~~~ 就一个部门：业务！ 先饿不死，然后说吃饱，再说吃好！~~~ 有半年到1年的业务开拓，自然会诞生出制度！~~~~我是从事软件业务多年的sales！~

软件项目管理的成功原则

1平衡原则 在我们讨论软件项目为什么会失败时可以列出了很多的原因，答案有很多，如管理问题、技术问题、人员问题等等，但是有一个根本的思想问题是最容易忽视的，也是软件系统的用户、软件开发商、销售代理商最不想正视的，那就是：需求、资源、工期、质量四个要素之间的平衡关系问题。

需求定义了做什么，定义了系统的范围与规模，资源决定了项目的投入（人、财、物），工期定义了项目的交付日期，质量定义了做出的系统好到什么程度，这四个要素之间是有制约平衡关系的。

如果需求范围很大，要在较少的资源投入下，很短的工期内，很高的质量要求来完成某个项目，那是不现实的，要么需要增加投资，要么工程延期；如果需求界定清楚了，资源固定了，对系统的质量要求很高，则可能需求延长工期。

对于上述四个要素之间的平衡关系最容易犯的一个错误，就是鼓吹多快好省四个字，多快好省，多么理想的境界啊？需求越多越好，工期越短越好，质量越高越好，投入越少越好，这是用户最常用的口号。

多：需求越多越好吗？ 软件系统实施的基本原则是全局规划，分步实施，步步见效，需求可以多，但是需求一定要分优先级，要分清企业内的主要矛盾与次要矛盾，根据PARETO的80-20原则，企业中的80%的问题可以用20%的投资来解决，如果你要大而全，对不起，你那20%的次要问题是需要你花费80%的投资的！而这一点恰恰是很多软件用户所不能忍受的。

快：真能快起来吗？ 快是用户、软件开发商都希望的。

传统企业里强调资金的周转情况，软件企业里强调的是人员的周转情况，开发人员应尽快做完一个项目再做另外一个项目，通过快速的启动项目、结束项目来承担更多的项目，来获利。

但是快不是主观的拍脑袋定工期就可以完成的，工期的定义一定要基于资源的状况、需求的多少与质量的需求来进行推算的。

软件毕竟需要一行代码一行代码的写出来，他的工作量是客观的，并非人有多大胆，地有多大产式的精神鼓动就可以短期完成的。

省：省到什么程度？ 一分钱一分货，这是中国的俗话，他是符合价值规律的。

甲方希望少投入，乙方希望降低自己的生产成本，省到乙方仅能保本的时候，再省，乙方就亏损了。

正视这四个要素之间的平衡关系是软件用户、开发商、代理商成熟理智的表现，否则系统的成功就失去了一块最坚实的理念基础。

企业实施IT系统的首要目标是要成功，而不是失败，企业可以容忍小的成功，但不一定容忍小的失败，所以需要真正理解上述四个要素的平衡关系，确保项目的成功。

2高效原则 在需求、资源、工期、质量四个要素中，很多的项目决策者是将进度放在首位的，现在市场的竞争越来越激烈，产品早上市一天，就早挣一天钱，挣的就比花的多，所以一定要多挣，基于这样一个理念，软件开发越来越追求开发效率，大家从技术、工具、管理上寻求更多更好的解决之道。

基于高效的原则，对项目的管理需要从几个方面来考虑： 要选择精英成员 目标要明确，范围要清楚 沟通要及时、充分 要在激励成员上下工夫 3分解原则 化繁为简，各个击破是自古以来解决复杂问题的不二法门，对于软件项目来讲，可以将将大的项目划分成几个小项目来做，将周期长的项目化分成几个明确的阶段。

项目越大对项目组的管理人员、开发人员的要求越高，参与的人员越多，需要协调沟通的渠道越多，周期越长，开发人员也容易疲劳，将大项目拆分成几个小项目，可以降低对项目管理人员的要求，减少项目的管理风险，而且能够充分地将项目管理的权力下放，充分调动人员的积极性，目标会比较具体明确，易于取得阶段性的成果，使开发人员有成就感。

作者主管过的一个产品开发项目代号为SB，该项目前期投入了5人做需求，时间达3个多月，进入开发阶段后，投入了15人，时间达10个月之久，陆续进行了3次封闭开发，在此过程中经历了需求的裁剪、开发人员的变更、技术路线的调整，项目组成员的压力极大，大家疲惫不堪，产品上市时间拖期达4个月。

项目完工后总结下来的很致命的一个教训就是应该将该项目拆成3个小的项目来做，进行阶段性版本化发布，以缓解市场上的压力，减少项目组成员的挫折感，提高大家的士气。

4实时控制原则 在一家大型的软件公司中，有一位很有个性的项目经理，该项目经理很少谈起什么管理理论，也未见其有什么明显的管理措施，但是他连续做成多个规模很大的软件项目，而且应用效果很好。

作者一直很奇怪他为什么能做的如此成功，经过仔细观察，终于发现他的管理可以用紧盯2字来概括，即每天他都要仔细检查项目组每个成员的工作，从软件演示到内部的处理逻辑、数据结构等，一丝不苟，如果有问题，改不完是不能去休息的。

正是在他这种简单的措施下，支撑他完成了很多大的项目，当然他也是相当的辛苦，通常都是在凌晨才去休息。

我们并非要推崇这种做法，这种措施也有他的问题，但是，这种实践却说明了一个很朴实的道理：如果你没有更好的办法，就要辛苦一点，实时控制项目的进展，要将项目的进展情况完全的实时的置于你的控制之下。

上述的方法中对项目经理的个人能力、牺牲精神要求是很高，我们需要有一种进行实时控制项目进度的机制，依靠一套规范的过程来保证实时监控项目的进度。

如在微软的管理策略中强每日构建，这确实是是一种不错的方法，即每天要进行一次系统的编译链接，通过编译链接来检查进度、检查接口、发现进展中的问题、大家互相鼓励互相监督。

实时控制确保项目经理能够及时发现问题、解决问题，保证项目具有很高的可见度，保证项目的正常进展。

5分类管理原则 对于不同的软件项目其项目目标差别很大，项目规模也是不同的，应用领域是不同的，采用的技术路线差别也很大，因而，针对每个项目的不同特点，其管理的方法、管理的侧重点应该是不同的。

就像古人讲的，因材施教，对症下药。

对于小项目你肯定不能象管理大项目那样去做，对于产品开发类的项目，你也不可能象管理系统集成类的项目那样去做，项目经理需要根据项目的特点，制订不同的项目管理的方针政策。

如，下表是作者为一家应用软件公司制订的项目管理的方针： 在该案例中，将项目分成了订单类项目与非订单类项目，非订单类项目是指由公司根据市场的需求开发一个标准产品的项目，而订单类是指针对某个具体的客户定制软件的项目，订单类的项目根据需要协调的资源的范围有划分成了公司级、部门级、个人级三类，非订单类根据估算的工作量的大小也分成了A、B、C三类，估算的工作量超过720人天的为A类，超过360人天的为B类，360人天以下的为C类。

不同类的项目管理的侧重点是不同的，从立项手续的完备性、计划的严格层度、周报的完备层度、规范的严格层度、跟踪的实时性、是否进行阶段总结、是否核算项目成本、是否严格进行阶段评审等多个方面来考虑，以确保管理的可行性。

6简单有效原则 项目经理在进行项目管理的过程中，往往会得到开发人员这样的抱怨太麻烦了，浪费时间，没有用处，这是很普遍的一种现象。

当然这样的抱怨要从2个方面来分析，一方面从开发人员本身可能存在不理解，或者逆反心理的情况，另一方面，项目经理也要反思：我所采取的管理措施是否简单有效？搞管理不是搞学术研究，没有完美的管理，只有有效的管理，而项目经理往往试图堵住所有的漏洞，解决所有的问题，恰恰是这种理想，会使项目的管理陷入一个误区，作茧自缚，最后无法实施有效的管理，导致项目的失败。

7规模控制原则 该原则是和上面提到的其他原则相配合使用的，即要控制项目组的规模，不要人数太多，人数多了，进行沟通的渠道就多了，管理的复杂度就高了，对项目经理的要求也就高了。

在微软的MSF中，有一个很明确的原则就是要控制项目组的人数不要超过10人，当然这不是绝对的，也和项目经理的水平有很大关系。

但是人员贵精而不贵多，这是一个基本的原则，这和我们上面提到的高效原则、分解原则是相辅相成的。

项目管理规范制度

给个制度的范例吧。

具体的模板网上一搜一大把。

目 录 1目的.... 3 2 适用范围.... 3 3角色和职责.... 3 4名词解释.... 4 5参考资料.... 4 6过程总述.... 4 7过程活动.... 5 7.1质量保证过程... 5 7.1.1入口准则... 7 7.1.2输入... 7 7.1.3任务... 7 7.1.4出口准则... 7 7.1.5输出... 7 7.2 QA在各个阶段中对流程的检查... 8 7.2.1输入... 8 7.2.2任务... 8 7.2.3输出... 8 7.3阶段预警... 8 7.3.1输入... 8 7.3.2 任务... 8 7.3.3输出... 8 7.4质量目标（本目标可以根据中心能力基线变化进行变更）... 9 7.5 质量控制... 9 7.5.1实施测试控制... 9 7.5.2实施过程控制... 10 7.5.3实施bug控制... 11 7.5.4实施文档控制... 11 8 表单和记录.... 12 9修订记录.... 13 1 目的 通过检查、监督项目的各个阶段，通过对项目各个阶段的判定，确保项目质量达到 阶段目标和客户的要求； 通过检查、监控项目过程，确保具体的项目质量管理活动，符合质量管理体系要求。

2 适用范围 产品类项目、定制类项目、平台类项目； 过程符合性适合于中心所有项目。

3 角色和职责 QA: l 在项目决策阶段制定《质量保证计划》，并维护和管理《质量保证计划》 l 发布质量标准以及相关的流程要求。

l 跟踪、监控各项目的检测评价的结果，进行再判定，将结果发给项目组成员，同时提交问题列表，监督各项目团队建立问题列表，追踪各负责人的问题管理情况，确保问题及时解决 l 对项目研发的各个过程进行检查，确保项目研发过程符合质量管理体系相关流程的要求。

l 参加项目各阶段的技术评审会。

研发人员： l 依据设计程序进行设计，组织进行设计评审，确保设计结果通过评审。

l 确认、分析QA发出的各项项目质量数据，对Issue & Bug进行数据库输入、原因分析，针对原因提出改进和预防对策，并确保改进和预防对策的有效性。

l 对第三方公司提出的测试报告进行检查和判断，确保其有效性。

测试人员： l 依据研发制的测试规范，确定有效的测试计划，并进行测试；及时提交所发现的Bug，并将测试报告发给项目组成员。

l 依据QA的要求进行再现性和模拟性的重复性测试。

4 名词解释 无 5 参考资料 IPD、CMMI管理理论相关的一些信息； ISO9001的要求和原则。

6 过程总述 质量保证规定分为三个过程：质量规划、质量保证和质量控制三个过程。

i. 质量规划： 质量规划是识别项目及其产品的质量高要求和/或标准，并署名描述项目将如何达到这些要求和标准的过程。

质量规划在项目立项阶段着手准备，并在立项后完成质量规划所要求《质量保证计划》。

ii. 质量保证： 实施保证过程是审计质量要求和质量控制测量结果，确保采用合理的质量标准和操作性定义过程，实施质量保证是一个执行过程，它是使用实施质量控制过程。

实施质量保证为持续过程改进创造条件。

iii. 质量控制： 实施质量控制是监测记录执行质量活动的结果，从而评估绩效并建议必要变更的过程，主要进行bug监控，过程监控，文档监控和测试控制。

流程图： 7 过程活动 7.1质量保证过程 阶段 NO 过程 作业内容 职责 输出 设计实现 1 项目计划 项目组生成项目计划 项目经理 项目计划 2 测试计划 （测试项，地点，计划，费用，负责人） 依据该项目的质量标准和项目计划初版，和研发人员确定项目测试类别（单元、离线、集成、可靠性、压力、特殊测试等） 项目负责人、QA 不同单元的测试计划 3 项目计划检查 检查项目计划是否合理：是否有立项评审时间、阶段是否完整、时间是否合理、各级计划是否合理 PM 检查结果 4 项目质量计划 依据该项目的质量标准、项目特性和项目计划（包括测试计划），制定项目质量计划，并评审通过。

项目质量计划要求： l 产品需求规格 l 关键过程的检查 l 文件的发放计划 l 成熟度（可选） l 质量的风险和经验教训的总结 QA 项目质量保证计划 5 过程监控 参与项目例会，识别例会是否有效，包括人员、重大问题、需求、风险等。

项目经理/PM/QA 周报 6 里程碑预警 PM应对设计阶段进行里程碑评审，QA依据项目质量保证计划，本阶段流程进行检查，确定是否可以启动里程碑评审会议，并及时进行里程碑预警工作 QA 里程碑预警信息 设计验证 7 项目质量保证计划 更新质量计划，并经过再次评审后发布；完善质量标准及质量审计流程 QA 更新后的PQP 8 里程碑预警 PM应对设计阶段进行里程碑评审，QA依据项目质量保证计划，对本阶段流程进行检查，确定是否可以启动里程碑评审会议，并及时进行里程碑预警工作 QA 里程碑预警信息 测试 9 更新、维护项目质量保证计划 根椐项目质量计划开展质量管理活动，更新、维护项目质量保证计划 QA 项目质量计划 10 阶段检查 同设计阶段 QA 检查报告 收尾 11 软件版本发布检查 1、软件版本发布，发布之前，所有的程序被冻结，由测试人员进行测试，检查bug库中所有bug的状态，如果有一二级bug，产品将不能发布；（程序打包之前对未解决的bug可以做专项测试） 2、测试人员编写版本发布质量报告进行质量分析总结 3、源码，文档入库；源码包括数据库编译脚本（含静态数据）、编译构建脚本和所有源代码；文档包括设计需求、详细概要设计报告、设计和测试文档、各种手册、产品介绍等 4、CM进行编码打基线，文档版本入库进行基线标记 QA 产品发布总结报告 12 软件版本发布批准 1、建立产品发布计划 2、编写发布说明包括产品的版本说明；产品概要设计，本次产品发布的文件包，本次发布和新增特性说明，遗留问题及影响说明，版权声明以及其他需要说明事项，客户手册、产品介绍等 3、正式发布通知 项目经理 13 结项 项目经理负责组织进行结项资料编写，QA对项目的质量问题进行总结 归档项目文件 项目经理 结项总结报告 14 结项评审 PM组织对结项资料进行预审核，收集干系人意见，发给项目经理进行结项总结，QA反馈质量部分意见经过修改后会议评审，经由IPMT批准后发布 项目经理 结项评审报告 7.1.1入口准则 项目立项完成 7.1.2输入 立项材料及立项评审报告 7.1.3任务 完成质量规划 完成质量保证计划 进行各阶段质量目标及过程保证 7.1.4出口准则 《质量保证计划》 7.1.5输出 《质量保证计划》 7.2 QA在各个阶段中对流程的检查 7.2.1输入 《质量保证计划》完成 7.2.2任务 QA依据《质量检查单》中的要求，对各个阶段的项目组输出进行检查，不符合流程时向项目组成员提醒。

并留记录，为里程碑评审和项目质量总结提供依据。

在流程执行方面有反复性问题时，要向中心各部门主管以上人输出。

7.2.3输出 《质量检查报告》 7.3阶段预警 依据《项目计划》要求，对各个阶段进行判定，提出里程碑预警，发给项目成员、分管领导、管理部的领导及IPMT。

7.3.1输入 项目立项完成 7.3.2 任务 项目过程中发现质量异常、或风险时QA人员提前向项目组与相关各部门主管提出预警。

问题严重时报告相关部门经理或者总经理以上级别领导，并与跟踪分析与改进结果；当问题涉及客户需求或客户关注的内容时提前向客户提出，并进行有效沟通。

7.3.3输出 项目阶段预警通知