今天，是肖潇作为项目主管负责的第一个项目组织召开设计定型会的日子，虽然已经身经百战，但她还是有点紧张。

设计定型是国家对新研制的军工产品进行考核，确认其达到规定的设计标准，并按规定办理审批手续的活动。经过设计定型的项目，产品的技术状态已经固化。

技术状态是指在技术文件中规定的并在产品中达到的物理特性和功能特性。按照国家有关装备研制程序的规定，武器装备的产品实现过程一般分为论证、方案、工程研制、设计定型和生产定型五个阶段，其中工程研制阶段的主要任务是通过初样机、正样机的设计、试制和试验，实现产品设计方案所确定的功能特性和物理特性，满足使用要求。武器装备的工程研制过程就是产品技术状态逐渐摸索、趋于固化的过程，研制阶段结束的标志就是通过设计定型，它是对完成设计的产品战术技术指标和作战使用性能进行全面的考核，认定的就是产品技术状态。简单来说，产品的技术状态主要包括设计文件、材料清单、工艺文件等。

距她刚接手这个项目已经过去两年了，能够把一个项目从论证立项一直做到设计定型的确不是一件容易的事情。中间经历的幸苦只有她自己清楚。

会议很顺利，用户在会上对肖潇所作的工作表示了感谢，也肯定了她的工作能力。肖潇也表达了感谢，表示后续一定更加努力，把用户在研的其它项目做得更好。

然而项目定型并不意味的问题的结束。

这天，肖潇接到对方项目主管的电话。原来，前段时间刚刚定型过的项目，因为在一个新型的武装车上装备，用户使用过程中发现有一个结构的外形特征影响产品的拆装，希望能够对这个特征做一个修改。

对于用户的这个要求，肖潇知道没这么简单，她说：“对于定型的项目如果要进行这样的设计更改，按国军标关于产品技术状态更改的要求，理论上至少需要两厂四方共同确认，这个流程走起来可不简单”。

“嗯，是的，因为改到很小，对产品的使用和可靠性都不会有什么影响，所以我们领导的意思是尽量不要走这个流程”。

听用户这么说，虽然很为难，肖潇还是先答应了对方的要求，“我先想办法解决吧，但是不一定能够搞定”，她说。

军品的技术状态更改，尤其是设计定型后军品的技术状态更改，不是一件简单的事情。

技术状态更改是指在产品寿命周期内，对已正式确认的现行技术状态所作的更改。

依据GJB3206A-2010《技术状态管理》第6.2节技术状态更改的要求，技术状态更改的一般流程为：

1、判定技术状态更改需求

2、确定技术状态更改类别

3、编制技术状态更改申请

4、评审技术状态更改申请

5、审批技术状态更改申请

6、编制技术状态更改通知

7、实施并检查技术状态更改

产品技术状态的更改应遵循论证充分、实验验证、各方认可、审批完备、落实到位的原则。因为用户需要对产品的外形尺寸进行调整，属于要求最为严格的一类更改，必须严格按照以上的程序走流程。

肖潇判断，这个流程是无论如何都走不下去的，首先更改的需求就没有来源。对于设计定型的项目，公司有明确规定，提交技术状态更改申请，必须有用户的明确需求，这是红线。

就算公司勉强允许申请，因为用户明确表示不想参与到更改的程序里来，流程是绝对走不下去的。

为此，肖潇找了质量部经理、分管质量的领导、自己的分管领导等都进行了深入的沟通交流，希望能有个一好的办法能够解决这个问题。但是，交流一圈下来，没有任何的办法。

“为什么一个这么小的更改需要走这么复杂的流程呢”？肖潇找到张晟寻求意见。

“这只是我个人的理解”，张晟表示，“军品的技术状态管理为什么会这么严格，主要的原因在于装备本身是一个很复杂的系统，作为系统中每一个小的设备，任何的一个技术状态变更会对装备最终的性能产品什么样的影响，不是你自己可以评估的。比如对于一架已经设计定型的飞机来说，如果每一个分设备厂家都为了减轻咱们发动机的压力，各自进行减重设计更改，最终的结果可能是导致飞机重心的偏移，想想这问题够严重了吧。而事实上，一个不经意的微小更改，导致飞机失事，机毁人亡的事情是真实发生过的”。

“所以说，从更高的层面来说，对产品进行严格的技术状态管理是非常有必要的”，张晟总结。

“我的问题怎么解决”，肖潇自然同意张晟的观点，但是用户的要求就摆在那，作为一个项目主管，用户的需求不能不考虑，而且这也是最终用户的需求。

“事实上你怎么决策都不会有问题，毕竟这件事情怎么做都没那么容易”。

“话是这么说，肯定会有更好的办法吧”，肖潇继续说。

看张晟不说话，肖潇知道他可能也不要太好怎么建议，她说：“那你说说如果是你大概会怎么做”？

张晟想了想说：“如果是我的话，我会首先想办法帮用户解决问题。可以先和用户商量能不能去装备现场实地看一下具体的情况，只有在现场才有可能知道真正的问题所在，也才有可能找到更好的解决办法”。

肖潇认同张晟的说法，便和用户协商去了装备现场。

经过现场的实际调研和交流，肖潇认为更改本身是有必要的。现场有其它公司提供的用于装备的产品，外形就是用户希望更改成的状态。所以更改后肯定不会对整个系统产生什么不利的影响。

回到公司，肖潇把实际的情况又和各方面进行了交流，虽然大家在技术上表示赞同。但大家都建议她按照国军标的要求走更改程序。

为此，肖潇再次和用户的项目主管进行了沟通，希望能够按更改程序办理。“这点事我们没办法走流程，用户希望下批交付的产品是更改过的，否则可能就不接收了，你还是尽快吧”，这是用户最终的答复。

“程序重要还是用户重要”？张晟能理解肖潇的难处，他接着说：“程序的目的是什么？我觉得你可以先好好思考一下这个问题”。

肖潇当然知道张晟的意思，她也听说过很多为了产品交付而不得不违反工作程序的事情，其中的门道她也大概知道一些。但是，自己真的碰到了这种事，感觉压力还是很大的。

三个月过去了，新的一批产品完成了交付，从用户那得到消息，产品的改进没有问题，后续可以按这个状态继续交付。

“能够让用户满意应该是最好的选择吧”，肖潇心想，“但是在程序和用户要求之间应该还有一个平衡点存在吧？这个点在哪？应该如何把握？”肖潇有了更多的迷茫。