临时需求——产品最讨厌的东西

发布网友发布时间：2023-05-28 04:23

共1个回答

热心网友时间：2024-01-22 16:48

背景介绍：当前正在负责的是一个O2O公司中营销的临时需求的产品。需求主要来自公司运营，和市场部门（线下地推人员）。当前在做的是满足业务随时间变动的临时性需求，产品通常都是一次性的，复用率较低。且公司尚无形成对业务的系统性支持。该产品的方向是，在满足业务临时需求的同时，总结一些常规化的需求模型，进行常规化的研发，更好的响应业务的需求，同事也避免重复性开发的资源成本。

近来临时需求的增多搞得自己昏头转向，时间浪费了很多，却没有很好的解决问题。逢着当前的闲暇，写一下自己的体会，教训。

临时需求对时间的要求会比较严格。所以一旦确定了要做某个东西，整个项目会进入倒排期的流程。从收到来自需求方的需求邮件开始，尽快的整理出需求，梳理出逻辑能为整个项目争取时间。但是就是在这种目的的营销下，容易产生几个问题，具体如下：

•需求了解不清楚。没有形成详细的业务流程图，因为需求方在上海，而我们在北京。所以需求的主要沟通方式是电话或微信，跨城市的沟通很容易产生分歧。简单的说就是你做完了东西，需求方不买账，吃力不讨好。所以，这要求我整理需求的时候务必流程化、图形化，进行邮件确认。把所有的需求都以邮件的方式告知，双方能够很好的避免出现后期扯皮的事情。需要邮件确认的内容包括流程图、功能点、文案、设计图，其中流程图和设计图务必要确认（最受运营重视）。

•需求的分析整理不透彻。这对于没有技术背景的的产品是一个需要历练的过程。一个需求往往不是自己能搞定的——比如我们当前在做的欧洲杯的项目，需要跟4个团队进行沟通协调。这就要求对具体怎么实现，能不能实现有一个清楚的认知。而这些细节在业务流程图中难以体现，最终确定的方案必然是在指定时间内可实现的满足了业务核心需求的双方妥协的产物。这个核心在对对接方有清楚的了解，清楚对方能做到什么，做不到什么，哪些应该他们做，哪些自己应该做。对接过程中最应该明确的是API文档。所以最起码的API文档必然要自己确认可行，才带研发团队进入。不然必然遭吐槽。方案改动的风险也极高。

做临时性需求时，有两点是需要自己时刻考虑的问题。

•临时需求如何体系化。无休止的满足业务需求，而不懂得理解需求的内核，只能是让自己变得很疲惫，没有成就感。所以针对公司业务，抽象大家常规的需求很重要。这要求做的时候考虑是否还会有类似的需求，哪些流程是可以常规化的，哪些是不行的。对业务的理解是一个初步的养成过程，不能一蹴而就。

•临时需求常规化。简单说就是尽可能早的预见到必须要做的临时需求。这主要需要培养需求方，让他们学会提早计划，提早提需求。保证提出需求后有充足的时间考虑，实现。考虑到一般运营的具体运营方案都是以月为单位，所以在具体执行时，在每月的月末发给需求方本月已经做了的事情，索要下个月的业务规划。这样可以很好的保证产品迭代的条理性，不会随便的加入CR。