内部业务系统的一些经验总结

　　从业那么久，以前作的要不就是软件外包，要不就是C端的产品，对于B端，或者企业内部系统还真没怎么接触。

　　最近这两年都是接触惬意内部业务系统，其实也就那么一回事而已，产品的设计仍是那样，只是会多了一个业务方、对接人，相比起C端用户的不明确，须要本身去研究，本身去尝试，企业内部业务系统，会有更明确的需求，同时也会更坑。

　　企业内部系统还有一个特色，就是偏重业务流程、偏重底层功能/逻辑的设计，而比较忽视界面、总体功能设计，毕竟作得再烂你也须要用（虽然这么说，本身仍是须要对本身有要求）。

 

记录了一些坑及应对方法：

一、对接人的专业性

　　通常到了必定规模的企业，都会选择一些统一的接口人，这些人的岗位多是某个职能部门的负责人或者某个运营人员或者某个岗位，他们的工做职责就是将部门内的需求汇总。

　　有一些只是作意见的搬运工，有一些还会作设计或者调研。若是只是前面的搬运工那就很好，你们责任清晰就好，他们作好运营、推广、收集。产品作好调研、设计，确保质量。

　　若是是后者，那就麻烦了，他们在收集到需求以后，会存在必定的扭曲或者优先级安排，干扰真正的用户需求。

应对方法：

　　A、创建自身的工做节奏，不要被对方带着走。可是又要协调好与对方的关系，维护好良好关系。

　　B、尽可能接触一线、真实的用户获取最原始的需求描述，若是接触不到，也尽可能接触到二线或者该部门的头头，否则被玩死都不知道怎么事。

　　C、设计尽可能通用、灵活、简单，而不作复杂的、个性的逻辑在里面，如将规则写在代码等，尽可能抽离出来，写在配置文件里面，最好是通用一套逻辑而不要作过多特殊逻辑。

　　D、逐步培训、教育对接人，提升对接人的业务调研、梳理的专业度

　　E、没有调研清楚的需求坚决不作。通常企业内部业务系统，都是线下已经有很成熟的业务，因此线下稳定运行，再搬到线上而且优化效率。若是没有调研清楚，没有线下稳定运行，那线上必然也会出问题。

 

二、试运行的必要性及细节调整

       不少时候，作了项目或者作了一个系统出来，没有一个试运行的阶段，直接发布，直接更新，而后直接开始下个阶段的工做。可是上次的功能设计是否有问题？运行是否提升效率？最重要是上次的设计，是否就完善，不须要再调整？

       我作过不少项目，极少一上线就百分百完美，由于没有人是完美，特别是那么多不一样性格、不一样专业的人在一块儿作一个项目，特别是从0到1的项目，更加多意外状况发生。你当时没想清楚，没设计好的，都会在上线以后爆发出来。

       因此最简单的作法，就是在真正上线以前，找一个小部门试点先运行，而且收集一波意见优化一下细节，再真正全局推广。

       而对于那些已经上线系统的优化迭代也一样适用，一次大的迭代，对功能有比较大的改动的核心迭代，必然须要试运行而且有一两个小迭代版原本优化下细节，完善下该功能。（固然尽可能在上线前，产品细节、质量尽量的好）

 

三、用户想要的，不是真正的

       这个基本作产品的都会遇到，特别是企业内部的，更为艰难。由于C端产品，不少时候用户是不会说话，只会经过一些行为或者一些场景来表达出他们的需求。

       可是企业内部业务系统，或者B端产品，他们会说出他们的需求，并且都会通过他们思惟转换。举个例子，某个需求，他们表述想要一个“备注”功能，可是当你深刻追问、了解他们的使用场景的时候，就会发现他们并非想要个备注去填写一些内容，而是想要一个能够存放证实的地方，作成一个附件上传，会比单纯“备注”更有价值，由于附件能够支持更多样式，而备注只支持纯文本。

       并且企业内部的业务系统，不少时候通过对接人的转换，那扭曲的需求会更加严重，因此这对产品的要求也会更高。同时这也是很容易区分低级产品与高级产品的差别，纯粹听对方要什么就作什么的产品，其实只是个需求分析师。对需求进行思考，并提出多种解决方案，更好去解决用户的问题，这种才是真正的产品经理。

 

四、没有正确与否只有适合与否

       企业内部的系统，大可能是基于企业线下业务，核心业务流程其实全世界都同样，就是进销存啊一进一出这样（几乎全部系统，都是输入、处理、输出三步骤）。可是每一个公司的业务细节都不同，不少时候遇到业务部门要求A，可是通过调研了解外面的通用设计，应该设计成B。可是业务部门就坚持A，那这种状况下，就只能作A了。

       为何呢？由于你找谁来判断A仍是B合适呢？我曾经看见过两个总监在讨论一个事情，明白人都知道A总监说的是对的，可是B总监硬说出一套似是而非的理论，并且比较野蛮。可是谁能作判断？除了老板，没有人能够作裁判，由于除了老板，他们就是最大的了。

       一样道理，在企业内部，除了业务部门的头头或者老板外，没有人能拍板决定对方提的要求是有问题，业务部门说线下就是这样，你作不同，到时候用不起来，那全是你的责任了。

       并且关键是，正如没有什么是不能作的同样（开发最喜欢拿这个来忽悠人），他的设计必然存在必定合理性及可运行性，就算明知道没价值及有问题，也只能作。

       应对的方法也像第一点同样：接触对方的老大，尽可能让对方老大参与并做出判断，若是对方老大也支持他，那只能作了。

 

五、要一次一个项目就作好，不要幻想有第二个迭代

       一开始的时候，我仍是保留C端的作法，分多个迭代不断完善功能、系统。作了一两次项目、迭代以后就发现，若是公司研发资源很少而且该项目不受重视的时候，最好就一次性作好。

　　A、尽可能设计的完善一点，尽可能灵活配置，容许撤回、编辑等，少留一些坑给本身

　　B、除了主业务流程外（输入、处理、输出数据），伴生的需求（通知、导出数据、管理员权限）也尽可能思考完善点，省的下次不知道何时才有资源搞第二个版本，尽可能将业务实现闭环，从一端到另一端

　　C、若是能够，尽可能约简单约好，而后再叠加复杂的限制、或者使用逻辑在里面，这样能够确保第一个版本没问题

 

　　企业内部系统还有不少不少的坑，作了两年左右，发现内部系统跟作软件外包同样，没有对错，只有负责人开心不开心而已。要作好企业内部的系统比单纯作C端的产品对产品的要求更高，须要懂得项目管理、人际关系处理等一系列技能。