Войти сейчас 做 OA 产品快一年了，每次听到“这个功能能不能帮我在 OA 里实现一下？”，心里都会涌上一股复杂的情绪。一边有点慌，怕对方提的需求太离谱；一边又隐隐有点期待，因为每个新想法背后，都藏着同事对系统的依赖，也是给自己的一道新题。
做过的功能渐渐多了，就觉得该停下来沉淀一下，索性趁这个机会，聊聊我平时是怎么规划一个 OA 新功能的。
先把业务吃透，别急着画原型
我习惯把 OA 里的功能先分成两类。一类是面向特定角色的，比如考勤统计。以前考勤专员每月手工算，又累又容易出错，现在系统自动出结果，用户就那几个人，路径非常清晰。另一类是跨角色的，比如招聘管理，从用人部门提需求，到 HR 筛选简历、安排面试，再到面试官填评价，甚至高层偶尔看一眼进度，每个角色的参与程度都不一样。
不管哪种类型，第一步都是钻进业务里，把前因后果搞清楚，知道现在到底卡在哪儿。如果连业务本身都没摸透，做出来的功能大概率会跑偏。
我常用的方法就两个。
第一个是看竞品。拿招聘管理来说，我一开始也按自己的理解列了流程，画了功能结构草图，但毕竟没做过招聘，看问题的视角很窄。后来专门去找了几家已经商业化的头部产品，分析它们的功能结构和背后的使用场景，一下子豁然开朗。能活下来并且跑在前面的产品，肯定有它的道理，要么流程设计足够成熟，要么踩中了用户的真实痛点。偶尔我也会翻翻用户对竞品的评价，看他们最在意什么、吐槽什么，这些信息比闭门造车有用得多。
第二个是用户访谈，这招最直接。如果说看竞品是看别人怎么做菜，那做内部 OA 就是得做出合自己人胃口的菜，得照着内部的口味来调整。面对面聊，永远比隔着屏幕猜需求靠谱。大部分同事其实很愿意聊，因为谁都希望系统能帮自己省点事，OA 用起来顺手，他们日常工作的阻力就小。如果对方一时没空，多约几次就好了，总能聊上。B 端产品角色划分很清楚，像招聘管理这种，我就会分别找用人部门、HR、面试官各聊一两个代表，把不同角色的视角拼起来，业务全景才慢慢浮现出来。
功能设计：从丝线到布料
业务摸透以后，我不会马上动手画原型，而是先画流程图和思维导图，把整个业务流程按角色和操作步骤通通捋出来。这一步很关键，它能帮我理清逻辑，避免后面画原型时漏掉某个环节，导致功能缺胳膊少腿。而且后续跟需求方或开发沟通时，拿着流程图讲，对方也能更快理解整个设计思路。
等流程清晰了，接下来就是怎么排功能优先级的问题。还是以招聘模块为例，角色那么多，每个角色的关注点其实不一样。HR 需要盯全流程，面试官可能只关心今天有几场面试、几点开始、怎么安排自己的工作节奏，至于招聘整体进度，他其实不太在意。那么，能不能把面试官关心的那部分信息单独拎出来，放在他最容易看到的位置？OA 的本质是提效，让不同角色一眼就能找到自己关注的东西，比堆砌一堆功能重要得多。
具体到原型细节的时候，有几个坑我每次都会反复确认。
第一个是权限。不同角色能看什么、能操作什么，数据边界划在哪里，上线后权限怎么维护，这些都要提前规划好。否则等上线后才发现数据泄露或者操作越权，麻烦就大了。
第二个是数据关联。B 端产品功能之间往往环环相扣，比如 A 数据在好几个地方被用到，B 数据改了会连带影响 C，某一步操作完成后又会触发定时任务 D。大模块内部的数据关系要抓牢，跨模块的关联也不能漏掉，不然很容易出现数据对不上的情况。
第三个是特殊情况。用的人多了，总会有出乎意料的情况冒出来。在 B 端产品里，这种特殊情况更可能是边界问题，一旦碰上，流程可能直接卡死，而不是体验好不好的问题。所以，哪怕觉得“这种情况平时不太会发生”，也不能轻易放过，一定要想好对应的处理方案。有些实在拿不准的，还得跟业务部门一起讨论，把处理规则明确下来。
上线只是开始，后面还得盯着
功能上线后，除了常规的迭代和体验优化，我还会特别留意两件事。
一是数据跟状态正不正常。B 端产品里存着大量业务数据，数据和状态跑得对不对，是系统能不能正常运转的底线。有些问题在测试环境很难发现，等跑了一段时间，真实数据慢慢积累起来，才可能暴露出来。所以上线后的一段时间，我会频繁去看相关数据，确认没有异常。
二是那些没考虑到的情况，要及时响应处理。即使前期想得再周全，也全都是基于现有经验，上线后总可能碰到新问题。这时候就得快速跟开发一起想办法，把问题解决掉，不能拖。
说白了，OA 产品规划说到底就三件事：数据要准，运行要稳，帮大家把效率提上去。至于其他花里胡哨的东西，很多时候反而是负担。
