2025-11-21 20:58:12
1.项目背景与目标
2024年初我被领导安排参与北京某项目担任软件负责人，该项目的主题词是“智能”。
2.项目团队与分工
该项目涉及5家单位，其中2家民企，1家研究所，1家高校，还涉及技术总体的一个部门。1家民企提供三维地球、1家民企负责评估、高校负责智能、技术总体的部门负责提供仿真引擎，项目管理机关为了省事强行将研究所的项目打包到我们的项目。 项目成员，除了外协外，巅峰时期6人，最少时期4人。
3.项目执行过程
2023年底，我记不清是哪个月，该项目的负责人找我，让我他们看看投标方案，我依稀记得他们在做投标的视频； 2023年底，我与我们部门的组长去技术总体的研发现场看了一下他们的仿真引擎，觉得能用； 2023年底，项目组的成员问我在Ubuntu上把引擎编译启动； 2023年底，该项目的负责人找我让我跟着去技术总体对接一下仿真引擎的事 2024年1月，我与技术总体加上了微信，算是正式参与了该项目； 2024年，项目负责人说软件需求所审没通过，主要篇幅太少，让我带领项目组成员按面向对象方式扩充篇幅； 2024年2月，驻场的开发； 2024年8月，我脱离项目； 2025年9月，某个会议上专家提了要适配国产化硬件，项目的其他人搞不定，领导让我救场； 2025年10月，项目定版失败，领导安排多个人员救场，我参与文档工作； 2025年10月，项目定版成功。
4.成果与数据分析
- 认识了一个新的仿真引擎
- 结识了一些朋友，认识了专家
- 写了一些专利或论文‘
- 拿了一些工资和差补
- 理清了定版的流程 对了以后这个软件肯定还要报奖。
5.经验与教训总结
5.1不要相信口头语言
不要相信语言，这里指的是两方面，一是不要相信口头的承诺，二是严格遵守纸上的文字。 不要相信口头的承诺 项目开始初期技术总体一直催着要看软件成果，几乎到了一周一看的地步，我们的外协厂家忍受不足，不断口头承诺加人，却一再推迟，承诺两人实到一人，承诺这个星期，推迟到下个星期，承诺经验丰富，实际刚刚毕业。最后我们中止了他们的合同，换了一家外协。 严格遵守纸上的文字，哪怕它是错误的， 场景1：项目的开始技术总体，一直强调该项目名字虽然有智能二字，但重点不在智能，后续的评审几乎每次都有专家问智能二字何解？从开始的软件需求外审，到最后的定版审查，一直有人在问，最终甚至到了不回答就无法通过的地步。 场景2：研究所的系统是项目管理中心为了省事，强行将他们作为我们的乙方，这样他们就只用管理一个项目节省了工作量，此后评审不断有专家质疑他们的系统与我们系统的关系，最后牵强的找了一个结合点融合在了一起。 场景3：总体技术方案中的有些接口是冗余的、描述不准确甚至时错误的，需求外审时，专家提出疑问，“需求的接口为何与总体技术方案对不上？你们一个字都不能改！” 场景4：”你们没把研制要求当回事！你们忽略了前半句“，定版审查会上专家带着愤怒 文字上的东西是我们的输入，是一切的起点，必须细细揣摩、认真分解，软件可以没有，评审看什么，看的就是纸上的文字。在人员够的情况下紧扣合同、研制要求、立项审批等顶层输入文档，逐字分解，在后续的文档（方案、需求、设计、测试）、软件、汇报，作出响应。这样在最后的定版就会做到从从容容游刃有余。
5.2文档的重要性
由”不要相信口头语言衍生出“本章节，一个项目要多少文档？从商务上的《投标方案》、《合同》，从工程管理上的《软件研制任务》、《总体方案》、《开发计划》，再到软件开发过程中《需求规格说明》、《软件设计说明》、《测试大纲》、《测试报告》、《用户手册》、《用户试用大纲》、《用户试用报告》、《研制总结报告》、每次开会时的《签到表》、《意见表》、《咨询费发放表》、给各家单位发的《函》，最后还要产出一个《研制总结》，每个阶段都要产生文档，前一个阶段的文档是后一个阶段的输入，环环相扣，这些或真或不那么真的文档形成了一条证据链，最终归了档，我想很快也许明天就没人关心软件能否运行，运行在什么操作系统，适用的场景是什么，但迟早由一天审计人员会带着翻看这些文档，问项目负责人，这个合同的外协费用是否超过标准。文档占据了项目组成员的大量时间，大家大部分时间只看文档，评审的也是文档，只能透过文档的描述想象软件做了什么。
5.2人最不靠谱
这也是两方面，不靠谱涉及两个方面，一个是对具体的人的行事作风的马虎、易错的描述，一是人员角色在项目中的支撑性的描述，主要从两个方面进行阐述。 场景1：外协人员的不靠谱，外协人员的水平参差不齐，有刚毕业的，有工作十年的，有能力强的，有能力弱的，有责任心的，有想跑路的，有适应加班的，有一点班都不愿意加的，形形色色。我认为的解决办法，1.将工作落实成文字，列出时间，优先级，负责人。2.最好让他们来一个现场的负责人，这样不用对每个外协人员进行对接。3.和外协的领导沟通很重要，搞不定只能以合同压着他们的领导派人了。 场景2：帮忙人员的不靠谱，仿真引擎是别人的，在我们请教了多次后工程师渐渐不耐烦，这是没办法的事，毕竟他们只是帮忙，我们也只及时能向技术总体反馈，当然反馈也要列举成条目，。 场景3：人本身的局限性，比如写文档时的标点，字体，交叉引用，自己怎么看都无法查出错误，只能让别人来校核，最完美的情况当然是靠代码程序来审阅文档，希望未来能够实现。
5.3汇报的重要性
这个项目的需求从不是那么明确，大到应用场景是什么、怎么个智能法，小到界面风格布局，都没有在需求分析就确定下来，设计文档定版后也没有确定这些，软件工程的生命周期模型在这里就是个笑话，仅仅是个流程，这个项目需求的确定就是一路汇报中确定的，开发过程中，不断有向技术总体汇报，甲方汇报，向评审专家汇报，开了几十次重要的会。汇报要向重点人员汇报，注意是重要人员，在项目初期我们开发了一段时间后，我们向甲方领导进行汇报后，甲方推翻了合同中的需求，提了一个不在合同之内的需求，虽然搞笑的事，我们努力开发了一段时间后，该领导岗位变动，没人关心这个需求了，最后的定版审查也完全没人关心。如果在项目初期，主动用原型软件向甲方汇报系统的整体构想，他确认签字后，我们朝着这个方向开发，会省下很多工作量。
6.个人成长与收获
开始工作时我想着好好写代码钻研技术，现在以最少的精力完成及格线的工作，代码什么的交给外协好了。开始工作时七点下班觉得很晚了，现在八九点觉得已经很好了，还降薪了。
