转自：http://www.cnblogs.com/umlonline/archive/2012/02/01/2334471.html
知道什么是挨踢项目吧？什么！不知道？那IT项目知道了吧？为了不让客户踢、不让老板踢、项目组成员之间不互相踢，俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功，也至少不会死得那么惨吧！我将分战略篇、团队建设篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。
挨踢项目求生法则-需求篇
由“我要吃饭”的故事想到的
某天某客户跟你说：“我要吃饭！”
你非常关注客户这个需求：“请问您要吃中餐还是西餐呢？您想吃什么呢？”
客户非常开心，一下子说出了很多想吃的：
“西餐嘛，不错，听说那个菲力牛排很不错，配上红酒更加美味！”
“不过听说某某路的那个潮汕牛肉丸火锅，牛味很浓，牛气冲天……”
“哎呀，最近上火，还是不吃这些上火的东西了，吃日本寿司吧，听说那里有日本菜自助餐，有生蚝，正啊！”
“啊，不行哦，最近日本核辐射，海鲜还是不吃了”
……
最后客户说：
“你还是先弄一顿给我尝尝吧，见到菜才能提出具体需求啊！”
遇到这样的客户，你可能想找10个馒头塞到他嘴里面，让他撑饱，搞定！
以上故事纯属虚构，如有雷同实属不幸！
这个故事是软件项目需求工作的缩影，客户的表面需求似乎很多，而且变来变去，很可能是因为我们没有抓住“我很饿”这个根本需求。客户可能提出很多匪夷所思的需求，提出一些超出自己预算范围的需求，如果我们能抓住客户的根本需求，让客户认识到自己的预算限制，再加上我们高水平的发挥，我们是有可能做出能满足客户根本需求，并且符合预算的软件系统。
需求分析与需求管理
我们可能经常听到一些关于需求方面的说词，如：需求开发、需求分析、需求调研、需求管理等等，下面将这些概念稍微梳理一下。
1）需求分析：
其他说法：需求调研、需求开发
关注点：如何获取和确认需求？
2）需求管理：
“双赢”：客户能赢，我们也能赢！在“双赢”的基础上，处理以下问题：
a）如何签署需求？
b）如何处理需求变更？
需求驱动地工作。
a）用需求指导计划、设计、编码、测试、实施等工作。
b）不做或少做与需求无关的事情。
需求分析和需求管理的工作，我统称为需求工作。需求工作中的问题有些是需求分析的问题，有些是需求管理的问题，或者是两者兼而有之。
法则1：搞清楚需要
解决肚子饿的问题，是客户的根本需求，客户的根本需求或者说需求之源泉，我称之为需要！如果客户是公费吃喝的，嘴馋想吃东西，那么满足这个需要的做法又不太一样了。
客户一般不会直接说出需要，往往提出的是他自认为能解决这个需要的某种解决方案。“我要吃饭”只是表面需求，透过这个表面需求，找到需要是需求工作的根本！我们需要思考：客户为什么有这样的要求？客户希望解决什么问题？
如果找到客户的真正需要了，那么我们需要进一步思考：有什么简单的方法可以满足客户的这个需要？
客户的需要其实很少会变的，变的是那些表面需求，多问问我们自己：我们抓住了客户的需要没有？有些客户对自己的需要很清楚，但有些客户可能只有朦胧的想法，我们需要总结出客户真正想要的东西并与客户确认。
法则2：搞清楚限制条件
10块钱解决肚子饿的问题，和100元解决肚子饿的问题，差异可以很大，所谓的看钱吃饭！
如果我们能搞清楚客户的需要，其实10块钱也可以有比较完美的解决方案的，可以去大排档吃个面、炒粉之类的，不是不可以的。某牛筋丸汤粉，才10块钱，但有8个牛筋丸，味道好极了，而且可以饱肚子！
除了预算，系统的技术条件限制，需要与第三方系统接口等其他限制条件，也需要事先搞清楚。需要、限制条件要和客户高层达成共识，一起努力找出在限制条件下可以满足需要的需求解决方案。
法则3：持续确认
曾经有人问我，几十页甚至上百页的需求规格说明书，如何让客户确认？
我反问：这几十上百页的需求文档是闭门造车写了n天后，才给客户确认的吗？对于客户来说，该文档是从天而降，他之前没有见过其中任何的内容吗？
需求不是等全部写出来才去确认的，要持续地逐步地确认。我曾经做过一个项目，连续5天进行需求调研的工作，第5天几十页的需求文档写出来了，给客户签字确认，客户很快就签字了！这份文档的绝大部分内容，在之前的4天他都曾经确认过，第5天只是一个最终的确认而已。
持续确认好处：
1.能尽快发现问题，能帮助我们尽早确认需要，避免后期可能的需求变更。
2.客户能逐步消化需求。
法则4：不要“二手需求”
曾经有一个某政府部门的项目，系统是各业务部门使用的，但需求只能从信息科那里获取。信息科的人自认为很牛，对项目组说：“需求向我们要就可以了！”而这个项目上线后，具体使用系统的部门就是不买帐，最后这个系统由信息科验收了。
信息科提供的是“二手需求”，向客户调研需求时，一定要避免“二手需求”！
上述案例你可能会觉得有点好笑，其实“二手需求”在项目组内也经常会发生。
某测试人员问为什么要做这个功能？开发说：这个你不用管，你这样这样测就可以了……
某实施人员觉得某功能看上去不太符合逻辑，提出疑问。开发说了一大通实施人员听不懂的技术用语，然后实施人员只能憋着不说话了。
项目组的测试人员、实施人员应该接触第一手的需求，最好能直接面对客户，而不是通过开发人员转述需求。
法则5：成为业务专家
你可能遇到过这样的情况，客户经常抱怨软件不好用，然后我们问：如何不好用？客户好容易说出了一些要求，我们按照这些要求修改了系统，但客户总是不满意，总是说不好用。诸如此类，不断重复。
客户说啥，我们做啥，是比较落后的一种层次。我们应该处在客户的利益，提出超出客户想法的解决方案。要打造有竞争力的产品或项目，成为业务专家是必须的，不能偷这个懒，不要仅停留在需求调研这样的层次，而是要引领需求，给客户带来更先进的知识和管理办法。
法则6：需求是“设计”出来的
手机订餐系统的故事我经常拿出来举例子，大意是：
某公司有一个订餐系统，但高层要求在这个基础上做一个手机订餐系统，让外出工作或请假的同事可以方便定午餐。手机订餐项目组花了九牛二虎之力，终于弄出这个系统，但问题多多。高层领导很不高兴：这点小事都折腾这么久！后来有人说：外出工作或请假的同事，打电话回公司，让前台帮忙订餐不就可以了？
“解决不方便订餐的问题”是需要，而“手机订餐系统”只是可以满足该需要的某种解决方案，我们完全可以通过其他更加简单的方法来满足需要。我个人观点：除了需要是来自客户的想法外，系统要具体做什么功能之类的需求，不是通过问客户问出来的，而是我们根据客户的需要，理解了客户的业务流程后，并根据限制条件，设计出来的！当然客户提出来的想法，会给我们带来很多启发，但我们不应该仅停留在需求调研的层次，而是提供一个高性价比的需求解决方案。
法则7：七分需求分析，三分需求管理
遇到客户变来变去的情况，我们可能第一反应是：有没有搞错！当初就应该让他签字！最好就是录音！
如果我们连客户的需要都搞不清楚，就去抱怨客户需求变来变去，那我们的水平未免有点低了。其实真正很难缠的客户、不讲道理的客户很少的，只是我们水平未够，不能理解或找出客户真正想要什么，才让我们误以为客户变来变去。
需求工作可能有很多问题，应该以做好需求分析工作为主，而需求管理为辅，两者比例大概是七三开。需求分析工作做好了，需求的问题可以减少很多，而且客户也会非常认可你的专业水平，这样后续的工作就比较容易处理了。
当然也可能会遇到很难缠又不能绕过的客户，遇到这样的情况，建议你看看“挨踢项目管理求生法则-战略篇”，如果从战略上判断该项目有很大问题，那么最好不要做这个项目，如果不幸要负责这样的项目，那么记住其中一个法则“输少当赢”。
挨踢项目求生法则-战略篇
摘要：
知道什么是挨踢项目吧？什么！不知道？那IT项目知道了吧？为了不让客户踢、不让老板踢、项目组成员之间不互相踢，俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功，也至少不会死得那么惨吧！我将分战略篇、团队建设篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。
什么叫挨踢项目？
IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。挨踢项目的几大特点：
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
两大不确定和两大限死，你想不“挨踢”都难！
指挥战争可能是最复杂的项目管理？
做挨踢项目可能比较杯具，但最复杂、难度最高、代价最大的项目管理可能是战争的管理了。战争靠什么取胜呢？如果你是这场战争其中一方的统帅，你会如何指挥这样战争呢？你可能会说：你不是在扯淡吗？说挨踢项目管理，怎么跑到战争去了？让我们先看看战争的战略管理，然后再回到项目的战略管理吧。
白起的故事
白起你不会没有听说过吧？就是那个杀死几十万赵国俘虏的杀人狂魔。但我说的不是他杀俘虏的事情，而是白起被称为战神，一生没有打过败仗，他是如何做到的？因为他只选择打战略上能打赢的仗！
当时只有赵国有实力和秦国一战，双方几十万大军对峙在长平一带。秦军统帅是白起，赵军统帅是廉颇。白起对于此战的战略上的判断是这样的：两国实力、军力相当，如果全力出战，秦国能胜，但只能是惨胜，这样的后果只能是削弱了自己，反而让其他战国有机可乘。秦国的优势在于全国上下一心，特别是秦王和大臣们众志成城。而赵国虽然军力不错，但赵国内部权力斗争厉害，各派只为自己利益不顾国家利益。因此白起定下的战争策略是：对外称病不能担当统帅，隐藏自己做统帅的事实，以拖待变，寻找有利战机再出击。另一方面，秦国使出反间计，成功让赵国更换主帅，换了那个很出名的只会“纸上谈兵”的赵括。
赵括上任后，全军出击，结果中了白起埋伏，白起利用地形，用基本相等的数量的士兵困住了几十万赵军，不与之决战，消耗赵军的粮草，最后赵军被迫投降。后面就是白起杀死几十万降兵的事情了。白起成功地用比较少的代价，给赵国带来致命的打击。
白起杀死几十万降兵后，立马建议秦王马上挥军灭掉赵国。秦王认为此时出击必会促使六国合纵，这样秦国会招架不住；但白起认为，刚杀掉几十万降兵，其他五国还在震惊之中，没有这么快缓过气来，一时无法合纵，此时正是灭掉赵国的好时机！但秦王坚持自己的想法，白起只有退兵。后来秦王后悔了，想让白起率军灭掉赵国。这时白起认为：其他五国已经缓过气来了，此时攻击赵国，六国必会合纵。但秦王一意孤行，白起托病不统军，秦王另找人统帅，结果六国果然合纵，出现了“信陵君盗取帅印”促使魏国出兵的著名历史事件，秦军大败。秦王再次要求白起统帅，认为只要白起统帅必能获胜，但白起仍然推辞，最后秦王恼羞成怒，杀了白起。
白起在战略上的判断是相当准确的，可惜他的老板和他想法不一样，白起拒绝执行战略上注定失败的决策，虽然避免了自己打败仗，但得罪了老板，下场凄惨啊！咱们这些做项目的，如果遇到一个战略上有问题的项目，你是做还是不做呢？
庞涓的故事
说起庞涓，大家可能马上想到的是他如何害孙膑，然后孙膑又如何设计杀之报复。其实庞涓是一个战略上判断正确的人，只是被迫执行了战略上有问题的决策。
庞涓是魏国的大将，他对魏王建议的国策是：先西进灭掉秦国，解除后顾之忧后再图其他。秦国当时并不强大，多年与魏国争夺河西河东，“三十年河西三十年河东”的故事就是这样来的。但魏王认为：秦国很穷，但秦人很彪悍，灭掉秦国代价太大，没啥好处。魏王最想做的事情是灭掉赵国和韩国，所谓的“三晋合一”，魏、赵、韩原本同属晋国，后来他们将之瓜分掉。庞涓认为：灭掉赵国、韩国是不可行的，因为附近的战国，特别是齐国不会让魏国成功的，其他战国必会出兵。但魏王执意要先灭赵国，然后是韩国，让庞涓统帅。庞涓只能坚决执行老板的决策，率军猛攻赵国，就快攻克邯郸之时，齐国突然出兵突袭魏国的大梁，这就是“围魏救赵”的故事。庞涓只能回师救大梁，途中遇到伏击，损失惨重，但还不至于战死。
魏王仍然不甘心，再次要庞涓统帅灭韩国，故事再次上演，这次是“围魏救韩”。庞涓再次回师，孙膑上演了“逐日减灶”的典故，让庞涓判断失误，率大军进入死地，被齐军伏击致死。
庞涓同样在战略上的判断是基本正确的，但他的老板想法不是这样，庞涓作为老板的手下，他选择了坚决执行老板的决策，但仍然得不到好下场！
遇到一个战略上有问题的项目，你不做会死，做也会死，怎么办呢？
认识软件项目的战略管理和战术管理
上面两个故事，希望我能大概说清楚什么是战略。项目的战略大概就是指：能决定项目成败的宏观因素，如：甲乙双方在这个项目上的商业利益、双方领导的特点、项目的预算、目标、工期等，还有就是你所带领的团队是否有能力有条件完成这个项目等。
战略上有赢的可能，加上好的战术，项目才有机会成功。
战略上没赢的可能，无论用什么好的战术，项目都逃不过失败。
战略上有赢的大好条件，但你的战术很差，项目也会失败，你浪费了一个大好的项目！
希望我们能尽量选择战略上有机会赢的项目，万一运气不好，挑上了一个战略上没机会赢的项目，那么就要想办法不要死得那么惨。
下面的法则供你参考。
法则1：从战略高度出发
客户为什么要做这个项目？我们公司为什么承接这个项目？
合同的金额是多少？我们公司对这个项目的预算是多少？项目工期有多长？
你的项目团队有什么人？每个人的水平和潜力怎样？
有没有其他影响项目成功的重大风险？
以上问题应该尽早搞清楚，通常来说可以在公司的高层领导那里得到很多重要信息，但如果你无法接触高层，或者高层不鸟你，你用尽所有办法都难以获取以上的重要信息，那么你基本上可以判断：这个项目死定！
最怕遇到一些让你自己解决所有问题的领导，这些只能是无水平、不负责任的领导！除了合同金额一些涉及公司机密的内容可能不方便透露外，其他信息是必须让项目经理知道的，而且有些事情是需要高层出马帮助项目组去搞定的。
遇到高层不鸟你的情况，法则1-4都没啥作用，你可以直接看法则5。
法则2：尽量提高你在客户面前的地位
通常情况下，我们需要门当户对地和客户接触，高层VS高层，基层VS基层。如果你是一位小小程序员，想和客户高层说话，这是大忌！
很不幸的是，项目经理能经常接触的客户中的最高领导，只能是对方的业务骨干，最多是部门经理，而项目经理以下的项目成员，身份更加是低微了。
为了让项目组将来的工作更加主动，要做好项目组成员的“包装”，例如让项目经理挂上副总、总监之类的头衔，尽量让项目成员的身份放大和提高。第一次和客户接触时，就要包装好你的高大形象。例如项目启动会上，以比较高的形象来展示项目组各成员。
法则3：让客户的高层重视项目
越是高层的客户，越抓得住项目的目标，越是基层的客户，越容易陷入细节，甚至提出很多匪夷所思的要求。如果客户的高层能向下属明确本项目的目标和范围，那么客户的中层基层就比较容易搞定了。
法则2做得好，就很有机会让项目经理可以直接接触到客户的高层，项目经理在掌握了项目的战略的情况下，了解了客户大致想法的情况下，就比较容易驱动客户高层做事情了。如果项目经理不好接触客户的高层，那么就要动用法则4，让你的高层去找客户的高层。
法则4：驱动你的高层做事情
项目中很多重大问题，方向性的问题，其实是需要我们的高层去做的。例如让我们的高层与客户高层明确项目的目标与范围，推动客户配合需求调研工作，推动上线试运行，推动验收等。项目中出现重大问题，会影响项目成功时，都应该第一时间将问题反馈给我们的高层，让高层去处理或给出建议。
我不觉得你能解决所有问题才叫厉害，在项目组的层面确实有些问题是无法解决的，这些问题如果不及时让高层知道并让高层支援你，问题将会变得更加严重。
如果你的高层是那种什么事情都让你自己搞定的话，那么本法则不适用，看“法则5：输少当赢！”
法则5：输少当赢！
如果是项目战略上判断觉得无赢的可能，但你的高层领导认为可以赢，执意要求你执行他的决策，那么本法则可能会让你不会死得那么惨。
做一个战略上不可能赢的项目是很痛苦的，最佳选择是不做这个项目，但通常你没得选，你只能硬头皮上。你应该庆幸，不是让你做战争的统帅，你不会象白起或者庞涓那样会死得很惨，你最多是辞职不干！
万一赢头皮要做这样的项目，只能是“输少当赢”了。向你的高层随时报告进展，遇到什么问题全部抛给他，美名其曰：向您请教应该如何处理！遇到与领导有某些分歧，你可以适当地争论一下，然后假装被你的领导说服，你还要装作很受教的样子。你只能在很有限的空间内，尽量降低这个项目的损失，尽量降低你将来需要承受后果的严重程度。将一些问题及时抛给高层，或许会有机会帮助高层重新思考自己的想法，逐步修正他对这个项目的战略判断，这样的话会慢慢变得对你有利。
采用法则5时，是不得已的选择。如果想不做这个项目，恐怕只能选择辞职；为生活，只能暂时忍一忍，接手这个烫手山芋吧。
关键是心态要好，尽自己力就OK了，对得起自己，也对得起这个项目。挨领导的批可能是不可避免的了，当他唱歌吧！
什么是“漂亮”的设计？
一些关于软件设计的资料提到，咱们的设计需要高效、可靠、易用、安全、可扩展、兼容性强、移植性强……
每次看到这样的文字，我的第一反应就是头晕，这些基本就是废话嘛！
软件设计是为软件服务的，要服从项目的商业目标。一味追求所谓的优雅设计，项目可能会死的很惨。客户购买的是软件而不是你的设计。如果你在客户面前介绍你的设计如何精妙、如何OO、如何依赖注入？那客户只能当你是火星人看了，客户并不会因为你的设计如何精妙而原谅你的推迟交付和增加费用。如果为了节省时间，忽略设计或者粗略设计，项目同样很可能会死得很惨！没有想清楚就动手，就相当于冒着大雾往前走，可能走错方向，可能跌入悬崖……
我认为“漂亮”设计应该是这样的：
1.能命中需求。
2.符合项目的战略。
3.做适度的设计。