to b/to c 成就感问题

[seagull7558]

工作几年,一直在做 TO B 的东西,业务简单或是复杂暂且不说

只是觉得写起来不好玩,虽然确实有人反馈有了使用了我们开发的软件后提升了很多工作效率

例如: 原本需要好几个小时人工完成的工作,可能借助软件系统,几分钟就搞定了

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

-----------------------------------------------------------------------------------------------------

to c 应该就完全不一样了,完全是因为好玩才去使用的,会收到很多反馈,会不会很有成就感

好想写好玩的东西

[cnbattle]

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

[Sh4p]

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

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

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

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

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

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

[ah64zzpk]

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

[jin5354]

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

[binge921]

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

[darkengine]

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

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

[hlwjia]

这和成就感没啥关系吧。

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

[mitsuizzz]

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

[paradoxs]

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

[zangaiboy]

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

[alphardex]

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

[ZSeptember]

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

[PaPaBoom]

To B Number One

[seagull7558]

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

[vzchn]

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

[imn1]

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

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

[arvinsilm]

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

[h1104350235]

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

[eason1874]

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

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

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

[seagull7558]

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