背景说明：
笔者曾经在一些ToB部门 和Saas公司工作过，基本每个这个地方的Leader都会告诉你中国ToB的前景有多大，美国的ToB企业市值有多高，中国有多大的潜力。
但可能也因为此，常常感觉有非常多激进的开发计划和频繁的产研变更，最后产出的产品质量往往参差不齐，客户吐槽声不断。
作为这个过程的经历者，从研发角度做了一些反思，总结一些ToB特点，不保证完全正确和完整，欢迎补充和纠正。
良好的设计，避免重构
ToB在于构建一个复杂的系统，因为越做越复杂，重构成本很高
而且ToB领域的人力成本相对于ToC领域是显而易见的，因此在设计之初，尽量做好可扩展的设计，统一代码风格，统一领域语言，统一理解和做事方式，如果没有这个基础，后面互相维护代码会很痛苦，也是造成后面人均产能较低的一个原因
技术的设计，这个又需要产品或市场要早一步拥有成熟的业务理解，因为代码的领域设计建立在深刻的业务理解之上
产品也可以先拿出方案，先去调研客户对方案的想法，如果特别受欢迎，再去走后面的开发环节。避免出现新设计的产品功能，没有客户使用的尴尬情况。
注重产研配合
原来看文章说，salesforce的产品需要懂技术，虽然没法证实，但的确能感受到一些产品在设计的时候没有考虑到可扩展和技术实现的困难，很多变成了客户需求的搬运工，反而很在意交互细节的设计，在此背景下，研发可能要承担更重要的作用，因此很多需求应该在初稿的时候就应该有研发介入，判断怎么设计合适，目前的很多情况是，研发这边很多看到的是终稿或者接近终稿，需求评审变成了研发接收产品的需求
迭代周期可以延长一些
第一个，客观环境，这个个人觉得一个是ToB需求长期存在，不用担心这个月或者下个月市场发生重大变化。
第二个，回归困难，因为每次发布都要回归，在每次发布的时候，需要回归原来的内容，在起初的阶段，产品还不够复杂，回归时间短一点可以接受，到后期，短时间能回归到的场景有限，很多问题会在线上用户使用发现，造成线上bug高居不下。
第三个，不用拼凑，小迭代周期下，一个需求的复杂度如果高一点，产品是希望研发尽量上线，这个时候研发可能出一些临时方案来实现，而临时方案会造成重复劳动或者重构,另外一个原因是，短周期迭代内，人力不能很好的分摊，可能存在这个迭代周期内，某个部分没有新的需求可以做，需要原来负责这块的研发做别人熟悉的领域，这样没有大的问题，但可能会降低效率和人均产出，也有可能不熟悉而造成bug。
第四个，保证需求质量，有更多的时间去评审一个需求的合理性和优先级，并且进行更好的设计，因为需求一旦进入开发阶段，就需要x2倍的研发和x1倍的测试工作量。
第五个，客户感受，对客户来说，关注的是核心功能点，不希望产品经常变动，而核心功能点又都是需要大周期开发完成的东西。
第六个，减少重复劳动，每次迭代会有很多会议对齐，发布回滚，计划review，排期调整的会议，这些会议占用了很多时间，迭代越频繁，占用的总时间比例越高。
（为了实现这个，可能就反过来要求，不要轻易承诺客户交付时间点）
激发团队活力和参与感
ToC领域很可能几个good idea就能hold住一个产品了，其他的可能是锦上添花，但是ToB领域，如果做的好，可能需要很多很多的地方进行优化，这需要所有人在自己的领域内贡献自己的idea，需要非常民主的氛围和鼓励一线创新的氛围
同时ToC容易对客户产生粘性，但ToB不会，你的少数的good Idea 很容易被抄袭过来，所以需要非常非常多的good idea，整体感觉ToB领域对团队整体要求更高，对公司文化要求更高。
培养领域专家
ToB领域如果一个企业做的好，那肯定是建立在原来对这个领域理解基础之上的，同时进行一些创新，形成先进的业界理念，这个要求企业在这方面有领域专家，从人才培养来看，需要一些员工在特定领域长期工作并得到充足的成长资源，这个可能要求一个很好的员工稳定性，及员工和业务关系的绑定稳定（最好不要这个员工今天做B业务，明天做C业务，知识碎片化，员工也容易失去信心，当员工确定在某个业务方向能稳定发展时，往往才会有深入了解业务的想法）
Salesforce文化在网上的评价是工作能和生活balance,虽然和国内崇尚奋斗的文化不一样，但是可能也是这个原因，Salesforce的员工稳定性好，同时Salesforce文化也很好，那么大家不会带着压抑的心情来工作，这样也构成一个员工稳定的核心。
识别需求的优先级
有的需求可能是很好的设计初衷但不符合市场，有的需求可能是产品在没有好的东西可做的时候，需要找点事做，有的需求可能是被个别用户牵引，这些需求可能最终的结果就是投入产出比不划算，因此可以尝试将需求优先级投票权交给一线的销售或实施或者通过其他的方式综合评估，确保优先产出价值更高的部分。
