2023 云栖大会观察与思考

20231103-apsara-conference

又是一年云起时

又到了一年一度的云栖大会. 赶在最后一天来参加, 主要是一来给友军支持鼓劲儿, 二来想gain some insights of the future.

全程用心听下来, 技术类的收获较少且较为零碎, 但当我尝试着从另外一些视角来看, 收获很多, 整理在这里.

演讲人

我会想, 如果站在台上的人是我, 那么我应该怎么做更好? 庆幸此时作为观众, 作为局外人, 能看清楚很多.

  1. 筛选自己的目标用户, 可以通过几个问题来开场. 或者说明下自己的目标群体, 需要有哪些背景知识. 发现这种临时的meetup, 演讲者与观众, 都是双向不可知的. 即
  2. 需要能提出问题, 让观众思考回答, 提升参与度. 不然就是无趣的讲课了.
  3. 需要说是什么, 但也要说不是什么. 不然就是没啥营养的产品介绍了.
  4. 讲话内容需要与PPT一样, 不能干说, 需要手指在PPT上划出重点. PPT 里只列出需要强调的重点.
  5. 最好能实时演示, 例如在线编程, 在线demo. 一定要防止成为产品介绍
  6. 不要使用页面截图, 太小了, 大家看不清, 也不会耐心去看. –> 突出重点即可. 内容不要堆砌太多, 讲不过来.
  7. 缺少具体数据&实际案例, 比较空
    1. 资源候补功能, 说了可以用, 但作为听众如果想使用这个功能, 其实更关注候补的成功率, 能否给出数据?
    2. 实时演示页面实在太小了, 根本看不清.
  8. 讲清楚 背景, 背景很重要!
  9. 要知道分享的目标是啥:
    1. 是单纯的秀肌肉么? —> 不能认怂, 嘲讽友军. —> Jobs的经典
    2. 是让观众能学到东西? 能有所收获? —> 内容要通俗易懂, 不要发明新名词, 不要buzzword. 可以认怂, 可以讲走的弯路.
    3. 我个人习惯第二种, 我相信作为观众, 也更喜欢第二种.
  10. 架构前后变化点(例如ECI从ImageCache变到支持ImageCache+DataCache), 需要 highlight 出来!
  11. 不要一一列举bulletpoint, 而要有层次地来将为啥有这些, 要关注在why, 而不是what. 例如主动运维的几个状态:
    1. Inquiring:
    2. scheduled
    3. executing
    4. avoided:
    5. 可以站在设计者角度: 为啥设计这几种状态, 这几种状态的递进层次是咋样的? 为啥不能有其他状态? 等方式进行讲解. 或者讲清楚背景&问题, 然后问观众, 假如让你来设计, 你会咋样?
    6. 也可以站在使用者角度: 怎么用这几个状态, 能列举出具体的case/sample.
    7. 记住: 人一次是记不住超过3项内容的.
  12. PPT里的文档链接地址, 实际上听众是拿不到PPT的, 所以无法访问到. 所以可以说明下, 然后在最后放个群二维码, 拉进群里, 统一把材料分发.
  13. 需要自己把演讲录下来, 然后站在听众的角度来思考来分析. 这样

组织者

  1. 中间没有休息, 导致全程听下来三个多小时, 腰酸背痛, 膀胱爆炸, 体验不好.
  2. 没有QA环节, 导致气氛不够活跃.
  3. 要注意多个演讲前后的连贯性, 防止使听众混淆. 例如 最开始A讲了 包年包月需要尽量转成 SP+OD; 但后边B/C又开始讲稳态的使用包年包月. 前后打架了.
  4. 排练的时候, 一定要也站在观众角度, 看演讲嘉宾的排练, 能提前发现问题, 给演讲者一些建议.
    1. 具体方式: 彩排时请组内的同学/行业内的人来作为观众, 进行提前预演. 我相信如果是我作为,
    2. 例如: 可以建议不要有API/售卖页的实时演示了, 实在看不清. 或者可以提醒进行放大.
  5. 是个好的机会, 收集开发者微信(例如红包建群), 可以后续运营/沟通, 连接开发者的通道. –> 或者拉进到研发交流群里(例如SPOT交流群)

case study

当然, 这种也

good case

bad case