背景
　　一眨眼，加入阿里大家庭已经一年多啦。在一年多的工作中，深深感受到互联网项目管理与传统IT项目管理的不同，在此尝试做一下简单的总结和分析。
　　本文先讲一讲需求管理。为啥要先说需求管理呢，因为在所有影响项目成功与否的因素当中，需求对项目的影响力，至少占50%以上。能够控制管理好需求，项目成功了一半。
　　需求不可贪大求全，要懂得取舍
　　互联网是一个快速变化的世界，我们所面临的用户、环境每天都在改变，这要求项目团队能够适应这种情况，要能够做到快速迭代、快速上线、快速试错、抢占用户。不同于传统的软件项目，动辄几个月甚至几年的项目周期，互联网项目通常是以周为单位进行迭代。相对于需求，速度、抢占用户的速度更加重要。我们需要产品快速上线，更快的获取用户反馈，在用户参与和反馈中逐步改进完善产品。
　　因此，我们要懂得取舍，懂得对不重要的需求说不。
　　当然，说不不代表不去实现，后期发现这个需求必须实现，你可以补上，总体工作量并没有增加。
　　如注册用户的功能，可以做得很复杂，也可以只有用户名、邮箱、密码和验证码这几个简单项，很显然，前者中有大量的信息项是不必要的，这些信息项可以先设计出来，然后放在下一个迭代中去完成。但如果产品的第一个版本去全部实现，这些不必要的内容会增加开发、测试环节的工作量。
　　这是传统IT项目与互联网项目大的不同。传统IT项目开发周期非常长，会做长时间的需求调研，需求大而全；而互联网项目大多小而精，在持续不断的迭代中优化产品。
　　确定需求优先级
　　项目经理需要根据业务需求确定优先级，需求的优先级应该满足如下几点：
　　1. 主流程，或者核心需求优先级高
　　体验性的需求优先级比较低。比如笔者负责的一个处理买家投诉的系统，投诉案件的处理流程是整个系统的核心，应该先完成；而对案件进行批量处理是一个改善性需求，优先级没有那么高。
　　2. 被其他需求依赖的需求优先级高
　　这个应该先完成。只有这样，才能不影响依赖它的需求的开发。比如创建案件功能，后续的案件处理都需要围绕创建的案件来进行，因此必须先开发。
　　3. 确定不变的需求优先级高于不确定的需求
　　这个应该先完成。对于一些模糊的需求，必须等业务方和PD讨论清楚了再动手。如果开发人员按自己的理解去完成了一些不是很明确的需求，结果后面发现需求要改，那前期的一些工作量已经浪费了。
　　在传统IT项目中，还有一种需求虽然从功能上来说可能优先级很低，但从关注度来说由于是对方公司领导或核心人员很看重的，优先级也会很高，必须优先实现。（不是本文讨论的重点）
　　确定好需求的优先级后，在项目开发后期，如果项目可能出现延期，项目经理可以对一些优先级低的需求进行取舍，保证项目按计划发布。后这些未实现的需求可以顺延到下一个迭代周期去完成。
　　项目经理要平衡好进度和用户体验
　　互联网产品需求其实有两个极端，一个是尽善尽美，尽可能的让功能更友好，用户体验更佳；一个是尽早交付，一切改善性的需求都可以牺牲。
　　只满足前者，项目进度可能会不断的拖延，因为很多功能的工作量其实是在用户体验的优化，而不是主要流程的完成。只满足后者，很可能会出现一个让用户很不满意的产品。
　　一个有经验的产品经理（项目经理），可以很好的平衡好这两点。这里有一个方法是和业务方提前沟通好系统每个功能的交互体验需要达到什么效果。
　　笔者在设计买家投诉系统时，案件查询有一个当前案件处理人的查询条件。如果要项目尽早完成，那么我们放一个输入框让用户自己输入处理人账号行。如果我们做一下适当优化，可以使用一个下拉框，里面列出当前所有的案件处理人，让用户选择；更好的体验是让用户自由的在这个输入框里面输入账号字母，然后系统会自己显示相匹配的处理人账号让用户选择。三个不同实现花费的时间是逐渐增多的。但是如果这两种改进都不做，让用户只是自由输入的话，用户交互体验效果会很差。具体终使用哪一个设计，需要和业务方沟通及平衡工期来确定。
　　控制好需求变更
　　这个世界不变的是变化了。项目一旦开始，变更也随之而来。基本上每个项目在开发过程中都会遇到需求变更，这是没法完全避免的，只能通过一些方法来控制需求变更的影响范围。变更不可怕，可怕的是变更不受控制。
　　1.我们首先要明确，项目越到后期，需求变更对项目的影响越大。
　　因此，项目开始之前先问下业务方或PD为什么要这样做，上线后能带来的业务价值是什么。 让业务方或PD把自己的需求想清楚，因为很多时候他们自己还没想清楚的时候让你去实现。
　　2.系统设计时要考虑未来的需求变化，使系统具有灵活性和扩展性。
　　如我们在设计用户投诉系统时，考虑到不同类型的案件，需要用户输入的信息可能有所不同，因此用户提交案件界面我们设计了可配置界面，用户的所有输入信息都可配置。后来当新增加一个案件类型时，我们只需要在后台进行输入信息的配置即可，完全实现了代码的零改动。
　　3.确定项目需求接口人
　　所有需求变更都需要该接口人同意。接口人需要对系统架构和业务需求非常清楚，一般都是项目经理。经常到了项目开发后期，都快上线了，业务人员或PD会过来说：“我这里有一个需求当时没想清楚，现在想清楚了，你帮我加上去”。这个时候需求的任何变化对工期的影响都是非常大的。一般到了项目后期，我的经验是，除非这个功能对这期上线的版本有重大影响，否则都放在下一个迭代中去完成。
　　之前有一个项目，第二天要发布了，业务人员跑过来说要增加一个小需求，而我们的开发人员也很好说话，二话不说加上去了。结果导致项目发布延期。而这个需求我们后来评估只是一个很小的改善性需求，放到下个迭代中去实现完全没有任何影响。