如何避免被程序员手撕——产品八项自查

   <p>自做产品以来，也经历过几个版本。跟另外一个小伙伴搭档，每个版本基本跟的需求都有一半一半。而我外加一个CMS后台。小步快跑，两个多星期一个版本。工作量大，却也能快速成长，但每次功能需求想半天没问题后，到真正开发时，却总有缺漏。有些很深、有些很细节，有些让人哭笑不得。甚至有些版本兼容问题没想过，到发版后才发现。好在有方案可在API上进行修复，而不需要客户端重新发。</p>    <p>还好开发测试都还好说话，看工作量跟排期能进行规则补充的商量。但有时信息同步不到位，排期又紧，难免会被批。最近一直在思考，功能设计上的缺漏，来来回回那么几种，是否可进行归纳总结，以便日后设计功能时进行自检。由此归纳如下八项功能自检自查项目，望能避免被手撕。</p>    <p>需求- 功能- 交互- 耦合- 数据- 异常- 兼容- 风险，这八项可用来自查。</p>    <p>按照如上介绍的八项自查原则，让我们逐一来看看吧！</p>    <p>一、需求</p>    <p>每个功能需求提出之前，思考比对调研。这时候的功能自查是冒着推翻现有方案重来的风险。所以建议这一步放到产品需求提出的第一步自查。</p>    <p>需求的本质相信大家都有了解。对需求的深挖是有层次的。我们来看那个熟悉的马与车的故事：</p>    <p>很久之前有个年轻人想要去一个较远的地方，他会跟你说他想要一匹更快的马。</p>    <p>但其实际是希望有更快的交通工具，若能给他辆汽车或者发明个飞机，他是不是更开心？</p>    <p>这就深挖了需求？如果他其实是为接一位名医给他父亲看病，那他更深的需求是不是希望有更便捷更完善的医疗体系或私人医生？</p>    <p>如果他父亲生病是因为吃错东西、着凉等等，那么24小时的贴身保姆等需求貌似就是更深的需求。</p>    <p>然而还有更深的事件耦合与需求。</p>    <p>那么问题来了，怎样的需求层面才足够深？</p>    <p>需求，是一类场景下的共性诉求的具体呈现。</p>    <p>我们知道，事物是普遍联系的。每一件事情的发生都不是独立的，而是有其前置条件与偶然因素叠加的。因此，需求的深挖程度我们要把握好度。</p>    <p>是否覆盖目标人群：若一开始那个骚年，是我们的目标用户。满足他更快出行是我们产品定位的话，就不必细化。</p>    <p>出行理由千奇百怪，那么不管每个人出行的原因。把握出行这个场景共性的诉求，就是更快更舒适，那就够了。再细分下去，就超出目标人群，而涉及更喜欢的个体。</p>    <p>是否脱离原有属性：产品的属性是做交通工具，如马车、汽车、飞机。而若按如上故事所述，那就去到医疗领域甚至家政服务业，与原有产品属性是脱节的。</p>    <p>需求深挖是纵向的，如上深度确定后就需要横向选择。比如如上的需求我们挖到更快的交通工具这一层，评估可以了。那么就进行需求方案的选取。</p>    <p>再者，如电商平台，我们可以为用户提供搜索功能，但搜索的关键是让用户更快更准地找到所需。那么个性化推荐系统、分类功效品牌等维度的商品筛选等，就是衍生的方案，可以一起做搭配做或短期内择优来做，就是产品经理要做的第一步自查！</p>    <p>二、功能</p>    <p>确认具体需求点后，需要分两步进行功能自查。</p>    <p>1、基本</p>    <p>更快的马对之前那位小骚年是短期能最快最好地实现的，这是其基础之一。马能跑完他想要去的距离，也是基础功能。而且这马不说拉马车，至少能载得动这个人吧，不能人一上去马就萎了。所以这匹马基本不止是跑得快，还要是活得能载人能长跑。而很多人只想到马跑得快就行，忽略这个场景下，需要满足的其它基础条件。</p>    <p>2、拓展</p>    <p>这匹苦命的马被设定好基础功能后，我们还要想以后是否有其他扩展可能，比如马身上搞个布袋方便以后放东西（即便这次骚年比较急不带什么东西）。预留扩展的好处是显而易见的。比如马在设计时一次性把马鞍麻袋啥的采购好，而下次需要装东西的时候再修修补补啥的就不用专门再去采购这些材料。扩展预留主要关乎成本！</p>    <p>三、交互</p>    <p>界面元素、交互是功能呈现给用户的重要手段。而界面元素由于是偏向固定静态的，所以设计时缺漏的概率不会像交互方面出现的那么高，这里更倾向对交互层面上的自查，如下当不仅限于此：</p>    <p>1、跳转规则</p>    <p>当多个页面间进行逻辑跳转时，规则一定要定义好。之前负责一个搜索的功能，搜索页去到搜索结果页，结果页重新点击搜索框会回到搜索页，而在此时未发生搜索时点击返回是回到原有不清空的搜索结果页还是直接跳出到搜索入口。一定要用流程图画好各种前置条件下的跳转规则才能保证程序开发的无二性，就是其确定性。</p>    <p>2、逆向</p>    <p>上下前后左右进出，这种具有逆向的交互往往我们在PRD中就申明定义了一种而忽略了另外一种相反情况。如某些顶部tab可左右滑动，且其交互是点击只显示一半的tab内容，该tab会弹出至某个位置。而我们习惯性地进行右边tab的描述，而忽略左边的描述。（有些人可能会说这个左右交互一看就知道要一致的嘛，但实际上，你不说，人家不做。你懂的）</p>    <p>3、场景：数量、前置</p>    <p>先说数量，一个模块其中的具体内容数量为1、2、3...各种数量时的情况。比如一个商品展示模块，最多显示四个，那么其获取的数据超出该数量时如何取数据？若小于该数量，页面如何展示排版。若干脆没有数据，该模块是否直接隐藏还是出现不一样的交互控件去进行引流？</p>    <p>再者是前置：进入当前场景的前提条件不同，其显示内容则不同。从不同维度进入到一个商品列表页面，可以从搜索、从分类、从品牌等不同维度进入。其前置场景不同，进入后显示交互的各种样式数据自然不同。</p>    <p>四、耦合</p>    <p>耦合是比较重要的自查点。比如在进行电商产品设计时，可能会对某个商品的展示样式进行修改，直观的，我们会对首页，或者商品列表等进行修改。而若我们还有购物车、设置是个人中心中支持对商品的收藏，那我们是否要考虑各个耦合场景的样式及数据内容同步修改？一个APP中还包括push系统等非直观场景可联想到的，但却有很多层级的耦合关系，所以耦合的场景需要遍历清楚。</p>    <p>另一点就是数据的耦合，这更为普遍。前端展示的数据内容有些是具有逻辑依赖的。如某个价格是通过原价跟折扣进行计算得出的。若要使用该最终价格，进行其他数据计算。而当一段时间后，我们忘记原有的数据逻辑，对原始数据逻辑进行修改，最后就会牵连有耦合的数据。</p>    <p>五、数据</p>    <p>数据能演变的玩法最多，也就有更多的状况。特别是运营后台进行录入，前端进行展示的数据需要反复考虑。</p>    <p>1、默认</p>    <p>如在后台进行某项数据的插入录入时，是否有给定默认值？一方面若默认值设置合适，可以减少运营人员的操作成本。另若运营忽略了该值的输入时，该数值会为空。若给出必填提示，其实质也增加操作成本。而这种情况，设置默认值是更为保险的方式。</p>    <p>2、边界</p>    <p>正常数据的录入，也同时需要进行判断。特别是边界检查。该数值超出合法区间如何处理？该数值填写正确保存成功是否给出提醒。输入超出边界后是情况原有内容还是只给个弹窗提示？</p>    <p>3、异常</p>    <p>若数据输入要求是数字，而此时进行文字的输入会如何？数据在录入时，发生断网、浏览器异常关闭时，数据进行本地草稿保存？不同的异常情况也要根据不同需求程度去进行考量设计！</p>    <p>六、异常</p>    <p>异常的情况不止出现在数据上，在客户端可能发生的情况更为多样。如网络异常导致数据加载失败，用户账号异常导致功能限制，GPS定位失败导致获取地理位置失败等情况。每个功能不仅要考虑顺利的情况，还要考虑各种异常分支，并进行相应的提示说明或跳转等操作。</p>    <p>七、兼容</p>    <p>兼容性问题是优化的重要限制点。有句话说得好“船大难掉头”，一个产品功能多了后，各个功能间的耦合更多。一个改动会涉及方方面面。如前端展示的样式发生改变，那么上线版本需要如何兼容。新版本中一个数据或样式增加，老版本不支持，如何通过接口或其他方式对老版本的新增数据样式进行过滤？或者老版本保留原有规则而新版本使用新规则与接口。</p>    <p>八、风险：落地细节</p>    <p>风险评估是保证项目顺利推进避免出现意外的情况的保障预警。如开发能力无法落实需求？开发时间无法掌控？客户端对后台数据的依赖导致客户端先行而数据跟不上？特别是大公司平台较多，相互依赖也多。跨部门的需求排期若跟进不到位，容易出现需求一直被晾着无法按计划实现。</p>    <p>以上几点是近来对工作的一点小总结。总结点是有优化空间，但真正关键的是如何将上述自查项在具体功能需求中进行自我排查思考。</p>    <p>越来越发现产品经理新手更多需要在执行层面上下工夫。当然不是说在产品战略或规划方面要少思考。而是作为一个新人，其快速融入职场及职业角色的方向应跟偏向落地。需求思考，功能落地，项目跟进，沟通掌控。对于项目来说，都是极为重要的。新手上路，产品不易，且行且总结！</p>    <p> </p>    <p>来自： <a href="/misc/goto?guid=4959671039145371371" rel="nofollow">http://www.pintu360.com/article/60102.html</a></p>