《互联网项目管理要点(干货)》由会员分享，可在线阅读，更多相关《互联网项目管理要点(干货)（9页珍藏版）》请在金锄头文库上搜索。
1、互联网项目管理要点互联网项目，会定一个安排发布日期，然而这个项目有个隐藏的实际合理发布日期。因为软件开发并不是一个干脆添加资源就可以加快速度的过程，所以这个实际合理发布日期是在现实资源合理利用前提下一个客观存在的最可能早的完成时间。项目进展的过程，其实也是发觉这个隐藏的合理发布日期的过程。从管理的角度来讲，当然是尽可能的赶上安排的发布时间，或者尽可能快的完成项目。但是因为多方面因素的影响，项目管理是一个欲速则不达的过程。假如这个安排发布日期早于这个实际合理发布日期，那你越往这个不合理的日期赶，工期内积累的问题就越多导致后期收尾的时候爆发，结果反而可能连合理发布日期都赶不上。借用让子弹飞里面的一
2、句话，步伐迈得太大了，简洁扯着蛋。给项目组定一个个合理的看得见的小目标，步步为营，一步一步朝着看得见的并且合理的每一个小目标前行，每一个小目标的积累，才能最终走向项目的胜利。所以务实的项目经理应当相识到如下几点：1. 项目组可以以快节奏的步伐在前行，但是项目经理本身确定要清晰的相识到，我们明面上是在赶那个安排发布日期，但是项目组实际的目标应当是那个客观存在的合理发布时间。2. 随着项目的进行，那个客观存在的合理发布时间会渐渐明朗。它与安排发布时间的差异也渐渐显示出来。此时有些项目经理往往会通过加资源的方法来尝试缩短这个合理发布时间。但是真实的状况是，除非你前期的资源配置不合理，不然在这种状况下
3、加资源，对项目帮助不大。这个地方无须多说，有疑问的人，去看一下人月神话就知道了。3. 项目经理必需有一些坚持。领导或者业务部门常常会有一些压力下来，要求赶那个安排发布时间，同时要求你想尽任何方法去赶上这个安排发布时间。而现实状况下，假如你能够调整一些需求的范围，你还是有戏。不然，你要嘛此时报喜，后期报忧，要嘛此时报忧，后期不忧。掩盖问题往往可以让人快乐，但是不代表问题不存在。4. 项目经理能做好的其实就5点：a. 限制好了需求；b. 及早的发觉问题，报告出来并解决；c. 不出现资源空闲的状态；d. 利用好每个资源去做擅长的事，快速有效的推动各种任务；e. 不奢侈资源去做一些对项目目标总体没有帮
4、助的工作，或者一些后期会推翻的需求。基于这样的相识下，本文有如下几个要点：#项目责任感项目经理应当有这个的责任感，你要为这个项目的任何一件事情负责，因为这个事情会影响到整个项目的工期，而你为整个工期负责。一个例子，我发觉现在的项目有一个紧急的问题须要项目组外的人帮忙解决。于是我把邮件发出去，通知Wendy抓紧处理这件事情。几天过去了，Wendy还没有处理。我想，我已经把问题说出去了，接下去就是Wendy的事情。那个问题还是没有解决，我的整个工期受影响了。事后追究起来，我说，我已经发出邮件了，是Wendy没有刚好处理。Wendy说，我事情那么多，我怎么知道这件事情这么急。项目工期受影响了，谁的责
5、任？Wendy吗？不，是我自己。作为一个对整个项目负责的项目经理，没有人会比你更在意项目的进展。让一个不负详细负责的人去帮你推动你的项目，远远不如你自己专心推动来得有效。#项目经理是打杂的项目组里面的每个专业成员，他们都有擅长的领域，做他们擅长的事情是他们的欢乐。而不属于他们擅长的事情，对他们来说就算是杂事一般。项目经理确定要有一个这样的意识：项目经理就是打杂的，帮助项目组成员把杂事处理掉，让他们可以专心的做他们擅长的事情，这样对项目组来说才是高效的。一个简洁的例子，测试人员Tracy在测试某个功能的时候，突然发觉她须要一个账号，同时开通这个账号的某些特定的权限，同时她须要一些服务器的信息，比
6、如主机名，某些功能文件夹存放的路径。但是她不清晰这个账号和权限要找谁开通，这些服务器的信息谁有。Tracy是个喜爱做测试的人，但是她不喜爱跟项目组外的人沟通，特殊是还要到其他部门去找人问人。这些对她来说就是杂事，而且她对其他部门的人也不熟，一个一个问明显效率不高。你可以自己去帮她找到须要的信息，也可以找一个对这方面比较熟的人去解决，但是你确定不能让她自己去做。“为什么我的手下不能解决这么简洁的问题？假如连这种事情都要我来帮忙的话，那我这个项目经理做来干什么？她当项目经理得了。“这种想法千万是不行取的。你当这个项目经理的目的并不是管人，指使这人做什么那人做什么。你的目标只是把项目快速推动完成。#
7、限制需求在全部因素当中，需求对项目的影响力，至少占50%以上。能够限制好需求，项目就胜利了一半。限制需求，有如下几点：1. 必需有人能够当好产品经理这个角色一个项目组当中，其实人人都可以影响需求。但是管理需求的，是产品经理这个岗位。假如你的项目组当中已经有一个很好的产品经理，恭喜你，项目经理可以轻松许多。但是世间事不会如此幸运，因为现实生活中，并不是全部的产品经理都这么棒。作为一个对项目完成负责的项目经理，当你们组没有一个好的产品经理的时候，你必需意识到，你至少要扮演好一半的产品经理，除非你本身对项目的完成也没什么责任感。2. 管理需求的人要平衡工期和功能友好程度需求其实有两个极端，一个是尽善
8、尽美，尽可能的让功能更友好，用户体验更佳；一个是尽早交付，一切改善性的需求都可以牺牲。只满足前者，项目工期可能会不断的拖延，因为许多功能的工作量其实是在细微环节的优化，而不是主要流程的完成。只满足后者，很可能会出现一个让用户很不满足的产品。一个有阅历或者产品意识很好的产品经理，可以很好的平衡好这两点。假如产品经理不能平衡好，那只好依靠项目经理来平衡。这点，假如产品经理或项目经理不是天才的话，只能通过阅历来学习。比如我们在做一个注册的页面，里面有个城市的输入框。城市的输入框可以做得很友好。假如要项目尽早完成，那么这个输入框我们只要让用户自己输入就行。一个比较好的设计就是两个下拉环框，一个选择省份
9、，然后再选择城市。但是一个更好的设计是让用户既可以选择，也可以自由的在这个输入框里面输入拼音首字母，汉字，然后系统就会自己显示相匹配的城市让用户选择。后两者的改进确定会花时间，但是假如这两种改进都不做，让用户只是自由输入的话，后期维护的时候就会出现用户输入不标准的城市数据，假如我们须要用户的城市数据做一些其他功能，就会有错误数据的风险。3. 懂得对不重要的需求说不假如你不能平衡好工期跟功能改进的话，有一点你确定要意识好，就是你确定要懂得对不重要的需求说不。这很简洁，你对一个需求说不，只要这个需求不是一个会造成其他功能依靠的核心需求，就算这个需求后面发觉必需实现，你可以补上，总体工作量并没有增加
10、。但是假如你花资源去完成了这个需求，后面却发觉这个需求是不重要的或者可以简化的，那你已经奢侈了一些工作量。两者的代价相比，明显前者的代价比较小。4. 理好需求优先级需求的优先级应当满足如下几点：a. 确定不变的需求应当先完成，假如项目组去完成了一些功能，结果后面发觉需求要改，那前期的一些工作量已经奢侈了。b. 被其他需求依靠的需求应当先完成，只有这样，才能不拦住依靠它的需求的开发。比如登录功能，许多登录后的页面都须要当前登录的用户信息。c. 主流程，或者核心需求应当先完成，改善性的需求应当后完成。比如信息列表页面，许多功能须要用户在信息列表里面选择要操作的记录。因此信息列表是核心需求。而在信息
11、列表页里面一个列显示格式的美化，这属于改善性需求。#风险管控风险管控是项目经理一个特别重要的技能。一个好的项目经理应当尽量在早期把全部的风险都列出来，一个一个解决。一个流畅的项目，从前期到后期风险点应当是倒三角形的，就是前期风险许多，后期风险越来越少。而项目管理不畅的，则是一个正三角形，上面风险少，到后期风险就多了。项目经理应当尽可能的找出全部的风险点。假设有一个点，你不确定他是不是有风险的，那即使我们把早期把它当做一个风险点重视起来，带来的代价也远远小于在后期等它爆发出来的时候再处理。我们现实中就有一个很适合的例子。我们有一个功能是SSO，让合作方去调用我们的接口实现免登录干脆从他们的站点跳
12、转到我们的站点接着运用。因为关系到第三方，所以我们前期就有些担忧到时候这一块会不会出现什么东西不行控。不过大家也就是想想而已，没有太在意。在项目后期的时候，须要跟第三方站点联调，通过他们的站点来测试我们的SSO接口和接下去的流程是不是可用的。结果这时候发觉，因为第三方平安管控很严格，外部人员无法访问他们的站点。于是我们的测试工作就停滞在那边。后面弄得鸡飞狗跳，两个公司的IT以及架构组的人探讨来探讨去看这个问题怎么解决。发布时间最终还是因为这一点拖延了。#外部依靠最不行控风险管控还有个要点要记住，项目组能处理的问题，算是小问题。须要项目组外的人员处理的，才是大问题。因为项目组外的人员不受你调配，
13、他应承你的时间不确定是你满足的时间；即使是你满足的时间，也不确定真的就能确保在那个时间完成；就算真的完成了，也不确定就达到你想要的效果。#必要的时候，任务要步步紧跟项目经理并不是把任务简洁分出去就可以不管的。假如你的开发人员不是很有阅历，或者技术实力很强，思维很缜密，那你应当紧紧的跟进你分发出去的任务。1. 你应当常常去看一下他们的任务开发到了什么程度，可以的话，让他运行给你看一下。2. 问一下有没有什么问题，有什么可以帮助他的。因为很有可能他就有个问题在纠结，而其实你因为阅历或者了解更多的背景，很简洁就为他指出简洁的解决方案。3. 你在检查的过程当中，也会有可能发觉一些他可能还没发觉的问题，
14、或者跟这个任务相关联的问题。任务的完成进度和完成质量，是影响项目进展的一个重要因素。项目经理的一个主要职能，就是帮助每个任务的快速推动。#做当前，看后续当我们把当前的做的迭代的需求，流程，依靠以及其他的疑问理清晰，让项目组可以顺当推动的时候，项目经理不应当再专注在当前的迭代，而是要起先想整理下一个迭代的事情，让大家在完成当前迭代的时候，不须要暂停在那边，去等待梳理下一个迭代的问题。举一个例子，当前的迭代我们在做用户登录的功能，做完这个迭代，接下去我们就要做登录完的首页展示。开发组在做登录的时候，项目经理也跟着在那边捣腾登录的细微环节。等下一个迭代起先的时候，项目组才发觉首页展示只有原型图，UI
15、 跟HTML都还没做出来，而其他功能更没有打算。于是项目组就只好花两三天的在那边等UI和HTML。#固定的项目组成员这是一个很简洁的要求，但是并不是全部的人都会重视。正如随意加一个开发人员进来并不能够立即让整个项目进展加快，换一个人的话，整个进展确定也会受影响。#组员潜力每一个程序员，测试人员，美工，产品经理，都比你想像的要聪慧。假如你没有对你组员的实力有个清晰的相识，那你可以尝试给他的任务增加一些难度，超过你原来的预期一点点。他能完成，你以后可以再增加一些难度。直到他干脆跟你说他搞不定。假如你觉得你已经有个清晰的相识了，那你也应当记得，只是你觉得。我们有一个项目，里面有个很棒的程序员Joy，平常是个很低调的人。项目经理分任务的时候，就给他几个特定的模块让他完成。他也坚守岗位，做好他份内的事。项目因为种种缘由，不断的拖延。但是Joy还是很诚恳的做好他的本分。后来有人跟Joy讲，你以后要把自己当dev lead看，全部开发的事情你统筹。Joy还是一个很低调的人，他接着做他本分的事情，只不过这次的本分就是统筹负责全部的开发问题。接下去就是项目的问题一个接一
