互联网项目管理心得

　　互联网项目管理心得_表格类模板_表格/模板_实用文档。. 互联网项目管理心得 # 项目经理应该有这样的认识： 互联网项目，会定一个计划发布日期，然而这个项目有个隐藏的实际合理发布日期。因为软件开发并不是一个 直接添加资源就可以加快速度的过程，所以 这个实

　　. 互联网项目管理心得 # 项目经理应该有这样的认识： 互联网项目，会定一个计划发布日期，然而这个项目有个隐藏的实际合理发布日期。因为软件开发并不是一个 直接添加资源就可以加快速度的过程，所以 这个实际合理发布日期是在现实资源合理利用前提下一个客观存在的 最可能早的完成时间。项目进展的过程，其实也是发现这个隐藏的合理发布日期的过程。 从管理的角度来讲，当然是尽可能的赶上计划的发布时间，或者尽可能快的完成项目。但是因为多方面因素的 影响，项目管理是一个欲速则不达的过程。 如果这个计划发布日期早于这个实际合理发布日期，那你越往这个不 合理的日期赶，工期内积累的问题就越多导致后期收尾的时候爆发，结果反而可能连合理发布日 期都赶不上。借 用《让飞》里面的一句话，步子迈得太大了，容易扯着蛋。给项目组定一个个合理的看得见的小目标，步步为 营，一步一步朝着看得见的并且合 理的每一个小目标前行，每一个小目标的积累，才能最终走向项目的成功。 所以务实的项目经理应该认识到如下几点： 1. 项目组可以以快节奏的步伐在前行，但是项目经理本身一定要清晰的认识到，我们明面上是在赶那个计划 发布日期，但是项目组实际的目标应该是那个客观存在的合理发布时间。 2. 随着项目的进行，那个客观存在的合理发布时间会逐渐明朗。它与计划发布时间的差异也逐渐显示出来。 此时有些项目经理往往会通过加资源的方法来尝试缩短这个 合理发布时间。但是真实的情况是，除非你前期的资 源配置不合理，不然在这种情况下加资源，对项目帮助不大。这个地方无须多说，有疑问的人，去看一下《人月 神 线. 项目经理必须有一些坚持。领导或者业务部门经常会有一些压力下来，要求赶那个计划发布时间，同时要 求你想尽任何办法去赶上这个计划发布时间。而现实状况 下，如果你能够调整一些需求的范围，你还是有戏。不 然，你要嘛此时报喜，后期报忧，要嘛此时报忧，后期不忧。掩盖问题往往可以让人开心，但是不代表问题不 存 在。 4. 项目经理能做好的其实就 5 点： a. 控制好了需求； b. 及早的发现问题，报告出来并解决； c. 不出现资源空闲的状态； d. 利用好每个资源去做擅长的事，快速有效的推进各种任务； e. 不浪费资源去做一些对项目目标总体没有帮助的工作，或者一些后期会推翻的需求。 基于这样的认识下，本文有如下几个要点： . . # 项目责任感 项目经理应该有这个的责任感，你要为这个项目的任何一件事情负责，因为这个事情会影响到整个项目的工期， 而你为整个工期负责。 一个例子，我发现现在的项目有一个紧急的问题需要项目组外的人帮忙解决。于是我把邮件发出去，通知 Wendy 赶紧处理这件事情。 几天过去了，Wendy 还没有处理。 我想，我已经把问题说出去了，接下去就是 Wendy 的事情。 那个问题还是没有解决，我的整个工期受影响了。 事后追究起来，我说，我已经发出邮件了，是 Wendy 没有及时处理。 Wendy 说，我事情那么多，我怎么知道这件事情这么急。 . . 项目工期受影响了，谁的责任？Wendy 吗？不，是我自己。 作为一个对整个项目负责的项目经理，没有人会比你更在意项目的进展。让一个不负具体负责的人去帮你推进 你的项目，远远不如你自己用心推进来得有效。 # 项目经理是打杂的 项目组里面的每个专业成员，他们都有擅长的领域，做他们擅长的事情是他们的快乐。而不属于他们擅长的事 情，对他们来说就算是杂事一般。 项目经理一定要有一个这样的意识：项目经理就是打杂的，帮助项目组成员把杂事处理掉，让他们可以专心的 做他们擅长的事情，这样对项目组来说才是高效的。 一个简单的例子，测试人员 Tracy 在测试某个功能的时候，突然发现她需要一个账号，同时开通这个账号的某 些特定的权限，同时她需要一些服务器的信息，比如主机名，某些功能文件夹存放的路径。但是她不清楚这个账号 和权限要找谁开通，这些服务器的信息谁有。 Tracy 是个喜欢做测试的人，但是她不喜欢跟项目组外的人沟通，特别是还要到其他部门去找人问人。这些对 她来说就是杂事，而且她对其他部门的人也不熟，一个一个问明显效率不高。 你可以自己去帮她找到需要的信息，也可以找一个对这方面比较熟的人去解决，但是你绝对不能让她自己去做。 “为什么我的手下不能解决这么简单的问题？如果连这种事情都要我来帮忙的话，那我这个项目经理做来干什 么？她当项目经理得了。“这种想法千万是不可取的。你当这个项目经理的目的并不是管人，指使这人做什么那人 做什么。你的目标只是把项目快速推进完成。 # 控制需求 在所有因素当中，需求对项目的影响力，至少占 50%以上。能够控制好需求，项目就成功了一半。控制需求， 有如下几点： 1. 必须有人能够当好产品经理这个角色 一个项目组当中，其实人人都可以影响需求。但是管理需求的，是产品经理这个岗位。如果你的项目组当中已 经有一个很好的产品经理，恭喜你，项目经 理可以轻松很多。但是世间事不会如此幸运，因为现实生活中，并不 是所有的产品经理都这么棒。作为一个对项目完成负责的项目经理，当你们组没有一个好的产品 经理的时候，你 必须意识到，你至少要扮演好一半的产品经理，除非你本身对项目的完成也没什么责任感。 2. 管理需求的人要平衡工期和功能友好程度 需求其实有两个极端，一个是尽善尽美，尽可能的让功能更友好，用户体验更佳；一个是尽早交付，一切改善 性的需求都可以牺牲。 只满足前者，项目工期可能会不断的拖延，因为很多功能的工作量其实是在细节的优化，而不是主要流程的完 成。只满足后者，很可能会出现一个让用户很不满意的产品。 . . 一个有经验或者产品意识很好的产品经理，可以很好的平衡好这两点。如果产品经理不能平衡好，那只好依赖 项目经理来平衡。这点，如果产品经理或项目经理不是天才的话，只能通过经验来学习。 比如我们在做一个注册的页面，里面有个城市的输入框。城市的输入框可以做得很友好。如果要项目尽早完成， 那么这个输入框我们只要让用户自己输入 就行。一个比较好的设计就是两个下拉环框，一个选择省份，然后再选 择城市。但是一个更好的设计是让用户既可以选择，也可以自由的在这个输入框里面输入拼音 首字母，汉字，然 后系统就会自己显示相匹配的城市让用户选择。后两者的改进肯定会花时间，但是如果这两种改进都不做，让用户 只是自由输入的话，后期维护的 时候就会出现用户输入不标准的城市数据，如果我们需要用户的城市数据做一些 其他功能，就会有错误数据的风险。 3. 懂得对不重要的需求说不 如果你不能平衡好工期跟功能改进的话，有一点你一定要意识好，就是你一定要懂得对不重要的需求说不。这 很简单，你对一个需求说不，只要这个需求 不是一个会造成其他功能依赖的核心需求，就算这个需求后面发现必 须实现，你可以补上，总体工作量并没有增加。但是如果你花资源去完成了这个需求，后面却发 现这个需求是不 重要的或者可以简化的，那你已经浪费了一些工作量。两者的代价相比，明显前者的代价比较小。 4. 理好需求优先级 需求的优先级应该满足如下几点： a. 确定不变的需求应该先完成，如果项目组去完成了一些功能，结果后面发现需求要改，那前期的一些 工作量已经浪费了。 b. 被其他需求依赖的需求应该先完成，只有这样，才能不挡住依赖它的需求的开发。比如登录功能，很 多登录后的页面都需要当前登录的用户信息。 c. 主流程，或者核心需求应该先完成，改善性的需求应该后完成。比如信息列表页面，很多功能需要用 户在信息列表里面选择要操作的记录。因此信息列表是核心需求。而在信息列表页里面一个列显示格式的美化，这 属于改善性需求。 # 风险管控 风险管控是项目经理一个非常重要的技能。一个好的项目经理应该尽量在早期把所有的风险都列出来，一个一 个解决。一个流畅的项目，从前期到后期风 险点应该是倒三角形的，就是前期风险很多，后期风险越来越少。而 项目管理不畅的，则是一个正三角形，上面风险少，到后期风险就多了。 项目经理应该尽可能的找出所有的风险点。假设有一个点，你不确定他是不是有风险的，那即使我们把早期把 它当做一个风险点重视起来，带来的代价也远远小于在后期等它爆发出来的时候再处理。 我们现实中就有一个很适合的例子。我们有一个功能是 SSO，让合作方去调用我们的接口实现免登录直接从他 们的站点跳转到我们的站点继续使用。因为关系到第三方，所以我们前期就有些担心到时候这一块会不会出现什么 东西不可控。不过大家也就是想想而已，没有太在意。 . . 在项目后期的时候，需要跟第三方站点联调，通过他们的站点来测试我们的 SSO 接口和接下去的流程是不是可 用的。结果这时候发现，因为第三方安全 管控很严格，外部人员无法访问他们的站点。于是我们的测试工作就停 滞在那边。后面弄得鸡飞狗跳，两个公司的 IT 以及架构组的人讨论来讨论去看这个问题怎么 解决。发布时间最终 还是因为这一点拖延了。 # 外部依赖最不可控 风险管控还有个要点要记住，项目组能处理的问题，算是小问题。需要项目组外的人员处理的，才是大问题。 因为项目组外的人员不受你调配，他应承你 的时间不一定是你满意的时间；即使是你满意的时间，也不一定真的 就能确保在那个时间完成；就算真的完成了，也不一定就达到你想要的效果。 #必要的时候，任务要步步紧跟 项目经理并不是把任务简单分出去就可以不管的。如果你的开发人员不是很有经验，或者技术实力很强，思维 很缜密，那你应该紧紧的跟进你分发出去的任务。 1. 你应该经常去看一下他们的任务开发到了什么程度，可以的话，让他运行给你看一下。 2. 问一下有没有什么问题，有什么可以帮助他的。因为很有可能他就有个问题在纠结，而其实你因为经验或 者了解更多的背景，很简单就为他指出简单的解决方案。 3. 你在检查的过程当中，也会有可能发现一些他可能还没发现的问题，或者跟这个任务相关联的问题。任务 的完成进度和完成质量，是影响项目进展的一个重要因素。项目经理的一个主要职能，就是帮助每个任务的快速推 进。 #做当前，看后续 当我们把当前的做的迭代的需求、流程、依赖以及其他的疑问理清楚，让项目组可以顺利推进的时候，项目经 理不应该再专注在当前的迭代，而是要开始想整理下一个迭代的事情，让大家在完成当前迭代的时候，不需要暂停 在那边，去等待梳理下一个迭代的问题。 举一个例子，当前的迭代我们在做用户登录的功能，做完这个迭代，接下去我们就要做登录完的首页展示。开 发组在做登录的时候，项目经理也跟着在那 边捣腾登录的细节。等下一个迭始的时候，项目组才发现首页展 示只有原型图，UI 跟 HTML 都还没做出来，而其他功能更没有准备。于是项目组就只好花两三天的在那边等 UI 和 HTML。 # 固定的项目组成员 这是一个很简单的要求，但是并不是所有的人都会重视。正如随便加一个开发人员进来并不能够立刻让整个项 目进展加快，换一个人的话，整个进展肯定也会受影响。 # 组员潜力 . . 每一个程序员、测试人员、美工、产品经理，都比你想像的要聪明。如果你没有对你组员的能力有个清晰的认 识，那你可以尝试给他的任务增加一些难 度，超过你原来的预期一点点。他能完成，你以后可以再增加一些难度。 直到他直接跟你说他搞不定。如果你觉得你已经有个清晰的认识了，那你也应该记得，只是 你觉得。 我们有一个项目，里面有个很棒的程序员 Joy，平常是个很低调的人。项目经理分任务的时候，就给他几个特 定的模块让他完成。他也坚守岗位，做好他份内的事。项目因为种种原因，不断的拖延。但是 Joy 还是很诚实的做 好他的本分。 后来有人跟 Joy 讲，你以后要把自己当 dev lead 看，所有开发的事情你统筹。Joy 还是一个很低调的人，他继 续做他本分的事情，只不过这次的本分就是统筹负责所有的开发问题。接下去就是项目的问 题一个接一个的被快 速解决掉，其他程序员也得到强有力的帮助，快速处理到自己手头中的 bug。项目进展很快赶上了原来的计划。你 真的很好的发挥了你组员的 潜力了吗？ #人人看到全盘 项目经理能够很好的分配好任务，让各个组员可以较独立的工作，这是不错，但也不见得就是好事。因为软件 开发是一个团体的工作，各个人做的事情之间都有交叉。我做的功能，接下去就要调用你的接口。你做的页面，接 下去就要跳转到我的。 Bruce 做一个功能，是要显示公司人员信息的列表。里面有个操作，选择一个人员计算出勤率。这个操作不是 Bruce 完成了，他只要直接调用 Lisa 的页面，Lisa 的页面会直接计算出勤率并显示出来。Bruce 认识，他只要简单 传一个人员的 ID 过去就可以了。 Lisa 做这个出勤率的页面，因为这个人员是属于业务人员，经常要在分公司跑，所以只能计算他在某一个分公 司的出勤情况。她以为大家都知道。等 大家都完成了，QA 在测试的时候，发现在人员信息列表里面点进去，显示 不了出勤页面。整个流程都走不通了。后来才发现有 2 个问题没解决好，一个人员信息跳 转到出勤页面前要传递 当前的分公司信息，一个是出勤页面还要增加选择分公司的功能。这 2 个问题一个是 QA 测出 Bug，一个是需求还有 不足。而这本来是应该 在开发周期内就可以发现并解决的问题。 根源就在于，Bruce 跟 Lisa 在做手头任务的时候，都没有去考虑跟其他人的关联。而他们 2 个人都没有去考虑 的话，其他人更不会去考虑了。如果 Bruce 或者 Lida 在做任务的时候，去想想他们彼此怎么串联起来，这问题本 身就很简单了。 项目组的每个人，可以重点在自己手头的任务，但是思路必须是在全盘，大家脑子里面都要经常去想想，整个 系统是什么样子的，我的功能前后的依赖是什么样的。项目经理平常要引导大家这样想。 # 一定要分成每一个小迭代 步伐迈得太大了，你就不知道你迈得对不对，迈得够不够快。项目是不可能一步到位的。把一个大目标分解成 每一个小目标，整个项目工期分成若干个短 迭代，一个一个的完成。每一个完成的小目标都能帮助你理清整个项 . . 目的进度，方向，帮助你审核一下目前的思路是对的还是错的，出错了，也能够及时的调整。 # 不做一半的功能 如果我们做了 2 个功能，但是我们每个功能都做了一半没全部完成，那目前为止我们总计完成了多少个功能？ 1 个？不是的，完成了 0 个。一个功能除非真正完成并且通过产品经理的检查，不然你永远不能确定这个功能是不 是还有一些遗漏的地方。 100 个完成度为 90%的功能合起来，完成的功能还是 0 个。你很兴奋你的程序里面有很多功能，但是你试了一 个又一个，结果发现每个功能都是半成品，没有一个功能可以正确解决你的问题。对于半成品的功能： 1. 你其实并不知道你还剩多少工作量，因为已经“完成“的工作不能验证说是线. 你没法给业务部门或者客户做演示，因为这些功能没做完。 3. 如果业务部门让你暂停一下，就先按照目前已有的功能去让客户测试一下，你会哑巴吃黄莲，有苦说不出。 所以我们做功能的时候，要确保我们在做的功能已经是真正完成了，我们再去接着做下一个功能。 # 不让细节影响你的目标 项目组的人很容易沉浸在功能的细节当中，为一些友好美观的显示，炫丽的功能或者很酷的设计浪费大把的时 间，忘记了这个项目的最终目标是什么。其他人可以投入，但是项目经理一定要能够抽身事外，专注在项目的全局。 沉浸在细节当中很容易让人忘记工期，忘记项目的最终目标。 我这个提示信息的颜色会不会太淡了？ 要不要再调深一些？我这个按钮是不是可以往左边移 10 像素，这样更好看？ 这个地方要不要来一个自动提示，这样会更友好一点？ 我这个面板的显示要不要使用渐变的？1 秒内渐变完成会不会太快？用户会不会还没看够？ 你先把功能完成再说好吗？以后有的是大把的时间美化这些。 # 正确的里程碑要点 我们碰过一个项目，项目经理的报告说，目前的状态是开发完成。结果一看，这样说的依据是分配到所有开发 人员的任务，开发人员都认定为完成了。于是大家就认为目前是开发完成，进入 QA 测试的阶段。结果 QA 报怨测试 不下去，流程都走不通。 产品经理进去看了一下，也说很多地方功能缺失。根本不能认定为开发完成。 1. 一个项目，或者一个短迭代，应该先列出一个所有人都认同的里程碑列表。比如，分为框架设计完成；分 解出来的需求已经可用于开发；子任务划分完成；子任务已经分配并预估完成；各子任务完成；开发人员整合测试 完成；产品经理检查通过；QA 测试通过。 2. 每个里程碑的完成要有大家都认同的验证方式比如如何判断开发人员整合测试完成，是不是开发人员坐在 一起或者开发组长把所有流程都走过一遍，然后发现没有什么大的问题？ #自我管理 . . 前面讲了这么多，弄得好像项目经理很重要，缺了这个项目经理整个项目就不转了。如果项目经理的手下是固 定的，只不过做的项目不一样，那我建议项目经理在完成项目的基础上，一定要考虑这样一个目标： 建立一套流程，一套大家都熟悉并且会遵守的流程。这个流程可以保证整个项目组在项目经理不在的情形下， 也可以运转得很好。 目前项目处在什么阶段，这个阶段大家要做什么，下一个阶段是什么；这个阶段有什么任务要做；每个阶段碰 到问题要怎么处理；每种任务或者问题由谁来处理。这些并不是很难学会的东西。项目的成员经历过几次，很容易 就可以理解要怎么做。 项目经理除了推进项目以外，还要在项目的过程中把流程的思路，解决各种问题的思路教给大家，同时明确每 个人的职责，达到项目组可以自我管理的程度。 一个可以自我管理的项目组，才是一个稳定高效的项目组。项目经理才可以抽身出来，同时去做一些其他的对 部门，对公司同时也对自己有利的事情。 .