从业那么久，之前做的要不就是软件外包，要不就是C端的产品，对于B端，或者企业内部系统还真没怎么接触。
最近这两年都是接触惬意内部业务系统，其实也就那么一回事而已，产品的设计还是那样，只是会多了一个业务方、对接人，相比起C端用户的不明确，需要自己去研究，自己去尝试，企业内部业务系统，会有更明确的需求，同时也会更坑。
企业内部系统还有一个特点，就是偏重业务流程、偏重底层功能/逻辑的设计，而比较忽视界面、整体功能设计，毕竟做得再烂你也需要用（虽然这么说，自己还是需要对自己有要求）。
记录了一些坑及应对方法：
1、对接人的专业性
一般到了一定规模的企业，都会选择一些统一的接口人，这些人的岗位可能是某个职能部门的负责人或者某个运营人员或者某个岗位，他们的工作职责就是将部门内的需求汇总。
有一些只是做意见的搬运工，有一些还会做设计或者调研。如果只是前面的搬运工那就很好，大家责任清晰就好，他们做好运营、推广、收集。产品做好调研、设计，确保质量。
如果是后者，那就麻烦了，他们在收集到需求之后，会存在一定的扭曲或者优先级安排，干扰真正的用户需求。
应对方法：
A、建立自身的工作节奏，不要被对方带着走。但是又要协调好与对方的关系，维护好良好关系。
B、尽量接触一线、真实的用户获取最原始的需求描述，如果接触不到，也尽量接触到二线或者该部门的头头，不然被玩死都不知道怎么事。
C、设计尽量通用、灵活、简单，而不做复杂的、个性的逻辑在里面，如将规则写在代码等，尽量抽离出来，写在配置文件里面，最好是通用一套逻辑而不要做过多特殊逻辑。
D、逐步培训、教育对接人，提高对接人的业务调研、梳理的专业度
E、没有调研清楚的需求坚定不做。一般企业内部业务系统，都是线下已经有很成熟的业务，所以线下稳定运行，再搬到线上并且优化效率。如果没有调研清楚，没有线下稳定运行，那线上必然也会出问题。
2、试运行的必要性及细节调整
很多时候，做了项目或者做了一个系统出来，没有一个试运行的阶段，直接发布，直接更新，然后直接开始下个阶段的工作。但是上次的功能设计是否有问题？运行是否提高效率？最重要是上次的设计，是否就完善，不需要再调整？
我做过很多项目，极少一上线就百分百完美，因为没有人是完美，特别是那么多不同性格、不同专业的人在一起做一个项目，特别是从0到1的项目，更加多意外情况发生。你当时没想清楚，没设计好的，都会在上线之后爆发出来。
所以最简单的做法，就是在真正上线之前，找一个小部门试点先运行，并且收集一波意见优化一下细节，再真正全局推广。
而对于那些已经上线系统的优化迭代也同样适用，一次大的迭代，对功能有比较大的改动的核心迭代，必然需要试运行并且有一两个小迭代版本来优化下细节，完善下该功能。（当然尽量在上线前，产品细节、质量尽可能的好）
3、用户想要的，不是真正的
这个基本做产品的都会遇到，特别是企业内部的，更为艰难。因为C端产品，很多时候用户是不会说话，只会通过一些行为或者一些场景来表达出他们的需求。
但是企业内部业务系统，或者B端产品，他们会说出他们的需求，而且都会经过他们思维转换。举个例子，某个需求，他们表述想要一个“备注”功能，但是当你深入追问、了解他们的使用场景的时候，就会发现他们并不是想要个备注去填写一些内容，而是想要一个可以存放证明的地方，做成一个附件上传，会比单纯“备注”更有价值，因为附件可以支持更多样式，而备注只支持纯文本。
而且企业内部的业务系统，很多时候经过对接人的转换，那扭曲的需求会更加严重，所以这对产品的要求也会更高。同时这也是很容易区分低级产品与高级产品的差异，纯粹听对方要什么就做什么的产品，其实只是个需求分析师。对需求进行思考，并提出多种解决方案，更好去解决用户的问题，这种才是真正的产品经理。
4、没有正确与否只有适合与否
企业内部的系统，大多是基于企业线下业务，核心业务流程其实全世界都一样，就是进销存啊一进一出这样（几乎所有系统，都是输入、处理、输出三步骤）。但是每个公司的业务细节都不一样，很多时候遇到业务部门要求A，但是经过调研了解外面的通用设计，应该设计成B。但是业务部门就坚持A，那这种情况下，就只能做A了。
为什么呢？因为你找谁来判断A还是B合适呢？我曾经看见过两个总监在讨论一个事情，明白人都知道A总监说的是对的，但是B总监硬说出一套似是而非的理论，而且比较野蛮。但是谁能做判断？除了老板，没有人可以做裁判，因为除了老板，他们就是最大的了。
同样道理，在企业内部，除了业务部门的头头或者老板外，没有人能拍板决定对方提的要求是有问题，业务部门说线下就是这样，你做不一样，到时候用不起来，那全是你的责任了。
而且关键是，正如没有什么是不能做的一样（开发最喜欢拿这个来忽悠人），他的设计必然存在一定合理性及可运行性，就算明知道没价值及有问题，也只能做。
应对的方法也像第一点一样：接触对方的老大，尽量让对方老大参与并作出判断，如果对方老大也支持他，那只能做了。
5、要一次一个项目就做好，不要幻想有第二个迭代
一开始的时候，我还是保留C端的做法，分多个迭代不断完善功能、系统。做了一两次项目、迭代之后就发现，如果公司研发资源不多并且该项目不受重视的时候，最好就一次性做好。
A、尽量设计的完善一点，尽量灵活配置，允许撤回、编辑等，少留一些坑给自己
B、除了主业务流程外（输入、处理、输出数据），伴生的需求（通知、导出数据、管理员权限）也尽量思考完善点，省的下次不知道什么时候才有资源搞第二个版本，尽量将业务实现闭环，从一端到另外一端
C、如果可以，尽量约简单约好，然后再叠加复杂的限制、或者使用逻辑在里面，这样可以确保第一个版本没问题
企业内部系统还有很多很多的坑，做了两年左右，发现内部系统跟做软件外包一样，没有对错，只有负责人开心不开心而已。要做好企业内部的系统比单纯做C端的产品对产品的要求更高，需要懂得项目管理、人际关系处理等一系列技能。