夜雨聆风
本文说的大项目，指的都是千万级别的项目，由于这些项目的体量大，业务复杂度高，交付周期长，涉及甲乙及第三方的干系人多，于项目的执行过程中，是能够暴露出作为供应商的软件公司，在其内部流程、沟通、协作、治理、风险和资源等各方面管理问题的。
铁哥就以接触过的一些案例，来分析一下那些在项目中暴露出来的公司管理乱象。
暗藏私心的多头管理
很多软件公司里矩阵式的管理架构，会将一条完整的项目管理职能，切分成多个无法形成闭环的职能区块。
比如，产品研发部门为了不陷入与客户个性化需求的拉扯中，会要求项目组引导客户收缩需求范围；销售部门为了持续经营客户，会要求项目组尽可能的满足客户需求；交付部门为了提高项目周转率，会要求项目组尽快结项以投入新的项目。
当这些不同诉求的声音从各自条线的领导层发出来时，项目组由于职级低，是不得不服从的。
这种现象，反映的是公司内部职责边界不清晰，都想通过操控项目来维持自身部门的利益。
权力游戏下的业务中台
完整的项目交付职能包括方案、配置、二开、测试、培训和运维，然而在有些公司里，却将这些职能单独拎出来，成立了多个中台组织，而交付则由项目经理协调这些中台组织来完成。
做过项目的牛马都知道，这种反复沟通将使项目中的协同成本陡增，更别说中台组织自身也会出现资源和能力的短板。
职能中台的有关分析，在铁哥视频号中也有过一期相关内容。
但这样的架构却会带来另一个结果，即每个中台组织必然会多出一个管理岗位。
由此，将若干普通的业务职能从项目中抽离出来，聚集成了一个新的权力机构，供那些追逐权力的冗余人员去竞相争夺，而项目运作是否高效或盈利，则不在这个权利游戏的考虑之内。
报喜不报忧的媚上文化
很多项目的暴雷，并不是突然发生的，而是一直压制风险预警造成的。
大项目的周期都很长，甚至比有些干系人的升迁周期都要长。
为了保证自身的升迁，项目在执行过程中是不能出现问题甚至是风险的，因为在一些登味领导眼里，报忧意味着能力不行。
由此，报喜成为项目汇报常态，风险应对措施被不断拖延，当最终爆发时，原来的干系人早已高升。
朝令夕改的产品规划
在没有现成产品的项目中，有些公司在售前阶段会信誓旦旦地承诺客户，将以项目为原型打造出新的产品。
然而，到了执行阶段，却因自身产品能力欠缺，最终将一个第三方产品OEM到了自己的系统中交付给客户。
作为非专业的客户来说，是很难发现这其中端倪的，只知道当初承诺的“原型产品”里有很多功能都是受限的。
这种乱象在业内并不少见，它体现出的不仅仅是公司产品能力的不足，更是经营诚信的败坏。
奇葩的职能定位
销售负责回款，交付负责里程碑，这是最常见的项目职能分工。
但铁哥接触过一家另类的公司，很多项目因为产品力的低下，交付常常无法完成里程碑的签署。
遇到这种情况，公司领导考虑的却不是如何提高产品能力，而是要求销售通过商务关系运作，去完成里程碑的签署，交付则负责配合销售的动作。
不排除该职能定位，在少数面子项目或政绩工程中是管用的，但这绝不是做实业的管理思维。
大项目的管理难度不亚于管理一家企业，管不好大项目的软件公司，其自身的管理能力也是堪忧的。
