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