【www.shanpow.com--工作计划】
软件项目理解篇一:解析软件项目管理
有人说中国软件企业和美国、爱尔兰，甚至日本（我这里不提印度，因为我认为中国和印度的软件企业发展思路是不一致的）相比最大的差距不是在技术层面上，而是在软件的项目管理上。我完全同意。 有人说中国软件企业和美国、爱尔兰，甚至日本（我这里不提印度，因为我认为中国和印度的软件企业发展思路是不一致的）相比最大的差距不是在技术层面上，而是在软件的项目管理上。我完全同意。
我也曾经参加过一些软件项目经理的聚会，在谈话中我发现，中国的软件项目经理真的是读了很多软件工程、项目管理类的书，很多人都参加过PMP（PMP是由美国项目管理协会发起的项目管理专业人员资格认证）的培训和考试，但在中国企业环境下解决软件项目中实际问题的能力存在不足，我们暂且抛开哪些"老外"们写的软件项目管理的经典论著，谈几个基本问题，希望对从事软件项目管理的PM们有所启发。
为什么要有项目管理？
没有项目管理，项目也有可能成功。但没有管理的项目，很难保证项目的利润空间，对公司来说，亏损的风险就大。所以我们要有项目管理，以保证公司在总体上是盈利的，注意不是每一个项目都要盈利。
另外，有了项目管理，就有了管理改进的基础，无论刚开始的项目管理多么糟糕，只要有管理，就有了改进的可能性，至于能不能得到改进，以及改进的快慢，则取决于两个因素：一个是人，特别是各级管理者；另一个是利益。关键是"利益"，准确的说是"利益的分配"，在权责利明确的前提下，人才能充分的发挥作用。还需要指出的?quot;利益"是多元的，这里的多元不仅指利益的具体形式，而且指利益的受众是多元的，包括客户方相关人员个人的利益。
为什么要有专职的项目经理？
专业化是一个趋势，因为在专业化的条件下，可以有效降低成本，提高利润率。项目经理的工作内容归根到底只有一项：识别并管理风险。这项工作的目的是控制项目成本。
由于项目的风险是多方面的，而且风险的表现形式也是多种多样的。从风险范围上来说，既有公司内部风险，也有和客户交流、合作的风险；从风险的类型上来说，既有管理风险，也有技术风险；从风险产生的阶段来说，包括了从业务分析到上线后维护的项目周期各个阶段。
我认为一个项目经理是否优秀，主要是看他/她能在多大程度上提前识别并消除风险，而不是弥补和解决了多少问题（风险未被及时识别或妥善处理，就会转换成问题）。当然能弥补和解决问题的项目经理也是相当合格的，但还不够优秀。
项目组的范围界限在哪里？
我认为项目组的范围界限可以有三种划分：
1、包括客户方所有参与该项目的立项、调研、审批、测试和使用人员，包括开发商市场开发、管理审批、商务谈判、后勤保障和具体负责孟钅靠⒌娜嗽保?br>
2、包括客户方项目经理、业务需求提出人和测试人，包括开发商具体负责该项目开发的人员；
3、仅包括开发商具体负责该项目开发的人员。
大部分人在思想上可以接受范围1，而在实务中接受的是范围3。而我个人认为项目经理，特别是开发商方面的项目经理应该采用的是范围。 对项目组范围理解不同，将影响项目经理对工作的处理方式，范围1实际上是很虚的，在项目管理实务操作中没有太大的意义；而范围3实质是把客户方和该项目有密切关系的人与开发商具体负责该项目开发的人对立起来，也就是所谓的甲方、乙方。在这种对立的前提下处理项目的分歧和矛盾，效果肯定要打折扣。
而按范围2来理解，在项目管理实务中项目经理就必须要让客户方和该项目有密切关系的人也接受这一观点，从而拆除双方之间的"障碍"，达到相互信任、相互尊重、共同协商解决问题的良性氛围，以达到降低项目外部风险的目的。当然，这样就增大了项目经理工作的难度，但对项目的成功则是很重要的。
怎样才能算是一个成功的项目？
对"成功项目"的标准解释为：项目范围、项目成本、项目开发时间、客户满意度四点达到要求。我认为其实只有一点--利益。项目范围、客户满意度主要代表客户的利益，项目成本主要代表开发商的利益，项目开发时间同时影响双方的利益。但每一个人关心?quot;利益"是不同的。
如何看待项目管理流程？
"项目管理流程"是管理项目的工具之一，不是管理本身，更不是项目管理的目的。
项目经理不能为了流程而流程。项目经理的工作内容我前面说过是"识别并管理风险"，而"项目管理流程"是在项目经理识别风险后作出的管理风险的选择。
不同的项目，项目风险也不同。
同样的项目，不同的项目经理，识别出的风险也不同。
同样的项目，同一个项目经理，面对不同的客户方负责人，面临的风险也不同。
同样的项目，同一个项目经理，同一批客户方负责人，不同的项目组成员，包含的项目风险也不同。
所以，我认为管理同一个项目可以有不同的流程。但不是要项目经理每次接手一个项目就创建一套全新的流程，而是根据不同的项目风险，选择适合的流程。事实上，项目流程的基本框架可以变化的地方并不多。另外还要能理解，即使采用完全相同的项目流程，处理流程各个环节中所涉及的具体问题的方法和时机仍然有很大的不同，所以即使采用同样的项目流程，也不能保证一定会降低项目风险。最重要的是"活学活用，融会贯通"，流程、项目管理软件、文档等等都是项目管理的工具。
如何确定项目资源投入量？
一个项目投入的资源有很多不同的内容，我只想谈谈关于开发人员的投入。有些公司的做法是项目经理、系统分析工程师根据客户需求估计一个人数，公司根据资源情况确定投入哪些人、什么时候投入、投入多少人。
我有几点是不理解的：项目经理、系统分析工程师确定项目组人数的标准是什么，仅仅凭需求就可以估算需要的人数吗？在公司不把成本控制指标下放给项目经理的前提下，项目经理凭什么决定要用多少人？在项目经理和系统分析工程师不了解开发项目组有哪些可用人、他们的具体技术背景、性格、合作默契度等情况下，凭什么决定要用多少人？需要给客户报价是另一回事。
我希望项目经理能够明白，项目人员的匹配有一个最佳的匹配范围，超出这个匹配范围的人数对项目是有害的，而且多要人可能比少要人对项目的风险更大，一次性投入和分阶段投入人员采用的管理方法是完全不一样的，实践证明用追加人员的方式来追赶已经延期的项目进度往往会造成延期的更久。
大家可以思考一下，为什么项目经理和系统分析工程师在确定开发人数时倾向于尽可能的多要？而在项目延期时，项目经理采用最多的方式是追加人员？
如何看待客户不断的需求变更？
首先要明白两点：一是，需求变更是不可避免的；二是，客户是理缘摹?br>
关于第一点，应该没有异议。第二点实际说了两层含义，一是，客户提出的需求变更是有理由的；二是，实现需求变更的方式和方法是可以和客户沟通，达成一致的。
如何理解"沟通"？
从某种意义上说，相当大的一部分需求变更和项目问题都是由沟通不充分产生的。影响沟通的主要原因为：
1、信息不对称。提出需求的客户和系统的最终用户信息不对称（甚至有时候，我们从一开始就得到的是错误的需求），我们和客户之间信息不对称，业务分析人员和项目组其他人员信息不对称，系统分析人员和程序开发员信息不对称等等；
2、人的惰性。人的惰性决定了：有些客户不会认真看业务分析文档和需求分析文档，甚至不会认真参加讨论；有些程序员不会认真看设计文档，不努力去理解业务知识；我们的文档没有记录所有的重要信息，没有根据变化进行时时的修改和更新；
3、选择了不恰当的沟通方法。我们没有选择有效的沟通方法与客户进行沟通；项目组内部没有有效的沟通机制。
4、时间约束。项目是在一定的时间约束的前提下开发的，而另一方面是客户往往没有专职人员，客户的时间不是随时都可以被占用的。
软件项目理解篇二:软件项目管理的成功原则
软件项目管理的成功原则
任甲林（转载自中国系统分析员）
1 平衡原则
在我们讨论软件项目为什么会失败时可以列出了很多的原因，答案有很多，如管理问题、技术问题、人员问题等等，但是有一个根本的思想问题是最容易忽视的，也是软件系统的用户、软件开发商、销售代理商最不想正视的，那就是：需求、资源、工期、质量四个要素之间的平衡关系问题。
需求定义了"做什么"，定义了系统的范围与规模，资源决定了项目的投入（人、财、物），工期定义了项目的交付日期，质量定义了做出的系统好到什么程度，这四个要素之间是有制约平衡关系的。如果需求范围很大，要在较少的资源投入下，很短的工期内，很高的质量要求来完成某个项目，那是不现实的，要么需要增加投资，要么工程延期；如果需求界定清楚了，资源固定了，对系统的质量要求很高，则可能需求延长工期。
对于上述四个要素之间的平衡关系最容易犯的一个错误，就是鼓吹"多快好省"四个字，"多快好省"，多么理想的境界啊？需求越多越好，工期越短越好，质量越高越好，投入越少越好，这是用户最常用的口号。
多：需求越多越好吗？
软件系统实施的基本原则是"全局规划，分步实施，步步见效"，需求可以多，但是需求一定要分优先级，要分清企业内的主要矛盾与次要矛盾，根据PARETO的80-20原则，企业中的80%的问题可以用20%的投资来解决，如果你要大而全，对不起，你那20%的次要问题是需要你花费80%的投资的！而这一点恰恰是很多软件用户所不能忍受的。
快：真能快起来吗？
"快"是用户、软件开发商都希望的。传统企业里强调资金的周转情况，软件企业里强调的是人员的周转情况，开发人员应尽快做完一个项目再做另外一个项目，通过快速的启动项目、结束项目来承担更多的项目，来获利。但是"快"不是主观的拍脑袋定工期就可以完成的，工期的定义一定要基于资源的状况、需求的多少与质量的需求来进行推算的。软件毕竟需要一行代码一行代码的写出来，他的工作量是客观的，并非?quot;人有多大胆，地有多大产"式的精神鼓动就可以短期完成的。
好：什么是好软件？
软件系统的"好"字是最难定义、最难度量的。"让用户满意"是最高目标，你可以做到，但是资金的投入与时间的投入用户能否承担的起呢？在硬件生产企业中，产品的需求是明确的，是有形的，质量目标是明确的，是可以分解到各个作业环节中去的，而软件生产不具备此特征。在硬件生产中，生产能力是基本稳定的，对人员的依赖性较小，质量的要求对进度的影响并不是差别很大，而在软件生产中质量的一点提高或降低可能会对工期、投入产生巨大的影响，尽管用户没有明确定义出质量要求，所以软件生产是质量敏感型的生产。
省：省到什么程度？
"一分钱一分货"，这是中国的俗话，他是符合价值规律的。甲方希望少投入，乙方希望降低自己的生产成本，省到乙方仅能保本的时候，再省，乙方就亏损了。
正视这四个要素之间的平衡关系是软件用户、开发商、代理商成熟理智的表现，否则系统的成功就失去了一块最坚实的理念基础。
企业实施IT系统的首要目标是要成功，而不是失败，企业可以容忍小的成功，但不一定容忍小的失败，所以需要真正理解上述四个要素的平衡关系，确保项目的成功。
2 高效原则
在需求、资源、工期、质量四个要素中，很多的项目决策者是将进度放在首位的，现在市场的竞争越来越激烈， "产品早上市一天，就早挣一天钱，挣的就比花的多，所以一定要多挣" ，基于这样一个理念，软件开发越来越追求开发效率，大家从技术、工具、管理上寻求更多更好的解决之道。
基于高效的原则，对项目的管理需要从几个方面来考虑： 要选择精英成员 目标要明确，范围要清楚 沟通要及时、充分 要在激励成员上下工夫
3 分解原则
"化繁为简，各个击破"是自古以来解决复杂问题的不二法门，对于软件项目来讲，可以将将大的项目划分成几个小项目来做，将周期长的项目化分成几个明确的阶段。
项目越大对项目组的管理人员、开发人员的要求越高，参与的人员越多，需要协调沟通的渠道越多，周期越长，开发人员也容易疲劳，将大项目拆分成几个小项目，可以降低对项目管理人员的要求，减少项目的管理风险，而且能够充分地将项目管理的权力下放，充分调动人员的积极性，目标会比较具体明确，易于取得阶段性的成果，使开发人员有成就感。
作者主管过的一个产品开发项目代号为SB，该项目前期投入了5人做需求，时间达3个多月，进入开发阶段后，投入了15人，时间达10个月之久，陆续进行了3次封闭开发，在此过程中经历了需求的裁剪、开发人员的变更、技术路线的调整，项目组成员的压力极大，大家疲惫不堪，产品上市时间拖期达4个月。项目完工后总结下来的很致命的一个教训就是应该将该项目拆成3个小的项目来做，进行阶段性版本化发布，以缓解市场上的压力，减少项目组成员的挫折感，提高大家的士气。
4 实时控制原则
在一家大型的软件公司中，有一位很有个性的项目经理，该项目经理很少谈起什么管理理论，也未见其有什么明显的管理措施，但是他连续做成多个规模很大的软件项目，而且应用效果很好。作者一直很奇怪他为什么能做的如此成功，经过仔细观察，终于发现他的管理可以用"紧盯"2字来概括，即每天他都要仔细检查项目组每个成员的工作，从软件演示到内部的处理逻辑、数据结构等，一丝不苟，如果有问题，改不完是不能去休息的。正是在他这种简单的措施下，支撑他完成了很多大的项目，当然他也是相当的辛苦，通常都是在凌晨才去休息。我们并非要推崇这种做法，这种措施也有他的问题，但是，这种实践却说明了一个很朴实的道理：如果你没有更好的办法，就要辛苦一点，实时控制项目的进展，要将项目的进展情况完全的实时的置于你的控制之下。
上述的方法中对项目经理的个人能力、牺牲精神要求是很高，我们需要有一种进行实时控制项目进度的机制，依靠一套规范的过程来保证实时监控项目的进度。如在微软的管理策略中强?quot;每日构建"，这确实是是一种不错的方法，即每天要进行一次系统的编译链接，通过编译链接来检查进度、检查接口、发现进展中的问题、大家互相鼓励互相监督。
实时控制确保项目经理能够及时发现问题、解决问题，保证项目具有很高的可见度，保证项目的正常进展。
5 分类管理原则
对于不同的软件项目其项目目标差别很大，项目规模也是不同的，应用领域是不同的，采用的技术路线差别也很大，因而，针对每个项目的不同特点，其管理的方法、管理的侧重点应该是不同的。就像古人讲的，"因材施教"，"对症下药"。对于小项目你肯定不能象管理大项目那样去做，对于产品开发类的项目，你也不可能象管理系统集成类的项目那样去做，项目经理需要根据项目的特点，制订不同的项目管理的方针政策。如，下表是作者为一家应用软件公司制订的项目管理的方针：
在该案例中，将项目分成了订单类项目与非订单类项目，非订单类项目是指由公司根据市场的需求开发一个标准产品的项目，而订单类是指针对某个具体的客户定制软件的项目，订单类的项目根据需要协调的资源的范围有划分成了公司级、部门级、个人级三类，非订单类根据估算的工作量的大小也分成了A、B、C三类，估算的工作量超过720人天的为A类，超过360人天的为B类，360人天以下的为C类。不同类的项目管理的侧重点是不同的，从立项手续的完备性、计划的严格层度、周报的完备层度、规范的严格层度、跟踪的实时性、是否进行阶段总结、是否核算项目成本、是否严格进行阶段评审等多个方面来考虑，以确保管理的可行性。
6 简单有效原则
项目经理在进行项目管理的过程中，往往会得到开发人员这样的抱怨"太麻烦了，浪费时间，没有用处"，这是很普遍的一种现象。当然这样的抱怨要从2个方面来分析，一方面从开发人员本身可能存在不理解，或者逆反心理的情况，另一方面，项目经理也要反思：我所采取的管理措施是否简单有效？搞管理不是搞学术研究，没有完美的管理，只有有效的管理，而项目经理往往试图堵住所有的漏洞，解决所有的问题，恰恰是这种理想，会使项目的管理陷入一个误区，作茧自缚，最后无法实施有效的管理，导致项目的失败。
7 规模控制原则
该原则是和上面提到的其他原则相配合使用的，即要控制项目组的规模，不要人数太多，人数多了，进行沟通的渠道就多了，管理的复杂度就高了，对项目经理的要求也就高了。在微软的MSF中，有一个很明确的原则就是要控制项目组的人数不要超过10人，当然这不是绝对的，也和项目经理的水平有很大关系。但是人员"贵精而不贵多"，这是一个基本的原则，这和我们上面提到的高效原则、分解原则是相辅相成的。
软件项目理解篇三:软件项目需求分析总结
需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键 总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况： 客户本身说不清楚 文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。 需求自身经常变动 随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。 分析人员或客户理解有误 毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。 由此出现的问题： a) 需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。 b) 需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。 c) 需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。 d) 对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。 e) 项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。 f) 此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。 结论 a) 需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。 b) 需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。 c) 需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。 d) 需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生 e) 需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。 f) 需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题 g) 帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解 h) 最后，需求分析报告一定要双方共同签字确认。
