从一个推送配置模块的设计到交付，步步拆解，总结一套方法

1、当我们没有能力制定产品战略规划时，我们应该如何开展产品碎片化的思想，不仅完成任务，而且提高自己？1.在工作的恶性循环中，一些新产品会觉得自己所做的事情缺乏挑战性，没有改进的空间。我所做的无非是根据领导和业务人员的要求画一个原型，增加几个参数来修改功能、配置功能和导出功能，缺乏积极的思考，或者认为这个功能再好也没用。在熟悉业务和团队开发人员后，他们可能会开始划水，或者花时间在项目管理或开发框架等其他事情上，希望跳槽加薪。不认真的态度不能取得优异的成绩，没有晋升的机会，仍然陷入初级琐碎的功能设计。2.工作的良性循环。当我们在具体的工作事项中问更多的问题时，我们不仅可以帮助我们更深入地了解业务，还可以更好地完成任务。与研发学生不同，产品的技能有特定的语言或框架。如果你告诉面试官你有良好的表达能力和强大的逻辑思维能力，人们仍然认为你一无所有。对于面试来说，过去的结果是最好的证明。因此，与其不认真工作，加上一点似有似无的理论知识学习，不如认真工作，不断复习总结。即使得不到亮眼的数据结果，也能沉淀出自己的方法论，就像我此刻在做的一样。接下来，我将从推送配置模块的设计到交付，逐步拆解，总结一套方法，希望能对读者有所帮助。5W2H法则：WHAT——是什么？目的是什么？做什么工作？WHY——为什么要这样做？能不能不做？WHO——由谁来做？WHEN——何时？什么时候做？什么时候最合适？WHERE——何处？在哪里做？HOW——怎么做？如何提高效率？如何实施？方法是什么？HOWMUCH——多少？到什么程度？2、了解需求：决定做什么，为什么在我们有能力做产品规划之前，需求总是由业务人员或领导提出。刚开始只是一句话:“需要做推送配置，不同渠道的用户需要看到不同的续费页面”。5W2H是从需求导入到功能输出全过程的指导规则。在理解需求的阶段，我们应该关注为什么要这样做，目的是什么。经过几次询问，我了解到我们有几个客户，他们购买了我们运营的流量卡，所以他们需要在自己开发的应用程序上有一个充值流量包，当流量服务到期或不足时需要相应的提醒，以提高更新率。提高续费率对我们公司和客户都有好处，因为我们的商业模式是按照续费套餐给客户一定的回扣。我将这些需求分为以下类型：1。痛点需求1）给流量包充电2）在相应的场景中提醒2。衍生需求信息埋藏点和数据分析3。规划需求1）个性化充电页面2）提醒个性化配置3。列出实现计划：确定如何做，我们不设定目标，然后设定计划；但讨论计划，并不断调整我们的目标，最后得出最好的解决方案。为什么呢？为什么？目标可以是长期的，也可以是短期的。我们都希望用一个长期的解决方案来解决当前的问题，但未来并不真实。很难说你现在制定的所谓长期计划在未来仍然可以闪耀。长期计划往往复杂程度高，此时就要选择了。实现的方案和应该达到的效果就像跷跷板的两端。我们不断推断权衡，使其达到平衡状态。此时，我们选择了性价比最高的方案。我的领导也给出了一句快速决策的金句:“如果你能做或不做业务需求，那就不要做；如果你能做或不做技术需求，那就做吧。“他只是考虑到市场的变化，今天的销售人员说他想要这个，也许还有其他的，当你不确定的时候，不要这样做。但技术问题，如服务器访问能力、架构优化等，如果不优化，就会埋下隐患，问题迟早会爆发。话说回来，这个推送配置模块该怎么办？1.关于账户系统建设1)计划启动运营平台账户系统，并与业务平台进行映射，推送配置作为运营功能，有利于加强运营平台的综合运营服务能力。2)方案二启用业务平台账号，业务平台采用树形结构。目前一个账号对应一个树节点，接口调用范围不够灵活。如果未来对外界面需要统一的账号调用，其工作量仍小于运营平台。与R&D负责人讨论的结论是，两个账户系统都不采用，后台有两个开放接口，一个是我提到的业务平台开放接口，已经重新投入使用；一个是在研究，还没有开放，很难合并，以后也不用合并。同一个客户提供两个账户调用我们的接口显然是不合理的，但我们可以使两个账户完全相同，客户不会觉得他实际上是两个调用的平台。我们暂时称一个需要调用我们接口获取推送服务的客户为“推送客户”，那么在建立新的推送客户时，他能获得的信息范围是什么呢？这里还有两个解决方案：改变业务平台的账户范围，选择新业务平台建立的账户，记录其范围；直接选择业务平台的用户树，圈定其范围。方案1的一个显著问题是，如果账户的范围在业务平台上修改，运营平台是否应该同步。不同步是不合理的，同步太难，所以在新推送客户时选择方案1。2.关于账户配置1)方案一账户列表和配置项放置在同一页面，缺点是不利于b端客户调整配置(但目前没有这样的需求，都是我们操作的)。2)方案二账号列表仅用于管理和权限配置；将推送配置放置在另一页，B端客户可以登录平台进行配置。缺点是我们的员工如何配置B端客户？要不要登录客户的账号？事实上，这并不是不可能的。在开始时给出默认值。讨论结论：早期客户没有配置需求，最终运营由我公司控制，未来太远，不真实，最终决定采用方案1。3.对于开放接口，麦联宝有一套API接口，还包括几种推送配置（扫描二维码续订、状态变化、机卡分离、实名推送），配置项目应统一管理；外部接口是否全部在一起，使我们的客户与我们的任何产品连接都是相同的账户密钥。讨论结论：与“关于账户系统建设”一样，做到形似，不强求合并。不合并的缺点是对外界给出的接口调用账户没有统一管理；API没有统一规范管理。4、与产品的关系：确定在哪里做，谁来做，从业务的角度来看，属于流量业务；从属性的角度来看，它具有操作属性。在我公司，既有业务平台，也有综合运营平台。哪里更适合放？这取决于我们用什么方案来实现？使用什么方案取决于我们想要做什么。1.我们首先要做的是什么程度？在前一章的讨论中，我们决定未来不一定会合并公司的所有开放接口，这次我们不需要考虑向用户开放账户进行配置。2.其次，该功能是偏业务还是偏运营？到期提醒、减速提醒等原本是按照默认规则写的，不能支持自定义。这些会更注重操作，关键是什么时候发送。发送什么内容？发送几次？3.最后，该功能在业务平台上可以重用多少东西，在实现需求的同时可以减少开发？已经提供了一套可以嵌入APP的充值H5页面。但从用户使用的角度来看，假设小爱扬声器不能连接wifi，有一张流量卡需要购买流量套餐。所以在APP中可以完全不提流量卡，只说为设备购买流量服务，有一个流量充值入口。原页面进来看当前流量卡的套餐和使用细节，点击另一个按钮续费。然后我们可以让用户直接到达充值页面，流量卡的细节放在二级，也就是说原来的H5页面不是很完美。从与技术的讨论中了解到，业务平台的账户系统对未来接口合并没有帮助。在这种情况下，它将被放置在操作平台上。五、梳理具体功能清单:确定具体做什么，这一步确定如何做后方案细化，具体做什么以原型和文档的形式固定。列出了功能清单，思路已经很清晰了，剩下的就是画原型，写需求文档，Axure大师两个小时就画完了。6、优先考虑需求：当决定何时成为需求提出者时，通常会有一个预期的交付时间。有些人说得越快越好。心里忍不住生气:越快越好？是多快？24小时加班够快吗？需求方从自己的角度给出了预期的时间，但R&D资源相当于公共基础资源，R&D资源总是稀缺，除非是特别大有钱的公司。优先级很重要，可以让他们一直忙于公司最重要的事情。设置优先级后，就知道什么时候做了；再估计工期，就知道什么时候可以交付了。需求方问你，心里就不慌了。7.总结5W2H原则广泛应用于各行各业，但在产品行业，我认为他的几个问题的顺序可以稍微调整一下:问what、why了解需求：需求方的最终目的是什么？这种需求是做什么的？问how、制定方案：展示方案和最期待的目标，将两者放在跷跷板上，不断调整，选择性价比最高的方案。通过询问where来揭示它与现有产品的关系，从而确定who：当公司既有业务平台又有运营平台时，可以通过连续三次询问来确定产品的需求。通过询问when来确定需求优先级：从公司的战略层面来确定优先级，我们知道什么时候才能开始。