分享到
挨踢项目求生法则
 

作者:张传波,发布于2011-11-30

 

挨踢项目求生法则-需求篇

摘要:

知道什么是挨踢项目吧?什么!不知道?那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.预算限死

两大不确定和两大限死,你想不“挨踢”都难!

由“踢皮球”事件想到的

事件回放:

某项目部署给客户后,重现了一些以前已经解决的问题,而这些问题测试时并没有出现。经检查,发现测试的版本不是部署的版本,不知道为什么老版本部署给客户了。领导要追究责任,于是大家各有说法:

开发人员说:我是按要求打标签的,没有问题。

测试人员说:我是在提交区中取版本来测试的,我没有出错。

实施人员说:我是按照开发给我的版本去部署的,我没有过失。

最后终于有人说:是之前已经离职的某某弄错版本号导致的。

详情可参阅《案例分析:项目组内踢皮球事件》一文:

http://www.cnblogs.com/umlonline/archive/2011/10/28/2226933.html

该事件暴露了很多问题,但我想说的是团队建设的问题,没有任何一个人首先从自己身上找原因,第一反应就是推卸责任!

唐僧四师徒西天取经,如果每个人都是这样,不是自己内斗死,就是被妖怪吃掉!优秀的团队能“自动”解决很多问题,如何才能打造良好的团队文化呢?

良好团队文化的源泉是什么?

良好团队文化的根本其实就是老板的管理思想了,不同的管理思想,老板会设计不同的部门规划和考核办法。

有朋友提到他的Boss喜欢工厂化管理,硬生生将员工分成两类人,设成两个部门。一个部门叫设计部门,负责需求和设计;一个部门叫实施部门,负责编码、测试、实施。设计部门通过一个任务管理系统向实施部门下单,实施部门根据这些工单来工作。该老板还设计了自以为很牛的考核办法,如果实施部门不能按时按质完成工单,则会影响考核;如果设计部门的工单被实施部门退回,则会影响设计部门的考核。于是两个部门之间的扯皮时间天天发生,以前完成一个工作很简单的,现在要扯来扯去。设计部门自认为需求、设计等文档已经写得很清楚,实施部门认为已经按照这些文档完成工作,或者是认为这些文档说得不够具体,要退单。当文档主要用来任务交接的时候,文档就会变成茶几上的杯具!

还有一些老板喜欢用bug数量、文档缺陷率、工期延误率等所谓客观的量化的数据来考核,同样只不过是杯具的另一种形式而已。

软件研发活动是人类复杂的高级智力活动,是需要team work的活动。如果明白这个道理,如果懂软件开发,就不会设计出这些傻瓜的管理措施,将软件研发团队的每个人变成机械人、卸责人。研发团队中的每一个人都应该是值得尊重的、有血有肉的、充满激情和战斗力的专家!

作为Team Leader应该怎样做?

Boss的想法我们无法控制,虽然无法从根本上改变公司的部门设计和考核制度,但作为Team Leader来说,在能力范围内还是可以做很多事情的。Team Leader应尊重每一位Team Member,平等地对待他们,充分发挥他们的潜力,给予足够的支持和成长空间等。对大家好,大家是知道的,将来会给你带来更大的回报。

下面一些法则供你参考。

法则1:一荣俱荣,一损俱损

项目组由项目管理、需求分析、软件设计、编码、测试、实施等各方面的专业人士组成,每位成员在自己专业领域内发挥主导作用,并可以为项目的成功提出非自己领域内的建议。最终的项目成果是各位专业人士共同努力的结果,所有人对最终成功承担同等的责任。

如果系统部署后,系统出现了一个严重缺陷,请问谁应该负责?

项目经理?测试?开发?……

都不是,而是项目组全体都要负责!

软件中某个功能做得很炫很好用,请问谁应该受到表扬?

项目奖励发下来了,请问谁可以分到这份奖励?

以上问题相信你应该有答案了!

项目组全体是共同承担连带责任的,要死一起输死,要活一起活。如果项目组中有人受罚,有人会得到好处,这个Team是很难团结和有战斗力的。

法则2:让 Team Member 当家作主

项目组中难免有部分成员是新手,经验和水平不足,某些工作可能一时不能胜任。而我们往往迫于项目进度压力,某些任务就会直接安排给他做,不让他提出自己的想法和见解。而我们这些接受了中国式教育的人,不少人喜欢以“接受任务”的方式来工作,而不是主动迎接挑战。于是有时候你可能遇到一些成员会跟你说“今天工作已经完成!”“我按照任务要求来做的,我没有错!”之类的活活会气死你的说话。

不要剥夺项目成员当家做主的机会,应相信每位成员在他的专业领域内都是专家,在他的专业范围内,他可以说了算!只要满足项目的大框架,只要出发点是为了项目成功,那么这段代码应该怎样写、这个功能点应该如何测试等之类的决定,完全可以交给Team Member来做主!项目成员可能一时没有魄力独立做决定,可能担心犯错误,没关系,要多多鼓励他!犯错不可怕,因为还有“法则3:鼓励犯错!”

法则3:鼓励犯错!

少做少错,不做不错。如果犯错误会受到惩罚的话,那么前面八个字就会应验!

犯错几种情况:

1.经常挑战高难度工作,犯错是难免的。

2.做一些之前没有经验的工作,犯错也是难免的。

3.犯一些低级错误。

4.犯一些之前曾经犯过的完全可以避免的错误。

对于情况1、2,绝对是需要鼓励的!对于情况3、4,要帮助他避免这类的错误。

软件研发工作大部分是高难度和复杂的,加上进度压力大,犯错是不可避免的,如何在总结中前进。一个在工作中从来不犯错的人,他不是神,他应该是那种“少做少错,不做不错”的人,或者是专挑低难度工作的人,你喜欢这样的人?

法则4:言传身教

曾经见到这样的一些领导,当下属有问题求助时,他会板起脸孔,摆出领导的样子,然后说:你自己不会解决问题吗?你应该自己列出解决方案后才来找我!

我赞同领导不应该帮下属解决所有问题,有些问题应该由下属自己搞定,但下属是不可能搞定所有问题的,有些问题超出能力范围和职责范围,作为领导就应该出手。

作为Team Leader,应着重帮助Member养成良好的工作习惯和工作方法。中国式教育培养出来的学生,可能会喜欢直接得到答案,而不求工作方法。这个中国式教育的错,就只能由我们来补了。

法则5:挡住骚扰团队的外来干扰

Team Leader应当住来组团队外部的干扰,让团队可以专心工作。挡住麻烦是Leader的职责之一,而不要因为嫌麻烦,而让你的Member去处理这些麻烦。

法则6:全力维护团队利益

某部门的员工的薪金近年来很少得到提升,原因是该部门经理对外是好好先生,每年都不会主动积极为部门争取加薪的预算,总是被别的部门抢去预算。

某项目出了问题,老板找来项目经理,说要找人负责任,否则不好向客户交代。以下三个选择你会选哪个?

A.该问题确实主要是因为某Member导致的,所有他来负责是应该的。

B.这是团队的责任,要全体负责。

C.尽管是主要因为某人出错导致的,但作为PM的我应该负主要责任。

作为一个Team Leader,无论任何情况下都不应该“出卖”自己的Member,应该自己一力承担!回头你可以关起门来,批评这位犯错的Member。

法则7:我们是一个人

法则7是最重要的,其实只要能做到“我们是一个人”,其他法则自然就做到了。你不会和自己的左手作对的,右脚不会和左手打架,你的身体哪一部分受伤,你都会觉得疼,一个人的手脚动作是很容易协调的。如果我们团队能凝聚在一起,达到“我们是一个人”的效果,那么我们将战无不胜!

挨踢项目求生法则-战略篇

摘要:

知道什么是挨踢项目吧?什么!不知道?那IT项目知道了吧?为了不让客户踢、不让老板踢、项目组成员之间不互相踢,俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功,也至少不会死得那么惨吧!我将分战略篇、团队建设篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。

什么叫挨踢项目?

IT项目,特别是软件开发项目,都属于“挨踢”项目的范畴。挨踢项目的几大特点:

1.需求不确定。

2.技术不确定。

3.工期限死。

4.预算限死

两大不确定和两大限死,你想不“挨踢”都难!

指挥战争可能是最复杂的项目管理?

做挨踢项目可能比较杯具,但最复杂、难度最高、代价最大的项目管理可能是战争的管理了。战争靠什么取胜呢?如果你是这场战争其中一方的统帅,你会如何指挥这样战争呢?你可能会说:你不是在扯淡吗?说挨踢项目管理,怎么跑到战争去了?让我们先看看战争的战略管理,然后再回到项目的战略管理吧。

白起的故事

白起你不会没有听说过吧?就是那个杀死几十万赵国俘虏的杀人狂魔。但我说的不是他杀俘虏的事情,而是白起被称为战神,一生没有打过败仗,他是如何做到的?因为他只选择打战略上能打赢的仗!

当时只有赵国有实力和秦国一战,双方几十万大军对峙在长平一带。秦军统帅是白起,赵军统帅是廉颇。白起对于此战的战略上的判断是这样的:两国实力、军力相当,如果全力出战,秦国能胜,但只能是惨胜,这样的后果只能是削弱了自己,反而让其他战国有机可乘。秦国的优势在于全国上下一心,特别是秦王和大臣们众志成城。而赵国虽然军力不错,但赵国内部权力斗争厉害,各派只为自己利益不顾国家利益。因此白起定下的战争策略是:对外称病不能担当统帅,隐藏自己做统帅的事实,以拖待变,寻找有利战机再出击。另一方面,秦国使出反间计,成功让赵国更换主帅,换了那个很出名的只会“纸上谈兵”的赵括。

赵括上任后,全军出击,结果中了白起埋伏,白起利用地形,用基本相等的数量的士兵困住了几十万赵军,不与之决战,消耗赵军的粮草,最后赵军被迫投降。后面就是白起杀死几十万降兵的事情了。白起成功地用比较少的代价,给赵国带来致命的打击。

白起杀死几十万降兵后,立马建议秦王马上挥军灭掉赵国。秦王认为此时出击必会促使六国合纵,这样秦国会招架不住;但白起认为,刚杀掉几十万降兵,其他五国还在震惊之中,没有这么快缓过气来,一时无法合纵,此时正是灭掉赵国的好时机!但秦王坚持自己的想法,白起只有退兵。后来秦王后悔了,想让白起率军灭掉赵国。这时白起认为:其他五国已经缓过气来了,此时攻击赵国,六国必会合纵。但秦王一意孤行,白起托病不统军,秦王另找人统帅,结果六国果然合纵,出现了“信陵君盗取帅印”促使魏国出兵的著名历史事件,秦军大败。秦王再次要求白起统帅,认为只要白起统帅必能获胜,但白起仍然推辞,最后秦王恼羞成怒,杀了白起。

白起在战略上的判断是相当准确的,可惜他的老板和他想法不一样,白起拒绝执行战略上注定失败的决策,虽然避免了自己打败仗,但得罪了老板,下场凄惨啊!咱们这些做项目的,如果遇到一个战略上有问题的项目,你是做还是不做呢?

庞涓的故事

说起庞涓,大家可能马上想到的是他如何害孙膑,然后孙膑又如何设计杀之报复。其实庞涓是一个战略上判断正确的人,只是被迫执行了战略上有问题的决策。

庞涓是魏国的大将,他对魏王建议的国策是:先西进灭掉秦国,解除后顾之忧后再图其他。秦国当时并不强大,多年与魏国争夺河西河东,“三十年河西三十年河东”的故事就是这样来的。但魏王认为:秦国很穷,但秦人很彪悍,灭掉秦国代价太大,没啥好处。魏王最想做的事情是灭掉赵国和韩国,所谓的“三晋合一”,魏、赵、韩原本同属晋国,后来他们将之瓜分掉。庞涓认为:灭掉赵国、韩国是不可行的,因为附近的战国,特别是齐国不会让魏国成功的,其他战国必会出兵。但魏王执意要先灭赵国,然后是韩国,让庞涓统帅。庞涓只能坚决执行老板的决策,率军猛攻赵国,就快攻克邯郸之时,齐国突然出兵突袭魏国的大梁,这就是“围魏救赵”的故事。庞涓只能回师救大梁,途中遇到伏击,损失惨重,但还不至于战死。

魏王仍然不甘心,再次要庞涓统帅灭韩国,故事再次上演,这次是“围魏救韩”。庞涓再次回师,孙膑上演了“逐日减灶”的典故,让庞涓判断失误,率大军进入死地,被齐军伏击致死。

庞涓同样在战略上的判断是基本正确的,但他的老板想法不是这样,庞涓作为老板的手下,他选择了坚决执行老板的决策,但仍然得不到好下场!

遇到一个战略上有问题的项目,你不做会死,做也会死,怎么办呢?

认识软件项目的战略管理和战术管理

上面两个故事,希望我能大概说清楚什么是战略。项目的战略大概就是指:能决定项目成败的宏观因素,如:甲乙双方在这个项目上的商业利益、双方领导的特点、项目的预算、目标、工期等,还有就是你所带领的团队是否有能力有条件完成这个项目等。

战略上有赢的可能,加上好的战术,项目才有机会成功。

战略上没赢的可能,无论用什么好的战术,项目都逃不过失败。

战略上有赢的大好条件,但你的战术很差,项目也会失败,你浪费了一个大好的项目!

希望我们能尽量选择战略上有机会赢的项目,万一运气不好,挑上了一个战略上没机会赢的项目,那么就要想办法不要死得那么惨。

下面的法则供你参考。

法则1:从战略高度出发

客户为什么要做这个项目?我们公司为什么承接这个项目?

合同的金额是多少?我们公司对这个项目的预算是多少?项目工期有多长?

你的项目团队有什么人?每个人的水平和潜力怎样?

有没有其他影响项目成功的重大风险?

以上问题应该尽早搞清楚,通常来说可以在公司的高层领导那里得到很多重要信息,但如果你无法接触高层,或者高层不鸟你,你用尽所有办法都难以获取以上的重要信息,那么你基本上可以判断:这个项目死定!

最怕遇到一些让你自己解决所有问题的领导,这些只能是无水平、不负责任的领导!除了合同金额一些涉及公司机密的内容可能不方便透露外,其他信息是必须让项目经理知道的,而且有些事情是需要高层出马帮助项目组去搞定的。

遇到高层不鸟你的情况,法则1-4都没啥作用,你可以直接看法则5。

法则2:尽量提高你在客户面前的地位

通常情况下,我们需要门当户对地和客户接触,高层VS高层,基层VS基层。如果你是一位小小程序员,想和客户高层说话,这是大忌!

很不幸的是,项目经理能经常接触的客户中的最高领导,只能是对方的业务骨干,最多是部门经理,而项目经理以下的项目成员,身份更加是低微了。

为了让项目组将来的工作更加主动,要做好项目组成员的“包装”,例如让项目经理挂上副总、总监之类的头衔,尽量让项目成员的身份放大和提高。第一次和客户接触时,就要包装好你的高大形象。例如项目启动会上,以比较高的形象来展示项目组各成员。

法则3:让客户的高层重视项目

越是高层的客户,越抓得住项目的目标,越是基层的客户,越容易陷入细节,甚至提出很多匪夷所思的要求。如果客户的高层能向下属明确本项目的目标和范围,那么客户的中层基层就比较容易搞定了。

法则2做得好,就很有机会让项目经理可以直接接触到客户的高层,项目经理在掌握了项目的战略的情况下,了解了客户大致想法的情况下,就比较容易驱动客户高层做事情了。如果项目经理不好接触客户的高层,那么就要动用法则4,让你的高层去找客户的高层。

法则4:驱动你的高层做事情

项目中很多重大问题,方向性的问题,其实是需要我们的高层去做的。例如让我们的高层与客户高层明确项目的目标与范围,推动客户配合需求调研工作,推动上线试运行,推动验收等。项目中出现重大问题,会影响项目成功时,都应该第一时间将问题反馈给我们的高层,让高层去处理或给出建议。

我不觉得你能解决所有问题才叫厉害,在项目组的层面确实有些问题是无法解决的,这些问题如果不及时让高层知道并让高层支援你,问题将会变得更加严重。

如果你的高层是那种什么事情都让你自己搞定的话,那么本法则不适用,看“法则5:输少当赢!”

法则5:输少当赢!

如果是项目战略上判断觉得无赢的可能,但你的高层领导认为可以赢,执意要求你执行他的决策,那么本法则可能会让你不会死得那么惨。

做一个战略上不可能赢的项目是很痛苦的,最佳选择是不做这个项目,但通常你没得选,你只能硬头皮上。你应该庆幸,不是让你做战争的统帅,你不会象白起或者庞涓那样会死得很惨,你最多是辞职不干!

万一赢头皮要做这样的项目,只能是“输少当赢”了。向你的高层随时报告进展,遇到什么问题全部抛给他,美名其曰:向您请教应该如何处理!遇到与领导有某些分歧,你可以适当地争论一下,然后假装被你的领导说服,你还要装作很受教的样子。你只能在很有限的空间内,尽量降低这个项目的损失,尽量降低你将来需要承受后果的严重程度。将一些问题及时抛给高层,或许会有机会帮助高层重新思考自己的想法,逐步修正他对这个项目的战略判断,这样的话会慢慢变得对你有利。

采用法则5时,是不得已的选择。如果想不做这个项目,恐怕只能选择辞职;为生活,只能暂时忍一忍,接手这个烫手山芋吧。

关键是心态要好,尽自己力就OK了,对得起自己,也对得起这个项目。挨领导的批可能是不可避免的了,当他唱歌吧!

 
相关文章

需求分析师的能力模型
基于模型的需求管理方法与工具
需求管理工具DOORS 的接口
使用Web+EA实现基于模型的需求管理
需求经过大脑的过程:需求分析评估方法
 
相关文档

需求分析与需求管理
需求分析具体要求全解
需求分析与验证
需求分析的核心线索
基于UML的需求分析方法
 
相关课程

需求分析与管理
从需求过渡到设计
业务建模与业务分析
产品需求分析与管理
需求分析最佳实践与沙盘演练
 
分享到
 
 
     

相关文章
需求分析方法—把测试流程图表化
敏捷需求分析五大关键因素
写好市场需求文档的10种技巧
需求分析中减少客户摩擦的法则
软件项目需求管理复杂性分析
EPC-事件驱动的流程链
更多...   

相关培训课程
软件需求分析与管理实践
业务建模与业务分析
软件需求分析与管理
软件需求分析师
面向产品的需求分析与管理
IT规划体系与实践

成功案例
北京 软件需求分析与管理
某知名基金 软件需求分析
联想 业务需求分析与建模
财税领域某IT服务商 测试需求分析
医疗行业 面向产品的需求管理
某知名IT服务商 测试需求分析>
某高新技术公司 测试架构、需求分析
更多...   
 
 
 
 
 
 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号