但实际做起来，并不像想象中那么容易，在实际实践的过程中，每个步骤都可能会踩坑。所以这篇文章想把产品自己这3个月踩过的坑总结一下，希望在从0到1搭建后台的细节方面，可以给到大家一些启发，之后如果遇到类似项目，也可以避开我踩过的坑。
一、业务调研环节：多提开放性问题
在业务调研环节，多去提开放性问题，少提封闭性问题。
在开始解释原因之前，我先说明一下什么叫开放说明会性问题和封闭性问题。
“请问这件事情这样做对吗？”对方只能回答“对”或者“不对”，这种问答就是封闭式的问答。
“请问这件事情怎么做？”对方要根据你的问题给出自己的回答，这种问答就是开放式的问答。
为什么要多使用开放性的问题？
如何因为在你对业务并不足够了解的情况下，开放性的问题更容易接近真实情况，封闭性的问题更容易给回答者错误的导向。
在我实际与一位业务同事小A调研的过程中，就发生了这样一件事情：
这一次的调研处于前期，还在梳理业务流程的阶段。业务同事小A为我讲解了她主要的工作流程，简单的概括就是她从销售同事处拿到学生资料，根据学生资料梳理学生上课需求，最适合的老师类型。
因为她的工作主要是梳理学生的需求，所以她说到梳理资料就停下了。我觉得这个流程后应该还有点什么，我问了个问题：你在整理完这些资料后，就会转交给负责老师的同事是吗？
对方回答：是的。
于是我将她的回答记下，把这一条业务流程简单记录为：销售转交资料-梳理资料-转交负责老师的同事。公司
在后台中的体现为：销售在相应页面填写资料，资料会流转到小A处。小A处理完后，点击转交，就会流转到负责老师的同事那边。
但功能上线后，小A找到我说，有部分少数特殊情况的资料，这些资料需要重新梳理一次再转交，现有页面有些字段不符合特殊情况资料，也不能对资料进行驳回。
虽然这部分资料非常少，他们暂时使用线下的方式处理，但我在设计中漏了这一点却是无可厚非的事实。
后面复盘想起来时，我才发现自己当时问的问题给了对方极大的误导性。我的封闭性问题让对方下意识的回答了“是”或者“不是”。
我认为这里更好的问法应该是：你整理完这些资料后，会继续做什么？
所以我们在业务调研的过程中，牢记多去使用开放性问题。
话虽这么说，但是实际操作起来，我们会一不小心忘记，或者习惯性的就使用了封闭性的问题。当我们的访谈进行到30分钟以上时，我们的头脑开始疲惫，就更容易抛出封闭性的问题了。
针对这个情况，我有几个小方法分享给大家，可以更好的帮助大家在业务调研过程中多去使用开放性问题：
- 提前准备大纲。需要提前准备好所有可能需要问到的开放性问题大纲，在不超过大纲的范围内提问。
- 合理安排访谈时间。对于一线岗位控制在30min内，对于重要岗位不超过1h。（数字仅供参考，每个人可以结合自己的实际情况和自己的专注能力判断。)
- 重要的问题往前排。趁自己注意力最集中的时候解决最重要的问题。
二、产品架构搭建环节：遵守版本规划
在完成业务调研后，我正式开始了产品设计的阶段。这个阶段我已经大概胸有成竹，只是需要点几下鼠标把自己心中的规划全部展示出来。
原本以为会顺利度过的这个阶段，在进行的过程中，却总是冒出一些在业务调研过成功程中遗漏的需求，或者业务方过来提出了新的需求。
虽然我已经事先做好了版本规划，很多需求可以放在后续的版本添加，但是业务却说这个急，那个不做很难用，最终逼迫于业务的压力，又添加了一些本不该有的需求。
结果在开发过程中，我一次又一次的被开发叫去，大部分都是同样的这句话：“这个功能别做了吧，和核心功能没什么关联，多做这个可能耽误交付日期。”
我仔细的重新梳理和查看后，的确不得不承认这些“小需求”和核心功能在开发逻辑上不存在强关联性，并且按项目的日期来说，开发需要把核心功能写完，并且改BUG上线，时间确实很赶。
最终我还是同意了将这些需求给砍掉。
虽然被砍掉不影响到最后的交付，但是实实在在的浪费了我很多精力和时间。
项目结束后回顾这个过程，我总结出：一定要事先做好版本规划，并且好好遵守它。
这里的遵守不是说一成不变，是在可能的情况下不要做太大的变动。
有小伙伴想问：道理我都懂，但业务方一定要加这个需求怎么办呢？
经过这次的踩坑，我也总结了3个小方法：
- 将版本规划同步给业务方。完成规划后，必须同步业务方，着重说明会实现什么，不会实现什么，提前给他们一个心理预期。
- 明确拒绝不合理需求。从产品的角度，开发的角度，项目管理的角度等，明确拒绝和MVP版本不符合的需求，并告知对方这样做带来的不好影响。
- 明确告知插需求后果。如果对方仍然坚持，告知对方会引起的工期延误等问题。
一般到第2点，很多业务方成功会放弃了。如果的确走到了第3点，说明业务方的确非常重视相关功能，这时候临时插入需求，相信无论是上级还是协作的开发测试小伙伴都会给予理解。
三、产品细节设计环节：验证产品设计
畅销书《原则》的作者、桥水基金总裁，瑞达里奥说过：“不管你押对的概率有多大，提高你的押对概率始终有价值。”
即使已经对自己的产品设计很有信心了，但对于这类开发量较大，返工成本高的产品，我们进一步提高自己押对的概率还是非常必要的。
验证自己产品设计的方法有很多，比如高保真原型、业务评审会等。
我使用的方法是高保真原型，因为我想直接观察业务的整个使用过程。当然我并不是说大家都要使用这个方法，有其他更方便快速的验证方法，也是可以使用的。
在与业务方进行原型测试的时候，我也发现了几个比较关键的问题。
其中一个比较有代表性的问题是我与一位销售同事在测试的时候发现的。
她坐在我旁边，首先就点击了她十分关心的订单功能，然后选择了创建订单。整个过程都很顺畅，但是正准备点击创建的时候，她却突然皱了皱眉，犹豫着，又盯着页面看了一下，点击了取消，返回订单列表页在查看什么。
没过几秒她转头问我：“这个商品设置货币的地方在哪里？”
我说：“货币默认设置为人民币的。”
她继续说：“有部分商品在海外售卖时，为了方便用户，会支持用户直接用本地货币购买。我们还需要外币。”
接下来我仔细的询问了这些海外售卖的情况，将相关功能补了上去。
如果你也打算使用高保真原型去验证产品设计，这里分享3个小方法给到大家：
- 做出基本交互即可。如果你的时流程间有限，做到基本的交互即可。基本交互的定义是：业务方可以跑完核心业务流程。例如销售需要去创建订单，那么完成入口-点击创建-填写订单信息-发送客户付款即可。其余一些特殊情况可以不做交流程互，例如取消订单、返回上一页面。
- 提前与测试者说明相关情况。有些测试者可能会在意你的想法，所以有问题也没有说。我们需要在开始测试之前就与测试者说明情况，告诉他们这个只是一个初说明稿，需要他们的给出意见方便我们更好的完善。
- 面对面观察测试者的使用情况。因为面对面的观察，测试者的动作和表情都方便我们更好的捕捉，所以最好是能面对面的观察测试者的使用情况。
就算在这一步发现了很多需要修改的地方，我们的修改成本也是相对而言最小的。
四、产品开发环节：只要有修改，就要有review
在进入到开发之后，产品的事情就少很多了。但是开发的过程一般都不会顺顺利利，偶尔会出现召开开发过程中发现的逻辑问题，或者发现某个功能难以实现，需要改功能设计。
当我们在开发过程中对某个功能进行了修改的时候，记得一定要把相关功能的逻辑重新梳公司理一遍，避免因这个功能的修改，而导致了另外一个功能的漏洞。
我自己就曾经在这个坑里狠狠的摔了一跤，那是在开发在做老师申请流程时的发生的事情。
那一天开发突然私聊我，反馈某个功能设计有逻辑问题，需要修改一下。
于是我火速与开发人员、业务拉了个会，确定了新的方案。我将新的方案梳理完成，开转交给开发。
但是当开发把功能完成后，又出现了问题：老师ID生成错误，变成了一道横杠：“–”。
经过我们的排查，发现问题的原因是：原本功能逻辑规定了老师申请时，学校为“必填”。经过上次我们沟通后，确定的新功能逻辑改为了“选填”。
但是与此同时存在的另外一个功能逻辑是：老师申请成功后，ID是根据老师的学校生成的。因为信息的缺失，所以ID无法生成，引发了报错。
于是我只能再次重新梳理，将选填又改回了必填。开发人员也忙活了一个下午处理没有ID的老师数据。
这就是没有将相关功能的逻辑一起重新梳理引发的后果。
所以在这之后，再对功能逻辑修改时，我都会将相关功能仔仔细细的重新梳理一遍。
为了方便每次的检查能够仔细、全面，推荐大家给自己准备一份自检表，自检表需要包含：
- 产品流程是否全面：对产品设计流程的检查，是否足够全面，是否包含特殊流程、逆向流程、异常流程；
- 操作节点是否无断头：对操作节点，交互节点的检查，是否已经形成闭环，是否有流程断头的情况；
- 修改后的文档是否表述精确：不要出现A页面修改了，B页面忘了修改，导致自相矛盾的情说明会况。
除了这3点外，可以根据自己的实际情况再增加需要检查的部分。平时会的做需求的时候最好也养成自检的习惯。
关于如何自检，怎么全面的自检，因篇幅限制，以后我会另外开一篇文章再详细讲。
五、收集反馈环节：驻场业务方观察使开用情况
因为不是每个公司都能提供这个条件，所以我认为这个点有条件的产品去做就好了。如果做不到，也没有太大的影响。
在我负责的后台上线后，陆陆续续业务方管理层就给我反馈了不少信息和优化点，其中当然不乏一些非常有帮助的信息。
但是当我实际去驻场之后，才发现被动的接受对方给来的反馈，是会缺失一些视角的。 因为在对方给你反馈意见的时候，会筛去一些他们主观层面上认为是他们“不会用”才导致的问题，或是筛去一些他们通过“另辟蹊径”解决了的问题。
怎么理解这句话呢？我举一个我实际经历的例子：
在驻场业务方期间，我是直接坐在销售旁边的。有一次对面的销售突然问她旁边的同事：“赠送的课时是不是一起写到总课时里？”
旁边的的同事回答：“对。”
突然出现的陌生字眼“赠送的课时”吸引了我的注意，我问：“什么是赠送的课时？”
对面的销售回答：“我们会根据每位客户的情况，赠送一些课时达到促单的目的。 不过不是每个客户都有，只有部分一次性买很多的才给。”
我突然意识到这里有一个我必须留意的地方，因为我在设计输入订单的时候，并没有设计赠送课时的空格。我继续问：“但是现在没有输入赠送课时的地方，你们现在输入到哪里？”
对方回答：“我们直接写到总课时里。”
从系统的使用来说，这样做也并没有什么问题。但是从公司成本测算的角度来看，赠送和学生购买的课时是应该被区分开来的。
但销售本身是不会站在公司成本角度去考虑的。他们通过输入到总课时内这种“另辟蹊径”的方式解决了问题，就不会继续反馈到给我们。
所以类似这些问题如果不通过现场的观察，可能要很长一段时间才会发现销售进行过这样的操作，并且在发现之后，之前已经产生的历史订单也很难再去追溯其中哪些是赠送课时。
亲自到现场观察的方法对于及时收集使用反馈还是非常有帮助的。如果公司没有类似的流程，只要和上级稍微提一下，相信业务方和上级都非常愿意配合。
对于如何更好的能观察到自己需要的信息，同样分享3个小方法给大家：
- 坐在相关如何方附近。和业务leader商量好，在你驻场期间，安排你坐在相关同事的附近。
- 主动留意业务人员之间的工作交谈。你坐在附近的时候，相关同事就已经会把相关的反馈直接反馈给你了。但是除了说明这以外，还可以主动听一下他们之间的对话。
- 直接观察使用情况。可以和几位好说话的同事商量好，在不影响对方工作的情况下，让你直接观察对方的工作情况。
写在最后
最后总结一下我分享的重点：
- 在业务调研的环节，多产品使用开放性问题，少使用封闭性问题。
- 在产品架构搭建的环节，最好遵守自己的版本规划，不随意增添删改需求。
- 在产品细节设计的环节，最好验证自己的产品设计。
- 在产品开发环节，如果出现功能修改的情况，使用自检表review整个功能逻辑。
- 在收集反馈环节，在可能的条件下，驻场业务方观察使用情况。
这5个重点中，我认为大家最需召开要注意的是：多提开放性问题这一点。因为我们整个产品都是基于业务调研结果设计的，如果在业务调研环节就出了错误，那么后面的产品设计也会无可避免的出现错误。
但作为一个在产品路上不断踩坑，又不断爬起来的人，我也想告诉大家：错误并没有那么可怕。
我和一些刚入会的行不久的产品同学聊天时，发现有些同学工作时会有意避开他们不熟悉的领域。他们说：“这个我没做过，做错了就糟糕了。”
可有谁是生来就全知全能呢？
没人能将每一件事都完成的十全十美，犯错是不可避免的。我曾经听过一位腾讯高级产品开的评审会，他的产品设计也会或多或少的出现纰漏。
我们应该做的是勇敢挑战不熟悉的领域，同时尽量减少自己的错误、和发生错误后总结经验教训。
