十几杆枪如何应对几十个项目-做好需求处理

楼主说的在理，认同！
看得出楼主做了很久了，经验丰富，也在北京啊，有机会出来吃个饭讨教讨教啊:D

同楼主一起来讨论下需求。
我们先来说一下系统。我们的软件，一般都是冠以“xx管理系统”，“xx支撑系统”导致我最初以为，只有上了软件，才能算做是有了系统。事实上，如果有一家单位，在他的管理上很精细，很制度化，拥有标准的相关文档和流程制度。那我们可以说，他们已经有了一套纸制的系统。当然，纸制系统有先天的缺失，和软件系统基本无可比拟。但是在纸制系统完善的情况下，我们去做开发，恐怕是最容易的了。因为一切需求基本都已定型，只需完善电子化之后的细节及新增功能即可。
个人理解，系统是以明确的制度、流程为基础的。即使在当前业务变化频繁的情况下，如果每次变化都是明确的、标准的，那么这种需求变更对系统伤害不大。
再来说一下我们天朝。我们天朝一向是以“以领导为本”作为管理、甚至生存之根本的。即便是在民企，也往往是领导大于制度。或者说，制度以领导为依托。当领导变更，那么制度一定也会变更。事实上，领导能确定标准的制度，也是凤毛麟角，少之又少。大多数情况下，复杂的组织机构加上层层领导，左分支，右派别，在实施过程中遇到已有标准制度于流程的单位，简直就是不可能的任务。
其实我们最可怕的是什么？如果一个单位自上而下的推行一套系统，又自下而上的热切拥抱这个系统。。呃，我在说无摩擦的完美物理情况，这个是不可能的。如果我们签下的项目在甲方单位不同派别有不同利益，甚至签合同的部门与验收部门，最终应用部门有仇恨。。呃，碰到这种就是项目经理的噩梦。。我们说几种简单合理的情况吧。
一、趁推动系统推动单位制度化、流程标准化。这个我个人碰到最多了， 部级、厅局级甚至处级单位。国企私企，好了，不去管他。这种情况下，甲方领导是和我们站在一边，为我们打气。恩，也只是打气而已。具体项目实施过程，还要靠我们自己去推动。阎王好斗，小鬼难缠。各业务部门的舒适度和安全度都可能受到影响，不作为是好的，引歪路的，拍桌子骂人的，什么样的都有。这时候的忽悠大法，我个人是和客户说，我们可以不做，但是我不做这个事自然还有人做，伸头缩头都是一刀，不如，我们试试？我们尽量在系统里给您方便。如果客户能接受，再往下忽悠系统的好处吧。不接受，只能等他缓缓气再来。
二、政治任务型。一般是集团公司推进、上级部门推进，到这一级从上到下都不认同，不认可。这种，只要销售成功，项目好歹做做吧。大家都是对付，能回款就成。需求，对付一下签字确认吧。
三、主管部门推动型。这种和甲方负责人打好关系。把需求反复的厉害讲清楚。业务进行中的新需求，额外需要，一律推到二期。保证主需求上线。
四、自发需要型。这种，呃，这种是最难的。我们不怕什么都不懂的，喜欢非常懂的。最怕半吊子。这种自发产生的需求，往往客户已经自认为有过横向比较，自认为研究的很深入，对项目介入最深。也最难说服。恩，最容易失败。这个时候项目经理的个人经验取主导性作用。需求的调研、梳理，客户的签字确认，公司领导的配合（出席各种客户认为重要的阶段性会议）。基本不要妄求给客户提供他能认可的方案，每一次需求的调研总结会议，都要步步为营，留出余地让客户推翻和反复。但是需求的主动权一定不能丢，如果已签合同，该强硬就要强硬。
没有系统总结，想到哪写到哪，本人5年政府oa经验。。其他行业不了解。

学习了，小弟是一码工，正在开发的项目已经接近尾声了，MD需求变了，用户推翻自己提出的需求，要求改，真是一场噩梦，先前的工作基本白做了