信息化项目甲方避坑指东之二
本篇是避坑指东的第二集，既然是第二集，很显然高潮还在后面，现在依然是会让人焦头烂额的项目前期。这个系列可能会持续地写到年底，也可能戛然而止。大型信息化项目的复杂性，都是在信息技术之外的。
笔者：国际认证信息系统审计师、软考系统分析师、软件工程硕士
就如电影情节通常都会在正叙的过程中插入闪回，笔者这个避坑指东系列，在顺序推进剧情之前，也要先回溯一下这个信息化项目的预算阶段，说说应该如何在信息化项目预算制订过程中避坑。
没看过第一篇的，可以先了解一下前情：
这个信息化项目的总预算规模不少，过千万了。但它的预算方案实质只是一个虚数，是在各种情况合力之下的产物，那么对于两级甲方（见上一篇内容），又要如何避坑呢？
正常情况下，信息化项目的预算应该基于用户需求和信息化环境情况确定，需求的确定过程应基于收集需求反馈、进行需求分析和给出概要设计的软件工程过程进行，一环扣一环地实现完整闭环和前后呼应。
但实际上信息化项目在制订预算的时候并不一定会严格按照这个过程，更多的只是拍脑袋。
原因也很简单，要实现这个严谨的过程需要甲方有软件工程专业知识的人，对于超大型集团化企业来说会有这样的人才，但对于其它规模的甲方，又或者是政府部门、事业单位来说，就不见得一定会有。
如果甲方内部没有这样的人，就只能对外委托，这就要产生费用，而这个费用也要先做预算：这对于甲方中层管理者来说，是过程上的无效延伸；对于甲方高层管理者就会理解为要买只鸡做菜还要专门搭配买酱油的无效支出。所以大概率都是会砍掉的。
除了前期费用之外，还有一个因素就是项目是有可能会被整个砍掉不立项。对于信息化项目责任部门来说，如果花了大功夫最后项目连预算都过不了立不了项，那还不如事前别花那么多人力和时间，把精力集中到在建的项目上去，等到预算通过了项目立项了再把事情做实。
其实关键在于控制风险，只要风险控制住了，项目实施建设的目标就能达到。
按第一点的分析，大家都知道了，大多数信息化项目确定预算的因素和实际的需求内容两者之间不会有太大的关系，只是基于模糊大概的认识而设计的一个数字。
那预算怎么定？如果不拍脑袋，那就只能找潜在的乙方单位定了。这个过程很不好说，对于甲方来说风险比较大......非常大。
只能拍脑袋了，但拍也必须要拍得科学点。关键招数在于：
1、寻找可靠的参考
上网搜索和自己的项目内容相似的项目招投标信息，综合这些信息估算一个神仙数，围绕这个神仙数写个从数千字到数十万字不等的说明材料......总之要写到最后自己都信了才行。
如果可参考的是公开的招投标信息，务必将其附带作为项目预算方案的支撑依据，从建设内容的相似性表述预算的合理性。
如果实在找不到支撑依据，找朋友打听一下业务同行类似项目的建设实施费用，即使难以拿出书面材料，也起码对设计的预算心中有底，在需要对预算进行口头解释时就能沉着应对了。
2、寻求专家支持
然后，举办专家论证会，由相关业务和技术专家对预算方案进行评审论证。这一步是必不可少。
专家费也没多少钱，现在各地一般都有明确的费用标准。一般来说，只要是有日常办公经费可以开支的，都有足够费用请到专家，有责任心的专家还会提出适当的预算方案修改意见，使预算方案更经得起推敲。
在选择谁来担任专家时，应同时考虑业务相关性和技术相关性，中级职称或以上且有一定年资。如果找不到同时具备业务和技术相关的专家，应分别选取，以保证业务和技术都能覆盖。
如果连专家费都出不起，那就要本着互相帮助的前提找有担任专家能力的朋友帮忙背书了，只要山水有相逢，就会有朋友帮忙，总不至于连这点对外联络的能力都没有吧。
预算方案上报，然后经过各级评审，通常还要被砍一刀之后，通过立项了。也就是预算这个箩筐成形了，但里面实际是空的，接下来才是真正往里装内容的时候。
所以对于许多甲方来说，真正的预算设计过程，是预算方案通过了之后才开始。这个阶段，可以称为“预算细化”阶段。
做过系统需求分析（没错就是我）就会知道，用户需求在提出来的时候必然是模糊的，都是基于大量的潜在背景知识的简化表述。
在细化需求形成概要设计的过程中，需求分析人员会发现用户的一两句话，实际是无底洞，而预算这个已经做好了的筐是装不下的。
预算和需求不匹配的风险就来自于无止境的需求，而风险的承担者，就是代表着整个甲方的项目管理责任部门。
因此，控制需求规模就是控制风险。从这一点出发，项目管理责任部门（注意：不一定是信息化工作部门，所以强调是责任部门）就必须具备判定需求的细化程度，适当控制设计深度，并获得用户部门等利益相关方的确认。
也就是：需求分析人员可以不精通技术，但必须要懂业务，需要通过沟通、思考、判断和协调等软技能才能实现控制需求规模，进而控制项目建设实施过程的风险。
笔者在之前的网络安全从业人员能力要求标准解读中，也特意指出了软技能这一点，可以点击跳转阅读：
解读 GB／T 42446-2023 《信息安全技术 网络安全从业人员能力基本要求》
回到作为例子的这个项目上来。项目中的二级甲方也就是项目所建设的信息系统的用户。项目管理责任部门作为总牵头部门，与系统用户的关系如何理顺，是信息化建设工作中的老生常谈。
基于用户角色，二级甲方有义务提出足够详细的需求描述。但在现实中，往往也就是因二级甲方提出需求，产生风险和不可控因素。
最典型的连锁反应是需求描述不够详细，对建设单位未能形成足够的指导作用，进而导致需求迟迟不确定、耽误建设时间、延期验收等。
最坏情况下，会导致项目管理责任部门和用户部门之间矛盾激化，项目彻底烂尾。
对于项目管理责任部门来说，两级甲方的关系在预算细化阶段产生的就是预算不足和需求泛滥之间的矛盾。
控制这种风险的措施首先在于项目管理责任部门的放和收，以及用户部门的责任义务和收益要和项目整体捆绑。
项目管理责任部门的“放”，指的是要把需求的提出权彻底放给二级甲方，不要有任何限制，更不能有各种明示暗示要如何如何。让二级甲方明白预算的筐有多大，然后充分思考，详细描述。这一点其实还是比较容易做到的。
但相反地，“收”就难了。因为这意味着产生责任。“收”是要把需求的决定权收在手里，确定在预算这个筐里面装进去什么，不装进去的又如何处理，是放弃还是纳入项目二期，都需要项目管理责任部门人员具备相应的软技能。
必须通过这样的“放”和“收”，才能有效控制预算和需求能够相互匹配。
只放不收，那其实任何人都能一眼看出就是在甩锅。但这个貌似甩出去的锅，最后是会变成回旋镖，击中自己的。
两级甲方的内部关系在前面已经引出。如果聚焦到预算上，必须要实现一件事：把二级甲方和预算支出相互关联起来，实现义务和收益转化为责任。
比如，通过教育工作，对二级甲方灌输基于预算限制考虑如何提出需求，以及充分理解项目完成建设能为自己带来的实在好处。
风险控制这个事情，如果反过来从二级甲方角度考虑，我作为二级甲方，规避项目风险的重点在于：
1、给我的预算限制是否明确；
2、我的核心关键业务是否能在预算限制内实现；
3、我哪些非核心关键业务是可以割舍的；
4、如果预算未能满足核心关键业务建设需要，我如何处理。
以上关键点，需要二级甲方向项目管理责任部门明确，经充分研究讨论后共同形成专门的情况说明。
尤其是第4点，处理办法无论是调增给二级甲方的预算份额以满足建设需要，还是干脆调减预算份额取消建设，都需要有全局思维和审计思维，从结果倒推过程去考虑和决定。
预算阶段的严谨与否，决定了整个项目的后续过程是否顺利。所以，想想还是多一句无聊的提醒：
所有的决定，以及对决定的支撑材料，都必须形成可追溯的过程记录，就如记叙文那样，时间地点人物事情，缺一不可。
其实各位读者，你们能想象到这个项目接下来的建设过程和最终的验收会是怎样的吗？本系列的下一期，将会从招投标开始，引出故事的另一个主角，也即项目的乙方：建设单位。
本文图片由Pexels和Pixabay提供并经过作者编辑。
