降本增笑，领导要求程序员半年做出一个金蝶

关于降本增效的事，今天在网上看到一个帖子，虽然有点搞笑，但是对于打工人（特别是技术同学）来说，可挖掘的东西也不少，特别分享给大家。

真的是好多年没听说这样的事了，记得以前总有老板让做个淘宝、做个京东，然后预算只有几千块，最多几万块。

这些故事程序员谈起来往往都是哈哈一笑，并疯狂吐槽一番。

不过笑过之后，大家是否想过如何去解决问题？或者真的去评估下可行性，探索一下可能的实现路径。

找到问题

首先我们看下老板的问题。老板的根本问题并不是想要做金蝶，为什么这么说呢？

我们看看网友的描述就知道了：经济下行，领导不想出金蝶系统的维护费，不想为新功能花大价钱。这才是根本问题，用四个字来说就是：降低成本。

然后才是老板想到能不能用更少的钱达到金蝶系统的使用效果，再之后才是自己能不能做一个类似金蝶的系统，并思考了自己可以承担的成本：一个前端、一个后端，半年时间。

最后问题被抛到了这位网友的手里。可以看得出来这位网友也不太懂，还去咨询了朋友。不知道它有没有向朋友说清楚问题，还是只说了老板想自己做一个金蝶系统，结果是朋友们都说不可行。

遇到问题时，我们得把这个问题完完整整的捋一遍，找到最根本的问题，然后再说怎么解决问题，否则只是停留在表面，就可能事倍功半。在这个上下文中，根本的问题就是：降低成本。

解决问题

明确了老板的根本问题，我们就可以琢磨方案了。既然是降低财务系统的成本，可行的方案应该还是有几个的。

使用替代产品

假如公司只使用产品的部分功能，是不是可以选择金蝶的低版本？是不是可以降低一些人头费？

金蝶的服务贵，是不是可以选择一些小厂的产品？国内做财务系统的应该挺多的，小厂也更容易妥协。

或者选择SaaS服务，虽然SaaS用久了成本也不低，但是可以先撑过这几年，降低当前的支出。

当然替换财务系统也是有成本的，需要仔细评估。不过既然都想自己做了，这个成本应该能hold住。

找第三方维护

金蝶的服务贵，是不是可以找其它三方或者个人来维护修改？根据我之前的了解，金蝶这种公司有很多的实施工作是外包出去的，或者通过代理商来为客户服务，能不能找这些服务商来代替金蝶呢？或者去某些副业平台上应该也能找到熟悉金蝶系统的人。

当然这个还要看系统能不能顺利交接，金蝶有没有什么软硬件限制，第三方能不能接过来。

另外最重要的必须考虑系统和数据的安全性，不能因小失大。

自己开发

虽然自己开发的困难和成本都很高，但我仍旧认为这可能也是一个合适的解决方案。理由有下面两点。

• 
  
• 功能简单：如果公司的业务比较简单，使用的流程也简单，比如不使用涉及复杂的财务处理，那么捋一捋，能给开发人员讲清楚，也是有可能在短时间内完成的。
  
• 迭代渐进：长城不是一天建成的，系统也都是逐渐迭代完善的。自己开发可以先从部分模块或者功能开始，然后逐步替换，比如前边的流程先在新系统中做，最后再导入金蝶。即使不能做到逐步替换，也可以控制系统的风险，发现搞不定时，及时止损。相信老板也能明白这个道理，如果不明白或者不接受，那确实搞不了。
  

当然我们也肯定不能忽视这其中的困难。我之前做过和金蝶系统的对接，订单的收付款在业务系统完成，然后业务系统生成凭证导入到金蝶K3。依稀记得业务也不算复杂，但是需求分析做了好几遍，我的代码也是改了又改，上线之后遇到各种问题，继续改，最终花了几个月才稳定下来。

事后分析原因，大概有这么几点：

• 
  
• 产品或者需求分析人员没接触过类似的业务，即使他对财务系统有一些经验，也不能准确的将客户的业务处理方式转换到产品设计中；
  
• 财务人员说不明白，虽然他会使用金蝶系统，但是他不能一次性的把所有规则都讲出来，讲出来也很难让程序员在短时间内理解；
  
• 程序员没做过财务系统，没接触过类似的业务，系统的设计可能要反复调整，比如业务模块的划分逻辑，金额用Long还是用BigDecimal，数据保留几位小数，这都会大幅延长开发周期，如果不及时调整就可能写成一锅粥，后期维护更困难。
  

这还只是和金蝶系统做一个简单的对接，如果要替代它，还要实现更多的功能，总结下，企业可能会面对下面这些困难：

业务复杂：财务规则一般都比较复杂，涉及到各种运算，各种数字、报表能把人搞晕。如果公司的业务也很复杂，比如有很多分支或者特殊情况，软件开发的难度也会很大，这种难度的变化不是线性增加的，很可能是指数级增长的，一个工作流的设计可能就把人搞死了。

懂业务的人：系统过于复杂时，可能没有一个人能把系统前前后后、左左右右的整明白。而要完成这样一个复杂的系统，必须有人能从高层次的抽象，到具体数字运算的细枝末节，完完全全的整理出来，逻辑自洽，不重不漏，并形成文档，还要能把程序员讲明白。

懂架构的人：这里说的是要有一个经验丰富的程序员，不能是普通的码农，最好是有财务系统开发经验的架构师。没走过的路，总是要踩坑的。有经验的开发人员可以少走很多弯路，极大降低系统的风险。这样的人才如果公司没有，外招的难度比较大，即使能找到，成本也不低。

灵活性问题：开发固定业务流程的系统一般不会太考虑灵活性的问题，如果业务需要调整，可能需要对系统进行大幅修改，甚至推倒重来。如果要让系统灵活些，必然对业务和技术人员都提出了更高的要求，也代表着更强的工作能力和更多的工作量。

和其它系统的对接：要不要和税务系统对接？要不要和客户管理系统对接？要不要和公司的OA对接？每一次对接都要反复调试，工作量肯定下不来。

总之，稍微涉及到财务处理的系统，都不是一个前端和一个后端能在短时间内完全搞出来的。

对程序开发的启示

搞清楚需求

日常开发过程中，大家应该都遇到过不少此类问题。领导说这里要加个功能，然后产品和开发就去吭哧吭哧做了，做完了给领导一看，不是想要的，然后返工反复修改。或者说用户提了一个需求，产品感觉自己懂了，然后就让开发这么做那样改，最后给用户一看，什么破玩意。这都是没有搞清楚真正的需求，没有触达那个根本问题。

虽然开发人员可以把这些问题全部甩给产品，自己只管实现，但这毕竟实实在在的消耗了程序员的时间，大量的时间成本和机会成本，去干点有意义的事情不好吗？所以为了不浪费时间，开发也要完整的了解用户需求。在一个团队中，至少影响产品落地的关键开发人员要搞懂用户的需求。

那么遇到这种问题，程序员是不是可以直接跑路呢？

也是一个选择， 不过对于一个有追求的程序员，肯定也是想把程序设计好、架构好的，能解决实际问题的，这也需要对用户需求的良好把控能力，比如我们要识别出哪些是系统的核心模块，哪些是可扩展能力，就像设计冯诺依曼计算机，你设计的时候会怎么处理CPU和输入输出设备之间的关系呢？

对于用户需求，产品想的是怎么从流程设计上去解决，开发需要考虑的是怎么从技术实现上去满足，两者相向而行，才能把系统做好。

当然准确把握用户的需求，很多时候并不是我说的这么容易，因为用户可能也说不清楚，我们可能需要不断的追问才能得到一些关键信息。比如这位网友去咨询朋友时，可能需求就变成了：我们要做一个财务系统，朋友如果不多问，也只能拿到这个需求，说不定这位朋友也有二次开发的能力，错失了一次挣钱的好机会。还有这位老板上边可能还有更大的老板，这位老板降低成本的需求也可能是想在大老板面前表现一下，那是不是还有其它降本增效的方法呢？比如简化流程、裁掉几个不关键的岗位（这个要得罪人了）。

我们要让程序始终保持在良好的状态，就要准确的把握用户需求，要搞懂用户需求，就需要保持谦逊求知的心态，充分理解用户的问题，这种能力不是朝夕之间就可以掌握的，是需要修炼的。

动起来

任何没有被满足的需求都是一次机会。

我经常会在技术社区看到一些同学分享自己业余时间做的独立产品，有做进销存的、客户管理的、在线客服的，还有解决问题的各种小工具，而且有的同学还挣到了钱。

我并不是想说让大家都去搞钱，而是说要善于发现问题、找到机会，然后动起来、去实践，实践的过程中我们可以发现更多的问题，然后持续解决问题，必然能让自己变得越来越强。在经济不太好的情况下，我们才有更强的生存能力。

啰里八嗦一大堆，希望能对你有所启发。

关注萤火架构，加速技术提升。