to b/to c 成就感问题

b 端的 bug 很多没那么紧急，c 端的 bug 必须火速修复

你以为的 2c：很多人用，很多人反馈，不断改进
真实的 2c：没人用，好不容易有人用点两下白屏了直接关了，好不容易推广开了不知道收益点是啥，最终项目失败部门被裁公司倒闭

写好玩的东西和 2b2c 无关，好不好玩 /风险高不高 /收益大不大 关系也不大，自己权衡好了之后，干就完了

1#回复相当真实，深夜被叫起来修复问题及改需求的次数数不胜数

to b 应该是业务相对比较复杂，且定制性极强的。 技术难度不是很大，但架不住投标公司忽悠，一个不到 10 个人用的项目要上 Spring Cloud 。还要加入灰度发布，自动化测试，非常尴尬。
to c 唯一麻烦的就是救火吧，不管什么时候，只要有严重 bug 你就得修，并且要快（这一点压力很大），因为用的人多，所以要考虑的东西就比较多，玩法也多，对自己的技术提升非常明显。

你是后端还是 web 端还是客户端？

有这个心态说明你在 2C 公司容易被当成大头兵，如果你体验过后真的乐在其中那你就是卷王了，如果你发现并不是自己想的那样，那你就惨了

问题是用的人多的 TOC 的东西也不多啊，并且那几家门槛也摆在哪里的

二楼真相了，之前 toc 一百多万用户，年流水几百个亿，然后团队裁员了三次。
现在 tob 做的垃圾软件没几个人用，年流水几百万，目前还没裁员。

你可知 to c 今年有多惨

"会收到很多反馈"
天天收到 bug 反馈很开心吗？ 都是祖传代码，改又不好改的那种，改出问题了影响又大

还是喜欢搞 to B ，需求稳定，甲方有钱，还能正常下班，业余打打游戏看看书，做几个 to C 的玩具不香么

to b to c 都有精品和垃圾

我就是从 to b 转 to c 的，你想要反馈，创业吧，全是反馈。。。哈哈哈，更惨

有没有想过 to C 天天给你报 bad case 的时候

to B 的也没那么爽，总是有些奇葩客户的奇葩需求要满足，还很难或者根本就没法做成共性的，结果就是业务逻辑越堆越复杂，维护成本越来越高。说到 bug ，很多时候客户追着你让你修，那怎么就不紧急了，影响的也不是一个用户，每次上线就怕出什么幺蛾子

to c 到亿级用户后，跟好玩已经完全不沾边了，开发的时候想得只有可能哪哪有风险问题

ToB 项目其实有一点跟 ToC 不一样。
那就是，业务比较重，如果是某大企业的定制业务，其实还是比较复杂的，不是说技术挑战，而是说业务复杂性。有几年工作经验的新人进来了，1 个月可能都完全改不动代码。因为看不懂代码。

ToB 接到大单子就能躺着赚钱了，ToC 还得运营天天搞

toC 眼里用户就是数据曲线，搞多了也没成就感，一个事情数据能涨就是好的，数据不涨就是没意义的，至于用户开心不开心和你关系不大

个人看法
tob 不用考虑服务器 人员维护成本等，啥都自己干，但技术栈保守，慢慢干
toc 反之，面向 API 接口 第三方服务 ，快速实现为主

首先不知道楼主是什么岗位，我自己是后端，并且 toB / toC 都做过，说说个人的感受

1. 「好玩」的反馈是用户给的，但不是所有的 PM 需求都会让用户觉得「好玩」。因为不「好玩」而失败，还占用了资源，最后导致大家下一轮绩效 review 都尴尬的情况是更多的。不然为什么大家 offer 对比的时候都会说看组呢。

2. 即使你真的在做一个「好玩」的东西，但是落到后端这里，写代码的时候不一定就是好玩的。设计和复用的第一关不是你说了算，是 PM 和 UX 说了算。并且真落到实施的时候，大家的合作是要服从康威定律的，会进一步限制你的设计。

3. 是会收到很多反馈，正反馈一定是先夸 PM 的，负反馈一定是要你先半夜起来修 bug 的。

4. toB 客户也不是不得不用，归根结底还是你们公司在竞标中胜出了。其实竞标能胜出，和用户觉得好玩而来玩，这两件事基本就是对标的，区别可能是在使用量能不能给你这个研发一个正反馈。

5. SaaS 类型的 toB ，你的服务是要接不少流量的，也可以让你在写代码时有好玩的感觉。

一直做 tob ，一般来说 tob 的用户相对而言比较专业，比如运营商或者是其他公司的 it 人员，客户对于产品的挑选也都是比较理性的，如果让我选我愿意做 tob 。

同时在做某亿级流量产品的 toC 和 toB
toC：极致的质量和性能要求，上线有 bug 分钟级反馈，24 小时要求你光速处理，搞不定就完犊子吧（当然了，祖传代码质量稀烂，屎山），经常半夜被喊帮忙看问题，必须支援
toB：能用就行，上线出了问题，冷门一点的出问题一个月都没人发现的。基本能睡个好觉
已经彻底跟好不好玩没关系了，纯纯打工牛马

现在 tob 之前 toc 只想说 toc 的及时修复会把你逼疯 tob 则不一样了 下周一再弄吧 明天再说吧 这个以后有空再加上吧 而且 甲方不缺钱 toc 的话 你赚那点钱 真就是全部心血 完全没有摸鱼的感觉 toc 的老板也会觉得 他要榨干你 tob 的老板觉得 只要不出大差错 其他慢慢改 都能聊 你想想吧 我现在就是在 tob 的过程中 想找一些 toc 的活儿 干干 1 是为了好玩 2 是为了赚钱 3 是为了挑战自己 4 是希望提升自己 toc 当饭碗还是相对于 tob 有点影响生活 自己抉择就好了 不过 toc 提升快是真的

"但我还是觉得这是因为工作原因,客户不得不用"

除非你是税务政务指定软件，不然怎么会有“客户不得不用”的 toB 软件，如果客户是因为使用了你们开发的软件后提升了很多工作效率，那不就是达成成就了么。

这和成就感没啥关系吧。

这明明是「酷不酷」的问题

现在在做 tob 很少有问题能被立即发现反馈，不过公司价值观难以苟同，强调客户价值至上，很没有成就感，一些破烂需求也要硬着做，一堆反人类设计，目的就是要让大客户用的爽，美其名曰提炼客户需求。

最近做了 2 个物联网的项目，完全不同的成就感。

toc 有法律风险，公司没背景有被端的可能

真好玩，明天上线，诶嘿~

To B 才更有成就感吧，因为产品有真正的实在价值。
ToC 也有价值，但是更多的是娱乐，休闲价值。

To B Number One

@leafre ? 我只定义了很主观的层面的好不好玩 从来没说过 TO B 简单

最好玩的是用 to c 的心态做 to b 的业务

以前喜欢做 to c ，找工作也特意避免 to b 的
后来发现除非自己做老板，不然 to c 也只是出工资而已，而且看着需求变化和难解决的奇奇怪怪 bug ，挺累的

后来开始自由职业，基于业务性质，基本上是 to b 的，感觉钱比 to c“好赚” 相对而言，因为只有一个客户，需求转变都在业务范围内，比起不知谁来个特殊需求就累死累活简单多了

toB 维护远古、中古、上古各个时代的无数个版本，每个时代还有若干个定制化分支，手里还要做着产品规划的下个时代

to B to C 都搞过
比较喜欢 B 端，喜欢没有紧急的需求，不用火急火燎的修复线上 Bug

2B 2C 都做过，2C 的优点跟缺点是同一个，自由

优点是你能做几乎一切抉择，2C 你想咋做就咋做，技术栈可以随意更换，功能也可以随意定制，从接受反馈到功能上线可能只要一到两天

缺点就是慢慢地你会在一次次抉择中迷失自己，你会变得跟聋哥一样，听不见别人说话。从喜欢用户反馈，到只看数据报表，变成报表驱动的赚钱机器，不知不觉就把小而美做成屎山（真实经历

@eason1874 功能的堆彻指定不能怪罪研发啊吧正常情况不是应该只去做产品仔细分析市场 /竞品后精心设计的功能模块吗?

2b 的业务一般迭代频率低一些，2c 的业务迭代频率就太高了，尤其是面向信息流广告的 2c 业务，追热点 /合规改造的时候，今天提需求今天就要上线都是常事。

@seagull7558 我们当时小团队分得没那么细，没有产品，或者说研发都是产品

屎山就是分析市场后做出来的。。。说白了，没有技术壁垒，产品没独特优势，要提高留存率提高收入只能靠功能去堆。新增功能不赚钱，要引入广告去摊平成本，于是广告也跟着多了

如果只是守着一亩三分地，倒可以一直小而美。但是这样也只能靠爱发电了，也不会长久

以前都是做 2c 业务，亿级的用户和日千万订单，业务迭代快，经常加班，每次上线都是提心吊胆，客户至上且投诉又多，甚至半夜处理问题，经常搞得要处理，还有各种舆论风险。
现在终于躺平来做 2b 业务，一个月才一个版本，有事绝大部分都能内部消化，没有什么紧急事项，甚至不用背电脑回家。
2c 的技术挑战更高一些，经常周末都在想某些需求咋处理，产品为了数据根本不让步； 2b 则大多数都好商量。

年轻时我是这么想的，当然现在我也这么想，可是呢这么多年来经历过不少公司，觉得这些都不重要，重要的是公司业务健不健康，团队舒不舒服。

@eason1874 又有你小子

@zqx 业绩这么好裁员?功能稳定了的原因吗?

小伙子。。只要项目赚钱。。比什么都强。成就感？少年。。太年轻了

tob 更轻松些，可能工资没有 toc 高

@darkengine 我司一个客户为了拿下我们的软件外包单子，不得不用我们开发的人事管理系统

@Otho 确实，你这个总结到位了

用着最好用的是 to myself
个人感觉，能把 toC 做大为 toB 的经历最优价值感

@liuidetmks 互联网裁员原因我总结一个是灰色产业，比如放贷产品，一个是盈利困难，流水高但是全靠烧钱投资，商业逻辑压根走不通就大量招聘再大量裁员。
tob 都是体力活，天天增删改查，但是合法且稳定