互联网项目的特点之项目管理要点(2)

　　比如我们在做一个注册的页面，里面有个城市的输入框。城市的输入框可以做得很友好。如果要项目尽早完成，那么这个输入框我们只要让用户自己输入就行。一个比较好的设计就是两个下拉环框，一个选择省份，然后再选择城市。但是一个更好的设计是让用户既可以选择，也可以自由的在这个输入框里面输入拼音首字母，汉字，然后系统就会自己显示相匹配的城市让用户选择。后两者的改进肯定会花时间，但是如果这两种改进都不做，让用户只是自由输入的话，后期维护的时候就会出现用户输入不标准的城市数据，如果我们需要用户的城市数据做一些其他功能，就会有错误数据的风险。

　　3. 懂得对不重要的需求说不

　　如果你不能平衡好工期跟功能改进的话，有一点你一定要意识好，就是你一定要懂得对不重要的需求说不。这很简单，你对一个需求说不，只要这个需求不是一个会造成其他功能依赖的核心需求，就算这个需求后面发现必须实现，你可以补上，总体工作量并没有增加。但是如果你花资源去完成了这个需求，后面却发现这个需求是不重要的或者可以简化的，那你已经浪费了一些工作量。两者的代价相比，明显前者的代价比较小。

　　4. 理好需求优先级

　　需求的优先级应该满足如下几点：

　　a. 确定不变的需求应该先完成，如果项目组去完成了一些功能，结果后面发现需求要改，那前期的一些工作量已经浪费了。

　　b. 被其他需求依赖的需求应该先完成，只有这样，才能不挡住依赖它的需求的开发。

　　比如登录功能，很多登录后的页面都需要当前登录的用户信息。

　　c. 主流程，或者核心需求应该先完成，改善性的需求应该后完成。

　　比如信息列表页面，很多功能需要用户在信息列表里面选择要操作的记录。因此信息列表是核心需求。而在信息列表页里面一个列显示格式的美化，这属于改善性需求。

　　#风险管控

　　风险管控是项目经理一个非常重要的技能。一个好的项目经理应该尽量在早期把所有的风险都列出来，一个一个解决。一个流畅的项目，从前期到后期风险点应该是倒三角形的，就是前期风险很多，后期风险越来越少。而项目管理不畅的，则是一个正三角形，上面风险少，到后期风险就多了。

　　项目经理应该尽可能的找出所有的风险点。假设有一个点，你不确定他是不是有风险的，那即使我们把早期把它当做一个风险点重视起来，带来的代价也远远小于在后期等它爆发出来的时候再处理。

　　我们现实中就有一个很适合的例子。我们有一个功能是SSO，让合作方去调用我们的接口实现免登录直接从他们的站点跳转到我们的站点继续使用。因为关系到第三方，所以我们前期就有些担心到时候这一块会不会出现什么东西不可控。

　　不过大家也就是想想而已，没有太在意。

　　在项目后期的时候，需要跟第三方站点联调，通过他们的站点来测试我们的SSO接口和接下去的流程是不是可用的。结果这时候发现，因为第三方安全管控很严格，外部人员无法访问他们的站点。于是我们的测试工作就停滞在那边。后面弄得鸡飞狗跳，两个公司的IT以及架构组的人讨论来讨论去看这个问题怎么解决。

　　发布时间最终还是因为这一点拖延了。

　　#外部依赖最不可控

　　风险管控还有个要点要记住，项目组能处理的问题，算是小问题。需要项目组外的人员处理的，才是大问题。因为项目组外的人员不受你调配，他应承你的时间不一定是你满意的时间;即使是你满意的时间，也不一定真的就能确保在那个时间完成;就算真的完成了，也不一定就达到你想要的效果。

　　#必要的时候，任务要步步紧跟

　　项目经理并不是把任务简单分出去就可以不管的。如果你的开发人员不是很有经验，或者技术实力很强，思维很缜密，那你应该紧紧的跟进你分发出去的任务。

　　1. 你应该经常去看一下他们的任务开发到了什么程度，可以的话，让他运行给你看一下。

　　2. 问一下有没有什么问题，有什么可以帮助他的。因为很有可能他就有个问题在纠结，而其实你因为经验或者了解更多的背景，很简单就为他指出简单的解决方案。

　　3. 你在检查的过程当中，也会有可能发现一些他可能还没发现的问题，或者跟这个任务相关联的问题。

　　任务的完成进度和完成质量，是影响项目进展的一个重要因素。项目经理的一个主要职能，就是帮助每个任务的快速推进。

　　#做当前，看后续

　　当我们把当前的做的迭代的需求，流程，依赖以及其他的疑问理清楚，让项目组可以顺利推进的时候，项目经理不应该再专注在当前的迭代，而是要开始想整理下一个迭代的事情，让大家在完成当前迭代的时候，不需要暂停在那边，去等待梳理下一个迭代的问题。

　　举一个例子，当前的迭代我们在做用户登录的功能，做完这个迭代，接下去我们就要做登录完的首页展示。开发组在做登录的时候，项目经理也跟着在那边捣腾登录的细节。等下一个迭代开始的时候，项目组才发现首页展示只有原型图，UI 跟HTML都还没做出来，而其他功能更没有准备。于是项目组就只好花两三天的在那边等UI和HTML。

　　#固定的项目组成员

　　这是一个很简单的要求，但是并不是所有的人都会重视。

　　正如随便加一个开发人员进来并不能够立刻让整个项目进展加快，换一个人的话，整个进展肯定也会受影响。

　　#组员潜力

　　每一个程序员，测试人员，美工，产品经理，都比你想像的要聪明。如果你没有对你组员的能力有个清晰的认识，那你可以尝试给他的任务增加一些难度，超过你原来的预期一点点。他能完成，你以后可以再增加一些难度。直到他直接跟你说他搞不定。如果你觉得你已经有个清晰的认识了，那你也应该记得，只是你觉得。

　　我们有一个项目，里面有个很棒的程序员Joy，平常是个很低调的人。项目经理分任务的时候，就给他几个特定的模块让他完成。他也坚守岗位，做好他份内的事。项目因为种种原因，不断的拖延。但是Joy还是很诚实的做好他的本分。

　　后来有人跟Joy讲，你以后要把自己当dev lead看，所有开发的事情你统筹。

原文转自：http://www.ltesting.net