钉钉微应用项目复盘

一、需求背景：

1. 需求场景：
   （1）公司的产品销售以销售专员跟进为主（正价产品单价较高，其他销售途径转化差），部分销售为提升业绩会进行违规操作，损害学员利益给公司带来负面影响。
   （2）为约束销售行为，同时留存日后奖惩和诉讼凭证，亟需一个线上签约工具。同时该应用也能用于公司其他部门发布公示文件。
2. 需求功能点：
   （1）主要用于公司各部门公示通知及文件发布（CMS）。
   （2）员工在用户端可以对特定文章点击确认。
   （3）管理后台可以看到基于每篇文章的全体员工阅读确认情况，同时对未确认的员工发送提醒。

二、产品方案踩坑：

1. 交互设计：
   （1）界面中凡涉及日后可能改动的部分，在满足交互体验的同时，考虑后续更改时的便利性，尽量在原来基础上增删即可，减少推翻重来的可能，增加方案的鲁棒性。
   （原始需求是4个部门，后来越加越多，不得不说设计老哥推翻我把图标放大的做法是明智的。）
   
   （2）任何需要用户操作的按键或功能点一定要有反馈（成功/失败；已操作/未操作），尤其是B端功能性产品，目的是增效降本，尽可能减少用户停留时间，最短路径实现目标操作，（如文章列表页有确认/未确认标识、按钮操作后置灰、Tab加阴影等）
   （3）业务方的核心需求肯定是所有指定人员都对文章点击确认，因此一些强制性的措施必不可少但因为是基于钉钉环境，又不能过于强制而影响员工办公，因此在未读即退出时，弹窗拦截，但坚持退出，依旧可以离开。
   
   （4）数据缺失等特殊情况的下的前端展示，如banner位无数据时自动隐藏banner位、图片未加载时展示本地提示图等。
2. 前端展示逻辑：
   （1）考虑数据边界问题，如文章（视频）列表页单次加载的文章条数，如果只考虑数据量小的情况，后期数据量的增加可能会导致应用卡顿加载出错。
3. 管理后台：
   （1）涉及人员上传的内容，都需要对内容做具体的参数限制（如图片尺寸、格式、大小；视频格式、大小等）B端产品可以在一定程度上牺牲操作人员的交互体验来确保功能的稳定性。
   
   （2）banner位的设置逻辑，banner配图属于稀缺资源，特别是有多个部门共用时，要合理安排灵活的使用方案，尽量做到每个部门都有自己的固定位置，又能在某个部门需求量大时灵活调用剩余资源。
   
   （3）对指定员工发送工作提醒，是个需要衡量的功能点，在充分了解钉钉的开发者文档后，有三种选择：工作通知；添加到相关人员的日称；发送钉邮通知。首先邮件通知力度太小，很多人不登录钉邮，太容易被忽视起不到提醒的作用；而添加到日程又力度太大，容易干扰正常工作（后来领导说就要添加到日程，果然是To B产品手动哈士奇），衡量下选择了工作通知类似于“钉”。

三、小结

1. 产品设计时在充分理解业务方需求后，一定要结合具体业务场景，要求PM本身对公司整体业务布局及组织架构更加深刻理解，从整体的角度来思考解决方案。有些业务方喜欢带着自己的解决方案来提需求，往往考虑的不够全面，业务方永远只负责提出自己的需求，具体的解决方案一定是PM在整体思考后来提出。
2. 那么否决来业务方提出的所谓“方案”必然会让某些业务方（尤其是权限职位比较高）很不爽，这就考验PM个人的沟通协调能力，就不展开说了。值得注意的是：虽说及时与业务方同步进度和问题是不可或缺的，但在方案评审业务方通过后，在开发和测试过程中，除必要情况不要让业务方参与到项目过程中，否则容易出现各种问题。
3. 一个好的产品肯定是具备很强的特殊情况应对能力。前天我妈还跟我吐槽健身房的APP一到预约高峰期就无法登录，我们暂且不说这是因为他们脆弱的服务器还是人为的峰值保护，最起码这种频繁的报错已经让顾客感到极其不爽。但想到的边界情况也绝不是自己一拍脑袋就去落实功能实现的，一定要脚踏实地得结合业务场景并确保整个路径走得通，没有明显的逻辑错误，再反过来衡量功能点的增删必要性。另外还要考虑某种情况出现的概率，如果因为一个低频的特殊情况去增加一个需要动用大量开发资源的功能就如同大炮大蚂蚁，得不偿失。

文中更多是个人忽略的问题的总结，想要了解具体的设计方案及数据获取、权限设定的问题可以私信。