Category Archives: 项目管理

  近来项目基本处于停顿状态，所以有时间停下来好好总结下。 　　由于项目进行中经历了项目经理的更换，所以对不同的管理方法有一些自己的看法。试着从程序员的角度来看看项目管理。先看两个问题： 　　1.文档 　　很多程序员都有一样的想法，就是很讨厌写文档（起码是过多的文档），可是项目管理者偏偏最看重这个，他们整天催你交他认为必须的文档，拿到手后又这也不对，那也不对，吹毛求疵。程序员讨厌这样，但是却不能表现出什么不满，抵触情绪自然会影响到工作。 　　2.进度 　　一般项目开发都会有一个进度安排，用Project也罢，用其它的也罢，但是都会精确到某一段时间内完成什么任务。程序员都按照这个来工作，进度落后了要加班，超前了会休息一下，看看书，学习学习。但是偏偏项目管理人员天天来问你，有时甚至一天几次：进度怎么样了？能完成吗？这时候开发人员会极度反感。“进度怎么安排的，我心里清楚，干嘛跟催命似的，我又不是奴隶，长工！！”但是有苦不能言啊，只能憋心里。 　　为什么出现这样的情况？ 　　有的项目管理者在项目刚开始的时候作需求，作计划，估算等等，忙的不亦乐乎，但是随着设计，编码工作的展开，他们的职能似乎就退化了，不参与设计，更不要说编码了，他们的任务逐渐变的就只剩催交文档和进度跟踪了，而对于真正的软件不闻不问。不去了解设计，更不要说去看代码，看也是在评审的时候看你是不是遵守编码规范，或界面上的一些bug。而对设计和怎么实现的毫不关心。但是对文档却是一个也不能少，而且还在格式上费尽心机。他们以为这样就可以很好的证明项目还在自己的控制中，而且这些开发人员也很听话，可以向老板表明他也很忙，也作了很多事情。所以我认为这种现象的根本原因就在于项目管理人员认为他们作的是管理（而不是真正的参与），只要有文档，有可控的进度，项目就尽在掌握；更甚者，他们除了文档和进度就再也无事可作，变成了一个真正的”闲事主任“，他知道别人的进度，但却不知道自己的进度。 　　解决的办法就是真正的参与到项目的开发中，设计，编码，不需要很多精力，但是已经足够在开发中树立你的威信，在别人碰到问题的时候能够和他们进行更深层次上的讨论，交流。在评审时才能够看到问题的本质，而不是些细枝末节。一方面增加了自己在项目中的作用，另一方面能和开发人员真正成为一个团队，消除对立的情绪，和开发者的关系由“你们”变为“我们”，尽管立场和根本出发点仍然不同，但是已经可以互相理解，协作。更重要的是，知道项目当前最需要的是什么，文档？交流？或是一次“站立会议”？而不是想当然的“瞎指挥”。      我并无意贬低项目管理在开发中的作用，更无意贬低项目管理人员，只是就我自己在开发中碰到的我觉得不合理的情况发表一点自己的看法（顺便发点牢骚），希望我的偏激没有冒犯那些真正出色的项目管理者，并且非常希望能看到来自项目管理者的观点。转

IT项目管理-启动-干系人分析   项目经理接受委任后，个人认为最重要的一件事情就是进行干系人分析。或者讲在启动前或被委任前就应该进行干系人分析，很简单的道理，比如高层管理都对项目不支持，项目经理再有能力也无法使项目实现目标。 干系人是对你项目的目标达成有影响的所有人，如果要关注项目开发出的产品所带来的长期效益，则干系人应该是对项目所开发的产品的整个生命周期都有影响的所 有人员。干系人的识别，干系人分析都不是干系人管理的最终目标，最终目的都将落到项目经理如何利用分析的结果，通过自身所拥有的资源，技能，沟通等去影响 干系人的行为，以达成项目的目标。 1.项目的出资方和赞助人 对于赞助人始终关注的如何使自己的投资有最丰厚和深远的回报，同时又将风险控制到最低。 跟个人投资是一个道理，投多少钱不是问题，关键是如何保证投入有低风险，稳定和客观的回报。因此赞助人不仅仅关注项目本身是否成功按目标完成，而是关心产品能否成功按计划推入市场和创造效益。 对于项目周期较长的时候，为了项目本身降低风险和满足干系人预期，项目迭代开发就显得更加重要。迭代开发可以保证将项目分为多个迭代周期，每个迭代版本都 是可用的而不是一个半成品，项目最终交付成果会分为多个迭代版本交付，赞助人可以尽可能早的看到项目所创造的产品或成果。同时采用迭代开发每个迭代版本都 可以尽可能早的投入市场和进行市场推广，资金不用一次性的全部投入，可以通过市场的反馈不断的纠正方向和需求。 2.项目高层领佳节又重阳导 高层领佳节又重阳导一般是期望项目取得成功的，但高层领佳节又重阳导关注的是PPM(项目组合管理)，因此项目经理一定要清楚在多项目，自己的项目在高层领佳节又重阳导眼中的优先级和地 位。明白了这点才能够分析在多项目资源冲突的情况下，自己的项目如何去通过高层领佳节又重阳导协调更多的资源。项目经理需要让高层领佳节又重阳导更加了解自己的项目，需要及时 准备的定期反馈和汇报项目进展，当出现资源问题时候需要有说服力的证据和数据，通过需要提前提出问题给高层领佳节又重阳导进行协调预留时间。 项目没有出现问题，往往高层领佳节又重阳导认为项目运转良好而不受重视，项目经理简单认为暴露了问题可能会使高层领佳节又重阳导怀疑自己的管理水平，而实际隐藏问题本身，这往 往导致项目最终无法实现目标交付。因此勇于暴露项目自身问题，积极汇报高层领佳节又重阳导，请求协调和资源是项目执行中项目经理沟通的一个重要方面。 3.项目产出物的最终用户 用户是重要的干系人，直接关系到项目成果能否创造最大效益。在项目启动和确定范围前期，充分的用户需求调研是必不可少的，另外在项目执行过程中可以分多个 迭代周期，每一个迭代周期都可以让用户参与进来反馈意见，及时纠正各种偏差，避免前期的缺陷泄漏导致后期过大的纠正成本。项目目标是否能够实现是项目经理 必须重点关注的，但项目说输出的成果能否赚钱则显得更加的重要，要使产品能创造价值则必须多考虑用户的需求和反馈意见。如果在项目执行过程中，发现了一个 重要的用户反馈需要变更项目范围，在这种情况下项目经理要勇于提出并找高层领佳节又重阳导和赞助人协调资源，而不是置之不理的仅仅为了完成项目启动制定的目标。 4.项目组成员 项目目标制定合理，高层领佳节又重阳导也能够保证项目资源，这个时候项目成功取决于项目经理，但项目经理必须清楚项目成功依靠的是整个项目团队的共同努力。对每个项 目成员的性格特点和技能特长进行分析是很重要的，但之前需要先搞清楚项目能够带给项目成员什么以及项目成员能够从项目中获取哪些收益？知脉，财脉和人脉仍 然是三个重要的方面，需要根据各个项目成员不同的需求在这三个方面进行平衡。明白了这些才可能在后期的人力资源管理和角色岗位分工中给出较合理的安排。如 果项目经理不管钱，项目成员绩效考核也不在项目经理，在这种情况下项目经理是很难对整个项目进行管理的，及时项目经理有很强的个人领佳节又重阳导力和权威。

如何加强项目团队的凝聚力 （一）凝聚力的概念 凝聚力指团队对成员的吸引力，成员对团队的向心力，以及团队成员之间的相互吸引。也有人把凝聚力定义力：团队使成员积极从事团队活动，拒绝离开的吸引力。团队的凝聚力不仅是维持团队存在的必要条件，而且对团队潜能的发挥有重要作用。一个团体如果失去了凝聚力，就不可能完成组织赋予的任务，本身也就失去了存在的条件。 （二）影响团队凝聚力的因素 一个团队的凝聚力大小是多种因素的结合： 1．成员与成员之间的吸引力。成员利益一致，关系和谐，互相关心、爱护和帮助，吸引力就大；反之，吸引力就小，甚至相互反感，相互排斥。 2．团队活动对成员的吸引力。团队活动的内容、形式、频率适合成员，吸引力就大；反之，活动不受成员的欢迎，吸引力就会降低，甚至会令成员产生厌倦、反感心理，从而脱离该团队。 3．团队对满足成员个人需要的吸引力。团队满足成员个人的各种物质和心理需要，是增强团体吸引力的最重要条件。 （三）凝聚力与生产效率之间的关系 团队凝聚力与团队工作效率之间的关系有人作过大量研究。结果表明，凝聚力的大小对生产效率有重要的影响。一般情况下，凝聚力强的团队比凝聚力弱的更有效率。凝聚力与团队工作效率之间的关系很复杂，还会受其他因素的影响，罗宾斯等人曾对此进行过研究，认为团队凝聚力与团队工作效率之间的关系存在以下四种情形，     ①团队目标同组织目标一致程度高，则团队的凝聚力虽然低，也能提高生产率     ②团队目标同组织目标一致程度高，团队的凝聚力也高，会大大提高生产率；     ③团队目标与组织目标很不一致，但团队的凝聚力却很高，那么，生产率就下降；     ④团队目标与组织目标一致程度很低，如果团队凝聚力也低，它对生产率不会产生明显的影响。 可见，凝聚力对生产率的影响还与团队目标同组织目标一致性有关。当团队与组织的目标一致时，增强凝聚力会大幅度提高生产率。研究者证实最好的团队的生产率是最差团队的至少4倍，不同的团队完成同样的项目需要的时间会有2.6:1的差距。1993年美国的一项研究中，B. Lakhanpal报道了在31个软件项目中团队的凝聚力、个人能力和经验如何影响整个项目业绩。项目持续时间从16个月到14个月不等，项目团队有4-8人，B. Lakhanpal发现项目团队的凝聚力要比个人能力和经验对生产率影响更大。B.Lakhanpal指出，在选择项目团队成员时，应把他们可能对增强项目团队凝聚力的贡献作为首要标准，其次才是他们的个人能力。 （四）增强项目团队的凝聚力 由前面的研究可以看出，项目团队的凝聚力不仅是维持项目团队存在的必要条件，而且对项目团队潜能的发挥、项目团队生产效率的提高有重要作用。因此项目经理应注意在工作中采取必要的措施不断增强项目团队的凝聚力，并引导团队成员努力为实现项目目标而工作。从前面的分析可知，要增强项目团队的凝聚力，项目经理应采取以下措施 1.建立共同的愿景 愿景是项目经理与项目组织成员共同建立起来的、融项目目标与个人目标于一体的、项目组织成员们努力要追求的目标。有了这样一个目标，项目团队就可以对团队成员产生强大的吸引力，从而增强团队的凝聚力，另外，愿景使组织目标与团队目标高度一致，因此可以使团队的生产效率大大提高。 2.采取措施满足项目组织成员各种物质和精神需求 除了建立共同的愿景之外，在项目建设的过程中，项目经理应注意采取必要的措施满足项目组织成员各种物质和精神需求，使其不断受到激励，从而增强团队对他们的吸引力。如：通过使成员承担的工作内容更有挑战性，授予他们在工作中更大的自主权，来满足他们希望实现自我价值的精神需要；通过为成员提供学习的机会，来满足他们希望不断提高自身价值、不断成长的需要；通过公平合理的工资和奖金的发放，来满足他们希望不断改善生活条件的需要；通过各种各样丰富多彩的业余活动的安排，如聚餐、郊游等，来满足他们希望与人交往、沟通的需要。 3.成为具有超凡魅力的领佳节又重阳导者 美国的罗伯特.豪斯认为具有超凡魅力的领佳节又重阳导者具有以下特点：自信；有远见；能清楚表述目标；对目标的实现具有坚定信念；不循规蹈矩；努力变革；对环境敏感。有超凡魅力的领佳节又重阳导者对下属有什么样的影响呢？罗伯特。豪斯对此也进行了研究，她的研究表明，有超凡魅力的领佳节又重阳导者与下属的高绩效和高满意度之间有着显著的相关性。为有超凡魅力的领佳节又重阳导者工作的员工，会因为受到激励而付出更多的工作努力，而且，由于他们喜爱和敬佩自己的领佳节又重阳导，也会表现出更高的满意度。而满意度越高，团队的凝聚力越强。 团队可以定义为：两个或两个以上相互依赖的个体，为了实现某一特定的目标而组成的协作团体。

项目经理10大成功态度  态度决定一切，要将项目做好，除了要掌握项目管理技能之外，项目经理更应该具备良好的态度，有人总结了10大成功态度如下: 1. 要有“一定要”的决心:一个人不是一定要的时候，连小石头都可挡住他的去路，只有“一定要”的人，再大的障碍都挡不住他想要的结果。 2. 要有强烈的企图心:要以成为行业中的世界最顶尖为目标。只要能找出一个成功的理由，你就能够成功! 3. 相信:成功者先相信，后看见，目标决定策略，只要精神不滑坡，方法总比困难多。 4. 做事:成功者愿意做一般人不愿意做的事，成功者愿意做一般人不敢做的事，成功者做一般人做不到的事。 5. 对待问题:你要了解解决问题，是一种态度而不是技巧，因此你必须相信你能解决所有问题。 6. 发挥潜能:人的潜能是无限的，你永远不知道你的潜能极限在哪里?不断地告诉自己:我喜欢我自己，我是最棒的。 7. 不要找借口:成功者找方法，失败者找借口;要成功就不要有借口，要借口就难以成功;当你没有借口的那一刻，就是你选择成功的开始。 8. 不怕困难:成功者“热爱痛苦”。 9. 学习经验:成功者学习别人的经验，一般人学习自己的经验。 10. 绝不放弃:成功者绝不放弃，放弃者绝不成功。

IT项目管理-计划-项目目标和范围   有了初步的项目范围，并委任了项目经理后可以进入到项目计划阶段，做项目计划过程仍然是目标驱动，树立系统观和关注各要素的平衡。因此首先需要确定项目的目标和项目的范围。 1.项目目标的来源和包含的内容 项目的目标不是无源之水，项目目标必须来源于组织的商业目标，而组织的商业目标就是在某个时间期限中获取最大的效益和利润。因此，有了商业目标驱动，项目目标应该包含进度，质量，成本三方面的目标，具体三方面的目标如何平衡即是通过组织期望获取价值和创造利益的过程是一个短期行为还是一个长期行为。 进度，质量，成本三方面的目标都会有一个最低限的目标，当发生最低限目标都无法满足的情况最有效的方式就是削减项目范围，如果范围也不能变动则必须提高项目团队的生产率。 项目目标根据商业目标确定，而项目目标确定后又驱动项目计划的具体制定过程，项目计划中关于进度，人力，资源，成本，质量等目标的安排都应该围绕项目目标进行。 2.项目目标的确定过程 首先必须搞清楚用户真正的需求和组织的商业目标，然后根据商业目标确定项目四要素中关键要素和约束(不能变动或变动范围很小的要素)。 对于其它可变要素间本来就会存在影响和相互制约，比如多投入项目成本可以获取到更好的产品质量。因此需要对各可变要素进行多种组合分析，分析在哪种组合下对于企业在某个时间期获取到最大收益是最有利的。 一个好的项目目标必须和企业商业目标一致，最终体现到项目创造的产品和服务能够为企业创造最大的价值和收益(包括潜在的无形收益)。 3.项目的范围 项目范围和产品范围不同，产品范围关注的是产品各阶段产出物本身以及整个包括了项目完成后维护的产品生命周期。而项目范围来源于产品范围，来源于产品需求和用户需求。通过对产品需求和用户需求的分析，根据选择的产品生命周期模型制作相关的WBS分解结构，前期需求文档或SOW工作说明书，加上WBS工作结构分解共同构成了项目的范围，也可以简单理解项目范围就是项目正式启动后到项目结束所做的任何事情都应该体现到项目范围中。 在计划阶段我们会对风险进行识别和分析，针对关键风险会制定风险应对和减轻计划，这些减轻计划会对应项目中相关活动和任务，这些也属于项目范围的重要组成。 为了使项目达到预期的质量目标可能会增加评审，测试，培训，代码Review等相关工作，这些工作都是项目范围的重要组成部分。项目日程固定周期的会议，项目经理对项目的跟踪控制，项目计划的制定过程等内容也属于项目的范围。 4.项目的范围定义的目的和要素 项目范围的定义是制定WBS工作分解结构，项目估算，进度安排。项目变更，跟踪控制，基线比较的基础。项目计划阶段项目范围必须明确，项目管理过程只应该做该做的事情，因此范围既不能遗漏也不能镀金。 项目范围必须是明确和可以验证的。因此WBS对应的分解工作包也必须有明确的可以验证的输出。项目范围的要素或输入有产品规划，立项报告，SOW,用户需求，产品需求等，这些都可能是项目范围重要输入。

项目接近尾声时不能忽视的10件事   对于你的组织规模，你可以把项目管理视为一项偶尔的实践或者可以拥有一个复杂的PMO。不论那种情况，你可能通过典型的项目初始、精化和构建过程。但是到了项目终结的时候，很多项目经理只讨论短期的终点线。最后的步骤处理不好会给行动增加混乱并且可能导致客户不满、员工不悦，并把项目拖得比所需时间更长。 　　 　　这里是一些你需要在达到你下一个项目的终点时要考虑的事情。其中有些项目是纯管理的，但其中很多能帮助你进一步保证你的项目能够成功。 　　一、最终测试 　　测试会耗费人员，而我们很多人都不愿意去做——特别是做过几轮之后。我见过大量的四到六个月的项目有一两天的计划去测试。没有安排适当数量测试的项目通常在实施的最初几周内因问题而结束。这里不要走捷径和将测试的重要性减至最小；否则，你会为痛苦的进展过程而承担额外的风险。 　　二、最终培训 　　用户？谁关心用户？好了，很多项目都为了他们的利益而做，所以确信把你所有的测试资料完成并移交。这个不做好最有可能体现在发怒的客户半夜三更打来的愤怒的电话上。 　　三、确认交付物 　　你检查了所有的箱子并清理了收件箱，而且你想真地结束了。但你的客户怎么想？安排时间和你的客户检查所有的交付物并且确认他们已经得到满足了。有些情况下，可能有一些特殊问题到你计划终止日期时尚未解决。在你项目的早些时候，应该有一份协议来决定如果发生这样的情况会如何影响你的结束日期。 　　四、获得项目签字 　　当你获得所有交付物都已满足的认可以后，请求在项目文档上做一个正式的签字。这样做帮助确保所有人都认可项目状态。因为这个签字通常标志着项目的正式结束，注意不要让你的客户感觉签字的压力。如果他们在不明所以的情况下做了，你可能会在日后出现问题的时候最终得到一个不满意的客户。 　　五、解散团队 　　现在项目完成了，你的团队何去何从？基于你的组织，他们可能被送回一个开发池或者去做业务。或者他们需要在企业内部为自己发起一些工作。不管是什么，你要保证花点时间和他们在一起，并且设置一个明确的不再需要他们的服务的最后日期。同时不要忘了你可能需要完成一些需要加入他们档案的业绩审核文档。 　　六、分析实际与计划的对比 　　资源——你是否真正摆脱了10周只有一个开发者/测试员，或者你需要去争夺并得到更多的人员？你为你的商业伙伴安排的时间量怎么样？明白你有多接近这些目标能帮助你为下一个项目更好地分配资源，并且在下一个项目来临时为它设定更切实的预期。 　　预算——项目要花费多少？你是达到预算、未达到预算、超出预算？坐下来弄明白这些基本问题的答案会给你一些对任何项目临界区域的洞察力。 　　七、存档文档 　　任何项目期间，好像我们都创建大量的文档。其范围可能从范围文档和项目计划到合同和会议纪要。不管是什么，在你结束时根据企业的保留策略应该有地方保存它们。当两年后你的电话铃响起来并且有人要你解释项目期间你所做的一个决定的背后原理时，你将会很高兴。 　　八、确保合同终止 　　一个项目不常有自己的预算。你可能还有硬件、软件或专业服务的合同。在你完成以后，确认检查合同的所有项目都满足了，向供应商索要发票并把它们提交给 AP，并且关闭任何相关的财务帐目，如果需要的话。 　　九、举行一个验尸会议 　　什么类型的风险你识别并减轻了？你想用以确保下次再做的什么真的变好了？和所有的项目利益相关者和有关参与者开个会，向他们提供了一个论坛来表述所学到的教训。 　　十、执行一个自我评估 　　终于结束了。在所有的艰苦工作都完成以后，你已经确认所有的 i 都被加了点而且所有的 t 都加了横。现在做什么？从和你在项目中互动的人员那里得到一些关于你绩效的反馈是重要的。如果你有机会发一份360度反馈调查给尽可能多的个人，我建议你这样去做。这会帮助你评估你进步了多少并且能给你一些极大地提示来决定你该着眼于哪些个人成长的机会。 　　这个清单并不是对每个人都一样，并且根据你的组织和它如何部署项目会有不同。但如果你能够去做，它会永远使到下一个项目的过渡更顺畅。  

软件需求设计评审之八项注意 摘要 一、注意对需求规格说明的正确性进行评审；二、注意对需求规格说明的实践性进行评审；三、注意对需求规格说明的完整性进行评审；四、注意对需求方案的可行性和成本预算进行评审；五、注意对需求的质量属性进行评审；六、注意对需求的可实施性进行评审 1931年，中共中央代表欧阳钦在向党中央报告说明中央苏区情况时，具体地说明了红一方面军的“三大纪律八项注意”, 此后三大纪律八项正式成为了全军和地方武装的纪律。本文所讨论的“八项注意”是对于软件需求设计评审工作的一些情况的说明。     现在让我们把目光聚焦到软件需求设计评审上来, 我们已经知道如何去获取需求,也知道了撰写需求规格说明书。现在的问题是,我们所撰写的需求规格说明书是否能让用户接受呢? 而用户又如何对需求说明书作出理性和客观的评审和确认呢? 事实上，当我们撰写需求规格说明书的时候不妨站在用户的角度去评写，唯其如此方能事先避免一些问题。本文探讨用户应该如何去“评审”软件需求说明书，并因此提出了需求评审的”八项注意”，以飨同仁。      需求确认是需求开发过程的第四个阶段,前三个阶段按顺序分别为需求获取、需求分析、编写需求规格说明。需求确认活动要力图确保如下几点:      １需求规格说明正确描述了预期的、满足各方涉众需求的系统能力和特征。      ２所述之软件需求是由系统需求、业务规格和其他来源中正确推导而来的。      ３需求是完整和高质量的。      ４需求的表示在所有地方都是一致的。      ５需求为产品设计和构造提供了基础。      需求确认活动可以确保需求符合优秀需求陈述的特征，包括完整、正确、可行、必要、具有优先级、无二义性和可验证, 同时亦符合好的需求规格说明的特征，即完整性、一致性、易修改和可跟踪性。      一般而言，我们通过需求评审活动去实现需求确认的目标, 参与评审者应包括各级客户、开发人员和测试人员, 在整个审查过程中，我们会有诸多“注意”。事实上,在实践活动中,每个企业会根据自身的情况存在更多的检查事项, 在此列出的八项亦属于最基本的要素。      一、 注意对需求规格说明的正确性进行评审      需求规格说明的正确性通常可以从如下方面得以体现：      1 是否有需求与其他需求相互冲突或者重复？      通常一份长达几百页的需求规格说明书都不会是一蹴而就的，它可能是系统分析师几个夜晚的心血之作。正是因为撰写过程的连续性，可能导致同一份文档中前后名词定义不一致，前后观点上有重叠或差异的情况出现，这需要我们在撰写报告前首先要在思想上形成统一概念, … Continue reading →

项目管理中的15个主要关注点   如何让项目朝着既定的目标良性进展？如何让项目能最终获得成功？针对这两个问题，我想每一位项目经理都会有自己的见解。以下结合作者的项目管理经验，总结出有助于项目良性进展、有助于项目成功的15个主要关注点，试图与项目经理们分享自己的心得和体会。       1、项目目标 　　“目标是行动的航标”，因此目标对项目的重要性不言而喻。 　　一个不关注项目目标的项目经理，最终只能将项目带入失败。实践已经并继续证明，任何不针对目标的行动都将是徒劳的。因此，项目经理一定要将项目目标装在“心”里并时时关注。 　　2、项目范围 　　“项目范围实际上就是我们工作内容的一个映射”，项目范围同时也决定了我们工作量的大小。 　　项目经理如果对项目范围没有一个清晰的把握并合理控制，则项目组开展的一些工作很可能于事无益，其结果只能是劳民伤财。 　　3、项目计划 　　“计划是行动的纲领”，项目计划的重要性我想已经是尽人皆知了。 　　项目经理不但需要重视项目计划的制定，更需要重视项目计划的执行。计划能使我们的思想具体化而体现出我们期望做什么、什么时候做、谁去做以及如何做，因此任何不在项目计划指导下的行动都将“杂乱无章”，甚至给项目带来巨大风险。 　　4、项目质量 　　“质量是项目的生命”，没有质量的项目无疑是失败的项目。因此，项目经理需要时时关注与项目质量密切相关的各种活动。 　　5、项目进度 　　“进度往往就是效率”，项目特别是商用项目，进度往往决定了它的市场价值。因此，项目经理在关注项目质量的同时，也需要密切关注项目的进展。 　　6、项目成本 　　“资本是项目得以正常开展的命脉”，一个成本失控或成本超标的项目，将面临很大的项目维系风险。 　　7、项目风险 　　“项目风险是影响项目能否顺利开展并取得最终成功的唯一不确定因素”。项目经理需要时时关注项目风险的状态，准备好应对预案做到“有备无患”，并尽可能消除不利风险发生的环境和条件。 　　8、项目干系人 　　“平衡项目干系人的期望是项目最终能得到各方认同的基础”，一个不能平衡并满足项目干系人期望的项目经理，在项目的开展过程中将会“举步唯艰”。 　　9、目标用户 　　目标用户虽然属于项目干系人范畴，但目标用户有别于其他项目干系人的一个明显之处是：他们是项目成果的最终使用者。目标用户的特征（如工作岗位、能力水平等）将在很大程度上决定了项目所需要的开发方式和项目成果的展现方式（如开发一个计算机应用系统，如果用户的计算机操作水平较低，则系统的设计就需要考虑尽可能简单、易学、易操作）。 　　10、项目团队 　　这里提到的项目团队主要是指项目经理所领佳节又重阳导的项目组。 　　“项目团队是项目成果的直接缔造者”，项目团队的工作效率直接决定了项目的效率。因此，项目经理需要非常关注项目团队成员（包括项目团队建设、绩效考核等）。 　　11、项目实施和运行环境 　　“项目实施和运行环境不但决定了项目的实施策略而且也在很大程度上决定了项目所需要的开发技术和模式”（如开发一个计算机应用系统，系统运行环境将在一定程度上决定了系统所可能采用的开发技术）。 　　12、产出物评审 　　“评审是发现问题最有效、最及时的方式之一”，一个问题多多的产出物一定会给后续工作带来巨大的障碍和风险。因此，项目经理一定要关注项目产出物特别是关键产出物的评审，决不要以为评审是走“过场”，是一个可有可无的活动。 　　13、缺陷 　　“缺陷是项目的定时炸弹”，如果缺陷被消除，就相当于消除了定时炸弹、消除了安全隐患。因此，项目经理一定要关注项目进展过程中所发现的各类缺陷，做到多发现、早消除。 　　14、用户问题 　　“用户问题是否被有效解决直接决定了用户对项目的配合程度和对项目成果的最终接受程度”。因此，用户问题是项目经理一定不能忽视的问题。 　　15、里程碑总结 　　“总结是发现问题并规避问题再次发生的最佳办法，是提炼经验并发扬经验的有利时机”。项目经理不但要重视项目进行中的阶段总结，也需要重视项目完结后的项目总结，因为项目总结为下一个项目提供了良好的经验借鉴。 　　项目管理中所需要关注的问题还很多，以上只是结合作者的经验总结了15个方面。由于项目的多样性，各项目的主要关注点也不尽相同，这需要我们具体情况决定分析，在参考自己和别人经验的基础上灵活把握。

对软件项目中产生的需求进行分级管理 　　客户的需求是否应该得到满足?软件工程是否目的就是满足客户的需求?这个问题看来是无法加以回答的，因为，它没有提供两个基本的解释，其一：客户的需求即算从客户的利益立场出发，是不是合理的?其次，客户的需求有多大程度上是必要的?还是只是一种个人的喜好? 　　如果说对于商业客户来说，在项目开始前，还存在着做与不做;以及多少价钱来做的选择的话，那么，在许多情况下，工程人员如果不对此有明确的立场，唯一的结果就是累死自已，而软件项目永远不令人满意，也永远不能完成。对于商业性客户来说，客户的需求是否合理是客户自已的事情，客户永远是对的，这句口号的台下词是：只要客户肯掏钱，那怕他要跳海，那也是他自已的事!但如果项目是已经签署定的合同单，那么就存在着是否按原合同继续，还是中止，还是变更付款条件的的问题。而对于内部项目，所谓的成本就是工程人员有多累和什么时侯累死的问题。这时侯，软件工程从业人员最好能够明白，在自已累死以前，老板，以及那些不学无术对技术一窍不通却自以为是行里大家的同事，都不会对你有任何怜惜的。 　　所以这时侯那种无条件满足客户需求的工程需求管理就不适用了，这时侯，软件工程人员只能根据自已能够承受的工作强度对各种需求进行取舍，而不是无条件地牵就“客户”的需求，更不是迁就无知的需求。客户是上帝这句话这时侯完全不适用，因为客户不会为朝改晚改的需求付钱，付帐的是程序员自已——让自已早点累死。 　　把种种需求明列并分级是唯一的办法;自已就按步就班一点点地完成，这是唯一的办法。事实上，对于商业客户这也是适用的，因为收钱的毕竟是公司老板而不是项目组的程序员，公司老板收了钱就不管实际项目成本是多少而让程序员无条件接受客户的需求也是常见的事情。所以把需求明列，既是让老板明白眼前项目的成本到底是多少(老板通常是技术盲)，也有了与客户讨价还价的根据。 　　我把需求分成五个等级。五分等级也是工程技术上的常用方式，如同大学的五分制。 　　一级需求(或改变)是关键性的需求，这种需求如果不满足，意味着整个项目不能正常交付使用，前期工作也会被全部否定。这是必须满足的，否则就意味着否定程序员自已。所以定为Urgent.; 这通常是属于补救性的debug类型，要救火。 　　二级需求(或改变)是后续关键性需求，它不影响前面工作内容的交付，但不加以满足，新的项目内容无法提交或继续。所以是NECESSARY;一般新模块关键性的基础组件，属于这个级别。 　　三级需求是后续重要的需求，它不能满足会令整体工作价值下降，为了体现项目价值，也是程度员自已的技术价值的证明，所以定为NEEDED;一般性的重大的有价值的全新模块开发，属于这个级别。 　　以上三个等级是应该实施的，但时间性上可以作优先级的排列。 　　四级需求是改良性需求，没有它并不影响已有功能的使用，但实现了，有可信的根据可以是BETTER。界面和使用方式的要求，一般在这个档次。 　　五级需求是可选性需求，没有它没有谁会活不下去，有了它，没有根据一定带来好处，更多是一种设想，以及一种可能;通常只是需求代理人员的一种个人喜好。所以是MAYBE。 　　对于四级需求，工程人员项目有空，不妨做下去;对于五级需求，有兴趣有余力就做，没有兴趣或者没有余力，管他需求不需求，除非额外付大钱，就让提这些外行需求的家为一边凉快去。  

软件公司对从事需求调研人员的基本素质是不太注意的，企业的信息化主管经常可以看到软件公司派住的调研人员的年龄是偏低的、经验是不够的。在我与企业中、高层管理者的交流中，他们普遍都有这样的感觉： “对于企业来讲，我们不太清楚信息化调研应当怎样开始，又怎样结束，我们实际上更关心的事情是把我们现有的管理方式向软件公司转达，并且不要寄希望这种转达是全面的，当面对转达不全面的时候，就需要软件公司的人员多问、多探讨，我们上管理系统的过程中也接触了不少软件公司的设计人员、需求人员，但是在与我们的交流过程中，感觉他们总是缺乏调研思路和必要的管理知识，许多是非常常用的管理知识他们也不太清楚，这样在调研中只能够在一些局部的问题上进行讨论，这些局部还是靠我们自己的中层管理者对于管理中所存在的问题而提出来的，而这种主动提出问题的现象，是当碰到了喜欢交流的经理们和业务骨干们的时候才能够有的情况”。 “大部分的调研情况是不好的，你知道，我们的许多业务骨干和经理们他们对于计算机是陌生的，对于信息化更是陌生，你让他们谈需求，首先是要与他们交流，在交流中获得需求。这就需要、讨论需求的软件公司人员必须有一定的管理知识和一定的管理经验，要用启发方式进行调研，否则我们的许多人不知道说什么，也不知道你们想获得什么，你们的软件究竟与我们所要求的内容之间有多大的差距，这些在调研中好像都没有看到，那么这种情况对于调研的结论就产生很大影响，在许多公司给我们提供的调研报告中都可以反映出来，简单一句话是不了解我们的企业”。某企业副总经理说。 他的观点代表了许多中高层管理者的意见，由于一些软件公司对需求调研工作的不重视，在人力资源的选配方面，总是倾向于给开发人员好的福利，而需求人员却无法获得较为合理的待遇，在这种普遍偏低的待遇下，只能吸收经验较少的人员、甚至经验没有的人员，即便这些人可能学的专业是管理或电脑类专业，但是软件公司往往忽略这样一个事实，这类人员必须招募综合性的人员，电脑要懂、软件功能作用要清楚、管理知识要会运用、沟通要有一定的技巧，组织管理能力也要具备，最好懂得如何作管理类咨询。对于这样一个人员的培养，显然要比培养一个优秀的开发人员要困难的多，目前的这种待遇下是无法吸收到满足要求的人员。而我们回过头去看看西方公司，需求人员的工资却普遍比开发人员的工资要高出很多，对于这种现状，是不是给了我们一些提示，软件的成功从“需求开始”，所以需求人员是软件的成功之本。 如果你是从事信息化工作的人员，并且你希望自己成为一名优秀的需求工作者，那么首先要检查自己是否具备与人实现良好沟通的能力，这种能力不是怯懦，不是没有争吵，而是善于根据自己的调研需求的需要、去诱导和启发企业的管理者和业务骨干，描绘他们自己所要的管理要求。同时你还是需求的传递者，你必须与需求定义的人员实现良好沟通，你也必须与软件的测试人员实现良好沟通，因为在你的下游所做的一切工作都是依赖于你的需求报告而产生。所以你必须有很好的表达能力、也必须有很好的管理知识和经验，因为这两点是成功沟通的基础，没有很好的表达你无法和软件公司的人员“默契”交流、也无法和企业的人员“默契”交流，这里使用了“默契”，是为了强调交流的成功度；而没有管理知识与经验，企业的管理者和业务骨干对于你的信服都将大大折扣。 第二你必须要熟悉你公司的软件产品，要了解它可以解决那些管理问题和流程，那些是不可以满足的，通过对于产品的了解你才能够有基础与企业管理者和业务骨干探讨在软件需求不满足时，是否可以采取变通的做法。从理论上说，任何流程都是可以被改变的，所以你尽管可以与企业人员对此展开探讨，但是千万不要固执己见，因为企业流程的改变是有危险的，这种对于流程开展的探讨，实质上更有利于企业，而不是不利于企业，让企业从另外的角度去思考改变的可能性。由于你对于软件的熟悉使你与企业的交流变得平滑，通过对于现有软件的讲解，同样可以启发企业的管理人员了解软件的同时，去描绘他们的实际需求，这就是需求人员熟悉产品所带来的好处。 第三你必须懂得管理知识，任何企业的管理流程、规则都是可以看到各种管理技术的影子，无论这个企业是优秀的企业、管理严谨的企业、松散的企业、还是民营企业，任何的管理方式的实质都是不同管理知识组合的体现，需求人员可以说是没有太多的资本去轻视这些企业的管理体系的，因为软件业的需求人员自身的大脑中并没有建立起一套完整的管理体系，在这种情况下最好的做法就是掌握必要的管理知识和管理技术，用这些知识和管理技术去与企业的管理者和业务骨干共同探讨，探讨诸如：软件所能够给企业未来管理带来的那些改变，并依据这是知识能够更好地了解企业的管理需求，在这种情况下，需求人员才能够懂得企业的某个规则和流程为何这样设计与安排(切记任何设计与安排都是现实管理的需要)，在这种情况下你才能够很好的理解企业的管理需求。 请各位不要介意，笔者对于掌握管理知识的感触是深刻的，所以我把一位朋友进入信息化领域的一个小故事分享给读者。他的信息化经历是从86年开始，参加的第一个项目是某大型商场的管理信息系统建设(MIS系统)，刚一进入项目组，组长(国家某著名研究所研究员，信息化专家)就告诉他，你的专业是计算机，你对于管理肯定不懂，所以为了尽快地进入角色，有两点你必须快速掌握，第一是商业管理理论与方法，第二是软件工程方法。对于这个要求他是认真地照办了，前后共花费了3个多月的时间认真地阅读了商业管理中所涉及的财务管理、库存管理等相关的书籍，大概有7、8本左右，他感觉这是一段思维的清洗过程，要让自己从计算机人员的思维方式转变成企业管理人员的思维方式。 经过3个月对于管理理论的通读之后，无论与业务部门的领佳节又重阳导、业务部门的骨干的交流，都会感觉到在与客户的交流中，再也不会产生任何隔阂，这是因为所有参与交流的人都在使用相同的语言在沟通，从此以后一切调研活动都变得轻松起来，这段经历为他后来对于企业管理、市场营销和战略管理的兴趣，也奠定了基础。 第四你必须掌握需求方法，需求方法可划分成三个阶段：调研、研究、总结，任何一个阶段都必须要非常清晰地了解方法与掌握方法，许多软件公司并没有建立这样的方法，所以在调研的过程中无法了解企业需求的全部，经常出现的现象是不知道调研是从哪里开头、也不知道调研从哪里结束，应当怎样了解企业状况，怎样写调研报告；如果出现这样的结果，同样会导致无法开展企业需求的研究，因为这些调研报告是不全面的、是片面的，研究的结论将是有些不真实的，自然也就无从作出一份完整的需求报告。所以软件公司的需求人员必须要掌握需求方法，如果现在没有这种方法，不妨从现在开始建立。 第五你必须懂得协调，国内许多企业的组织体系并不是完美的，它们的现有组织有时候来源于历史沿革，有时候来源于竞争，有时候来源于亲情，在这样的组织体系下的管理层一般都是有矛盾的，这种矛盾有时候会反映到需求调研过程中(由于有可能改变原有结构与责任、还有利益)，作为一名优秀的需求人员，你必须清晰这种矛盾，要梳理清楚这些矛盾，选择比较适合的方式去解决矛盾，可以通过流程的变化、可以通过控制规则的变化、可以通过你的决定(装作没有看到矛盾，表现出一切为企业着想)，总之有一点必须多听、多看、多探讨、多选择不同的解决方案，一定不要激化矛盾，矛盾的激化对于企业不利、对于软件公司同样不利。 需求人员的基本能力要求可能并不只是这六个方面，这里只是一点探讨和想法，一定不完善，希望读者能够从自身的工作角度去补充和发挥。其实写这个小节的中心目的，是希望软件公司、软件应用的企业必须关注需求的重要性，关注需求人员能力的培养和提升，因为软件使用的成功与否，需求对于企业管理的复合程度起到了至关重要的作用。