前言
这次我们不谈技术，而是说说做过的几个奇怪或翻车的项目，为了降低敏感性项目仅以代号称呼，关键信息也一并去掉。这里权当做回顾和总结，切勿对号入座。
具体项目
HS项目
这个项目是一个典型的打野型项目，之前没有跟用户做过接触，项目也没有跟踪。
基本过程
- 业务人员独自完成项目申请
- 拿下后，组织技术人员进行讨论和实施启动
- 但经过研究和分析，发现其中一个关键技术指标在项目额度限制范围内，是无法达到，虽然有可实现途径但会导致项目成本飙升，从而导致亏损。 基本确定了这个指标是埋下的雷，之前业务人员不管可行性一概响应用户要求，对于这种做法我只能嘿嘿嘿。
- 两条腿同时走：1.开始投入研发资源准备高成本实现项目2.联系用户，侧面打听到原来的意向单位
- 最终达成一致，终止自研，外包给原意向单位
- 最终项目已成功验收
结局
good ending
改进点
- 可行性分析进行的有点晚，导致埋雷发现的略晚
- 项目争取还是悠着点，不能乱投
- 自研力量投入有点多，只能当做后期积累
GU项目
本项目是用户升级类项目，原由是他们内部一个平台的推广，就想在我们交付的系统上应用，于是准备了经费找我们对系统进行升级来兼容他们的平台。于是项目就这样开始了，
基本过程
- 跟用户沟通确认要求
- 跟平台商沟通确认对接模式
- 跟平台技术人员沟通获取平台技术资料
- 分析平台技术资料，确认技术路线
- 改造平台的对应组件，抽象出标准API，确保在我方组件和平台上组件的切换只需要配置或是重命名(这个事后被证明是最为正确的决定)
- 开发厂商的API适配器
- 赴现场联调测试
- 先后经过两周的联调测试，完成平台的对接
- 给用户演示，但由于每次加载组件时间都要超过20s所以，每次显示都要重新初始化都耗时20s，用户十分不满，但跟平台厂商协调无果，遂决定对接取消
- 全部修改回滚
结局
项目过去2年了还在扯皮
bad ending
改进点
- 不能光听厂商的人介绍，需要实际观察和使用也许才能发现关键点
- 及早跟用户确认和沟通演示形式，关键指标也需要确认
GX项目
这个项目规模比较大也是比较正式的项目，历时近2年
基本过程
- 项目跟踪
- 项目争取
- 实施，前半程一切正常
- 但相关人员有意或无意忽视对接部分，因此此前已经规划在其他项目中对接，觉得这次肯定也没有问题
- 本来要投入试运行，但遇到不可抗拒力，导致无法验收和上线，项目延期3个月
- 进入验收阶段，初步评审后确认没有实际对接
- 用户不让步，完全按照合同验收，且对于合同的理解和我方有较大的的投入
- 用户仍然不让步，项目完全按照用户理解实施
- 研发团队确认改造内容和技术路线
- 投入研发力量进行改造
- 完成改造
- 对接协调，对接方也不让步，没有费不对接
- 跟对接方签订补充合同
- 赴用户单位，进行现场部署和对接
- 发现现场环境与预期不一致，且安全要求涌现
- 再次投入研发力量现场对系统进行修改升级
- 发现根据用户安全要求，无法使用原有对接接口，调整接口参数，但与对接方谈崩
- 项目推迟，团队撤场
- 用户协调，最终减钱让步验收(这步尚未完成)
结局
good ending
改进点
- 项目开始时就明确对接方的责任和内容
- 项目开始时就明确用户整体对于系统的安全要求以及对对接的要求和规范
FZ项目
这个项目是最近做的，一个意向项目，没有任何合同或协议，只有口头承诺，项目极其复杂至少涉及甲乙丙丁四方
基本过程
- 前期沟通和演示的天花乱坠
- 可行性分析显示，必然亏损
- 项目初期乙方催的很紧
- 乙方提出限定开发技术栈和场地
- 需求分析过程初期表现和不满
- 需求分析中后期总是无反馈或是还可以等模糊结论
- 完成需求规格说明书和概要设计的初步编写后告知不用做了
- 项目取消
结局
bad ending
改进点
- 演示内容和实施内容要匹配，前期天花乱坠后期变成乞丐版一般人接受不了
- 涉及多方协作的要谨慎，对于甲方信息同步基本是零
- 商业合作不要天真
总结
- 形成一套高效并有效的研发流程，可行性分析和启动不可缺少，参看HS项目
- 关键指标形象确认，有时候纸面上的一个数字往往无法让用户明白，别等用户看了真系统才反应指标不合适，参看GU项目
- 合作方关键问题的现场考察至少要实际视频来确认，参看GU项目
- 各方要考虑周全，你以为的不一定是他们以为的，参看GU项目
- 合同或要求明确到位，模糊挖坑往往是坑自己，参看GX项目
- 业主要求和规范要跟实际负责人员确认和对齐，参看GX项目
- 空口无凭，风险自己承担，参看FZ项目
- 竞争无处不在，你不行必然有人取代你，就算你能行也有可能更强的人来挖墙脚，参看FZ项目
这些项目现在回想起来都让人唏嘘不已，吃一堑长一智，希望大家不要在同一条轨道上翻车。
原创文章 155
获赞 81
访问量 22万+