Bear的产品迷途——一个有关线下活动的H5

用于推广线下活动用的H5项目（需将搬运数据）——一次失败的经历

---

作为内嵌到公众号中的一个H5项目。Bear将这个项目简称为“V推广1.0”。

项目概况介绍

该项目前期先开发1.0版本，为2.0版本做铺垫。接下来进入对该项目的回顾，项目在Bear接触时已经有了一个大概的项目建设方案，但是随着进一步的交流和沟通，发现方案中并不完全符合合作方的设想。于是对方案进行了新的修改，此时产品原型已经完成了一部分了，算是前期的需求变更吧（虽然导致了Bear加了半个通宵的班，没有钱的那种T_T）。项目具体内容如导图所示：

页面设置和功能点的思维导图

线上活动状态和用户使用流程图如下：

活动报名流程图

在一切看上去完美的情况下，项目进入了开发。这时，问题开始逐步突显出来。具体大致为：来自合作方的不合理需求添加；来自合作方的设计偏差大；来自公司内部的员工离职；来自公司内部的开发人员自己寻找其他开发人员帮忙而不让Bear插手管理（新手被瞧不起，哈哈）；来自沟通交流的不及时（Bear的锅）；

数据搬运中的问题（解决）

这个产品是内嵌在合作方一个常用的公众号中，由于合作方想利用这个项目将其他平台的用户导流到这个公众号中，所以，有了标题说的搬运数据的内容，实际情况有三个途径的数据需要搬运。

1.和另外的公司（管理其他平台）进行沟通交流然后拿到数据接口；

2.合作方本公司原公众号项目客户数据；

3.合作方要求导入的新用户。

其中，用户数据的字段有许多差异，比如：数据1没有邮箱字段而实际需要的数据中有。由于需要给老用户（数据里有的）打上标签，所以这是一个棘手的问题。所以先罗列出三个数据来源中相同的字段，并从这些字段提出一个最重要的字段，比如手机号码，身份证号码等。然后进行匹配打上“老用户”的标签。为了形成统一数据，将不必要的数据去除掉，然后将不完整的，必须的数据字段加入到产品用户补充的身份资料部分。用这样的方法来达到数据的对应统一。

失败的由来

1.各种不确定和“先这样做吧”。在这个项目中出现的最可怕的问题就是合作方对一些内容是否真正要做并不确定。这导致了项目进程中有许多的更改，比如合作方出的设计和原型大相庭径，数据所需字段具体为哪些等等。也许也是Bear太年轻了，不知道如何拒绝更改，但是这也让Bear清楚的认识到，一个项目下来，所有的不确定和不清楚都是之后的隐患，即使开发过程不发作，交付过程也会让人窒息。

2.沟通交流问题。和同事以及合作方沟通的时候，注意理解的具体事项是否一致。在项目复杂的情况下必须做好相应的记录并进行项目进度更新。比如，“注册时只需要识别手机号码就可以了”这句话是否等于“注册时只需要填写手机号就可以了”，“这些数据不需要了”这样的意思是“不需要使用了，但是还要保存好”还是说“不需要了，可以删了，避免从后台看数据时候的冗余”。

3.内部协调问题。一个项目下来人员的调动和协调必须牢牢把握好，必要时还是用文档记录下来。接触了那么多项目以后，Bear认为产品的文档必须要有条理性和分类，别只是注意传统意义上的文档。确认一件事情有时候文档比语言更有可信度。这是题外话，我们回归主题，在项目吃紧的时候，必须强调人员负责的工作要对应好相应的内容，以至于拼凑起来之后是一个完整的产品。Bear当时没注意（知道这回事，但开发人员觉得没必要Bear进行管理），项目直属的开发人员找了其他同事帮忙开发，自己将项目需要完成的内容分为几个部分派发到别人手中，由于其他开发人员对需求理解不全面，结果使得部分产品功能反复的修改，引起了内部怨声四起。

4.需求变更。其实每个项目基本都会有大大小小的需变问题发生，但是， 这次的变更很是过分。从设计比原型多出了4-6个功能到banner图的跳转活动变更成多种跳转方式。一系列匪夷所思的变更和体验越改越差的情况下，通宵熬夜成为了日常。

总结

作为产品小白，Bear真的会乱套。这次经历让Bear知道了产品应该具备清晰的逻辑和淡定的心理，也理解了真正意义上的沟通确认的重要性。每件事情都是欲速则不达的，项目如同需求，需要冷静的分析才能最高效率的完成。所以，不能总把注意力放在一些拖时间却不可控的事情上，假如事情不能如约按照制定的进度“甘特图”走。那么，项目的拖延可能已是必然，这时需要解决的是确认自己团队做的事情并没有错而且不用进行大量的修改。

Bear想着从乱套的内容中拾荒，重塑自己的知识体系，继续奔跑！