方法总结：通过历史需求了解一款你将要负责的产品

　　你想象什么，你自己就能成为什么。
　　前不久的一个夜晚，怎么也睡不着，抱着手机打了草稿，现在整理下来。这篇文章要写的主题是，通过项目管理平台的历史需求了解一款你将要负责的产品。
　　展开来说，我们假设一个场景：当你接到一个产品或项目，你之前从未了解它，而从今天开始，它交给你来做，老板只给你了一个项目的共享协作账号，里面有自产品上线以来，所有的产品文档和需求沟通记录，那么，你如何通过历史需求列表了解它，了解到如同自己亲身经历一般，我们就来讨论这个问题。
　　（当然，没有历史需求文档的产品我不管）
　　拿到问题，假设场景，认真思考，开始实践，我们从六个步骤开始循序渐近。
　　第一步：细读历史任务列表
　　通过需求日期或状态筛选，一个字一个字的读，达成你第一步的目标：
　　了解产品的历史；
　　了解产品的总体思路；
　　了解产品运营团队其他人的工作；
　　想象需求提出方与设计者是自己，将自己代入，针对每条历史需求进行思考，提出想法与建议；
　　建立新任务，记录目前未了解到的问题，再进行询问。
　　第二步：根据团队找到适合自己的节奏
　　做产品，权利不重要，只要有owner意识就好啦，每一步都要慢慢来。
　　为了避免被他人带偏，你首先要有自己的工作节奏和流程。
　　这一步我们需要达成的目标：
　　找到适合自己的工作节奏和流程
　　融入团队工作，提高你与团队成员的配合度
　　快乐高效工作
　　现有的产品需求流程不一定和你心中所想的一样，你自己是怎么想的，你想到的适合这个团队吗？
　　或许你可以将自己的想法和团队现有的流程进行融合，就像这样：舍弃所能舍弃的，改变我要改变的。（哈哈，游戏台词）
　　第三步：针对产品进行需求讨论
　　了解了历史需求，你也许会想要有自己的产品规划了，但在这之前，不要着急。
　　你可以抛出你想要解决的几个小问题，放在团队的讨论区（讨论区建议在项目管理平台上创建一个）。
　　举个例子，如果你正在负责一款工具类产品，产品最终目标为引导用户成为年费会员。你觉得现有产品的付费模式不利于年费会员的销售，且你已经发现了历史需求列表中有人提出类似的需求，但由于种种原因，被取消了，你觉得这个需求有必要调整。或者你单纯的就想要改，怎么办？
　　你可以去看看其他产品定价的例子，你可以将付费会员的经典案例放在讨论区，发起一个讨论，比如你找到上海迪士尼的案例：
　　上海迪士尼年卡有三种：
　　周日年卡：1299
　　工作日周日年卡：1599
　　无日期期限年卡：3299
　　工作日周日年卡只比周日年卡多300元，而无日期限制年卡3299元，怎么想都是1599元最划算。因此，用户选择：1599元年卡。
　　那为什么没有周六年卡呢？
　　因为周六来迪士尼人最多，周六生意最好，不需要卖卡，周六卖单日门票最划算。
　　那我就不买年卡，只买单日票呢？
　　那在用户买单日票的时候，迪士尼发一条短信告诉用户，单日票票价可抵用年卡费用。
　　迪士尼单日门票500左右一张，你就会想一家三口加起来的门票也1000多了，年卡才1500多，你心动了，然后迪士尼再告诉你，票价抵扣年卡费用仅当天可用，隔日作废。把不办当成一种损失，把可办限定为当天，你本打算一辈子只来一次，但是只要你办了卡，你就会再来，对存量用户有效激活，提升了客单价。
　　这一步的目标是：发现适合团队的讨论区与学习区，与团队深入交流。
　　需求都需要讨论，但能做的并不多，团队的成长离不开学习氛围的带动。
　　第四步：针对需求讨论与需求历史进行需求规划
　　了解产品的前因后果，建立整体思路与概念。
　　现在你可以规划一些你要做的需求了。
　　第五步：设定需求目标，拆分需求进行落地
　　需求应有目标，目标应对应需求，拆分它们，同时检验需求。
　　综合考虑需求投入成本与检验方式
　　降低需求前期的投入成本，低成本投入得出结论，再进行迭代。
　　举一个年费服务产品购买后，不满意可无条件退款的例子：首先这个需求能够在一定程度上，直接向用户表明了产品所提供的服务经得起推敲，被认为是一个很nice的需求。
　　增加3天内使用不满意可随时退款协议：
　　让用户大胆的尝试，使用我们的产品，提高付费率；
　　如果用户付费后，在3天内申请退款，我们可以要求用户提供原因，我们也可以查看用户使用情况，告知客户不满足退款要求；
　　如果用户过了3天再退款，就更加不在退款保障里了；
　　如果推出这个条例，付费率没有明显增加，我们就关闭这个条例；
　　做的时候，需要制作出申请退款的表单，让付费用户填写。模拟出真实可退款的气氛。
　　如果xx总觉得可以做，我开始描述细节。
　　以上是copy过来的原始需求，只更改了最后一行的两个字“xx”。
　　提出者给了一个重要的需求前提：如果这么做，若不能怎么怎么样，我们就关闭这个条例。
　　我们可以猜想，如果这个需求的退款，降低实现成本变成人工处理会怎么样：增加人工退款通道，由人工客服来询问用户“为什么要退款”，同时增加与用户的一次交互。
　　在购买页面上加一条文案：最后一个购买理由：我们承诺：购买后使用x天内不满意可联系客服xx无条件退款。
　　然而这个需求也有很多不可忽略的细节：
　　退款时长：？天
　　退款方式：原路返回？
　　退款纠纷：退款率并不一定高，也许用户想要退款的时候，他给忘了。他在过了deadline的一分钟后，联系客服，说自己忘了，这种情况也许会出现，但是概率不高；如果出现了，该怎么办？
　　退款与产品付费策略的冲突：如果产品改变付费策略为三个月，一个月，我们的不满意退款保障时间是否需要变化。
　　购买了产品的退款用户，可以重点的运营，找到这些用户，得到反馈并改进。
　　第六步：验收需求与效果，复盘总结
　　原计划随时都有可能改变，如同导航软件。
　　若偏移不多，则进行纠偏；若偏移太多，造成原路返回成本过高，就需要改变基线。
　　不断根据目标规划调整后继续进行。
　　写在最后
　　每一个需求都需要严谨与缜密，需要花很多时间思考细节与流程，细节的程度，是尽量做到滴水不漏。
　　这是最近在工作中的一些思考，写出来想听听大家的建议，文中举的例子有不恰当与杜撰成分在里面，但都是基于现实的改写。