一次出差的需求之旅
端到端什么意思？
端到端流程是一组有组织的相关活动，共同创造客户价值。
- 流程的重点不是单个工作单元，这些工作单元本身无法为客户完成任何事情，而是关注整个活动组，当这些活动有效地组合在一起时，就会创造出客户重视的结果。客户不在乎我们是否已分配库存或计划交付；客户只关心他是否及时收到了订购的货物。
- 广泛的信息交流是对付企业组织非自然的分隔的一种办法。解决这个问题的办法应该是把被分割成块的活动或流程重新聚合在一起，回到原来的状态。这种做法的另外个名称叫作跨职能一体化。
- 任正非认为，端到端就是解决流程断头的问题。端到端交付，实际上是指端到端的合同交付，以合同为主线，包括项目立项、投标、合同签订、制造／发货／工程准备、工程实施和合同关闭的整个过程。
- 我的理解就是有始有终，管理过程的效率完成，交出高质量的产品。
如何做需求？
年前 刚接到年后要出差这个需求任务，开始有点烦，因为这之前都是别人给需求我来测试，现在我要去做需求，我应该如何下手呢？带着迷茫我踏上了这个旅途。
这一去就是2个月，这2个月我和宝宝分开，爷爷奶奶把宝宝带的挺好的。我也完成任务。这期间还有自己的时间去管理我这走样的身材，给自己立了一个flag20斤。找到了那种自信。
好了不废话了，总结了一下我这次需求的心得。
- 这次做的是本地专题类需求【一次上门1200人天】【智能质检400人天】。
- 过程：
- 前期和客户调研专题类的需求想要实现的目标，我们的产品能提供什么样的能力支撑；--》调研回来需求就要输出一版需求文档的大纲
- 需求人员和本地需求对接了解本地产品总体情况，梳理流程方案，需求专题会落实在哪个流程环节；--》内部串流程输出流程方案
- 需求人员依据现阶段了解到的情况，细化需求文档输出一版；--》细化需求文档
- 现场需求预约客户过需求方案确认主要的功能点；---》依据客户的要求结合实际在细化需求文档
- 研发设计要进行拆工作量，工作量不够要拆补充；--》在细化一版我们的需求文档
上面的过程3,4,5，就是不断的评审过方案细化的过程，然后按时间的节点交给研发研发进入下一里程碑。
【需求分解步骤】
1、在做需求之前有做一个需求预估工作量评估这是要上报客户，然后丰富需求文档，评审的时候还要拆需求工作量
2、需求下来了解整个流程，把这每一个流程都串起来
3、现在的我就是细分需求中的每一个细节 接口还有原型我需要有自己的思想图构造出来。
4、调研之前尽可能的熟悉目前已经存在的系统或者文档，多方明确详细表述 能传达查出来，最后内部评审
5、 需求文档的编辑一般都是总体描述 然后来个原型 字段的一个解释
6、和客户定了方案功能接下来就是对功能点详细的细化，这个过程可以很多次的确认。
【耗时】
拿到需求 300人天 ： 0.5天就调研完 2天写方案 确认讲解0.5天 改0.5天 评估工作量 2小时 客户评审 讲0.5天 150-300人 技术评审 0.5天 二级评审0.5天 耗时一周半
【影响因素】
客户时间的不凑巧
员工的熟练度
原型图不熟悉
人员的对接都是要时间成本
【需求理解的经典案例】
经过这个事情，让我想起项目管理中的一个经典案例，“客户说想要个月亮，怎么办？”
客户说想要什么就要什么，那还得了？客户不是上帝，只不过是财神爷。
需求分析的目的，就是搞清楚客户的真实需求，而不是他张嘴就说的“要什么”。那只是表面现象。
问客户，你要月亮干什么呀？
客户说，我晚上怕黑？
那给你修路灯行不行呀？
客户说，俺家在乡下，没电
那就他给建议，你看，我们公司有个产品，轻便小巧，可以随身携带，能够室内室外全天候使用，一个100块钱，给你打八折优惠，你看怎么样？
OK，10块钱买一个，卖给他就行了。
赚的70元钱，就是需求分析的价值。需求分析不是客户要什么，我们给什么，而是要知道客户在想什么，这样我们才知道做什么。
经常听一些程序员说，某某软件，那么简单，只是增删改查而已，就能卖几十万，肯定是关系户，一脸的不屑。要知道，人家的价值，就是能真正精准的理解用户需求，快速实现预期目标。
技术的确很简单，你也可以做，但在不明晰需求的情况下，做个试试？返工两回，你的成本就超支了，这个时候，你就不会觉得几十万贵了，而会觉得亏。