To B(usiness) 和 To C(ustomer)

毕业后第一家公司是做的To B的产品,而后第二家公司是做To C的(社区)服务,现如今是做企业内部服务,如果要归根的话,还是属于 To B。简单的描述一下我感受到的To B和To C的区别(典型情况下,并非绝对):

  • To B对稳定性要求高,迭代速度要求低。To C的套路通常是上了再说,小步快走,快速迭代。而To B面对的用户都是付费用户,花钱 是要买享受的,所以通常To B的产品会要求在交付给用户之前,各种测试,稳定性达到一定程度。

  • To B的技术挑战通常在于边界条件的判定。要处理好各种边界条件,虽说To C的服务也要处理,但是To C有更大的挑战—高并发。To C通常面向的用户都是有一定量级的,所以我们可以用QPS等指标来衡量,而相反,To B的业务如果一定要用QPS来衡量,那么十有八九 数值都不会超过100—毕竟通常To B的产品都是每个企业自己部署一套,高不到哪去。

  • To C的产品,面向所有用户,也就是说,每个用户的区分度不大,大家看到的都是一样的。而To B的产品则一般都是定制化,每个企业 根据自己的需求进行定制化。

  • To C的用户体验一般来说要优于To B的产品。我目前接触到的普遍规律都是这样,互联网产品必须想方设法提高用户体验,让用户爽, 这样才能留住用户,进行薅羊毛。To B就不一样了,一手交钱,一手交货,用户体验?看命。

  • 不论To B还是To C,你都有很大机会习得一种叫做 Boss-Driven Programming 的技能。

😄完。


微信公众号
关注公众号,获得及时更新

更多文章
  • Goroutine是如何处理栈的?
  • StackGuard的作用
  • Go DiskQueue源码阅读
  • NSQ源码分析
  • NSQ简明教程
  • 结合Redis与MySQL实现又快又好的数据方案
  • 程序员的MySQL手册(五):索引优化
  • 程序员的MySQL手册(四):索引设计
  • 程序员的MySQL手册(三):数据库设计
  • Linux窗口管理器下的截图
  • Go设计模式:facade模式和观察者模式
  • 程序员的MySQL手册(二): 监控与benchmark
  • Go设计模式: 责任链模式
  • 我们真的需要这么复杂的技术栈吗?
  • Go设计模式:装饰器模式