作者从项目实践出发，对OA办公系统中如何发布公告进行了分析复盘，并从多个方面对关于公告的相关概念和功能进行了拆解，与大家分享。
公告是什么是指政府、团体对重大事件当众正式公布，一种行政公文。
它有三大特性：庄重性、广泛性和周知性。
公告和通告区别在严格意义上讲，公告是国家机关对于重大事件决议结果的一种公文告示。
而通告，则是适用于公布社会各有关方面应当遵循或者周知的事项的公文文体。
这样来看，大部分OA中的“公告管理”其实是“通告管理”，但是为了不那么“钻牛角尖”通常会统一叫做“公告管理”，方便直面理解。
在此次OA的公告中，也是将其作为了两种不同的公告样式。
公告的作用简单的四个字“公而告之”。
作为信息化系统，公告是可以作为一种信息数据载体，然后通过“之”限定范围已达到信息输出和反馈的目的。
相对于普通的即时信息，最重要的一点就是它具有庄重性。
公告包含的内容整体上，公告的业务模块就是包含两部分：公告查看公告管理一个业务的构成往往是：一定组织（若干角色），经过一套流程，完成一定的事（处理一定数据载体）公告涉及到角色公告此项业务主要涉及三种角色：公告发布者公告审核者公告接收者公告的基础流程以上三种角色，通过发布公告、审阅查看公告，来完成公告发布查阅这一事务。
部分核心内容公告查看对于公告的查看其实分为两部分：公告接收公告内容查看公告接收中又分为两部分：1.新公告的被动推送提醒 2.主动查看公告提醒其中被动推送提醒，主要是指用户在登录时，收到的系统级公告推送。
一般是在新公告发布时的即时推送，或是用户初始登录，推送离线期间发布的公告。
而主动查看公告提醒，则是用户在相关的门户页，查看到的相关未读公告列表。
一种是“推”式，一种是“拉”式。
公告内容查看是用户主动查看公告的正文内容，并涉及到阅读状态的回执处理。
公告的查看还涉及到两个范围：1.谁能看？2.能看哪些公告？而这些都是由公告管理在制作公告时所决定的。
公告管理管理公告主要管哪些？对于公告管理模块可能管理内容很多，但是当我们聚焦一条公告信息，则主要管理的有三部分：公告正文公告范围公告的已阅情况公告正文就主要是公告的主体信息，包括主题、发布者、正文内容等信息。
在正文部分其实也暗含公告的种类，目前使用较多的为两类：普通公告；红头文件普通公告基本就是由公告正文构成，红头文件种类就比较多了，这里就列举下通用模板：一般会在正文的落款处加盖红章，红章的样式也有很多细目，这里举两种例子：公告范围由 有效时间+公告发布对象构成。
这两者确定了公告接收者的查看公告的核心逻辑：以上的逻辑控制只是决定了“谁能看”，但是对于公告接收者“能看哪些公告”这层业务逻辑没有回答。
“能看哪些公告”主要是关注“能看哪些过期公告”。
例如：一个公告的有效期范围是【2020年1月1日 ~2020年1月3日】，发布对象为【全体】可看。
在1月5日创建了一个新用户，此时该新用户是否可查看此条公告？这是一条不定的业务逻辑，不同的公司业务规则不同，比较理想化的是——在公告管理时就有相关的配置项进行业务规则设定【新用户是否可查看过往公告】，亦或是其他的业务规则设定，这里就不再展开讨论。
当确定了公告范围后，就剩下对于公告已阅情况的管理了。
公告的已阅情况，主要是查看某个公告其接收者的回执。
对于已阅情况的数据处理有两种方案：已阅情况的查看，个人认为是个低频的，所以就废弃了已阅接收表这样的快照,采用了第二种【查看已阅情况时动态组织】的以时间换空间方案。
这样做的好处是节省了保存已阅人员的空间，当然带来的坏处就是过期的公告想回顾历史时无法回顾，只能看到当前的组织结构情况，这项决定的决策点就在于预判企业是“向前看”还是“向后看”。
而且就算有了快照，对于公告来说，在其有效期内若是组织结构发生了变动，而此快照想要精确的变动要素就要追加。
既然采取了以时间换空间的方案，就要想办法优化相关的处理，好在在B端产品中，很多业务场景会常用到组织树的查看，所以可以在这方面进行一定的存储查询优化：当然服务端缓存机制也有若干种类，如redis、服务端内存 等，这里也不再展开讨论，根据公司实际情况暂定一种即可。
其他除了上述的一些公告核心业务处理，还需考虑到公告除了自身本身是个独立业务，它也是信息数据的载体。
除了公告模块自己可以发布公告，其他业务也可以搭载【转为公告】，而此功能仅是用于快捷化填充公告的主体信息。
本文由 @29号同学 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。

（图片来源网络，侵删）