本文首发于公众号「技术落地手记」，一个国企技术管理者的实战笔记。关注回复「落地」获取更多技术管理实践。
从2014年开始用第三方研发管理系统RDMCD，一晃十二年。
这个时间比我团队里很多同事的工龄还长。RDMCD见证了我们团队的成长，也见证了无数需求从白板上的一个想法，最终跑在线上。
开源免费、稳定可靠，那些年RDMCD真的帮了我们很多，没有收过一分钱。
但2026年上半年，我还是把它换掉了。
不是RDMCD变差了，是我们变了
说实话，RDMCD本身没什么问题。我们团队的研发流程比较常规，RDMCD基本能满足，无非是需求收集和任务分配这些事。
但随着时间推移，有几个具体的摩擦点越来越让人难受。
周报这件事
每周五下班前，员工要写周报。这是全团队最痛苦的一个小时，一边是还没收尾的工作，一边是急着下班度周末，挤出来的东西质量可想而知。
更麻烦的是，到了季度末、年末要汇总工作量，RDMCD帮不上什么忙。数据是在里面的，但要出成像样的报告，得自己去查数据库，根本不是拿来就能用的东西。
通知这件事
需求上线了，要人工通知需求方，因为RDMCD的webhook打不通微信。我们整个日常沟通都在企业微信，这条通路断着，每次上线都得有人去挨个发消息。
最核心的是AI这件事
这才是我最终下定决心的原因。
现在AI已经可以在需求分析、产品文档、架构方案、代码、测试用例这些环节里帮很大的忙，不是百分之百，但在人工审核的前提下，效率提升是实打实的。
我们想把AI嵌进研发流程，但RDMCD是个相对封闭的独立系统，想接什么AI能力、想怎么接，它给不了这个灵活度。
这三个问题摆在一起，我开始认真想，与其每次在一个不够顺手的系统里将就，不如自己造一个。
以前算不过来的账，现在算过来了
以前这个念头冒出来，很快就会自己灭掉。
一个研发管理系统，不复杂，但也不是几天就能搭出来的，要立项、要拉人、要算时间成本。算来算去，可能最后还是算了。
但现在有AI辅助编程，这个账就不一样了。
两周，第一个版本上线，投入日常使用。
这个速度让我自己都有点意外。也更坚定了一个判断，AI辅助编程真正改变的，不是代码质量，是自研的决策门槛。以前「要不要自研」的核心顾虑是时间和成本，现在这两个顾虑都小了很多。
这套系统长什么样
既然是自研，就完全按我们团队的实际工作方式来设计，没有多余的功能，能用就行。
需求分两种
研发需求走完整流程，需求评审、UI设计、开发、测试、上线，适合新功能开发这类多岗位协作的工作。
事务需求简化流程，评审通过直接分配执行，日常运维、数据处理、简单改动，不需要走整个研发流程的事情用这套。
优先级P1到P4四个档，紧急程度一眼看清楚。
三个看板
团队看板是给负责人用的，所有需求的进展状态扫一眼就清楚，待确认、设计中、开发中、测试中、已完成。
个人看板是给每个人自己用的，登录进来看到的就是自己的任务清单，进行中的任务、待处理的Bug、本周完成的工作，不用翻来翻去。
测试看板是给测试和运维用的，测试同事验完点一下，运维上线后再点一下，整个闭环就完成了。
工时自己填
取消了复杂的审批流。任务开始时自己填预估工时，完成时自己填实际工时。
这个设计的前提是信任。小团队老同事，都在一个办公室，谁干了多少活大家心里有数，没必要为了管控搞一堆流程来互相消耗。
周报自动生成
这是团队反响最好的功能。
本周完成了哪些需求、哪些任务、处理了哪些Bug，系统自动汇总，不需要做任何的额外工作。
再也不用周五下班前绞尽脑汁想「这周到底干了啥」。
需求上线自动通知
上线后系统自动发通知到个人微信，需求人、需求人的上级、部门负责人，可以自己配置，不用人工一个个去说。
AI辅助，持续接入中
目前已接入的，根据需求描述自动生成标题，减少一个小摩擦。
后续计划的，需求分析、测试用例生成、代码审查建议，想接什么就接什么，不受第三方系统限制，这是自研最大的优势。
版本记录
需求每次修改自动创建新版本，改了什么、为什么改，都留着。
产品和开发之间「我当时说的不是这个意思」这种扯皮，基本消失了。
系统界面
用了一个多月，感受如何
最明显的变化是团队周五下班时心情更轻松了，主要是周报这件事。以前每周五都像一场集体受罪，现在大家不需要做任何额外的总结，反而会收到本周的周报。
当然也有不完善的地方，边用边改，这是自研系统的常态，我们接受这个。
如果你也在用RDMCD或者其他研发管理工具，但总觉得「哪里不对劲」，我的建议是，先把那个「不对劲」具体化，找到是哪几个具体的流程点让你每次都烦。
如果只是感觉差点什么，那可能是心理问题，换个工具也不会好很多。
但如果那个摩擦是具体的、高频的，那现在重新算一下自研这笔账，结果可能跟以前不一样了。
以上是我们的真实经历，不一定适合所有团队，仅供参考。
如果你的团队也有类似的困扰，欢迎聊聊。
