每一次的功能更新 ， 产品经理总会期待获得用户的肯定 。这就要求在每一个新功能上线之前，产品经理需要做好规划 。本文作者以OA系统新功能规划为例，对功能迭代的需要注意的关键步骤和问题进行了总结~
文章插图
“Hi，我想在把这个功能放在OA上，能实现吗？”每次听到这句话，都会夹杂着又害怕又期待的复杂情绪 。你不知道同事们可能提出什么五花八门的想法，而每一个新需求，是他们对你的认可和期待，也是对自己的挑战 。
做OA产品快1年，是时候对自己进行复盘，那么就来聊聊 ， 笔者是如何规划OA的新功能的吧 。
一、熟悉业务 ， 了解需求 OA上的功能 ， 笔者个人习惯分成2种 。
一是功能使用对象为特定人群，比如具体出勤统计，使用对象为考勤专员，由人为统计每个月的出勤情况转为OA自动统计 。
二是涉及到多种角色的功能，比如招聘管理 ， 这里面涉及到的主要人员有用人部门、招聘hr、面试官、高层，每个角色在这个业务里均有不同程度的参与 。
文章插图
与所有产品规划一样，OA第一步也是熟悉业务，了解业务的前因后果与症结 ， 才知道要如何下手 。笔者最常用的是以下2个方式 。
1. 参考竞品 拿招聘管理举例，笔者在开始时按照自己的了解，罗列了招聘的流程，初步规划了功能结构，但毕竟自己的角度是单一的，在没接触过招聘行业的情况下，视线非常局限 。
参考市面上已经商业化的产品是一个很好的方式 ， 找到头部产品，去分析他们的功能结构、使用场景，可以让自己更全面的了解业务 。能够商业化的产品 ， 是经过市场考验的较为成熟的 ， 头部之所以能站在顶端，也必然有其优势 。
同样，善用搜索，可以通过一些平台找到竞品的评价，进一步确认用户的关注点 。
2. 用户访谈 如果把规划需求比为做菜，那么参考竞品就是知道别人的菜谱；而做内部OA系统就是把这道菜做的符合自己的口味，需要去掉自己不喜欢的食材，对自己的口味进行配比 。
还有什么比面对面聊天更能了解用户需求呢？直接找对应人员聊呀！
大家都想通过系统取代繁琐的工作，提高效率，且OA使用频率高，功能设计会直接影响到自己的日常使用体验，所以同事们对于访谈都比较积极 。对方没有时间的话，多约几次总能约到的！
B端功能的角色分类较为分明，比如前述招聘管理中的几个角色 。所以最好各个角色都找代表进行访谈 。
文章插图
二、功能设计 1. 画流程图、思维导图 把业务以流程图的形式画出来，罗列每个流程对应的角色和功能 。这样能够帮助自己捋顺逻辑，并且在设计具体原型时不会歪掉重心，不遗漏功能 。后续跟需求方、开发过需求时，也可以协助讲解，让听众更好理解原型设计 。
2. 思考角色的关注点、功能的排部 在完成前一步后，要做什么功能、功能之间的跳转逻辑心里已经有数了，现在是功能如何排部的问题 。
这里可以从角色、从场景出发 。
还是拿招聘模块举例，这里面涉及了那么多角色 ， 每个角色的关注点并不一致 。hr关注整个流程 ， 而面试官很可能只负责面试考察候选人的水平，他关注的是今天我有多少个面试安排，在什么时间，我要如何规划今天的工作，至于招聘进度结果如何，面试官并不关心 。那么面试官涉及到的部分 ， 是否可以抽出来做一个突出呢？
OA的目的是提升效率，需要让不同角色更轻松的看到自己关注的部分 。
3. 确定具体细节 到这里，产品原型的设计已经大致成型了，但是细节不能被忽视，以下方面的问题需要过一遍：
1）考虑不同角色的操作权限和数据查看范围，是否需要做对应的权限规划 ， 权限规划是否变更，上线后要如何进行维护；
2）考虑功能、数据之间的关联 。B端产品功能之间更加环环相扣，说几个常见的情况：A数据同时用在多个地方，影响着多个功能；B数据变化了会影响C数据的变化；D操作完成后要触发定时任务E 。大模块内的数据关系容易记住，模块与模块之间的关联也不要遗漏；
3）考虑特殊情况 。使用人数多了，总会有特殊情况 ， 在B端产品 ， 特殊情况更多是边界情况 ， 会导致流程无法继续进行 ， 而不是体验不佳可以适当兼容 。所有能想到的问题，不要带着“大家正常不会这样做”的态度去无视，必须想好对应的处理方案 ， 这部分可能还会需要跟需求部门一定讨论特殊情况的处理规则 。
文章插图
三、上线后的跟进、迭代 发布上线后，除常规的功能迭代、体验优化外，笔者还会特别关注以下2个方面：
1. 数据、状态是否正常 B端产品存储了大量的业务信息，数据、状态无误是OA正常运行的基础，有些问题在测试时并不能完全发现 。
2. 未考虑到的情况并及时回复处理【内部OA系统功能迭代怎么做 oa系统功能简介】 产品规划时需要尽可能考虑到各种情况，然所有的考虑都是基于已有的经验，上线后也许会遇到新的问题，这需要pm和开发能够及时应对处理 。
