一个需求的一生.docx

一个需求的一生 PAGE 1 一个需求的一生 求这个词对产品的意义，就像代码这个词对于开发的意义；一个需求由提出到解决经历了哪些过程？一个需求的“一生”是怎样的？让我们随着作者的思路看下去。相信对于产品人员来说，听到频率最高的一个词莫过于“需求”了。业务人员或者客户会对产品说：这里要加一个需求/功能；产品会对各方人员解释说：这个需求是这样的，这个场景是那样的……为了加需求和改需求，产品和开发相爱相杀的案例也不少。可以说，产品的日常工作，最绕不开的一个词，就是需求了。我们每天要接收需求，要处理需求，要传达需求。需求这个词对产品的意义，就像代码这个词对于开发的意义。对于产品每天都要打交道的“需求”，我突然想聊一聊“一个需求的一生”这个话题。首先我们看一下关于需求的流程：一、需求的产生需求是怎么来的呢？很多人会以为需求产生的源头是产品经理。其实并不全是。需求方有几类人员：客户、老板、产品、业务/销售、测试。而需求的产生也并不是一开始就是需求（此类需求称为“纯需求”），也有从bug转化过来的需求（此类需求称为“bug转需求”）。纯需求一般是客户提出来较多，业务/销售传达的纯需求也是客户的想法。客户在日常使用产品的时候，会发现有的产品的流程和实际业务有出入，会觉得“系统不好用”。这个时候他们经常会联系技术支持人员或者业务人员，传达自己的想法。客户在提需求的时候也会有不同，一种是根据实际业务提需求，一种是根据竞品提需求。如果是根据实际业务提需求的话，在提需求的时候，客户会告诉你实际的业务流程、当前系统存在的问题以及他所期望的效果。虽然这类需求算是比较明确的，但是产品在接到这类需求的时候，还是需要多问多思考；因为有的时候客户提的需求有可能是“伪需求”。他们可能觉得业务上需要这个，那就得增加这个功能；其实有些问题可以通过更好、更优的方案来解决。这就需要产品深入地思考客户的“痛点”到底是什么，通过对客户的诉求抽丝剥茧，找到他们真实的需求。如果全部按照客户的描述去产出方案的话，虽然能够满足客户的需求，但是对整个产品未必是有益的。除了根据业务提需求，客户还会根据竞品提需求。有可能客户试用了或者看到了其他竞品的某个功能，觉得很不错。会过来跟我们提需求：“人家XX系统的那个签合同的功能可好了，现在你们系统没有，很不方便，需要加一个”。这种需求其实是比较明确的，连竞品帮产品都找好了。产品如果确定了要做这个需求的话，直接去梳理一下竞品的逻辑，然后根据自己系统做好调整就可以了。还有一类需求是bug转需求，这些一般是由测试人员发现。测试人员在测出或收集bug的时候，会将这些东西推送到产品经理那里，由产品给出解决方案和排期。还有一些比较复杂的bug，在迭代里做不完，就会转成需求。产品可以有更多的时间进行规划。产品经理和老板也经常会根据系统的规划提出需求，产品和老板会根据自己对用户、业务、当前系统的了解，对系统提出改进和优化。这个时候就会有一些优化的想法，这些也是“需求”。当然，不管是产品还是老板，在提需求的时候都应当实事求是，考虑自己产品的定位和开发的能力。不然的话，只根据自己天马行空的想法来，提出类似“手机主题颜色根据手机壳变化”这种无理需求，很容易被吐槽，也很容易挨打。二、需求的处理需求产生后，需要产品人员去进行处理。接到需求后，不管是大需求还是小需求，产品需要找到提出需求的人，去了解这个问题的前因后果。通常由于开发资源、产品时间的问题，很多需求会来不及做。那么很多需求就会堆积在产品人员这里。如果产品没有对这些需求做好整理和排期的话，很容易遗漏需求，会容易这个需求“永不见天日”，问题就没办法解决。在整理需求的时候，产品人员需要记录需求的模块、页面、提需求的人、需求提出的时间、需求来源、具体问题、排期、优先级等问题。你写的越详细，等过段时间忘了这个需求的时候，看需求记录能够让自己快速回想起该需求的相关内容。实在不行，找到提出这个问题的人，再重新了解一遍就够了。当需求了解得很透彻了，产品经理就需要静下心来思考怎么解决这个问题。如果是小需求的话，产品可以快速地给出解决方案，把这个问题放在最近的迭代里即可。如果是比较复杂的需求，则需要立项，把这个当着一个项目来做了。（可查看以往的文章→产品新人第一次负责项目应该怎么做？）大需求的话，则需要产品画出原型，写好PRD。这个时候“需求”已经变成为“方案”了。此时产品可以邀请业务人员、其他产品进行方案评审，方案评审通过后进行技术评审。这一轮一轮的评审和修改过去后，这个需求已经变成“成熟方案”了。当方案确定后，项目经理要在禅道（需求管理工具）里建项目。而产品则需要在该项目下建任务。禅道里各类角