互联网项目管理总结
互联网项目管理心得
# 项目经理应该有这样的认识：
互联网项目，会定一个计划发布日期，然而这个项目有个隐藏的实际合理发布日期。因为软件开发并不是一个直接添加资源就可以加快速度的过程，所以这个实际合理发布日期是在现实资源合理利用前提下一个客观存在的最可能早的完成时间。项目进展的过程，其实也是发现这个隐藏的合理发布日期的过程。
从管理的角度来讲，当然是尽可能的赶上计划的发布时间，或者尽可能快的完成项目。但是因为多方面因素的影响，项目管理是一个欲速则不达的过程。如果这个计划发布日期早于这个实际合理发布日期，那你越往这
上。
成功。
月
存在。
4. 项目经理能做好的其实就5点：
a. 控制好了需求；
b. 及早的发现问题，报告出来并解决；
c. 不出现资源空闲的状态；
d. 利用好每个资源去做擅长的事，快速有效的推进各种任务；
e. 不浪费资源去做一些对项目目标总体没有帮助的工作，或者一些后期会推翻的需求。
基于这样的认识下，本文有如下几个要点：
期，而你为整个工期负责。
一个例子，我发现现在的项目有一个紧急的问题需要项目组外的人帮忙解决。于是我把邮件发出去，通知Wendy赶紧处理这件事情。
几天过去了，Wendy还没有处理。
我想，我已经把问题说出去了，接下去就是Wendy的事情。
那个问题还是没有解决，我的整个工期受影响了。
事后追究起来，我说，我已经发出邮件了，是Wendy没有及时处理。
Wendy说，我事情那么多，我怎么知道这件事情这么急。
项目工期受影响了，谁的责任？Wendy吗？不，是我自己。
作为一个对整个项目负责的项目经理，没有人会比你更在意项目的进展。让一个不负具体负责的人去帮你推进你的项目，远远不如你自己用心推进来得有效。
# 项目经理是打杂的
项目组里面的每个专业成员，他们都有擅长的领域，做他们擅长的事情是他们的快乐。而不属于他们擅长的事情，对他们来说就算是杂事一般。
项目经理一定要有一个这样的意识：项目经理就是打杂的，帮助项目组成员把杂事处理掉，让他们可以专心的做他们擅长的事情，这样对项目组来说才是高效的。
做。
#
已经有一个很好的产品经理，恭喜你，项目经理可以轻松很多。但是世间事不会如此幸运，因为现实生活中，并不是所有的产品经理都这么棒。作为一个对项目完成负责的项目经理，当你们组没有一个好的产品经理的时候，你必须意识到，你至少要扮演好一半的产品经理，除非你本身对项目的完成也没什么责任感。
2. 管理需求的人要平衡工期和功能友好程度
需求其实有两个极端，一个是尽善尽美，尽可能的让功能更友好，用户体验更佳；一个是尽早交付，一切改善性的需求都可以牺牲。
只满足前者，项目工期可能会不断的拖延，因为很多功能的工作量其实是在细节的优化，而不是主要流程的完成。只满足后者，很可能会出现一个让用户很不满意的产品。
一个有经验或者产品意识很好的产品经理，可以很好的平衡好这两点。如果产品经理不能平衡好，那只好依赖项目经理来平衡。这点，如果产品经理或项目经理不是天才的话，只能通过经验来学习。
比如我们在做一个注册的页面，里面有个城市的输入框。城市的输入框可以做得很友好。如果要项目尽早完成，那么这个输入框我们只要让用户自己输入就行。一个比较好的设计就是两个下拉环框，一个选择省份，然后再选择城市。但是一个更好的设计是让用户既可以选择，也可以自由的在这个输入框里面输入拼音首字母，汉字，然后系统就会自己显示相匹配的城市让用户选择。后两者的改进肯定会花时间，但是如果这两种改进都不做，让用户只是自由输入的话，后期维护的时候就会出现用户输入不标准的城市数据，如果我们需要用户的城市数据做一些其他功能，就会有错误数据的风险。
#
风险管控是项目经理一个非常重要的技能。一个好的项目经理应该尽量在早期把所有的风险都列出来，一个一个解决。一个流畅的项目，从前期到后期风险点应该是倒三角形的，就是前期风险很多，后期风险越来越少。而项目管理不畅的，则是一个正三角形，上面风险少，到后期风险就多了。
项目经理应该尽可能的找出所有的风险点。假设有一个点，你不确定他是不是有风险的，那即使我们把早期把它当做一个风险点重视起来，带来的代价也远远小于在后期等它爆发出来的时候再处理。
我们现实中就有一个很适合的例子。我们有一个功能是SSO，让合作方去调用我们的接口实现免登录直接从他们的站点跳转到我们的站点继续使用。因为关系到第三方，所以我们前期就有些担心到时候这一块会不会出现什么东西不可控。不过大家也就是想想而已，没有太在意。
在项目后期的时候，需要跟第三方站点联调，通过他们的站点来测试我们的SSO接口和接下去的流程是不是可用的。结果这时候发现，因为第三方安全管控很严格，外部人员无法访问他们的站点。于是我们的测试工作就停滞在那边。后面弄得鸡飞狗跳，两个公司的IT以及架构组的人讨论来讨论去看这个问题怎么解决。发布时间最终还是因为这一点拖延了。
# 外部依赖最不可控
风险管控还有个要点要记住，项目组能处理的问题，算是小问题。需要项目组外的人员处理的，才是大问题。因为项目组外的人员不受你调配，他应承你的时间不一定是你满意的时间；即使是你满意的时间，也不一定真的就能确保在那个时间完成；就算真的完成了，也不一定就达到你想要的效果。
#
思
#
不需要
页展示只有原型图，UI 跟HTML都还没做出来，而其他功能更没有准备。于是项目组就只好花两三天的在那边等UI和HTML。
# 固定的项目组成员
这是一个很简单的要求，但是并不是所有的人都会重视。正如随便加一个开发人员进来并不能够立刻让整个项目进展加快，换一个人的话，整个进展肯定也会受影响。
# 组员潜力
每一个程序员、测试人员、美工、产品经理，都比你想像的要聪明。如果你没有对你组员的能力有个清晰的认识，那你可以尝试给他的任务增加一些难度，超过你原来的预期一点点。他能完成，你以后可以再增加一些难度。直到他直接跟你说他搞不定。如果你觉得你已经有个清晰的认识了，那你也应该记得，只是你觉得。
我们有一个项目，里面有个很棒的程序员Joy，平常是个很低调的人。项目经理分任务的时候，就给他几个特定的模块让他完成。他也坚守岗位，做好他份内的事。项目因为种种原因，不断的拖延。但是Joy还是很诚实的做好他的本分。
后来有人跟Joy讲，你以后要把自己当dev lead看，所有开发的事情你统筹。Joy还是一个很低调的人，他继续做他本分的事情，只不过这次的本分就是统筹负责所有的开发问题。接下去就是项目的问题一个接一个
#
是
，一个
考虑的话，其他人更不会去考虑了。如果Bruce或者Lida在做任务的时候，去想想他们彼此怎么串联起来，这问题本身就很简单了。
项目组的每个人，可以重点在自己手头的任务，但是思路必须是在全盘，大家脑子里面都要经常去想想，整个系统是什么样子的，我的功能前后的依赖是什么样的。项目经理平常要引导大家这样想。
# 一定要分成每一个小迭代
步伐迈得太大了，你就不知道你迈得对不对，迈得够不够快。项目是不可能一步到位的。把一个大目标分解成每一个小目标，整个项目工期分成若干个短迭代，一个一个的完成。每一个完成的小目标都能帮助你理清整
个项目的进度，方向，帮助你审核一下目前的思路是对的还是错的，出错了，也能够及时的调整。
# 不做一半的功能
如果我们做了2个功能，但是我们每个功能都做了一半没全部完成，那目前为止我们总计完成了多少个功能？1个？不是的，完成了0个。一个功能除非真正完成并且通过产品经理的检查，不然你永远不能确定这个功能是不是还有一些遗漏的地方。
100个完成度为90%的功能合起来，完成的功能还是0个。你很兴奋你的程序里面有很多功能，但是你试了一个又一个，结果发现每个功能都是半成品，没有一个功能可以正确解决你的问题。对于半成品的功能：
1. 你其实并不知道你还剩多少工作量，因为已经“完成“的工作不能验证说是真正完成的。
#
#
QA报怨测试不下去，流程都走不通。
产品经理进去看了一下，也说很多地方功能缺失。根本不能认定为开发完成。
1. 一个项目，或者一个短迭代，应该先列出一个所有人都认同的里程碑列表。比如，分为框架设计完成；分解出来的需求已经可用于开发；子任务划分完成；子任务已经分配并预估完成；各子任务完成；开发人员整合测试完成；产品经理检查通过；QA测试通过。
2. 每个里程碑的完成要有大家都认同的验证方式比如如何判断开发人员整合测试完成，是不是开发人员坐在一起或者开发组长把所有流程都走过一遍，然后发现没有什么大的问题？
#自我管理
前面讲了这么多，弄得好像项目经理很重要，缺了这个项目经理整个项目就不转了。如果项目经理的手下是固定的，只不过做的项目不一样，那我建议项目经理在完成项目的基础上，一定要考虑这样一个目标：建立一套流程，一套大家都熟悉并且会遵守的流程。这个流程可以保证整个项目组在项目经理不在的情形下，也可以运转得很好。
目前项目处在什么阶段，这个阶段大家要做什么，下一个阶段是什么；这个阶段有什么任务要做；每个阶段碰到问题要怎么处理；每种任务或者问题由谁来处理。这些并不是很难学会的东西。项目的成员经历过几次，很容易就可以理解要怎么做。
项目经理除了推进项目以外，还要在项目的过程中把流程的思路，解决各种问题的思路教给大家，同时明确