说老实话，我都不知道什么算是大型项目经验，我也不知道，那些所谓要求有大型项目经验的公司，在做多大的项目，有多NB，但我并不以做过大项目为荣，我这几年的项目经验告诉我，团队不在于大，在于精，我经历过20人的团队，也有60人的团队，我觉得这样的项目要做好以下的几点：
1.项目团队构建前，组织架构要精细考量
各个关键角色的能力有与角色职责相适应，越向上，能力要足够的全面，要足够的强势，这样才能层层推动。
上至CTO，GM，下至PM，DBA，TM，要能够撑得住，靠一个NB的PM，是绝对撑不住的，俺经历过一个60人的项目，4个PM，一个GM，一个GM assistant，结果是GM，天天躲在自己的办公室里，发email, 以为自己是船长，吹个口哨，大家都齐心协力的向前划了，结果是今天向东，明天向西，每次开会，乱成一团，一帮SB PM，满口单元测试，闭口敏捷，开口迭代，谁也不服气谁。
2. 避免跟着感觉走，
其实国内很多软件公司都一样，越向上的领导，技术层面越来越薄弱，即使一些曾经是大N的技术人员走上了CTO的岗位，但也会逐渐丧失掉技术的敏感度，很多PM都很少写程序，何况CTO、GM？估计每天的时间都浪费在回复邮件，开会，评审，会客之类的所谓的很虚的管理之上。
这样造成的结果，就是掌控力度，其实是越来越弱，在用人，更是做不到知人善任，对于不懂技术的上领导来说，一头猪和一个高手，是没有什么区别的，只能跟着感觉走，对下边的一些人会特别的依赖，当下面的PM发生争论时，也搞球不清楚，那个SB说的对，那个SB越的有道理。
但做人要对得起良心，作为一线的PM，要相对虚心，自己没有经验的，从书上学来的，不要轻易乱用，不要拿别人当实验品，更不能现学现卖，欺骗不懂技术的上领导，有的时候，也是没有办法，会叫的孩子有奶吃，也要讲究策略。
3. 沟通与协作
作为PM向上的领导，有的时候，你感觉自己好像都在天天开会，但有的会，就开的很好，起到了事半功倍的效果，有的会，就开的很糟糕，不仅得罪人，还吃力不讨好，在沟通与协作能力方面，作为稍大的项目以上，PM是必须要把握尺寸的，我见很多嚣张的PM，说话节奏快，语气比较强势，经常批评其它的PM,结果在OP会上，很容易遭到攻击，大家的级别和能力都差不多，谁也不会卖你的账，更不会给你帮助和施以援手了。有的PM就比较圆滑，在会上很少发言，听的比较多，经常说的话就是：是的，对，OK，没问题，尽量吧，等等话语，这样的PM就很少被攻击，也更容易得到帮助。
其实，大家经常解释时说的一句话："我也是就事论事"，但在OP这样比较高层面的会上，还是尽量不要这样搞，就事论事，可以在下面一对一的搞，不要动不动都拿到OP会上搞，得不到别人的协作，要尽量的沟通，不能动不动，就上报给CTO之类的领导，这样会更糟糕。因为CTO可能会不能罩你一辈子。也并不是每个CTO都是清明的领导。
email有email的用处，但它不是command, 也不是communication, 从你的坐位上站起来，在公司内走一走，要比一个email强万倍。
4.架构师
架构设计是个很复杂的东东，但如何选择合适的架构师，如何进行最终的决策，很多公司做的并不好，很多领导在架构师的任命上，很容易草率，说你行，你就行，说你不行，你就不行。于是一些不负责的、半桶水的人，就在领导的指示下，走上前台，将项目推向死亡之谷。
架构的设计依赖你全生命周期项目经验的积累，格局要大，依赖于你对技术的敏感度，技术上比较全面，就像参谋长一样，从军校毕业的，就容易纸上谈兵，比较激进，从士兵，一路杀过来的，就比较慎重，但如果不爱学习上进，则又属于野路子，做又不究其理，不善于抽象，不讲究方法论。
总之，在这点上，能找一个NB的，又有理性的，不太容易。
5. 文档
项目组与项目组之间，项目组与客户，项目组与测试部门，项目组与评审组之间的交互，有很重要的部分就是文档。
文档这个东东，说实在话，就是一个鸡肋，但不要又不行，客户要签字，领导要评审，测试组要拿它写测试用例，但对于项目组来说，天天在那咬文嚼字的，实在是没有意义的，俺在原型分析与用例驱动上探索了很长时间，虽然用例直接了当，且很容易转化成功能书、测试用例，但工作量，比之传统的需求文档说明书，有过之而无不及，在时间紧的时候，也很难保持实时一致。
我目前的做法是原型必须与客户的需求保持一致，基于静态页面的原型，修改起来，速度很快，且更容易被客户、程度员、设计者所接收，长篇大论，动不动上百页的需求文档，你喊破喉咙，也没有人看。
文档，有专人写，专人维护，但会比较滞后，只要能够保证在提交测试部门时，有一份完整的文档，这样测试部门，也更方便测试。培训的时间也少。
在评审时，可以评审，但具体文档要拖一拖了。
客户签字，就以原型为主了。文档，它也不看。如果动真格，要看，那就抽时间赶出来。
当然对于接口等技术文档，还是必须要的。
(未完待续)