技术经理投标

文章目录

作为一个技术经理，最核心要保证的就是: 按时上线、系统稳、少返工、出问题有人兜底

你们汉得项目经常驻场，如何管控开发进度，避免延期上线？

标准规范：我们有统一的开发规范，有开发、测试、生产三套环境

前期拆分：技术工作量的评估，拆分里程碑；

编排开发计划：双周滚动计划

每周同步机制：每周固定例会同步进度、阻塞点；

分层开发：公共组件先行封装，

review代码：把控项目风险

预留兜底：提前预留 10% 工期缓冲用于 bug 修复

驻场兜底：核心开发 + 技术经理现场驻场，突发问题当日解决

成果沉淀：梳理项目技术难点、解决方案、优化经验，形成项目知识库

意外情况：

①做好预案：出了问题除紧急修复外，日常也要做好预案，定期安排人手值班，对于常见可能的突发问题都要提前准备

②协调人员：协调公司的专家中心的人员

③驻场兜底：核心开发 + 技术经理现场驻场，突发问题当日解决

需求中途频繁变更怎么处理，会不会额外加价、拖工期？

区分优化微调、需求漏项、颠覆性改版三类：

微调（小字段、页面按钮）：我方免费优化，不计额外费用；
漏项需求（前期需求文档遗漏）：小范围免费增补，大范围出具变更清单、工时报价，双方确认后落地；
颠覆性需求：出具方案、工期、报价，所有变更书面留痕，双方确认。

项目人员离职（汉得人员流动大），如何保证项目不断档？

标准化交接文档：接口文档、数据库设计、部署手册、坑点台账全部归档，项目知识库统一沉淀；

内部备份：每个核心模块配备 AB 角，1 主 1 备 Java 开发，我作为技术经理统筹全项目代码；

原有系统是老单体，我方要做定制开发，如何兼容老系统，不影响现有生产？

接口隔离：新 Java 服务通过 API/ESB 对接老系统，不改动老系统核心代码；

环境隔离：开发、测试、生产三套环境，所有改动先测后上线；

灰度上线：新功能灰度放量，切流量试运行，出问题一键回滚；

数据双写：关键业务初期双落新旧库，过渡期平稳再切换。

系统突然宕机等应急处置流程是什么样的？

5 分钟响应：驻场人员第一时间定位，核心开发 + 技术经理现场介入；

分级故障：P1 生产阻断优先重启降级兜底、临时切备用方案，保障甲方业务能用；P2 功能异常当日修复；

事后复盘：出具故障报告，优化代码 / 定时任务逻辑，规避同类问题；

除紧急修复外，日常也要做好预案，对于常见可能的突发问题（如：死锁、宕机、OOM等问题）现场运维都需要提前演练，紧急时刻知道该怎么处理。而且数据库备份等方式做好兜底。

数据敏感，如何做权限管控、防止数据泄露？

应用层：RBAC 权限体系（权限集分给角色，角色分给用户，这样用户只拥有对应角色的权限）

数据库：生产库开发人员无删除 / 修改权限，线上改数据走审批流程；

操作留痕：关键数据变更日志审计，可追溯操作人员。

项目上线结束后，后期运维怎么保障，是不是做完项目就撤场？

上线初期 1-3 个月驻场运维，保障磨合期问题快速处理；

后期：找对应的技术经理和项目经理都是可以给协调到人给处理的。也可签署年度运维框架，按需驻场，不会项目收尾直接撤人甩锅。

涉及到业务问题：

不同企业 SRM 业务规则差异很大，细分业务落地细节我暂时没法精准给到方案；

我们先摒弃这个业务，单纯从技术角度，您如果是觉得接口集成、并发性能、数据一致性或者其它什么方面有技术难点，我可以从技术落地角度帮您拆解分析。

汉得是业务和技术分离，我这边的主要任务是把文档和设计转为代码，做好技术团队的管理规范和进度的把控，

SRM业务流程

第一阶段：供应商准入 → 在线注册 → 资料校验 → 黑名单检查

第二阶段：供应商评估 → 初审 → 联合评审 → 现场审核 → 分级入库

第三阶段：采购需求 → PR 单提交 → 审批 → 生成采购计划

第四阶段：寻源与定价 → 询价/招标 → 供应商报价 → 评标定标

第五阶段：合同管理 → 起草 → 审批 → 签署 → 归档（合同管"怎么买"，订单管"买什么、买多少、何时要"）

第六阶段：引用采购申请/ERP同步订单 → 订单维护 → 订单发布（采购员手动点击发布或根据规则自动发布） → 供应商确认订单 → 送货协同 → 发货 → 收货质检 → 入库 / 退货

第七阶段：结算付款 → 对账 → 三单匹配 → 付款审批 → 执行付款

第八阶段：绩效评估 → 数据采集 → 评分 → 评级 → 优胜劣汰

新材料想上市，能源板块不上市，从业务的角度是同一套系统，从数据库角度需要分库分表，这个该我如何实现？

①两条内部业务线，用「业务编码 biz_type」做分片

②用租户分库，通过动态数据源路由在运行时根据租户标识切换到对应的数据库。

分库分表中间件：ShardingSphere

spring:

shardingsphere:

datasource:

names: ds0,ds1

ds0:

url: jdbc:mysql://host:3306/newmaterial_db

ds1:

url: jdbc:mysql://host:3306/energy_db

rules:

sharding:

default-database-strategy:

hint:

algorithm-class-name: TenantHintShardingAlgorithm

SRM供应商模块是外网访问，采购方是内网，如何实现外网访问？

DMZ 区部署 SRM 应用

公网 → 外网防火墙 → DMZ 区 Nginx → 内网防火墙 → 内网 API 网关 / SRM 服务

一、完整数据流（你说的映射逻辑）

DMZ 只放 Nginx（反向代理 + SSL + 域名解析）

公网域名解析到DMZ Nginx 公网 IP

外网防火墙只放通 443 到 DMZ Nginx

Nginx 做反向代理转发，转发地址填：内网网关地址：端口

内网防火墙放行：DMZ 网段 → 内网网关端口

内网网关再转发给后端 SRM 应用、ERP 接口

供应商电脑(公网随机IP)

→ 浏览器访问 https://srm-supplier.xxxcompany.com:443

→ 运营商DNS解析到203.120.50.10

→ 边界防火墙放行443，DNAT到DMZ-Nginx(192.168.20.10:443)

→ Nginx反向代理 → DMZ-SRM应用(192.168.20.20:8080)

→ SRM需要查ERP订单 → 跨防火墙访问内网ERP(192.168.10.30:8090)

→ ERP查内网数据库(192.168.10.40:3306)

→ 原路逐层返回数据给供应商页面

数据安全、权限分级、数据备份与故障恢复相关保障？

数据安全：

存储方面：①主从复制，主机宕机后切换到备机；②多主复制。
网络层通过https，使用 JWT Token传递用户信息，避免明文传输。通过XXS攻击防范策略（每次请求都带随机令牌）、跨站请求伪造(CSRF攻击：防止一些带js语法的文字输入)、SQL注入（防止入参里面含or 1=1）防范策略等防止系统被攻击，保证数据安全。定义文件类型白名单，禁止上传 .exe、.sh、.jsp等可执行文件。上传目录禁止脚本解析权限。

权限分级：

RBAC权限体系；

数据备份与故障恢复：

支持日常备份（每天）、定期备份（每周/每月）和特别备份。定期做灾备恢复演练。

SRM系统未来的迭代优化方向？

1、智能化升级：引入AI智能报价、智能风控、智能预警、智能对账，进一步实现无人化、自动化办公；

2、数据化赋能：强化数据看板、数据分析能力，为供应链决策、成本管控、风险预判提供数据支撑；

3、国产化与轻量化适配：适配国产框架、云端部署，优化移动端操作，提升易用性；

涉及到架构设计：

我们都是标准的产品化实施，前后端分离的微服务技术架构，前端使用React，后端是springcloud做的微服务，未来随着齐成业务的发展，可以进行二开调整，可以新增微服务。

部署方式有k8s、linux，中间件...

能否适配我方后续业务扩容迭代需求？

汉得SRM系统采用微服务架构，未来可按照齐成业务成长情况，快速通过硬件扩容的方式，完成服务器硬件对快速发展的采购业务的支撑。

未来随着齐成业务的发展，可以进行二开调整，可以新增微服务。

说明系统后续业务增多能否顺畅承载运行，保障多长时间？

应答：按照目前汉得对齐成电采系统的服务器配置建议，可保障采购方2000个日活跃用户，供应商3000个日活跃用户访问系统，并支持采购方150并发用户数、供应商300并发用户数。可支持采购订单100万行、入库单700万行，结算数据500万行的数据存储、读取能力。如采购业务量未来随齐成业务发展快速上行，可根据数据量增长趋势，进行硬件扩容，满足未来5~10年齐成采购业务的运行新需求。

交接给甲方

系统上线后汉得项目组提供1年的驻场运维保障，质保期内可进行小版本升级，

后面如果需要交接，汉得项目组将从平台技术框架、系统文档、场景运维问题、前端开发技术、后端开发技术、业务操作等多个维度，对齐成内部技术人员进行培训。

AI编程方面：

我们公司统一采用火山引擎 Coding Plan 平台的团队版服务，账号支持研发多人共用，月度总 Token 配额 30 亿，可支撑代码生成、接口开发、问题排查等全研发场景；平台按需调度模型，主力选用智谱 GLM、DeepSeek-V3.2，分别适配通用编码与复杂算法推理开发，灵活控制调用成本。