ARCHIVELIST · 368 POSTS AAPL$---- GOOGL$---- NET$---- CLOCK UTC --:--:--
北京 --:--:--
POSTS368 CATEGORIES3 TAGS49 PAGES7
LAST UPDATE2026-09-06

按分类着色: 生活 · 技术 · 设计。 左侧竖条为轨道标识,中间为分类徽章,右侧为标题。点分类、标签或 KPI 可跳转对应归档。

design lives tech 紫砂 48 人生感悟 45 随笔 31 社会观察 25 设计 17 数码 14 软件工具 14 道教 14 中医 13 佛学 13 美食 13 建站 12 职业 12 职场 12 书画 11 人际 11 民俗 11 科普 11 旅行 10 自然 10 养生 8 国学 8 影视 8 怀旧 8 诗词 8
tech 2024-06-16 · 721 字 · POSTS

可能是最奇葩的项目了:昨天,在微信群里跟甲方吵了一架

发布 2024-06-16 15:51 修改 2024-06-16 字数 721 阅读 约 3 分钟 职场社会观察

可能是最奇葩的项目了:昨天,在微信群里跟甲方吵了一架

1 背景

1.1 项目背景

  • 项目是一个软件设计、实施项目,今年1月份被调到这个项目做项目经理。

  • 主要功能是各职能部门用户在系统中录入各种计划,系统进行校验后执行并记录结果、通过数据库写入直接反馈至ERP系统。

  • 甲方之前的软件供应商没有做好,硬件设备杂牌、软件硬件的通信反馈耦合度高,几乎每天都会莫名其妙的出问题。

  • 原乙方已经不运维,甲方已经将乙方撵出。

  • 公司领导为了拿下项目,口头承诺要负责原系统的运维。

  • 根据原系统的业务逻辑做了优化,重新从头搭建新系统。

1.2 原系统的知识转移

  • 业务需求文档:0

  • 业务详细设计:0

  • 开发说明书:0

  • 源代码:0

  • 业务流程图:0

  • 硬件布线或者网络图:0

  • 无测试环境

总之,就是除了一个系统能登录进去操作,其他全部没有。

1.3 原系统运维

  • 各种奇葩的故障找不到原因,无法分析。

  • 遇到问题,只能直接干数据库,直接修改数据。

2 新系统开发

  • 业务详细设计不签字

  • 会议纪要不签字

  • 测试时候:要兼顾工厂业务(24小时)流转,等业务不忙的时候才能现场测试(满拉高浓度硫酸的车辆来来往往,有危险)

  • 测试阶段被是不是中断,因为硬件设备被占用

  • 合同截止日期已过,期间被占用的时间甲方倒是承认,可以顺延

3 矛盾爆发原因

明确沟通是有一项的页面数据是通过系统“手工录入”,但是实际要求却是“点击按钮来通过接口来获取数据”,

在微信群里,说我“理解偏差”,我回复“会议室里面这么多人,难道都理解错误?”

….

说:“如果手工录入,那还不如让员工写在纸上,手工录入有什么意义?”

回答:“意义就是在系统中能够查询到”

….

矛盾到极点了。

回复:“我不同意手工录入”

….

4 解决方式

  • 重新制定上线策略,工作细分、责任到人

  • 以专业程度来纠正偏差

  • 情感安慰