项目那点事.docx
- 文档编号:8248817
- 上传时间:2023-01-30
- 格式:DOCX
- 页数:60
- 大小:98.96KB
项目那点事.docx
《项目那点事.docx》由会员分享,可在线阅读,更多相关《项目那点事.docx(60页珍藏版)》请在冰豆网上搜索。
项目那点事
个案分析是个啥
最近手里的项目结束,虽然公司没有规定要写个案分析,想一下自己还是总结一下吧。
记录一下自己的历程也好啊。
准备要写的时候,有同事来问我,什么是个案分析。
这才发现,敢情很多人还不太了解呢?
怎么说呢,看过《人月神话》吧,那就是一个个案分析。
不过人家分析的是IBM的大项目,大项目的个案分析就像炸弹扔到粪池里,分量十足。
咱这个,顶多算是扔块石头到粪池,能溅到哪位的身体中下部就算成功了。
好了,不讨论粪池水花的问题了,说说个案分析吧。
其实,老外对个案分析有自己的说法,更牛的是居然有两个说法:
一个说是CaseAnalysis,还一个说是Acasestudy。
按字面上看,第一种说法就是个案分析,而第二种应该是个案学习。
其实我个人更倾向后者。
因为这个分析来分析去,目的不就是为了学习吗。
学习以后不吃亏啊。
毕竟亏不是谁都愿意吃的,而且我相信,大多数人是不愿意吃亏的。
现在我们知道啥是个案分析了,那做这个东西有啥用呢?
这就要从项目管理的目标说起了,放心吧,我会用很通俗的说法来讲的。
包学包会。
首先,大家知道项目经理做得最多的是什么工作啊?
有人说开发,有人说需求,还有人说是骂人。
别笑,说骂人的这个还真答对了。
但是我们不叫骂人,标准说法叫沟通。
个案分析其实也是一种沟通,大家互相沟一下,就通了,通则不痛嘛。
大家都通了,项目的问题也就少了。
总而言之,总结前面的经验,再接再励。
其次,大家都知道皇帝死了,要写遗诏,国家亡了,要写X史,这是什么,这是文化沉淀。
项目结束了也要写个案分析,也就是项目总结。
由于皇帝死了,遗诏大部不是自己写的,所以骂人的较多,而我们的个案分析就是在职的项目经理写的,相对表扬的较多。
这样也好,咱也学学别人是怎么干的。
最后,这个东东是项目价值的最后体现。
这个物尽其用啊,项目验收了,钱收回来了,奖金也发了,产品也得了,团队也有了,公司的战略也实现了。
但是还有一条啊,要把项目总结成个案,为下一个项目打好基础。
这也是项目价值啊。
早朝的决定
先说一下项目情况吧,也没啥太复杂的,就是个物流的业务系统,主要是一个总公司下面有几家分公司,分公司使用WMS系统,总公司有个共用的数据库。
项目情况说完了。
那就开始正题吧。
那一天,老板把我叫到他的金銮殿(办公室),说要给我个项目做,先说好,半年内结束(正常是一年多结束的),这种情况大家都遇到过,那我们就摆事实讲道理和老板讲可以吗,我提醒各位,这样做是没用的,一般领导给你项目期限是不太会改的,当然他也知道你不能完成,可这样做对领导有两个好处。
首先,他可以给你压力,让你尽量往前赶。
其次,他可以有把柄来约束你,到时不想要你了或要减你工资了,就说:
“给你项目,让你半年做完,结果你做了九个月......”,说得你觉得拿工资都不好意思,到时在年终奖、项目奖上扣你一些,你又没话说。
之后老板又说一大堆做好项目后怎样怎样的承诺。
其实我知道,以前曹操就用过这招,叫望梅止渴(参看《三国演义》青梅煮酒论英雄那一章),是忽悠人用的。
所以我也没在乎,毕竟要吃饭,所以就接下来了。
还等我刚倒身从老板的金銮殿出来时,内阁首辅(公司副总)过来了,说让我看看我的团队。
我就跟着,看到面前这5个程序员,那时我的感觉就是,我连敌人是谁都不知道,你给我5万军队干什么啊?
我马上找首辅同志沟通,我说,这个现在好像不是安排程序员的时候,首辅同志很无奈,人都招过来了,现在他们又没事,你给他们安排点工作吧。
敢情人不是饿死的,也不是撑死的,是晕死的.那安排什么啊,那就让他们先看看兵法(物流知识)吧。
还是去了解一下这个项目吧。
我们公司做项目有时是会签合同的,说有时,意思就是也有不签合同就开工的项目,这个现象在国内可能比较多。
到质量部一问,不错这个项目还是签了合同的。
既然有合同,就先看合同吧。
翻开合同一看,真是豁然开朗,如果你想了解物流业务那就看这份合同吧,几乎把所有的物流业务都写在合同上了,不管是制造业还是第三方的,不管是保税的还是货代的,像部物流百科全书。
估计这个做合同的人与明朝的永乐皇帝是亲戚,除了都爱编全书,还都是姓“猪”的。
看来合同上是指不上了,那只能去客户现场了。
先去个电话,约好见面时间、地点、人物三要素后,就准备了。
准备什么?
准备的可多了,要知道这种第一次见面,和政治谈判差不多,很多决定性的东西,就是这时候确定下来。
1、还是先看看那本“全书”吧,不管怎么说,这个东西还是法律效应的,毕竟两个血红的大章在上面呢。
先让公司的影后(影印皇后,如果是男的就是影帝,影印小弟),把合同复印一份,原件还是归还质量部存档吧。
2、在全书的赝品上,把笔拿出来,当然了,萤光笔最好了,其他的笔也行,毛笔也可以。
把上面和功能相关的都标记上。
并看一遍相关的内容和要求。
3、遇到不懂的功能,就XX一下,毕竟是21世纪嘛。
4、搞懂合同了,就上网看看这家客户的主页,看看客户是做啥的,最近的新闻。
当然了这些都是忽悠人的,多了解些总是好了
5、把想到的问题都写到自己的本子上。
这里要说一下,记事本是项目经理的法宝,比word、excel都要有用的多,这个要随身携带,像“锦囊”一样,搞不好从里面就能找到一条“妙计”。
记到本上的问题,是要在见面时和客户沟通用的。
6、把项目的规定都写在本子上,到时和客户商量。
这包括,例会的安排、项目组织的情况、甲乙双方的沟通方式,项目的计划安排,前期调研安排等!
准备好了,现在出发吧
胜负在此一举(需求分析)之角斗开始
上回书说到,我们准备好资料,到客户处进行第一次面谈.一路上换了地铁换公交,终于到客户单位了.
大家分宾主落座,双方就项目情况进行了亲切友好的会谈,为加强甲乙关系和物流项目的成功做出了贡献。
好了,套话(官话)讲完了。
现在要说正事了,真正做事,可不像上面说得那么好看。
这是第一次见面,但双主的角斗在见面前就开始了。
这是争夺项目主夺权的战斗。
首先出场的是希望少花钱多办事的甲方,上身休闲夹克,下身西裤,手里拿着一个茶杯,还有一个记事本,嘴里还叼着香烟。
之后出场的希望多赚钱少办事的乙方,全身西装,内着衬衫领带,手夹公事包。
看到双方阵容了吧。
记得穿西装卖东西肯定比穿休闲装卖的贵,即使西装卖的东西比休闲装的差一些。
所以这身穿束是我仔细考虑后才穿上的。
大家发现了吗,甲方的人叼着香烟呢。
大家知道啊,香烟有害健康。
如果这时我发挥环境保护组织和绿色和平组织的精神,上去讲道理列图表,再把那个子弹和香烟的比较图拿出来,那我肯定是疯了。
香烟有害,也要看香烟在谁的嘴上,在客户嘴上,你说什么也不能把烟抢过来,扔到地上,再狠狠的踩两脚。
那怎么办啊?
医学上说吸二手烟的危害最大,那为了不吸二手烟,我也把烟点上好了。
声明一下,本人平常是不抽烟的。
当然了和客户一起抽烟,绝不仅仅是因为二手烟的原因。
人其实是很奇怪的动物,比如你要是喜欢上网,可是对方却不爱上网;你要是喜欢玩网游,但对方搬出一堆玩物丧志的道理,我想你也不太会喜欢和这样的人在一起的。
同理,如果你喜欢抽烟,你当然觉得和抽烟的人沟通更好了。
其实这是种暗示心理,就是说我和你是同类人,我们有共同的爱好。
在双方各自释放烟雾弹的情况下,正式的交战开始了。
首先乙方进攻。
很奇怪的,我和甲方进行过多年战争,一直以来首先发动进攻的总是乙方,有次我故意不说话,发现连甲方也不说话了,在等着我。
先介绍一下自己吧,以及自己对这个合同的看法,并提出征求甲方的意见。
甲方的意见很快就回复了。
按合同做。
要是按合同做,我过来干什么啊,这个合同哪有可执行性啊,按照合同写的,我就算把SAP的产品线都拉过还不一定够呢。
看来甲方是想吃定我了。
不行,按合同做肯定是个死,不过还好我们合同里有一条,“实际开发以《需求规格说明书》为准”。
利用这一条无数的IT企业忽悠过甲方客户。
先签了合同,其实合同里面除了时间、金额、付款方式外就没有别的有用的东西了。
合同中的系统要求、功能描述统统会被《需求规格说明书》所代替。
而甲方在这份文件签字时,乙方一般会说这是公司必要的程序,只是签字确认没有别的意思。
晕乎乎的甲方就签了,到验收时才发现原来验收是按照《需求规格说明书》来做的,不是按照合同。
当然也存在老油条甲方,来个将计就计,利用这个规则把乙方涮了的。
鉴于历史的经验,我决定绕开合同,先做实际的需求调研。
本次参与谈判的甲方都是总公司的管理人员,这些人员是不参与下边实际操作的。
由于合同是他们签定的,那就从他们开始调研吧。
相关部门的负责人和技术人员都到场了,我翻开自己的“锦囊”(不知道此是何物者,请查《项目那点儿事二)》),把我准备好的问题一个一个的询问。
甲方也算配合,是有什么说什么,不过明显废话多于实话。
先不管废话还是实话都记上。
顺便再问一下,他们实际工作是怎么做的,记下来。
这次进攻还算顺利,虽说没抓到对方的什么将领,至少锣鼓帐篷还是得了一些的,同时了解了一下对手的基本情况。
那咱们见好就收,与甲方主帅(甲方项目负责人)打个照呼,改日再战(定下下步工作计划,未来项目安排,项目例会安排等等)。
至此第一次见面算是结束了。
篇外话
有人问我,为什么一定要站到客户的对立面上,难道不能双赢吗?
如果有同样想法的同志,请翻一下400年前,亚当.斯密写的《国富论》,里面提到一个真理——人天生,并将永远,是自私的动物。
换句话说,每个人都会站在自己的角度想事情。
做为项目的甲乙双方,两者的利益点是不同,双方都希望用最少的代价换来最大的成果,不同的是对代价和成果的理解正好是相反的。
而项目经理就是要让双方在代价和成果上取得平衡。
就是说你不能让客户占太多便宜,也不能让公司得太大的实惠,因为一方的获胜总是以另一方的失败为代价的。
这就是PMBOK里面讲到的控制。
项目经理要能够控制整个项目,一但你无法控制客户,那你的项目就要失控了。
有人就说客户是项目的出资方,是你的衣食父母啊。
可实际上你的衣食父母是你的老板。
按照家族关系算,客户是你老板的父母,就是你爷爷。
现在你爷爷出钱买你爸的东西,这件事正好由你来负责,而你知道你爸之所以卖东西给你爷爷是因为他想赚钱,那你要怎么做呢。
尤其当你爸说,事成后分20%利润给你时。
所以我们要平衡,爷爷不开心时,肯定爸爸会来收拾你,爸爸不开心时,肯定你要挨打了。
所以这种关系就是由项目经理来操心了。
关于爸爸和爷爷,PMBOK里称为项目干系人,维护项目干系人的利益是项目经理的职责,这是PMP的道德准则。
我之所以把和客户的沟通形容为战争,是让大家清醒的认识到,不管你和客户有多好,要知道客户就是客户,不可能成为自己人。
在项目中除了你的公司,你没有自己人。
对于需求调研,古人有话证:
“兵者,国之大事。
死生之地,存亡之道。
不可不察也”--孙子兵法始计
胜负在此一举(需求分析)看破对手
自从第一次交手完毕后,毕(其实是鄙,我不想用这个字,就私自换了一个)人回到公司,先与首辅同志汇报一下,再看看我那五万丘八练得如何,之后拿出“锦囊”开始着手整理客户的需求。
整理需求也是很有学问的,首先是要区分里面的有用的需求和无用的废话。
怎么区分啊,当然不是用SELECT语句或者把这句话通过泛型引入到类的方法里,之后等待系统返回是true还是false了。
能看出里面真正的需求,与找到对手破绽都要用到一样本领,我们一般把这种本领称为行业经验。
行业经验是如何炼成的?
我们知道战争是分军种的,比如海军、陆军等。
项目也是分行业的。
比如制造业、物流业、政府行业、金融行业等等。
做为IT产业,属于服务型行业。
我们知道服务型行业必须依附于生活需要所存在,如饭店、桑那以及那些路边亮红灯小店里招手的。
那IT产业也同样了,比如这家公司是给政府做电子政务,那家公司是给制造业做ERP。
一个项目经理在同样的行业时间久了,形成对这个行业结构和业务形态的了解就是他的行业经验。
行业经验越多,做起来同行业的业务就越熟练越快,成功机率也就越高。
当然了也存在那些无师自通的猛人,我们称为天才。
我这里只讲一般性,超人和蜘蛛侠不在我讲的范围。
有了行业经验,在需求分析时就体现出这种经验的重要性了(说明一点需求分析应该是BA做的,但在国内现状很多时候这种工作都是项目经理代劳的)。
回到我“锦囊”里的那些需求吧。
由于我做物流行业7年了,所以较容易分析出其中的需求和废话。
并发现其中有多种破绽(业务流程有漏洞、需求之间相互矛盾、需求不清晰)
那要是没有行业经验怎么办呢?
如果你现在到一个新的行业,不能依赖原有的行业经验来判断,千万别以为ERP和物流都是供应链的应该差不多吧。
在行业里可别认亲戚,因为我们的祖先早就告诉我们了“隔行如隔山”。
所以在新行业中,要放弃原来的行业经验,从零开始。
当然了困难肯定是有的(没有困难找项目经理做啥),缺少行业知识时,最重要的一点,就是在和客户交手时,你根本没法招架,就像你是少林派,非得和西洋拳交手,不出半分钟你就被罚下场了,理由是伤害对方腰带以下,而且用的是脚。
我们玩帝国时,在不明了敌人数量和位置的时候,你应该要尽量收缩你的部队做好防卫,之后派出侦骑(斥侯)去探明对手的虚实。
同理在和客户交手时,把他们所有的招数都记下来,一定要记到“锦囊”里,如果记到哪张报纸上后来不见了,你自己想办法吧。
记下后,回到公司逐招分析,不会就XX一下,做到尽量理解,如果能发现对手招数中的破绽,恭喜你,你现在可以看到对手(客户)的破绽了。
用笔在破绽的地方标出来。
在双方第二次面对面时,我提出业务流程的漏洞,客户开始边和我讨论边思考,但我明显感觉到讨论时向我学习的成分在增加。
因为这就像打仗时看破对手的阵型一样,对方觉得你很专业,至少比他强。
而我告知他漏洞的行为让他觉得,你在为他着想,对你的好感和信任都会大增。
这是个机会,战场上要时刻占据主动,但项目中有时要以退为进。
之后我摆出第二招“欲擒故纵”。
把相互矛盾的需求提了出来。
并把解决问题的决定权交给客户了。
这回客户就有活干了。
当敌人不动时是不会有破绽的,破绽总是出现在出招后。
客户为了解决矛盾的需求,开始变更原来的说法,这时我又抓住一个新的漏洞,彻底捍卫了我在这次战场上的主动权。
最后把几个需求不清晰的部分,交给客户。
对方的回答时,回去再好好仔细想想。
我知道鸣金的时候到了。
我们是做项目又不是真的打仗,得了便宜就跑。
收队!
这次交手可是收获颇丰啊,现在形势很好啊,是大好不是小好。
以后我再和客户沟通就不用担心了。
俗话说:
人的名,树的影。
意思就是关羽没劈华雄、战吕布、斩颜良、诛文丑时,连出战单挑的机会都很难,而成名后找关羽的人就要抬棺材才能上阵。
所以此次之后,客户将会对我的业务能力有一个肯定。
在未来这个肯定会带来意想不到的结果。
篇后话
昨天Sail跟我说,需求这段我写得战争味太浓了。
我是很想写的花香水美的,但是这种两者对抗除了战争,我实在找不到再精准的比喻了。
其实看破对方需求破绽的主要用途不是为了项目的进度,而是为了让你,就是乙方占据项目的主动权,不让项目失控。
从看破对手的行为体现出你高人一等的水平,使对方对你的能力进行肯定并且相信你。
就像股票一样,有个人说明天大盘会到XXXX点,你不信,结果预言成真。
第二次他又预言中了,到第三天还是一样,如此5、6次,你会认为这个人很牛是股神,并且完全的相信这个人讲述关于股票的一切吗?
看看带头大哥的事件就知道了,这种心理作用还是很大的。
胜负在此一举(需求分析)之斗智斗勇
按说需求调研好了,应该由乙方整理后提交《需求规格说明书》。
那甲方这时候干什么呢?
我找了很多资料,没有发现对这时甲方的工作要求。
换言之就是甲方这时没事干。
甲方没事干对我来说是件非常可怕的事,比我那闲置的五万丘八还可怕。
丘八闲置只是浪费一点钱,不会出事,客户闲下来是要闹事的。
“温饱思X欲”,这可是圣人言啊。
当然了客户不可能对我那个啥的(IT项目好像也没有这种潜规则),但是他无聊时,就会想很多,他想得多了,就会给你找活干。
你看看你们公司给你安排工作的人都是不做实际事的,天天就是想着让你干啥活,今天出个考核表,明天搞个测评,后天让你写程序员日记。
自己人都这样,何况是当爷爷的客户呢。
找你干活没商量。
所以我的做法就是我工作时,客户也不能闲着。
所以我会安排很多事给他们做,比如流程图的确认工作、所有报表EXCEL化并写清每列的计算方法、功能列表的确认。
总之我会把整个《需求规格说明书》拆成几个部分来确认,像报表这个部分基本就是让客户做的。
不过一开始客户不太高兴呢,毕竟傻子都知道花报表这个是挺大的工作量,反正我说了如果我做了报表你们再看再修改那时间肯定不够用了,而且报表大部分是给领导看的,如果不合领导心意肯定不好,再说你做的报表,让领导知道,会对你大加表扬的。
客户权衡利弊后,决得还是自己做划算一些。
从此这个项目中的报表都是客户做的,大概120多张吧。
现在客户有事忙了。
我要开始做《需求规格说明书》了。
所说《需求规格说明书》,就是包含项目目标、背景、功能列表、用例的文档。
现在我们要做的就是从客户一大堆的流程和描述中,分别找出功能来。
有个简单的办法,把客户描述中的名词都标出来,每个名词就是一个对象,而名词所做的动作就是方法。
将具有同类的对象设计为一个功能。
看功能列表和用例数都出来了。
好了要写用例了,说到用例我要罗索一点了。
春秋时有个叫孙子的人,当然了本名不叫孙子,叫孙武,后来的人尊敬他就叫他孙子了(原来古代是这样尊敬人的,汗啊)。
在他的一本书里说“知已知彼,百战不殆(dai同带,不是台啊,我认识位仁兄就读错了)”。
所说知己,就是说,了解自己的实力。
我们做项目自己这边的斤两还是清楚的。
那知彼就难了,要了解对方的体重了,怎么了解啊,在项目里当然不能用体重秤了,好在这个世界上聪明人很多,有几位大侠就发明了一种工具,专门来了解客户的需求,这几位大侠是......(都是老外,也不用多了解,反正会用工具就行了,如果有想了解的同志,可以去找UML发展史看一下。
)。
这种工具就是UML,准确的讲,是UML当中的用例部分。
用例是一个工具,估计大多数人都用过,可是你知道这个工具除了能描述需求外还能完善需求吗?
我最喜欢的就是用例能完善需求的功能。
用例怎么做,我就不说了,回去找一本《UML模型与设计》看一下就知道。
完善需求是我在做项目体会到的。
我们将用例完整的填写到用例说明的时候,会发现有时这个说明写不下去了,写不下去的原因是因为你根本不知道这里该如何处理。
比如某个用例的扩展流程“当无法找到当前记录时,系统应......”这时你发现系统要怎么做是不知道的,因为需求里没有写明,这时就要和客户沟通了。
当你把所有的用例都填写完成后,基本上产品的样式就出来了。
我见过有人只写主流程,而不写扩展流程的,我的经验告诉我,如果不写扩展流程你会死得很惨。
就像我们出门旅行,你只带了必用品,没有带“谢丽婷”,到时你的旅行就行可能变成公厕观光游,还是付费的。
所以必须写完扩展流程。
不过工作量和风险是成正比的,因为扩展流程往往是主流程的三到五倍。
用例图画一个主体的就行了,千万别给每个用例画图,因为那样会变成一个小人用长矛插一个鸡蛋,很难看的,同时也没啥大用处。
有空多写点用例说明吧。
好像这样做要写很多用例了,这次我做项目就写了200多页用例,如果这个用例只是给客户看看的实在是太浪费了。
别急后面我会讲这个用例怎么用到开发中。
好了用例写好了,《需求规格说明书》完成了,现在要做一件很重要的事---签字。
找到客户,客户说这么多要看一下才能签字。
好,给你们看吧。
这一看就是一星期。
其实给客户签字的东西写得越多就越有利。
你想一本200页的文档,你会逐项逐字的看吗?
最终客户同意签字了。
为什么说签字重要呢,写《需求规格说明书》就是草拟圣旨,圣旨不盖玉玺是没用的,签字就是盖章了。
很多人感觉到给客户签字后,客户的需求依然想变就变,细毫不为以前的签字而脸红,项目管理的书上说签字就是确认,是不应改变的,书上还说签字是对客户的约束,但现实根本和书上说的不一样啊。
其实大可不必为这种事大惊小怪。
因为客户从来没看过项目管理的书啊。
其实这个问题要从圣经说起。
上帝造人后,亚当和夏娃的子孙,决定通过自己的能力建造一座塔,一座通到天堂的塔,圣经里称为巴别塔。
上帝这老小子挺缺德的,他不想大家都上天堂,于是给不同的人类赋于了不同语言,好家伙。
大家不能沟通了,那造塔计划也就失败了。
这是历史上记载最早的失败项目,失败原因是沟通不畅。
之后语言们各自发展直到现在。
现在我们看到最大的文化差异就是象型文字的代表汉语与拼音文字的代表英语两者产生的。
签字文化发展于英语也就是中国人眼里的西方世界,原因很简单,英文仅有26个字母,每个书写不同的主要点在字母与字母间的连接,而老外签名一般都是一笔就写好了。
这样造成老外的签名模仿难度极大,被肉眼分辩的成功率较高。
再看看中国人签名,中国的汉字是方块字,字与字之间一般不连,而汉字发展了5000多年,还优雅的发展出大量的书法门派,中国人把写字提升到艺术层次。
导致临摹胜行(小时候我还写过《庞中华字帖》呢)。
经过这么多年,中国人多少都有临摹的基因,所以用心学个人的笔迹不是很困难,但是发现两者不同却要笔迹专家的水平(小时候在考卷上模仿家长签字,老师都很难发现)。
久而久之,中国人对签字变得不再用心了,签字认证也就不被世面接受。
在这种环境下,你一定要求客户签字认证,是很困难的。
当然了项目管理的书没有说错,毕竟那是老外的东西。
所以要控制客户的疯狂变更,还要想别的办法?
后面我将详细说一下,我是怎么控制客户变更的。
在我的勇气(敢给客户安排工作)和智慧(写了厚厚的需求说明)下,需求总算确定下来了。
焦油坑(需求变更)之充满想象力的客户
我们回来需求调研,在这时客户提出了一大堆的想法,我们姑且称为设想。
这些设想有些是依据现实业务提出来的,有些就是天马行空了。
要想分析变更,先理解变更是怎样炼成的。
什么是变更呢?
举例就是盖房子的地基打好了,回头客户说,五层楼不行,要改成十层楼。
这个行为就是变更。
大家都知道变更,是指在某个东西的原样上进行改动。
这就有个问题了,原样在哪?
在我这个项目里来看,原样就是客户签字和盖单的《需求规格说明书》。
现在大家知道了吧,要是你没有签字的需求,连做变更的权利都没有了。
变更的原因有很多种,主要原因是理解差异,政治参与和客户主观三种。
我这次只说客户主观变更的问题。
其余两项将在后期详细说明。
客户主观变更在需求变更中算是最好处理的了。
用金先生的“打狗棒法”就行了(不是骂客户啊)。
这是丐帮的不传功法,我这边没这规则,毕竟我不是要饭的。
第一招“绊字诀”
这天我正在做数据库设计(小公司就是惨啊,什么活都要项目经理来做),客户电话来了。
“羽之啊,我能不能在新建用户,同时新建角色啊”
他说的意思就是在,新建用户的界面可以单击按钮,切换到新建角色里去。
实话讲这个要求是确实会简化操作,但有个问题,这个问题就会让他的变更无法实现。
“没问题的啊,系统加个按钮就行了,这样操作会简便很多”这种情况要马上答应他,并且赞美他。
“不过(重点出来了),如果总公司要对角色进行统一管理,而用户新建的权限放到分公司怎么办呢?
”把问题抛回去,让他自己否定自己。
“这个问题啊,我回去再考虑一下”。
结果和我预想的一样,这一考虑就没下文了。
这就是绊字诀,先把他的招接过来,之后他脚下出一招,让他用自己的冲力把自己摔倒
第二招“封字诀”
有一次我去见客户,和他商讨表单打印问题。
大家都知道WEB打印是件比较痛苦的事情,但客户不这样认为,
他说:
“我们结算系统的打印方式就挺好的,效果好看,功能又多”,
看来他是想让我也实现这个功能。
我想既然有好的东西,咱就本着学习的态度去看看吧
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目