挨踢项目求生法则-需求篇、战略篇以及设计篇

 
摘要:
知道什么是挨踢项目吧?什么!不知道?那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了,对得起自己,也对得起这个项目。挨领导的批可能是不可避免的了,当他唱歌吧!
挨踢项目求生法则-战略篇
 
摘要:
知道什么是挨踢项目吧?什么!不知道?那IT项目知道了吧?为了不让客户踢、不让老板踢、项目组成员之间不互相踢,俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功,也至少不会死得那么惨吧!我将分战略篇、团队建设篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。
 
什么叫挨踢项目?
IT项目,特别是软件开发项目,都属于“挨踢”项目的范畴。挨踢项目的几大特点:
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
 
两大不确定和两大限死,你想不“挨踢”都难!
 
指挥战争可能是最复杂的项目管理?
做挨踢项目可能比较杯具,但最复杂、难度最高、代价最大的项目管理可能是战争的管理了。战争靠什么取胜呢?如果你是这场战争其中一方的统帅,你会如何指挥这样战争呢?你可能会说:你不是在扯淡吗?说挨踢项目管理,怎么跑到战争去了?让我们先看看战争的战略管理,然后再回到项目的战略管理吧。
 
白起的故事
白起你不会没有听说过吧?就是那个杀死几十万赵国俘虏的杀人狂魔。但我说的不是他杀俘虏的事情,而是白起被称为战神,一生没有打过败仗,他是如何做到的?因为他只选择打战略上能打赢的仗!
 
当时只有赵国有实力和秦国一战,双方几十万大军对峙在长平一带。秦军统帅是白起,赵军统帅是廉颇。白起对于此战的战略上的判断是这样的:两国实力、军力相当,如果全力出战,秦国能胜,但只能是惨胜,这样的后果只能是削弱了自己,反而让其他战国有机可乘。秦国的优势在于全国上下一心,特别是秦王和大臣们众志成城。而赵国虽然军力不错,但赵国内部权力斗争厉害,各派只为自己利益不顾国家利益。因此白起定下的战争策略是:对外称病不能担当统帅,隐藏自己做统帅的事实,以拖待变,寻找有利战机再出击。另一方面,秦国使出反间计,成功让赵国更换主帅,换了那个很出名的只会“纸上谈兵”的赵括。
 
赵括上任后,全军出击,结果中了白起埋伏,白起利用地形,用基本相等的数量的士兵困住了几十万赵军,不与之决战,消耗赵军的粮草,最后赵军被迫投降。后面就是白起杀死几十万降兵的事情了。白起成功地用比较少的代价,给赵国带来致命的打击。
 
白起杀死几十万降兵后,立马建议秦王马上挥军灭掉赵国。秦王认为此时出击必会促使六国合纵,这样秦国会招架不住;但白起认为,刚杀掉几十万降兵,其他五国还在震惊之中,没有这么快缓过气来,一时无法合纵,此时正是灭掉赵国的好时机!但秦王坚持自己的想法,白起只有退兵。后来秦王后悔了,想让白起率军灭掉赵国。这时白起认为:其他五国已经缓过气来了,此时攻击赵国,六国必会合纵。但秦王一意孤行,白起托病不统军,秦王另找人统帅,结果六国果然合纵,出现了“信陵君盗取帅印”促使魏国出兵的著名历史事件,秦军大败。秦王再次要求白起统帅,认为只要白起统帅必能获胜,但白起仍然推辞,最后秦王恼羞成怒,杀了白起。
 
白起在战略上的判断是相当准确的,可惜他的老板和他想法不一样,白起拒绝执行战略上注定失败的决策,虽然避免了自己打败仗,但得罪了老板,下场凄惨啊!咱们这些做项目的,如果遇到一个战略上有问题的项目,你是做还是不做呢?
 
庞涓的故事
说起庞涓,大家可能马上想到的是他如何害孙膑,然后孙膑又如何设计杀之报复。其实庞涓是一个战略上判断正确的人,只是被迫执行了战略上有问题的决策。
 
庞涓是魏国的大将,他对魏王建议的国策是:先西进灭掉秦国,解除后顾之忧后再图其他。秦国当时并不强大,多年与魏国争夺河西河东,“三十年河西三十年河东”的故事就是这样来的。但魏王认为:秦国很穷,但秦人很彪悍,灭掉秦国代价太大,没啥好处。魏王最想做的事情是灭掉赵国和韩国,所谓的“三晋合一”,魏、赵、韩原本同属晋国,后来他们将之瓜分掉。庞涓认为:灭掉赵国、韩国是不可行的,因为附近的战国,特别是齐国不会让魏国成功的,其他战国必会出兵。但魏王执意要先灭赵国,然后是韩国,让庞涓统帅。庞涓只能坚决执行老板的决策,率军猛攻赵国,就快攻克邯郸之时,齐国突然出兵突袭魏国的大梁,这就是“围魏救赵”的故事。庞涓只能回师救大梁,途中遇到伏击,损失惨重,但还不至于战死。
 
魏王仍然不甘心,再次要庞涓统帅灭韩国,故事再次上演,这次是“围魏救韩”。庞涓再次回师,孙膑上演了“逐日减灶”的典故,让庞涓判断失误,率大军进入死地,被齐军伏击致死。
 
庞涓同样在战略上的判断是基本正确的,但他的老板想法不是这样,庞涓作为老板的手下,他选择了坚决执行老板的决策,但仍然得不到好下场!
 
遇到一个战略上有问题的项目,你不做会死,做也会死,怎么办呢?
 
认识软件项目的战略管理和战术管理
上面两个故事,希望我能大概说清楚什么是战略。项目的战略大概就是指:能决定项目成败的宏观因素,如:甲乙双方在这个项目上的商业利益、双方领导的特点、项目的预算、目标、工期等,还有就是你所带领的团队是否有能力有条件完成这个项目等。
 
战略上有赢的可能,加上好的战术,项目才有机会成功。
 
战略上没赢的可能,无论用什么好的战术,项目都逃不过失败。
 
战略上有赢的大好条件,但你的战术很差,项目也会失败,你浪费了一个大好的项目!
 
希望我们能尽量选择战略上有机会赢的项目,万一运气不好,挑上了一个战略上没机会赢的项目,那么就要想办法不要死得那么惨。
 
下面的法则供你参考。
 
法则1:从战略高度出发
客户为什么要做这个项目?我们公司为什么承接这个项目?
 
合同的金额是多少?我们公司对这个项目的预算是多少?项目工期有多长?
 
你的项目团队有什么人?每个人的水平和潜力怎样?
 
有没有其他影响项目成功的重大风险?
 
以上问题应该尽早搞清楚,通常来说可以在公司的高层领导那里得到很多重要信息,但如果你无法接触高层,或者高层不鸟你,你用尽所有办法都难以获取以上的重要信息,那么你基本上可以判断:这个项目死定!
 
最怕遇到一些让你自己解决所有问题的领导,这些只能是无水平、不负责任的领导!除了合同金额一些涉及公司机密的内容可能不方便透露外,其他信息是必须让项目经理知道的,而且有些事情是需要高层出马帮助项目组去搞定的。
 
遇到高层不鸟你的情况,法则1-4都没啥作用,你可以直接看法则5。
 
 
法则2:尽量提高你在客户面前的地位
通常情况下,我们需要门当户对地和客户接触,高层VS高层,基层VS基层。如果你是一位小小程序员,想和客户高层说话,这是大忌!
 
很不幸的是,项目经理能经常接触的客户中的最高领导,只能是对方的业务骨干,最多是部门经理,而项目经理以下的项目成员,身份更加是低微了。
 
为了让项目组将来的工作更加主动,要做好项目组成员的“包装”,例如让项目经理挂上副总、总监之类的头衔,尽量让项目成员的身份放大和提高。第一次和客户接触时,就要包装好你的高大形象。例如项目启动会上,以比较高的形象来展示项目组各成员。
 
 
法则3:让客户的高层重视项目
越是高层的客户,越抓得住项目的目标,越是基层的客户,越容易陷入细节,甚至提出很多匪夷所思的要求。如果客户的高层能向下属明确本项目的目标和范围,那么客户的中层基层就比较容易搞定了。
 
法则2做得好,就很有机会让项目经理可以直接接触到客户的高层,项目经理在掌握了项目的战略的情况下,了解了客户大致想法的情况下,就比较容易驱动客户高层做事情了。如果项目经理不好接触客户的高层,那么就要动用法则4,让你的高层去找客户的高层。
 
 
法则4:驱动你的高层做事情
项目中很多重大问题,方向性的问题,其实是需要我们的高层去做的。例如让我们的高层与客户高层明确项目的目标与范围,推动客户配合需求调研工作,推动上线试运行,推动验收等。项目中出现重大问题,会影响项目成功时,都应该第一时间将问题反馈给我们的高层,让高层去处理或给出建议。
 
我不觉得你能解决所有问题才叫厉害,在项目组的层面确实有些问题是无法解决的,这些问题如果不及时让高层知道并让高层支援你,问题将会变得更加严重。
 
如果你的高层是那种什么事情都让你自己搞定的话,那么本法则不适用,看“法则5:输少当赢!”
 
 
法则5:输少当赢!
如果是项目战略上判断觉得无赢的可能,但你的高层领导认为可以赢,执意要求你执行他的决策,那么本法则可能会让你不会死得那么惨。
 
做一个战略上不可能赢的项目是很痛苦的,最佳选择是不做这个项目,但通常你没得选,你只能硬头皮上。你应该庆幸,不是让你做战争的统帅,你不会象白起或者庞涓那样会死得很惨,你最多是辞职不干!
 
万一赢头皮要做这样的项目,只能是“输少当赢”了。向你的高层随时报告进展,遇到什么问题全部抛给他,美名其曰:向您请教应该如何处理!遇到与领导有某些分歧,你可以适当地争论一下,然后假装被你的领导说服,你还要装作很受教的样子。你只能在很有限的空间内,尽量降低这个项目的损失,尽量降低你将来需要承受后果的严重程度。将一些问题及时抛给高层,或许会有机会帮助高层重新思考自己的想法,逐步修正他对这个项目的战略判断,这样的话会慢慢变得对你有利。
 
采用法则5时,是不得已的选择。如果想不做这个项目,恐怕只能选择辞职;为生活,只能暂时忍一忍,接手这个烫手山芋吧。
 
关键是心态要好,尽自己力就OK了,对得起自己,也对得起这个项目。挨领导的批可能是不可避免的了,当他唱歌吧!

挨踢项目求生法则-设计篇
知道什么是挨踢项目吧?什么!不知道?那IT项目知道了吧?为了不让客户踢、不让老板踢、项目组成员之间不互相踢,俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功,也至少不会死得那么惨吧!我将分战略篇、团队建设篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。
 
什么叫挨踢项目?
IT项目,特别是软件开发项目,都属于“挨踢”项目的范畴。挨踢项目的几大特点:
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
 
两大不确定和两大限死,你想不“挨踢”都难!
 
什么是“漂亮”的设计?
 
一些关于软件设计的资料提到,咱们的设计需要高效、可靠、易用、安全、可扩展、兼容性强、移植性强……
 
每次看到这样的文字,我的第一反应就是头晕,这些基本就是废话嘛!
 
软件设计是为软件服务的,要服从项目的商业目标。一味追求所谓的优雅设计,项目可能会死的很惨。客户购买的是软件而不是你的设计。如果你在客户面前介绍你的设计如何精妙、如何OO、如何依赖注入?那客户只能当你是火星人看了,客户并不会因为你的设计如何精妙而原谅你的推迟交付和增加费用。如果为了节省时间,忽略设计或者粗略设计,项目同样很可能会死得很惨!没有想清楚就动手,就相当于冒着大雾往前走,可能走错方向,可能跌入悬崖……
 
我认为“漂亮”设计应该是这样的:
1.能命中需求。
2.符合项目的战略。
3.做适度的设计。
 
当然以上内容可能仍然不够清楚,请继续阅读下文。
 
为什么需要设计?
以前公司过ISO的时候,其中一个我觉得比较厌烦的问题是:软件的实际设计已经和设计文档不符了,ISO内审员要求我去更新设计文档。为了避免这些麻烦,我试图将设计文档写得比较粗和通用,这样就大大降低了需要更新文档的机会。如果将设计进一步抽象化,我完全可以写出一个N层架构的设计出来,这样的设计可以复用到n多项目上,每个项目的设计文档复制这个设计就可以了。但问题是:我们的软件设计就是为了得到一个不用怎样修改的文档吗?况且这样粗的设计对项目实际工作有什么实用价值呢?
 
在某项目管理培训中我展示了某项目的某模块的详细设计文档,但有学员提出了质疑,从他的经历看来,无法让程序员写出类似这样的文档。写不出文档,是因为没有能想清楚?还是因为不会中文呢?软件设计并不是写文档,而是通过探索和思考,想出解决问题的方案,文档写不出了没有关系,关键是你有没有解决方案?哪怕这个方案存在与你的脑袋当中,你能不能清晰的表达出来?表达的方式不一定是文档,可以是口头表达,可以是通过Demo来展示等等。
 
现在可以来回答“为什么需要设计?”这个问题了,我的观点如下:
1.需求解决做什么的问题,而设计是解决怎样做的问题。
2.如何更简单、更少工作量地解决怎样做的问题,是设计工作的重点。
3.需求工作决定了软件的价值,而设计决定了软件的成本。
4.写设计文档并不等同于软件设计,软件设计在于探索、思考、实践,摸索出有效的解决方案、具体做法等。
5.Word文档仅是软件设计的其中一种表现形式而已。
6.设计不是一次成型就不变的,而是需要持续优化和改进。
 
我们需要做什么设计?
设计包括概要设计和详细设计,这是我们惯常的认识,但我将设计分为以下几方面的内容:架构设计、模块设计、数据库设计、用户体验设计。
 
架构设计可以近似看作是概要设计,架构设计是通盘考虑了所有软件需求后的一个宏观设计,我通常会用UML的部署图、组件图和包图进行架构设计,设计的粒度会达到组件及模块级别。
 
模块设计是指在架构设计的基础上,在软件系统划分成n个模块,每个模块进行详细设计。我通常会用UML的类图、顺序图来进行模块设计,设计的粒度会达到类、类的方法和属性、类之间的调用关系等。
 
数据库设计这个不用多解释,粒度要达到最终实现的程度,而用户体验设计可能需要多加解释了。
 
用户体验是指用户使用软件时的整体感觉,用户体验设计需要考虑清楚软件的整体界面规划、界面先后关系、文字表达、软件与用户如何交互等等。说到用户体验设计,很多人直接反应就是美工的事情,这是不对的,美工仅是用户体验设计的一小部分内容而已。一个软件如果内部实现很烂,但用户体验设计做得很好,那么这个软件仍然会很受欢迎。相反,一个软件的用户体验设计很烂,哪怕软件的内部设计很精妙,客户也不会卖账。从这个角度上看,用户体验设计是相当重要的,但用户体验设计往往是被忽略的。很多软件公司没有专门的用户体验设计职位,往往由程序员自己设计软件与用户的交互,做出来的软件非常不人性化。
 
我在以前的公司做项目,一个项目一般会有1份架构设计文档,1份或者多份模块设计文档,1份数据库设计文档和1份用户体验设计文档。我想说明的是,以上提到的四种设计并不是非要对号入座,每种设计对应一份或多份文档,而是软件设计应该包含这四方面的内容,至于文档的数量和形式没有规定,你可以一个文档包含四个方面的内容。另外还要说明的是,并不是软件所有的模块都需要写详细的设计文档的,如果该模块的实现方法已经很成熟,成为项目组的“常识”,这些内容没有必要额外再写文档。
 
法则1:需求驱动设计
以前曾经参加某项目的某设计文档的评审,大家围着一个局部的技术问题进行讨论,但争论的内容仅仅是一些软件设计上的大道理,每个人对这些大道理诠释不同而已。于是我问:大家知道这个项目的需求吗?能不能列出设计中需要重点考虑的需求是哪些?居然没有人能答出来!
 
我去评审设计文档很简单,就是事先将需求搞清楚,列出设计中需要重点考虑的需求,然后看看设计文档是如何考虑这些需求的实现。设计就是用来满足需求的,用需求来检验设计文档,这是很基本的“常识”,但这个常识往往被我们忽略。编写设计文档的为“节省”时间,不去全面深入理解需求就去写设计文档,参加设计评审的为“节省”时间也不去了解需求,这样设计和设计评审就变成了走形式、浪费时间的事情。
 
前面提到设计决定了软件的工作量,在设计时间上“节省”时间,你的代价就是将会花数倍甚至数十倍以上的项目工作量。认真地需求驱动地做好设计工作,这是必须的。下面简单介绍一下什么需求驱动什么设计:
1.架构设计是通盘考虑全部需求后设计出来的,所以可以说:全部需求驱动架构设计。
2.模块设计是在架构设计的基础上,针对局部需求的具体实现设计出来的,也就是说:局部需求驱动某模块设计。
3.数据库设计是整理了全部需求当中的业务数据,思考这些业务数据如何在数据库中存取后设计出来的,也就是说:业务数据驱动数据库设计。
4.用户体验设计需要考虑业务流程、业务数据等,为满足客户的业务目标,我们设计出来的系统与用户之间的交互细节等,也就是说:业务流程、业务数据、业务目标等驱动用户体验设计。
“需求驱动设计”这句话还不够具体,还要进一步细化,什么需求驱动什么设计!上述几点是我以往工作的简单总结。
 
法则2:不要误解“简单设计”
极限编程中提到“简单设计”,有些朋友很兴奋,终于可以用“简单设计”作为不写设计文档的理由了!
 
什么是“简单设计”呢?以下情况是不是简单设计呢?
1.简单想一下,然后快速做一个设计。
2.没有设计文档的设计,就是简单设计。
3.不设计就是最简单的设计。
4.编码就是设计。
 
极限编程对“简单设计”的诠释可以总结为两点:
1.不要考虑太长远,仅考虑当前的需求。
2.用最简单的办法来实现。
 
我基本认同这个观点,但问题一些朋友的理解可能出现了偏差。第2点“用最简单的办法”这是很难做到的,将事情简单化这是难度很高、很考验智慧的事情。“简单想一下”是很难想出“最简单的办法”的,随便想一下想出来的办法,往往是工作量巨大的办法!简单设计的意思是指要让项目工作变得简单,而不是将设计的思考过程简单化。软件设计是一种智力投资,多花一小时想清楚如何让项目工作变得更加简单,会节省你更多的项目时间。
 
法则3:做高性价比的设计
在符合项目战略的情况下,用尽量少的工作量来实现需求,这基本上就是“高性价比”的意思。
 
实际上我们不太可能做出一个“最好”的或者说“完美无缺”的设计,因为有以下的条件限制:
1.有限的项目工期。
2.有限的项目预算。
3.项目成员的能力条件限制。
 
软件设计是高难度的技术活,需要你做出适当的取舍和平衡,做出一个合适的设计。
 
但高性价比的设计意味着:
1.公司项目的利润更加大,公司赚钱更多了,咱们能分到的钱也就更多了。
2.项目工作更加简单,项目组不需要加班或少加班就能完成工作。
3.高性价比设计是挑战智力的工作,会让你的工作更加有愉悦感和成就感。
所以为了公司好、你好、大家好,向“高性价比设计”的目标进发吧!
 
法则4:人人都是软件设计师
有这样一种观点:由软件设计师设计出详细的设计,程序员按“图纸施工”便可。
 
我不喜欢将软件研发工作变成流水线的工作,将研发过程分割为需求、设计、编码、测试等几个环节,每个环节有专职的人员,他们做好本职工作就可以了。这样的工作模式有以下几个问题:
1.人变成了机器,没有创造力可言。
2.每个人对工作职责负责,而不是对项目成功负责。
3.这样的模式不可能产生创意,也意味着不可能完成复杂的、需要创造力的项目。
 
我认为项目组中每个人都可以是软件设计师,不要剥夺程序员思考的机会,不要将他们变成按图纸施工的机械人。
 
在我的项目中,我是这样做的:
1.架构设计和数据库设计由富有经验的程序员负责,其他项目成员参与学习和评审该设计。
2.模块设计由将来负责该模块编码的程序员负责,架构设计师来评审该设计。
3.用户体验设计由测试工程师或实施工程师负责,程序员参与。
 
法则5:设计文档应该先己后人
一些QA通常用这样的理由来说服项目组编写设计文档:
1.为了让将来接手项目的同事搞清楚状况,设计文档是必须的。
2.将来你自己也很可能需要改程序的,现在写下文档对你将来的工作有用。
 
以上的做法,就好象你对一个正在挨饥荒的人说:现在多存点粮食吧,对你将来有用。听你劝说的人肯定气死了,恨不得吃掉你充饥!
 
所以以上的理由是不能驱动项目组写设计文档的,设计文档应该达到这样的效果:对项目当前的工作有用,能帮助我立刻解决问题!如果设计文档不能达到这样的效果,就不能驱动项目组写好设计文档。
 
设计文档必须先保证对自己、对项目组本身的当前工作有用,在这前提下有条件才去考虑对自己的将来有用、对别人有用。也只有立足于这个出发点下,才可能写出有实际价值的文档,文档不是摆设,是要立马在工作中用上的。
 
法则6:设计文档不一定是Word文档
以前曾经遇到一个挺郁闷的事情:
某项目用SQL Server数据库,我直接在SQL上进行设计,也就是说数据库的设计与实现一起做了。在数据库上做设计的好处有:
1.设计马上得到验证。
2.以利用数据库的特性做很多设计上的探索,让设计做得更好。
3.设计完成了,数据库也建成了,不需要再做一次,节省很多时间。
我很喜欢这样做,但QA认为我没有数据库设计文档,不符合ISO的要求。我觉得很郁闷,数据库这个文档就是数据库设计文档,干嘛非要写一个Word文档?后来迫于要ISO审核,我用复制粘贴大法写了这个数据库设计的Word文档。如果项目使用的数据库只有一种,我觉得直接在该数据库上做设计没有什么不妥,当然如果你的项目需要支持多种数据库时,该做法可能不妥。
 
通过这个例子我想说明的是:设计的表现形式可以很多,不一定是Word文档,怎样的方式对当前项目工作最有效,就应该采用怎样的方式。当然有人会说,写下Word文档对将来的人有好处,但前面的法则说了,要“先己后人”而不是“先人后己”,如果我现在就饿死了,你让我现在存粮有啥意义?况且Word文档并不一定是所有软件设计的最佳表现形式。
 
法则7:不是所有地方都需要有设计文档
有这样一种观点:代码没有设计文档是不符合CMMI要求的。
 
你认为是不是所有代码都应该对应有详细设计文档呢?
 
数据库四轮马车的操作如果你们公司已经驾轻就熟了,你们项目组闭着眼睛都能做了,你还会写一份详细的设计文档,然后对着该文档编码吗?
 
并不是所有的地方都需要设计文档,仅在需要的地方才写设计文档,我的做法通常是这样的:
1.架构设计文档一般不可缺。
2.数据库设计文档一般也不可缺。
3.并不是所有模块都要写设计文档的,一般在以下情况下才写该模块的详细设计文档:
   1)算法比较复杂;
   2)想法不太成熟;
   3)负责该模块的程序员是新人等。
4.用户体验设计文档一般也不可缺,但文档的内容一般不会覆盖软件的全部内容,成为“常识”的内容不需要写。
 
法则8:“编码即设计”是合适的,但烂代码除外
“编码即设计”这个观点我支持,我要进一步修正,应该是“好的编码即设计”。架构设计文档、数据库设计文档或不可缺,但详细设计文档是可以直接通过编码来代替的,但前提条件是该程序员的编程素质足够好才行。
 
中国计算机教育培养出来的程序员,大多数是编程基本功不过关,在校没有写过多少代码。这是一大问题,而另外一大问题是这些编程基本功很水的人士,大多不会认识到自己的问题所在,还自认为自己水平不错,编程是小菜一碟的事情。遇到不愿意写或者写不出设计文档,又自认为自己编程水平很行但实际很差的项目组成员,就需要项目管理者多花心思来引导了。
 
有时候遇到一些编程新手,死活写不出设计文档,我会让他直接通过编码来思考。文档可能没有办法让他理清思路,那么直接编码来理清思路吧,你可以通过他的代码来了解他的想法并给出针对性的指导,帮助他提升水平。
 
如果本文对你有帮助,麻烦点击一下“推荐”,谢谢!

挨踢项目求生法则-战略篇
 
摘要:
知道什么是挨踢项目吧?什么!不知道?那IT项目知道了吧?为了不让客户踢、不让老板踢、项目组成员之间不互相踢,俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功,也至少不会死得那么惨吧!我将分战略篇、团队建设篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。
 
什么叫挨踢项目?
IT项目,特别是软件开发项目,都属于“挨踢”项目的范畴。挨踢项目的几大特点:
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
 
两大不确定和两大限死,你想不“挨踢”都难!
 
指挥战争可能是最复杂的项目管理?
做挨踢项目可能比较杯具,但最复杂、难度最高、代价最大的项目管理可能是战争的管理了。战争靠什么取胜呢?如果你是这场战争其中一方的统帅,你会如何指挥这样战争呢?你可能会说:你不是在扯淡吗?说挨踢项目管理,怎么跑到战争去了?让我们先看看战争的战略管理,然后再回到项目的战略管理吧。
 
白起的故事
白起你不会没有听说过吧?就是那个杀死几十万赵国俘虏的杀人狂魔。但我说的不是他杀俘虏的事情,而是白起被称为战神,一生没有打过败仗,他是如何做到的?因为他只选择打战略上能打赢的仗!
 
当时只有赵国有实力和秦国一战,双方几十万大军对峙在长平一带。秦军统帅是白起,赵军统帅是廉颇。白起对于此战的战略上的判断是这样的:两国实力、军力相当,如果全力出战,秦国能胜,但只能是惨胜,这样的后果只能是削弱了自己,反而让其他战国有机可乘。秦国的优势在于全国上下一心,特别是秦王和大臣们众志成城。而赵国虽然军力不错,但赵国内部权力斗争厉害,各派只为自己利益不顾国家利益。因此白起定下的战争策略是:对外称病不能担当统帅,隐藏自己做统帅的事实,以拖待变,寻找有利战机再出击。另一方面,秦国使出反间计,成功让赵国更换主帅,换了那个很出名的只会“纸上谈兵”的赵括。
 
赵括上任后,全军出击,结果中了白起埋伏,白起利用地形,用基本相等的数量的士兵困住了几十万赵军,不与之决战,消耗赵军的粮草,最后赵军被迫投降。后面就是白起杀死几十万降兵的事情了。白起成功地用比较少的代价,给赵国带来致命的打击。
 
白起杀死几十万降兵后,立马建议秦王马上挥军灭掉赵国。秦王认为此时出击必会促使六国合纵,这样秦国会招架不住;但白起认为,刚杀掉几十万降兵,其他五国还在震惊之中,没有这么快缓过气来,一时无法合纵,此时正是灭掉赵国的好时机!但秦王坚持自己的想法,白起只有退兵。后来秦王后悔了,想让白起率军灭掉赵国。这时白起认为:其他五国已经缓过气来了,此时攻击赵国,六国必会合纵。但秦王一意孤行,白起托病不统军,秦王另找人统帅,结果六国果然合纵,出现了“信陵君盗取帅印”促使魏国出兵的著名历史事件,秦军大败。秦王再次要求白起统帅,认为只要白起统帅必能获胜,但白起仍然推辞,最后秦王恼羞成怒,杀了白起。
 
白起在战略上的判断是相当准确的,可惜他的老板和他想法不一样,白起拒绝执行战略上注定失败的决策,虽然避免了自己打败仗,但得罪了老板,下场凄惨啊!咱们这些做项目的,如果遇到一个战略上有问题的项目,你是做还是不做呢?
 
庞涓的故事
说起庞涓,大家可能马上想到的是他如何害孙膑,然后孙膑又如何设计杀之报复。其实庞涓是一个战略上判断正确的人,只是被迫执行了战略上有问题的决策。
 
庞涓是魏国的大将,他对魏王建议的国策是:先西进灭掉秦国,解除后顾之忧后再图其他。秦国当时并不强大,多年与魏国争夺河西河东,“三十年河西三十年河东”的故事就是这样来的。但魏王认为:秦国很穷,但秦人很彪悍,灭掉秦国代价太大,没啥好处。魏王最想做的事情是灭掉赵国和韩国,所谓的“三晋合一”,魏、赵、韩原本同属晋国,后来他们将之瓜分掉。庞涓认为:灭掉赵国、韩国是不可行的,因为附近的战国,特别是齐国不会让魏国成功的,其他战国必会出兵。但魏王执意要先灭赵国,然后是韩国,让庞涓统帅。庞涓只能坚决执行老板的决策,率军猛攻赵国,就快攻克邯郸之时,齐国突然出兵突袭魏国的大梁,这就是“围魏救赵”的故事。庞涓只能回师救大梁,途中遇到伏击,损失惨重,但还不至于战死。
 
魏王仍然不甘心,再次要庞涓统帅灭韩国,故事再次上演,这次是“围魏救韩”。庞涓再次回师,孙膑上演了“逐日减灶”的典故,让庞涓判断失误,率大军进入死地,被齐军伏击致死。
 
庞涓同样在战略上的判断是基本正确的,但他的老板想法不是这样,庞涓作为老板的手下,他选择了坚决执行老板的决策,但仍然得不到好下场!
 
遇到一个战略上有问题的项目,你不做会死,做也会死,怎么办呢?
 
认识软件项目的战略管理和战术管理
上面两个故事,希望我能大概说清楚什么是战略。项目的战略大概就是指:能决定项目成败的宏观因素,如:甲乙双方在这个项目上的商业利益、双方领导的特点、项目的预算、目标、工期等,还有就是你所带领的团队是否有能力有条件完成这个项目等。
 
战略上有赢的可能,加上好的战术,项目才有机会成功。
 
战略上没赢的可能,无论用什么好的战术,项目都逃不过失败。
 
战略上有赢的大好条件,但你的战术很差,项目也会失败,你浪费了一个大好的项目!
 
希望我们能尽量选择战略上有机会赢的项目,万一运气不好,挑上了一个战略上没机会赢的项目,那么就要想办法不要死得那么惨。
 
下面的法则供你参考。
 
法则1:从战略高度出发
客户为什么要做这个项目?我们公司为什么承接这个项目?
 
合同的金额是多少?我们公司对这个项目的预算是多少?项目工期有多长?
 
你的项目团队有什么人?每个人的水平和潜力怎样?
 
有没有其他影响项目成功的重大风险?
 
以上问题应该尽早搞清楚,通常来说可以在公司的高层领导那里得到很多重要信息,但如果你无法接触高层,或者高层不鸟你,你用尽所有办法都难以获取以上的重要信息,那么你基本上可以判断:这个项目死定!
 
最怕遇到一些让你自己解决所有问题的领导,这些只能是无水平、不负责任的领导!除了合同金额一些涉及公司机密的内容可能不方便透露外,其他信息是必须让项目经理知道的,而且有些事情是需要高层出马帮助项目组去搞定的。
 
遇到高层不鸟你的情况,法则1-4都没啥作用,你可以直接看法则5。
 
 
法则2:尽量提高你在客户面前的地位
通常情况下,我们需要门当户对地和客户接触,高层VS高层,基层VS基层。如果你是一位小小程序员,想和客户高层说话,这是大忌!
 
很不幸的是,项目经理能经常接触的客户中的最高领导,只能是对方的业务骨干,最多是部门经理,而项目经理以下的项目成员,身份更加是低微了。
 
为了让项目组将来的工作更加主动,要做好项目组成员的“包装”,例如让项目经理挂上副总、总监之类的头衔,尽量让项目成员的身份放大和提高。第一次和客户接触时,就要包装好你的高大形象。例如项目启动会上,以比较高的形象来展示项目组各成员。
 
 
法则3:让客户的高层重视项目
越是高层的客户,越抓得住项目的目标,越是基层的客户,越容易陷入细节,甚至提出很多匪夷所思的要求。如果客户的高层能向下属明确本项目的目标和范围,那么客户的中层基层就比较容易搞定了。
 
法则2做得好,就很有机会让项目经理可以直接接触到客户的高层,项目经理在掌握了项目的战略的情况下,了解了客户大致想法的情况下,就比较容易驱动客户高层做事情了。如果项目经理不好接触客户的高层,那么就要动用法则4,让你的高层去找客户的高层。
 
 
法则4:驱动你的高层做事情
项目中很多重大问题,方向性的问题,其实是需要我们的高层去做的。例如让我们的高层与客户高层明确项目的目标与范围,推动客户配合需求调研工作,推动上线试运行,推动验收等。项目中出现重大问题,会影响项目成功时,都应该第一时间将问题反馈给我们的高层,让高层去处理或给出建议。
 
我不觉得你能解决所有问题才叫厉害,在项目组的层面确实有些问题是无法解决的,这些问题如果不及时让高层知道并让高层支援你,问题将会变得更加严重。
 
如果你的高层是那种什么事情都让你自己搞定的话,那么本法则不适用,看“法则5:输少当赢!”
 
 
法则5:输少当赢!
如果是项目战略上判断觉得无赢的可能,但你的高层领导认为可以赢,执意要求你执行他的决策,那么本法则可能会让你不会死得那么惨。
 
做一个战略上不可能赢的项目是很痛苦的,最佳选择是不做这个项目,但通常你没得选,你只能硬头皮上。你应该庆幸,不是让你做战争的统帅,你不会象白起或者庞涓那样会死得很惨,你最多是辞职不干!
 
万一赢头皮要做这样的项目,只能是“输少当赢”了。向你的高层随时报告进展,遇到什么问题全部抛给他,美名其曰:向您请教应该如何处理!遇到与领导有某些分歧,你可以适当地争论一下,然后假装被你的领导说服,你还要装作很受教的样子。你只能在很有限的空间内,尽量降低这个项目的损失,尽量降低你将来需要承受后果的严重程度。将一些问题及时抛给高层,或许会有机会帮助高层重新思考自己的想法,逐步修正他对这个项目的战略判断,这样的话会慢慢变得对你有利。
 
采用法则5时,是不得已的选择。如果想不做这个项目,恐怕只能选择辞职;为生活,只能暂时忍一忍,接手这个烫手山芋吧。
 
关键是心态要好,尽自己力就OK了,对得起自己,也对得起这个项目。挨领导的批可能是不可避免的了,当他唱歌吧!
  • 0
    点赞
  • 0
    收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
评论
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值