因业务问题，在商贸版后又经历了一次比较大的版本迭代，几近于推倒重来，需求收集时间就接近三四个月，与业务方反复推敲，复又产生许许多多的涉及业务流程的细节，其中艰辛，自不必说。目前项目正处于研发阶段，产品工作大多已完成，遂来进行复盘前期的产品工作，方便时时自省与经验拾取。
一、需求收集：
因公司业务特殊，需求信息的索取几乎来自于公司业务人员，因此在收集过程中多有掣肘，产生过一次大的需求变更，期间更是有大大小小四五次小的需求变更，其原因愚以为是对业务不够全盘了解，之前自认为是对细节了解不够通透，经过这次大的变更后，更深深感觉到对流程依然存在盲区，对其中的业务原因更是缺乏深度了解。因在本项目前多接触的是一些C端产品，曾天真以为对于用户体验来说，不过是样式、交互，页面展示尔尔，而对业务逻辑有所欠缺。接触到此项目后，深深感觉到，产品不仅是一个仅注重页面展示的活计，这样工作就类似于前端或者美工了，产品逻辑才是做产品的根基。而现在这个项目其背后盘根错节的业务逻辑关系，虽复杂至如此，但是也真的为我打开了一扇通往B端产品的大门。
1、如期进行
任何需求的收集皆是有备而来，不可空手盲目问询，这样需求方与用户也不知该如何作答或者答非所问，整理好自己的疑问，并采取循循善诱的方法，指引用户答出自己想了解的内容。
在最初接到要做组合营销业务的时候只是接到上级的指示，要做“组合营销”，那么，何为组合营销？为什么要做组合营销？怎样做组合营销？这些只是草草听到个大体概念，其中的细节，自然要与业务人员详细交流才能明白，但是在交流的过程中，因对项目不甚了解，因此忽略了很多细节，业务人员也无甚考虑，导致后面的二次变更。
初期需求收集完成后，着手做业务流程图、资金流程图，并拿去与业务方与高层领导，确定业务方向，无异议后，着手准备细节：如页面设置、与技术讨论实现问题、与业务人员确定流程中的系数设定、卡壳处业务方案更改，等等等等，不一而足，历时大概两个月左右。
种种细节确定后，业务人员签字需求池进行确定，我方便开始立项、评审、确定里程碑、确定测试里程碑、确定工期。
2、横生变故
本以为能如期完成，新版项目的业务流程细节越来越清晰，在与业务人员的一次交流中，发现忽略了业务人员从未提起的部分细节，而这些细节足以导致我们所做的努力几近于零，于是与业务人员召开紧急会议，商讨最终业务方案，签字确认，才最终完成。于是又是复一轮的立项、评审、确定里程碑、确定测试里程碑、确定工期，延期之事，更不必说。
经验教训：
此次的需求变更在一部分上是业务人员的责任，另一部分则是产品的责任，未能全面、周全的收集到需求，也是产品的失职。追根溯源，因牵扯到多个部门，组织的需求收集会议有部分人员不参加，收集过程中不如业务人员熟悉且考虑周全，自然而然忽略了部分细节，因此吃一堑长一智，一来在后期会议中签到表，二来多与业务人员交流，力求了解更多细节。
网友评论