1、项目管理实行方案作为一个项目管理者，如何要成功的做好项目管理；第一一定先要理解的是在特定的领域中给予这个角色所要实现的目标、肩负的职责、以及项目管理者的详细工作内容是什么？从我个人的愚见和角度以及我们所从事的IT领域来解析回答以上三个问题。第一：目标作为一个项目的管理者，一定要明确的知道自己的工作目标；我个人以为项目管理者的目标不过就是以下两点：1、就是清楚明确地认识项目利害关系者的需乞降希望，努力做到满足项目利害关系者的不一样需求；项目利害关系者包含：项目团队成员和项目团队外成员(比方各部门的部门负责人和市场人员，客户等)。2、就是保证开发项目按需准时保质的达成。第二：职责作为项目的管理者，2、第一要正直态度，要明确知道自己的工作职责，认识到这份工作职责的实质。项目管理者不是来管人的，而是来支持人的，是来协调资源的，是来创建一个适合团队成员比较认可的工作环境随和氛的，是来为一个共同的目标和大家一起战斗共同成长的。可以大概概括成以下几点：1、成立有效的工作流程保证项目的顺利进行。2、拟定详细周密的项目计划。3、追踪，推进项目按计划进行。4、踊跃解决项目过程中出现的问题和矛盾。5、调动开发团队的踊跃性，创建力，推进团队成员在项目过程中不断成长。6、项目风险鉴别、风险评估、风险解决微风险管理策略以及做好突发风险的应急方案。7、实现目标第三：项目管理者的详细工作内容最后一个是项目管理者的详细3、工作内容，作为项目管理者一定清楚的知道自己的工作范围和所要做的工作内容以及工作重心，分为以下六点：1、项目先期阶段对项目进行技术可行性解析、技术评估、成本评估以及风险评估。与需求提出方的代表进行需求谈论，明确项目的目标、价值；确立项目范围、功能及优先级。组建项目团队，特别要搞清楚项目的keyperson(对产品有决定权的人)。项目启动会议，相关的利害关系人员都一定参加。该阶段达成后的成就：确认后的最后软件需求规格说明书文档。2、解析设计阶段依据确认后的软件需求规格说明书，拟定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包含人员和软硬件资源)；数据库4、设计；系统设计；文档(包含UseCase、Demo系统原型、TestCase等)；评审会议。该阶段达成后的成就：A、UserCase(系统用例)；B、DEMO(系统原型)；C、系统设计文档(大纲设计和详细设计)；D、数据库设计文档。最后对达成的成就，包含UserCase和设计文档等进行评审。3、履行阶段(开发和测试)准备开发环境、测试环境；追踪，推进项目按计划进行；以周报的形式通知项目的进展状况。对项目的阶段成就进行评估，以保证该阶段达成的质量，包含代码审查、SQL审查等。对需求更改进行控制管理；对项目风险进行管理；测试阶段BUGFIXED及改进、采集反响建议。4、公布阶段包含拟定项目公布计划5、，用户培训，公布上线。5、上线后监控数据监控(日记、服务器状态)，依据监控出现的问题，及时进行BUGFIXED及改进或做补丁升级。6、结束阶段产品交付，项目总结会。第四：基于以上三个问题所做的对付细则要做好项目管理，并能的确解决好以上三个问题，实现目标、履行职责、达成工作中的详细内容，从我个人这几年的工作经验和面临的一些问题，还有所累积的一些项目管理中的一些知识以及自己的观察和思虑的角度看，应该要努力做好以下这几个方面的详细工作：1、项目开发时间的估量拟定项目进度时间表的时候，需要估量每个任务所需的时间，此中开发任务中模块的分配和时间估量是此中最主要的部分；在分配模块和估量开发时间时需要依照的6、原则和目标：1、保证项目整体的进度。2、有助于保证开发编码的质量。3、有助于提升开发编码的速度。在公司现有的技术框架下，开发人员主要的工作是投入在详细的商业逻辑上。平常每个模块所需的开发时间取决于以下三个要素：1、所负责模块的商业逻辑的复杂程度。2、开发人员的技术水平易对项目所在应用的熟习程度(包含对框架和应用的熟习程度)。3、该模块技术实现上能否有技术难点；这里所谓的技术难点定义是：在现有系统中还未实现的、开发人员自己也未没接触过的技术。对于这样的难点，开发者没有相关的代码可以参照，自己也没有经验，因此需要投入一些时间研究解决。模块分配和开发时间估量的步骤：1、在划分好模块后，第一自己先估量7、一下每个模块所需要的开发时间。2、而后招集全部开发人员，谈论模块的分配和开发时间估量。将划分好的模块，让开发人员从中优选他们感兴趣的模块。这样做可以提高开发人员的主动性和参加性。在分配模块的时候还需从以下几方面考虑，以保证开发的速度和质量：A、相同近似的模块由同一人负责开发，比方用户管理的增修改由同一开发者负责。这样做的好处就是开发者对相关逻辑会更加熟习，同时接口的定义也会比较明确，沟通的成本比较低，同时功能实现的缺点也相应的会降低。B、技术难度比较大的模块由技术水平比较高的人负责。C、业务逻辑比较复杂的由对这块逻辑比较认识的人负责。3、模块分配完后，开发人员评估自己负责开发的模块所需要的时间8、。在此过程中最好做到要和开发者比较详细的谈论每个模块的技术实现，以便使时间的估量更加正确。4、对开发人员估量的时间进行确认。在确认过程中作为项目管理者应参照以上提到的三个要素，同时将自己估量的时间和开发人员估量的时间进行比较。这此中的差异自然会存在的。对于那些差异比较大的，将与技术人员商讨此中的缘故。对于时间周期比较长的任务，尽量将任务经过再细分的手段细化任务，争取每个任务的最长时间不超过3天；时间周期越长的任务，不确立性越高，风险也越高，越有可能成为项目的瓶颈，影响项目的进度。2、CodeReviewCodeReview是保证项目中代码质量特别重要的一个环节，在这一环中我们公司做的特别欠缺，9、把关不严格；这是以致每次测试后出现大批bug的主要原由，这一环需要归入绩效核查中，实行责任追究制，实行重点监控。出现这样的单薄环节，造成这样的原由，我想也是有很多要素造成的；比方开发人员对需求不是很明确，以自己比较主观的要素去达成任务的；还有对整个系统业务逻辑没有正确的清楚的认识的原由，以及对项目构成员培训不到位的原由等众多要素集结在一起才产生的。如何做好这方面的工作？第一编码要有“编码规范”文档，CodeReview要有“代码审查规范”文档：记录代码实现应该依照的标准。经过这两个文档来规范开发人员的代码实现，代码编写者一定要严格依照规范来进行；代码审查者依据这些标准来CodeReview代码10、，同时在CodeReview过程中不停完美该文档。在做好这些先期工作的前提下，分以下几个步骤来实行：1、检查开发者的代码实现能否依照了编码规范。2、从代码的易保护性、可扩展性角度观察代码的质量，提出更正建议。3、代码编写者和代码审查者坐在一起，由代码编写者依照UseCase挨次讲解自己负责的代码和相关逻辑，从Web层-到Manage层再到Dao层；4、代码审查者在此过程中可以随时提出自己的疑问，同时踊跃发现隐蔽的bug；对这些bug记录在案。5、代码讲解达成后，代码审查者给自己安排几个小时再对代码审查一遍。代码需要一行一行静下心来看。同时代码又要全面的看，以保证代码整体上设计优秀。6、代码审查11、者依据审查的结果编写“代码审查报告”，“审查报告”中记录发现的问题及更正建议，而后把“审查报告”发送给相关人员。7、代码编写者依据“代码审查报告”给出的更正建议，更正好代码，有不清楚的地方可踊跃向代码审查者提出。8、代码编写者bugfixed达成以后给出反响。9、代码审查者把CodeReview中发现的有价值的问题更新到代码审查规范的文档中，对于特别值得提示的问题可群发email给全部技术人员。假如经过以上步骤，还因为是代码编写者的原由此出现严重的缺点问题，将通过绩效核查来加深代码编写者的印象，并在周报会议上做通知责备。3、需求更改管理需求更改管理也是项目管理中最重要的一个环节，对需求更改管理12、的有效性将直接影响项目的成功与否。对待需求更改的态度：1、需求更改是不行防备的。2、需求更改要一定被管理。3、踊跃发现引起更改的要素，促使更改尽可能早的出现，减低更改带来的风险。需求更改管理的目标：1、相关的相关人一定清楚地认识发生的更改。2、更改处于有效的管理中。3、尽量降低更改带来的风险。经过拟定需求更改的流程，保证项目中的需求更改有效地进行，实现上述的目标。需求更改流程：1、确立需求的基准线。将以UserCase作为需求基准线，在UserCase确认以后的任何需求改变，都需要走需求更改流程，这一环节我们基本没有，时期有时使的工作很凌乱，也就是因为没有一个规范的更改流程而造成的；假如成立了13、这么一个流程规范和体系，需求更改没有走这个流程的将不被认可。2、项目管理者接收到需求更改的要求。需求更改的提出者可以是项目中的任何人包含产品经理、市场人员、开发人员、测试人员等。3、项目管理者评估该需求更改。针对接收到的需求更改的要求，召集相关人员谈论该需求更改的合理性、可行性，实行的代价以及对项目的影响。包含可能影响的项目范围，进度，花费，质量等计划。项目管理者作为项目的负责人，对项目的成功与否负有主要的责任。所以需求更改的决策者应该由项目管理者肩负。4、需求更改确认后由专人将需求更改记录下来，通知给项目中全部成员。此中以下人员对需求的更改是密切相关的，他们一定认识并认可此需求更改。包含（客14、户方，需求解析人员，测试人员，相关开发人员）。需求更改记录格式以下：更改提更改种类(是更改描出时对原有需求原更改提开发对进度的影响序号述(工作量)间的更正还是因出者人员新增需求)125、确立更改的负责人。肩负需求更改的详细工作，比方基线控制，对需求更改的记录，并通知相关人员。6、相关人员接收到确认的需求更改后，做以下事情。需求解析人员更正需求说明书和UserCase的相关内容。测试人员更正测试用例的相关内容。开发人员更正代码中的相关部分。7、依照更改后的计划实行项目，并进行检查，追踪，对更改后的实施反响和可能出现的问题及时沟通和办理。8、需求冻结。项目越到后期，需求更改对项目的影响就越大，因此15、在一准时候要进入需求冻结阶段，不再接收新需求或需求的更改。4、风险管理风险管理是项目管理者最重要的工作之一。风险管理是一个连续的过程，贯穿于整个项目过程中，风险管理包含风险鉴别、风险评估、风险解决以及风险管理策略。在项目的实行过程中需要不停地鉴别和对付风险，并加以有效的控制，风险管理的好与坏直接影响项目的实行成效，从某种意义上讲，项目实行对于项目管理者就是鉴别、解析、对付、控制风险的过程，使项目的拘束性目标和质量目标朝有益的方向发展。项目不一样于平常任务，它有明确的起止时间和目标，要在明确的范围、时间和成本拘束下，达到相应的质量标准，并获得用户的满意。影响项目成败的要素涉及方方面面，而且风险陪16、伴着项目的一直，是客观存在的，作为一个项目管理者，应该具备优秀的风险控制意识，擅长鉴别风险并解析风险的影响，从中发现影响目标的风险点，并施加影响或采纳对付措施，把风险的负面影响降到最低，而且风险控制应该贯穿项目一直。风险引起的负面结果会合表此刻进度延后、成本超支、质量不达标等方面，以致这些问题的要素主要包含目标以及需求不明确、范围延伸以及需求更改、代码质量或返工风险、人员技术和资源的不足、缺少优秀的团队协作等。下边将详细描述一下这些问题以及出现这些问题时的对付方案：1、目标以及需求不明确为了市场竞争或内部管理决策的需要，业务部门提出的需求常常要求的时间比较紧急，需求的提出大多逗留在几张纸或口头17、的传达上，没有形成正式的业务需求文档，在没有明确的需求范围的状况下，有时为了逢迎业务部门的口味赶忙动工，过程顶用户不停地提出新的想法，技术人员开始疲于奔命和对付，很难保证项目的进度和质量，也难以获得业务部门的认可。因此，在项目的先期必定要采纳相应的手段或措施，与业务部门共同明确项目目标、需求范围，充分考虑现有的时间和资源拘束，将需求排定优先级，对于重点的需求优先实现，其余辅助性的依据过程中的详细状况进行转动式计划，并获得业务部门的书面确认。在此过程中要侧重发掘用户的隐性需求，可以经过指引、系统原型等手段让用户在先期充分裸露自己的想法和需求。2、范围延伸以及需求更改在有了明确的目标和需求范围的状18、况下，需求的更改还是不行防备的，业务部门在看到详细系统的真实雏形以后，纷至沓来地要求、新想法随之产生，假如不对此加以控制，新的需求的加入平常会影响已实现的需求，而且对项目进度和成本产生很大的影响。项目管理者针对这类状况必定要采纳严格的更改控制流程，不可以碍于面子，不然最后的结果常常是用心不讨好。针对用户提出的新需求，依照正式流程提出更改申请，组织相关团队成员进行解析及评估，作为能否实行的依照，更改控制负责人依据解析结果判断能否同意，假如同意，那项目组可以安排实行，不然，正式拒绝用户的央求，自然实质状况下可以采纳一些软措施缓解矛盾。需求更改风险：需求已经打上了基线，但此后依旧有更改发生，对项目造19、成影响。如何减少此类风险的发生？先期的需求谈论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。找出项目中需求的决策者(平常会是产品经理、相关职能主管、客户)，全部的需求要经过他们的认可。客户在项目过程中的全程参加有助于降低此类风险。需求谈论、需求确认、UserCase确认、测试阶段的客户查收等环节，都要要求客户参加。在发生需求更改时，严格依照需求更改流程履行。在解析设计阶段的中的确认和评审也是降低此类风险的重要手段。3、代码质量或返工风险质量风险主要指开发代码的质量。如何提升开发人员开发的质量？在拟定项目计划时，对开发时间的评估要尽可能的适合。合理的开发时间对开发质量的影响也很大。有20、时开发人员为了赶进度在比较紧张的时间需要达成指定的任务，可能就存在很大的开发质量问题。开发要有一套严格可行的代码规范，编码时严格遵守，到此刻为止，我们这个方面做的不是很规范，做的也很不足，大家编写的代码随意性比较大，代码编写者的主观意识性比较强。要成立一套大家认可而且规范可行的编码规范和核查规范，codereview时严格核查。在编码前，开发人员要对框架熟练掌握；一份好的系统设计文档对指导开发特别重要。返工是项目组最不肯意看到的，既浪费人力、物力和财力，又影响团队踊跃性。需求不明确或范围没有有效控制都可能造成返工，别的造成返工的原由是质量没有达到用户要求。常常有这样一种状况，每个团队成员依照项21、目计划报告进度都是100%达成，但一到最后系统交互测试或集成的时候就会发现一大堆问题，不得不花销很大精力回头排查、更正程序，造成这类状况的主要原由是过程中质量保证没有做到位，把大多数问题留在了后边。这就需要在项目实行过程中采纳有效的措施来闪避返工的风险，平常的做法有同行评审，比方大纲设计达成以后，邀请其余项目组的技术专家进行技术评审以发现架构设计问题；管理评审，经过组织级的质量审计看产品以及实行过程能否满足质量要求；代码走查，在编码过程中加入最少一次的代码走查，排查不吻合规范或性能要求的代码，走查平常可以发现50%-70%的错误；每日成立，这是一种特别有效的方法，可以防备把各部分的集成问题拖到22、最后，而且可以及时发现相应的错误，日成立一般在项目的中后期开始，每日自动从版本服务器上获得源代码进行自动编译和测试。4、人员技术和资源的不足项目实行过程中因为人员技术欠缺造成的进度延后和软件质量问题其实许多见，一个熟练的技术人员达成相同一个任务需要3天，但一个新手可能就需要7-10天。项目管理者应该在先期就解析清楚项目所要采纳的技术以及相应的人员技术要求，针对不一样的角色，及时采纳相应的技术培训，以保证项目的顺利实行。假如对于项目中某些部分专业性特别强或新技术，短期内又不可以快速成立技术的状况，可以考虑将该块任务外包，借鉴合作商的力量降低实行风险，自然要进行外购人力成本与自建人力成本的效益解析23、。开发过程中遇到技术难题，以致开发时间延缓也许需求不得不发生更改。如何减少此类风险的发生？在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻下。假如在可预期的时间内没法解决，假如可以，将向需求提出方要求更改需求或找寻可代替方案。这样的风险应该在项目的先期阶段就应该解决在萌芽状态来防备这样的风险在后期或中期出现。项目所需人力资源没法准时到位，以致资源风险。如何减少此类风险的发生？这个就需要在项目计划拟定的时候提前申请确认资源，并在项目过程中不停沟通协调。5、缺少优秀的团队协作软件项目实行属于知识型，要发挥团队成员的创建力，不一样于制造业计件生产，各模块最后要集成在一起形成一个有机的整体24、，这就需要各小组之间的亲近配合，界定清楚工作界面及接口关系，并在实行过程中连续地沟通沟通和共享，第一团队要融为一体，产出的软件才能融为一体。这是一个团队的软实力，团队之间的协作利害也将是个潜伏的风险问题，在项目启动和团队组建的时候就应该加以闪避这样的风险出现。项目风险管理的重点：1、上述我们所说的风险管理都是指可以预期将要发生的风险，那些不行预期将要发生的风险不属于风险管理的范围。这也将是考验一个项目管理者的经验和知识对能否管理好风险至关重要的内容。2、对不行预期的风险，项目管理者要有潜伏的风险意识评估，做好一些可操作性的方案准备。3、详细明确的项目计划、以及项目履行过程中每个重点的质量保证是25、降低项目风险的必需条件。4、风险报告是项目团队以及领导认识项目风险的一个有效手段。风险报告的格式：序号风险简介对项目的影响解决方案或对策5、团队管理团队就是一组个体为实现共同的目标而互相依赖、一起工作的共同体。团队工作顾名思义就是团队成员为实现这个共同的目标而付出的共同努力，项目团队的工作能否有效直接关系到项目的成败。团队管理是个渐进的过程。世界上只有完满的团队，没有完满的个人。好的高效的团队不是管理出来的，而是创建出来的。团队成员需要有大家可认可的团队文化，这需要大家共同的努力。1、创建优秀的工作环境随和氛。2、建设优秀或鲜亮的团队文化。3、保持高效的沟通。6、项目会议组织会议是项目管理者平26、常工作中一项特别重要的工作任务，项目过程中很多重要的决定都是在会议中做出的，也有很多因为不行功的会议而对项目自己造成了不好的影响。第一看看不行功的会议常常表现为哪些形式：1、会议氛围不好，参加者发言不踊跃；2、会议谈论常常偏离主题；3、会议没有获得预期的结果；4、会议时间常常一拖再拖。这些不行功的会议最后的结果就是：既浪费了大家的难得时间又没有达到会议的目的，很多人都对这样的会议都有抗争情绪，对此也是痛心疾首。以下是组织会议时应该注意的问题，也可看作组织会议的最正的确践。在列出最正的确践以前有三点我们一定要清楚：1、会议能否会获得成功很大程度上取决于会议的组织者。只有组织得有力，会议才有可能获27、得成功，这是会议成功的充分条件。2、会议的组织者和参加者的想法平常是不一致的，有时甚至会大相径庭。因此不要希望会议的参加者和你相同，对会议有着这样的期待，对大多数参加者而言，在会议中他不过一个发布想法的人，他不用对会议的成功肩负责任。3、以下十一条最正的确践是形式上的商定，详细的实行可以依据实质状况来做。组织会议的十一条最正的确践：1、只有需要开会时才开会。有时两三个人单独小范围沟通会更加有效。2、提前发出会议议程，以便会议参加者知道他们来做什么。3、请对人很重要，不要把非必需的人召来开会，自然也不要遗漏那些重点人物。在保证必需人物都在的状况下一次会议参加者越少成效越好。4、提前预定参加者的时28、间，以保证他们能准时列席。5、会议的开场很重要。会议组织者要在开始前做好几件事情。平常我建议有几点要在开场时说：A、再一次重申会议的目标，我们来做什么。B、重申会议的主题与基调。比方：本次会议是一个需求确认会，而非需求谈论会，主若是谈论做还是不做以及见告大家我们要做什么，而不要把太多的精力放在谈论如何做上边。C、说明一下会议的规则。如要发言，请举手；不要有小圈子谈论；不要打断他人的讲话，等他人说完你再说等等。6、会议过程中时辰注意指引和控制会议，以保证会议依照目标进行。一次会议的氛围能否优秀，谈论能否充分，好的指引至关重要。比方多提一些开放式的问题。7、会议记录很重要，把一些结论和有价值的内容29、记录下来，这些是本次会议的重要成就之一。8、会议要有结论。我们常在会议上听到有人说：大家谈论了这么半天，结论呢？。没有结论的会议是没有意义的。9、会议后别忘发会议纪要，以及一些Action，什么人什么时候做什么。10、会议后的action履行状况的反响很重要。反响是对会议参加者的尊敬，同时也见告了会议的成效。不然会让大家感觉到这是一个可无可无的会议，大家此后参加的踊跃性也会降低。很多会议常常都不注意这一点。11、准时结束的会议会遇到全部人的欢迎。7、版本控制版本控制也是项目管理者的一个重要工作内容之一，一个项目或产品的达成不行能是一步到位的，在项目达成的后期可能会有多个不一样的版本的公布（开发版本，测试版本，公布版本等）。需要做好版本的管理和控制。8、项目总结在项目达成后，总结整个达成项目的过程和经历，为下一次的项目启动供给参照经验，完美不足，防备在近似的项目中出现可能存在的相同的错误发生。您好，欢迎您阅读我的文章，本WORD文档可编写更正，也可以直接打印。阅读过后，希望您提出保贵的建议或建议。阅读和学习是一种特别好的习惯，坚持下去，让我们共同进步。