java 创建日程到期提醒_飞书（Lark）到底好不好用——日程篇

我个人理解飞书的核心思想是期望通过协作来解决企业办公场景下的效率问题，作为飞书重要功能模块之一的日程通过与消息、通讯录、工作应用的深度打通使团队成员间可以高效的规划、组织日程

一、一次艰难的会议组织

小张的梦想是成为一名音乐家，他尤其钟爱古典音乐并对其有深刻和别样的理解，巴赫海顿莫扎特柴可夫斯基这些名字他是如此的熟悉，毕业后的他顺理成章的成为了一名互联网产品经理

最近他们打算做一个查找附近有钱人的功能，经历了三天三夜的挑灯夜战他终于完成了对应的产品文档并通过了组内评审。今天他准备拉上运营、UIUE、开发、测试同学进行正式的需求评审

小张想了一下今天的时间安排，他觉得下午2点半是一个不错的时间。于是他在项目群里分别@了相关人员，“下午2点半K5-F4贝尔会议室进行查找附近有钱人功能的评审，请问大家有空吗？没问题我发会邀了哈”

消息刚发出，屏幕上接连出现了四个“好的”、“收到”，小张的嘴角微微上扬

“我下午2点半有组内review，能否改成4点”Android开发小刘说

“4点其他人都有空吗？”小张捏了一把汗。这次他收到了五个正向回应，他松了一口气

小张看了一下，测试老张还没有回复，于是他又单独@了一下老张。十分钟后还没有任何回音，小张拿起了电话，“张哥，今天下午4点要需求评审你这边有空吗？”，“啊？我今天休年假了，要不明天吧”

…………嗯嗯嗯嗯嗯

二、办公场景下与日程有关的痛点

1. 工作上各种安排太多，重要日程事项容易忘记参与

2. 组织会议活动时组织者不知同事在相应时间段的忙闲状态，安排日程前需要挨个与参与者反复沟通协调时间

3. 组织者统计日程各参与者参与情况与建议新时间情况成本较高

4.参与者反馈参与情况容易导致群内信息刷屏，降低群聊信噪比

5. 项目组内外成员难以直观的了解项目排期进度及重要时间节点

总结一下，对于用户来说在日常办公的场景下，会有重要日程忘记参与、组织会议不方便、项目排期进度同步难等痛点

对于这些痛点可以抽象为提醒、协同、开放三个日程的核心思想

三、飞书的亮点功能

目前市面上不乏优秀的日程类产品， 但这类产品在办公场景下往往由于缺乏关系链很难达到成员间相互协作的层面，大多只能做一个个人待办事项提醒的工具。飞书、钉钉类产品本身自带关系链，在企业通讯录的加持下，日程模块的功能才会有更多的想象空间

1.安排时间

作为会议组织者协调参与者的时间是一件很头疼的事，通过安排时间功能，所有日程参与者的忙闲状态一目了然

安排时间功能可谓飞书日程的亮点功能之一，但该功能顺利使用的前提是团队/项目成员都需要使用飞书来进行日程管理，安排时间功能能极大的提高日程组织者组织会议的效率

2.订阅日程/团队日程

飞书允许用户订阅企业通讯录中成员的日程，订阅成功后可查看该成员的日程安排情况。有了这个功能再约对方聊工作、约面试官面试等就能十分精准的把握被邀请人的时间安排，从而减少不必要的沟通 。钉钉其实也有相似的功能，只是钉钉对于日程所有者是主动的共享，而飞书是被动的订阅

团队日程可以用来记录项目的排期进度及重要时间节点，公开团队日程方便其他成员订阅可以让团队成员实时了解项目的排期进度。但项目排期类日程通常为全天日程，在飞书APP端月视图中，创建跨多天全天日程无拖动连选交互，不如PC端方便

3.一键建立日程群

支持快速创建日程群，一事一议便于后续线上讨论沉淀日程内容。如果之后与飞书的在线文档深度结合，创建日程群后可快速选择创建会议纪要、头脑风暴等在线文档模板，同时文档会自动填充参会人员名单，方便会中讨论及时沉淀，这样的体验是不是会更加的流畅

4.提醒体系

飞书日程的提醒大体可以分为：参与提醒、倒计时提醒、修改提醒、取消提醒四类，其中倒计时提醒采用客户端悬浮窗形式进行提醒，剩下的三种提醒统一采用日程助手BOT通过卡片式消息进行下发

四、对于飞书日程的胡言乱语

1.各种日程提醒(参与提醒、倒计时提醒、修改提醒、取消提醒)的提醒触达方式都依靠Push推送，缺乏短信、电话等强提醒方式

2.创建新日程需上传服务端，但飞书在无网情况下也可在客户端成功创建相关日程。客户端没有等待服务端的返回就直接创建成功，虽然存在重试机制但还是容易引发一系列问题

之前我在做类似功能时也遇到过该问题，关于这个问题有两种处理方式：1.客户端等待服务端返回成功再创建日程，若无网、超时或失败则提示用户创建日程失败  2.客户端不等服务端返回直接创建成功，未成功上传至服务端的日程会被标记待环境允许时触发重试机制

方案1相对比较稳妥，但缺点是无网或服务器异常时会打断用户操作

方案2的风险是用户层面已经感知日程创建成功，但是实际上并未上传至服务端，不会对日程参与者下发日程邀请，同时到达特定时间也不会有任何提醒。虽然定义重新上传机制，但是如果用户在日程开始时也没触发重新上传机制会始终无任何提醒，最终导致用户错过日程

权衡两种方案的收益和成本后不难做出选择，不知对于这个问题还有没有更好的解决方案也欢迎大家与我交流

3.安排时间功能图形界面不准。在日视图下，为保证日程卡片能显示主题信息所以需定义一个最小卡片宽度。即使该日程的持续时间小于30分钟，在图形界面上展示的卡片宽度也和持续30分钟的日程宽度相同。这个逻辑本无问题，但是我们在使用安排时间功能时可能就会出现一点问题

图示创建的“登录会议”日程起止为13:00-13:10，但由于规则限制，实际展示的时间跨度为13:00-13:30。这时我们选择新创建一个13:15-14:00的日程，在图形化界面上视觉的感知与所设置的开始时间是有时间冲突的，但根据实际规则判断是无冲突的

4.企业通讯录联系人选择器存在优化空间。联系人选择器只能按照组织架构来进行选择，不能从群聊中快捷选择成员参与日程，邀请群内成员参加会议这个场景应该不是一个低频的场景

5.尝试与工作应用审批功能数据打通。团队成员在提交请假、出差申请通过审批后则自动为该成员创建相关日程。其他成员在使用安排时间或订阅他人日历功能时可看到该成员在对应时间段为忙碌状态，提高成员日程信息的精准性

五、其它产品的几个有意思的功能

1.钉钉的“催一下”。使用钉钉创建日程后，日程组织者可以一键再次提醒未查看、未响应该日程的参与者

2.钉钉倒计时提醒悬浮窗的时间原本是写死的，固定展示为15分钟、30分钟……近期版本更新后，倒计时时间变为动态可变

3.谷歌日历的建议新时间。谷歌日历允许日程参与者通过日程功能直接建议新的日程时间，建议新时间时也能查看其它参与者的日程忙闲情况

4.云之家的委托。参与者收到会议邀请后除了可以选择参加或不参加还可以选择委托其他成员参加会议

六、一周的第一天应该是周几

分享一个我在做日程一期版本时遇到的一个有趣的问题

一般来说一周七天有两种排序方式，从周一到周日或从周日到周六，到底哪种排序方式更优呢，我查阅了一下资料

在不同地区，一星期的开始时间并不完全一致。英语国家、犹太教和日本一般认为一个星期开始于星期日。埃及人的一星期是从星期六开始的。多数欧洲国家都以星期一为一星期的第一天。而中国习惯上也认为星期一是开始时间。越来越多的英文(或美式英文)字典也开始以星期一定义为一星期的第一天，否则周末 (weekend) 这个字就很难说得通。从宗教的观点来看，圣经中认为，上帝用六天创造世界万物，在第七天休息，这七天是从星期日开始的，第七天是星期六，所以犹太教以星期六为安息日；基督教因为耶稣是在星期日复活的，所以将礼拜日改为星期日；伊斯兰教认为真主在第六天完成创造工作，这一天应该庆祝，所以将星期五定为重大礼拜的主日。但无论如何，国际标准 ISO 8601 已将星期一定为一星期的第一天

回到问题上来，似乎按照这种解释第一天默认为周一比较合理(我个人也比较倾向该方案)。但是手机系统日历几乎全部都是按照周日至周六的顺序进行排列，大多用户已经习惯这种排列方式(简单的用户调研也证实了该点)，用户已有相关认知。综合考虑，当时日程一期版本采用周日至周六的顺序进行排列，后续计划会允许用户自由设置日历一周的开始时间(周一、周六、周日)

Last. 最近看到钉钉不断发力校园市场以及阿里推出“Real如我”瞄准校园社交，我一直觉得校园社交的点在于“B”，下次想重点闲聊下这方面的内容，拜~