阿里巴巴「防疫精灵」的敏捷开发实战

本文涉及的产品
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
注册配置 MSE Nacos/ZooKeeper,182元/月
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
简介:

以始为终,从心出发。

2020.01.26 09:30

正月初二,伴随着疫情的进一步蔓延,我观察到钉钉群内不时有人在询问当前疫情状态。联想到之前产品运营时使用过的阿里云 Dataworks 「机器人工厂」产品,迅速搭建了一个简易问答机器人,产品功能很简单,3个问答:疫情指数、线上问诊、每日打卡,疫情指数来源于丁香园,由我手动输入。

1

机器人完成后,我首先投放在了内部团队群,得到了大家的一致肯定。同时,我搜索到 GitHub 上已有相关的开源疫情数据 API 可供调用,联想到阿里云 IoT Studio 便捷的服务开发功能,因此迅速完成了接口的封装,同步实现了疫情监控推送钉钉机器人。
2

定时推送及自动问答功能实现后,我做了第一个产品决策:
整合隔离宝及疫情监控为一个机器人,同时在同事的建议下,更名为「防疫宝」。

当然最重要的,一个简洁大方的 ICON 必不可少,于是 UED 加入,很快输出了一个酷炫霸气的 ICON:

3

(PS:这个ICON一直沿用到了对外版)

简单调试后,机器人就正式部署至内部部门群中,就这样,防疫宝的种子用户诞生了。此时:

团队人数:3
产品阶段:PoC
用户数:3个内部群
我们对用户规模的预期:先等等看,可能也没那么多需求

简短的雀跃之后,我们马上思考下一步的目标,能否部署到更多的内部群,服务更多的阿里人?要实现这个目的,产品上需要完成几步优化:

1、数据源剔除三方接口依赖,并且监控和降级策略;
2、机器人工厂是内网服务,Studio是公网服务,需要开发网关接口实现对接;
3、更多一方内容和问答知识库的搭建。

2020.01.26 19:00 - 2020.01.27 01:30

我和貔阁都有一定的开发经验,但是面对这波真实的技术需求,在我们努力尝试多次后,很快敲定了当日的第 2 个决策:

引入开发支持,迅速完成接口替换和对接。

在各同事的推广支持下,防疫宝拓展到了 27 个内部群,其中部分单群人数超过 10000。此时:

团队人数:6
产品阶段:version 1.0.0
用户数:27个内部群,2万阿里人
更新日志:
功能迭代:

1、疫情详情跳转链接至「阿里健康」详情页
2、每日疫情推送由手动推送变更为定时推送,由 IoT Studio 实现
3、定时推送内容更改为高级回应( FeedCard )

产品运营:
1、机器人配置视频教程
2、Webhook 用 Excel 收集,并且对推送时间进行规格化,只允许两小时一次&一天一次(定制化需求收敛)。

2020.01.27 9:00 - 2020.01.28 00:30

在集团 OC 的助力下,防疫宝开始大规模推广,表格里的钉钉群数上升到了 100+,大家感到纯人肉的配置指导有些吃不消了。简短的电话会之后,我们联系到了钉钉的技术同学,在他们的协助下,完成了官方机器人的上架,进一步缩短了配置时间,为接下来的用户规模拓展奠定了基础。此时:

团队人数:6
产品阶段:version 2.0.0
用户数:100个内部群,6万阿里人
更新日志:
功能迭代:

1、疫情详情数据接口替换为「阿里健康」。
2、IoT Studio 发布“防疫宝”模板+疫情通报节点。

4

3、阿里巴巴内部官方机器人上架

##2020.01.28 09:00 - 2020.01.30 00:30

伴随着接入群数的不断增长,我们的压力也越来越大,作为传达疫情的第一线,稍有差池,将产生巨大的连锁反应。此后,防疫宝交由集团统筹管理。此时:

团队人数:6
产品阶段:version 2.0.0
用户数:阿里集团内100个内部群
更新日志:
功能迭代:

1、调整Studio推送频率
2、知识库完善

(插曲)01.31 01:30

大年初三开始,我就偶有咳嗽+腹泻,同时伴随头晕,一直持续到 31 日。对比新冠肺炎症状,我顶着强大的心理压力和交叉感染的风险,连夜前往了当地医院。

万幸,最终确诊病毒性感冒+突发性高血压,感谢防疫宝护体,躲过一劫,回到家的我已然筋疲力尽,瘫倒在床,防疫宝该咋办?
5

2020.01.31 09:00 -2020.02.01 00:30

我将生病的情况告知了团队,虽然难舍,但是很遗憾,至少今日我无法与团队并肩作战。很快又一位老朋友测试开发加入,接手了机器人工厂相关的优化工作。尽管对内的产品已经交给了其他团队,但是,我们的下一站早已明确:

走出阿里,服务企业。

产品转为对外,一系列替代需求接踵而来,打卡等链接都需要和外部服务进行对接。同时考虑到钉钉的用户量,水位控制和高并发的处理迫在眉睫。团队及时在晚间发布灰度版本。此时:

团队人数:8
产品阶段:version 2.1.0
用户数:10+外部企业群
更新日志:
功能迭代:

1、机器人工厂知识库自动学习训练
2、疫情趋势截图替换为 IoT Studio 原生组件

2020.02.01 09:00 - 2020.02.02 0:00

压测,调试,压测,调试……无限的循环中,团队终于完成了所有产品对外发布的工作。考虑到配置接入咨询工作量,又引入了钉钉客服小蜜。同时,对外版更名为「防疫精灵」。

2020 年 02 月 01 日 15:00 ,防疫精灵正式对外发布了:

6

上线短短 1 小时,接入群数已经破 1000 ;截至 24:00,发布 9 个小时,已有 4124 个企业群接入「防疫精灵」。截至 2020 年 2 月 13 日,已有 15W 钉钉群接入「防疫精灵」,累计触达人数超 500万,累计添加机器人 145836 个。我相信伴随着远程办公的铺开,还将有更多的企业和师生得到小精灵的陪伴。

小结

回望这段既平凡又伟大的旅程,长篇赘述的方法论显然不合时宜,因此我选择用纪实重现每分每秒,希望大家能看到每个人心中的「哈姆雷特」。

有别于传统瀑布流产品设计开发流程,「防疫宝」全程没有一份 PRD ,团队 8 人分别位于祖国的 8 个城市,所有需求都以钉钉远程电话会沟通后敲定的聊天记录为准,随时迎接动态调整。但是在永恒的变化下,每天的工作始终由明确不变的目标驱动,诸如 toAli 到 toB 的决策都非常果断,没有人有任何异议。

一直以来,我经常听到「敏捷开发难为」的噪声,历经数个产品,在 toG&toB 业务的「敏捷开发」之路上我一直在探索,几点感悟,发自肺腑:

1、不到关键时候不轻易动用开发资源,一旦用,承担责任和风险:我们的技术无所不能,也因此,保持敬畏之心,技术同学不应该为每一个小想法买单;
2、把后背交给团队,相信每一位伙伴:持续一周的开发过程中,产品经理、项目经理、运营都相继生病短暂离开,但是产品进度没有受到任何影响,大家都非常快速完成补位;
3、充分利用集团资源,借力而为:从阿里云到钉钉,再到阿里健康,防疫宝离不开每一个集团伙伴的支持,尽早明确团队、产品和BU的能力边界,积极借力,协同共赢;
4、对内部产品保持充分的熟悉度,不要让对产品的认知禁锢了想象力。如果当初我仅从本部门的产品出发,防疫精灵是不可能诞生的;
5、掌握一定开发知识,不求替代开发,但是至少能独立完成PoC:比画原型更高效的,是做出原型;
6、不忘初心,敢梦敢做:永远不要忘记产品的初衷,不要让KPI等所谓的数字扰乱自己的心,伴随产品生命周期演进,动态调整产品目标;
7、适时储备运营推广物料:产品经理始终是产品的一号位,前期给运营足够的支撑,lead 种子用户的拓展
8、时时回头看看:喧闹与激情过后,想想 why us and how?

全民抗疫,共克时艰,新型冠状病毒的防疫已经到关键时刻。 2 月 3 日,阿里云对外宣布,即日起至今年 6 月,为了支援抗疫,同时支持前线智慧医疗,对全球医疗检测类设备免费开放了接入物联网平台能力,扫码详细咨询:

lALPDgQ9rqYjCbzNAXjNAXw_380_376_png_620x10000q90g

作者信息:
陈欣澜,花名墨澜,现任职阿里云智能 AIoT 事业部高级产品经理 ,主要负责智慧城管、智慧消防等物联网智慧城市产品与解决方案策划,致力于物联网产品创新工作与技术公益活动。

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
相关文章
这一招,让ppt、word中的字体到别的电脑上也不变样儿!
今天,不坑老师就教大家一招儿,让你的PPT、Word、Excel文档里面花里糊哨的字体、样式在别人电脑中也能正常展示。
778 0
|
10月前
|
机器学习/深度学习 自然语言处理 监控
探索深度学习在自然语言处理中的应用与挑战
本文深入分析了深度学习技术在自然语言处理(NLP)领域的应用,并探讨了当前面临的主要挑战。通过案例研究,展示了如何利用神经网络模型解决文本分类、情感分析、机器翻译等任务。同时,文章也指出了数据稀疏性、模型泛化能力以及计算资源消耗等问题,并对未来的发展趋势进行了展望。
|
机器学习/深度学习 数据可视化 算法框架/工具
使用Python实现深度学习模型:智能家庭安防系统
使用Python实现深度学习模型:智能家庭安防系统
332 1
|
安全 关系型数据库 MySQL
揭秘MySQL海量数据迁移终极秘籍:从逻辑备份到物理复制,解锁大数据迁移的高效与安全之道
【8月更文挑战第2天】MySQL数据量很大的数据库迁移最优方案
1367 17
|
人工智能 NoSQL MongoDB
MongoDB的未来发展趋势
MongoDB的未来发展趋势
225 2
|
分布式计算 API 云计算
|
SQL 安全 数据库
[RCTF2015]EasySQL1 题目分析与详解
[RCTF2015]EasySQL1 题目分析与详解
|
机器学习/深度学习 人工智能 资源调度
GPU计算资源智能调度:过去、现在和未来
随着AI和大数据技术发展,GPU成为关键计算组件。文章探讨了GPU计算资源调度从静态到动态再到智能调度的演变,现以机器学习优化资源利用率。未来趋势包括自适应调度、跨平台、集群级调度和能源效率优化,旨在提升GPU性能,推动人工智能和大数据领域进步。
|
存储 缓存 NoSQL
Redis从入门到精通之底层数据结构SDS(简单动态字符串)详解
SDS是Redis中的一种字符串类型,它是一种二进制安全的字符串,由简单动态字符串(SDS)实现。SDS支持多种数据结构,其中字符串(String)是最常用的一种数据结构之一。SDS的优点在于它可以避免C字符串常见的问题,比如缓冲区溢出和内存泄露等。SDS的常数复杂度获取字符串长度和杜绝缓冲区溢出可以避免使用strlen和strcat函数时的一些问题。同时,SDS的空间预分配和惰性空间释放两种策略可以减少修改字符串的内存重新分配次数。SDS也是二进制安全的,因为它不是以空字符串来判断字符串是否结束,而是以len属性表示的长度来判断字符串是否结束。SDS还兼容部分C字符串函数
3247 104

热门文章

最新文章