如何高效管理软件项目

⑴ 如何做好项目进度管理

题主提到了项目集、项目经理和工具这三个关键词。其实涉及到专业的项目管理，还需要结合具体的场景，比如主要是敏捷还是瀑布管理，是否是金融体系内的“稳态”+“敏态”的双模管理等等。不考虑场景因素，单从项目管理工具来看，这种复杂场景需要怎样的产品，能支撑起完整的项目流程。

先来看看企业研发管理的经典流程：

成功的项目都是相似的，失败的项目却各有各的原因。作为一款优秀的研发项目管理工具，我们接下来会持续为大家分享项目管理中的那些坑和国内外各类项目管理经验，希望我们一起向阳生长！

⑵ 软件开发的项目,如何进行范围管理

在项目一开始时，红匣子科技首先对项目进行可行性研究，接着进行成本分析，并把结果做成一份报告，交于领导批准。在项目的整个生命周期中，我们把项目管理工作分为五个过程组：启动、计划、执行、监控与收尾。

项目启动阶段

收尾阶段

项目收尾阶段是完结项目管理所有活动以正式结束项目或阶段的过程。在项目结束后，项目经理需要审查以前各阶段的收尾信息，确保所有项目工作已完成。整个项目结束，要对整体的项目做个总结，并且进行产品的测试阶段。

⑶ 如何进行有效的IT项目管理

从普遍角度上说，一个有效的项目管理要从几方面入手。
1. 项目范围
明确定义好项目管理范围，才能有效配置相应资源。
2. 项目计划
根据项目要求，制定切实可行的项目计划。国内大部分项目经理都是根据上级指示做事，没有仔细做过项目评估，这就导致在项目执行过程中，经常出现不可控因素，影响了项目的执行结果。
3. 项目资源
包括设备，材料，资金，人力资源等。关键是资金和人力资源，一个是保持适当的现金流，一个是保证有足够的人去做该做的事。
4. 风险预估
包括对用户及对自身评估两部分。对用户主要涉及其信用度，财务状况，技术能力/经验等方面；对自身主要包括足够的项目管理人员，技术人员配置是否足够，经验是否丰富，有否做过同类项目，用户的付款条件对项目管理造成的风险是否可控？
以上是针对工程类项目，针对软件开发项目，在项目范围/风险中，还需要特别关注用户对项目的具体及特殊要求。
内容来源于ITSS符合性评估落地工具-云雀运维！！！

⑷ 软件项目管理的成功原则

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人，当然这不是绝对的，也和项目经理的水平有很大关系。但是人员贵精而不贵多，这是一个基本的原则，这和我们上面提到的高效原则、分解原则是相辅相成的。

⑸ 如何做好软件项目的团队管理

决定项目成败的不仅仅是范围、成本、进度的计划多么完美，而是团队是否能高效的工作。说到项目管理，很多人都会记得范围管理、成本管理、进度管理，这些都是衡量项目成败的要素，重视对这些要素的管理，无可厚非，但却忘了一个根本的问题，那就是：所有的这些目标都将是团队来完成的。计划做的再好，没有人去实现，或者没有忠诚的成员去实现，那岂不是空谈。

或许跟其他的项目不同，软件项目彻底是"以人才为核心"的项目，项目的主要成本来自于人力成本、项目的进度完全由成员决定，因此，在软件项目中，对团队的管理不仅仅是对进度的保障，更是对项目质量、项目成本的保障。团队管理才是软件项目管理中的重中之重。

然而，软件项目中的项目经理往往缺少团队管理的意识，这可能跟他们的发展历程有关。软件行业中，很多项目经理都是从程序员做起来的，我们都知道，程序员的职业发展规划路径都是"程序员--高级程序员--项目经理"。而串起这条职业路径的线，就是技术，这就导致了只要技术高，五六年自然都发展成为项目经理了。而软件的技术高手在沟通方面都普遍存在很大的问题，他们不善于跟团队成员交流、不善于人际关系、不善于鼓励与倾听，他们都喜欢独立的研究技术问题，在大家的记忆里，很多电影里，软件高手就是那种一个人可以破jie国家安全密码的人，他们往往不可能是整个团队的管理者。

⑹ 对于软件项目的管理重要性

软件项目管理是为了使软件项目能够按照既定的成本、进度、质量顺利完成而对成本、人员、进度、质量和风险进行分析和管理的活动,它是决定软件项目能否高效、顺利进行的基础性工作。目前的软件开发过程中尚存在开发环境复杂,代码共享困难、程序规模增大,软件重用性程度不高以及软件维护困难等问题,因此,对软件项目的管理就显得尤为重要。软件项目管理较其他类项目管理的特殊性主要体现在如下方面:
(1)与普通项目不同,软件项目涉及的是纯知识产品,其开发进度和质量难以准确估计和度量,很多软件项目交付的成果事先不可见。有的应用软件已经不再是业务流程的电子化,而是同时涉及业务流程再造或业务创新,这就造成了项目需求获取环节的困难。
(2）软件项目开发的周期长、复杂度高、变更可能性大。软件项目开发周期一般比较长，一般大型的软件项目开发周期达到2年以上。软件系统的高复杂度使软件开发过程的各种风险难以预测和控制。软件项目的变更主要来自外部和内部两个方面,外部变更包括商业环境、政策法规等对项目范围和需求造成的影响;内部变更包括组织结构、人事变动等对项目造成的直接影响。

⑺ 如何做软件项目管理

1、需求管理和分析的重要性
如果你认真分析每一个失败的项目，导致项目失败的原因都或多或少和项目的需求分析有关。
并且项目需求分析是“业务导向”的
作为项目经理，当你选择技术方案、制定项目规划、确定验收标准时，客户的“业务目标”远比“技术实现”重要的多。首先要搞明白的是为什么做，而不是怎么做。
业务角度例：为什么建立这样一个系统？我们目前遇到的主要业务问题是什么？希望通过这一系统解决那些业务问题？
技术角度例：（客户要建立一个xx系统）要实现那些功能？多少人同时使用？希望使用什么数据平台？IT架构是什么样的？
2、需求管理的流程
获取需求：主要了解使用方的意向。由使用方提交需求文档，双方对需求进行沟通。参与人员包括：开发方接口人，使用方接口人 获取需求文档参见《需求调研表》
需求确认：需求确认是指开发方和使用方共同对需求文档进行评审，双方需求达成共识后做出书面承诺，并确认需求基线 。需求确认人员：开发方负责人，使用方接口人
需求跟踪：需求跟踪是通过比较需求文档与后续工作成果之间的对应关系，实时跟踪，确保产品依据需求文档进行开发。需求跟踪人员：项目负责人
需求变更控制：
1）需求变更流程

⑻ 如何进行IT项目管理

从普遍角度上说，一个有效的项目管理要从几方面入手。
1. 项目范围
明确定义好项目管理范围，才能有效配置相应资源。
2. 项目计划
根据项目要求，制定切实可行的项目计划。国内大部分项目经理都是根据上级指示做事，没有仔细做过项目评估，这就导致在项目执行过程中，经常出现不可控因素，影响了项目的执行结果。
3. 项目资源
包括设备，材料，资金，人力资源等。关键是资金和人力资源，一个是保持适当的现金流，一个是保证有足够的人去做该做的事。
4. 风险预估
包括对用户及对自身评估两部分。对用户主要涉及其信用度，财务状况，技术能力/经验等方面；对自身主要包括足够的项目管理人员，技术人员配置是否足够，经验是否丰富，有否做过同类项目，用户的付款条件对项目管理造成的风险是否可控？
以上是针对工程类项目，针对软件开发项目，在项目范围/风险中，还需要特别关注用户对项目的具体及特殊要求。