“稍后整理”总是亏损的原因
当在代理机构讨论博客运营结构时，大多数反应是这样的。
“现在只是写，
等稍微扩大一点再整理吧。”
这句话听起来很合理。
因为现在很忙，立即就能运转。
但实际上，也是
改变结构最昂贵的选择之一。
博客运营结构存在‘无法回头的时刻’
当博客数量为1~2个时，
无论什么结构都没有大问题。
- 人少
- 内容不多
- 靠记忆就能应对
但有一刻会超越这个界限。
- 客户增多
- 内容积累
- 负责人分散
从这时起，结构就
固定在资产上了。
结构变更成本与博客数量无关，与‘累积量’成正比
很多人都有误解。
“博客增多只会变得更麻烦。”
实际成本不在于博客数量，
而是积累的东西。
- 内容迁移
- 权限重新定义
- 运营规则再教育
- 实务中断成本
这一切都不是
“现在不做也行”的事情，
而是“推迟做会变得更昂贵”的事情。
最大成本是‘在运营中改变的风险’
改变结构时，
最可怕的不是技术。
- 运营会停止吗？
- 出错了怎么办？
- 需要向客户解释吗？
因此团队会变成这样。
- 想改变但推迟
- 不舒服但维持
- 知道问题但不管
这种状态持续时间越长，
结构变更就会变得越来越困难。
因此大多数团队都是‘事后’行动的
现场最常见的模式是这样的。
- 不舒服但忍耐
- 发生小事故
- 将其视为‘偶然’
- 发生更大事故
- 然后才改变结构
在这个顺序中，有一点很重要。
结构变更的原因是‘预防’而不是‘恢复’。
结构越早确立越便宜
总结起来很简单。
- 博客数量少时 → 结构变更成本低
- 内容少时 → 风险较小
- 人少时 → 教育成本低
因此结论是
在问题爆发之前改变结构是最便宜的。
此时的选择很简单
如果现在博客运营
还是“可以忍受的不便”，
那么现在改变结构
可能是最好的时机。
等到完全不方便时，
很多时候已经太迟了。
在下一篇文章中，
将总结这一切，
包括blog.haus不需要的情况，
并坦率地整理。
下一篇预告
〈哪些团队不需要使用blog.haus〉