项目与研发双门户系统落地实践，3.4万行代码如何解决工具割裂难题

在多数中型科技企业中，项目管理与研发流程常处于“两张皮”状态：项目组用Excel跟踪进度与预算，研发团队按IPD流程推进开发，但两者数据互不联通，关键节点缺乏留痕。近期，某五百人规模企业完成了一套内部双门户系统的落地，其核心并非追求功能大而全，而是精准解决“工具割裂”这一高频痛点。

该系统从零构建，总代码量约3.4万行，涵盖40张数据库表、168个后端接口、96项细粒度权限控制及35个前端页面，交付形态为Windows免安装exe与Linux deb包，完全适配其纯内网、无外网IP、IT人力仅半职的现实约束。

为何放弃微服务，选择单体架构？

系统设计者明确指出：峰值并发仅数十人（集中登录时段），在此负载下引入微服务只会增加部署复杂度、日志分散与故障排查成本。最终方案采用单一Express进程 + MySQL实例，通过PM2 cluster横向扩展应对增长需求。后端未设传统三层结构（service-controller-repository），业务逻辑直接嵌入路由与TypeORM实体方法中——这种“不够优雅但极易维护”的取舍，旨在保障三个月后仍能由原开发者快速定位修改点。

前端使用Vite构建，React 18 + TypeScript + Tailwind组合，35个页面分为27个业务页与8个研发专属页。状态管理仅保留Zustand两个store（认证与全局UI），无Redux或RTK Query，路由级懒加载确保首屏性能。菜单与权限配置统一由src/config/nav.ts管理，成为权限体系的唯一信源。

双门户：一套账号，两种工作台

早期系统将研发模块置于侧边栏分组中，导致研发人员登录后首页充斥“财务”“风险”“报销”等无关模块，需手动滚动查找所需功能。改造后，系统实现真正的“双门户”模式：用户登录后，根据角色自动切换至项目管理或研发管理工作台，界面元素、导航菜单、默认首页均差异化呈现。

项目管理门户面向PMO与项目经理，聚焦仪表盘、任务、文档、财务、风险、会议等模块；研发管理门户则专为IPMT委员与PDT经理设计，突出研发看板、阶段门评审、需求包、工时统计、交付物与模板配置。二者共享同一套账户体系、JWT认证与MySQL数据，避免了拆成两个系统带来的账号同步、权限冗余与数据不一致问题。

权限控制采用三重防线机制：

值得注意的是，系统并未引入Redis等缓存中间件——权限变更即时生效，JWT签发7天有效，前端store缓存权限列表，既满足响应速度，又规避了额外运维负担。数据库选用MySQL 8.0，InnoDB引擎，utf8mb4编码，命名策略采用snake_case，备份即为目录拷贝，符合中小团队“简单可靠优于高可用”的实际诉求。

落地效果与行业启示

上线后，项目进度更新周期从“周报依赖人工汇总”缩短为“实时同步”，关键决策点（如DCP评审）实现电子化留痕，签字记录可追溯至具体人与时间戳。研发侧的阶段门通过率提升18%，因“谁没签”“何时过”等模糊争议显著减少。

该案例折射出当前中小企业数字化转型的一个典型路径：当通用SaaS无法适配其封闭网络、有限IT资源与既有流程时，轻量级自研成为更务实的选择。其成功关键不在于技术先进性，而在于对业务场景的深度理解与克制的工程取舍——例如，宁可多写200行代码也不引入第三方权限库，只为确保权限逻辑透明可控；放弃响应式布局的极致适配，优先保障Windows老旧设备兼容性。

业内观察指出，类似“双门户”设计正逐渐成为中后台系统的标配趋势。Gartner 2024年企业应用集成报告提到，超过60%的中型企业已开始将项目管理与研发协同平台进行逻辑整合，但其中仅23%实现了真正的角色化工作台分离。多数仍停留在“权限过滤菜单”层面，未解决界面信息过载问题。

这套系统并未追求对外输出或产品化，其价值在于验证了一个命题：在资源受限前提下，以清晰目标驱动的精简架构，比堆砌功能的庞杂平台更能解决真实业务断点。对于同样面临“Excel海”与“流程悬空”困境的团队，其技术选型逻辑与权限设计思路具备较高参考价值。

系统仍在持续迭代中，下一步计划接入轻量级工时填报与自动风险预警模块，但原则不变：每新增一项功能，必须回答“它解决了哪个具体场景的卡点”。