自己开发管理系统，卡在哪三处？

团队越来越依赖系统，"要不要自己开发一套"这个问题就被反复提起。理由听上去都很实在：需求自己最清楚，不必迁就现成的做法；想改就改，不用等别人排期；数据放在自己这边，边界看得见。这些理由都是真的。可真正开工之后卡住的项目，多半不是因为写不出代码，而是因为三件与代码无关的事——需求会在开发过程中不断长大、上线之后需要有人长期接着维护、以及业务与技术之间那些说不清的共识。本文不评价"自己做"和"用现成的"哪个更对，只把这条路上大概率会遇到的事情摊开，供判断时参考。

自己开发看起来好在哪里？

先把吸引力说清楚，后面的坎才有比较的意义。第一是贴合：功能跟着自己的做法长，不必为了迁就软件去改流程。第二是节奏：先做哪一块、什么时候让业务用上，由自己定，不用等版本排期。第三是掌控：数据存在哪里、谁能看、留多久，边界都是自己画的。这三条确实是最有价值的地方，也是不少团队愿意投入的原因。但它们有一个共同前提——项目能顺利走到长期运行。多数半途而废的项目，问题恰好出在这个前提上。

第一处：需求会在开发过程中不断长大

立项时能说清楚的往往只有一句话，比如"要能看客户"。开工之后，具体的想法才一个个冒出来：还得看是谁改的、还得按地区分、还得能批量导出。这些补充需求单独看都合理，堆在一起就是工期一次次顺延。更深一层的问题是内部意见不统一：销售想要一套做法，售后想要另一套；有人要求简单，有人要求全面。如果没有一个能拍板的人，开发方只能把所有意见都做进去，结果哪一头都不满意。比较现实的做法是三步：先定一个最小闭环，让一条主线先跑通；把明显还会变的部分留出调整空间；再约定一个统一的变更窗口，避免每天改一点。

第二处：上线之后，谁来接着维护

开发是有终点的，维护没有。上线只是这件事的开始：环境会变，服务器、系统版本、浏览器都在更新；数据会涨，越用越多、越用越慢；问题会来，报错、卡顿、误操作都需要有人接住。这些事都需要随时能找到一个人，而这个人往往就是当初写代码的那个人。一旦他调岗或者离开，接手的人要先读懂别人写的逻辑，才谈得上修改——这段时间里，业务只能等。

这三段的难点性质完全不同，但很多人立项时只算了第一段。也正因为如此，"有没有人长期接着做"这个问题，比"能不能做出来"更值得先回答。

第三处：会写代码的人，不一定能替业务定规则

系统能不能用起来，取决于规则怎么定：什么情况算成交、哪些信息必须填、谁能看到谁的数据、一处改了别处要不要跟着变。这些规则业务人员未必说得清，开发人员又猜不出，必须有人把它们翻译成明确的、没有歧义的约定。缺了这一环，做出来的东西常常是"功能都有，就是不好用"——字段一大堆，没人愿意填；绕来绕去，一线宁愿回到原来的做法。所以自建项目里真正稀缺的往往不是开发人手，而是能把业务说清楚的人。

怎么判断该自己做还是用现成的？

把几个维度摊开看，判断会清楚很多：

这张表不给出结论，它的用处是把"想自己做"和"适合自己做"分开。想自己做通常来自对做法的熟悉，适合自己做则取决于人手、时间和需求稳定性——两者不一致时，项目风险往往就藏在这里。

还有一种折中：核心用现成的，外围自己做

不少团队最后走的不是二选一，而是分工：把客户、订单、售后这类标准化程度高的环节交给成熟产品，把真正体现差异的那一小块留在自己手里。这样做的前提是把边界画清楚——哪些数据以哪边为准、两边怎么对应、谁负责同步。边界画不清，折中就会变成两头维护、双份录入，比单一路线更累。

常见问题

问：先做个简单的，以后再慢慢加，可行吗？
答：这是比较稳的路径，前提是"简单"指的是主线功能少而完整，而不是结构上将就。结构一旦将就，后面每加一项都要先补前面的欠账。

问：开发人员离职，项目就废了吗？
答：多数情况不至于废，但会停摆一段时间。想减少损失，平时的文档与交接比事后的补救有用得多，这也是立项时就该谈清楚的事。

问：业务部门自己用现成工具拼一套，能行吗？
答：小范围、单人使用往往可行；一旦涉及多人同时更新、权限分级和长期留存，就需要有明确的责任人和规则，否则数据很快会散成多份。

自己做还是用现成的，最后比的不是技术能力，而是团队有没有把需求说清、把人留住的准备。工具只是承载规则的容器，容器再好，规则不清楚，里面装的东西还是会乱。