解码IT项目管理？

导语：项目是指一系列独特的、复杂的并相互关联的活动，这些活动有着一个明确的目标或目的，必须在特定的时间、预算、资源限定内，依据规范完成。以下是我分享给大家的部分关于项目管理的一些经验，欢迎大家前来查阅!也希望文章能够给解决大家的烦恼!

项目管理经验分享

企业项目管理体系建设的核心是建立企业的项目管理方法，目前,大部分组织缺乏系统的、统一的项目管理方法。在我们咨询的几家公司中，我们常常会听到这样的质疑声：一套方法怎么可以管所有的项目吗特别是IT项目，技术过程都不统一，如何用一套方法来管所有的项目，由此我们也看到很多朴素的管理方法在各个项目组织中自由成长，但在一个企业内，项目间的联系是不可避免的，相互间的协作、配合由于缺少系统的管理方法，往往顾此失彼，矛盾此起彼伏，项目经理和公司领导成为消防队员，责权不明，协调不畅, 常常陷于项目经理无法，公司管理层无奈，项目成员无所适从的状态，给项目成功实施带来了潜在的风险。是什么原因导致这样的问题呢，是否有可行的办法来解决这个问题呢

一个完善的项目管理体系建设是与企业本身的行业背景、业务领域是分不开的，出现上面的问题的根本原因就在于项目管理和业务流程的交叉，导致项目管理过程复杂化，不可控，这也就是为什么大家说一套方法不可以适用所有的项目的根本原因。

企业的项目运作包括业务流程、项目管理、技术工作三个方面，业务流程是如何运作业务，是由企业的行业特点、业务背景所决定，项目管理是如何管理项目，而技术工作则是实现项目目标所需要的技术手段。对于一个企业而言，建立企业的项目管理方法论就需要依照企业的业务流程、技术手段来设计相应的管理方法。

项目管理方法是一个结构化的方法，是可以在大部分项目中应用的方法，具体实践过程中，项目管理方法需要针对行业特点，建立适合行业特色的项目管理体系。

依照项目管理理论，项目管理过程按阶段划分为启动、计划、实施、收尾，对于任何一个项目我们都可以依此进行阶段的划分，这是项目的共性，而对于项目中的个性就是项目的业务和技术层面，对于具体的企业，项目阶段划分就需要由业务流程和技术方法决定，在实施过程中，针对具体的项目进行客户化，项目管理方法论的核心就是综合所有项目的特点，建立一套包括技术、工具、管理技巧在内的一站式服务的指南和模板。这种将项目管理方法和业务流程相互配合，并在实践中进行优化的管理方法，就是项目管理方法论。

项目管理体方法论的重要表现形式是项目管理手册，这是组织规范项目标准管理过程的重要手段，通过正确的决策、高效的流程、标准的 *** 作、可控的过程，确保项目的有效实施。

企业项目管理手册编制的基本方法可分为三个层面，一是项目管理理论知识体系，目前世界范围内比较通用的主流项目管理知识体系，包括美国项目管理协会(PMI)推出的《项目管理知识体系指南PMBOK》，英国商务部开发的项目管理方法《PRINCE2成功的`项目管理》可作为理论支撑。二是在管理方法上跨国企业实施项目的管理方法，中国著名企业的项目管理经验可作为最佳实践基础，在此基础上则是对企业本身项目管理实践经验的总结。从三个层面对企业的项目管理过程进行梳理、定义、借鉴，即可固化出企业本身的项目管理方法。

具体到项目管理手册内容就是描述项目输入转变为输出的过程。通过项目阶段过程的定义，将项目管理过程、项目实施支撑、项目监控方法及项目作业指导，系统化地与项目管理理论及产品要求融入到具体的 *** 作实践过程中。

具体包括以下主要内容：

1 项目过程控制阶段划分：通常需要考虑两类过程，一是按照项目的管理过程，对项目过程进行阶段划分;另外是按照项目的技术过程，将项目过程进行阶段划分。企业的业务流程，主要关注项目的管理阶段划分，而项目经理执行和管理项目时，必须将项目的管理阶段和项目的技术阶段划分结合起来，进行项目管理。

2 阶段输入和输出：包括数据和信息、计划和报告、风险及可以交付的成果等;

3 过程控制：包括工作流程，工作方法、 *** 作规则和作业指导;

4 角色职责：在实践中，项目管理职责，不能简单归于项目经理一个人，而是由一组角色共同完成，包括职能部门和角色对项目阶段和实施步骤的贡献。

依照项目管理方法论编制的项目管理手册，将项目实施过程中的项目管理方法与企业的业务流程、技术方法有机地集成起来，从而建立以项目管理为核心的业务流程。

不可错过的优秀项目管理者经验分享

执行计划

在完成计划编写之后，项目经理需要将计划分发给每个团队成员，然后给成员提供需要的资源，由成员开始执行计划。此过程除非项目经理还兼职技术角色，通常需要做的事情不多，假如你在此阶段非常辛苦，通常是因为计划作的不够好。在晚餐项目中，因为我还兼职小工，所以比较忙，这会儿已经开始淘米、下米、洗菜、切菜等活动。

团队建设

首先，项目经理需要懂得团队发展的阶段(形成、震荡、规范、成熟)，其次项目经理必须熟悉各种领导(指导、教练、支持、授权)、管理风格(民主、独裁、自由、官僚)，并在合适的时机采用合适的风格。此外，项目进行中，难免出现困难、挫折和打击，团队成员的士气会低落，严重影响项目绩效。此刻，项目经理需要采用各种手段激励团队，让团队充满干劲。激励的关键有几点，第一点，要想激励别人先激励自己;第二点，必须懂得人们做事的动机;第三，要根据团队成员的特定采用恰当的激励手段;第四，在恰当的时机来激励。

在晚餐项目中，因为我们就两个人，彼此非常熟悉，所以团队震荡期非常短，形成后迅速到达规范期。启动项目时我采用了自由式的风格，大家各抒己见，来讨论各种可能性;我做计划的时候采用了民主式的风格，因为我爱人属于做饭方面的专家，民主式可以广泛征求团队成员的建议;在执行中，我采用了独裁式，严格要求我们执行既定的计划;在接近工作完成，我采用了官僚式的风格，对晚餐执行中的问题、经验、进行了记录和总结。关于激励，是每时每刻必做的事情，我爱人不断赞美我洗菜的专注、切菜技术的进步;我也时刻保持谦虚谨慎，用求知的眼神向她请教、用崇拜的目光欣赏她的成果。总而言之，我们保持了优良的团队作风，大家充满激情的、充满快乐的完成项目的工作。

管理团队

再熟悉的成员，也会有摩擦，再好的团队，也会有冲突。项目经理必须了解冲突常见原因，熟悉冲突常用解决策略(问题解决、强制、撤退、妥协、调和、合作)和使用时机，能够迅速的解决团队中出现的冲突，并且注意及时、私下、合作这些基本原则。及时就是越早越好，因为冲突开始的时候大家不会情绪化;私下就是不要在正式场合，给对方面子，不让对方下不来台;合作就是本着解决问题共同进步的态度，不是要追究谁的责任、证明谁是对的、谁是错的。

在完成项目执行期间，我和我爱人发生了二个冲突，分别采用了不同的措施进行解决：第一个，在做花生黄瓜时，我想用刀切，而不是拍黄瓜。我爱人指出来必须拍，我问为什么，她解释拍出来的味道鲜美，用刀切味道会受菜刀的影响。因为她是专家我听她的，问题得到解决;第二个，在洗菜过程中，我突然想起来需要写点东西，于是擦手计划去电脑旁边，我爱人根据计划指出来，我洗菜必须按时按质量完成。我不服还想去写东西，我爱人采用了强制的手段：如果我去写东西，这饭就不做了。我采用了撤退的策略，放弃写东西的念头，乖乖继续洗菜。

验收成果

很多人会误解，以为项目成果的验收是项目收尾的事情，其实不然，在执行过程中，可以随时对完成的成果进行验收。验收包括两个步骤，一是质量是否符合要求，二是得到干系人(通常是上级)认可。在实际项目中，得到认可非常重要，因为认可后的才可以要求付款。

在晚餐项目中，我们随时进行验收，如淘米工作完成时，我对淘完的米进行检查，我爱人进行认可;洗菜完成时，我对洗完的菜进行检查，我爱人进行认可;切好菜之后，我对菜切的大小数量进行检查，我爱人进行认可;在炒菜工作完成时，我爱人自己品尝咸淡对菜质量进行检查，我进行认可;这些都属于阶段性的成果验收。

监控风险

在项目执行过程中，项目经理需要密切关注已经识别的风险是否发生发生的风险是否应对应对的效果是否达到同时还需要识别新的风险。实践中，需要定期召开风险会议来实现上述目标。具体会议召开的次数，需要看项目的阶段、项目的规模来确定。

在晚餐项目中，因为我们识别了可能的风险，并采取了应对措施，基本没有出现新的风险。在项目执行和监控中，项目经理需要做两类事情，一是管项目，对项目绩效的管理;一是管人，对团队的管理。第一类事情比较容易，只要懂得必要的技术知识、制定了完整的项目计划，按计划进行即可。最难的是第二类，如何管理项目团队 。由于我们国家的发展背景，目前大多数企业中项目管理 者都是技术出身，对技术很熟悉，对管理很陌生。面临的最大挑战就是如何由技术到管理、如何在思想、能力、行为方面做出转变。

在此过程对项目经理的要求，知识方面需要具备心理学、领导模式、管理模式、团队规律等方面知识;能力方面需要懂得沟通、激励(当团队遇到困难时)、说服(在变更发生时)、谈判(随时随地)、领导(指明方向)、管理(协调资源)、问题解决(解决冲突、控制风险)等能力。

应对变化

在项目进行中，项目的环境可能发生变化，如此前的假设不再成立，或者因为发生了风险，项目的计划可能需要调整。变化是必然的，为了应对变化，在必要的情况下我们需要变更项目计划。这需要在项目启动时，就确定变更的流程、变更审批的组织(在大型项目中通常由高层组成变更控制委员会ccb)、变更的文档。

案例分析：

软件项目管理工作经验总结

软件项目最大的特点就是不确定性。这是指软件项目不可能完全在规定的时间内，按照规定的预算，由规定的人员完成。

因为这种不确定性，导致了计划赶不上变化，也导致了平时的工作中的2种倾向：1、变化太快，索性不制定计划。2、过度强调计划，往往要将项目中非常琐碎的事情都考虑的非常清楚之后再启动项目。第一种倾向，在我做过的项目里占了2/5，都是在项目开始时制定一份计划，项目一启动就丢到一边，项目过程中完全不理会，个人能力强的PM大致还能把握方向和进度，但是问他之前做了些什么额外的工作时，往往回答不出来，等到项目结束，再把当初的计划改改，做个大概的统计也就了事。而项目过程中的一系列的常见问题也是导致项目失败的原因(以下的原因是我做过的项目中总结出来的影响最大的5点，按照影响程度的严重性，从高到低排列。)

1、项目经理的管理能力不足

项目经理的管理能力不足之所以放在第一位，我想大家都清楚原因。项目经理作为一个项目的灵魂，对于进度的把控、团队成员的组建以及积极性的调动、成本的控制、和客户的沟通、需求变更的把控、重大事情的决策。。。这些任何一个都能左右一个项目是否成功。我遇到的几个项目中都是由于项目经理的能力不够，直接导致项目失败，而且使得项目成员在项目过程中也疲惫不堪，怨声载道。其实现在很多项目的项目经理都是由技术骨干兼任,因此他们往往习惯于关注技术开发，而忽视了项目管理工作。项目，本身就是为了盈利而生，所以不排斥项目经理兼任项目技术主管或业务咨询，但是必须要有将项目管理工作区分开来的意识和责任感。如果没有这样的意识，就会造成疏忽项目计划的制定、上下左右的沟通、专业资源的分配、项目组织的调整、成本的控制、风险分析等。项目管理工作的忽视，必然导致项目失控。

2、需求不明确，变化多

需求的多变是必然的。由于用户对计算机系统认识的不足，加上一个东西的从无到有，所以往往需求开始都是模糊的，只有随着项目的发展和反复的沟通，才能逐渐的明确。如何尽早的引导客户把需求明确，是项目经理、需求分析人员的工作，是保障项目可以顺利实施下去的前提保障，它是一门技术，也是一门思维沟通艺术。需求调研清楚了不代表着万事大吉。同一个东西，不同的人有着不一样的理解。开发人员和客户之间隔着需求人员这么一层，如何把客户的意思明白、清楚、不变形的传递给开发人员，这也是大部分项目中头痛的问题。我们经常可以看到在产品开发的差不多的时候，需求、开发、测试聚在一起吵架，责任互推。

3、工作量估计过低

工作量的估计不足，会直接导致项目延期。要对每项任务，甚至整个项目给出一个合适的工作量估计，需要综合开发的技术、人员的生产效率、工作的复杂程度、历史经验等多种因素。我遇到的几个项目中，计划制订者往往是凭个人经验，个人拍脑袋给出来的，问他的凭据是什么，回答往往是个人经验，有时里面也会包含其个人对自己的自信或自尊心问题，怕给出的时间过多而显得自己能力不足。抛开这些，我们还应该注意一些平时不可见的工作量，如人员的培训时间、各个阶段的评审时间等等。制定工作量时，不能被客户给的时间期限或上级的压力所限制，否则往往是以失败结束。

4、项目团队水平不足

技术人员的水平如果不能与项目的要求相适应，对项目需求或新技术不是很熟悉，对项目的质量、成本、进度都会产生影响。当进度开始滞后，项目经理最常用的方法就是增加人手。我之前的一个项目就是如此，由于项目经理不能把握需求，需求不断的增加，于是开始不断的加班，在这种折磨中，老员工开始纷纷离开，新来的员工不熟悉，进度进展缓慢，项目经理开始大量的加人，但是对系统代码和需求的不熟悉，往往3、4个人新员工都抵不了1个老员工。于是，开始无限制的加班，在加班的折磨下，新员工又纷纷离开，于是又加人。恶性循环，项目被无限的延期。这样的项目相信大家遇到过不少。导致项目失败的因素还有很多，对于一个团队来说，一个好的管理者是一个好的开始，但并不等于项目成功。加强自身能力的提升，是每个项目管理者必须有的意识。

5、计划不充分

计划不充分，分为计划太粗或太细。制定的计划不严谨，随意性太大，会导致可 *** 作性差，在实施中根本无法遵循，也就失去了计划的作用。有的人会抛弃全局计划，采取每周制定下周的计划，这样也是不可取的，毕竟计划没有一个长远的目标或宏观上的掌控，只局限于眼前的一点点事情，往往会致使项目失控。我一般采取先制定全盘计划，再每月制定详细计划，当月快结束时，根据实际情况调整下个月的计划，这样既有了较长期的把控，也有了和项目目标的对比，同时也不会把自己陷入无止境的修改计划中。

项目开发方面

项目应以需求为核心。一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。由于eas项目的特殊性，项目开发过程中能够与客户建立有效快速的沟通渠道，是项目成功的关键。

需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书，以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点（用例）。eas项目在前期对需求不够重视，导致在需求理解上出现了一些偏差，从而影响了项目的进度。幸而得到了及时的纠正，在项目管理部的协助下，所有需求都得了客户或客户代表的签字确认。从而使得项目在客户验收时，有了充分的保证。

项目应确立专门的需求分析师。公司没有专门的需求分析师，不能不说是人员配备上的一大弊端。（软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师）从eas项目的开发过程中，我们就充分地认识到这一问题的严重性。需求的不断更改，客户迟迟未签字确认，原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时，总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术，没有经过专门训练的需求分析师，通常会给项目带来隐患。

项目应指定各个模块的需求接口人。只有这样，才能有效地保证项目组与客户的及时沟通，快速响应客户的请求与反馈。eas项目在开发早期及时地确立了需求接口人，在一定程度上规避了需求变更给项目带来的风险。但是，确立的需求接口人未经过系统培训，在需求调研以及与客户沟通的过程中，工作表现只能说是差强人意。

注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业，而项目经理以及需求分析负责人对这一过程还欠缺足够的重视，同时没有好的工具或流程来监控这一过程，使得需求调研记录没有发挥更大的作用。此外，需求跟踪也非常重要，毕竟，任何项目的需求都不是固定不变的，需求随时会发生变更，而开发人员实现的需求也可能会与客户的要求偏差。

注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解，项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期，项目及时撰写了eas项目需求功能列表，并结合交付版本与客户进行了沟通和协商，从而规避了需求偏差的风险。(需求追踪，任何原始需求来有头就有尾。原始需求->用户需求->产品需求->软件需求->设计->测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏，更多的是为了做变更影响分析使用)

控制需求变更。重视ccb的作用，同时应建立需求变更的响应机制。eas项目组对于需求变更的响应还不够及时，这一点项目经理与项目管理小组要担负一定的责任。（范围管理中范围控制的内容，变更管理是配置管理的一个重要内容。需求必须要受到控制，否则容易引起计划的频繁调整而发生混乱)

设计

重视架构设计。eas项目的成功，一定程度是源于我们有个优秀的框架开发小组，我们在项目立项之初就基本确定了整个系统的架构。其中虽然发生了一些变化，但核心架构仍然没有发生大的变化。由于，我们建立了稳定、简单的系统框架，可以极大地提高开发效率，规避了对框架的重复编码。(软件开发的第二个重要分工就是最好有专门的架构设计人员，架构设计和总体设计要由1-2个人来完成，以保证高度的概念完整性和设计统一)[1][2][3][4]

善于对设计作出取舍。项目开发的三要素是成本、质量与进度。在保证质量的前提下，为了项目进度不出现大的偏差，eas项目组并没有过分强调技术，特别是在考虑进度的情况下，牺牲了系统的部分可扩展性。虽然这为系统的后期维护带来一定隐患，但却能够有效地保证项目的进度。从eas最初的架构设计来看，我们引入了 castle与aop，试图简化orm以及横切关注点例如日志、异常、权限、事务等功能的实现。同时，希望采用wcf，利用soa思想建立松散耦合的面向服务应用程序。但随着客户需求的变化，我们果断地放弃了采用wcf的构想，同时又克服了技术困难，坚持了对castle与aop的使用，并为此成立了框架开发小组。事实证明，在技术的抉择上我们作出了正确的决定。

重视ui原型设计。系统的原型设计与需求分析相辅相成。如果有好的原型版本交付给客户，则客户更能够理解系统的实现，促进沟通的有效性与准确性。在eas项目中，我们从一开始就确立了原型设计小组，并在分析需求阶段，就开始了原型设计。这一做法无疑在客户沟通、需求确认、ui设计等方面都发挥了很大的作用。但是，我们在这一点上，由于缺乏专门的ui设计人员，因此，这一工作还存在很大的缺陷，甚至于ui的设计为迭代版本的交付带来了很大的障碍。在项目后期，关于ui的bug是最多。因此，我们认为在开发类似的web应用程序时，应尽早确立ui设计规范，以约束所有的ui设计。同时，必须培养专门的ui设计师，在开始原型设计时，就尽快完成ui交互的设计。并且，必须成立专门的ui 设计小组，在需求阶段与需求分析师合作，在编码阶段与开发人员合作。(原型设计是加强前期用户需求挖掘和减少后期需求变更的重要手段，不一定需要专门的ui设计人员，原型设计可以由需求分析师来完成)

测试

测试成员应了解需求。如果不了解需求，测试人员无法编写正确的测试用例，同时在测试过程中，也可能因为错误地理解需求，从而导致报告错误的bug，影响开发人员效率。加强开发人员与测试人员的合作。开发人员必须及时响应测试人员提交的bug。而测试人员也应跟踪开发人员对bug的修复情况。(测试人员应该要意识到自己和需求分析人员的区别，测试人员不用想需求分析人员一样分析和开发业务，但是他们必须和需求分析人员一样对已经分析出来的需求和业务高度熟悉)

测试之初必须确定测试原则，对bug的严重程度进行分级。同时，必须确定修复bug的优先级别。

进度管理

保证项目进度不出现大的偏差的前提是制定一个好的项目计划。必须根据项目规模，成员情况，技术难度等多方面考虑整个项目计划。如果项目的deadline已经确定，则必须采用一些方法来保障项目计划的完成。首先是选择符合项目的软件开发生命周期。通常情况下，并不建议采用瀑布开发方式。最佳的办法，应该是 rup或者敏捷开发，然后结合原型法制订项目计划。这样可以规避因为需求变更产生的风险。

其次，要每日跟踪项目的进展情况。可以通过晨会、周会以及项目日报、项目周报了解项目进展情况。同时，需要为各个小组指定进度跟踪人，根据各个小组长的日报，判断实际的进度是否与计划出现偏差。

要制定项目进度偏差的应对方法。一旦项目进度出现了偏差，必须采取相应错误解决问题。或者通过加班、增加人手、申请项目进度等方法及时作出响应。

及时向项目成员汇报项目进度情况。只有让各个项目成员了解到项目现状，才能够给每个成员增加压力，不至于松懈。同时，也能够使得每个成员能有一个目标，而不至于茫然失措。

制定项目计划时，必须考虑阶段评审与同行评审的时间。这一点在eas项目中做得不够好。其中原因也是由于项目进度本身较紧的缘故。注意维护项目进度跟踪表与项目进度偏差跟踪表。让项目管理部以及qa及时掌握项目进度，有利于对项目进度的管理。

变更管理

变更包括需求变更、人员变更。如果不控制好，两者对项目的进展都会带来灾难性的后果。需求变更在前面已经叙述，而eas项目中发现人员变更的情况也非常严重，因此这里重点介绍关于人员变更的管理。

如果发生人员进入的情况，那么对项目带来的通常都会是好的影响。但我们也必须注意如何让新成员更快地融入团队。整体上讲，如果需要新成员加入，发生变更的最佳时机是项目前期。如果在项目中后期加入新成员，无疑则意味着项目出现了灾难性的后果。而新增加的成员，由于不熟悉项目，所能带来好的影响也是有限的。如果不处理好新成员与老成员之间的合作关系，反而会带来负面影响。

人员的退出很多时候是不可控的，同时对项目带来的影响也是不可估计的。为了将这些影响降到最低，就必须在项目开始之初就要确立编码规范。同时，还应该重视对文档的维护与更新。而在人员退出时，必须做好交接工作。同时，还应对这种变更进行合理的评估，并及时报告项目管理部，并与客户及时沟通。如果对项目进度有严重影响，应争取最大的努力取得客户的理解，提出项目延期的申请。

风险管理

要在项目开始之初就考虑到项目过程中可能出现的所有风险，是不现实的。但是，我们必须考虑对风险的管理，尤其是在制订项目计划以及创建团队的时候，考虑这一因素。风险有很多，包括需求的风险、进度的风险、质量的风险以及技术风险等。必须制定一套完整的风险管理计划，而一旦发生了风险，则必须及时响应，组织相关人员解决风险。不能忽略任何一个小的风险，否则一个小的风险到最后会造成大的灾难。风险的把握必须要有项目经理与系统架构师把关。

成员管理

不团结的项目组是无法保证项目的成功地。项目经理与项目组长在管理团队成员时，必须时刻注意成员状况，即使处理工作出现的矛盾与摩擦，随时保证团队合作精神得到最大程度的执行。

持续地保证项目成员的士气非常重要。项目每取得一个阶段性的进展，必须告知全体成员，如此才能收获成功的信心。项目开发过程需要注意劳逸结合。一味地强制性加班，只能降低项目成员的工作效率。项目过程中，如能适当地开展一些活动，无疑能够让团队成员感受到项目组的集体气氛。在阶段实现的重要时刻，项目经理必须注意通过文字、语言等激励项目组成员。而项目经理的自信也是保证成员士气的一个关键。

必须注意了解团队成员的心理状态与工作状态。项目成员的战斗力除了是个人的能力发挥之外，一个好的领导也是至关重要的。因此，必须选择合适的项目组长，通过他们掌握整个项目团队成员的工作进展。同时，还要了解每个成员的能力，以安排合适的角色与岗位。

重视开发组与测试组以及项目管理小组的合作。项目组是一个整体，每个成员的角色不同，但大家都是团队的重要一员。

作者:张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（mvp），著作/译作包括《软件设计精要与模式》、《wcf服务编程》。张逸熟悉c#，asp，wcf等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 soa企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。

首先这是一个失败的项目，因为没有获得对应的商业利益。那症结就应该是基于商业利益的。

第一个问题：症结应该是在项目启动时的商业文件内容，公司是有很好的技术优势，但能否通过技术手段得到很好的商业效果是需要做前期调研与数据分析的。没有做好商业分析的话，技术好也没有用。责任人是发起人与项目经理。

第二个问题：症结已经找出来了，总结经验教训就是

1 要在启动阶段就做好商业分析并在项目过程中不断地反复查验商业分析的条件是否仍然存在。

2 不要盲目的相信技术优势，一个项目的成功需要很多个维度的思考与执行都到位。

以上就是关于项目管理经验的分享全部的内容，包括:项目管理经验的分享、互联网IT项目的管理心得体会、解码IT项目管理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！