大项目特征

TOB软件超大系统项目一般会有以下特征：

之一、项目组人多，项目分组也多

比如项目组成员超千人，不可能只分在一个组，一般会按照不同的维度，划分成很多的项目小组，比如按地区、按功能、按层级等来划分。

第二、决策者压力巨大

TOB和TOC产品不太一样，TOC产品使用人再多，那也都属于外部人员，对产品设计者的影响有限，一般只能用脚投票；而TOB产品，全是内部人员，产品带有使用强制性，使用者不能用脚投票，但是却可以用口水对接，分分钟都能淹死人。

当TOB系统使用人上十万级，任何一个小小的方案决策，都会影响到很多人，迫使领导的决策会非常谨慎。

第三、专家多

超大项目中，参与的高端专业人士也会比较多，甲方乙方都充满了各种业内顶尖人士。

但是越是顶尖人士多的团队越是不好管理，因为每个人的意见都不能忽视，要是遇到意见不合，较难协调，比如美国宇航局。

第四、牵一发而动全身

任何一个小改动，都可能会影响广泛，对项目工期和项目质量都会有巨大影响。

提建议注意事项

由于TOB超大项目具有以上的特征，因此一个不经意的建议，可能会惹出意想不到的麻烦，因此要特别注意提建议的方式 *** 。

之一、模棱两可的建议不要提

比如说，如果你提了一个也可以的方案，说：“这样其实也可以。”

要是这个方案正好处于领导的知识盲区，这会给该领导带来不必要的焦虑，会担心自己是不是考虑不周到，以为这个方案是不是更优，要是他真的决定换这一种方案，那么可能会导致很多事情要重新来过，但是其实可能完全没有必要。

第二、没有明确实现路径的建议不要提

目前的方案也许有瑕疵，但是那也是通过负责该方案的项目小组经过一番讨论过后确定的，会接受瑕疵都必然有其原因，你要是不知道之前为什么会形成这个方案，就兀然给领导提了一个看起来更好的建议，但是实际上不可行的方案，会导致领导以为该项目小组成员没有思考周全，以为还有改进的余地，然后又召集大家讨论，结果白白浪费工期。

第三、非自己负责的板块的建议不要提

哪怕你再是该领域的专家，但是由于目前你并没有负责该领域，实在是想要知道为什么他们的方案跟你认为的更优方案不一致，你可以跟该板块的负责人私下沟通，千万不要直接去找领导，并且以专家的身份给领导提建议，同样会容易引起领导的恐慌，再次花费时间论证方案，导致项目延期。

第四、不管甲方乙方，都应该先统一内部团队意见再提出建议

如果是内部意见都不统一，当提出来的建议遭到内部团队成员反对的时候，更不容易受到外部的认可，提了不但浪费时间，也容易给人造成不靠谱的印象。

第五、切忌为了表现自己而提建议

大项目由于人多，高级的人也多，个人难得有突出表现，如果完全是为了要表现自己而提建议，极易被周围人看穿。

水一旦流深，就发不出声音。
人一旦聒噪，也就显得浅薄。